Більшість інженерних команд досі оцінюють ШІ-агентів так само, як перевіряють домашні завдання з математики. Вони дивляться на кінцевий результат. Якщо відповідь правильна, вони дають зелене світло релізу та рухаються далі. Це небезпечний шлях скорочення. Правильна відповідь може приховувати глибоко зламану систему.
Справжня історія криється в шляху, яким агент дійшов до результату. Цей шлях називається траєкторією агента. Він включає кожен виклик інструменту, кожне рішення щодо маршрутизації, кожну паузу, коли агент зупиняється, щоб переосмислити дії. Ви можете уявити це як шлях із крихт хліба, залишених агентом. І якщо ви перевіряєте лише пункт призначення, ви пропускаєте всі попереджувальні знаки, розкидані вздовж шляху.
Проблема заплутаних шляхів
Агент може прийти до правильної відповіді, поводячись при цьому як п'яний водій. Він хаотично перемикається між неправильними інструментами, повертається до маршрутизатора та ходить колами через надлишкові міркування, перш ніж зрештою випадково натрапити на щось правильне. Користувач бачить чистий результат. Але за лаштунками система марнує ресурси та накопичує ризики.
Як цей безлад виглядає на практиці?
По-перше, це надлишковий виклик інструменту. Агент робить запит до вашої бази даних клієнтів, отримує результат, забуває про нього через п'ять секунд і знову запитує той самий запис із ідентичними параметрами. Це не проблема даних. Це проблема траєкторії. Агент не зміг зберегти стан, тому повторює роботу.
Потім іде патерн «спочатку неправильний інструмент». Агент для написання коду може намагатися шукати в інтернеті визначення функції, яка вже є в локальному репозиторії. Або агент підтримки може звернутися до billing API, коли запитання користувача чітко потребує інструмента налаштувань облікового запису. Кожен неправильний вибір спалює токени, збільшує затримку та підвищує ризик того, що ліміти контексту будуть вичерпані ще до початку основної роботи.
Цикли маршрутизації — це ще один тривожний сигнал. Вузол прийняття рішень не може визначитися. Він надсилає завдання на гілку А, передумує, повертає його, пересилає на гілку Б, а потім без причини спрямовує через загальний вузол відкату (fallback node). Кожен цикл додає мережевий стрибок (network hop) і ще один рівень плутанини в майбутній лог налагодження.
Нарешті, це повторний аналіз. Агент продовжує щоразу виводити той самий висновок на кожному етапі замість того, щоб вважати його остаточним. Це схоже на те, як тесля десять разів вимірює дошку перед кожним розпилом. Першого вимірювання було достатньо. Наступні дев'ять — це марні рухи.
Ці зайві кроки мають реальні наслідки. Затримка накопичується. У синхронному чат-інтерфейсі зайві три секунди здаються цілою вічністю. У масштабах системи ці секунди перетворюються на тисячі доларів витрат на обчислення. Ризик збою також зростає. Кожен непотрібний стрибок — це ще один шанс для того, щоб зовнішній API перейшов у таймаут, вікно контексту переповнилося або виникла стан гонитви (race condition). І коли щось таки зламається, успіхів у налагодженні трасування, яке схоже на спагеті. Ви витратите години, намагаючись відтворити, чому агент зробив сьомий крок, лише щоб зрозуміти, що сьомого кроку взагалі не мало бути.
Що насправді означає конвергенція
Якщо траєкторія — це шлях, то конвергенція — це міра його ефективності. Конвергенція показує, наскільки близько агент дотримується найкоротшого життєздатного маршруту між запитом користувача та правильним вирішенням.
Це не те саме, що точність (accuracy). Точність — це грубий інструмент. Вона запитує, чи є кінцевий стан правильним. Конвергенція запитує, чи був шлях раціональним. Агент із високою точністю та низькою конвергенцією — це проблема, що прикидається успіхом. Агента з високою конвергенцією та середньою точністю зазвичай легше виправити, оскільки його міркування чіткі, а помилки локалізовані.
Ви можете розрахувати приблизний показник конвергенції, порівнявши кроки, які агент робить насправді, із найкоротшим шляхом, визначеним вами для цього класу завдань. Якщо стандартний запит на повернення коштів має потребувати рівно три виклики інструментів, а агент використав дев'ять, ваш коефіцієнт конвергенції падає. Ви можете уточнити це, надавши різні ваги різним типам марнотратства. Один неправильний виклик інструменту може коштувати дорожче, ніж один надлишковий виклик, залежно від затримки та ціни інструмента. Цикл маршрутизації, який не приносить жодної користі, може мати найважче покарання, оскільки він сигналізує про архітектурну