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

Уявіть собі розробника о другій годині ночі, який три тижні переписував інструкції, пробував найновішу флагманську модель та налаштовував розміри частин даних у форматі RAG. У тестовому середовищі агент працює чудово. У реальних умовах він зазнає краху: забуває рішення, прийняте двома кроками раніше, оголошує про успіх безпосередньо перед тим, як повернути пошкоджений результат, а його рівень успішності виконання завдань становить 68% незалежно від того, яка модель використовується. Досягнення рівня понад 70% здається неможливим.

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

Три етапи роботи з LLM

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

Етап перший: інжиніринг запиту

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

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

Етап другий: інжиніринг контексту

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

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

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

Третій етап: інженерія керування

Тепер виникає питання, чи може модель продовжувати правильно функціонувати з часом, і відповідь дещо розчаровує тих, хто сподівався, що краща модель впорається з цим. Інженерія керування — це практика створення „каркасу“ навколо моделі: детерміністичні системи, які стежать за її діями, виявляють помилки, встановлюють обмеження та повертають її на правильний шлях, коли вона відхиляється. Це слово походить від повідків та страхових тросів — обладнання для керування.

Ментальна модель: агент — це модель плюс керувальний каркас

Підхід, популяризований LangChain, пояснює це просто: агент — це модель плюс інструментарій. Майже все в кодовій базі, що дозволяє агенту працювати в реальних умовах, окрім виклику API базової моделі, належить до цього інструментарію.

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

• Запити — це порядок денний: привітання, презентація продукту, запитання щодо вимог.
• Контекст — це інформація про фон: історія співпраці з клієнтом, ціновий список та цілі зустрічі.
• Інструментарій — це все інше: чек-лист, який вони мають при собі, зв’язок з вами на півдорозі, запис розмови, можливість виправити їхні помилки та чіткі критерії прийнятності звіту про зустріч.

Краща інформаційна підготовка не може компенсувати відсутність структури відповідальності. Перші два етапи допомагають моделі краще мислити, а інструментарій забезпечує її надійну роботу. Опис однієї команди, який є анекдотом, а не критерієм оцінки, свідчить про те, що переробка розбиття завдань, обробки станів, перевірки критичних кроків та відновлення після збоїв дозволила тій самій моделі за допомогою тих самих запитів підняти рівень успішності виконання завдань з приблизно 70% до понад 95%.

Шість рівнів зрілого інструментарію

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

Рівень 1: межі інформації

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

Рівень 2: система інструментів

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

The harness should govern when tools get used, not just which ones exist. It should stop the model from guessing when it ought to search, and from searching when it already knows. And one rule has no exceptions: don't pipe raw tool output straight back to the LLM. A 50-item JSON reply from an API poisons the context. Filter, parse and summarise results before the model sees them.

Layer 3: execution orchestration

Models often fail not for lack of individual skills but because they can't chain them in order. They run in a stream of consciousness, hopping between steps, skipping checks and writing output before they have what they need. The harness sets fixed rails: understand the goal, assess what information is held, fetch what's missing, analyse, generate, verify, then output.

Це переводить управління проектом від ймовірнісної моделі до детермінованої системи. Модель не повинна визначати порядок виконання робіт — ця структура має належати до інструментів керування.

Шар 4: пам’ять та стан

Агент без стану має амнезію на кожному кроці, ніби кожен етап багатоетапного завдання є новою розмовою. Ефективний підхід суворо розділяє три види пам’яті:

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

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

Шар 5: оцінка та спостережуваність

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

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

Шар 6: обмеження, перевірка та відновлення

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

• Обмеження: жорстко закодовані правила щодо того, чого агент ніколи не повинен робити.
• Перевірка: контрольні перевірки до та після формування вихідних даних, такі як перевірка схеми, перевірка формату та підтвердження дотримання обмежень.
• Відновлення: повторні спроби, альтернативні шляхи вирішення та повернення до останнього відомого стабільного стану.

Тривога через контекст

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

Очевидним рішенням є стиснення: підсумувати історію, вставити цей підсумок та продовжувати роботу. Це зменшує кількість токенів, але не скидає когнітивний стан моделі чи рівень розсіяності уваги. Ефективним є більш радикальний підхід — повне перезапуск агента. Коли обсяг контексту стає занадто великим, стиснутий підсумок передається до абсолютно нової інстанції агента з чистим контекстом та без усіх накопичених проблем. Це схоже на усунення витоку пам’яті шляхом перезапуску процесу, а не через поспішну обробку сміття. Позначенням для цього підходу є «context reflect».

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

Розділення генерації та оцінки

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

• Планувальник перетворює нечіткі запити людини на точні інженерні специфікації.
• Генератор використовує ці специфікації та виконує завдання крок за кроком.

Оцінювач працює як незалежна посада з контролю якості, функціонально відокремлена від генератора.

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

OpenAI пішов ще далі. Коли агенти почали писати код швидше, ніж люди могли переглянути запити на зміни, вони надали цим агентам власну автоматизовану систему CI/CD. Агенти виконують свою роботу у ізольованих сандбоксах, роблять скріншоти за допомогою безголових браузерів, аналізують власні журнали подій та продовжують цей процес до тих пір, поки розгортання не стане успішним, знову без жодного спостерігача. Позначка „Готово“ більше не означає лише створення тексту — вона означає, що код було запущено, перевірені журнали подій, знайдена та виправлена помилка, а розгортання підтверджено у сандбоксі.

Де насправді знаходиться верхня межа

Інтелект моделі-основи встановлює теоретичний ліміт для таблиць з результатами тестування. Як добре спроєктований механізм керування визначає, чи зможе цей інтелект вижити, відновитися та принести користь у складних реальних умовах. Після певного рівня модель більше не є вузьким місцем. Різниця між рівнем успішності 70% та 95%, що також є різницею між демо-версією та готовим продуктом, полягає саме у цьому механізмі керування.