RAG или длинный контекст: что надёжнее для большого комплекта документов
Когда нужно ответить по сотне документов, команда обычно выбирает между двумя маршрутами. Первый загружает большой объём текста прямо в контекст модели. Второй заранее строит индекс и перед каждым ответом достаёт несколько релевантных фрагментов — это RAG. Ни один подход не надёжнее всегда: длинный контекст видит больше исходного материала, а поиск снижает объём запроса и позволяет точнее показывать источник. Правильный выбор зависит от вопроса, частоты обновлений и цены пропуска.
Коротко о различии
В длинном контексте модель получает весь доступный комплект или его крупную часть. Это удобно для связей между удалёнными разделами, общей редакторской оценки и одноразового анализа закрытого набора. Но объём не гарантирует внимания ко всем деталям. Условие в середине файла может потеряться, а цена и задержка растут вместе с входом.
RAG сначала разбивает документы на фрагменты, вычисляет их представления и строит индекс. По запросу система выбирает кандидатов и передаёт модели только их. Такой маршрут экономнее и проще обновляется, но зависит от поиска. Если нужный фрагмент не попал в выдачу, языковая модель не сможет его учесть, каким бы хорошим ни был финальный промпт.
Сценарий 1: вопрос по конкретному факту
Для поиска срока уведомления, номера пункта или точного определения RAG обычно удобнее. Пользователь получает короткий ответ со ссылкой на документ и страницу. Систему можно заставить отказаться, если подтверждающего фрагмента нет. Для этого индекс должен хранить версию, заголовок и устойчивый адрес источника, а не только обезличенный кусок текста.
Длинный контекст также способен найти факт, но проверяющему сложнее понять, откуда он взят. Если файлов много, модель может смешать старую и новую редакции. Поэтому даже при полной загрузке нужно требовать точную цитату и идентификатор документа. Наш гайд по проверке фактов описывает базовый протокол сверки.
Сценарий 2: связи между несколькими файлами
Для вопроса «где требования противоречат друг другу» большой контекст может быть сильнее, потому что модель одновременно видит разные части. Обычный поиск часто достаёт только фрагменты, похожие на формулировку запроса, и пропускает смысловой конфликт, выраженный другими словами. Помогают несколько поисковых запросов, расширение кандидатов и отдельный этап сравнения.
Однако загрузка всего архива не должна становиться единственной страховкой. Разделите задачу: сначала найдите документы по объекту и периоду, затем сравните их в ограниченном контексте. Такой гибрид уменьшает шум и сохраняет возможность увидеть связь. В результате спор идёт не о названии архитектуры, а о том, можно ли восстановить путь от вывода к исходным фрагментам.
Сценарий 3: часто меняющаяся база
RAG удобнее для инструкций, каталога и нормативных документов, которые обновляются регулярно. Один файл можно переиндексировать без повторной подготовки всего запроса. Но системе нужны правила удаления старой версии и контроля доступа. Если индекс сохранил закрытый документ или устаревший фрагмент, хороший ответ станет опасным.
Большой контекст проще для одноразовой папки, зато каждое изменение требует заново собирать комплект. Пользователь может случайно загрузить две версии и не обозначить приоритет. Для любого маршрута полезны дата документа, статус и владелец. Без этих полей нейросеть не знает, какая инструкция действует сегодня.
Полнота и эффект «всё же загружено»
Самая неприятная ошибка длинного контекста — ложное чувство полноты. Файл присутствует в запросе, поэтому команда считает, что модель обязана его учитывать. На практике внимание распределяется неравномерно, таблицы и приложения разбираются хуже, а похожие условия смешиваются. Тест должен содержать факты в начале, середине и конце, а также противоречивые версии.
У RAG риск виден раньше: можно посмотреть найденные фрагменты до генерации. Это важное эксплуатационное преимущество. Если поиск ошибся, ответ не запускают. Но хорошие фрагменты ещё не гарантируют верный вывод. Проверять нужно два этапа отдельно: полноту retrieval и точность ответа на найденном материале.
Цена, задержка и приватность
Длинный контекст передаёт модели больше данных при каждом запросе. Это увеличивает стоимость и площадь доступа. Кэширование может помочь, но его режим и хранение нужно проверять у поставщика. RAG требует первоначальной индексации, базы и мониторинга, зато в модель уходит меньший объём. При правильной фильтрации прав пользователь не получает фрагменты из чужого отдела.
Для чувствительных документов сравните не только цену токенов. Добавьте распознавание сканов, подготовку метаданных, обновление индекса, проверку ответа и разбор инцидентов. В небольшом одноразовом проекте простой длинный контекст бывает дешевле сложной инфраструктуры. В постоянной базе с сотнями пользователей расходы часто разворачиваются в пользу поиска.
Контрольный тест на двадцати вопросах
Составьте пять точных вопросов, пять связей между файлами, пять ловушек со старой версией и пять вопросов, на которые ответа нет. Для каждого заранее укажите правильный источник. Прогоните оба маршрута с одинаковой моделью. Считайте правильность, полноту источников, обоснованные отказы, время и стоимость принятого ответа.
Не меняйте одновременно модель и архитектуру: иначе причина различия останется неизвестной. Ошибки поиска, рассуждения и цитирования записывайте отдельно. После первого теста улучшите только один компонент и повторите скрытую часть выборки. Перед тестом полезно сверить устройство RAG простыми словами и правила работы с большим контекстом, но здесь обязательно присутствует альтернативный маршрут без индекса.
Когда выбрать каждый вариант
Длинный контекст разумен для небольшого стабильного комплекта, одноразового обзора и вопросов о целостной структуре. RAG подходит для растущего архива, точечных фактов, частых обновлений и разграничения доступа. Гибрид нужен, когда поиск сначала сужает область, а модель затем сравнивает несколько полных документов.
Не закрепляйте выбор навсегда. При росте базы, смене модели или появлении новых типов файлов повторите контрольный набор. Надёжность определяется не размером окна и не модным названием, а тем, насколько часто система находит нужное, показывает доказательство и честно отказывается без него.
FAQ
Большой контекст заменяет RAG?
Не всегда. Он уменьшает необходимость дробить небольшой комплект, но не решает обновление, права доступа и проверяемость источника.
Можно ли использовать оба подхода?
Да. Поиск может выбрать несколько релевантных документов, после чего они целиком передаются модели для сравнения.
Какая метрика главная?
Доля принятых ответов с правильным доказательством. Отдельно считайте опасные уверенные ответы без подтверждающего источника.