журналопыт и цифрыавтор

директор и машина · контроль качества · заметка с планёрки · запись № 053 · · Давид Герштейн

Транскрибация обрывается на полуслове: техническая изнанка речевой аналитики

66 звонков/мес сверки · дельта оценок · лимит символов в ячейке
Коротко · суть разбора

Речевая аналитика в этом кейсе ошибалась не потому, что подвела модель, а потому что транскрипт звонка обрезался техническим лимитом ячейки таблицы ещё до того, как его увидел ИИ. Решение — хранить полную расшифровку отдельно по ссылке, а не в самой таблице, и проверять оценки ИИ ручной сверкой: за первый месяц так перепроверили 66 звонков.

Содержание · 3 разделов
  1. Что нашли внутри: где речевая аналитика теряет данные до ИИ
  2. Что сделали: ссылка на расшифровку вместо текста в ячейке
  3. Почему это касается не только транскрибации

Речевая аналитика в CRM должна была снять с Иры рутину прослушивания звонков — и почти сняла, пока не начала путать несделанную работу с сделанной. Ира на планёрке кладёт на стол распечатку одного звонка и говорит: «Я не понимаю, за что ему поставили тройку. Он же весь скрипт отработал». Смотрим оценку ИИ — действительно тройка, комментарий модели: «менеджер не выявил потребность, не назвал цену». Слушаем запись — потребность выявлена на второй минуте, цена названа на седьмой. Звонок на девять минут. Значит, дело не в звонке.

Ира почти три года слушала звонки ушами — сначала по тридцать в день, потом меньше, когда добавились текстовые каналы. Она первая сказала фразу, которая потом стала поводом для отдельного разбора: «оценка плывёт», когда транскрипт какой-то… короткий. Мы сначала подумали, что дело в качестве записи — шум, обрыв связи. Оказалось, дело не в записи.

Что нашли внутри: где речевая аналитика теряет данные до ИИ

Расшифровки хранились прямо в таблице — одна ячейка на один звонок. Удобно: открыл строку, увидел весь текст, рядом оценка. Но у ячейки в таблице есть технический лимит на количество символов. Длинные звонки — от десяти минут и дольше — в этот лимит не влезали. Текст обрезался молча, без ошибки, без предупреждения. ИИ получал не весь разговор, а его начало, и честно оценивал только то, что видел.

Система не ошибалась — она оценивала то, что ей дали. Дело было не в модели, а во входных данных.

Дальше выяснилось второе: даже когда транскрипт полный, оценка одного и того же звонка при повторном прогоне не всегда совпадает сама с собой. «Оценка, она не всегда адекватна» — так это сформулировали на разборе. Прогнали один звонок трижды — получили не три одинаковых результата, а три близких, но разных. Для менеджера, у которого от этой оценки зависит премия, разница в один балл — это не мелочь.

Что сделали: ссылка на расшифровку вместо текста в ячейке

С обрезкой транскрипта решение нашлось простое, хотя дошли до него методом исключения. Вместо полного текста в ячейке таблицы теперь хранится короткий фрагмент — начало разговора для ориентира — и ссылка на полную расшифровку, которая лежит отдельно и открывается по клику. ИИ для оценки берёт полный текст из документа, а не то, что видно в таблице глазами человека. Разделили «что показываем человеку» и «что скармливаем модели» — вопрос, который вообще стоит держать в голове, когда решаете, какие данные можно отправлять в нейросети, а какие нет. Половина проблемы закрылась.

Со вторым — нестабильностью оценки — решили не бороться в лоб, а сначала измерить масштаб. Ввели ручную сверку: каждый месяц отдел контроля качества берёт часть звонков — набралось 66 за первый месяц — и оценивает их вручную параллельно с ИИ. По каждому звонку считается дельта: разошлись ли оценки и насколько. Это не финальное решение, это диагностика — мы пока не готовы полностью довериться автоматической оценке, если не понимаем, насколько она вообще адекватна. Заодно ручная сверка помогает не превратить запуск автоматической оценки в саботаж со стороны тех, кого она оценивает — эта часть внедрения устроена так же, как в кейсе про контроль звонков без саботажа.

Честно: если раньше Ира могла ушами прослушать от силы тридцать звонков в день, то ручная сверка 66 звонков в месяц с оценкой ИИ — это ещё около трёх часов её времени каждую неделю, которые раньше не тратились. Пока это не экономия, это цена за то, чтобы вообще понять, можно ли автоматизации доверять.

Почему это касается не только транскрибации

Проблема шире одной ячейки в таблице. Любая CRM-интеграция речевой аналитики сталкивается с вопросом: как система понимает, что это именно тот звонок, который нужно оценивать. Первый звонок может быть холостым, следующий — система не захватит, менеджер не всегда переводит сделку на нужный этап вовремя — это отдельная головная боль, разобранная в материале о том, почему менеджеры не вносят данные в CRM. Мы в итоге ушли от привязки к действиям менеджера — систему настроили так, что она сама выгружает все звонки по клиенту с уникальными идентификаторами и смотрит контекст предыдущих разговоров перед тем, как оценить последний. Про то, как это устроено технически на стороне речевой аналитики целиком — отдельный разбор в «Контроль качества звонков без ОКК».

Вывод с этой конкретной планёрки простой: прежде чем доверять оценке ИИ по звонкам, проверьте не модель, а трубу, по которой в неё льются данные. Обрезанный лимитом транскрипт и гуляющая от прогона к прогону оценка — не повод отказываться от речевой аналитики. Это повод не запускать её на всех менеджеров сразу, пока дельта между машиной и человеком не посчитана хотя бы на паре месяцев данных.

Мы пока эту дельту считаем. Чем кончится — расскажем отдельно.

#контроль и надёжность #ии и нейросети #ошибки и провалы

Дальше читать подобрано по направлению и темам
006
Как оценивать звонки: пять критериев вместо полусотни пунктов
66 звонков ручной сверки · цена одной ошибки — до 2,4 млн ₽ (оценка) · 25% охват контролем вручную
051
Как нейросеть научили оценивать звонки менеджеров: от калибровки до расхождений с ручной проверкой
66 звонков сверки · 25%→100% охват · 10 чек-листов
054
Распознавание документов ИИ: как мы снизили ошибки с 20% до 7% на 92 эталонных документах
92 эталонных документа · ошибки 20% → 7% · токены −30–40%