Почему агенты ИИ проходят QA, но терпят неудачу в производстве

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

Агент ИИ может пройти каждое предварительное тестирование и все равно потерпеть неудачу в производстве через неделю. Это не является противоречием. Набор тестирования отражает то, что команда знала, чтобы протестировать до запуска. Производство – это где появляются пропущенные случаи: странные формулировки, отсутствие контекста, краевые случаи инструментов, нетерпеливые пользователи, противоречивые политики и рабочие процессы, которые никто не представлял.

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

Это почему непрерывное обучение становится центральным для инженерии агентов. Это не функция одного продукта. Это категория методов для улучшения агентов из опыта, сохраняя то, что уже работает. Классические исследования непрерывного обучения сформулировали проблему как обучение во времени без катастрофического забывания. Агенты делают эту проблему шире. То, что меняется, может быть моделью, но оно также может быть подсказкой, инструментом, навыком, рабочим процессом или памятью.

Этот различие имеет значение, потому что большинство неудач агентов не решаются путем обращения к обучению модели.

Рефлекс тонкой настройки слишком узок

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

Но многие производственные неудачи не являются неудачами весов модели. Они являются системными неудачами.

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

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

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

Тесты полезны, но производство редко дает вам один

Есть интересная работа по оптимизации самого харнесса агента. Методы, такие как GEPA, Meta-Harness и связанные подходы к оптимизации подсказки или рабочего процесса, рассматривают агента как систему, которая может быть изменена и протестирована. Они могут предложить редактирование подсказок или других компонентов харнесса, запустить кандидатов и сохранить версии, которые получают лучшие оценки.

Это правильное направление. Оно перемещает улучшение из узкого кадра “обновить веса” в более широкий кадр “улучшить агента”.

Но есть одна проблема: эти методы обычно предполагают тест. Они нуждаются в задаче, которая может быть запущена повторно, и в оценщике, который говорит, является ли кандидат А лучше, чем кандидат Б. Без этого оптимизация становится угадыванием с лучшим инструментом.

Это не то, что имеют большинство команд в производстве.

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

Этот разрыв – это где многие усилия по непрерывному обучению застревают. Команда имеет опыт, но еще не имеет среды обучения.

Логи не являются уроками

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

Лог не определяет контрфакт. Должен ли агент попросить подтверждение? Должен ли он сделать вывод о дате из предыдущего контекста? Должен ли он вызвать другой инструмент? Должен ли он отказаться от продолжения, пока неясность не будет решена? Человек может знать ответ после прочтения трассы, но система не получает эту структуру бесплатно.

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

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

Без этого шага команды в основном исправляют из памяти.

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

Опыт сам по себе недостаточен. Он должен быть сделан тестируемым.

Регрессия – это скрытая стоимость

Даже когда неудача становится тестируемой, самой сложной частью остается исправление ее без сломки чего-то еще.

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

Каждый патч имеет смысл локально. Система все равно дрейфует глобально.

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

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

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

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

Что требует практическое непрерывное обучение

Цикл непрерывного обучения, готовый к производству, требует четырех свойств.

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

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

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

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

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

Это то, что превращает непрерывное обучение из расплывчатой амбиции в инженерную дисциплину.

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

Когда агент терпит неудачу завтра, может ли система превратить эту неудачу в тест? Может ли она направить исправление в правильный слой? Может ли она доказать, что исправление помогло? Может ли она доказать, что ничего другого не сломалось?

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

Агенты, которые будут иметь значение в следующий раз, будут делать что-то лучше. Они будут накапливать.