🧠 05. Память и RAG

📌 1. Зачем нужна внешняя память LLM

Определение

RAG (Retrieval-Augmented Generation) — архитектура «поисковая система + LLM»: релевантные фрагменты документов подставляются в контекст перед генерацией ответа.

LLM — stateless. Context window ограничен (4K-1M tokens). Реальные приложения требуют:

• Доступ к знаниям, которых нет в обучающих данных
• Запоминание между сессиями
• Поиск по корпоративным документам
• Персонализацию

RAG (Retrieval-Augmented Generation) = поисковая система + LLM.

📌 2. RAG Pipeline

INGEST:
  Document → Chunk → Embed → Store in Vector DB

QUERY:
  User question → Embed query → Search Vector DB → Top-K chunks → Context → LLM → Answer

flowchart LR
    subgraph ingest["INGEST"]
        Doc["Document"] --> Chunk["Chunk"]
        Chunk --> Embed["Embed"]
        Embed --> VDB["Vector DB"]
    end
    subgraph query["QUERY"]
        Q["User question"] --> QEmbed["Embed query"]
        QEmbed --> Search["Search Vector DB"]
        Search --> TopK["Top-K chunks"]
        TopK --> Context["Context"]
        Context --> LLM["LLM"]
        LLM --> Answer["Answer"]
    end
    VDB --> Search

🔹 Chunking (разбиение на фрагменты)

Sliding Window (скользящее окно):

[chunk1: tokens 0-500] [overlap: 50]
         [chunk2: tokens 450-950] [overlap: 50]
                  [chunk3: tokens 900-1400]

Semantic Chunking (семантическое разбиение):

• Разбивает не по размеру, а по смыслу (через embeddings similarity)
• Лучше для документов с разнородным контентом

Parent-Child (родитель-потомок):

• Маленькие chunks для точного поиска
• Возвращаем большой parent chunk для контекста

Параметры:

• Chunk size: 256-1024 tokens (512 — стандарт)
• Overlap: 10-20% от chunk size

🔹 Embeddings (эмбеддинги)

Модель	Размерность	Контекст	Описание
OpenAI text-embedding-3-large	3072	8191	Топ по качеству
OpenAI text-embedding-3-small	1536	8191	Баланс
BGE-large (open-source)	1024	512	Лучший open-source
E5-large-v2	1024	512	Microsoft
Cohere embed-v3	1024	512	Мультlingual
GLM Embedding-3	2048	8192	Zhipu

Что важно:

• MTEB benchmark — рейтинг embedding моделей
• Размерность влияет на скорость поиска и память
• Multilingual: не все embeddings хорошо работают с русским

🔹 Vector Stores (векторные хранилища)

Store	Type	Когда использовать
Qdrant	Dedicated	Production, scale, filtering
Pinecone	Managed SaaS	Быстрый старт, no ops
Weaviate	Dedicated	Hybrid (vector + keyword)
Milvus	Dedicated	Massive scale (billions)
pgvector	PostgreSQL ext	Если уже есть Postgres
Chroma	Embedded	Prototyping, local
FAISS	Library	In-memory, research

🔹 Retrieval Strategies (стратегии поиска)

На собеседовании

Production RAG почти всегда использует Hybrid Search: dense (embeddings) + sparse (BM25) → re-rank. Чистый dense retrieval плохо находит точные совпадения (имена, код, IDs).

1. Dense Retrieval (стандартный RAG)

query embedding → cosine similarity vs all chunks → top-K

2. Sparse Retrieval (BM25 / keyword)

query → TF-IDF / BM25 → top-K

Лучше для точных совпадений (имена, код, IDs).

3. Hybrid Search (гибридный поиск)

Dense results ∪ Sparse results → re-rank → top-K

Лучший подход для production.

4. Re-ranking (переранжирование) После initial retrieval → cross-encoder re-ranks top-K. Модели: Cohere Rerank, BGE-Reranker, ColBERT.

⚠️ RAG Failure Modes (режимы отказа RAG)

1. “Lost in the Middle” (потеря в середине)

• LLM игнорирует контент в середине context window
• Fix: ставить самые релевантные chunks в начало и конец

2. Conflicting Information (противоречивая информация)

• Два chunks с противоречивой информацией
• Fix: re-ranking, confidence scoring, source attribution

3. Stale Knowledge (устаревшие знания)

• Документы обновились, но embeddings не пересчитаны
• Fix: incremental updates, timestamping

4. Chunk Boundaries (границы фрагментов)

• Ответ разрезан между двумя chunks
• Fix: overlap, parent-child chunking

📌 3. Advanced RAG (продвинутый RAG)

🔹 GraphRAG (Microsoft, 2024)

1. LLM извлекает entities и relationships из документов
2. Строится knowledge graph
3. Community detection → summary каждого community
4. Query → ищем по графу, а не по chunks

Преимущества: лучше для вопросов “как связано X с Y?” Недостатки: дорогой preprocessing, сложнее обновлять.

🔹 Agentic RAG

Вместо одного retrieve → answer:
1. LLM решает: нужен ли поиск?
2. LLM формулирует query (возможно несколько)
3. LLM оценивает: достаточно ли информации?
4. Если нет → дополнительные запросы
5. LLM synthesizes ответ

🔹 Self-RAG

• LLM обучена решать: нужна ли retrieval
• Если да → retrieve → assess → accept/reject
• Adaptive: не всегда нужен RAG

📌 4. Memory в Production Agents (память в production)

🔹 Hermes Memory Architecture

MEMORY.md (memory)     ← факты, окружение, уроки
USER.md (user profile) ← предпочтения пользователя
skills/                ← процедурные знания (SKILL.md)
sessions/              ← эпизодическая память (transcripts)

• Memory инъекция: каждый turn, до 2200/1375 символов
• Session search: FTS5 (full-text search) по прошлым сессиям
• Skill loading: progressive disclosure (description → SKILL.md → references/)

🔹 MemGPT / Letta

• OS-inspired memory hierarchy
• Main context (RAM) → external storage (disk)
• LLM управляет собственной памятью (что грузить, что выгружать)

🔹 LangChain Memory

• ConversationBufferMemory: полная история
• ConversationSummaryMemory: summary через LLM
• ConversationSummaryBufferMemory: гибрид
• VectorStoreRetrieverMemory: vector search по истории

📌 5. Evaluation RAG (оценка RAG)

Важно

Без метрик Faithfulness и Context Recall RAG в production слепой: модель может галлюцинировать поверх retrieved context или не находить нужные документы.

📊 Metrics (метрики)

Faithfulness (достоверность): ответ основан на retrieved context? (не hallucinated) Answer Relevance (релевантность ответа): ответ относится к вопросу? Context Precision (точность контекста): retrieved chunks релевантны вопросу? Context Recall (полнота контекста): весь нужный контекст найден?

🔹 Frameworks (фреймворки)

• RAGAS: автоматическая оценка RAG pipelines
• TruLens: tracking + evaluation
• LangSmith: LangChain’s observability + eval