Как голосовой ИИ-агент врал клиентам, путал звонящих и подделывал собственный голос — и как это чинится

[brutto]

А когда перешли на не последовательную обработку с учётом описанных вами ограничений сколько получилось секунд на ответ?

[Mefodiytr]

Сейчас как раз это докручиваю, поэтому точные цифры дам позже. Концептуально главное: важна не секунда на весь ход, а время до первого звука — STT идёт по ходу речи, TTS начинает озвучку первого предложения, пока модель пишет дальше, так что пауза перед ответом заметно короче. Целюсь в ~2–2,5 с.

[aleksandrartemov]

У меня есть такой же проект, столько боли, а клиентов пару полуживых инвалида. Доверие прям вооьще никакое к этому ии... Могу поделится своим проектом.. callops только российская платформа, найдите меня там по профилям, буду рад каким то хоть клиентам

[stranger82]

У меня в проверке и оптимизации голосовых интерфейсов хорошо работал подход разделения проблем со звуком (turn detection, interruptions) и проблем с содержанием. Проблемы со звуком нормально можно проверить и вычистить вручную. Для содержания хорошо показало моделирование ситуаций и за юзера отвечает ллм. Моделирование дает транскрипт, ллм критик проверяет транскрипт и дает фидбэк, другой агент меняет промпт и перезапускает. Но все это работает настолько хорошо, насколько хороши промпты моделирования, оценки и изменений. И тут получается подмена задачи оптимизации исходного процесса задачей оптимизации процесса, который оптимизирует. Но вторая задача оказывается все же проще, поэтому оно того стоит.

[Mefodiytr]

В точку — у меня то же разделение, и оно оказалось главным рычагом. Звук (turn detection, перебивания, эхо) чищу вручную, ухом, за пару заходов. А содержание — рекурсия, как вы и описали: LLM за юзера → транскрипт → критик → правка промпта → перезапуск. И да, оптимизация исходного процесса подменяется оптимизацией оптимизатора — черепахи до низа. Спасает только то, что нижняя задача проще, поэтому оправдано. По сути мой тезис из статьи на уровень выше: надёжность не в одном идеальном промпте, а в структуре — теперь уже вокруг самого цикла улучшения.

А критик и правщик промптов у вас — одна модель в разных ролях или разные? И проверяете ли самогшо критика? Подозреваю, вся петля держится на его честности: начнёт подыгрывать — тихо деградирует. Как с этим боретесь?

[stranger82]

1. Я не заметил глобальной разницы в том, разные это модели или одинаковые, главное, чтобы они не шарили контекст между собой.

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

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

А вы пробовали использовать Alice AI LLM как замену YandexGPT для уменьшения задержки?