Почему большой контекст не заменяет поиск по документам
Как RAG находит фрагменты, почему подходящий по теме текст бывает недостаточным и что нужно проверить между документом и готовым ответом.
8 сентября 2026 года Epoch AI опубликовала сравнение задержки до первого токена у GPT-5.6 Terra и Sol, Claude Sonnet 5 и Opus 5. При увеличении входа кривые GPT заметно изгибались вверх, а кривые Claude оставались ближе к линейным. Для Opus данные заметно шумнее: отсутствие кривизны окончательно не установлено. Исследователи отключили рассуждение; измеряли отклик API, а не качество ответов по документам. Свежая работа возвращает к простому вопросу: даже если большой архив помещается в контекст, всегда ли полезно передавать его целиком?
В папке отдела лежат инструкции, старые презентации и несколько редакций одного документа. Сотрудник спрашивает помощника: какой порядок согласования действует сейчас? Кажется, достаточно загрузить всю папку в модель с большим контекстным окном. Но в ответе можно получить смесь старого и нового порядка, а ссылка будет вести к документу, который действительно существует, только уже не действует.
Это удобный пример для понимания RAG — генерации ответа с использованием найденных материалов. Здесь сталкиваются разные задачи: хранить документы, находить подходящие фрагменты, понимать их и подтверждать вывод. Большое окно контекста помогает передать больше текста за один раз. Оно не определяет автоматически, какая версия актуальна и достаточно ли найденных сведений для ответа. Именно поэтому поиск и управление контекстом остаются полезными даже тогда, когда технический лимит входа перестаёт казаться тесным.
Поиск начинается до разговора с моделью
В описании Contextual Retrieval от 19 сентября 2024 года Anthropic объясняет обычную цепочку RAG: документы делят на фрагменты, превращают в векторные представления и находят подходящие части по запросу. Компания также рассматривает сочетание смыслового поиска с BM25, который полезен при точных совпадениях терминов. Её дополнение — поясняющий контекст рядом с каждым фрагментом до индексации. Он помогает не потерять сведения о том, к какому документу относится отрывок.
Представим абзац «заявку согласует руководитель». Без названия процесса и версии инструкции он почти бесполезен: заявок много, руководители разные. Если рядом сохранены раздел, дата и принадлежность документа, фрагмент легче правильно использовать. Это наш учебный пример, не цитата из корпоративного регламента. Сообщённое Anthropic снижение ошибок поиска относится к её экспериментам и выбранным настройкам, а не к любому архиву. Сам метод стоит проверять на собственных документах: добавленное пояснение тоже способно ошибаться. Источник: Anthropic, «Introducing Contextual Retrieval».
Похожий по теме текст может не содержать ответа
Google Research в публикации от 14 мая 2025 года предлагает различать релевантный и достаточный контекст. Первый связан с вопросом, второй содержит информацию, необходимую для определённого ответа. Исследователи изучали, как системы ведут себя при недостаточных материалах, и предложили использовать сигнал достаточности при решении, отвечать ли на вопрос. Их работа не обещает устранения всех выдуманных ответов. Источник: «Deeper insights into retrieval augmented generation: The role of sufficient context».
Для нашей инструкции различие очень практичное. Поиск может вернуть документы о согласовании, но ни один не сообщает, какой из них действует. Если помощник выбирает самый уверенный по тону абзац, пробел не исчезает. Более полезный ответ назовёт, что найдено и чего недостаёт: например, нет подтверждения даты вступления новой версии в силу. Это не обязательно конец работы. Система может поискать приказ об утверждении или попросить уточнение. Но она должна замечать пробел, прежде чем оформлять догадку как установленный порядок.
Контекстом нужно управлять и после поиска
Anthropic в материале об инженерии контекста от 29 сентября 2025 года описывает отбор информации на каждом шаге агентной работы. Среди подходов — загрузка материалов по необходимости, сжатие истории и отдельные структурированные заметки. Авторы предупреждают, что слишком агрессивное сжатие может потерять детали, значение которых выяснится позже. Это инженерные рекомендации компании, а не универсальная формула длины запроса. Источник: «Effective context engineering for AI agents».
В нашем примере полезная заметка могла бы хранить названия проверенных документов и неразрешённое противоречие между версиями. Фраза «порядок согласования найден» слишком коротка: она стирает именно то, ради чего потребовалась проверка. При продолжении разговора нужно иметь возможность снова открыть исходник. Поэтому краткая память и исходные документы выполняют разные функции. Память помогает продолжить работу; документ позволяет проверить утверждение. Увеличение контекстного окна не отменяет необходимости выбирать, что оставить в активном обсуждении и как вернуться к полному тексту.
Для некоторых вопросов нужен обзор всего архива
Microsoft Research в первом объяснении GraphRAG от 13 февраля 2024 года описывает другую трудность: обычному поиску похожих фрагментов сложно отвечать на вопросы о темах всего корпуса и связях между разрозненными сведениями. GraphRAG строит с помощью языковой модели граф сущностей и отношений, группирует его и использует подготовленные обобщения. Авторы показывают преимущества на выбранных задачах; оценка включает модельного судью. Это не означает превосходства такого подхода во всех видах поиска.
Вопрос «кто согласует эту заявку?» обычно требует точного фрагмента. Вопрос «какие этапы чаще всего вызывают разногласия в наших инструкциях?» требует сопоставить материалы шире. Для второго набора ближайших по смыслу абзацев может оказаться мало. При этом граф не становится первичным свидетельством: связи извлекла модель, и их нужно проверять по исходным документам. Полезно сохранять путь от обобщения обратно к конкретному месту в тексте. Источник: Microsoft Research, «GraphRAG: Unlocking LLM discovery on narrative private data».
Иногда следующий запрос рождается из предыдущего ответа
5 июня 2026 года Google Research описала агентный RAG, который планирует поиск, обращается к нескольким корпусам и проверяет достаточность найденного. Если сведений не хватает, система уточняет запрос и продолжает. В опубликованном эксперименте использовались вопросы FramesQA, а правильность ответов оценивала языковая модель относительно эталона. Это результаты Google для описанной системы и данных, не независимая оценка любого корпоративного помощника. Источник: «Unlocking dependable responses with Gemini Enterprise Agent Platform’s Agentic RAG».
У нашего сотрудника такой ход выглядел бы следующим образом. Сначала помощник находит инструкцию, затем обнаруживает отсылку к приказу, после этого ищет приказ и проверяет, отменяет ли он предыдущую редакцию. Здесь нужны последовательные поиски: заранее неизвестно, какой идентификатор появится в первом документе. Но продолжительность цепочки стоит ограничивать. Если приказ отсутствует, десяток переформулировок не создаст его в архиве. Хороший итог тогда содержит найденную часть ответа и конкретный неразрешённый вопрос. Так проверка достаточности становится полезнее, чем бесконечное накопление похожих отрывков.
Измерять надо весь путь до ответа
26 августа 2026 года MLCommons представила сквозной бенчмарк RAG с отдельными процессами построения векторной базы и ответов на вопросы. В наборе — 824 вопроса FRAMES и фиксированный снимок 2 515 статей Wikipedia. Первая версия использует режим Offline, когда все запросы известны заранее. Производительность ответов измеряется задачами в секунду, а не единым числом токенов в секунду для разных компонентов. Источник: «Introducing the MLPerf End-to-End RAG Inference Benchmark».
Для читателя здесь важнее устройство измерения, чем очередной результат. Подготовка индекса, поиск, повторное ранжирование и составление ответа образуют цепочку. Быстрый генератор может ждать медленный поиск, а хорошо найденные документы могут быть неверно поняты. При этом пакетный тест на фиксированном корпусе не воспроизводит живую папку отдела, где файлы обновляют каждый день. Потребуются отдельные проверки актуальности и прав доступа. Нельзя переносить показатели такой нагрузки на интерактивный помощник без уточнения условий; сам бенчмарк этого переноса не доказывает.
Что проверить на своей папке документов
Для начала выберите вопросы, на которые ответ известен ответственному сотруднику. Добавьте случаи со старой редакцией, противоречием и отсутствующим документом. Сохраняйте не только ответ помощника, но и найденные фрагменты с версиями. Так можно отделить промах поиска от ошибки чтения: нужного абзаца вообще не было на входе или модель получила его и сделала неверный вывод? Это предлагаемый порядок проверки, а не проведённое исследование конкретного продукта.
Отдельно проверьте ссылки. Они должны помогать открыть нужный источник и подтвердить конкретное утверждение, а не просто вести в ту же папку. Для рабочего процесса также важно, как удалённый или обновлённый документ перестаёт участвовать в ответах. Большой контекст и RAG можно сочетать: поиск отбирает материалы, модель получает достаточно широкие отрывки для понимания. Решение определяется вопросами и состоянием архива. Надёжность появляется, когда путь от документа до вывода можно проследить, а недостающие сведения остаются видимыми.
Работа Epoch добавляет к этому выбору отдельную ось — ожидание ответа. Задержка включает сетевые и серверные накладные расходы; по ней нельзя установить внутреннюю архитектуру закрытой модели. Тем более нельзя заключить, что более быстрое чтение обеспечивает более верный ответ. На своей папке документов полезно сравнить два маршрута: передать большой набор целиком или сначала отобрать фрагменты. Запишите не только время ожидания, но и найденную версию инструкции, пропущенные исключения и пригодность ссылки. Поиск оправдан там, где этот маршрут лучше отвечает вашей задаче; объём контекстного окна сам по себе решения не принимает.