Модели с длинным контекстом для документов и knowledge base: как выбрать между long context и RAG

Когда в начале 2024 года появились long context LLM с окном в 1 миллион токенов, многие команды объявили RAG устаревшим. Зачем строить пайплайн с эмбеддингами, векторной БД и retrieval-логикой, если можно просто загрузить всю базу знаний в контекст?

Реальность оказалась сложнее. У каждого подхода есть своя ниша, свои границы и свои способы сломаться. Эта статья — практическое руководство по выбору между моделями с длинным контекстом и RAG: с конкретными критериями, сравнительной таблицей и гибридной архитектурой, которая берёт лучшее от обоих миров.

Когда нужен long context, а когда нет

Ответ на вопрос «использовать long context или RAG» зависит не от модных тенденций, а от трёх параметров вашей задачи: объём корпуса, тип запросов и требования к стоимости.

Long context — правильный выбор, когда:

Корпус документов умещается в 50K–200K токенов и меняется редко. Это один договор, набор технических спецификаций для конкретного проекта, финансовый отчёт за квартал. Здесь long context даёт очевидный выигрыш: нет задержки на retrieval, модель видит весь документ целиком и может замечать противоречия между разными его частями — то, что chunking при RAG разрушает.

Задача требует кросс-документного reasoning: «найди все пункты договора, которые противоречат политике компании» или «сравни условия в трёх версиях соглашения». RAG с chunk-retrieval справляется с этим плохо — он возвращает отдельные фрагменты, теряя структурные связи.

Команда небольшая, и векторная инфраструктура — лишняя операционная нагрузка. Для MVP или внутреннего инструмента на 10 пользователей overhead от поддержки Pinecone или Weaviate нецелесообразен.

RAG — правильный выбор, когда:

Корпус исчисляется тысячами документов или постоянно обновляется. Векторный индекс обновляется инкрементально; long context требует перезагрузки всего контекста при каждом изменении.

Нужна прослеживаемость источников: RAG по определению возвращает конкретные чанки с метаданными источника. Long context может «синтезировать» ответ без явной привязки к конкретному месту в документе.

Стоимость токенов критична. При контексте 500K токенов и 10 000 запросов в день расходы на input-токены становятся определяющей статьёй бюджета.

Long context vs RAG: плюсы, минусы и граница применимости

Сравнительная таблица

Граница рентабельности

Точка перехода от long context к RAG — около 200–300 страниц постоянного корпуса при стандартных ценах API. Ниже этой отметки overhead от RAG-инфраструктуры перевешивает экономию на токенах. Выше — расходы на long context начинают превышать стоимость построения и поддержки retrieval-пайплайна.

При корпусе от 500 страниц и более 5 000 запросов в день переход на RAG окупается в среднем за 4–8 недель только за счёт разницы в стоимости токенов. Актуальные сравнения по моделям — в исследовании retrieval vs long context для enterprise.

Как тестировать качество на длинных документах

Три обязательных теста перед production

Needle-in-a-haystack (NIAH). Вставляете конкретный факт в середину длинного документа и проверяете, может ли модель его извлечь при прямом вопросе. Это базовый тест на «потерю» информации в середине контекста. Прогоняйте с разным положением факта: начало, 25%, 50%, 75%, конец документа. Для production-систем требуйте точность выше 95% на всех позициях.

Multi-hop reasoning. Задача требует связать факты из разных частей документа: «каков суммарный бюджет проектов, упомянутых в разделе 3 и разделе 7?». Этот тест выявляет деградацию при заполненном контексте — модель часто отвечает только на основе «ближайшего» к вопросу фрагмента, игнорируя остальное.

Contradiction detection. Документ намеренно содержит противоречие между двумя разделами. Задача — обнаружить его. Это особенно важно для AI для документов в юридическом, финансовом и compliance-контекстах, где пропуск противоречия — критическая ошибка.

Метрики оценки качества

Не используйте только BLEU или ROUGE — они не отражают фактическую корректность ответа по документу. Три рабочие метрики:

Faithfulness — все ли факты в ответе содержатся в исходном документе (оценка LLM-judge на выборке запросов). Цель: >95% для production. Значение ниже 85% означает систематические галлюцинации.

Answer relevance — соответствует ли ответ заданному вопросу, не уходит ли модель в сторону. Оценивается вручную или LLM-judge по шкале 1–5.

Context recall — использовала ли модель все релевантные части документа, или ответила только на основе одного фрагмента, проигнорировав остальные. Этот показатель важнее всего при multi-hop задачах.

Как организовать evaluation pipeline

Создайте набор из минимум 50 эталонных пар «вопрос → правильный ответ с указанием источника в документе». Разделите на три категории сложности: простые фактические вопросы (30%), вопросы с reasoning по нескольким разделам (50%), вопросы на обнаружение противоречий или аномалий (20%). Прогоняйте этот набор при каждом изменении промпта, модели или параметров контекста.

Типовые провалы и как их исправить

Провал 1: «Lost in the middle»

Симптом: модель точно отвечает на вопросы о начале и конце документа, но систематически ошибается на вопросах о средних разделах.

Причина: известный эффект, при котором трансформерная архитектура уделяет меньше внимания токенам в середине длинного контекста. Подтверждён исследованиями для всех major моделей при заполнении контекста выше 60–70%.

Решение: переструктурируйте документ перед подачей в модель — разместите самые важные части в начале и конце. Для регулируемых сценариев добавьте явную инструкцию в system prompt: «Перед ответом прочти весь документ и процитируй конкретный раздел». Альтернатива — гибридный подход с RAG на первом уровне (см. следующий раздел).

Провал 2: Уверенные галлюцинации при переполнении контекста

Симптом: при объёме документа, близком к пределу контекстного окна, модель начинает «синтезировать» ответы, которых нет в документе — и делает это с высокой уверенностью.

Причина: при заполнении контекста выше 85–90% модель начинает «додумывать» недостающие связи между фрагментами вместо того, чтобы признать неопределённость.

Решение: установите жёсткий лимит на заполнение контекста — не более 70% от максимального размера окна. При превышении либо обрезайте документ, либо переключайтесь на RAG. Добавьте в system prompt явное требование: «Если ответ не содержится в тексте — скажи "информации нет в документе"».

Провал 3: Игнорирование обновлений в базе знаний

Симптом: команда обновила документы, но модель продолжает отвечать на основе устаревшей информации.

Причина: при long context подходе «база знаний» — это буквально текст, который вы передаёте в запрос. Нет механизма инкрементального обновления; нужно явно управлять версионированием и передавать актуальный текст.

Решение: для часто обновляемых корпусов long context — неподходящий инструмент. Переходите на RAG с инкрементальным индексом или гибридную архитектуру. Если остаётесь на long context — добавьте метаданные версии в system prompt и тестируйте обновления на regression-наборе перед раскаткой.

Провал 4: Дорогой контекст для простых запросов

Симптом: 80% пользовательских вопросов касаются одного-двух разделов, но каждый запрос тарифицируется с полным корпусом в контексте.

Решение: classify запросы перед маршрутизацией. Простые фактические вопросы с известным разделом — RAG или точечный поиск. Сложные вопросы с кросс-документным reasoning — long context. Это типичная задача для маршрутизирующего роутера, описанного в разделе ниже.

Гибридная архитектура: лучшее из двух миров

Для большинства production B2B-систем оптимальным решением является не выбор между long context и RAG, а их комбинация.

Двухуровневая схема

Уровень 1 — RAG для простых запросов. Классификатор определяет, что вопрос касается конкретного факта (определение термина, значение показателя, дата события). RAG извлекает 3–5 чанков с высоким cosine similarity и передаёт их в модель с коротким контекстом. Результат: низкая latency, минимальная стоимость токенов, высокая точность.

Уровень 2 — RAG + long context для сложных запросов. Классификатор определяет аналитический или кросс-документный характер запроса. RAG извлекает top-20–50 чанков из всего корпуса. Все они подаются в long context модель целиком — без дополнительного обрезания. Модель видит достаточно материала для multi-hop reasoning, но контекст остаётся управляемым (обычно 32K–64K токенов).

Ключевые компоненты гибридной архитектуры

Классификатор запросов — лёгкая модель (GPT-4o-mini, Claude Haiku) с system prompt, который определяет тип запроса по нескольким признакам: наличие слов «сравни», «все случаи», «противоречие», «итого»; длина и структура вопроса; история предыдущих вопросов в сессии.

Адаптивный retrieval. При уровне 2 первый проход retrieval возвращает top-50 чанков. Второй проход — cross-encoder reranker (например, Cohere Rerank или BGE Reranker) отбирает top-20 наиболее релевантных. Это улучшает качество «сырья» для long context модели и снижает риск потери важных фрагментов.

Citation tracking. Каждый чанк, передаваемый в long context модель, содержит метаданные: источник, раздел, страница. System prompt требует от модели цитировать источник при каждом фактическом утверждении. Это одновременно улучшает faithfulness и даёт пользователю возможность проверить ответ.

Детальные спецификации актуальных long context LLM с реальными бенчмарками на документных задачах — в каталоге моделей с длинным контекстом.

FAQ

Сколько токенов реально нужно для работы с корпоративными документами?
Типичный PDF-договор — 5 000–15 000 токенов, техническая спецификация — 10 000–40 000 токенов, годовой отчёт — 50 000–150 000 токенов. Для единичных документов хватает 32K–128K. Для одновременной работы с десятками документов или базой знаний на тысячи страниц без RAG потребуется контекст от 500K, что сегодня экономически нецелесообразно в большинстве сценариев.

Как long context LLM справляется с задачей «иголки в стоге сена»?
Современные модели демонстрируют точность выше 95% на needle-in-a-haystack тесте при контексте до 100K токенов. При заполнении контекста выше 70–80% качество заметно снижается: модель начинает терять факты из середины документа. Это известный эффект «lost in the middle», задокументированный в нескольких независимых исследованиях.

Можно ли использовать long context вместо векторной базы данных?
Для небольшой базы знаний до 200–300 страниц — да, это рабочий подход с минимальной инфраструктурой. Для корпоративной базы на тысячи документов long context становится экономически нецелесообразным: стоимость каждого запроса растёт линейно с размером контекста, тогда как RAG масштабируется на миллионы документов без роста cost per request.

Что такое гибридная архитектура RAG + long context?
RAG извлекает top-20–50 релевантных чанков из базы знаний, а затем все они подаются в long context модель целиком без дополнительного обрезания. Это сочетает точность RAG на больших корпусах с качеством reasoning long context модели при анализе извлечённого материала. Размер контекста при этом остаётся управляемым — обычно 32K–64K токенов.

Какие метрики использовать для оценки качества ответов по документам?
Три ключевые: faithfulness (все факты в ответе содержатся в источнике — оценивается LLM-judge), answer relevance (ответ соответствует вопросу) и context recall (модель использовала нужные части документа). Для регулируемых отраслей добавляйте citation accuracy — точность ссылок на конкретные разделы документа.

Заключение и следующий шаг

Long context LLM — не замена RAG, а дополнение к нему с конкретной нишей. Выбор определяется тремя параметрами: объём корпуса, тип запросов и допустимая стоимость на запрос. Для корпуса до 200–300 страниц и задач с кросс-документным reasoning long context даёт максимальное качество при минимальной инфраструктурной сложности. Для больших, постоянно обновляемых баз знаний RAG остаётся единственным масштабируемым решением. Для enterprise-систем с разнородными запросами — гибридная архитектура с классификатором.

Главный вывод: не принимайте решение на основе максимального размера контекстного окна модели. Принимайте его на основе того, как ваши конкретные запросы и ваш конкретный корпус ведут себя в тестах faithfulness, multi-hop reasoning и needle-in-a-haystack.

Следующий шаг: изучите актуальные модели с длинным контекстом с реальными бенчмарками на документных задачах, а затем ознакомьтесь с результатами enterprise-исследования retrieval vs long context — там собраны данные по реальным production-системам, которые помогут обосновать архитектурное решение перед командой.

Используете long context, RAG или гибрид в production? Поделитесь реальными цифрами в комментариях — добавим в следующее обновление сравнительной таблицы.