Чому агенти штучної інтелекту проходять перевірку якості, але все одно не справляються у виробництві

Неперервне навчання стає інженерною дисципліною для вдосконалення агентів після розгортання, без порушення того, що вже працює.

Агент штучної інтелекту може пройти кожну перевірку перед запуском і все одно не справитися у виробництві через тиждень. Це не суперечить один одному. Набір перевірок відображає те, що команда знала перевірити перед запуском. Виробництво – це місце, де з’являються відсутні випадки: дивна фраза, відсутній контекст, крайні випадки інструментів, нетерплячі користувачі, суперечливі політики та робочі процеси, яких не уявляв жоден дизайнер бенчмарка.

Агент постійно виправляється користувачами. Він розчаровує користувачів. Потім сесія закінчується, журнал зберігається, і наступний користувач зустрічає практично ту саму систему.

Це пояснює, чому неперервне навчання стає центральним у інженерії агентів. Воно не є функцією одного продукту. Воно являє собою категорію методів для вдосконалення агентів за допомогою досвіду, зберігаючи те, що вже працює. Класичні дослідження з неперервного навчання сформулювали проблему як навчання протягом часу без катастрофічного забуття. Агенти роблять цю проблему ширшою. Те, що змінюється, може бути моделлю, але це також може бути підказкою, інструментом, навичкою, робочим процесом або пам’яттю.

Ця відмінність має значення, оскільки більшість невдач агентів не вирішуються шляхом навчання моделі.

Рефлекс донастройки надто вузький

Коли команди говорять про поліпшення системи штучної інтелекту, план часто звучить так: зібрати невдачі, позначити кращі відповіді, донастроити модель. Цей інстинкт зрозумілий. Надійна донастройка, безпосереднє оптимізація переваг, групове відносне оптимізація політики та параметро-ефектні методи, такі як LoRA, корисні інструменти, коли сама модель потребує змін.

Але багато невдач у виробництві не є невдачами ваг моделі. Вони є системними невдачами.

Агент може покладатися на застарілу пам’ять, пропустити необхідне підтвердження, викликати інструмент з неправильним аргументом або направити випадок через неправильний робочий процес. Часто проблема не полягає в здатності базової моделі. Це контекст, пам’ять, інтерфейс інструменту або робочий процес, який оточує її.

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

Іноді правильний виправлення полягає у записі пам’яті. Іноді це редагування підказки. Іноді це обгортка інструменту, правило маршрутизації або патч робочого процесу. Донайстрування повинно залишатися доступним, але воно не повинно бути першим відповіддю на кожну невдачу.

Бенчмарки корисні, але виробництво рідко надає їх

Є цікава робота з оптимізації самої оболонки агента. Методи, такі як GEPA, Meta-Harness та пов’язані підходи оптимізації підказок або робочих процесів, розглядають агент як систему, яку можна змінити та протестувати. Вони можуть пропонувати редагування підказок або інших компонентів оболонки, запускати кандидатів та зберігати версії, які мають кращий результат.

Це правильний напрямок. Воно переміщує поліпшення з вузької рамки “оновлення ваг” у ширшу рамку “поліпшення агента”.

Але є одна проблема: ці методи зазвичай припускають бенчмарк. їм потрібне завдання, яке можна виконувати повторно, та оцінювач, який каже, чи кандидат А кращий за кандидата Б. Без цього оптимізація стає здогадкою з кращим інструментарієм.

Це не те, що мають більшість команд у виробництві.

Те, що у них є, – це журнали. У них є траси, виправлення користувачів, тикети підтримки, події знизу, примітки про ескалацію та періодичну експертну відповідь. Ці сигнали цінні, але вони ще не є бенчмарком. Вони кажуть, що щось трапилося. Вони не кажуть автоматично, як відтворити це, яким повинен бути успіх або як оцінити запропоноване виправлення.

Цей розрив – це місце, де багато зусиль з неперервного навчання застряють. Команда має досвід, але ще не має середовища навчання.

Журнали не є уроками

Журнал виробництва реєструє один шлях через взаємодію. Користувач запитав рейс. Агент знайшов. Користувач сказав, що дата була неправильною. Це свідчення невдачі, але цього недостатньо, щоб вивчити.

Журнал не визначає контрфакт. Чи повинен агент запитати підтвердження? Чи повинен він вивести дату з попереднього контексту? Чи повинен він викликати інший інструмент? Чи повинен він відмовитися продовжувати, доки не буде вирішена двозначність? Людина може знати відповідь після прочитання траси, але система не отримує цю структуру безкоштовно.

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

Це менш помітна частина роботи, але це частина, яка робить поліпшення реальним. Як тільки невдача стає середовищем, яке можна відтворити, можна поставити конкретне питання: чи дійсно запропоноване виправлення виправило поведінку?

Без цього кроку команди в основному виправляють за допомогою пам’яті.

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

Досвід сам по собі недостатній. Його потрібно зробити тестируємим.

Регресія – це прихована вартість

Даже коли невдача стає тестируємою, найважча частина залишається: виправлення її без порушення чогось іншого.

Хто б не підтримував складний агент, бачив цю картину. Ви додаєте інструкцію, щоб агент ескалував агресивні запити на повернення коштів. Тепер він ескалує звичайні повернення коштів, які повинні оброблятися швидко. Ви зменшуєте виклики інструментів в одному робочому процесі. Тепер інший робочий процес пропускає необхідну перевірку. Ви виправляєте застарілу пам’ять. Тепер агент надміру узагальнює виправлення для іншої лінії продукції.

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

Це агентська версія катастрофічного забуття. У нейронних мережах цей термін зазвичай відноситься до нового навчання, яке стирає старіші можливості. У агентах невдача ширша та часто важче побачити. Забуття може відбуватися в підказках, інструментах, пам’яті, маршрутизації та робочому процесі. Воно проявляється не як чистий метрик на кривій навчання, а як користувач, який каже: “Це раніше працювало”.

Це чому контроль регресії не може бути остаточним етапом перевірки. Воно повинно бути всередині самого циклу навчання.

Мета не полягає просто у максимізації продуктивності щодо останньої невдачі. Мета полягає у поліпшенні нового випадку, зберігаючи старі випадки. Кожне виправлення, яке працює, повинно стати частиною зростаючої пам’яті агента про те, що повинно продовжувати працювати. На практиці це означає, що старі невдачі стають тестами на регресію. Історія агента стає обмеженням, а не просто архівом.

Це місце, де неперервне навчання стає більш серйозним інженерним забезпеченням, ніж просто налаштування підказок. Зміна хороша не тому, що вона звучить краще. Вона хороша тому, що вона покращує виміряну поведінку та не регресує поведінки, які система вже заслужила.

Що практичне неперервне навчання вимагає

Цикл неперервного навчання, готовий до виробництва, потребує чотирьох властивостей.

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

По-друге, діагноз повинен бути голістичним. Виправлення може належати моделі, але воно також може належати пам’яті, підказці, шару інструментів або робочому процесу. Найкраще виправлення зазвичай найменше тривале виправлення, яке пояснює невдачу.

По-третє, навчання повинно бути довічним. Агент не повинен покращуватися цього тижня, тихо скасовуючи поведінку минулого тижня. Попередні успіхи повинні стати обмеженнями під час оптимізації, а не сюрпризами після розгортання.

По-четверте, цикл повинен бути ефективним. Якщо кожне поліпшення вимагає проекту повторного навчання кожних трьох місяців, система ніколи не впорається з виробництвом. Цикл повинен спочатку спробувати дешеві виправлення, ескалувати лише при необхідності та зберігати перевірку близько до зміни.

Жодне з цього не означає, що агенти повинні оновлюватися сліпо. Це означає протилежне. Поліпшення повинно стати вимірним. Кожна зміна повинна мати тест, оцінку до та після зміни, та перевірку на регресію.

Це те, що перетворює неперервне навчання з розмитої сподіванки на інженерну дисципліну.

Майбутнє агентів не буде визначено лише більшим контекстним вікном, сильнішою базовою моделлю або більшим числом інструментів. Все це матиме значення. Але більш важливим питанням для підприємств є те, що відбувається після розгортання.

Коли агент невдається завтра, може система перетворити цю невдачу на тест? Чи може вона направити виправлення до правильного шару? Чи може вона довести, що виправлення допомогло? Чи може вона довести, що нічого іншого не зламалося?

Якщо відповідь – ні, агент не дійсно вчиться у виробництва. Він накопичує ризик.

Агенти, які матимуть значення далі, зроблять щось краще. Вони будуть нарощувати.