Проектирование RAG-системы

Abstract

RAG — архитектура, в которой система извлекает внешние данные и добавляет выбранные фрагменты в контекст генерации. Она даёт модели доступ к корпусу во время inference, не изменяя её веса.

Базовый контур

документы → parse → chunks → index
                              ↓
запрос → query rewrite → retrieve → rerank → context → generate → citations/checks

Реальная система не обязана содержать каждый этап. Начни с простого поиска и добавляй сложность только после измеримого провала.

Что RAG может улучшить

  • доступ к приватным или изменившимся знаниям;
  • проверяемость через координаты источника;
  • работу с корпусом больше context window;
  • обновление знаний без fine-tuning.

RAG не гарантирует фактическую точность. Retrieval может не найти нужный документ, выбрать неверный фрагмент или передать противоречивые данные; модель может проигнорировать контекст или неверно его пересказать.

Основные решения

СлойВопрос
Ingestionчто считать документом и как обрабатывать версии
Chunkingгде проходят смысловые границы и какие метаданные сохранять
Indexkeyword, dense, graph или их комбинация
Retrievalкак формировать запрос и фильтровать область поиска
Rerankingнужен ли второй, более дорогой этап отбора
Context assemblyсколько фрагментов передать и как удалить дубли
Generationкак цитировать, выражать неопределённость и отказываться без evidence
Evaluationнашли ли evidence и использовал ли его ответ корректно

RAG и long context

Это не взаимоисключающие подходы. Retrieval выбирает кандидатов из большого корпуса, а context window определяет, сколько выбранного материала модель может обработать за один вызов.

Выбирай сначалаКогда
Long contextнебольшой стабильный набор документов, важен полный обзор
RAGбольшой или часто обновляемый корпус, нужен точечный поиск
RAG + long contextнужно собрать несколько крупных первичных источников

Сравнивай варианты на одинаковом eval set по качеству, latency и полной стоимости. Утверждения «RAG всегда дешевле» и «длинный контекст всегда точнее» неверны.

Минимальные evals

Разделяй ошибки:

  1. Retrieval: нужный evidence попал в top-k.
  2. Context: evidence не потерян при обрезке и дедупликации.
  3. Answer: утверждения поддерживаются переданными источниками.
  4. Citation: ссылка указывает на правильный фрагмент.
  5. Freshness: индекс отражает актуальную версию документа.

Добавь негативные вопросы, для которых в корпусе нет ответа. Хорошая система должна признать недостаток evidence.

Безопасность

Retrieved content — недоверенные данные. Он может содержать prompt injection, секреты и устаревшие разрешения. Изоляция инструкций в разметке полезна для модели, но policy enforcement должен находиться в коде и правах tools.

Источники

Связанные заметки