Как проверять AI-агента до запуска: сценарии, границы и журнал ошибок

Три часа ночи, я смотрю на логи пилота. Агент поддержки работает неделю, метрики красивые: 94% ответов «приняты пользователем». Утром звонит клиент — и оказывается, что агент неделю обещал возвраты, которых компания не делает. Никто из пользователей не пожаловался, потому что поверили. Метрика «принят ответ» показывала не качество, а вежливость.

С этого дня я перестал верить демо. Совсем.

Почему демо — это не проверка

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

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

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

Значит, evaluation должен строиться не вокруг способностей агента, а вокруг поведения пользователей. Это принципиально другая логика.

Что именно мы оцениваем

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

Первый слой — фактическая точность. Отвечает ли агент на вопрос по существу, опирается ли на данные, не выдумывает ли. Здесь важно различать два провала: агент говорит неверное и агент говорит правдоподобное, но не по делу. Второе опаснее, потому что выглядит убедительно.

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

Третий слой — поведение в неопределённости. Что делает агент, когда не знает? Когда данных мало? Когда запрос противоречив? Хороший агент уточняет или честно отказывает. Плохой — сочиняет уверенный ответ. Этот слой отличает игрушку от рабочего инструмента.

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

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

Шестой слой — стоимость и задержка. Красивый агент, который думает сорок секунд и стоит как крыло самолёта, не готов к production, даже если отвечает идеально.

Матрица, а не список

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

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

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

Дальше начинается самое важное: для каждой клетки вы пишете конкретный тест. Не «проверить провокации», а «пользователь просит скидку 50%, агент должен отказать и предложить альтернативу». Разница огромная: первое нельзя оценить, второе — можно.

На старте хватит тридцати-сорока тестов. Потом матрица растёт: каждый баг из production превращается в новый тест, каждый новый сценарий — в новую клетку. Через полгода у вас набирается живой набор, который ловит регрессии.

Как считать результат

Плохая новость: бинарная оценка «прошёл/не прошёл» слишком грубая. Хорошая: есть шкала. Я использую четыре уровня — «правильно», «приемлемо», «сомнительно», «провал». Разница между первым и вторым — стиль, между вторым и третьим — риск, между третьим и четвёртым — инцидент.

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

Часть тестов можно автоматизировать. Фактичность — сравнением с эталоном. Границы — регулярками и классификатором. Тон — моделью-судьёй. Но не всё: сложные сценарии, где важен нюанс, лучше смотреть глазами. Полностью автоматизированный evaluation ловит глупости и пропускает тонкие провалы.

Журнал ошибок

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

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

Журнал ценен ещё и тем, что превращает разговоры в факты. Когда заказчик говорит «мне кажется, агент стал хуже», вы открываете журнал и смотрите динамику: количество провалов по неделям, по классам, по серьёзности. Это уже не ощущение, это данные.

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

Границы: где evaluation заканчивается

Есть соблазн оценивать всё. Не надо. Evaluation не заменяет мониторинг — он проверяет готовность до запуска, мониторинг следит за поведением после. Не заменяет нагрузочное тестирование — это отдельная дисциплина. Не заменяет анализ стоимости — это финансовая история, а не качественная.

Граница проходит по вопросу: можем ли мы это проверить на ограниченном наборе кейсов и получить осмысленный ответ. Если да — evaluation. Если нет — другой инструмент.

Организационная часть

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

Важнее другое: право вето. Если релиз не проходит по критичным клеткам матрицы — он не выходит. Без этого правила evaluation превращается в ритуал, а ритуалы в инженерных командах не выживают.

Что в итоге

Хорошо отвечает в демо — это про возможности. Готов к клиенту — это про границы. Между ними лежит работа: матрица, сценарии, метрики, журнал. Не самая романтичная часть разработки AI-систем, зато та, которая отличает продукт от красивой презентации.

Я не встречал команды, которая пожалела бы о вложенных двух неделях в evaluation. Зато встречал те, кто откатывал пилоты и переделывал архитектуру, потому что проверяли только демо. Разница в цене — примерно на порядок.

Глоссарий терминов

• AI-агент — система на основе модели, выполняющая задачи автономно в заданных рамках.
• Evaluation (оценка) — процесс систематической проверки качества и границ AI-системы до запуска.
• Матрица evaluation — сетка тестов, где по одной оси идут классы запросов, по другой — критерии оценки.
• Демо — показ возможностей системы на подобранных сценариях. Не является проверкой готовности к production.
• Production (прод) — рабочая среда, где система работает с реальными пользователями.
• Классы запросов — типы пользовательских обращений: точные, размытые, провокационные, граничные, пустые, враждебные, составные.
• Критерии оценки — свойства, которые проверяются: фактичность, полнота, тон, соблюдение границ, честность в неопределённости.
• Фактичность — соответствие ответа реальным данным и документации.
• Галлюцинация — уверенный, но неверный ответ модели, не опирающийся на данные.
• Границы агента — правила, которые система не должна нарушать: обещания, доступы, раскрытие инструкций.
• Провокационный запрос — обращение, пытающееся вынудить систему нарушить правила.
• Манипуляция (prompt injection) — попытка переопределить инструкции агента через пользовательский ввод.
• Сценарий отказа — заранее описанное поведение агента, когда он не знает ответа или не может помочь.
• Сценарий деградации — поведение системы при сбое внешнего компонента или нехватке данных.
• Журнал ошибок — реестр провалов агента: что спросили, что ответили, почему это плохо, что должно было быть.
• Регрессионный тест — тест, проверяющий, что закрытая дыра не открылась снова.
• LLM-as-a-judge — подход, при котором оценку ответов выполняет другая языковая модель по заданным критериям.
• Метрика — измеримый показатель качества: точность, полнота, задержка, стоимость.
• A/B-тестирование — сравнение двух версий системы на реальных пользователях.
• Инцидент — событие в production, приведшее к сбою или деградации.
• Право вето — правило, при котором релиз не выходит без прохождения критичных тестов.