Чому AI-агент помиляється: винен пошук, а не модель

Stanford і Together AI перевірили шість чат-ботів на 2100 питаннях: понад 70% помилок дає пошук, а не міркування. Що це означає для вашого RAG-пайплайна.

Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai. Коли агент дає неправильну відповідь, перша реакція бізнесу — взяти розумнішу модель. Дослідження Stanford і Together AI на 2100 питаннях показало інше: понад 70% помилок виникають на кроці пошуку, а не міркування. Коли модель знаходить правильне джерело, вона зазвичай правильно витягує з нього факт. Уся складність — взагалі потрапити на потрібний документ.

TL;DR (за 30 секунд)

Помилка агента найчастіше стається до генерації. Агенту принесли не той документ, і він чесно на ньому відпрацював.
Stanford разом з Together AI прогнали шість комерційних чат-ботів через 2100 питань по свіжих новинах BBC протягом 14 днів. Формулювання авторів: retrieval, а не reasoning, дає понад 70% усіх помилок.
Розбивка причин: провал пошуку — 38,8%, знайдене «про ту саму тему, але не про те» — 32,7%.
Найкращі системи дають понад 90% на питаннях із варіантами відповіді. У вільній формі точність просідає на 11–13 відсоткових пунктів, по всій когорті — на 16–17.
Найнижча точність — на хінді (у середньому 79% проти 89–91% в інших мовах, той самий формат із варіантами). Причина не в мовних здібностях моделі, а в перекосі індексу: на хінді-запити моделі цитують англомовну «Вікіпедію» частіше за будь-яке місцеве видання.
Варто підкинути в запит одну помилкову передумову — і точність падає з 88–96% до 19–70%, навіть коли системі прямо дозволяли відповісти «недостатньо інформації». Найвразливіша модель приймала вигаданий факт на віру у 64% випадків.
Практичний висновок: перш ніж платити за дорожчу модель, витратьте той самий бюджет на пошук. Він окупається краще.

2100 питань, шість чат-ботів, чотирнадцять днів

У травні 2026 року група Мірача Сузгуна зі Stanford разом із Together AI виклала роботу «Evaluating Commercial AI Chatbots as News Intermediaries» (arXiv:2605.22785). У липні її розібрав The Batch під назвою Web Retrieval Flusters LLMs.

Дизайн простий і чесний. Чотирнадцять днів поспіль, з 9 по 22 лютого 2026 року, автори брали свіжі матеріали BBC News із шести регіональних служб і генерували з них питання про події, які сталися буквально кілька годин тому. Вийшло 2100 питань. Далі шість чат-ботів із увімкненим веб-пошуком — Gemini 3 Flash і Pro, Grok 4, Claude 4.5 Sonnet, GPT‑5 і GPT‑4o mini — намагалися на них відповісти.

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

Перший результат виглядає заспокійливо. На питаннях із п’ятьма варіантами відповіді Gemini 3 Flash дав 95,6%, Grok 4 — 95,0%, Gemini 3 Pro — 93,7%, Claude 4.5 Sonnet — 90,4%. GPT‑5 набрав 85%, GPT‑4o mini — 69%.

Але потім автори прибрали варіанти відповідей і попросили відповісти своїми словами. Найкращі системи втратили 11–13 відсоткових пунктів, по всій когорті просідання склало 16–17. Тобто помітна частина тих «дев’яноста з гаком відсотків» була не знанням, а вгадуванням правильного варіанта зі списку — приблизно те саме, чим займається школяр на тесті, коли матеріал знає приблизно.

Головна цифра: понад 70% помилок — це пошук

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

Формулювання з абстракту статті звучить так: retrieval, а не reasoning, дає понад 70% усіх помилок. Коли моделі вдається дістати правильне джерело, вона зазвичай правильно витягує з нього відповідь. Уся складність — узагалі потрапити на потрібне джерело.

The Batch наводить розбивку по двох найбільших категоріях:

Причина помилки	Частка
Провал пошуку — потрібного матеріалу не знайшли взагалі	38,8%
Знайшли джерело по темі, але з іншими деталями — воно не відповідає на конкретне питання	32,7%
Решта причин разом — розуміння, хронологія тощо (за відніманням, у джерелі окремо не наведено)	~28,5%

Друга категорія — це не «нічого не знайшов». Це «знайшов щось розумне і релевантне, тільки не те». Автори описують такі джерела як «smart but wrong» — розумні, але неправильні. Ззовні відповідь виглядає обґрунтованою: агент цитує реальний документ, документ справді по темі, у ньому справді є цифри. Просто цифри стосуються іншого періоду, іншого регіону або іншого об’єкта.

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

Чому «візьмемо розумнішу модель» не спрацьовує

Стандартна реакція на помилку агента: модель дурна, беремо старшу. Дані статті кажуть, що ці гроші здебільшого підуть повз проблему.

Логіка тут майже арифметична. Відповідь агента на питання, якого не було в його навчальних даних, тримається на трьох кроках: отримати нормально сформульоване питання, знайти релевантний документ, витягти з нього факт. Модель відповідає за третій крок і трохи за перший. Понад 70% помилок сидять на другому.

Апгрейд моделі покращує те, що і так працює на 90+ відсотків, і не чіпає те, що ламається.

Автори роблять із цього прямий висновок: покращення пошуку, найімовірніше, дасть більший приріст якості, ніж нарощування параметрів моделі — принаймні там, де запити стосуються актуальної інформації. Три напрямки, які вони називають: повнота індексу (які документи взагалі потрапляють у пошук), ранжування джерел (у якому порядку знайдене лягає перед моделлю) і обробка запитів не англійською.

Історія з хінді тут показова. На тих самих питаннях із варіантами відповіді кожна модель показала найгіршу точність саме на хінді — у середньому 79% проти 89–91% в інших мовах. При цьому відповідаючи на запити хінді, моделі цитували англомовну «Вікіпедію» частіше, ніж будь-яке індійське видання. Це не «модель гірше знає хінді». Це індекс, зібраний англомовним світом для англомовного світу, і пошук, який на неанглійському запиті зісковзує на англомовне джерело. Абсолютно та сама механіка спрацює на вашій українській базі документів, якщо векторна модель і пошуковий стек налаштовані за замовчуванням.

П’ять способів принести агенту не той документ

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

1. Знайшов релевантне, але не потрібне

Та сама категорія на 32,7%. Агент шукає умову договору про терміни оплати, а індекс віддає загальну сторінку розділу «Умови співпраці». Тема збігається, конкретики немає. Або запитали про матеріал, а знайшовся профіль його автора: слова ті самі, об’єкт інший.

Механізм простий: релевантність темі й релевантність питанню — різні речі, а більшість пошукових конфігурацій за замовчуванням оптимізує першу.

2. Переплутана сутність

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

Ця помилка найважче ловиться на перегляді, бо в тексті все правда. Неправда тільки прив’язка.

3. Семантична схожість замість точного збігу

Найтиповіша інженерна пастка. Векторний пошук за побудовою шукає «про те саме», а не «саме те». На розмовному запиті це перевага, на точному ідентифікаторі — джерело помилок.

Артикул, номер замовлення, версія документа, номер норми, назва тарифу, дата — це рівно ті сутності, де семантично близький результат є неправильним результатом. І це рівно ті сутності, де ціна помилки найвища. Схожість за змістом перемагає точний збіг, і агент упевнено бере сусідній рядок.

4. Джерело застаріло

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

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

5. Немає стану «не знайшов»

Найархітектурніша з п’яти. Якщо в системі не передбачений дозвіл сказати «доказів недостатньо», вона оптимізується на завершеність відповіді, а не на її достовірність.

У дослідженні цей ефект вимірювали окремо: в запити підкидали одну помилкову передумову — неправильне прізвище, зсунуту дату, вигадану деталь — і додавали варіант «недостатньо інформації для відповіді». Точність упала з 88–96% до 19–70% залежно від моделі. Найвразливіша приймала вигаданий факт на віру у 64% випадків. Тобто дві третини разів система не помітила, що питання побудоване на неправді, і сумлінно шукала підтвердження того, чого не було.

Автори помітили ще й окрему дивину, яку назвали detection-accuracy paradox: найкращий детектор помилкових передумов виявився лише другим за здатністю все-таки дати правильну відповідь. Помітити підступ у питанні та вибратися з нього — це, схоже, дві різні здібності, і одна не тягне за собою другу.

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

Що з цим робити

Порядок нижче — від найдешевшого до найдорожчого у впровадженні.

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

Перевіряти відповідність фрагмента питанню, а не темі. Між «цей текст про терміни оплати» і «цей текст містить відповідь на питання про термін оплати за договором №» — прірва. Реранкер, який оцінює саме друге, знімає більшу частину категорії «smart but wrong».

Hybrid retrieval замість чистих embeddings. Розкладіть навантаження: keyword-пошук (BM25) бере точні ідентифікатори, коди, назви й версії; векторний — розмовні та перефразовані запити; реранкер упорядковує кандидатів; фільтри за метаданими відсікають чужого клієнта, не той період і не ту версію. Це не «покращені ембединги», це розподіл ризиків між механізмами, кожен з яких сильний там, де інший сліпий.

Далі йдуть дві дешеві речі, які чомусь роблять останніми. Свіжість має бути окремим сигналом ранжування: recency scoring плюс політика застарівання, бо документ без дати індексації — це документ без строку придатності. А provenance (джерело, версія, час індексації, позиція у файлі) потрібен на кожному фрагменті: відповідь без валідного посилання просто не повинна доходити до користувача. Це найдешевший спосіб перетворити невидиму помилку на видиму, і його майже завжди відкладають «на потім».

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

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

Логіка та сама, що й у самонавчанні агента: поки результат не можна автоматично перевірити, покращувати нема від чого відштовхуватися.

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

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

Ланцюг, у якому ламається

Якщо звести все до однієї схеми, шлях від даних до відповіді виглядає так:

Джерело → Витяг → Нормалізація → Зберігання → Індексація → Пошук → Реранкінг → Відповідь

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

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

RAG не знімає проблему, а переносить її

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

Сам RAG теж не рятує, він міняє характер помилки. Замість «модель вигадала» ви отримуєте «модель упевнено переказала не той документ». Другу принаймні можна відстежити до конкретного файла, але тільки якщо в системі є provenance, дати й окремі метрики пошуку. Без них ви так само дивитеся на гладкий абзац і не маєте способу перевірити, звідки він узявся.

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

FAQ

Чи вирішує RAG проблему галюцинацій? Ні, RAG змінює її природу. Замість вигаданого факту ви отримуєте реальний факт із неправильного документа. Це краще, бо помилку можна простежити до джерела, але тільки за умови, що кожен фрагмент має provenance — посилання, версію і дату.

Як зрозуміти, що проблема саме в retrieval, а не в моделі? Візьміть кілька десятків запитів, на яких агент помилився, і подивіться, який контекст йому фактично передали. Якщо потрібний документ у контексті був, а відповідь неправильна — це модель. Якщо документа не було або був не той — це пошук. У дослідженні Stanford і Together AI друге склало понад 70% випадків.

Що таке hybrid retrieval і чому недостатньо самих embeddings? Це поєднання keyword-пошуку (BM25) для точних збігів, векторного — для змісту, реранкера — для впорядкування кандидатів і фільтрів за метаданими. Чистий векторний пошук за побудовою знаходить «про те саме», а не «саме те», тому програє на артикулах, номерах, версіях і датах — там, де ціна помилки найвища.

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

Чи можна замінити retrieval великим контекстним вікном? Якщо весь корисний корпус поміщається в контекст — так, і це часто простіше за пайплайн. Межу варто визначати не на око, а вимірюванням: прогнати ту саму задачу на 10, 50, 200 і 500 тисячах токенів і знайти точку, де якість починає падати. Саме вона показує, коли retrieval справді потрібен.

Що робити, якщо запит користувача містить помилкову передумову? Передбачити явний варіант «недостатньо даних» і навчити систему ним користуватися. У дослідженні моделям давали питання з однією невірною деталлю і при цьому додавали відповідь «недостатньо інформації» — точність на такому наборі падала з 88–96% до 19–70%, а найвразливіша модель приймала вигаданий факт на віру у 64% випадків. Без дозволу відмовитися система оптимізується на завершеність відповіді, а не на її правдивість.

Як тестувати retrieval окремо від генерації? Зберіть набір реальних запитів із заздалегідь відомими правильними документами і міряйте, чи потрапляє потрібний документ у top-k видачі. Ця метрика не залежить від моделі, тому показує ефект від змін в індексації, чанкінгу й ранжуванні в чистому вигляді.

Джерела: Suzgun M., Shen E., Bianchi F., Spangher A., Icard T., Ho D. E., Jurafsky D., Zou J. «Evaluating Commercial AI Chatbots as News Intermediaries», arXiv:2605.22785, 21.05.2026; розбір The Batch, «Web Retrieval Flusters LLMs», 24.07.2026.

Опублікував Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai.