Как выбрать систему речевой аналитики: пять уровней разбора разговора

Вопрос «есть ли в системе GPT или LLM» в 2026 году почти перестал делить рынок: языковую модель через API добавляет практически любой поставщик. Полезнее понять, как продукт комбинирует уровни разбора и можно ли проверить его выводы. Именно здесь под одним названием «речевая аналитика» скрываются технологически разные системы: одни работают на правилах и словарях, другие добавляют машинное обучение, третьи опираются на LLM, а сложные платформы держат несколько подходов сразу.

Автоматический разбор звонков компании берут ради охвата. Классический отдел контроля качества физически успевает прослушать 1–3% потока, а речевая аналитика оценивает почти весь. Но фраза «проверяем 100% звонков» не говорит, как именно идёт проверка: в одном продукте это поиск пяти обязательных слов, в другом — чек-лист на 40 параметров, в третьем — смысловая оценка сценария языковой моделью. При сравнении Auto-QA важна глубина критерия; доля анализируемых коммуникаций сама по себе говорит мало.

Из чего собран разбор звонка

Упрощённо конвейер выглядит так: аудио → ASR → транскрипт → структурирование → анализ → бизнес-правило → действие. Для звонка это распознавание, разделение реплик оператора и клиента, определение возражения, оценка работы менеджера, запись результата в CRM.

Первый слой, ASR, переводит аудио в текст, и на нём критичны шум, телефонный кодек, акцент, одновременная речь и корректная диаризация спикеров. Здесь легко ошибиться при выборе: точный транскрипт ещё не даёт точного разбора. Система может почти идеально восстановить слова разговора и при этом плохо определять причину отказа, соблюдение скрипта или скрытый негатив. Качество распознавания измеряют через WER (Word Error Rate), реже CER, precision, recall, F1, latency p50/p95/p99 — и любая из этих цифр сопоставима только при одинаковом наборе аудио, разметке и методике расчёта.

Пять уровней, и каждый остаётся рабочим

Словари и правила. Системе задают слова и выражения — «дорого», «подумаю», «хочу расторгнуть» — и добавляют логику вида «клиент произнёс фразу X, а оператор в следующие 30 секунд не произнёс фразу Y». Такой подход хорошо закрывает compliance: была ли произнесена обязательная юридическая формулировка, назвал ли сотрудник своё имя, упоминался ли конкурент, звучала ли запрещённая лексика. Правило «сказано X → true» дешевле, быстрее и легче проверяется, чем прогон того же вопроса через LLM. Слабое место одно: люди говорят не так, как написаны скрипты, и «слишком дорого для меня сейчас», «не уверен, что готов столько отдавать» и «вернёмся к этому через пару месяцев» словарь по цене не свяжет.

ML-классификация. Вместо перечисления всех формулировок модель обучают определять класс: причина обращения (покупка, возврат, техническая проблема, жалоба), результат разговора (продажа, отказ, повторный контакт). ML эффективен на массовых повторяемых задачах — категоризация миллионов звонков, контроль типового чек-листа, базовая Auto-QA.

Семантический анализ. Система ищет близкие по смыслу высказывания: под запрос «клиент считает стоимость высокой» подходят «не вижу смысла платить столько» и «у конкурента существенно дешевле». Реализуют это через embeddings, NLP-модели, LLM или их сочетание. Аналитик описывает бизнес-смысл, а формулировки система подбирает сама.

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

Поиск неизвестного заранее. Система сама кластеризует массив разговоров и подсказывает категории проблем, которых аналитик не закладывал. Пример механики — «дерево смыслов» Yandex SpeechSense: иерархия тем строится автоматически вплоть до восьми уровней и открывает слепые зоны.

Каждый следующий уровень надстраивается над предыдущим и продолжает им пользоваться. Хорошая архитектура ближе к формуле «словари + правила + ML + semantic AI + LLM», где инструмент применяется там, где эффективнее.

Где LLM обходится дорого

У языковой модели есть четыре ограничения, и не все они про деньги. Прогон простого чек-листа через LLM для нескольких миллионов звонков заметно дороже правил или ML. Ответ недетерминирован: он зависит от промпта, контекста, модели, температуры, версии и длины разговора — для compliance-задач это критично. Вывод модели нужно уметь проверить, поэтому enterprise-система должна показывать фрагмент диалога, на котором построено заключение. И качество промпта прямо задаёт качество критерия: слабый вопрос даёт слабую метрику.

Отсюда гибридные схемы. Naumen рекомендует массовые типовые проверки отдавать ML, а языковые модели подключать к задачам с глубоким бизнес-контекстом; в проекте ОТП Банка описан именно двухуровневый разбор, где ML делает массовую классификацию, а LLM разбирает сложный контекст и эмоции клиента. Это распределение вычислений по стоимости: дорогой инструмент не ставят туда, где задачу надёжно решает дешёвый.

Приёмы, по которым видно глубину

Несколько механик стоит научиться узнавать в демо. ABSA (aspect-based sentiment analysis) разделяет отношение к отдельным аспектам: в реплике «интернет работает отлично, но тариф стал слишком дорогим» качество связи получает плюс, а стоимость — минус, тогда как обычная оценка тональности упирается в противоречие. Каскадное промптирование, которое публично показала BSS, заменяет один огромный запрос цепочкой шагов — определить цель обращения, при продаже определить потребность, при возражении классифицировать его, проверить действия оператора, собрать итоговую оценку, — и каждый шаг использует результат предыдущего.

Вопросы поставщику

Какие данные получает модель — весь разговор или только отдельные реплики.
Можно ли создавать собственные критерии или доступны только готовые.
Как строятся сложные зависимости: получится ли задать условие «если произошло A, но не произошло B, проверить C».
Показывает ли система фрагмент разговора, на основании которого принято решение.
Можно ли сочетать LLM с точными правилами — это важно для compliance.
Можно ли менять модель, особенно для On-Premise.
Сколько стоит массовый анализ: цена тысячи тестовых диалогов и миллиона звонков — разные экономики.

Рекламные «точность 95%» и «самое точное распознавание» без описанной методики почти ничего не сообщают.

Что дать системе на пилоте

Демо разработчика показывает удобные случаи, поэтому для проверки полезнее взять 100–500 собственных реальных коммуникаций и намеренно добавить трудные. Шесть проб разводят уровни между собой:

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

На пробах с первой по вторую сойдутся почти все системы; расхождение между технологиями видно начиная с третьей.

Как сузить выбор

Ключевой сдвиг последних лет — уровень вопросов, которые бизнес задаёт разговорам. От «сколько клиентов сказали „дорого“» к «почему клиенты считают продукт дорогим» и дальше к «какие характеристики продукта и у каких сегментов чаще дают ощущение завышенной цены». Такой разбор кормит данными маркетинг, продажи, CX и обучение.

Готовый инструмент для отдела продаж закрывают специализированные SaaS с коротким порогом входа. Компаниям с собственной методикой продаж и ветвящимися регламентами ближе конструктор или platform-решение, где методологию можно перенести в систему целиком. Финальное сравнение внутри короткого списка идёт по цепочке: архитектура → управляемость → масштаб → стоимость вычислений → интеграция в реальные бизнес-процессы.