Красная команда для диалогового ИИ

Коротко для руководителя. Когда диалогового ИИ-агента тестирует та же команда, что его написала, она проверяет не агента, а собственные ожидания — и почти всегда получает зелёный результат. Чтобы узнать настоящую надёжность, нужен независимый контур, заинтересованный не подтвердить, а сломать: красная команда. В безопасности это давно норма — никто не доверяет аудит самому разработчику. Для разговорного ИИ это пока редкость, и именно поэтому большинство ассистентов уверенно проходят демо и проваливаются на живых клиентах. Красная команда переносит цену этой проверки на этап до запуска, а не на убыток после.

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

Гипотеза: своего агента нельзя протестировать честно — нужен независимый оппонент

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

Чтобы измерить настоящую надёжность, нужен противоположный по мотивации контур. Не тот, кто хочет, чтобы агент прошёл, а тот, кому платят за то, чтобы агент НЕ прошёл. Его задача — запутать систему, увести её в сторону, поймать на противоречии, заставить выдать неверное или опасное. Это и есть красная команда, перенесённая из безопасности на разговорный ИИ. И на современном этапе её всё чаще собирают не из людей, а из второго агента: «AI red team» — уже не метафора, а инженерная дисциплина.

Проблема: разработчик тестирует свои ожидания, а не агента

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

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

Второе — порядок. Разработчик ведёт диалог линейно: вопрос, ответ, уточнение. Живой человек прыгает: начинает про одно, вспоминает про другое, возвращается к первому через десять реплик. Тест по «правильному» порядку никогда не дойдёт до того места, где агент теряет нить.

Третье — отсутствие сопротивления. Автор не спорит со своим агентом, не врёт ему, не меняет внезапно вводные. А реальный пользователь делает всё это постоянно — не со зла, а потому что человеческий диалог хаотичен по своей природе. И когда среда разработки ещё и подыгрывает — исправляет опечатки, выбирает наиболее вероятную интерпретацию, упрощает ввод — зелёный отчёт становится почти гарантирован. Он растёт, а реальная устойчивость стоит на месте.

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

Почему обычные подходы не работают

Естественная реакция команды на сомнение в качестве — написать больше тестов. Это не помогает, и важно понять почему.

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

Второй типовой ход — нанять QA-человека и посадить ручное тестирование. Лучше, но упирается в две стены. Стена объёма: человек проверит десятки диалогов, а нужны тысячи, чтобы поймать редкие, но дорогие сбои. Стена недетерминизма: один и тот же диалог у LLM каждый раз идёт чуть иначе, поэтому единичный прогон ничего не доказывает — нужна статистика по многим повторам одного и того же давления, а не галочка «проверили».

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

Покажу на обезличенном примере. У крупного travel-ритейлера под NDA был ассистент подбора, который на внутренних тестах закрывал больше девяноста процентов сценариев. Тесты писала команда, и каждый шёл по чистой ветке: клиент называет направление, даты, бюджет — агент подбирает. Когда мы натравили на него настоящую красную команду — атакующего агента с моделями трудного поведения и корпусом реальных диалогов, — картина изменилась за первый же вечер. Клиент, который трижды менял даты в одном диалоге, ломал агенту контекст. Клиент, который называл нереальный бюджет, а потом обижался на отсутствие вариантов, уводил агента в извинения вместо подбора. Клиент, который посреди разговора про каюту вдруг спрашивал про визы, заставлял агента терять исходную задачу. Ни один из этих провалов не был виден на «правильных» тестах — потому что ни один разработчик так с собственным агентом не разговаривает. Красное нашлось ровно там, куда зелёный контур не заглядывал.

Инженерная модель: агент-оппонент, которому платят за провал

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

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

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

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

И последнее, без чего весь контур теряет смысл: источник сценариев. Не синтетика из головы разработчика, а корпус реальных диалогов — настоящие чаты, звонки, обращения в поддержку. Люди ломают агента не так, как воображает инженер, и единственный способ узнать как — взять тестовый материал из живых разговоров, а не выдумать его.

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

Практический вывод для бизнеса

Главный управленческий вывод один: не доверяйте оценку надёжности агента тем, кто его построил. Это не вопрос доверия к людям — это вопрос структуры. Автор объективно не может проверить своё творение, как бы ни старался.

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

Что завести. Независимое тестирование диалогового агента — это отдельная функция, ровно как security review, а не доработка силами авторов. На старте достаточно одного атакующего агента с библиотекой трудных ролей, судьи на исход и корпуса ваших реальных диалогов. Это дёшево относительно цены агента, который уверенно сказал клиенту не то и стоил вам сделки или репутации. Если строить такой контур не на чем — это и есть задача на разработку ИИ-агентов, а не на «докрутить промпт».

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

Открытые вопросы

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

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

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

Если у вас уже есть диалоговый ИИ-агент, но его «проверяла» та же команда, что писала, — настоящей оценки надёжности у вас пока нет. Обсудить задачу → — соберём красную команду и покажем, какие атаки ваш агент пока не проходит.