Шпаргалка: RAG и векторные БД¶

~7 минут чтения

Предварительно: Эмбеддинги и представления | Архитектура трансформера

Справочная карточка по RAG-пайплайнам, векторным базам данных и стратегиям поиска. По данным Databricks (2025), 87% production LLM-приложений используют RAG вместо fine-tuning: это дешевле в 10-50 раз, позволяет обновлять знания без переобучения и снижает галлюцинации на 40-60%. Эта шпаргалка покрывает выбор embedding-модели, сравнение векторных БД (Pinecone, Qdrant, Milvus, pgvector), стратегии чанкинга, гибридный поиск и метрики оценки RAG-систем.

Тип: synthesis / interview cheat sheet Дата: Февраль 2026 Synthesis of: RAG, embeddings, vector DB, retrieval patterns

Quick Reference: Key Numbers¶

Metric	Value	Context
Embedding dimension	768-4096	Typical models (BGE, OpenAI, Cohere)
Chunk size	256-1024 tokens	Balance context vs precision
Chunk overlap	10-20%	Prevent boundary loss
Top-K retrieval	5-20	Before reranking
Reranker improvement	10-30%	Over embedding-only
Vector DB latency	1-50ms	HNSW, millions of vectors

1. RAG Architecture Patterns¶

Basic RAG¶

Query → Embedding → Vector Search → Top-K Chunks → Prompt + Context → LLM → Response

Advanced RAG Patterns¶

Pattern	Description	Use Case
Multi-query	Generate N variations of query	Improve recall
Hybrid search	Dense + sparse (BM25)	Keyword + semantic
Reranking	Cross-encoder on Top-K	Precision boost
HyDE	Generate hypothetical doc	Better query-doc matching
Parent-child	Retrieve child, return parent	More context
Fusion	Combine multiple retrievers	Diverse sources

RAG Evaluation Metrics¶

Metric	Description	Tool
Faithfulness	Answer supported by context	RAGAS
Answer Relevance	Answer addresses query	RAGAS
Context Precision	Relevant chunks retrieved	RAGAS
Context Recall	All needed info retrieved	DeepEval

2. Embedding Models (2026)¶

MTEB Leaderboard (Feb 2026)¶

Model	Dimension	Avg Score	Notes
GTE-large-en-v1.5	1024	67.3	Alibaba, strong all-around
BGE-large-en-v1.5	1024	64.2	Open-source, popular
OpenAI text-embedding-3-large	3072	65.5	Best for OpenAI ecosystem
Cohere embed-v3	1024	66.8	Commercial, multilingual
E5-mistral-7b	4096	66.0	Higher quality, slower

Selection Criteria¶

Need speed?                 → BGE-small or GTE-small
Need quality?               → GTE-large or E5-mistral
Already using OpenAI?       → text-embedding-3-large
Multilingual?               → Cohere embed-v3 or BGE-m3
Cost-sensitive?             → BGE open-source

Embedding Trade-offs¶

Dimension	Speed	Quality	Storage
384	Fastest	Lower	4× smaller
768	Fast	Good	2× smaller
1024	Medium	Better	Baseline
1536	Slower	High	1.5× larger
3072	Slow	Highest	3× larger

3. Vector Databases¶

Comparison Table¶

DB	Type	Strength	Scale	Query Time
Pinecone	Managed	Easy setup	10M+	5-20ms
Weaviate	Self-hosted	Hybrid search	100M+	10-50ms
Qdrant	Self-hosted	Rust, fast	100M+	5-30ms
Milvus	Self-hosted	Enterprise	1B+	10-100ms
pgvector	Extension	PostgreSQL	10M	20-100ms
Chroma	Embedded	Simple	1M	10-50ms

Index Types¶

Index	Build Time	Query Time	Memory	Accuracy
Flat	None	O(N)	High	100%
IVF	Fast	O(N/C)	Medium	90-95%
HNSW	Slow	O(log N)	High	95-99%
PQ	Fast	O(N/M)	Low	80-90%

Decision Framework¶

<1M vectors?                → pgvector or Chroma
1-10M vectors?              → Qdrant or Weaviate
10-100M vectors?            → Milvus or Pinecone
>100M vectors?              → Milvus distributed

Need exact search?          → Flat index
Memory-constrained?         → IVF + PQ
Need fast queries?          → HNSW
Need hybrid search?         → Weaviate or Qdrant

4. Chunking Strategies¶

Strategies Comparison¶

Strategy	Description	Best For
Fixed-size	N tokens per chunk	Simple, uniform docs
Recursive	Split by separators, then size	General purpose
Semantic	Split by meaning boundaries	Narrative text
Document	One chunk per doc	Short documents
Parent-child	Small retrieval, large context	Need more context

Optimal Chunk Size¶

Document type → Chunk size (tokens)
────────────────────────────────────
Code              → 100-200
FAQ/short docs    → 200-400
General text      → 400-800
Long articles     → 800-1200
Research papers   → 1000-1500

Code Example: Recursive Chunking¶

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""]
)

chunks = splitter.split_text(document)

5. Retrieval Optimization¶

Hybrid Search Formula¶

\[ \text{Score} = \alpha \cdot \text{Dense}(q, d) + (1-\alpha) \cdot \text{Sparse}(q, d) \]

Typical \(\alpha = 0.7\) (favor semantic).

Reranking¶

Reranker	Latency	Quality Boost	Best For
Cross-encoder	50-200ms	20-30%	Highest quality
ColBERT	20-50ms	15-20%	Fast + accurate
LLM-based	500ms+	25-35%	Complex queries

Code: Hybrid + Rerank¶

def hybrid_search(query, k=20, alpha=0.7):
    # Dense retrieval
    dense_results = vector_db.search(query_embedding, k=k*2)

    # Sparse retrieval (BM25)
    sparse_results = bm25.search(query, k=k*2)

    # Reciprocal Rank Fusion
    combined = rrf_fusion(dense_results, sparse_results, alpha)
    top_k = combined[:k]

    # Rerank
    reranked = cross_encoder.rerank(query, top_k)
    return reranked[:10]

RRF (Reciprocal Rank Fusion)¶

\[ \text{RRF}(d) = \sum_{r \in R} \frac{1}{k + \text{rank}_r(d)} \]

Where \(k = 60\) (typical).

6. Advanced RAG Patterns¶

Query Transformations¶

# Multi-query expansion
def multi_query(query, n=3):
    prompts = [
        f"Generate {n} variations of: {query}",
    ]
    variations = llm.generate(prompts)
    return [query] + variations

# HyDE (Hypothetical Document Embedding)
def hyde(query):
    hypothetical_doc = llm.generate(f"Write a document answering: {query}")
    embedding = embed(hypothetical_doc)
    return vector_db.search(embedding)

# Step-back prompting
def step_back(query):
    abstract = llm.generate(f"What is the general concept behind: {query}")
    return search(abstract + query)

Self-Querying¶

# Extract filters from natural language
def self_query(query):
    parsed = llm.generate(f"""
    Extract filters from: {query}
    Return JSON with: {{ "query": "...", "filters": {{...}} }}
    """)
    return vector_db.search(
        query=parsed["query"],
        filters=parsed["filters"]
    )

Adaptive Retrieval¶

def adaptive_rag(query):
    # Decide if retrieval needed
    needs_retrieval = llm.classify(query, ["needs_context", "sufficient"])

    if needs_retrieval == "sufficient":
        return llm.generate(query)

    # Decide retrieval depth
    complexity = llm.classify(query, ["simple", "complex"])

    if complexity == "simple":
        chunks = search(query, k=3)
    else:
        chunks = multi_query_search(query, k=5)

    return llm.generate(query, context=chunks)

7. Production Considerations¶

Caching Strategy¶

graph TD
    Q["Запрос пользователя"] --> EC["Exact Match Cache<br/>(Redis)"]
    EC -->|"HIT (90%+ для FAQ)"| R1["Вернуть кэш"]
    EC -->|MISS| SC["Semantic Cache<br/>(Vector DB, sim > 0.95)"]
    SC -->|HIT| R2["Вернуть похожий"]
    SC -->|MISS| RAG["Full RAG Pipeline<br/>Embedding + Retrieval + Generation"]

    style EC fill:#e8eaf6,stroke:#3f51b5
    style SC fill:#f3e5f5,stroke:#9c27b0
    style RAG fill:#fff3e0,stroke:#ef6c00
    style R1 fill:#e8f5e9,stroke:#4caf50
    style R2 fill:#e8f5e9,stroke:#4caf50

Cost Optimization¶

Technique	Cost Reduction	Quality Impact
Semantic caching	50-80%	None
Prompt compression	30-50%	Minimal
Smaller embedding	20-40%	Small
Fewer retrieved chunks	10-30%	Varies
Quantized embedding	10-20%	Minimal

Latency Breakdown¶

Typical RAG request (100ms total):
───────────────────────────────────
Query embedding:     5-10ms    (5-10%)
Vector search:       5-20ms    (5-20%)
Reranking:           20-50ms   (20-50%)
LLM generation:      50-200ms  (50-80%)

Optimization priority: LLM > Reranking > Search

8. Evaluation & Monitoring¶

RAGAS Metrics¶

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevance

results = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevance]
)

Monitoring Dashboard¶

Metric	Alert Threshold	Action
Retrieval latency	>100ms	Check index, scale
Embedding errors	>1%	Check model health
Context relevance	<0.7	Tune retrieval
Faithfulness	<0.8	Check chunking
Cache hit rate	<50%	Review query patterns

9. Типичные заблуждения¶

Заблуждение: больше чанков в Top-K = лучше качество

Увеличение Top-K с 5 до 50 без reranking снижает precision на 30-40%. Больше контекста = больше шума для LLM. Оптимум: Top-K=20 + cross-encoder reranking до Top-5. По данным RAGAS benchmarks, faithfulness падает с 0.92 до 0.71 при Top-K=50 без reranking.

Заблуждение: cosine similarity > 0.8 значит документ релевантен

Порог релевантности зависит от модели эмбеддингов. Для BGE-large cosine 0.7 может быть отличным результатом, а для OpenAI text-embedding-3 cosine 0.85 -- средним. Всегда калибруйте пороги на своих данных. Более того, cosine similarity не учитывает длину документа и может давать высокие скоры для коротких нерелевантных фрагментов.

Заблуждение: RAG полностью устраняет галлюцинации

RAG снижает галлюцинации на 40-60%, но не устраняет полностью. LLM может игнорировать контекст (faithfulness < 1.0), генерировать детали не из контекста, или комбинировать факты из разных чанков некорректно. Мониторинг faithfulness через RAGAS обязателен в production.

10. Интервью-вопросы¶

Базовые¶

В: Что такое RAG и зачем он нужен?

"RAG -- это когда LLM ищет информацию в базе данных"

"RAG (Retrieval-Augmented Generation) -- паттерн, где перед генерацией LLM получает релевантный контекст из внешнего хранилища через embedding search. Три ключевых преимущества: снижение галлюцинаций на 40-60%, обновление знаний без переобучения модели, и traceable ответы с указанием источников"

В: Объясните стратегии чанкинга

"Просто режем текст на куски по 500 токенов"

"Выбор стратегии зависит от типа документа: fixed-size (100-200 токенов) для кода, recursive splitting по разделителям для общего текста (400-800 токенов), semantic splitting по границам смысла для нарративных текстов. Ключевое -- overlap 10-20% для предотвращения потери контекста на границах чанков. Parent-child стратегия позволяет искать по маленьким чанкам, но возвращать больший контекст"

В: Что такое гибридный поиск?

"Это когда используем и BM25, и эмбеддинги"

"Hybrid search комбинирует dense retrieval (semantic embedding similarity) и sparse retrieval (BM25 keyword matching) через взвешенную формулу Score = alpha * Dense + (1-alpha) * Sparse, где alpha ~0.7. RRF (Reciprocal Rank Fusion) объединяет ранжирования. Гибрид дает +10-15% recall vs только dense, потому что ловит и семантические совпадения, и точные ключевые слова"

Продвинутые¶

В: Сравните индексы HNSW и IVF

"HNSW быстрее, поэтому всегда лучше"

"HNSW -- граф-индекс с O(log N) поиском и 95-99% accuracy, но требует высокого потребления памяти (весь граф в RAM). IVF -- кластерный индекс, быстрее строится, меньше памяти, но 90-95% accuracy. Для < 10M векторов HNSW оптимален. Для > 100M с ограниченной памятью IVF+PQ (Product Quantization) дает 80-90% accuracy при 4x меньшей памяти"

В: Когда использовать reranking?

"Всегда, это улучшает качество"

"Reranking добавляет 50-200ms латентности (cross-encoder), поэтому оправдан только при высоких требованиях к precision. Паттерн: retrieve Top-20-50 кандидатов через bi-encoder, затем rerank до Top-5-10 через cross-encoder. ColBERT дает компромисс: 20-50ms с +15-20% качества. Для FAQ-ботов с low-latency требованиями reranking часто избыточен"

В: Как работать с устаревшими эмбеддингами?

"Просто пересоздаем все эмбеддинги при обновлении модели"

"Четыре стратегии: (1) версионирование эмбеддингов в метаданных, (2) периодическое полное переиндексирование (background job), (3) инкрементальные обновления для измененных документов, (4) freshness scoring с timestamp-взвешиванием. Критично: при смене embedding-модели нужно переиндексировать ВСЕ документы, т.к. cosine similarity между разными моделями не сопоставим"

System Design¶

В: Спроектируйте RAG для корпоративной базы знаний с 1M документов

Перечисление компонентов без обоснования выбора

"Для 1M документов: Qdrant или Milvus с HNSW-индексом (latency 5-30ms). Recursive chunking 512 токенов с 10% overlap. BGE-large эмбеддинги (1024 dims, open-source). Hybrid search (dense + BM25, alpha=0.7). Cross-encoder reranking Top-20 до Top-5. Redis semantic cache (50-80% hit rate на повторяющихся запросах). Мониторинг через RAGAS: faithfulness > 0.8, context precision > 0.7. Итоговая латентность: ~200ms (5ms embedding + 20ms search + 50ms rerank + 100-150ms LLM)"

10. Formulas Quick Reference¶

Cosine Similarity¶

\[\text{sim}(a, b) = \frac{a \cdot b}{\|a\| \|b\|}\]

Reciprocal Rank Fusion¶

\[\text{RRF}(d) = \sum_{r \in R} \frac{1}{k + \text{rank}_r(d)}\]

Hybrid Search Score¶

\[\text{Score} = \alpha \cdot \text{Dense} + (1-\alpha) \cdot \text{Sparse}\]

Faithfulness (RAGAS)¶

\[\text{Faithfulness} = \frac{\text{Supported claims}}{\text{Total claims}}\]

11. Sources Synthesized¶

rag-system-design-2025-2026.md — Architecture patterns
advanced-rag-patterns-2025.md — HyDE, multi-query, fusion
embeddings-mteb-benchmark.md — Model comparison
llm-evaluation-benchmarks.md — RAGAS metrics
feature-stores-comparison.md — Vector DB selection
rag-techniques-vector-databases-2026.md — Pinecone v3, HNSW, hybrid search, RRF (ФАЗА 5)
llm-evaluation-frameworks-2026.md — DeepEval, Ragas framework comparison (ФАЗА 5)
agentic-workflows-multimodal-rag-2026.md — Agentic RAG, multimodal retrieval (ФАЗА 5)