Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Голосового агента научили переносить обязательный порядок разговора на процедуры, которых не было в обучении. В работе ARAC локальная модель после дообучения почти сравнялась с более крупной, хотя препринт не рецензирован, а числа получили сами авторы. Для продукта это предлагает средний путь между свободной LLM и отдельным жёстким сценарием для каждого клиента.
Один документ управляет разговором, инструментами и проверками
В регулируемом разговоре недостаточно решить задачу клиента. Агент должен сначала подтвердить личность собеседника, затем назвать себя и кредитора, сообщить сумму долга в установленном порядке и не раскрыть сведения постороннему человеку. Правильная фраза, сказанная слишком рано, уже нарушает процедуру.
Авторы описывают каждое внедрение в FlowSpec — машиночитаемом документе с состояниями диалога, переходами, доступными инструментами и ограничениями. Из него система собирает инструкцию для модели, разрешает или блокирует вызовы инструментов, строит эталонные разговоры для обучения и формирует проверки.
Это отличается от обычной схемы, где регламент, программная логика, обучающие примеры и тесты поддерживают отдельно. Если клиент меняет порядок раскрытия сведений или название инструмента, команда правит одну спецификацию, а не синхронизирует несколько реализаций вручную.
Модель не сочиняет ответы. Она выбирает действие и одну или несколько реплик из утверждённого каталога, после чего среда подставляет нужные данные. Такой подход не гарантирует правильный момент для фразы, зато исключает произвольный текст и позволяет заранее проверить весь набор того, что агент способен произнести.
Для обучения использовали разговоры, построенные по 297 случайно изменённым процедурам. В них переставляли этапы, переименовывали инструменты и идентификаторы, меняли ограничения и правила завершения звонка. Поэтому модель должна была научиться читать текущую процедуру, а не запоминать один поток.
Обучение помогло соблюдать документ, а не понимать клиента
Авторы разделили проверки на два класса. В первом правильное действие задаёт процедура: какие инструменты вызвать, в каком порядке раскрыть сведения и как записать результат звонка. Во втором ответ определяется самим разговором: например, совпадает ли переданное инструменту имя с тем, что произнёс собеседник.
У модели с 9 млрд параметров доля пройденных проверок первого класса выросла с 67–71% до 93–100%. Значит, основной эффект пришёлся именно на чтение и исполнение нового регламента. Проверки, связанные с содержанием разговора, и до обучения проходили почти без ошибок.
На уровне целых сценариев результат поднялся с 15 из 43 до 40 из 43. Более крупная модель без такого обучения справлялась заметно лучше исходной компактной, но не помещалась на предусмотренном для внедрения оборудовании. Дообучение не создало способность с нуля, а перенесло её в модель, которую можно запускать локально в голосовом конвейере.
Спецификация сокращает число реализаций, но становится критической частью продукта
Работа меняет планы команды, если ей предстоит поддерживать несколько клиентов с похожими законами, но разными внутренними процедурами. Вместо отдельной управляющей модели или вручную написанного автомата для каждого внедрения можно проектировать общий исполнитель, а различия хранить как данные.
Для этого регламент придётся формализовать глубже, чем для обычной инструкции в подсказке модели. Состояния, допустимые переходы, обязательные действия и условия доступа к инструментам должны быть однозначными. Ограничения, оставленные обычным текстом, модель может понять, но среда не сможет надёжно проверить или принудительно исполнить.
Сильная сторона FlowSpec одновременно создаёт главный риск: обучение и тесты зависят от одного источника. Аудит нашёл 11 дефектов спецификации, причём 3 не обнаружила сформированная из неё метрика. В одном случае ошибка добавила в обучающие данные эпизоды, где баланс раскрывался до проверки личности; такие эпизоды составляли около 1% соответствующей генерации.
Поэтому высокий результат означает соответствие формализованной процедуре, а не автоматическое соответствие закону. Для промышленной системы нужны две независимые проверки: правильно ли модель исполняет FlowSpec и правильно ли сам FlowSpec передаёт юридические и операционные требования. Вторую проверку нельзя строить только из того же документа.
Границы эксперимента также узкие: перенос проверяли на четырёх процедурах для тайского исходящего агента, включая полностью отложенную ветку шаблонов. Разговоры проходили в виде текста с имитированным собеседником, поэтому работа не показывает, как итог изменят ошибки распознавания речи, реальные звонящие или последующие правки уже знакомой процедуры.
Практический вывод — не заменять существующий голосовой продукт целиком, а отделить утверждённые реплики и принудительные ограничения от модели, которая выбирает следующий шаг. FlowSpec показывает рабочую форму такого разделения. Но перед внедрением команде потребуется независимый аудит спецификации и тесты на собственных процедурах, речевом канале и инфраструктуре.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
