RAG як cargo cult: ти ставиш його, бо інші ставлять, не тому, що тобі потрібно. Я плачу

1955 рік, кімната без вікон у лабораторії Вестерн Резерв у Клівленді. Чотири людини — Аллен Кент, Меделін Беррі, Фред Люрс і Джеймс Перрі — сидять над котушками магнітної стрічки й перфокартами і намагаються виміряти одну просту річ: коли машина шукає документи, наскільки добре вона шукає. Вони вигадують два числа, які переживуть їх усіх. Recall — скільки потрібного ти витяг із усього потрібного. Precision — скільки з витягнутого справді потрібне. І того ж дня народжується закон, від якого інженерія не відкараскається сімдесят років: щоб не пропустити жодного релевантного документа, ти неминуче втягуєш купу сміття. Підкрутиш recall — провалиться precision. Підкрутиш precision — щось загубиш. Ножиці. Завжди ножиці.

Тримайте це число — 1955 — у голові. Бо за сімдесят років по тому я сидів над трьома своїми продуктами на LLM, у кожен із яких хтось дбайливо вмонтував retrieval-шар, і виявив, що інженери все ще бояться не того ворога. Вони досі бояться, що загублять сигнал у шумі. А справжня біда виявилась рівно протилежною: мій акуратний, високоточний пошук годував модель отрутою — отрутою з ідеальним рейтингом свіжості, бездоганною етикеткою і високим retrieval-скором. Виглядала як їжа. Труїла як їжа.

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

RAG як архітектурний рефлекс оформився між 2020 і 2022 роками — у часи GPT-3 із чотиритисячним токеновим вікном, коли запхати навіть середній документ у контекст фізично не виходило. Тоді retrieval був не звичкою, а необхідністю: треба знайти правильний шматок, бо цілого не вмістиш. Але в 2024–2025 роках вікна пробили позначку 200k, бенчмаркова хвиля — Databricks, Stanford, SIGIR, Adobe, Chroma — задокументувала «гниття контексту» як самостійний феномен, а Gemini 1.5 Pro продемонстрував мільйонний контекст на живих даних. Операційна система, під яку писали RAG-за-замовчуванням, змінилась. Проблема не в тому, що RAG поганий. Проблема в тому, що 2022 рік закінчився, а Сергієва схема на дошці — ні.

Сергій, який малює одну й ту саму схему

У кожній AI-команді є свій Сергій. Мій — збірний, але ви його впізнаєте з першого погляду на дошку. Технічний лід, відкриває LinkedIn як requiem, на будь-який продукт із LLM рефлекторно малює маркером одне й те саме: користувацький запит → embeddings → векторна база → top-k chunks → промпт. Він малює цю схему ще до того, як хтось у кімнаті спитав, скільки в продукті взагалі тих даних і чи влазять вони цілком у контекстне вікно. Питати про обсяг даних перед тим, як намалювати retrieval, для Сергія — те саме, що питати про діагноз перед тим, як виписати ліки: технічно правильно, але якось неспортивно.

Для Сергія RAG — не інструмент. Це обряд. Векторна база в стеку — як краватка на співбесіді: ніхто не питає, навіщо вона, але без неї ти виглядаєш несерйозно.

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

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

Двоє людей сидять на потрібних даних і тонуть

Є сцена, яка переслідує мене щоразу, коли я відкриваю дашборд retrieval-метрик. «Вся президентська рать», 1976 рік. Вудворд і Бернстайн у читальному залі Бібліотеки Конгресу, перед ними стіл, завалений формулярами видачі книг — паперовими картками, на яких записано, хто що замовляв. Вони шукають слід Говарда Ганта. І оператор Гордон Вілліс робить те, через що ця сцена увійшла в історію кіно: камера повільно, безжально повзе вгору. Стіл із двома постатями зменшується. Проявляється весь читальний зал. Потім увесь поверх. Потім купол ротонди, під яким ці двоє — дві крапки на дні мармурового колодязя. (Камеру тягнув угору винч із кабелем, закріплений просто в куполі Бібліотеки; платформа на блоках так налякала чиновника, що дозвіл на зйомку відкликали за сорок вісім годин до неї — і повернули лише після панічних дзвінків нагору.)

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

Це і є RAG, доведений до межі. І тут починаються числа, від яких Сергієва краватка трохи затягується на горлі.

Стенфордська праця «Lost in the Middle» (Liu та колеги, TACL, 2024) виміряла те, що кіношники інтуїтивно зняли за п'ятдесят років до того. Коли релевантна інформація лежить у середині контексту, а не на початку чи в кінці, точність моделі провалюється. Крива виходить U-подібна: модель пам'ятає, що було спершу, чіпляється за те, що в кінці, і провалюється в усе, що посередині. На multi-document QA падіння — понад двадцять відсоткових пунктів. А ось деталь, яка має змусити Сергія опустити маркер: у крайньому випадку GPT-3.5 із доступом до документів падав нижче за свій же результат у режимі closed-book — 56,1%, тобто гірше, ніж коли в нього взагалі не було жодних документів, тільки питання. Дайте моделі дані — і вона стане дурнішою, ніж була порожня. Це ефект самої архітектури уваги. Жоден реранкер цього не лагодить, бо ламається не пошук. Ламається читання.

Випадковий шум лікує. «Схоже» — труїть

Тепер найгарніший цвях. Якщо ви досі думаєте, що рішення — це «знайти ще точніше, ще релевантніше», SIGIR 2024 має для вас холодний душ.

Праця з прекрасною назвою «The Power of Noise» (Cuconasu та колеги) зробила те, що нормальній людині на думку не спаде: накидала в промпт RAG випадкових, абсолютно нерелевантних документів. Сміття. Шуму. І точність LLM піднялася — до тридцяти п'яти відсотків. А документи з найвищим retrieval-скором, ті, які ваш дорогий ретрівер гордо ставить на перше місце, бо вони «схожі» на запит, але лише дотично релевантні — саме вони шкодили найсильніше. Тобто ретрівер працював як офіціант, що несе найгарніше блюдо найпершим — і саме воно отруєне.

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

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

Тоді я й почав підозрювати, що лагодив не те. Бо в усіх трьох моїх продуктах ретрівер працював. Recall був прекрасний. Він знаходив. Він просто знаходив отруту — і ставив її першою в чергу, бо вона найкраще збігалася за вектором.

Контраргумент, якого я не вимкну

Зупиніться. Перш ніж внутрішній Сергій закипить, дайте йому слово — бо він частково правий, і важливо розуміти, де саме. Для справді великих динамічних корпусів RAG незамінний. Юридична фірма з мільйоном прецедентів, що оновлюються щотижня. Медична база, куди щодня падають нові дослідження. Корпоративна вікі на 40 тисяч сторінок, з якої кожен відділ читає свою третину. Там retrieval — не краватка, а зябра: без нього модель просто не дихає. Проблема не в RAG. Проблема у рефлексі — у привичці малювати стрілочку до векторної бази раніше, ніж хтось виміряв корпус і сказав уголос: «Стривайте, тут двісті сторінок».

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

Маркетинговий слайд проти реальності: де саме все тоне

Індустрія продає вам один трюк і називає його доказом. Він зветься «needle in a haystack»: ховаєш у мільйоні токенів один підкинутий рядок — «магічне число дня — 7» — і просиш модель його знайти. Gemini 1.5 Pro дає на цьому 99,7% recall. Прекрасний слайд. Його малюють на кожній презентації 1M-контексту як обіцянку, що тепер RAG не потрібен — просто запхай усе у вікно. Це як рекламувати автомобіль за результатом тесту, у якому він стояв на місці із заглушеним двигуном.

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

Adobe Research зробили з цього строгий бенчмарк — NoLiMa (ICML 2025): пошук без буквального збігу слів, тобто реальний кейс, а не циркове «знайди точну фразу». На 32k токенів десять-одинадцять моделей упали нижче половини від свого ж сильного короткого бейслайну. Навіть найкращий GPT-4o провалився з майже ідеальних 99,3% до 69,7%. На синтетичному needle-тесті довгий контекст блищить. На реалістичному семантичному пошуку — тоне. Різниця між цими двома цифрами і є ширина прірви між слайдом і продом.

А Chroma у «Context Rot» (Hong, Troynikov, Huber, липень 2025) прогнали 18 моделей — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — і знайшли «гниття контексту»: продуктивність падає зі зростанням довжини входу навіть на тривіальних задачах. Один дистрактор уже знижує точність. Кілька — компаундять провал. Але найруйнівніша деталь ось яка: моделі працювали краще на перетасованому, безладному стозі сіна, ніж на логічно зв'язному. Тобто акуратна, структурована подача даних, та сама, якою пишається «правильний» RAG, місцями шкодить більше за хаос. Ви платите інженеру за те, щоб він навів лад у даних, а модель воліла б, щоб він просто висипав їх на підлогу.

Зведу це в одну таблицю, бо інакше в неї не повірять.

Що показав бенчмарк	Маркетинговий слайд	Реальність	Джерело
Recall на «голці в копиці» (1 факт)	99,7%	~60% на багатофактному пошуку	Gemini 1.5 Pro / огляд бенчмарків
Пошук без збігу слів, 32k токенів	99,3%	69,7% (GPT-4o); 10–11 моделей <50%	NoLiMa, ICML 2025
Доступ до документів vs closed-book	«більше даних = краще»	GPT-3.5 падав нижче 56,1% без даних	Lost in the Middle, TACL 2024
Додати випадковий шум у промпт	«шум — ворог»	+до 35% точності	The Power of Noise, SIGIR 2024
Логічно зв'язний контекст	«структура допомагає»	shuffled > coherent	Context Rot, Chroma 2025

П'ять рядків. У кожному маркетинг каже одне, а вимірювання — протилежне. І в жодному рядку проблема не зветься «поганий пошук».

Точка насичення: модель ламається раніше за свій рекламний ліміт

Databricks (Leng, Portes, Havens, Zaharia, Carbin, серпень 2024) протестували RAG на чотирьох датасетах і знайшли те, що я назвав би комерційною таємницею галузі: довший контекст не дає рівномірного приросту. У кожної моделі є точка насичення, після якої якість падає — і ця точка раніша за рекламований ліміт контексту. Mixtral-instruct ламається після 4k токенів. DBRX-instruct — після 8k. Claude-3-sonnet і GPT-4-turbo — після 16k. Llama-3.1-405b — після 32k. GPT-4-0125-preview — після 64k. Вам продають вікно на 200k, а корисно працює воно до 16k. За решту 184k ви платите як за житлову площу, а живете в передпокої.

Але коронний доказ, що проблема не в retrieval, — це як саме моделі ламаються. Claude-3-sonnet при зростанні контексту починає масово відмовляти, посилаючись на copyright: частка відмов зросла з 3,7% при 16k токенів до 49,5% при 64k. Майже половина запитів. Вдумайтесь: потрібний шматок лежить у вікні, ретрівер спрацював бездоганно, дані на столі — а модель просто відмовляється їх використати, бо їй здалося, що це порушує авторські права. Mixtral у тих самих умовах видавав повторювані китайські ієрогліфи. DBRX ігнорував питання і тупо переказував контекст, як школяр, що не читав параграф, але переписав його з дошки і сподівається, що проскочить.

Жоден із цих зривів не лагодиться кращим пошуком. Ви можете мати ідеальний, богоподібний retrieval — і Claude однаково скаже вам «вибачте, copyright» у половині випадків. Сергій принесе ще один реранкер. Реранкер не вміє вмовляти модель перестати боятися уявних юристів.

Чому Сергій ніколи не вимкне RAG сам

Тут варто спитати: якщо все це виміряно й опубліковано, чому RAG ставлять рефлекторно? Відповідь не технічна. Вона економічна.

Глобальний ринок RAG оцінили приблизно в 1,2 млрд доларів у 2023-му з прогнозом до 11 млрд до 2030-го — складний річний приріст близько 49%. Великі підприємства дали понад 72% частки. Навколо retrieval виросла ціла індустрія: вендори векторних баз, консультанти, автори курсів, продавці «обов'язкового» шару. На простоті ніхто не заробляє. Не можна виставити рахунок за речення «слухайте, у вас тут даних на три сторінки, запхайте їх у промпт і не вигадуйте» — за таку пораду консультанта проводжають до дверей, а за діаграму з векторною базою дають контракт на рік.

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

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

А Барнетт із колегами (CAIN 2024, Лісабон) у праці «Seven Failure Points When Engineering a RAG System» додали ще й найгірше для Сергія: RAG узагалі не можна «спроєктувати правильно» наперед. Із семи формалізованих ними точок зриву майже немає «погано знайшли» — домінують відсутній матеріал, неправильна специфічність, невитягнута відповідь при наявному контексті (через шум або конфлікт) і проігноровані інструкції формату. Коректність RAG, кажуть автори, виявляється лише в експлуатації й еволюціонує в часі. Тобто шар, який Сергій малює як готову архітектуру за п'ять хвилин на дошці, насправді — це сім нових способів зламатися, які ви виявите вже на проді, на живих користувачах. П'ять хвилин на дошці — і сім засідок у проді: курс обміну, від якого нудить.

Інструмент: матриця, яку я тепер вішаю над Сергієм

Перш ніж хтось у моїй команді намалює стрілочку до векторної бази, він заповнює цю матрицю. Не «який ретрівер вибрати» — а «чи потрібен він узагалі». Borges у «Вавилонській бібліотеці» (1941) описав нескінченну бібліотеку, що містить усі можливі книги, отже й усю істину — похованою під безмежжям беззмістовних перестановок тих самих літер; бібліотекарі божеволіють не від нестачі інформації, а від її повноти. 1M-контекст без потреби — це і є той Вавилон: ти отримав усю істину світу і саме тому не знайдеш у ній жодної. Матриця нижче — щеплення від цього божевілля.

Сигнал у твоєму продукті	RAG, ймовірно, ЗАЙВИЙ	RAG, ймовірно, ПОТРІБЕН
Обсяг корпусу	< 100k токенів — влазить у вікно	Мільйони документів, фізично не влазить
Динаміка даних	Статичні, рідко змінюються	Оновлюються щогодини/щодня
Тип запиту	Один-два факти, локальна відповідь	Синтез із багатьох розкиданих джерел
Симптом галюцинацій	Модель плутає «схоже» з «правильним»	Модель не має доступу до факту взагалі
Природа проблеми	Scope / дані / постановка питання	Справжня відсутність знань у вікні
Що зробити спершу	Викинути RAG, покласти все в промпт, перевірити	Будувати retrieval — але міряти operational, не at-design

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

Що я зробив із трьома продуктами

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

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

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

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