Поиск слова «дорого» в транскрипте звонка когда-то считался речевой аналитикой

Поиск слова «дорого» в транскрипте звонка когда-то считался речевой аналитикой. Сегодня бизнес хочет ответить на другой вопрос: почему клиент не купил, даже если ни разу прямо не сказал, что его не устраивает цена? Это две принципиально разные задачи. В первом случае достаточно распознать речь и проверить текст по словарю. Во втором системе нужно учитывать контекст, последовательность реплик, намерение клиента и весь сценарий разговора.

Именно поэтому под названием «речевая аналитика» в 2026 году продаются технологически очень разные продукты. Одни по-прежнему работают на правилах и словарях. Другие добавляют машинное обучение. Третьи используют LLM. А наиболее сложные платформы комбинируют несколько подходов одновременно.

Упрощенно pipeline современной системы выглядит так: аудио ? ASR ? транскрипт ? структурирование ? анализ ? бизнес-правило ? действие. Между «получили текст» и «поняли, что произошло» располагается несколько технологических слоев.

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

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

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

Следующим этапом стали модели машинного обучения. Вместо ручного перечисления всех фраз система обучается определять класс. Модель способна учитывать множество признаков текста. Классический ML никуда не исчез с появлением генеративного ИИ. Naumen, например, рекомендует комбинировать ML и LLM: массовые типовые проверки выполнять ML, а языковые модели использовать для задач, где необходимо глубокое понимание бизнес-контекста. Это важный архитектурный принцип: LLM — не обязательная замена всему, что существовало раньше.

Следующий шаг — переход от слова к смыслу. Здесь аналитика должна найти не конкретную формулировку, а семантически похожие высказывания: «Клиент считает стоимость слишком высокой», «Не вижу смысла платить столько», «У конкурента существенно дешевле». В современных системах это реализуется через embeddings, специализированные NLP-модели, LLM или комбинацию технологий. При словарном подходе аналитик должен знать, что именно искать. При семантическом — он задает бизнес-смысл. А при более продвинутом AI-подходе система способна сама помочь обнаружить неизвестные заранее закономерности. Yandex SpeechSense развивает «дерево смыслов»: система кластеризует причины обращений и проблемы клиентов, формирует иерархию тем вплоть до восьми уровней. Это позволяет искать не только заданные признаки, но и «слепые зоны», о которых аналитик не знал.

Большие языковые модели значительно расширили класс задач. Системе можно задать вопрос естественным языком: «Выясни, почему клиент отказался», «Определи, понял ли менеджер настоящую потребность», «Найди случаи, когда оператор формально выполнил скрипт, но фактически не решил проблему», «Выдели договоренности и следующий шаг», «Определи сильные и слабые стороны менеджера». Это уже ближе к работе живого аналитика.

Например, клиент говорит: «Что-то дороговато получается». Менеджер отвечает: «Понимаю. У нас в стоимость входит техническая поддержка и обучение сотрудников, поэтому после запуска дополнительных расходов не будет». Словарь может отметить возражение по цене и наличие ответа. Но самостоятельно определить качество ответа менеджера он не может. LLM способен оценить, понял ли менеджер возражение, привел ли аргумент и связал ли его с ценностью продукта, и выдать структурированный разбор. Именно такая глубина — главное преимущество LLM.

Но у языковой модели есть как минимум четыре ограничения. Первое — стоимость. Прогнать простой чек-лист через LLM для нескольких миллионов звонков может быть значительно дороже, чем использовать правила или ML. Поэтому гибридная архитектура экономически рациональнее. Второе — воспроизводимость. Для compliance-задач критично, чтобы одно и то же правило давало стабильный результат, а LLM может быть вариативен. Третье — объяснимость. Нужно понимать, на основании какой части разговора сделан вывод, поэтому enterprise-система должна позволять возвращаться к первичному диалогу. Четвертое — методология. LLM не избавляет компанию от методологии: плохой вопрос дает плохой критерий. Yandex Cloud прямо обучает пользователей SpeechSense работе с промптами для сложных смысловых Pro-тегов.

Наиболее интересный подход сегодня — гибридный: соблюдение жесткого регламента проверяется правилами, массовые типовые задачи — ML, а глубокий смысловой анализ — LLM. Это важнее, чем само наличие слова AI на лендинге.

Посмотрим на несколько российских систем по публично заявленной аналитической модели.

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

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

WordPulse строится на комбинации трех уровней. Особенно интересен ABSA — aspect-based sentiment analysis. Например, фраза «Интернет работает отлично, но цена тарифа стала слишком высокой» содержит противоречие для обычной оценки тональности. ABSA разделяет отношение к отдельным аспектам: к качеству интернета — положительное, к цене — отрицательное. Это полезно для продуктовой и CX-аналитики. WordPulse также позволяет использовать произвольные LLM-промпты — например, для определения эмпатии или поиска скрытых смыслов.

SpeechSense хорошо показывает эволюцию аналитического интерфейса. Теги для точного поиска заданных выражений, смысловые теги для автоматической классификации диалогов по смыслу, Pro-теги для более сложного анализа через пользовательские вопросы к диалогу. Дерево смыслов автоматически группирует большой массив коммуникаций и помогает обнаруживать ранее неизвестные категории проблем. Получается лестница: от точного поиска к смысловым категориям и к открытию новых закономерностей.

BSS в 2026 году публично показала каскады LLM-промптов. Вместо одного огромного запроса «Проанализируй разговор и расскажи обо всем» строится последовательность: шаг 1 — определи цель обращения, шаг 2 — если это продажа, определи потребность, шаг 3 — если было возражение, классифицируй его, шаг 4 — проверь действия оператора, шаг 5 — сформируй итоговую оценку. Каждый следующий запрос использует результаты предыдущего. BSS называет это каскадным промптированием и позиционирует как способ последовательно уточнять контекст и углублять анализ. Для сложных бизнес-сценариев такая архитектура логичнее попытки решить всю задачу одним prompt.

imot.io технологически находится в той же современной категории: распознавание, GPT-аналитика, контроль скриптов, рекомендации, CRM. Но важное отличие — способ упаковки технологии. imot.io выглядит сильнее как вертикализированный Conversation / Revenue Intelligence продукт. LLM-анализ здесь чаще продается не как конструктор, а как готовый сценарий: «вот как система анализирует конкретный процесс продаж». Для определенных компаний это большое преимущество.

Rechka находится ближе к классу специализированных SaaS для анализа отдела продаж. Технологический стек максимально спрятан за бизнес-сценарием: загрузил звонок ? получил AI-разбор. Это снижает порог входа для небольших отделов продаж. Но при выборе такого класса системы важно проверить, насколько глубоко компания сможет менять методологию, если стандартный анализ перестанет удовлетворять ее требованиям.

Auto-QA — одна из основных причин внедрения речевой аналитики. Классический отдел качества физически способен проверить небольшой процент звонков, а речевая аналитика позволяет оценивать практически весь поток. Но когда поставщик заявляет «мы анализируем 100% звонков», важно понять, что именно проверяется. В одном продукте это может означать поиск запрещенных слов, в другом — контроль наличия фраз, в третьем — смысловую оценку сценария через LLM. При сравнении Auto-QA нужно смотреть не на процент анализируемых коммуникаций, а на глубину критерия.

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

В 2026 году почти любой поставщик может добавить LLM API. Гораздо полезнее спросить другое: как система структурирует диалог? Анализирует ли она весь разговор или только отдельные реплики? Умеет ли проверять ветвящиеся сценарии: если произошло A, но не произошло B, проверить C? Какова стоимость анализа на масштабе миллионов звонков? И главное — можете ли вы перенести в систему свою методологию контроля, а не подстраиваться под встроенную модель?

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: