Коли панель керування показує зелений статус, а агент робить помилку: відстеження стану
Панель керування має зелений колір, і агент помиляється: проблеми приховуються у стані, який передається між коректними кроками. Які записи трекінгу, маршрутизації та оцінок необхідно фіксувати.
Джерела: When the Dashboard Is Green and the Agent Is Wrong: Tracing Multi-Step Failures Past the LLM Call
Зелений панель керування та неправильна відповідь
У виправленні помилок у штучних інтелекту є дратівлива особливість: екран моніторингу може стверджувати, що все гаразд. Виклик моделі завершився, інструменти працювали, API повернули код 200, затримка є звичайною, а використання токенів — у очікуваних межах. З точки зору інфраструктури нічого не відбувається, проте кінцевий результат може бути абсолютно неправильним.
Це не той очевидний вид помилки, коли модель вигадує щось абсурдне. Такі проблеми легші, адже принаймні ви знаєте, з чого почати. Складнішим є випадок, коли кожен крок здається розумним, технічних збоїв немає, а відповідь настільки правдоподібна, що хтось може діяти на її основі.
Проблема посилюється у міру того, як системи еволюціонують від простих викликів LLM до агентів та багатоетапних робочих процесів. Перш ніж з’явиться відповідь, її основна інформація могла пройти через кілька моделей, інструментів, API, процедур трансформації та маршрутизаторів, тож кінцева модель може виконувати свою роботу ідеально, працюючи з даними, які вже були пошкоджені п’ять кроків тому. Цій аспекту спостережуваності агентів потрібно значно більше уваги, ніж він отримує.
Зміна схеми, яку ніхто не помічає
Розгляньмо типову задачу забезпечення успіху клієнтів. Від агента вимагають знайти клієнтів, чиї поновлення контрактів припадають на наступні 30 днів, позначити акаунти, які, ймовірно, можуть піти, та підготувати звіт для команди забезпечення успіху. Під час виконання цієї роботи він може звертатися до CRM, обчислювати рівень ризику, отримувати останні запити підтримки, перевіряти рівень використання продукту та нарешті змусити LLM написати звіт.
Тепер уявімо, що CRM змінив одну зі своїх схем відповідей. Учора вміст повідомлення виглядав ось так.
{
"health_score": 42
}
Сьогодні воно виглядає ось так.
{
"health": {
"score": 42
}
}
API все ще працює, запит все ще успішний, а JSON все ще парсується. Залежно від коду інтеграції не потрібно кидати жодних винятків. Проблеми виникають пізніше, коли шар нормалізації продовжує шукати health_score, а на наступному кроці отримує значення null.
Можливо, механізм оцінки ризиків сприймає відсутнє значення як нейтральне, або можливо, у інструкціях сказано використовувати все, що є під рукою. У обох випадках робочий процес продовжується та закінчується правдоподібним звітом, у якому не враховується акаунт, про який команда мала б знати.
Зосереджуючись на кінцевому результаті, легко звинувачувати модель, тож люди починають переписувати інструкції, змінювати моделі чи налаштовувати параметри температури, не торкаючись справжньої причини. Краще поставити запитання про те, коли стан вперше став неправильним, і завдяки цьому запитанню відлагодження агента виглядає зовсім інакше.
Події успіху не доводять розуміння
Один нещодавній есе про те, як веб перетворюється на API для агентів, описує, як програмне забезпечення переходить від надання інформації до виконання дій за користувача. У ньому стверджується, що надання інструментів у розпорядження моделі — це лише частина процесу, адже наміри, дозволи, контроль під час виконання та можливість аудиту мають значення, коли агенти виконують реальні дії.
Те саме стосується виправлення цих дій. Інформація про те, який інструмент було виконано, є корисною, але вона не розкриває, чи розумів решта робочого процесу результати дії цього інструменту. Уявіть собі слід, який містить таку інформацію.
crm.search_accounts
status: success
duration: 184ms
records: 47
Ви дізнаєтесь, що CRM надав 47 записів. Однак залишається невідомим, чи всі 47 записів дійшли цілими до наступного етапу. Можливо, існувало ще шість сторінок, а пагінація закінчувалася після першої. Можливо, сума була перерахована з доларів у центи, або час у форматі UTC було сприйнято як місцевий час. Можливо, у значенні типу enum змінилася орфографія з „cancelled“ на „canceled“, або API почав повідомляти про помилки на рівні додатку у відповідях, чий HTTP-статус здавався нормальним.
Це звичайні програмні баги. Особливість у роботі з агентами полягає у тому, що наступна модель зазвичай продовжує працювати, приймаючи дані, які здаються правдоподібними, та аналізуючи їх. Тому більш складна модель не обов’язково щось виправить. Якщо дані вже при надходженні є неправильними, модель просто розв’язує неправильну проблему з більшою майстерністю.
На ключових моментах ви повинні мати можливість переглянути вхідні дані, результати, зміни, які були застосовані до відповіді, та те, що отримано на наступному етапі. Не обов’язково зберігати всю необроблену інформацію назавжди, але потрібно зберігати достатньо даних для відновлення процесу після збою.
Відстеження відсутнього конкурента
Інструменти стають кращими. Семантичні конвенції GenAI від OpenTelemetry починають стандартизувати опис викликів моделей та виконання інструментів, а такі фреймворки, як OpenAI Agents SDK, відстежують процеси генерації, виклики інструментів, передачу даних та правила безпеки. Це корисний сировий матеріал, але зробити ці дані корисними все ще складно, коли робочий процес завершено, а справжній збій прихований у даних, переданих між двома етапами.
Розгляньмо спрощений процес, як показано на малюнку.
Припустимо, у кінцевому звіті відсутній конкурент, який очевидно має бути присутнім. Раніше звичайно було відкривати кінцеве запитання та перевіряти відповідь моделі. Можливо, інструкції були недостатньо чіткими, або модель проігнорувала частину контексту, або інша модель виконала б роботу краще. Але зараз цей підхід вже не є правильним.
Краще працювати у зворотному напрямку. Чи отримала кінцева модель відсутнього конкурента? Якщо ні, то чи пройшов етап класифікації? Якщо він зник ще до класифікації, чи був він присутній після вилучення даних? Його наявність після вилучення, але відсутність після нормалізації означає, що проблема полягає саме в одному з етапів обробки.
{
"company": "Example Corp",
"website": {
"url": "https://example.com"
}
}
хоча крок нормалізації саме цього й очікував.
{
"company": "Example Corp",
"website": "https://example.com"
}
У всьому цьому не було нічого драматичного. На середині процесу об’єкт змінив форму, і один з кроків було виконано неправильно, проте більшість операцій поруч все ще виглядали нормально. Такі помилки потребують розслідування, адже без нього вина падає на той компонент, який є найбільш помітним, незалежно від того, що відбувалося раніше.
Практичний урок полягає не в тому, що потрібен якийсь конкретний інструмент для спостереження. Він полягає у тому, що система трасування має дозволяти відстежувати стан протягом усього процесу роботи та не повинна лише перелічувати компоненти, які були запущені. Існує велика різниця між тим, щоб знати, що було виконано 4-й крок, та тим, щоб знати, що отримав від нього 5-й крок.
Зміна плану здається доцільною
Як тільки ви виявляєте порушення, пов’язане з обмеженнями інструменту, це є досить очевидним. Однак проблема з відхиленням від плану складніша, адже агент може відхилитися від початкового завдання через кроки, кожен з яких здається логічним. Уявіть собі агента, якому доручено дослідити п’ять постачальників, оцінити їхні ціни та надійність та скласти рекомендацію, з вказівкою не зв’язуватися з ними.
Агент знаходить постачальників та починає збирати дані. Два з них не вказують цін, тож він шукає інший спосіб це обійти. Зрештою він знаходить інструмент для електронної пошти. Його логіка не є абсурдною: потрібні ціни, вони не є публічними, а повідомлення постачальнику могло б це вирішити. Однак це також порушує одне з найважливіших правил завдання.
Коли правило — це просто речення біля верхньої частини зростаючого вікна контексту, усе залежить від того, чи буде модель продовжувати сприймати його як важливе після того, як накопичаться тисячі токенів результатів пошуку, результатів роботи інструментів та проміжних станів. Обмеження з реальними наслідками заслуговують на чітку формулювання.
{
"objective": "Compare suppliers and prepare a recommendation",
"constraints": [
"Do not contact suppliers"
],
"completed_steps": [
"discover_suppliers",
"collect_public_pricing"
],
"next_action": "request_missing_prices",
"requested_tool": "send_email"
}
Тепер у додатку є щось, що можна перевірити перед виконанням дії. Він може відхилити запит про використання інструменту, вимагати людського схвалення або надіслати агента на пошук іншого шляху. Правильна відповідь залежить від процесу роботи, але ключовий момент полягає у тому, що обмеження більше не полягають виключно у формулюванні інструкцій.
Правила на кшталт ліміту витрат, „сформувати проект, але не надсилати“ чи „ніколи не торкатися продакшну“ функціонують так само. Проста мова допомагає передати наміри користувача, але дозволи та обмеження, які мають значення, також мають бути реалізовані у вигляді контролів під час виконання.
Програмне забезпечення вирішує це питання всюди інакше. Ніхто не буде писати у коментарі „будь ласка, не дозволяйте неуповноваженим користувачам видаляти базу даних“ та називати це контролем доступу, а агенти не заслуговують на виняток лише через те, що їхні інструкції написані англійською.
Маршрутизація моделей створює межу
Маршрутизація створює схожу проблему. Вибір моделі вже не є просто значенням конфігурації, адже необхідно збалансувати якість, вартість, затримку, використання інструментів та різні можливості моделей у продуктивній системі, і рішення щодо маршрутизації стає частиною запису подій, необхідного для дебаггінгу.
Припустимо, крок 6 зазвичай виконується за допомогою моделі A. Під час роботи в реальному часі у постачальника обмежується швидкість обробки, тож маршрутизатор перемикається на модель B. Це є запасним варіантом, який працює згідно з проектом, оскільки робочий процес залишається активним, а не зупиняється. Проте модель B форматує структуровані аргументи для наступного інструменту трохи інакше. Вони залишаються дійсними, і інструмент працює успішно, але одне з полів читається так, що це змінює кінцевий результат.
Якщо звіти про спостережуваність відображають лише модель, налаштовану для робочого процесу, хтось може годинами намагатися відтворити проблему на моделі A, тоді як саме модель B обробляла запит, що спричинив збій. Тому трек повинен фіксувати запитану модель, ту, що відповіла, будь-які альтернативні варіанти, діючу політику маршрутизації та те, чи було це повторне запитання. Це не надто цікава інформація, але більшість корисних засобів для виправлення проблем у продакшені також не є захоплюючими. Окрім демонстрацій, більша частина роботи полягає у виявленні тих непомітних деталей, які змінилися.
Стан треку, а не лише події
Інструменти агента тепер ефективно відображають структуру виконання завдання, зокрема виклики моделей, інструменти, передачі даних, повторні спроби та інші події у все зручніших віджетах відстеження. Помилкою буде припускати, що запис більшої кількості подій автоматично забезпечує хорошу можливість спостереження. Навіть якщо у виконанні є десять добре інструменталізованих етапів, це не допоможе, якщо неможливо зрозуміти, який стан існував між ними.
Короткий перелік запитань допомагає розібратися з проблемним виконанням. Що спочатку хотів користувач? Які обмеження діяли? Який план дотримувався система? Що повернув кожен інструмент та що отримав наступний крок? Яка модель прийняла кожне рішення? Чи щось змінилося у зовнішньому світі? Де результати перестали відповідати очікуванням?
Відповіді на ці запитання потребують менше даних, ніж їх повне записування, а останнє саме по собі створює проблеми. Запити, аргументи інструментів та їхні відповіді можуть містити приватні дані клієнтів, облікові дані чи інший конфіденційний вміст, який не слід без роздумів передавати на платформу для моніторингу. Рекомендації OpenTelemetry щодо GenAI вказують на це, а їхня детальна специфікація span робить запис вхідних та вихідних даних моделі добровільним, а не стандартним.
Отже, мета полягає у тому, щоб зробити можливим відновлення лише відповідних частин виконання завдання, а не записувати все. Іноді достатньо скоригованої відповіді, іноді — версії схеми та ідентифікатора об’єкта, а іноді для проміжного результату потрібен знімок, оскільки ніщо інше не може відтворити виконання завдання. Вирішуйте свідомо, щоб у разі інциденту не залишалося лише значення status: success як єдиного записаного даних.
Що це означає для оцінки
Пояснення може розкрити, що сталося, але не визначить, чи був результат хорошим, тому оцінка залишається необхідною. Anthropic стверджує те саме у своїй статті про оцінку агентів. Агентів важче оцінювати, ніж окремі відповіді, оскільки вони працюють протягом кількох етапів, використовують інструменти, змінюють стан та адаптуються до попередніх дій.
Деякі результати можна перевірити без додаткової моделі. Агент, якому сказали не надсилати електронний лист, але він його надіслав, провалив завдання, а завдання на вилучення даних, яке мало повернути 27 записів, а повернуло лише 11, значно відхиляється від норми. Інші випадки є більш неоднозначними: чи був дослідницький звіт достатньо детальним? Чи були джерела якісними? Чи вирішила відповідь служби підтримки проблему клієнта? Для таких випадків може знадобитися людський огляд, відгуки користувачів, набори даних чи оцінювачі, засновані на моделях.
Справжня цінність полягає у поєднанні оцінки з трекуванням. Оцінка «негативна» поруч із збереженою кінцевою відповіддю лише свідчить про те, що користувачу вона не сподобалась. Підключена до всього процесу виконання, ця ж інформація дозволяє переглянути отриманий матеріал, інструменти, які були використані, моделі та момент, коли змінився стан.
Як тільки знаходиться справжня причина збою, цей процес виконання зберігає свою цінність після інциденту, адже він може стати прикладом для оцінки з метою запобігання повторенню після майбутніх змін у запитах, моделях чи робочих процесах. Це набагато краще, ніж поступово виправляти погані відповіді, сподіваючись, що більше нічого не зламається.
Не починайте з кінцевого запиту
Ймовірно, найбільша зміна у відлагоджуванні систем ШІ — це саме вона. У простому додатку на основі LLM, який надає неправильну відповідь, достатньо прочитати запит та відповідь, адже місця для проблеми майже немає. Коли системи стають складнішими, така практика вже не є ефективною. Уявіть собі конвеєрний ланцюжок, який включає кілька моделей, інструменти пошуку та отримання даних, зовнішні API, маршрутизатори та цикл перевірки: останній запит може бути просто тим місцем, де нарешті проявилася попередня помилка.
RAG вже дав урок. Коли механізм пошуку вставляє неправильний документ у вікно контексту, більш складна модель генерації не зможе це виправити, тож доводиться повертатися назад, щоб виправити процес пошуку. Агенти діють за тією самою логікою, але з додатковими обмеженнями. Чи все гаразд із пошуком? Подивіться, що сталося з результатом. І тут усе гаразд? Подивіться на наступне рішення. Чи обрано правильний інструмент? Подивіться на аргументи та результат. Чи все ще правильний стан? Продовжуйте, поки не натрапите на першу ситуацію, коли все відхиляється від ваших очікувань.
На папері це звучить просто, проте люди забувають про це, тому що кінцева відповідь знаходиться прямо перед ними, і зазвичай її найлегше звинувачувати.
Оперативність спостережень за всім процесом
Агенти стають все складнішими. MCP надає їм більше інструментів, багатоагентні схеми дозволяють делегувати завдання та передавати їх, маршрутизатори на льоту обирають моделі, а довготривалі робочі процеси забезпечують постійний стан, можливість повторних спроб та продовження роботи. Схвалення людини може знаходитися посеред виконання завдання, а агенти, які працюють у браузері чи на комп’ютері, можуть змінювати системи значно поза межами чату. Кожен з цих факторів робить агентів більш здатними, але водночас підвищує ризик помилок, оскільки кожен компонент повідомляє про успіх.
Саме тому можливості спостереження мають виходити за межі метрик ШІ. Важливими є затримки, кількість токенів, помилки та витрати, і панель керування обов’язково має попереджати, коли агент застрягає у циклі та спалює кредити API о 2 годині ночі. Проте ці показники переважно вказують лише на те, чи працює система. Багатокроковий агент також потребує способу підтвердження того, що процес, який через нього проходить, продовжує відповідати завданню користувача.
На практиці це означає відстеження початкової мети, ключових обмежень, інструментів та моделей, які фактично використовувалися, стану, який передавався між кроками, та кінцевого результату. Якщо результат є неправильним, ви повинні мати змогу прослідкувати шлях назад до першої точки, де стан відхилився від реальності. Завдяки цій здатності проблемна робота перетворюється на звичайну інженерну проблему, яку можна дослідити, відтворити та протестувати. Без неї ви просто дивитеся на кінцеву відповідь та здогадуєтесь, яка частина системи зламалася раніше.
Пов’язана література
- Практичні нотатки: Створення агента для кодування в приватній хмарі: OpenCode + локальний LLM — Детальний посібник з практичних нотаток щодо створення агента для кодування в приватній хмарі: OpenCode + локальний LLM, включаючи контракти, перевірки та шаблони коду для команд, які використовують цю схему.