Контекстуальне отримання даних для RAG: що приховує показник у 67%, які витрати це супроводжує та коли цей підхід зазнає невдачі.
Контекстуальне отримання даних для RAG: як використання префіксів виправляє відокремлені фрагменти, чому показник 67% враховує три зміни, що економить кешування запитів та коли воно зазнає невдачі.
Джерела: Your RAG Chunk Doesn’t Know Whose Revenue Grew 3% — Contextual Retrieval
«Дохід компанії зріс на 3% порівняно з попереднім кварталом». Векторна база даних може містити тисячі таких речень, і кожне з них є функціонально марним, поки не стане зрозуміло, про яку саме компанію та який квартал йдеться.
Проблема не в моделі, яка формує кінцеву відповідь. Вона полягає у фрагменті тексту, який потрапив до індексу без ідентифікатора. Будь-яка система RAG, побудована на документах, контрактах, технічній документації чи вихідному коді, є вразливою, оскільки ці корпуси тексту повторюють одні й ті самі лінгвістичні шаблони в десятках місць, і це не дає системі знаходження інформації можливості розрізняти ці повтори.
Ліки є дешевими. Їхня ціна вимірюється у доларах за мільйон токенів, і для їх створення потрібне лише одне сформоване речення, написане під час побудови індексу. У тестах Anthropic такий префікс зменшив кількість невдалих пошуків до 67%. Ця цифра у заголовку приховує певну структуру, а випадок використання, обраний для демонстрації, згодом отримав контрприклад. Також існують чотири налаштування, у яких витрати важко обґрунтувати.
Коротко про основну ідею
Коли індекс розділяє документи на частини по кілька сотень токенів, деякі з цих частин втрачають свою тему та часові рамки. Фраза „Дохід зріс на 3%“ не вказує жодної компанії та жодного кварталу, і жодна модель ембеддингу не може це відновити, оскільки ця інформація відсутня в тексті.
Контекстуальне отримання інформації вирішує проблему один раз під час індексації. Моделі мови показують увесь документ разом із одним фрагментом, і вона створює короткий префікс, що складається з п’ятдесяти–ста токенів, у якому вказується, що це за фрагмент, кого він стосується та коли.
У багатьох резюме пропускається другий крок, який є найважливішим. Оновлений текст подається до векторного індексу та індексу BM25 – лексичного ранжеру, який існував ще до використання ембеддингів та знаходить точні слова, а не їхнє значення. Таким чином одна процедура виправляє обидві частини пошукової системи, з витратами, які виникають лише під час індексації, а не за кожен запит.
За даними оцінки Anthropic, лише префікс ембеддингів зменшив кількість невдалих пошуків на 35%. Повна система з використанням BM25 та повторного ранжування зменшила їх на 67%. Кешування запитів робить цей процес дешевшим, оскільки весь документ читається лише один раз, а не з нуля для кожного фрагмента.
Ця техніка не є універсальною, і саме тут вона стає цікавою. По-перше, механізм та сам запит.
Префікс, який надає фрагменту ідентичності
Інтуїція передує механіці. Фрагмент, вирізаний з документа, — це сторінка, вирвана з папки, без заголовка, номера справи чи дати. Якщо читати його окремо, це не дозволить зрозуміти, чия компанія має зростання доходів та коли. Модель для ембеддингу стикається з такою ж порожнечею, тільки не має способу її позначити.
Механізм відновлює відсутній заголовок. Під час індексації модель отримує два вхідні дані — повний джерельний документ та один з його фрагментів, — і має одну місію: написати короткий контекст, який розмістить цей фрагмент у загальному контексті.
Запит від Anthropic поміщається у кілька рядків:
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the
overall document for the purposes of improving search retrieval of the
chunk. Answer only with the succinct context and nothing else.
Якщо застосувати це до прикладного фрагмента, результат може виглядати так: «Цей фрагмент походить із документа SEC щодо результатів діяльності ACME Corp у другому кварталі 2023 року; дохід у попередньому кварталі становив 314 мільйонів доларів». Слідом йде речення про початковий приріст у 3%. Приблизно сто токенів дозволяють перетворити випадковий фрагмент на запис із ключем.
Потім цей доповнений текст записується у два індекси. Один — це індекс вбудовувань (Contextual Embeddings), інший — індекс ключових слів (Contextual BM25). Оскільки назва ACME вказується у кожному фрагменті, BM25 може знайти цю компанію на будь-якій сторінці звіту, тоді як раніше про неї згадувалося лише на титульній сторінці.
Це також не була перша спроба. Anthropic раніше повідомляла про експерименти з узагальненими резюме документів, доданими до фрагментів, які принесли „дуже обмежені результати“, а також про використання HyDE та індексації на основі резюме, які також виявилися не дуже ефективними (Anthropic, вересень 2024 р.). Залишився лише префікс.
Різниця між резюме та префіксом є механічною. Одне резюме є спільним для всіх фрагментів документа, тому воно не може відрізнити фрагмент А від фрагмента Б у межах одного річного звіту, тоді як кожен префікс створюється спеціально для своєї позиції в документі.
Корпуси даних, складені з заявок, контрактів, технічної документації чи кодових баз, де одна мовна структура повторюється в багатьох місцях, — саме там сьогодні загублюються фрагменти. Лише використання префікса для вбудовування даних дозволяє зменшити кількість помилок на 35%, і це лише перший рівень оптимізації.
Сходи всередині одного числа
Часто цитується значення „67%“ як ефект використання однієї лише техніки. Опублікована таблиця показує інші дані, і її краще розглядати як послідовні кроки, а не як один стрибок.
Результати вимірюються як один мінус recall@20 – це частка запитів, у яких правильний фрагмент не потрапив до топ-20. Anthropic називає це показником невдач та наводить його для кодових баз, художньої літератури, статей arXiv та наукових публікацій.
Чотири конфігурації будуються одна на одній:
- Базова конфігурація зі звичайними ембеддингами для сирих фрагментів: 5,7% запитів провалюються.
- Лише з контекстуальними ембеддингами: 3,7%, що на 35% менше завдяки самому префіксу.
- З додаванням контекстуального BM25: 2,9%, що дає загальне зниження на 49%, причому додаткову користь приносить індекс ключових слів.
- З додаванням функції переранжування: 1,9%, саме звідси й походить цифра 67%, завдяки останньому етапу обробки.
Реранкер — це друга модель, яка одночасно аналізує запит та кандидатські фрагменти. Вона працює повільніше, ніж перший етап, але значно точніше. У цьому випадку вона скоротила кількість кандидатів з 150 до двадцяти. Усі чотири показники стосуються найефективнішої конфігурації ембеддингу у тесті — Gemini Text 004, і не є середнім значенням серед усіх моделей ембеддингу, які використовувалися компанією Anthropic.
Цей розбір змінює рішення, а не лише опис ситуації. Команда, яка вже використовує гібридний пошук та реранкінг у промислових умовах, може очікувати, що лише контекстуалізація дозволить досягти показника близько тридцяти п’яти відсотків замість шістдесяти семи, оскільки два інші етапи вже оплачуються. Вважати це одним ефектом — це поширена помилка, а значна частина скорочення походить від стандартних компонентів пошуку, які виконують свою звичайну роботу.
У треді на Hacker News наводиться важлива застереження: ніхто не оприлюднив даних про продуктивність простого алгоритму BM25 без жодної контекстуалізації у тому самому тесті. Без цих даних неможливо визначити, наскільки зростання ефективності до 49% зумовлене контекстом у лексичному індексі, а наскільки — простим гібридним пошуком.
Пастка під час цитування цифр
Будь-хто, хто цитує ці результати, також може потрапити у пастку обчислень. У посібнику Anthropic наведений менший набір даних — дев’ять кодових баз та 248 запитів, оцінених за іншою метрикою: Pass@20 зростає з 90% у базовому варіанті до 97% у повній версії. Різний корпус, різна метрика, тому поєднання цих цифр із попередніми є просто помилкою.
Це скорочення не є безкоштовним. Воно коштує грошей під час індексації, але один механізм дозволяє тримати цю вартість ближче до одного долара, ніж до тисячі.
Чому саме долар, а не тисяча
Розгляньмо наївний підхід. Документ із 8 000 токенів розділяється на десять частин. Без жодної оптимізації кожен запит знову читає весь документ, тож ідентичний текст обробляється десять разів для опису десяти різних абзаців.
Саме така структура витрат протягом багатьох років заважала реалізації цієї ідеї. Люди вважали її методом грубої сили та відхиляли її під час складання бюджету, ще до того, як було виміряно її переваги з точки зору якості.
Кешування запитів змінює ситуацію в одному аспекті. Документ надсилається один раз у вигляді фіксованого префікса. Перший запит вимагає запису в кеш за ціною, приблизно в 1,25 раза вищою за базову, тоді як кожен наступний запит до цього документа вимагає читання з кешу за ціною, приблизно в десяту частину від базової.
Якщо враховувати типові розміри частин та документів, процес контекстуалізації коштує 1,02 долара один раз на мільйон токенів вихідного тексту. Ця цифра наводиться разом із параметрами, зокрема з частинами по 800 токенів та документами по 8 000 токенів, для яких ціни зустрічаються дуже рідко. Це дозволяє перерахувати витрати, використовуючи локальні дані, замість того щоб сліпо їм довіряти.
У прикладі з кулінарною книгою, яка складалася з 737 частин, майже 62% токенів вхідного тексту було взято з кешу. Загальні витрати знизилися з приблизно 9,20 доларів до приблизно 2,85 доларів. Краща модель не стала причиною економії у дві третини — причиною було те, що документ читали лише один раз.
Деталь порядку, яка вирішує все
Практична деталь визначає, чи все це стане реальністю. Кешування працює на основі збігу префіксів, тому всі фрагменти одного документа потрібно обробляти по черзі, щоб можна було повторно використати один запис кешу. Паралелізм між документами є прийнятним — по одному працівнику на документ — але поєднання фрагментів з кількох документів у одній черзі недопустиме. Типовий наївний підхід до обробки розподіляє фрагменти між спільним пулом потоків, через що кеш використовується лише час від часу, і доводиться платити повну ціну.
До цього пункту також варто додати попередження. Сума у $1,02 відображає ціни на модель 2024 року та не є постійною величиною. Наступне покоління цієї моделі коштує в чотири рази більше, тому повторення цієї цифри сьогодні без перерозрахунку є застарілою інформацією.
З економічної точки зору все виглядає чудово для документів, поданих до SEC, саме такого типу документів використовується як приклад. Проте хтось протестував саме цей тип документів та побачив протилежний результат.
Флагманський приклад, який не пройшов власний тест
Тут починається та частина, яку ігнорують більшість коротких описів.
У ілюстрації використовувався уривок з документа SEC, але список виміряних доменів не включає ці документи. У ньому згадуються кодові бази, художня література, arXiv та наукові публікації, тож фінансові документи слугують лише прикладом для опису, а не тестовим корпусом.
Інші дослідники заповнили цю прогалину та виявили протилежний результат. Інженери Snowflake (Tarakad, Yu, Samdani, Merrick, березень 2025 р.) використали близько 23 000 справжніх документів типу 10-K та 10-Q як корпус та оцінили ефективність своєї системи на основі приблизно 500 вручну складених запитів.
Додавання до кожного уривка детального, унікального резюме, створеного моделлю, що команда сама назвала контекстуальним пошуком, знизило оцінки на 5,8 балів для однієї моделі та на 0,4 — для іншої. Результатом стали втрати та значно вищі витрати на обчислення.
Коли дешеві метадані кращі за дорогу модель
Цікавішим є те, що спрацювало в тому самому експерименті. Введення метаданих на рівні документа — а саме назви компанії, дати подання та типу форми — підвищило точність відповідей з приблизно 50 до 60% до діапазону 72–75%, причому не використовувалась жодна мовна модель.
Цей контраст несе в собі урок. Проблема була справжньою, адже частина документа дійсно не знала назви своєї компанії. Проте найдешевший спосіб вирішення проблеми виявився ефективнішим за найдорожчий, оскільки назва компанії залишається незмінною протягом усього процесу подання, а її додавання не вимагає використання моделі.
Це порівняння не є чистим відтворенням умов експерименту, і це слід відкрито зазначити. Snowflake використовував власні параметри запиту, модель інкорпорації, розмір частин документа та методи оцінки, тому результати не можна порівнювати як результати одного й того самого експерименту. Проте вони стосуються одного й того самого типу документів, саме тому вони мають значення.
Ще два результати пом’якшують ентузіазм. Бенчмарк 2026 року, заснований на T²-RAGBench та не пов’язаний із дослідженням Snowflake, тестував здатність до контекстуалізації фінансових документів із таблицями. Він показав підвищення показника recall@5 на 2,8 відсоткових пунктів при щільному пошуку та на 2,2 при гібридному пошуку (arXiv). Це підвищення є справжнім та відтворюваним, проте воно зовсім не наближається до 67%.
Цей самий бенчмарк, який охоплює понад 23 000 запитів у 7 318 документах, також містить висновок, який має насторожити всіх, хто працює з звітами: більшість залишкових помилок пов’язані з неузгодженістю структури таблиць. Текстовий префікс тут не допоможе, оскільки він лише точно позначає фрагмент, який залишається нерозбірливим.
Другий момент стосується обчислювальних ресурсів. У дослідженні ConTEB (2025) метод у стилі Anthropic було порівняно з моделлю ембеддингів, навченою спеціально для цієї мети. Навчена модель у середньому показувала трохи кращі результати та обробляла кожен документ приблизно в сто разів швидше (arXiv). Різниця у якості є незначною, адже підхід із використанням префіксів безумовно перемагає у деяких наборах даних, наприклад у корпусі страхових документів, але програє з невеликою перевагою в інших. Справжньою перевагою навченої моделі є нижча вартість обчислень.
Існує також конкуруючий підхід. Технологія Late Chunking (Jina AI, вересень 2024) вирішує ту саму проблему на нижчому рівні шляхом ембеддингу всього документа та його розділення на частини лише після обробки за допомогою трансформерного моделювання, без залучення мовної моделі. Її структурною слабкістю є те, що до індексу ключових слів нічого не додається, що позбавляє її половини переваг, які надає Contextual BM25.
Для більшості корпусів корпоративних даних саме ця асиметрія, а не різниця у метриках, ймовірно, визначає вибір. Це суб’єктивне рішення, і наведений критерій ConTEB не перевіряє його безпосередньо, оскільки BM25 не є одним із компонентів, які він оцінює.
Як тільки приклад, представлений для демонстрації, виявить контрприклад, виникає важливе питання: де саме ця техніка не є ефективною та як можна перевірити конкретний корпус протягом п’яти хвилин.
П’ять хвилин тестування перед будь-якими витратами
Почніть з тесту, а не з реалізації. Візьміть десять випадкових фрагментів з індексу та прочитайте кожен окремо. Якщо можна сказати, про що кожен фрагмент та звідки він взявся, це означає, що фрагменти вже містять контекст, а додавання префіксу лише збільшить кількість токенів, а не інформації.
Для тесту не потрібен код, і він займає п’ять хвилин. Це також єдиний доказ, який стосується саме реальних даних, а не чиїхось інших.
Чотири задокументовані ситуації, коли ця техніка не допомагає:
- Корпус менше двохсот тисяч токенів. Власна порада Anthropic для такого масштабу — включити всю базу знань у запит та повністю пропустити процес пошуку. Контекстуалізація призначена для випадків, коли корпус більше не поміщається у вікно контексту.
- Частини тексту, які вже є самостійними. Пари запитань та відповідей, картки продуктів та статті словника містять свою тему безпосередньо, тож префікс лише її повторює.
- Корпус, який часто змінюється. Витрати виникають лише один раз, якщо документи стабільні. Документи, які переглядаються щотижня, оплачуються знову щотижня.
- Таблиці та фінансові звіти. Якщо проблема полягає у структурі таблиці, а не у відсутності назви компанії, частина тексту описується точно, але залишається нерозбірливою.
Форматування вміщується у три рядки. Невеликий, стабільний корпус підходить для довгих контекстів із кешуванням. Великий корпус із неоднозначними фрагментами підходить для контекстуального пошуку. Короткі, самодостатні записи підходять для звичайного гібридного пошуку без додаткових витрат.
Порядок впровадження має значення, і саме це найчастіше призводить до розчарування. Контекстуалізація підвищує цінність гібридного пошуку, але не замінює його. Команда без технологій BM25 та механізмів переранкінгу повинна спочатку їх додати; ігнорування цього порядку означає придбання третього рівня, поки перший все ще відсутній.
Розрахуйте витрати до запуску, а не після нього. Формула є відомою, розміри фрагментів та документів також відомі, а єдиним справжнім невідомим є те, чи справді процес досягає кешу.
Що взяти з собою на перегляд дизайну
Повернімося до початкового речення. Фраза «Дохід зріс на 3%» ніколи не була неправильною. Вона не мала суб’єкта. Виправленням не став ані розумніший модель, ані краще вбудовування даних — лише один заголовок, доданий один раз під час індексації.
- Яким би сильним не був модель генерації відповідей, фрагмент без контексту є марним. Причиною є індексація, а не галюцинації.
- Три заходи разом дають 67% ефективності, а не один. Лише префікс дає майже тридцять п’ять відсотків, а гібридний пошук із переранжуванням забезпечує решту.
- Кешування запитів зробило цю техніку доступною, а не сильнішим моделем, і економія зникає без обробки документів поодинці.
- У типі документа, використаному в прикладі, є задокументований контрприклад: у звітах SEC дешеві метадані документів показали кращі результати, ніж дорогі виклики моделі для кожного фрагмента.
- П’ятихвилинна перевірка справжнього індексу має більше значення, ніж будь-яка заголовкова новина. Прочитайте десять фрагментів окремо.
На практиці це зводиться до трьох кроків у певній послідовності: проведіть тест з десятьма фрагментами, перевірте, чи відповідає корпус одному з чотирьох негативних варіантів, а лише потім розрахуйте вартість індексації за опублікованою формулою. Лише третій крок потребує бюджету, а перші два визначають, чи варто його запитувати.
Є одна проблема, якої неможливо уникнути. Anthropic опублікував розбивку результатів у додатку у вигляді статичного PDF, а не у вигляді сирого набору даних, і незалежні команди, які намагалися відтворити ці цифри, вказують на це як на проблему відтворюваності. Оцінки на корпусах даних інших мов, окрім англійської, також є дуже обмеженими. Доки ці прогалини не будуть заповнені, кожна цифра тут походить від конкретної налаштованості, а не від закону фізики, а найбільше сьогодні бракує показників ефективності для корпусів даних, що не є англійськими.
Пов’язана література
- Практичні поради: перехід від RAG до продакшну: проблеми від початку до кінця з реальних проектів — Детальний посібник з практичних порад щодо переходу від RAG до продакшну, включаючи контракти, перевірки та шаблони коду для команд, які впроваджують цю модель.