Агенти ШІ рідко аварійно завершують роботу. Вони дають збій непомітно — і дослідження пояснюють чому

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

Збій, який виглядає як успіх

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

Розгляньмо поширений випадок. Інструмент для роботи з прогнозом погоди дає збій і повертає текст «служба недоступна» у відповіді, яка загалом має звичайний вигляд. Модель читає цей текст, чемно перепрошує або, що гірше, складає правдоподібний прогноз на основі навчальних даних. Користувач отримує зв’язну відповідь. У журналах сервера запит позначено як успішний, а затримка — як звичайна. У традиційній системі моніторингу ніщо не фіксує, що щось пішло не так.

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

Це не новий тип проблеми, а лише загострена версія давньої. У 2015 році інженери Google на чолі з D. Sculley описали «прихований технічний борг» у системах машинного навчання. Вони стверджували, що більшість ризиків у виробничій системі машинного навчання пов’язана не з кодом моделі, а із залежностями від даних, конфігурацією та допоміжним кодом, який усе поєднує. Агенти додають до цього переліку новий рівень. Запити й описи інструментів — це конфігурація, яка може змінити поведінку системи без жодних змін у її коді.

Невеликі правки, значні наслідки

Наскільки важливою може бути невелика зміна запиту? У статті, представленій на ICLR 2024, Мелані Склар із University of Washington та її колеги змінили лише форматування запитів із кількома прикладами: роздільники, інтервали й регістр літер. Зміст залишився незмінним. Однак точність виконання того самого завдання для LLaMA-2-13B усе одно відрізнялася на величину до 76 пунктів. Ця чутливість не зникла ні зі збільшенням моделей, ні з додаванням прикладів, ні після донавчання на інструкціях.

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

Те саме стосується описів інструментів, які модель читає як частину запиту. У посібнику Anthropic зазначено, що визначення інструментів потребують «не меншої уваги до розробки запитів», ніж основний запит. У ньому описано агента для написання коду, який постійно помилявся у відносних шляхах до файлів. Коли інструмент налаштували так, щоб він вимагав абсолютних шляхів, модель почала користуватися ним без помилок. Модель не змінилася. Змінився лише опис, який вона читала.

Один успіх мало що доводить

Інший напрям досліджень присвячений стабільності результатів. Бенчмарк τ-bench, опублікований Шунью Яо та його колегами із Sierra і представлений на ICLR 2025, моделює розмови зі службою підтримки, у яких агент має користуватися інструментами й дотримуватися бізнес-правил. Автори запровадили метрику pass^k: імовірність того, що агент правильно виконає те саме завдання в усіх k спробах.

Результати були невтішними. Агент на основі GPT-4o виконав близько 61% завдань у роздрібній торгівлі з першої спроби. Коли він мав успішно виконати те саме завдання вісім разів поспіль, показник упав приблизно до 25%. Демонстрація, яка спрацьовує один раз, мало що говорить про поведінку системи під час тисячного запуску.

Де дають збій системи з багатьма агентами

Тепер багато команд об’єднують кілька агентів у ланцюжок: один планує, інший виконує, а третій перевіряє роботу. У дослідженні 2025 року, проведеному в UC Berkeley, «Чому дають збій системи LLM із багатьма агентами?», проаналізовано понад 1600 анотованих трас виконання у семи популярних мультиагентних фреймворках. Автори на чолі з Мертом Джемрі створили таксономію MAST із 14 типами збоїв у трьох групах: проблеми проєктування системи, неузгодженість між агентами та перевірка завдань.

Головний висновок авторів полягає в тому, що багато збоїв спричинені конструкцією системи, а не лише обмеженнями базової моделі. Агенти ігнорують призначені їм ролі, втрачають нитку розмови або оголошують завдання виконаним, не перевіривши результат. Такі збої не залишають запису про помилку. Їх можна побачити, лише якщо хтось здатен прочитати, що саме зробив кожен агент. У матеріалі Unite.AI про парадокс мультиагентних систем викладено споріднену думку з погляду архітектури: додавання агентів може посилити ранню помилку, а не нівелювати її.

Як зробити невидиме видимим

Інженерний підхід запозичено з розподілених систем, де запити вже давно відстежують у багатьох сервісах за допомогою техніки, що називається трасуванням. У системах із агентами кожен запит користувача стає трейсом, а кожен виклик моделі чи інструмента — «спаном» у його складі. У спані фіксуються вхідні дані, результат, використані токени та тривалість виконання. Організація, що розробляє галузеві стандарти для цієї сфери, OpenTelemetry, готує спільні правила для спанів генеративного ШІ. Станом на 2026 рік ці правила все ще мають статус тих, що перебувають у розробці, тож назви атрибутів іще можуть змінитися.

Кілька проєктів із відкритим кодом, зокрема Langfuse, Arize Phoenix і AcruxCore, уже застосовують цей підхід. Їхній вихідний код відкритий, тож команди можуть перевірити, як зберігається трейс, і запускати програмне забезпечення на власних серверах. Ці проєкти записують виклики моделей та інструментів як спани в межах одного трейсу й дають командам змогу додавати до них оцінки якості. Вибір інструмента менш важливий за одну деталь: у спані інструмента має фіксуватися те, що він насправді повернув, а не лише те, чи успішно виконано мережевий запит. Інакше описаний вище збій інструмента погоди залишиться непомітним.

Галузеві опитування свідчать, що трасування вже стало поширеним, але тестування відстає. У звіті LangChain «Стан інженерії агентів» опитали 1 340 фахівців наприкінці 2025 року. Якість була найчастіше згадуваною перешкодою для запуску агентів у виробниче середовище: її назвали 32% респондентів. 89% організацій повідомили, що певною мірою забезпечують спостережуваність своїх агентів, а 62% ведуть детальне трасування окремих кроків і викликів інструментів. Лише 52,4% проводили офлайн-оцінювання на тестових наборах, а 37,3% оцінювали трафік у реальному часі. Більшість команд можуть бачити, що робили їхні агенти. Менше команд перевіряють, чи правильно ті діяли.

Масштабне оцінювання відповідей

Трейси показують, що сталося. Але вони не свідчать, чи була відповідь якісною. Перевіряти кожну розмову вручну неможливо в масштабах великих обсягів, тож команди дедалі частіше використовують для оцінювання другу модель — підхід, відомий як «LLM-суддя». У статті для NeurIPS 2023 Ліанмінь Чжен і його колеги виявили, що потужні моделі, як-от GPT-4, збігалися з людськими оцінками в понад 80% випадків — приблизно так само часто, як і люди погоджуються між собою.

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

Від практики до політики

Вимірювання стає також вимогою у сфері врядування. Національний інститут стандартів і технологій США опублікував Рамкову систему управління ризиками ШІ у січні 2023 року. Одна з чотирьох її основних функцій — «Вимірювання» — закликає організації кількісно оцінювати ризики ШІ, відстежувати їх і документувати з часом. Для агента трейси й оцінки результатів є саме тими доказами, яких вимагає ця функція.

Що команди можуть зробити вже зараз

Це перегукується з думкою, висловленою на цій платформі: справжнє випробування агентного ШІ — його надійність. Наведені вище дослідження доповнюють цю думку деталями щодо вимірювання: надійність — це не властивість, яку можна оцінити один раз, а діапазон, який потрібно постійно вимірювати.

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

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

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