LLM отвечает, код решает: зачем голосовому боту отдельный классификатор

Редакция APICODIK · 01.11.2026

Как Jev-подобные модели помогают разделить разговор, маршрутизацию и выполнение действий в голосовом боте — и почему дополнительный классификатор не заменяет бизнес-правила.

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

В статье на Хабре Владимир Самуков, Head of Product в Voximplant, рассматривает архитектуру, в которой часть решений выносится из разговорной LLM в специализированный классификатор. Один из разобранных примеров — Jev от TypeSafe. Главная идея материала не в замене одной модели другой, а в разделении ответственности: речевая модель ведёт диалог, классификатор оценивает ситуацию, а программная логика определяет допустимое действие.

Почему хороший ответ ещё не означает правильное действие

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

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

Поэтому вопрос архитектуры звучит иначе: какие решения действительно требуют генеративной модели, а какие можно представить как ограниченный выбор?

Что делает классификатор

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

Это позволяет задавать узкие задачи: определить тему обращения, проверить подтверждение действия, оценить завершённость реплики. Дальше результат обрабатывает код.

Такой интерфейс не следует путать с гарантией правильности. Ограниченный набор ответов упрощает использование результата, но классификатор всё равно может неверно оценить сказанное. В статье отдельно подчёркивается, что пороги уверенности необходимо подбирать под конкретный сценарий.

Три места, где разделение особенно полезно

Маршрутизация разговора

Если один номер обслуживает запись, отмену визита, вопросы о заказах и обращения к оператору, необязательно помещать все инструкции в один промпт. Классификатор может определять тему и передавать разговор специализированному агенту с собственным набором инструментов.

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

Проверка перед изменением данных

Наиболее важная граница проходит между предложением LLM вызвать инструмент и фактическим выполнением операции. В разобранном в статье кейсе телефонного ассистента Pocos промежуточный классификатор проверяет выводы речевой модели до того, как они повлияют на систему или диалог.

Например, он оценивает, подтвердил ли человек действие и не отменяет ли последняя реплика предыдущую договорённость. Затем бизнес-логика сопоставляет результат со своими правилами.

Для разработчика это означает явное разделение двух событий: модель предложила перенести запись — система получила достаточно оснований для переноса. Если оценки расходятся, действие можно не выполнять и перейти к уточнению. Сам классификатор здесь не становится владельцем бизнес-процесса.

Управление очередностью речи

Тишина не всегда означает, что человек закончил говорить. После короткого согласия бот может отвечать, а после незавершённого объяснения ему стоит подождать. Одинаковая по длительности пауза требует разных решений в зависимости от смысла.

Источник описывает сочетание акустического определения конца хода с анализом расшифровки. Аудиоконтур обнаруживает паузу, а классификатор оценивает, завершена ли мысль. Для этого полезен контекст предыдущего вопроса бота.

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

Экономия требует отдельной политики

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

Но простота формулировки и низкая цена ошибки — разные вещи. Короткий запрос тоже может требовать осторожности. Поэтому источник предлагает повышать класс модели при низкой уверенности и не отправлять рискованные задачи на дешёвый маршрут только потому, что они выглядят простыми.

Это не автоматическая экономия от появления ещё одной модели. Это политика распределения нагрузки, в которой нужно заранее определить условия переключения.

С чего начинать внедрение

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

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

Jev-подобная модель в этой архитектуре — не ещё один собеседник. Это компонент управления. Смысл подхода в том, чтобы оставить LLM свободу формулировать ответы, но не связывать с этой свободой безусловное право менять данные и управлять всем звонком.