Генеративный AI

RAG: Retrieval-Augmented Generation

ChatGPT знает что произошло до января 2022 и не знает ничего после. Но ChatGPT Enterprise с RAG отвечает на вопросы о корпоративных документах прямо сейчас. Разница - не в модели. Разница в том как организована подача знаний: retrieval-augmented generation превращает LLM из статичного snaphost в живой оракул с актуальной памятью.

  • GitHub Copilot Workspace (2024): RAG по codebase пользователя - embeddings файлов проекта, retrieval при каждом completion. Без этого модель не знает локальные функции
  • Notion AI Q&A: пользователь задаёт вопрос о содержимом workspace, RAG находит релевантные страницы, LLM синтезирует ответ - кастомный ChatGPT поверх личной базы знаний
  • Perplexity.ai: hybrid RAG поверх веба в реальном времени - web search + BM25 + dense retrieval + reranking, ответы с цитатами из источников

Предварительные знания

  • AI Agents: архитектура и провалы

Patrick Lewis и рождение RAG

В 2020 году Patrick Lewis и команда Facebook AI Research опубликовали статью «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks». Идея была простой и мощной: вместо того чтобы запихивать все знания в параметры модели, дать ей доступ к внешней базе документов и подмешивать найденное в контекст генерации. Модель перестаёт галлюцинировать факты, которых не знает, и начинает отвечать на основе актуальных источников. К 2023 году RAG стал самым массовым паттерном внедрения LLM в бизнес: корпоративный поиск, чат-боты по документации, ассистенты по базе знаний. Сам Lewis позже шутил, что если бы знал, как приживётся этот термин, придумал бы название покрасивее.

Chunking: разбивка документов

Lewis et al. 2020 - RAG paper от Facebook AI: первая система, где retriever и generator обучались совместно. До RAG LLM работали только с тем, что было в весах модели. Hallucination rate на knowledge-intensive tasks (TriviaQA, NQ) снизился вдвое. Ключевое открытие: качество retrieval ограничивает качество generation - garbage in, garbage out.

Chunking - разбивка документов на фрагменты перед индексацией. Размер чанка - главный гиперпараметр: маленькие чанки (128 токенов) дают точный retrieval но теряют контекст, большие (2048 токенов) несут контекст но разбавляют сигнал. Стратегии: fixed-size с overlap (простая), sentence-based (NLTK/spaCy), recursive character (LangChain default), semantic chunking (SBERT cosine similarity между предложениями).

Проблема потерянного середины (Lost in the Middle, Liu et al. 2023): LLM хуже обрабатывают релевантную информацию в середине контекста - attention сильнее на начало и конец. Следствие: правильный retrieval важнее длинного контекста. Даже при 128K токенов качество падает если нужный факт на позиции 60K.

Semantic chunking разбивает документ по:

Vector Search: поиск по embeddings

Bi-encoder архитектура (Reimers and Gurevych 2019, SBERT): query и document кодируются независимо в dense vectors, сходство - cosine similarity. Скорость: один forward pass на query, все документы предвычислены. Approximate Nearest Neighbor (ANN): точный поиск O(n) слишком медленный для 100M документов. HNSW (Hierarchical Navigable Small World) - граф приближённого поиска, 99% recall при 100x speedup.

Embedding models benchmark: MTEB (Massive Text Embedding Benchmark, HuggingFace 2022) - 56 задач, 112 языков. Лидеры 2024: text-embedding-3-large (OpenAI), E5-mistral-7b, BGE-M3. Русскоязычный retrieval: ru-en-RoSBERTa показывает -8% vs best multilingual. Размер вектора vs качество: 768 dim vs 3072 dim дают +2-3% при 4x больше памяти.

HNSW используется в vector databases потому что:

Reranking: точная релевантность

Cross-encoder vs bi-encoder: bi-encoder кодирует query и document независимо (быстро, но менее точно), cross-encoder видит пару [query, document] целиком через joint attention (точно, но O(n) на inference). Решение: двухэтапный pipeline. Stage 1: bi-encoder retrieves top-100 (fast). Stage 2: cross-encoder reranks до top-5 (precise). ms-marco-MiniLM-L-12 - стандартный reranker: 33M параметров, latency ~20ms на документ.

Cohere Rerank API: managed cross-encoder с RLHF fine-tuning на human relevance labels. В экспериментах Cohere (2023): reranking поднимает nDCG@10 на 15-25% vs pure bi-encoder. LLM-as-reranker (RankGPT, Sun et al. 2023): GPT-4 как reranker через listwise prompting - лучшее качество, но latency 2-5 секунд на 20 документов.

Reciprocal Rank Fusion (RRF): ensemble нескольких retriever без reranker. score = sum(1 / (k + rank_i)) для каждого retriever i. k=60 - эмпирически оптимальный. Преимущество: не требует score calibration (разные retriever имеют несопоставимые шкалы оценок). Используется в Elasticsearch hybrid search из коробки.

Почему cross-encoder не используют для первичного retrieval?

Hybrid RAG: sparse + dense + GraphRAG

Dense retrieval (embeddings) vs sparse retrieval (BM25): dense хорошо работает на семантически похожие формулировки, sparse точен при exact keyword match. Пример: query 'GPT-4 RLHF training' - dense найдёт документ про 'обучение языковых моделей с обратной связью от людей', sparse точно найдёт документ с 'GPT-4'. Hybrid = лучшее из обоих: Elasticsearch 8.0+ (2022) добавил нативный hybrid search, комбинируя BM25 и kNN через RRF.

GraphRAG (Microsoft, 2024): вместо плоского индекса строится knowledge graph из документов через LLM entity extraction. Query-time: граф traversal + community summaries + vector search. На corpora с плотными связями (юридические документы, научные статьи) GraphRAG на 30-50% точнее vanilla RAG на вопросах требующих синтез через несколько документов. Цена: в 10-20x дороже по LLM calls на индексацию.

RAG evaluation: RAGAS framework (2023) - автоматическая оценка без labeled data через LLM-as-judge. Метрики: faithfulness (ответ подкреплён retrieved контекстом?), answer relevancy (ответ релевантен вопросу?), context precision (retrieved docs релевантны?), context recall (все нужные факты retrieved?). Типичные значения production RAG: faithfulness 0.7-0.85, answer relevancy 0.75-0.90.

Больший контекст (128K токенов) делает RAG ненужным - просто засунуть всю базу знаний в prompt

Long context и RAG решают разные проблемы: RAG фильтрует нерелевантное, long context помогает когда весь документ нужен

Lost in the Middle (Liu et al. 2023): LLM теряют факты из середины длинного контекста. 128K токенов это ~96K слов - корпус компании не влезет. Кроме того cost: 128K токенов = $0.40 per call vs $0.01 для top-5 RAG chunks

GraphRAG превосходит vanilla RAG прежде всего на:

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

RAG на пересечении нескольких областей: retrieval из information retrieval, generation из NLP, storage из database systems

  • Трансформеры и Attention — Bi-encoder и cross-encoder - оба построены на трансформерах; attention позволяет joint query-document понимание
  • NLP: Text Classification — TF-IDF и BM25 - sparse методы используемые в hybrid RAG как complementary к dense retrieval
  • Vector Databases — pgvector, Pinecone, Weaviate - инфраструктура хранения и ANN-поиска для dense retrieval
  • AI Agents — RAG как tool в агентском цикле - retrieval on demand вместо статичного контекста

Ключевые идеи

  • Chunking size - главный гиперпараметр RAG: маленький = точный retrieval, большой = полный контекст. Semantic chunking по cosine distance лучше fixed-size
  • Two-stage pipeline: bi-encoder retrieves top-100 (fast), cross-encoder reranks до top-5 (precise). Экономия: пересчитывается только 100 документов, не миллионы
  • Hybrid search (BM25 + dense через RRF) превосходит pure dense на keyword-specific queries - exact match важен для терминов, аббревиатур, имён собственных
  • GraphRAG выигрывает на multi-hop вопросах (+30-50%), но стоит в 10-20x дороже на индексацию - выбор зависит от типа queries в production

Вопросы для размышления

  • Корпоративная база знаний: 500K документов на русском и английском. Какой embedding model выбрать и почему? Как изменится стратегия chunking для PDF с таблицами vs plain text?
  • Пользователь жалуется: 'RAG отвечает неточно на вопросы про наши продукты, хотя документация есть в базе'. Какие метрики RAGAS покажут диагноз проблемы - плохой retrieval или плохая generation?
  • Long context window в 1M токенов (Gemini 1.5 Pro). Когда всё равно нужен RAG, а не просто вставить весь корпус в prompt?

Связанные уроки

  • gai-15 — Агенты используют RAG как инструмент памяти
  • dl-08 — Трансформеры генерируют embeddings для vector search
  • ds-15 — TF-IDF в NLP - предшественник sparse retrieval в RAG
  • db-11-query-optimization — Vector databases (pgvector, Pinecone) хранят embeddings
  • la-15-svd
RAG: Retrieval-Augmented Generation

0

1

Войти