Вики
Блог nikolskiy.dev

RAG

Как дать модели знание о ваших данных и снизить галлюцинации — от базового поиска до продакшен-архитектур.

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

1. Базовая модель RAG

RAG — это не «умная LLM», а pipeline: запрос → retrieval → сборка контекста → генерация. Качество результата определяется в первую очередь retrieval'ом, а не моделью: если в контекст пришло не то, генерация не спасёт. Поэтому chunking, токенизация и контекстный бюджет — не технические детали, а основа качества.

  • RAG — retrieval-augmented generation как pipeline, точка входа в тему.
  • Chunking — нарезка документов; размер/overlap прямо влияют на retrieval.
  • Embeddings — векторное представление, фундамент dense retrieval.
  • Context Window — физический бюджет, в который собирается найденное.
  • Tokenization — чанки и лимиты меряются в токенах, не в символах.

2. Retrieval stack: поиск и ранжирование

Два разных механизма поиска: dense (по смыслу, через эмбеддинги) и lexical/BM25 (по словам). Гибрид (vector + BM25, объединённые через RRF) покрывает слабости каждого. Reranker — отдельный второй проход, нужен когда top-k «грязный». Выбор embedding/reranker нельзя брать из бенчмарка вслепую — проверяй на своём корпусе.

  • Hybrid Search — dense + lexical (BM25) + RRF.
  • Reranking — переранжирование кандидатов вторым проходом.
  • RU Embedding Model Selection — выбор embedding-модели под русский корпус.
  • Model Selection — выбор моделей (embedding/reranker/генератор) под задачу и бюджет.

3. Storage и lifecycle индекса

  • Vector Databases — где хранить эмбеддинги: pgvector vs dedicated store.
  • Vector Store Persistence — versioning, re-embedding, alias-миграция индекса.
  • RAG Observability — трейсинг retrieval для диагностики регрессий индекса.

4. Архитектурные варианты knowledge access

Четыре способа дать модели знания, выбор зависит от объёма, частоты обновления и того, кто решает «что искать»: RAG — retrieval на каждый запрос (большая/меняющаяся база); CAG — знания заранее загружены в контекст/кэш (небольшая стабильная база); Agentic RAG — агент сам решает, что и когда искать (сложные многошаговые запросы); GraphRAG — знания как граф сущностей/связей (запросы, требующие обхода связей).

  • RAG — базовый вариант: retrieval на каждый запрос.
  • CAG — cache-augmented: знания в контексте вместо поиска (глубокая механика — см. Prompt Caching → KV Cache).
  • Agentic RAG — retrieval под управлением самого агента.
  • GraphRAG — графовая структура знаний вместо плоских чанков.
  • Prompt Caching — переиспользование префикса промпта; механизм, на котором стоит CAG.
  • RAG vs CAG vs Agentic RAG — decision matrix выбора подхода.

5. Quality, evals и observability

Две взаимодополняющие линзы: offline eval (метрики на фиксированном датасете до деплоя) и online tracing (что реально происходит в проде). Частый диагноз «LLM галлюцинирует» на деле означает «retrieval принёс не то» — поэтому chunk-attribution и index_version в трейсе важнее, чем кажется.

  • RAG Metrics — offline-метрики: Hit Rate, MRR, Faithfulness.
  • RAG Observability — online-трейсинг: chunk-attribution, index_version в трейсах.
  • Reranking — рычаг улучшения precision top-k по результатам eval.
  • Agent Evals — общая методология оценки (offline датасет vs online), применима к RAG.

6. Production RAG route

Собрать production-ish RAG RAG → Chunking → Embeddings → Hybrid Search → Reranking → Vector Databases → Vector Store Persistence → RAG Metrics

(После выхода в прод подключай RAG Observability — раздел 3/5.)

7. Architecture decision route

Выбрать RAG / CAG / Agentic RAG / GraphRAG RAG → CAG → Agentic RAG → GraphRAG → RAG vs CAG vs Agentic RAG

Связано с