Риск удачного запуска: ИИ-агент справился один раз, но схема не стала надежнее

В работе с ИИ-агентами есть опасный момент: один удачный запуск легко принять за улучшение всей схемы.

Ты меняешь модель, инструкцию, память или правила доступа к инструментам. Добавляешь отдельную проверку результата. Запускаешь задачу.

Агент справляется.

На вид - шаг вперед.

Но один успешный запуск доказывает меньше, чем кажется.

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

Надежность из этого не следует.

Повторяемость - тоже.

Цена запуска могла вырасти сильнее качества.

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

Такой запуск полезен. Он показывает, что сценарий вообще возможен.

Но это еще не проверка качества.

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

Почему единичный успех так легко обманывает

С обычной программой все скучнее.

Есть входные данные. Есть ожидаемый результат. Есть проверка. Есть повторяемость.

С агентами границы быстрее расползаются.

Вчера была одна инструкция.
Сегодня ее переписали.
Потом добавили память.
Потом дали доступ к новому инструменту.
Потом включили отдельную проверку.
Потом чуть иначе сформулировали задачу.
Потом человек в процессе подсказал направление.

Агент справился.

Очень легко решить, что новая схема лучше.

Но в этой цепочке смешано слишком много факторов.

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

Сигнал настоящий: запуск прошел хорошо.

Вывод - нет.

"Сработало один раз" и "стало надежнее" - разные утверждения.

Что нужно сравнивать на самом деле

Рейтинг агентов отвечает на другой вопрос.

Команде важнее не "кто умнее", а "что изменилось после нового варианта работы".

Например:

Вариант А: та же модель и та же инструкция, но без памяти. Вариант Б: та же модель и та же инструкция, но с памятью.

Или:

Вариант А: агент работает один. Вариант Б: после агента результат проверяется отдельным проходом.

Или:

Вариант А: агенту доступна только командная строка. Вариант Б: агенту доступны командная строка и работа со страницами в интернете.

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

А впечатление - плохая основа для изменения процесса.

Нормальная единица проверки

Минимальная единица проверки:

Семейство задач. Входные данные. Разрешенные действия. Ожидаемый проверяемый результат. Правило проверки. Сравнение двух вариантов работы.

Семейство задач - это не одна задача, а тип повторяемой работы.

Например:

исправить локальную поломку в проекте; ответить по фиксированному набору документов; посчитать показатели по таблице и сделать короткий отчет; разобрать входящие обращения поддержки; выполнить действие через локальный служебный интерфейс по правилам.

Входные данные - то, с чем агент работает.

Разрешенные действия - что ему можно делать, а что нельзя.

Ожидаемый проверяемый результат - что должно появиться на выходе: файл, отчет, изменение состояния, список источников, журнал действий, журнал решений.

Правило проверки - как мы понимаем, что результат принят.

Сравнение - как мы смотрим на вариант А и вариант Б на одинаковых примерах.

Так вместо ощущения появляется предметный разговор.

На этом семействе задач новый вариант дал меньше нарушений правил, не потерял качество, стал дешевле, быстрее или стабильнее.

Почему видимых примеров недостаточно

Видимые примеры нужны.

Без них невозможно нормально собрать проверку, отладить правила и объяснить формат задачи.

Но видимый пример со временем часто становится тренировочным.

Даже если модель его не видела, его видит человек. Его видит команда. Под него начинают подстраивать инструкцию, память, правила доступа к инструментам, примеры и формат результата.

Это нормальная часть разработки.

Проблема начинается, когда качество проверяют только на видимых примерах.

Так можно улучшить не способность агента работать, а способность проходить один знакомый набор задач.

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

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

Иначе проверка начинает мерить узнавание примера, а не способность работать.

Где это стоит бизнесу денег

На уровне команды ошибка выглядит так.

Команда добавила память. Или новый инструмент. Или перешла на другую модель. Или собрала схему из нескольких агентов.

После этого агент красиво справился с одной задачей.

Решение: выкатываем новый вариант шире.

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

Проблема не в том, что изменение было плохим.

Проблема в том, что его приняли по одному сигналу.

Как проверить

Перед тем как верить выводу "стало лучше", нужен такой фильтр.

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

2. Одинаковые ли входные данные у старого и нового варианта? Сравнение имеет смысл только когда оба варианта проходят одну и ту же проверку.

3. Одинаковое ли правило проверки? Если один результат оценивается жестко, а другой мягко, итоговое число ничего не говорит.

4. Есть ли проверяемый результат? Агент должен принести не только хороший ответ, а след, который можно проверить: файл, отчет, изменение состояния, список источников, журнал действий.

5. Есть ли закрытые примеры или измененные варианты? Иначе легко улучшить прохождение публичного примера.

6. Видны ли поломки, а не только средняя оценка? Средняя оценка может вырасти, пока важный сценарий ломается. Для процесса важны категории ошибок.

7. Видны ли цена, время и нарушения правил? Новый вариант может стать качественнее, но слишком дорогим, медленным или опасным для реальной работы.

8. Не видит ли агент ответы заранее? Если агенту доступна скрытая проверка или правильный ответ, это уже не проверка качества, а подсказка.

Что особенно важно для ИИ-агентов

Для обычных программ часто проверяют итоговое поведение.

Для агентов нужно проверять еще и поведение процесса.

Агент может дать правильный ответ, но:

- использовать запрещенный источник;
- раскрыть приватный фрагмент;
- проигнорировать правило;
- сделать лишнее внешнее действие;
- не оставить проверяемый след;
- придумать источник;
- решить задачу дороже, чем приемлемо;
- случайно попасть в правильный итог.

Поэтому проверка ИИ-агента должна смотреть не только на финальный ответ.

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

Не обязательно все сразу.

Но если этого нет вообще, проверка легко становится красивой витриной.

Ограничения

Такая проверка не заменяет человека.

Есть задачи, где жесткое автоматическое правило слишком грубое.

Есть задачи, где нужна оценка по нескольким признакам.

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

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

Еще сама проверка может стать целью игры. Если команда начинает настраивать агента только под видимые правила, качество может расти в отчете и падать в реальности.

Проверка не финальная истина.

Это способ уменьшить самообман.

Вывод

Один удачный запуск не должен быть основанием для выката нового варианта работы.

Сравнительная проверка нужна не для выбора "самого умного агента".

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

Не "агент справился".

А:

где стало лучше;
где стало хуже;
сколько это стоит;
какие ошибки появились;
какой риск все еще остается.

Один успешный запуск - это сигнал.

Но еще не доказательство.