Что такое RAG и как устроена RAG-система

RAG, или Retrieval-Augmented Generation, — архитектура, в которой перед генерацией ответа система находит релевантные фрагменты документов и передаёт их языковой модели. Это позволяет отвечать по внутренней базе знаний и свежим данным без дообучения LLM.

Два контура RAG

Офлайн-индексация готовит документы к поиску:

1. файлы загружаются и очищаются;
2. текст делится на чанки;
3. для чанков вычисляются эмбеддинги;
4. векторы, текст и метаданные записываются в хранилище.

Онлайн-запрос выполняется для каждого вопроса:

1. вопрос превращается в эмбеддинг;
2. поиск возвращает top-k похожих чанков;
3. при необходимости результаты фильтруются или rerank-моделью меняется их порядок;
4. найденный контекст вместе с вопросом передаётся LLM;
5. модель формирует ответ со ссылками на источники.

RAG не делает модель всезнающей: он лишь даёт ей выбранные системой доказательства.

Зачем RAG, если можно положить документы в промпт

Для нескольких коротких файлов прямой контекст действительно проще. Но большая база не помещается в окно модели, стоит дорого и содержит много нерелевантного текста. Retrieval выбирает небольшой набор фрагментов под конкретный вопрос.

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

Основные точки отказа:

• документ не попал в индекс;
• chunking разорвал важный контекст;
• embedding-модель плохо отражает предметную область;
• нужный чанк не вошёл в top-k;
• LLM проигнорировала найденный текст или придумала вывод сверх источников.

Поэтому качество RAG нельзя оценивать только по красоте финального ответа.

Пример RAG на трёх документах: от вопроса до доказательства

Пусть бот отвечает по внутреннему справочнику компании. В базе есть три записи: о возврате товара, времени доставки и восстановлении пароля. Клиент спрашивает: «Сколько дней даётся на возврат?»

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

Ниже учебный retrieval на Python без ключа API и сторонних пакетов. Он ищет по совпадению слов. Это демонстрация передачи источника, а не реализация семантического поиска: синонимы и перефразирование такой поиск понимает плохо.

import re

documents = [
    {"id": "return-policy", "text": "Возврат товара: срок 14 дней после получения."},
    {"id": "delivery", "text": "Доставка товара занимает от 2 до 5 дней."},
    {"id": "password", "text": "Чтобы восстановить пароль, запросите письмо на странице входа."},
]

def words(text):
    return set(re.findall(r"[а-яёa-z0-9]+", text.lower()))

def retrieve(question, documents, k=2):
    query_words = words(question)
    ranked = sorted(
        documents,
        key=lambda doc: len(query_words & words(doc["text"])),
        reverse=True,
    )
    return [doc for doc in ranked if query_words & words(doc["text"])][:k]

question = "Возврат товара: какой срок?"
hits = retrieve(question, documents)
context = "\n".join(f'[{doc["id"]}] {doc["text"]}' for doc in hits)
prompt = (
    "Ответь на вопрос по источникам ниже. Укажи id источника. "
    "Если нужного факта нет, сообщи, что данных недостаточно.\n"
    f"Источники:\n{context}\nВопрос: {question}"
)
print(context)

Первым будет return-policy, затем delivery. Срок возврата подтверждается только первым документом; число 2–5 из доставки не должно попасть в ответ о возврате. Желаемый ответ модели — «14 дней после получения [return-policy]». Код выше создаёт промпт, но не вызывает LLM и не гарантирует такой ответ.

В промышленной системе вместо этого простого retrieval могут стоять BM25, векторный поиск или их комбинация. Контракт остаётся тем же: вопрос → найденные источники → контекст → ответ → проверка ссылок.

Что проверять на каждом этапе

Возьмите вопрос с известным ответом и посмотрите на выдачу поиска до генерации. Если return-policy отсутствует, изменение стиля промпта не исправит поиск. Если источник найден, но ответ говорит «30 дней», ошибка находится на этапе генерации или проверки ответа. Если найден старый вариант политики, нужно проверить обновление индекса и версии документов.

И ещё один граничный случай: «Можно ли вернуть использованный товар?» В приведённых источниках ответа нет. Система должна признать недостаток данных, даже если нашла документ со словом «возврат».

RAG и fine-tuning решают разные задачи

RAG подаёт факты из найденных документов во время запроса. Fine-tuning меняет поведение модели на обучающих примерах. Дообучение само по себе не является механизмом актуализации справочника и не даёт проверяемых ссылок на текущую запись. При этом инструменты можно сочетать: например, дообучить формат ответа и по-прежнему получать факты через retrieval.

Следующий шаг

Для поиска по смыслу разберите эмбеддинги и семантический поиск. Если нужный документ регулярно не попадает в первые результаты, переходите к гибридному поиску и reranking.

Как оценивать RAG

Сначала проверяют retrieval: нашёлся ли нужный документ и на какой позиции. Для этого используют Recall@k, Precision@k и MRR. Затем отдельно оценивают генерацию: отвечает ли текст на вопрос, подтверждается ли контекстом и корректно ли указывает источники.

Хороший минимальный тестовый набор содержит реальные вопросы пользователей, ожидаемые документы и критерии ответа. После каждого изменения chunk size, embedding-модели или промпта набор прогоняют заново.

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

RAG — это поисковая система плюс генератор. Если retrieval не нашёл доказательство, модель не должна уверенно компенсировать его выдумкой.