RAG чи великий контекст: що обрати для PDF, таблиць і довгих документів

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

Головна умова для текстового конвеєра: обидва підходи залежать від якості витягнутого тексту. Помилки OCR і втрачену структуру таблиць треба перевіряти окремо. Мультимодальний режим може передавати моделі також зображення сторінок; наприклад, OpenAI підтримує PDF із текстом і зображеннями для моделей із зором. Це окремий варіант для тестування, а не гарантія правильного читання документа.

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

Два способи передати документи моделі

У текстовому конвеєрі модель отримує підготовлений текст, а не самостійний доступ до всієї папки. Різниця між підходами в тому, скільки матеріалу і які саме фрагменти потрапляють у запит. Якщо передаються також зображення сторінок, це потрібно окремо врахувати в оцінці якості й вартості.

Повний контекст. Документ або кілька документів цілком передаються моделі разом із питанням. Модель бачить усе одночасно і сама шукає потрібні місця. Цей підхід став практичним, коли з'явилися моделі з великим контекстним вікном, тобто з великим максимальним обсягом тексту, який вони приймають за один запит.

Вибір фрагментів (RAG). Документи заздалегідь розбивають на фрагменти і індексують. Коли надходить питання, система шукає найбільш релевантні фрагменти і передає моделі лише їх. RAG (Retrieval Augmented Generation) означає генерацію з попереднім пошуком.

Кожен підхід має свою ціну:

• Повний контекст простіший в архітектурі, не залежить від якості пошуку, але кожен запит обробляє весь обсяг тексту. Це впливає на вартість і час відповіді, і обсяг обмежений розміром вікна.
• RAG передає відібрані фрагменти, що може зменшити кількість вхідних токенів, і масштабується на бібліотеки, які не вмістяться в одне вікно. Повна вартість залежить також від підготовки індексу, пошуку та повторного ранжування. Але він додає компоненти, які теж можуть помилитися: розбиття на фрагменти, пошук, складання контексту. Як їх діагностувати, ми розібрали в статті про те, чому RAG вигадує відповіді.

Розмір контекстного вікна сам по собі не визначає якість. Те, що модель може прийняти весь документ, ще не означає, що вона однаково добре використає кожну його частину.

Що насправді порівнювали дослідники

Дві роботи часто цитують у суперечках «RAG чи довгий контекст». Варто знати, що саме в них перевіряли.

Lost in the Middle (2023). Автори перевірили, як моделі використовують інформацію в довгому контексті, на двох задачах: відповідь на питання за кількома документами і пошук значення за ключем. Результат мав U-подібну форму: якість була найвищою, коли потрібна інформація стояла на початку або в кінці контексту, і помітно знижувалася, коли вона була посередині. Спад зберігався і для моделей, спеціально призначених для довгого контексту. Це результат для моделей 2023 року на двох конкретних задачах. Він не описує всі сучасні моделі, але показує, що використання довгого контексту варто перевіряти, а не припускати.

RAG or Long Context (2024). Робота порівняла RAG і довгий контекст на кількох публічних наборах даних з трьома моделями, сучасними на 2024 рік. У повному тексті порівнювали GPT-4o, GPT-3.5-Turbo і Gemini-1.5-Pro. Висновок авторів: за достатніх ресурсів довгий контекст у середньому стабільно перевершував досліджений варіант RAG, а RAG зберігав суттєву перевагу у вартості. Автори запропонували гібридний метод Self-Route: модель сама оцінює, чи вистачає їй знайдених фрагментів, і за потреби запит перенаправляється на повний контекст. У досліджених умовах це знижувало витрати при якості, близькій до повного контексту. Робота прийнята на EMNLP 2024 (industry track).

Чого з цих робіт не випливає:

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

Практичний висновок обох робіт інший: якість і вартість треба міряти на своїх задачах, а гібрид може зберегти більшу частину якості за меншої ціни.

Чому PDF складніший за звичайний текст

Більшість суперечок «RAG чи великий контекст» мовчки припускають, що текст документа вже є і він правильний. Для PDF це припущення часто хибне.

Скани. У текстовому конвеєрі сторінка-зображення перетворюється на текст розпізнаванням (OCR). Рівні впевненості залежать від продукту й версії API: наприклад, для custom models Microsoft Document Intelligence починаючи з API 2024-11-30 GA оцінка поля враховує впевненість у словах. Не переносіть правило незалежності оцінок зі старої схеми відповіді на всі версії. Перевіряйте фактичні оцінки слів, полів і таблиць та зіставляйте їх із ручною розміткою.

Колонки і порядок читання. Текст у дві колонки при витяганні може злитися в рядки, де половина речення з лівої колонки, а половина з правої.

Підписи, печатки, примітки на полях. Вони або губляться, або вставляються посеред основного тексту.

Розірвані таблиці. Таблиця, що переходить на наступну сторінку, може розірватися на дві з повтором заголовка або без нього. Документація Microsoft окремо пояснює, що для рядків, розірваних між сторінками, впевненість у рядку може бути нижчою, ніж у цілих рядків, навіть якщо окремі клітинки розпізнано впевнено.

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

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

Висновок для текстового конвеєра: помилковий текст з PDF зашкодить і повному контексту, і RAG. Тому якість витягання тексту перевіряють першою, окремо від вибору архітектури.

Сценарії вибору

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

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

Гібридний підхід

На практиці підходи часто поєднують. Ось кілька поширених способів.

Маршрутизація задач. Різні типи питань ідуть різними шляхами. Питання про конкретну умову в одному договорі обробляються повним контекстом цього договору. Питання «де в наших регламентах описано…» йдуть через пошук. Розрахунки за таблицями йдуть через код.

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

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

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

Як порівняти на своїх даних

Порівняння має сенс лише за однакових умов. Ось як його побудувати.

Однакові файли. Візьміть реальні документи процесу, включно з проблемними: скани, таблиці на кілька сторінок, документи з колонками. Зафіксуйте версію і спосіб витягання тексту, однаковий для обох підходів. Окремо перевірте вручну якість витягнутого тексту на кількох сторінках.

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

Що рахувати:

• окремо частку правильних відповідей і частку коректних відмов;
• вартість однієї правильної відповіді за однаковий період: витрати на OCR, ембединги, індекс, пошук, переранжування і генерацію, поділені на кількість правильних змістовних відповідей. Разові витрати розподіліть на обґрунтований обсяг використання, а умови кешування й трафік зробіть порівнянними. Коректні відмови обліковуйте окремо; якщо правильних відповідей немає, ця метрика не визначена;
• p95 затримки, тобто час, за який отримують відповідь 95% запитів;
• окремо помилки, спричинені витяганням тексту, щоб не приписати їх архітектурі.

Однакова модель. Порівнюйте підходи на одній моделі. Інакше ви порівнюєте моделі, а не підходи.

Що зробити найближчим часом:

1. Розкладіть свої задачі за сценаріями з матриці: разовий документ, велика бібліотека, таблиці з розрахунками, дані, що часто змінюються.
2. Перевірте якість витягання тексту з ваших PDF на кількох характерних документах, окремо для сканів і таблиць.
3. Підготуйте набір питань з еталонними відповідями, включно з питаннями з середини документів і розрахунками.
4. Проженіть повний контекст і RAG на однакових файлах і однаковій моделі.
5. Порівняйте частку правильних відповідей, вартість однієї правильної відповіді і p95 затримки.
6. Для розрахунків за таблицями перевірте окремо варіант із кодом розрахунку над витягнутими даними.

Часті питання