Агенти ШІ провалюють очевидні задачі: це не міркування, а пошук — 49% і 67% за даними Anthropic

Агент, який уміє підсумовувати довгий PDF, правильно викликати API й виконувати багатокроковий процес, усе одно пропустить строк повернення коштів, захований у документі з політиками, візьме не той SKU товару або забуде результат інструмента, отриманий десять секунд тому. У дописі, опублікованому на DEV Community, розробник Ларс Вінстанд доводить, що більшість багів «агент дурний» — це не збої міркування, а невдалі вибірки даних, і це змінює те, з чого варто починати налагодження.

Збій виглядає як міркування, але ним не є

Схема, яку описує Вінстанд, знайома з ботів підтримки та внутрішніх копілотів: агент дає раду складним частинам, а потім спотикається на одному очевидному кроці. Це відчувається як погане міркування, хоча зазвичай одного конкретного факту не було в один конкретний момент. «Це не збій міркування. Це невдала вибірка», — пише він.

Цифри Anthropic: на 49% і 67% менше промахів

Аргумент спирається на дослідження Contextual Retrieval від Anthropic: коли фрагменти отримують контекст і комбінуються із семантичним пошуком та Contextual BM25, кількість невдалих знаходжень зменшується на 49%. Додавання етапу реранкінгу піднімає цей показник до 67%. Стандартний RAG — базовий поділ на фрагменти з чисто семантичним пошуком — порівнянної цифри не наводить.

Довгого контексту й векторного пошуку замало

Дві поширені передумови не витримують перевірки. По-перше, якщо віддати моделі всю документацію, це не гарантує, що вона скористається потрібним уривком: через ефект «Lost in the Middle» моделі часто працюють гірше, коли потрібний факт лежить посеред довгого запиту. По-друге, чистий embedding-пошук програє там, де потрібна буквальна точність — ідентифікатори замовлень, назви політик, SKU товарів, назви робочих процесів, коди помилок і номери тікетів. Тому гібридний пошук — ключові слова, семантика й реранкінг разом — надійніший у реальних системах.

Спершу налагоджуйте шар пошуку

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

Останній пункт — архітектурний: якщо база знань цілком уміщається в контекст (приблизно до 200 000 токенів), Anthropic радить узагалі відмовитися від RAG, а кешування запитів може зменшити затримку більш ніж удвічі та витрати до 90%. Правило автора: коли агент провалює очевидну задачу, спитайте, що повернув пошук, де з'явився факт, чи існував пошук за точним збігом, чи працював реранкінг і чи побачив агент потрібне в придатній формі.