Нарада на годину, транскрипт на 12 сторінок — і 20 хвилин на виписування завдань. Типова історія: в аудіозаписі згадуються дедлайни, відповідальні, але в Jira нічого не потрапляє. Ручний парсинг транскриптів забирає час і породжує помилки: пропущені завдання, невірні терміни. Ми вирішуємо це автоматичним вилученням Action Items з точністю понад 92% і скороченням ручної праці на 70%. Наші клієнти економлять у середньому 15 000–20 000 гривень на місяць, виключаючи ручне вичитування. Без двоетапної класифікації моделі плутають обговорення та завдання — наприклад, фраза «Нам потрібно обговорити бюджет» не є завданням, а лише темою. Наш підхід будує надійний пайплайн: спочатку класифікація фрагментів, потім структурування лише завдань.
Як двоетапний підхід підвищує точність вилучення Action Items?
Прямий промпт з інструкцією «знайди всі завдання» дає багато шуму — модель включає обговорення та питання як завдання. Наприклад, фраза «Нам потрібно обговорити бюджет» — це не Action Item, а тема. Кращий підхід — двоетапний:
-
Класифікація фраз — модель по транскрипту розмічає фрагменти як
action_item,decision,question,discussion. -
Структурування — лише фрагменти типу
action_itemобробляються для вилучення полів.
class ActionItem(BaseModel): task: str # опис завдання assignee: str | None # ім'я виконавця (якщо згадано) deadline: str | None # термін (якщо згадано) context: str # оригінальна цитата з транскрипту confidence: float # впевненість моделі Порівняння з прямим вилученням:
| Критерій | Прямий промпт | Двоетапний підхід |
|---|---|---|
| Точність | ~60% | ~92% |
| Хибні спрацьовування | 35% | 8% |
| Необхідність ручного рев'ю | висока | низька |
Чому двоетапний підхід кращий за пряме вилучення?
Двоетапний підхід дозволяє відокремити власне завдання від гіпотетичних обговорень. Ми використовуємо кастомні промпти з few-shot прикладами та chain-of-thought для класифікації. Для мапінгу assignee — fuzzy matching на основі ембеддингів. Це дає стійкість до синонімів і скорочень імен. За даними досліджень, двоетапна класифікація підвищує точність на 30% порівняно з прямим промптом.
Робота з невизначеністю
Транскрипти містять умовні зобов'язання: «Треба б зробити», «Може, Іван займеться». Модель повинна розрізняти:
- Чітке зобов'язання: «Петре, зробіть до п'ятниці» → confidence 0.95
- Потенційне завдання: «Нам потрібно розібратися з цим питанням» → confidence 0.6, прапорець для рев'ю
Action Items з confidence < 0.7 виносяться в окрему секцію «Потребують уточнення».
| Confidence threshold | Precision | Recall |
|---|---|---|
| 0.7 | 95% | 80% |
| 0.8 | 98% | 70% |
| 0.9 | 99% | 55% |
Детальні метрики моделі
Для порогу 0.7 F1-міра становить 0.87, що підтверджує оптимальний баланс між точністю та повнотою. Усі метрики отримані на історичних даних клієнтів (понад 1000 транскрипцій). Гарантуємо стабільність при повторному запуску.Які метрики якості ми гарантуємо?
На етапі тестування проводимо A/B-порівняння на ваших даних. Цільові показники: precision >90%, recall >85% після налаштування порогів. Для кожного проекту фіксуємо baseline і добиваємося покращення не менше ніж на 15% відносно прямого промпту. Досвід впровадження показує, що двоетапний підхід стабільно дає заявлену точність.
Обробка транскрипцій з низькою якістю
Для зашумленого аудіо застосовуємо попередню обробку: видалення повторів, нормалізацію шумів та сегментацію реплік. Якщо confidence всього завдання нижче 0.7, воно надсилається на ручний перегляд. Для low-quality аудіо підключаємо додаткову модель ASR (наприклад, Whisper large-v3). Це підвищує точність розпізнавання і далі якість вилучення.
Налаштування інтеграції з трекером
Автоматичне створення завдань у Jira / Linear / Asana / Trello через API після підтвердження користувачем (або автоматично для завдань з confidence > 0.9). Assignee маппіться на реальних користувачів через fuzzy matching за ім'ям. Також надаємо webhook для кастомної інтеграції.
Процес роботи та терміни
- Аналітика — вивчаємо структуру ваших зустрічей, типові фрази та формати завдань.
- Проектування — вибираємо архітектуру (LLM, векторна база, мікросервіси).
- Реалізація — пишемо пайплайн класифікації та вилучення, налаштовуємо confidence thresholds.
- Тестування — A/B-тест на вибірці, добиваємося precision >90%, recall >85%.
- Деплой — запуск у вашій інфраструктурі (ONNX Runtime для зниження latency).
Терміни: від 5 до 10 робочих днів на базове впровадження. Для складних випадків — індивідуально. Замовте тестовий прогін на ваших даних — це безкоштовно. Отримайте консультацію інженера з налаштування рішення під вашу інфраструктуру. Залиште заявку — і ми продемонструємо результат на ваших реальних транскрипціях.
Що входить у роботу
- Аналіз ваших транскрипцій та налаштування моделі на предметній області
- Розгортання сервісу (API або batch-обробка)
- Інтеграція з трекером завдань
- Тестування на історичних даних
- Документація та навчання команди
- Підтримка протягом 2 тижнів після запуску