RAG или длинный контекст: искать нужный кусок или отправлять всё?

Можно отправить модели весь документ. Можно сначала найти нужные фрагменты и дать только их. Оба подхода способны ответить правильно — и оба могут ошибиться по разным причинам. Поэтому спор «RAG уже не нужен» мало помогает при выборе устройства конкретного приложения.

В Чатиуме удобно сделать два режима для одной библиотеки: ответ по выбранному документу и ответ по найденным разделам. Показывайте исходники рядом с результатом, чтобы сравнивать не только красоту текста, но и полноту оснований.

Что делает RAG

RAG — подход, при котором приложение извлекает подходящие материалы и передаёт их модели для ответа. Поиск может учитывать ключевые слова, смысловую близость и фильтры. Само наличие векторного индекса ещё не гарантирует, что найден именно действующий пункт для нужного пользователя.

У такого процесса как минимум две проверки: нашли ли нужное и правильно ли ответили по найденному. Если первый этап пропустил исключение из правила, модель может аккуратно пересказать неполный набор данных. Исправлять только текст инструкции генератору в таком случае недостаточно.

Когда целый документ удобнее

Представим небольшую инструкцию по выдаче оборудования. Общие правила находятся в начале, исключения — в конце, а определения — в приложении. Если документ укладывается в ограничения и задача требует сопоставить эти части, передача целиком может упростить подготовку.

Но когда вопрос касается одного пункта среди тысяч разных инструкций, сначала полезно сузить набор. Иначе в запрос попадут нерелевантные версии, возрастут объём обработки и сложность проверки. Длинный контекст расширяет возможности, но не отменяет отбор.

Ошибка, которую легко не заметить

В учебном примере пользователь спрашивает, можно ли выдать ноутбук стажёру. Найденный фрагмент говорит «оборудование выдаётся сотрудникам по заявке». В соседнем разделе есть отдельное условие для стажёров. Ответ «да, по заявке» выглядит обоснованным, пока не открыть пропущенный раздел.

Варианты улучшения: сохранять связи между разделами, добавлять соседний контекст, проверять упоминания исключений, точнее формулировать поисковый запрос. Какой способ помогает, нужно проверить на наборе вопросов. Простое увеличение числа случайных фрагментов может только добавить шум.

Фильтры доступа стоят раньше ответа

Перед поиском и передачей модели ограничьте документы теми, которые доступны пользователю. Нельзя сначала собрать ответ по закрытому источнику, а потом спрятать его название. Содержание уже могло попасть в результат.

Храните у фрагмента исходный документ, версию, раздел и статус актуальности. При обновлении файла обновляйте соответствующий поисковый набор. Удалённый или заменённый документ не должен оставаться невидимой основой новых ответов.

Как сравнить режимы в Чатиуме

Заведите вопросы с ожидаемыми источниками, включая случаи с исключениями и отсутствием ответа. Запускайте оба режима на одной версии библиотеки. Сохраняйте состав переданных фрагментов, результат, время и фактические расходы.

Для генерации можно использовать startCompletion, как в помощнике по базе знаний. Но этот вызов сам по себе не строит поисковый индекс и не определяет права. Подготовка источников — отдельная часть приложения, которую нужно сделать и проверить.

Почему гибрид часто полезнее лозунга

Приложение может сначала выбрать несколько документов, а затем передать их полностью. Или найти раздел и добавить связанные определения. Это рабочие варианты сочетания поиска и длинного контекста, а не обязательная сложная архитектура для любого проекта.

Начните с самого простого способа, который проходит ваши проверочные вопросы. Если документов десять и они короткие, не нужно заранее строить универсальную поисковую платформу. Если библиотека растёт и права различаются, правила отбора становятся частью качества продукта.

Частые вопросы