Чому продакшн-агенти ШІ потребують більшого, ніж просто хороший запит.

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

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

Більше, ніж ШІ-модель з інструментами

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

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

1. Перевірити, чи є запит коректним.
2. Вийняти інформацію з документа.
3. Отримати відповідний контекст.
4. Скласти правильний запит до моделі.
5. Змусити модель міркувати на основі отриманих даних.
6. Перевірити результат, який надала модель.
7. Використати додаткові інструменти.
8. Обчислити результати, які мають бути точними.
9. Зберегти результат.
10. Повідомити інтерфейсу про прогрес.
11. Повторно спробувати виконати те, що не вдалося.

Записуйте журнали та сліди для подальшого відлагодження.

На цьому етапі робота вже не полягає у швидкому проектуванні. Йдеться про проектування розподіленої системи, яка випадково містить LLM. Чітке розподілення обов’язків допомагає.

Вхідні дані та контекст

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

Шар міркувань

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

Припустимо, бізнес-правило виглядає так: variance <= 5% → PASS. Нікому не потрібен LLM, щоб вирішити, чи 3,8% менше за 5%. Просто обчисліть це. Використовуйте модель там, де потрібні міркування, а код — там, де можливий детермінізм. Такий розподіл значно полегшує тестування систем агентів.

Інструменти роблять агентів корисними

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

Ось суть паттерну ReAct: міркування, дія, спостереження, потім знову міркування. Він є потужним, тому що агенту не потрібно заздалегідь знати всі факти — він може знаходити потрібну інформацію під час виконання завдання.

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

Пам’ять — це не спосіб накопичувати

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

Корисно мислити пошарово:

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

Питання, яке потрібно поставити, — це не те, скільки агент може запам’ятати, а те, що йому потрібно знати прямо зараз. Ця невелика зміна може значно спростити архітектуру.

Будьте обережні з великою кількістю агентів

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

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

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

Планування на випадок збою

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

Тут традиційна інженерія бекенду стає необхідною. Агенти у продакшені потребують:

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

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

Експліцитні стани, такі як QUEUED → RUNNING → COMPLETED або QUEUED → RUNNING → FAILED → RETRYING.

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

Перегляд того, що зробив агент

Звичайні додатки вже потребують журналів подій та метрик. Агентам потрібно ще більше. Коли агент дає поганий результат, інформація про те, що HTTP-запит повернув 200 OK, майже нічого не говорить. Важливим є весь процес: запит, отриманий контекст, створений запит, виклик моделі, вибраний інструмент, його виконання, оцінка результату та кінцева відповідь.

Для кожного запуску команда повинна мати можливість відновити наступне:

• Контекст, який був наданий агенту
• Модель, яка працювала
• Інструменти, які були використані, та у якому порядку
• Час, витрачений на кожен крок
• Споживання токенів
• Причина збою – чи то інфраструктура, чи процес міркувань
• Висновок після кроку оцінки

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

Тестування недетерміністичної поведінки

Класичне програмне забезпечення дотримується простого правила: вхідні дані A дають вихідні дані B. Штучні інтелектуальні мови не зобов’язані до цього, адже два правильні відповіді можуть бути сформульовані зовсім по-різному. Тому тестування потребує кількох рівнів.

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

Автономність має враховувати ризик

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

• Низький рівень ризику: виконується автоматично.
• Середній рівень ризику: виконується, потім фіксується в журналі або перевіряється.
• Високий рівень ризику: потрібна схвалення людини перед виконанням.

Метою не є максимальна автономія. Це корисна автономія з контрольованим ризиком.

У сукупності картинка стає зрозумілою, і виявляється, що LLM — це відносно невелика складова в цій системі. Це робиться навмисно.

Питання перед вибором фреймворку

Перед тим, як обрати фреймворк або написати складний запит, варто поставити кілька питань:

1. Яке рішення дійсно потребує ШІ? Одина крок розумових міркувань не робить усю робочу процедуру інтелектуальною.
2. Що може залишатися детермінованим? Обчислення, перевірка, дозволи та критичні бізнес-правила мають бути в коді.

Який контекст насправді потрібен агенту? Завантажуйте інформацію вибірково та уникайте надання повного опису запиту.

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

Як буде оцінюватися якість? Визначте критерії оцінки ще до того, як святкувати першу успішну демонстрацію.

Як його буде дебагувати через шість місяців? З самого початку вбудуйте функції відстеження та структурованого журналування.

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

Інженерія запитів, вибір моделей та RAG все ще мають значення. Але для практичного використання потрібна більш широка дисципліна: архітектура програмного забезпечення, побудована навколо ймовірнісного інтелекту. Найкращий дизайн — це не той, у якому найбільше агентів, найбільша модель чи найсучасніша система оркестрації. Це той дизайн, у якому можна чітко визначити, що знає агент, що він може та не може робити, як оцінюється правильність дій, що відбувається у разі збою та як система відновлює роботу. Саме тоді ШІ-агент перестає бути просто цікавою демонстрацією та стає програмним забезпеченням, якому можна довіряти.