инженерные заметки
Почему LLM плохо играют роль клиента
Симуляторы клиента на LLM ведут себя слишком разумно и помогают агенту вместо того чтобы его ломать. Почему для честного тестирования ИИ-агентов нужны модели трудного поведения.
Коротко для руководителя. Идея «пусть один ИИ играет клиента, а другой — нашего агента, и так мы его проверим» звучит логично, но почти не работает. Языковые модели обучены быть полезными, поэтому в роли клиента они через пару реплик начинают помогать агенту: отвечают по существу, не сбиваются, не вредничают. В итоге проверка выходит тепличной, а реальный клиент ломает агента на первой же странности. Чтобы тест был честным, симулятору нужно задавать конкретные модели трудного поведения. Библиотека «трудных людей» — такой же инженерный актив, как код агента.
Когда команда строит автоматическую проверку диалогового агента, у неё возникает естественная мысль: посадить напротив агента второй ИИ, который изобразит клиента. Один агент продаёт, другой притворяется покупателем, диалог идёт сам, тесты масштабируются. Идея красивая — и на ней спотыкаются почти все, потому что языковая модель в роли клиента ведёт себя совсем не как клиент.
LLM обучена быть полезной — поэтому в роли клиента она помогает агенту, а не мешает ему.
Гипотеза: симулятор клиента на LLM по своей природе слишком разумен
Языковые модели прошли обучение на полезность: отвечать по делу, быть последовательными, доводить разговор до результата. Это ровно те качества, которые делают плохого тестового клиента. Попросите модель «сыграть раздражённого покупателя» — и она раздражается одну-две реплики, а потом сваливается в кооперацию: начинает чётко формулировать запрос, отвечает на уточняющие вопросы, помогает агенту прийти к решению. Она не выдерживает роль, потому что роль противоречит тому, как её настроили.
Отсюда гипотеза: наивный симулятор клиента не проверяет агента, а подыгрывает ему. Он создаёт диалог, который выглядит как тест, но по трудности ближе к идеальному сценарию из презентации, чем к реальному разговору. Это прямое продолжение того, почему синтетические диалоги слабее реальных: сгенерированный клиент гладкий и удобный там, где живой — шершавый и непредсказуемый.
Проблема: тепличный симулятор даёт ложную зелёную картину
Опасность не в том, что симулятор плохой, а в том, что он плохой незаметно. Диалогов много, они разнообразны на вид, метрика проходимости высокая — и всё это создаёт ощущение серьёзной проверки. На деле агента гоняли против оппонента, который ему помогал. Зелёный отчёт растёт, а реальная устойчивость стоит на месте.
Дальше срабатывает знакомый механизм: менеджмент видит «агент прошёл тысячи автоматических диалогов» и читает это как готовность. Но тысячи кооперативных диалогов не стоят одного диалога с клиентом, который путается, злится и трижды меняет запрос. Агент уходит в прод, и первый же по-настоящему трудный человек находит то, что симулятор обошёл стороной. Это всё тот же перекос в сторону зелёного, только теперь его источник — не среда разработки, а сам тестировщик-ИИ, который не умеет быть трудным.
Почему обычные подходы не работают
Первый рефлекс — «попросим модель играть пожёстче» — даёт короткий эффект и сходит на нет. Одной общей инструкции «будь сложным клиентом» модели хватает на пару реплик; дальше тяга к полезности перевешивает, и она снова скатывается в кооперацию. Трудность нельзя задать прилагательным — она слишком расплывчата, чтобы удержать роль.
Второй подход — «возьмём модель помощнее, она сыграет лучше» — бьёт мимо. Более сильная модель ещё более полезна и последовательна, то есть ещё хуже как трудный клиент. Проблема не в способностях модели, а в направлении, в которое её настроили: помогать, а не вредить. Рост способностей усиливает именно кооперативность.
Третий подход — «зададим случайность, пусть ведёт себя хаотично» — путает шум с трудностью. Случайные реплики делают диалог бессвязным, но не воспроизводят конкретные способы, которыми реальные люди ломают агента: не абстрактный хаос, а тревога, конфликт, забывчивость, подозрительность. Корень у всех трёх подходов один: мы пытаемся получить трудного клиента, не описав, в чём именно состоит трудность.
Инженерная модель: библиотека моделей трудного поведения
Решение — перестать просить модель «быть сложной вообще» и начать задавать ей конкретные, узкие модели поведения. Не «трудный клиент», а набор персонажей, каждый из которых ломает агента своим способом. Практически это библиотека, и она важнее самой модели-симулятора.
Тревожный требует повторных подтверждений, переспрашивает одно и то же, не доверяет первому ответу — проверяет, умеет ли агент успокаивать, не теряя нить. Конфликтный спорит, придирается, провоцирует — проверяет, держит ли агент линию, не скатываясь ни в оправдания, ни в грубость. Забывчивый теряет контекст, противоречит сам себе, путает свои же данные — проверяет, удерживает ли агент состояние диалога за клиента. Подозрительный ищет подвох, отказывается давать данные, сомневается в каждом предложении — проверяет, умеет ли агент строить доверие. Импульсивный меняет решение на ходу, перескакивает, торопит — проверяет устойчивость цели. Скучающий отвечает односложно, не вовлекается, в любой момент готов уйти — проверяет, умеет ли агент удерживать внимание. Каждая модель — это не прилагательное, а заданное поведение: что персонаж делает, чего избегает, как реагирует на попытки агента довести диалог до конца.
Трудность нельзя задать прилагательным «сложный» — её задают конкретной моделью поведения: тревожный, конфликтный, забывчивый, подозрительный.
Такая библиотека встраивается в контур, где тестировщик — не человек, а другой агент: симулятор берёт одну из моделей трудного поведения, ведёт диалог с целью затруднить достижение цели, а отдельный судья оценивает исход — дошёл ли клиент до результата. Сценарии при этом берутся не из воображения, а из корпуса реальных диалогов: по живым перепискам видно, какие именно типы трудных людей встречаются в вашей аудитории и в какой пропорции. Библиотека не выдумывается за один присест — она растёт: каждый новый способ, которым реальный клиент сломал агента, становится новой моделью поведения. Со временем это превращается в актив — описание того, как именно ваши клиенты бывают трудны, переиспользуемое для каждой новой версии агента. Этот подход — частный случай красной команды для диалоговых систем: независимого контура, чья работа — не помогать агенту, а доказать, что он не работает.
Практический вывод для бизнеса
Не верьте «агент прошёл тысячи диалогов с ИИ-клиентом» как доказательству. Спросите, какие модели трудного поведения использовались и откуда они взяты. Если симулятору просто сказали «будь клиентом», агента проверяли против помощника, а не против клиента, — и эта проверка ничего не говорит о проде.
Что поручить. Библиотека моделей трудного поведения — отдельный артефакт, который стоит вести наравне с тестами. На старте достаточно нескольких чётко описанных персонажей, собранных по вашим реальным диалогам; даже небольшой набор, заданный поведением, ловит куда больше, чем «универсальный сложный клиент». Где это важно вдвойне: там, где агент работает с эмоционально нагруженными ситуациями — продажи, возвраты, поддержка по проблеме, — потому что именно там тревога, конфликт и подозрительность встречаются чаще всего.
Чего не делать. Не стройте проверку на одном наивном симуляторе клиента — он будет помогать агенту. Не наращивайте мощность модели вместо описания поведения: сильная модель играет трудного клиента хуже, а не лучше. И не путайте случайность с трудностью — хаотичные реплики не воспроизводят конкретные способы, которыми ломаются ваши агенты.
Собрать библиотеку трудных клиентов под вашу аудиторию — .
Открытые вопросы
Сколько моделей поведения достаточно — зависит от того, насколько разнообразна и эмоционально нагружена ваша аудитория; ориентир — покрыть реально встречающиеся типы, а не собрать коллекцию. Насколько глубоко модель вообще способна удержать трудную роль — открытый вопрос: даже с чётким описанием поведения LLM тянет к кооперации, и за этим нужно следить через судью и метрику исходов. И где граница между «агента честно проверили на трудном клиенте» и «агента загнали в нереалистично враждебный диалог» — её задаёт пропорция типов из реального корпуса, а не максимальная жёсткость ради жёсткости. Шире эта тема — про границы того, что ИИ знает о пользователе, и про структурные проблемы мультиагентных систем.
Если вашего ИИ-агента проверял один «универсальный» ИИ-клиент, его почти наверняка проверяли слишком мягко. — соберём библиотеку трудных клиентов под вашу аудиторию и посмотрим, на ком агент ломается. Близкие задачи — в наших кейсах и на странице корпоративных чат-ботов.