Разбираем технологии речевой аналитики: ASR, словари, ML, семантический анализ, LLM и Auto‑QA. Сравниваем подходы Deeray, Naumen, SpeechSense, BSS, WordPulse и других систем.
Поиск слова «дорого» в транскрипте звонка когда‑то считался речевой аналитикой.
Сегодня бизнес хочет получить ответ уже на совершенно другой вопрос:
Почему клиент не купил, даже если ни разу прямо не сказал, что его не устраивает цена?
И это две принципиально разные задачи.
В первом случае достаточно распознать речь и проверить текст по словарю. Во втором системе необходимо учитывать контекст, последовательность реплик, намерение клиента и зачастую весь сценарий разговора.
Именно поэтому под названием «речевая аналитика» в 2026 году продаются технологически очень разные продукты.
Одни по‑прежнему в значительной степени работают на правилах и словарях. Другие добавляют машинное обучение. Третьи используют LLM. А наиболее сложные платформы комбинируют несколько подходов одновременно.
Разберемся, зачем нужны все эти уровни, почему LLM не всегда лучше обычного правила и как оценивать системы речевой аналитики с технической точки зрения.
Из чего вообще состоит речевая аналитика
Упрощенно pipeline современной системы можно представить так:
Аудио → ASR → транскрипт → структурирование → анализ → бизнес‑правило → действие
Например:
звонок → распознавание → разделение оператор/клиент → определение возражения → оценка работы менеджера → запись результата в CRM.
Но между «получили текст» и «поняли, что произошло» сегодня располагается уже несколько технологических слоев.
1. ASR — распознавание речи
Первый слой переводит аудио в текст.
На этом этапе критичны:
качество записи;
шум;
телефонный кодек;
акцент;
профессиональная терминология;
скорость речи;
одновременная речь;
корректная диаризация спикеров.
И здесь возникает первая распространенная ошибка при выборе продукта.
Хорошая транскрибация еще не означает хорошую речевую аналитику.
Система может практически идеально восстановить текст разговора, но плохо определить:
причину отказа;
соблюдение скрипта;
потребность клиента;
качество аргументации;
скрытый негатив.
Это уже задачи следующих уровней.
Уровень 1. Словари и правила
Самая понятная механика речевой аналитики.
Мы задаем системе набор слов или выражений:
«дорого»
«подумаю»
«конкурент»
«жалоба»
«хочу расторгнуть»
и получаем звонки, где они встречаются.
К простому словарю можно добавить логику:
«показать звонки, где клиент произнес фразу X, а оператор в течение следующих 30 секунд не произнес фразу Y».
Получается уже простая сценарная аналитика.
Где словари до сих пор хороши
Очень хорошо.
Например, когда требуется определить:
была ли произнесена обязательная юридическая формулировка;
называл ли менеджер конкретный продукт;
использовал ли запрещенную лексику;
упоминался ли конкурент;
назвал ли сотрудник свое имя;
произнесено ли кодовое слово.
Для таких задач использование LLM иногда даже менее рационально.
Правило:
если сказано X → true
дешевле, быстрее и проще проверяется.
Главная проблема словарей
Люди разговаривают не так, как написаны скрипты.
Клиент может сказать:
Для меня сейчас это слишком дорого.
А может:
Не уверен, что готов столько отдавать.
Или:
За эти деньги я лучше пока ничего менять не буду.
Или вообще:
Давайте вернемся к этому через пару месяцев.
Во всех четырех случаях причиной поведения потенциально является цена, но простой словарь может увидеть только первый вариант.
Количество правил начинает расти.
И возникает классическая проблема:
чем больше вариантов живой речи нужно учитывать, тем сложнее поддерживать словарь.
Уровень 2. ML‑классификация
Следующим этапом развития стали модели машинного обучения.
Вместо ручного перечисления всех фраз система обучается определять класс.
Например:
причина обращения:
покупка;
возврат;
техническая проблема;
консультация;
жалоба.
Или:
результат разговора:
продажа;
отказ;
повторный контакт;
запись;
нецелевой звонок.
В отличие от словаря модель уже способна учитывать множество признаков текста.
Где ML особенно эффективен
На массовых повторяемых задачах.
Например:
категоризация миллионов звонков;
классификация тематик;
контроль типового чек‑листа;
определение результата обращения;
базовая Auto‑QA.
Именно поэтому классический ML никуда не исчез с появлением генеративного ИИ.
Naumen, например, прямо рекомендует комбинировать ML и LLM: массовые типовые проверки выполнять ML, а языковые модели использовать для задач, где необходимо глубокое понимание бизнес‑контекста.
Это важный архитектурный принцип.
LLM — не обязательная замена всему, что существовало раньше.
Уровень 3. Семантический анализ
Следующий шаг — переход от слова к смыслу.
Здесь аналитика должна найти не конкретную формулировку, а семантически похожие высказывания.
Например, мы задаем:
Клиент считает стоимость слишком высокой.
И хотим найти:
«Для меня это дорого».
«Не вижу смысла платить столько».
«У конкурента существенно дешевле».
«За такие деньги не готов».
В современных системах это может реализовываться через embeddings, специализированные NLP‑модели, LLM или комбинацию технологий.
Почему это существенно меняет работу аналитика
При словарном подходе аналитик сначала должен знать, что именно искать.
При семантическом подходе он задает бизнес‑смысл.
А при более продвинутом AI‑подходе система уже способна сама помочь обнаружить неизвестные заранее закономерности.
Например, Yandex SpeechSense развивает «дерево смыслов»: система кластеризует причины обращений и проблемы клиентов и может формировать иерархию тем вплоть до восьми уровней. Это позволяет искать не только заранее заданные признаки, но и «слепые зоны», о которых аналитик первоначально не знал.
Вот это уже принципиально другой сценарий использования речевой аналитики.
Уровень 4. LLM
Большие языковые модели значительно расширили класс задач.
Теперь системе можно задать вопрос практически естественным языком:
Выясни, почему клиент отказался.
Определи, понял ли менеджер настоящую потребность клиента.
Оцени качество аргументации.
Найди случаи, когда оператор формально выполнил скрипт, но фактически не решил проблему клиента.
Составь резюме разговора.
Выдели договоренности и следующий шаг.
Определи сильные и слабые стороны менеджера.
Это уже существенно ближе к работе живого аналитика.
Пример: проверяем отработку возражения
Представим диалог:
Клиент:
— Что‑то дороговато получается.
Менеджер:
— Понимаю. У нас в стоимость входит техническая поддержка и обучение сотрудников, поэтому после запуска дополнительных расходов не будет.
Словарь
Ищет:
«дорого» → найдено.
Но самостоятельно определить качество ответа менеджера не может.
ML
Может классифицировать:
возражение по цене → обработано.
Если соответствующая модель была обучена.
LLM
Можно попросить:
Оцени, понял ли менеджер возражение, привел ли аргумент и связал ли его с ценностью продукта.
И получить уже структурированный разбор.
Именно такая глубина является главным преимуществом LLM.
Но у LLM есть цена
Причем не только финансовая.
У языковой модели существуют как минимум четыре ограничения.
1. Вычислительная стоимость
Прогнать простой чек‑лист через LLM для нескольких миллионов звонков может быть значительно дороже, чем использовать правила или ML.
Поэтому гибридная архитектура зачастую экономически рациональнее.
2. Недетерминированность
Обычное правило:
обнаружено запрещенное слово → нарушение
дает однозначный результат.
Ответ LLM зависит от:
промпта;
контекста;
модели;
температуры;
версии модели;
длины разговора.
Для compliance‑задач это критично.
3. Необходимость проверки
Если языковая модель пишет:
клиент недоволен ценой,
нужно понимать, на основании какой части разговора сделан такой вывод.
Поэтому enterprise‑система должна позволять возвращаться к первичному диалогу.
4. Качество промпта
LLM не избавляет компанию от методологии.
Плохой вопрос дает плохой критерий.
Yandex Cloud прямо обучает пользователей SpeechSense работе с промптами для сложных смысловых Pro‑тегов.
Поэтому современные системы становятся гибридными
Наиболее интересный подход сегодня выглядит примерно так:
Задача | Рациональный инструмент |
|---|---|
Транскрипция | ASR |
Запрещенная фраза | Словарь |
Обязательная формулировка | Правило |
Тема обращения | ML |
Тип звонка | ML |
Сложная причина отказа | LLM / semantic AI |
Саммаризация | LLM |
Поиск скрытых проблем | LLM |
Соблюдение жесткого регламента | Rules + ML |
Оценка сложного сценария | Semantic AI / LLM |
Поиск неизвестных тематик | Clustering / LLM |
Это важнее, чем само наличие слова AI на лендинге.
Как разные платформы реализуют этот подход
Теперь посмотрим на несколько российских систем не по принципу «кто лучше», а именно по публично заявленной аналитической модели.
DEERAY: no‑code и сценарная семантика
DEERAY позиционирует продукт как настраиваемую платформу аналитики коммуникаций.
В системе сочетаются:
готовые речевые и акустические критерии;
словесные критерии;
сценарные критерии;
смысловой анализ;
тематизация;
саммаризация;
рекомендации;
пользовательские правила.
В актуальном исследовании платформы зафиксированы 50+ готовых критериев, при этом пользовательские критерии и скрипты можно создавать без ограничения их количества.
Это довольно важное отличие архитектурного подхода DEERAY (deeray.com).
Пользователь не просто получает заранее обученную модель вроде:
«продажа / не продажа».
Он может переносить в систему свою методологию контроля коммуникаций.
Например:
менеджер должен выявить потребность;
если клиент сомневается — определить тип сомнения;
для каждого типа возражения существует собственная ветка;
если менеджер вышел из сценария — проверить, был ли результат достигнут другим способом.
Именно здесь появляется интересный класс задач — графовые сценарии.
В исследовании рынка DEERAY отдельно выделяется возможность контролировать многоэтапные ветвящиеся сценарии, а не только линейный checklist.
Где подход особенно полезен
В крупных компаниях с:
собственной методикой продаж;
сложными регламентами;
большим количеством сценариев;
несколькими бизнес‑подразделениями.
Naumen CI: ML + LLM
У Naumen, пожалуй, один из наиболее понятно публично описанных гибридных подходов.
В одной платформе существуют:
ручная оценка → ML‑контроль → LLM‑анализ.
Naumen (naumen.ru) прямо отмечает, что использование LLM для каждого чек‑листа возможно технически, но может быть нерационально экономически.
Поэтому:
ML используется для массовых типовых задач,
а LLM — для:
неочевидных зависимостей;
сложного контекста;
инсайтов;
причин поведения;
глубокого анализа клиентского опыта.
В проекте ОТП Банка описан именно такой двухуровневый подход: ML выполняет массовую классификацию и автоматическую оценку, а LLM подключается для анализа сложного контекста и эмоций клиента.
Почему это интересно
Это практически классический пример экономического распределения вычислений.
Не нужно использовать дорогой инструмент там, где задачу уже надежно решает дешевый.
MWS AI WordPulse: правила + ML + LLM
WordPulse также прямо строится на комбинации трех уровней:
rules + ML + LLM.
Разработчик описывает использование:
собственных правил;
ML;
LLM;
семантического анализа;
анализа тональности;
ABSA;
произвольных промптов.
Особенно интересен ABSA — aspect‑based sentiment analysis.
Допустим, клиент говорит:
Интернет работает отлично, но цена тарифа стала слишком высокой.
Обычная оценка тональности может столкнуться с противоречием.
ABSA разделяет отношение к отдельным аспектам:
качество интернета → позитив
стоимость → негатив
Такой подход полезен для продуктовой и CX‑аналитики.
WordPulse (mws.ru) также позволяет использовать произвольные LLM‑промпты — например, для определения эмпатии или поиска скрытых смыслов в разговоре.
Yandex SpeechSense: от тегов к дереву смыслов
SpeechSense (aistudio.yandex.ru) хорошо показывает эволюцию аналитического интерфейса.
Там сосуществуют:
Словарные теги
Для точного поиска заданных выражений.
Смысловые теги
Пользователь описывает условие естественным языком:
клиент жаловался на доставку.
Система автоматически классифицирует диалоги по смыслу.
AI‑ассистенты
Используются для более сложного анализа:
оценка качества;
резюме;
рекомендации;
пользовательские вопросы к диалогу.
Дерево смыслов
Автоматически группирует большой массив коммуникаций и помогает обнаруживать ранее неизвестные категории проблем.
Получается своеобразная лестница:
BSS: каскадное промптирование
Интересный подход в 2026 году публично показала BSS (bssys.com).
В речевой аналитике появилась возможность строить каскады LLM‑промптов.
То есть вместо одного огромного запроса:
Проанализируй разговор и расскажи обо всем,
можно создать цепочку.
Например:
Шаг 1. Определи цель обращения.
Шаг 2. Если это продажа — определи потребность.
Шаг 3. Если было возражение — классифицируй его.
Шаг 4. Проверь действия оператора.
Шаг 5. Сформируй итоговую оценку.
Каждый следующий запрос использует результаты предыдущего.
BSS называет это каскадным промптированием и позиционирует подход как способ последовательно уточнять контекст и углублять анализ.
Для сложных бизнес‑сценариев такая архитектура логичнее попытки решить всю задачу одним prompt.
imot.io: LLM вокруг готового бизнес‑процесса
imot.io технологически находится в той же современной категории: распознавание, GPT‑аналитика, контроль скриптов, рекомендации, CRM.
Но важное отличие — способ упаковки технологии.
imot.io выглядит сильнее именно как вертикализированный Conversation / Revenue Intelligence продукт:
медицина;
недвижимость;
offline;
видео‑встречи;
специализированные CRM‑поля.
То есть здесь LLM‑анализ чаще продается не как конструктор:
«создайте любую методологию»,
а как готовый сценарий:
«вот как система анализирует конкретный процесс продаж».
Для определенных компаний это, наоборот, большое преимущество.
Rechka.AI: AI‑first подход для продаж
Rechka находится ближе к классу специализированных SaaS для анализа отдела продаж.
Акцент делается на:
анализ звонка;
контроль качества;
выполнение чек‑листа;
выявление ошибок;
рекомендации менеджеру.
То есть технологический стек максимально спрятан за бизнес‑сценарием:
загрузил звонок → получил AI‑разбор.
Это снижает порог входа, особенно для относительно небольших отделов продаж.
Но при выборе такого класса системы важно проверить, насколько глубоко компания сможет менять методологию, если стандартный анализ перестанет удовлетворять ее требованиям.
А где здесь Auto‑QA?
Auto‑QA — одна из основных причин внедрения речевой аналитики.
Классический отдел качества физически способен проверить, например:
1–3% звонков.
Речевая аналитика позволяет оценивать практически весь поток.
Но тут есть интересный нюанс.
Сам термин:
«проверяем 100% звонков»
не говорит, как именно эти звонки проверяются.
В одном продукте это может означать:
поиск пяти обязательных слов.
В другом:
40 параметров чек‑листа.
В третьем:
смысловую оценку сценария через LLM.
Поэтому при сравнении Auto‑QA нужно смотреть не на процент анализируемых коммуникаций, а на глубину критерия.
Пять поколений речевой аналитики
Если сильно упростить эволюцию, получится такая схема.
Поколение | Что анализируем |
|---|---|
1 | Слова |
2 | Правила и последовательности |
3 | Классы и паттерны |
4 | Смыслы и контекст |
5 | Причины, зависимости и неизвестные заранее инсайты |
Но переход на новый уровень не отменяет предыдущий.
Наоборот.
Хорошая современная архитектура выглядит скорее так:
словари + правила + ML + semantic AI + LLM.
Каждый инструмент используется там, где он наиболее эффективен.
Почему «у нас есть LLM» — плохой критерий выбора
В 2026 году почти любой поставщик может добавить LLM API.
Поэтому вопрос:
Есть ли в системе GPT/LLM?
практически потерял смысл.
Гораздо полезнее спросить другое.
Какие данные получает модель?
Весь разговор или только отдельные реплики?
Можно ли создавать собственные критерии?
Или доступны только готовые?
Как строятся сложные зависимости?
Можно ли создать условие:
если произошло A, но не произошло B, проверить C?
Можно ли проверить результат модели?
Показывается ли фрагмент разговора, на основании которого принято решение?
Можно ли сочетать LLM с точными правилами?
Это особенно важно для compliance.
Можно ли менять модель?
Особенно для On‑Premise.
Сколько стоит массовый анализ?
Цена тысячи тестовых диалогов и миллиона звонков — две совершенно разные экономики.
Как сравнивать качество систем
Здесь есть еще одна проблема рынка.
В рекламных материалах регулярно можно встретить:
«точность 95%»
или:
«самое точное распознавание».
Но без методики такая цифра почти ничего не означает.
Для ASR существует WER:
Word Error Rate.
Он показывает долю ошибок распознавания слов.
Можно использовать и другие показатели:
CER;
accuracy;
precision;
recall;
F1;
latency p50/p95/p99.
Но сравнение имеет смысл только если:
используется одинаковый набор аудио;
одинаковая разметка;
одинаковые условия;
единая методика расчета.
Практический тест: что дать системе на пилоте
Если компания выбирает речевую аналитику, я бы вообще не начинал с демо разработчика.
Лучше взять 100–500 собственных реальных коммуникаций.
Причем специально добавить сложные.
Тест 1. Простое правило
Найдите разговоры, где сотрудник не представился.
Тест 2. Синонимы
Найдите клиентов, которых не устраивает цена.
Тест 3. Смысл
Найдите клиентов, которые хотят отказаться от услуги, хотя прямо не говорят «отказаться».
Тест 4. Сценарий
Клиент возразил → менеджер выяснил причину → предложил аргумент → получил реакцию.
Тест 5. Неизвестная проблема
Какие причины отказов встречаются в этих разговорах?
Без заранее заданных категорий.
Тест 6. Ошибка сотрудника
Что менеджеры систематически делают хуже всего?
Вот здесь разница между технологиями становится хорошо видна.
Какая архитектура подходит для какой задачи
Только compliance
Подойдут жесткие правила + словари.
LLM зачастую избыточна.
Массовая классификация
ML.
Глубокая оценка продаж
ML + semantic AI + LLM.
Voice of Customer
Semantic analysis + clustering + LLM.
Сложные корпоративные методики
No‑code + rules + scenario engine + LLM.
Миллионы коммуникаций
Гибрид.
Использовать LLM буквально для каждой элементарной проверки необязательно.
Как выглядят платформы по технологическому подходу
Не как рейтинг, а именно как ориентир.
Платформа | Наиболее заметный публичный подход |
|---|---|
DEERAY | No‑code, семантика, пользовательские критерии, графовые сценарии, LLM |
Naumen CI | Гибрид ML + LLM + manual QA |
MWS AI WordPulse | Rules + ML + LLM + ABSA |
Yandex SpeechSense | Словарные/смысловые теги + LLM + дерево смыслов |
BSS | AI/LLM + каскадные промпты + enterprise QA |
imot.io | GPT/AI + готовые вертикальные workflows |
Rechka.AI | AI‑first анализ отдела продаж |
ЦРТ | Собственный speech‑stack + enterprise speech analytics |
Важно: эта таблица не оценивает качество моделей. Она показывает, какие технологические особенности сами разработчики наиболее явно выносят в публичный продукт.
Что в итоге выбрать
Пожалуй, главное изменение последних двух‑трех лет заключается не в том, что в речевой аналитике появилась LLM.
Главное — сменился уровень вопросов, которые бизнес может задавать данным.
Раньше:
Сколько клиентов сказали слово «дорого»?
Сегодня:
Почему клиенты считают продукт слишком дорогим?
Следующий уровень:
Какие характеристики продукта чаще всего приводят к ощущению завышенной стоимости и у каких сегментов клиентов?
Это уже не просто контроль операторов.
Это источник данных для:
маркетинга;
продаж;
CX;
продуктовой команды;
обучения;
управления процессами.
Поэтому современную речевую аналитику правильнее оценивать не по количеству красивых AI‑функций.
А по тому, насколько глубоко система способна превратить неструктурированный разговор в проверяемое бизнес‑знание.
И здесь разные продукты решают разные задачи.
Если нужен прежде всего готовый инструмент для отдела продаж — можно смотреть специализированные SaaS вроде Rechka или imot.io.
Если требуется технологический конструктор — интересен SpeechSense.
Для крупных организаций с собственными процессами стоит сравнивать platform‑oriented решения вроде DEERAY, Naumen, BSS, WordPulse и ЦРТ.
А при выборе между ними уже имеет смысл проверять не маркетинговое наличие «AI/LLM», а:
архитектуру → управляемость → масштаб → стоимость вычислений → интеграцию в реальные бизнес‑процессы.
keyword → semantic tag → LLM → unsupervised discovery.
