01. Аудит 100 % звонков и переклассификация без повторного ASR

Проблема

Отдел контроля качества физически слушает 1–7 % звонков: выборка формируется вручную, а «неудобные» звонки (короткие, с конфликтом, с отказами) в неё не попадают. Руководитель принимает решения по 3 % разговоров и считает, что знает про остальные 97 %.

Вторая, менее очевидная проблема: модель классификации устаревает. Сменился скрипт, появилась новая кампания, изменилась таксономия — и весь исторический массив звонков описан старыми метками. У классических решений повторный разбор означает повторный прогон распознавания: дорого, долго, иногда невозможно (аудио уже удалено).

Решение

Разделяем дорогое и дешёвое. Распознавание (ASR) делается один раз и сохраняется в S3/MinIO как JSON с таймкодами. Классификация — отдельная стадия, которая читает транскрипт и пишет вердикт по ключу call_id + taxonomy_version.

Отсюда три следствия, которые и продаются:

1. 100 % покрытие. Обрабатываются все записи, без выборок и «ручных отборов». Полный охват даёт то, чего не даёт выборочное прослушивание: конфликты, отказы и короткие сбросы попадают в анализ, а не выпадают из него.
2. Переклассификация архива за часы. Изменили таксономию или промпт — запускается только стадия классификации. ASR не повторяется. Пересчёт 6 млн звонков — это работа LLM-слоя, а не GPU-распознавания: часы вместо недель.
3. Сравнение версий таксономии. Каждый вердикт хранит taxonomy_version, поэтому можно ответить на вопрос «сколько было бы конфликтов, если считать по новому определению» — без повторной обработки аудио.

Знаменатель покрытия

«100 %» считается от записей, поступивших в конвейер: файл доставлен коннектором или выгрузкой из АТС и прошёл стадию приёма. Что не было доставлено, система увидеть не может, — поэтому честный охват проверяется сверкой объёмов: число звонков в выгрузке АТС против числа принятых и обработанных. Методику сверки (период, источник, разбор расхождений — недоставленные файлы, дубли, записи вне периода) фиксируем на пилоте, вместе с критериями Go/No-Go.

Дашборд покрытия разделяет три знаменателя: поступившие записи, обработанные и ушедшие в очередь ручного контроля — чтобы «обработано 100 %» всегда имело явную базу сравнения.

Как это выглядит

• Дашборд покрытия: «обработано 100 % из 1 284 930 звонков за период», отдельно — доля звонков, где сработала очередь ручного контроля.
• Кнопка «Переклассифицировать»: выбор периода + версии таксономии → задача с прогрессом и ETA; по завершении — отчёт «что изменилось» (сколько звонков сменило метку).
• API: POST /v1/reclassify {from, to, taxonomy_version} → job_id; GET /v1/jobs/{job_id} → прогресс. Тарификация — по полям classification.*, без повторной оплаты минут.

Метрики успеха

Как это устроено у нас

• Классификация идёт по сохранённым транскриптам: смена таксономии пересчитывает вердикты за часы и не запускает распознавание заново.
• Версии таксономии сохраняются: видно, что изменилось после переклассификации и на каких звонках.
• Один конвейер работает и на потоке, и на архиве.