init
This commit is contained in:
707
book/12_rag.md
Normal file
707
book/12_rag.md
Normal file
@@ -0,0 +1,707 @@
|
||||
# ГЛАВА 12. RAG: КОГДА МОДЕЛИ НЕ ХВАТАЕТ СОБСТВЕННЫХ ЗНАНИЙ
|
||||
|
||||
---
|
||||
|
||||
У каждого эксперта есть предел. Он может знать всё о гражданском праве — но не помнить конкретный пункт из приложения к договору, подписанному вчера. Он может блестяще рассуждать об архитектуре ПО — но не знать, что ваша команда три дня назад перешла на новый API. Знания, вшитые в голову (или в веса модели), — это **параметрическая память**. Она мощна, но у неё есть дата отсечения (knowledge cutoff) и физический предел — нельзя запомнить всё.
|
||||
|
||||
Параметрическая память LLM — это то, что модель «выучила» за время тренировки. После деплоя она статична. Новый регламент компании, свежий баг-репорт, обновлённый прайс-лист — модель о них не знает, пока вы не сообщите ей явно.
|
||||
|
||||
Наивное решение — засунуть всё в context window. Как мы разобрали в [Главе 5](05_long_context.md), это путь с квадратичной стоимостью, деградацией качества (Lost in the Middle) и растущей латенси. Запихнуть 500 документов в контекст — это дорого, медленно и ненадёжно.
|
||||
|
||||
**RAG (Retrieval-Augmented Generation)** — альтернативная стратегия: вместо того чтобы давать модели *всё*, дать ей *только то, что нужно*. Библиотекарь не читает все книги в библиотеке перед каждым ответом — он знает, где искать, находит нужный том, открывает нужную страницу и цитирует. RAG превращает LLM из эрудита, ограниченного собственной памятью, в исследователя с доступом к актуальной базе знаний.
|
||||
|
||||
Lewis et al. (2020) формализовали эту идею в рамках NeurIPS: модель, которая *сначала* извлекает релевантные документы, *а потом* генерирует ответ с опорой на них, — превосходит чисто параметрические модели на knowledge-intensive задачах. С тех пор RAG стал одним из базовых паттернов production-систем на LLM.
|
||||
|
||||
---
|
||||
|
||||
## 12.1. Почему context stuffing не масштабируется
|
||||
|
||||
Казалось бы, зачем возиться с retrieval, если у Claude Opus 4.6 контекст 1M токенов? Три причины.
|
||||
|
||||
**Стоимость.** Даже с оптимизациями (Flash Attention (Dao et al., 2022), KV-кэш, PagedAttention (Kwon et al., 2023)), inference стоимость растёт с длиной контекста. Отправить 200K токенов в каждый вызов API — это десятки центов за запрос. При 1000 запросов в день расходы становятся значительными.
|
||||
|
||||
**Качество.** Lost in the Middle (Liu et al., 2023): релевантная информация, помещённая в середину длинного контекста, обрабатывается хуже, чем та же информация в начале или в конце. Модель «видит» длинный контекст, но attention-веса распределяются неравномерно. Подробный разбор — в [Главе 5, раздел 5.3](05_long_context.md).
|
||||
|
||||
**Латенси.** Time-to-first-token растёт с длиной входа. Для интерактивных приложений (чат, поиск, автокомплит) задержка в 5–10 секунд на prefill — неприемлема.
|
||||
|
||||
RAG решает все три проблемы: вместо того чтобы скармливать модели всю базу знаний, мы извлекаем 5–20 релевантных фрагментов и подаём только их. Контекст остаётся коротким, стоимость — низкой, качество — высоким.
|
||||
|
||||
| Стратегия | Стоимость за запрос | Латенси | Качество на 500 документах |
|
||||
|-----------|--------------------|---------|-----------------------------|
|
||||
| Context stuffing (все документы) | $$$ | Высокая (секунды на prefill) | Деградирует (Lost in the Middle) |
|
||||
| RAG (top-10 чанков) | $ | Низкая (~200 мс retrieval + стандартный inference) | Стабильное (фокус на релевантном) |
|
||||
| Fine-tuning | Амортизировано | Быстрая (нет retrieval) | Хорошее для узкой области, не обновляется |
|
||||
|
||||
---
|
||||
|
||||
## 12.2. Анатомия RAG-пайплайна
|
||||
|
||||
Стандартный RAG-пайплайн — это конвейер из шести этапов. Каждый можно настраивать и заменять независимо:
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ Документы │ ─→ │ Чанкинг │ ─→ │ Embedding │
|
||||
│ (корпус) │ │ (нарезка) │ │ (векторы) │
|
||||
└─────────────┘ └─────────────┘ └──────┬──────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ Генерация │ ←─ │ Reranking │ ←─ │ Retrieval │
|
||||
│ (LLM) │ │ (пересорт) │ │ (поиск) │
|
||||
└─────────────┘ └─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
**1. Чанкинг** — нарезка документов на фрагменты фиксированного или переменного размера.
|
||||
**2. Embedding** — превращение каждого фрагмента в вектор в семантическом пространстве (см. [Главу 1](01_tokens_vectors_and_semantic_space.md)).
|
||||
**3. Индексация** — сохранение векторов в хранилище с поддержкой similarity search.
|
||||
**4. Retrieval** — поиск топ-k фрагментов, ближайших к запросу пользователя.
|
||||
**5. Reranking** — пересортировка результатов более точной моделью.
|
||||
**6. Генерация** — LLM генерирует ответ, опираясь на извлечённые фрагменты.
|
||||
|
||||
Этапы 1–3 выполняются **один раз** при индексации корпуса (offline). Этапы 4–6 — **при каждом запросе** (online). Это ключевое архитектурное свойство: RAG разделяет подготовку данных и inference.
|
||||
|
||||
---
|
||||
|
||||
## 12.3. Чанкинг: как нарезать документы
|
||||
|
||||
Чанкинг — первый этап, и ошибки здесь каскадируются на все последующие. Слишком маленькие чанки — точный retrieval, но потерянный контекст. Слишком большие — контекст сохранён, но релевантность размывается.
|
||||
|
||||
### Стратегии чанкинга
|
||||
|
||||
| Стратегия | Размер | Плюсы | Минусы | Когда использовать |
|
||||
|-----------|--------|-------|--------|-------------------|
|
||||
| Fixed-size (по символам/токенам) | 256–1024 токенов | Просто, предсказуемо | Режет предложения и абзацы | Однородные тексты, логи |
|
||||
| Sentence-level | 1–5 предложений | Сохраняет грамматическую целостность | Разброс размеров | Справочные статьи, FAQ |
|
||||
| Recursive (LangChain-стиль) | Адаптивный | Сначала делит по `\n\n`, потом по `\n`, потом по предложениям | Сложнее контролировать | Markdown, документация |
|
||||
| Semantic | Динамический | Группирует по смысловой близости | Требует embedding на этапе чанкинга | Длинные нарративные тексты |
|
||||
| Document-aware | По структуре документа | Учитывает заголовки, разделы, таблицы | Нужен парсер формата | PDF, HTML, код |
|
||||
|
||||
### Overlap
|
||||
|
||||
Overlap (перекрытие) между чанками — 10–20% от размера чанка — решает проблему «разрезанного абзаца». Если критическое предложение попало на границу, перекрытие гарантирует, что оно целиком окажется хотя бы в одном чанке.
|
||||
|
||||
> **Промпт для генерации кода.** *«Напиши recursive text splitter для документов: chunk_size 512 токенов, overlap 64 токена (~12%), разделители по приоритету — двойной перенос строки, одинарный перенос, точка с пробелом, пробел. Используй LangChain RecursiveCharacterTextSplitter или аналог текущей версии фреймворка. Покажи пример нарезки одного документа.»*
|
||||
|
||||
### Практические рекомендации
|
||||
|
||||
- **Документация, база знаний**: recursive splitting, 400–600 токенов, overlap 50–80.
|
||||
- **Код**: document-aware splitting по функциям/классам (tree-sitter для AST).
|
||||
- **Юридические документы**: sentence-level с сохранением номеров пунктов в метаданных.
|
||||
- **Таблицы**: не режьте — сериализуйте строки с заголовками в каждом чанке.
|
||||
|
||||
---
|
||||
|
||||
## 12.4. Embedding и retrieval
|
||||
|
||||
### Dense embeddings
|
||||
|
||||
Embedding-модели превращают текст в вектор фиксированной размерности. Семантически близкие тексты оказываются рядом в пространстве (подробнее — [Глава 1](01_tokens_vectors_and_semantic_space.md)). Для RAG это означает: запрос «как настроить авторизацию» окажется близко к чанку про OAuth, даже если в чанке нет слова «авторизация».
|
||||
|
||||
Популярные модели (2025–2026):
|
||||
|
||||
| Модель | Размерность | Контекст | Особенности |
|
||||
|--------|------------|----------|-------------|
|
||||
| OpenAI `text-embedding-3-large` | 3072 (сжимаемо) | 8K токенов | Matryoshka: можно усечь до 256–1536 dim |
|
||||
| Cohere `embed-v4` | 1536 (по умолчанию; сжимаемо до 256) | 128K токенов | Мультимодальные (текст + изображения), search/classification |
|
||||
| `bge-large-en-v1.5` (BAAI) | 1024 | 512 токенов | Open-source, English |
|
||||
| `bge-m3` (BAAI) | 1024 | 8K токенов | Open-source, мультиязычный, multi-granularity |
|
||||
| Voyage `voyage-4-large` | 1024 (Matryoshka: 256/512/2048) | 32K токенов | Серия voyage-4 (large/standard/lite) |
|
||||
|
||||
**Matryoshka embeddings** (Kusupati et al., 2022) — подход, где первые координаты полного вектора уже сохраняют большую часть полезного сигнала. Это позволяет хранить укороченные векторы (256 dim вместо 3072) с минимальной потерей качества retrieval — и экономить на хранении и скорости поиска.
|
||||
|
||||
### Sparse retrieval: BM25
|
||||
|
||||
Dense embeddings ловят *семантическую* близость — но иногда нужна *лексическая*. Если пользователь ищет «ошибка ERR-4021», dense embedding может не найти точный номер ошибки, зато BM25 найдёт моментально — по точному совпадению терминов.
|
||||
|
||||
BM25 — вероятностная модель ранжирования, основанная на TF-IDF с нормализацией по длине документа. Несмотря на возраст (Robertson et al., 1994), BM25 остаётся конкурентным baseline и в 2026 году.
|
||||
|
||||
### Hybrid search
|
||||
|
||||
Лучшая практика — **гибридный поиск**: объединение dense и sparse retrieval с последующим слиянием результатов.
|
||||
|
||||
```python
|
||||
# Псевдокод: hybrid search с Reciprocal Rank Fusion (RRF)
|
||||
def hybrid_search(query: str, k: int = 10) -> list[Chunk]:
|
||||
dense_results = vector_db.search(embed(query), top_k=k * 2)
|
||||
sparse_results = bm25_index.search(query, top_k=k * 2)
|
||||
|
||||
# Reciprocal Rank Fusion (Cormack et al., 2009)
|
||||
scores: dict[str, float] = {}
|
||||
for rank, chunk in enumerate(dense_results):
|
||||
scores[chunk.id] = scores.get(chunk.id, 0) + 1 / (60 + rank)
|
||||
for rank, chunk in enumerate(sparse_results):
|
||||
scores[chunk.id] = scores.get(chunk.id, 0) + 1 / (60 + rank)
|
||||
|
||||
return sorted(scores, key=scores.get, reverse=True)[:k]
|
||||
```
|
||||
|
||||
RRF (Reciprocal Rank Fusion) — простой и эффективный способ объединения: чем выше документ стоит в каждом списке, тем больше вклад он получает в итоговый score; вклад убывает с номером позиции, после чего результаты суммируются. Это устойчивее, чем нормализация скоров, потому что шкалы dense и sparse метрик — разные.
|
||||
|
||||
### Векторные базы данных
|
||||
|
||||
| База | Тип | Особенности |
|
||||
|------|-----|-------------|
|
||||
| Qdrant | Dedicated | Фильтрация по payload, distributed, Rust |
|
||||
| ChromaDB | Embedded | Простой API, для прототипов |
|
||||
| Pinecone | Managed | Serverless, автомасштабирование |
|
||||
| Weaviate | Dedicated | Hybrid search из коробки, GraphQL |
|
||||
| pgvector | Extension | PostgreSQL-расширение, HNSW-индекс |
|
||||
|
||||
Для прототипа — ChromaDB или pgvector. Для production с > 10M векторов — Qdrant или Pinecone. Критерий выбора: не «какая база модная», а *как она интегрируется с вашим стеком*, поддерживает ли фильтрацию по метаданным и какой latency на вашем объёме.
|
||||
|
||||
### Квантизация
|
||||
|
||||
Хранение 10M векторов по 3072 dim в float32 — это ~115 ГБ. Квантизация (int8, binary) снижает объём в 4–32 раз с потерей ~1–3% retrieval quality. На масштабе — это компромисс, который почти всегда оправдан.
|
||||
|
||||
---
|
||||
|
||||
## 12.5. Reranking и фильтрация
|
||||
|
||||
### Зачем нужен reranking
|
||||
|
||||
Embedding-based retrieval — быстрый, но грубый. Bi-encoder (embedding-модель) обрабатывает запрос и документ *независимо*, а потом сравнивает их векторы. Cross-encoder (reranker) смотрит на пару (запрос, документ) *совместно* — и точнее определяет релевантность.
|
||||
|
||||
Аналогия: bi-encoder — это фильтр по резюме (быстро, но много false positives). Cross-encoder — это техническое собеседование (дороже, но отсеивает точно).
|
||||
|
||||
```
|
||||
Retrieval (top-50, быстро) → Reranking (top-50 → top-5, точно) → LLM (top-5)
|
||||
```
|
||||
|
||||
### Инструменты
|
||||
|
||||
| Reranker | Тип | Особенности |
|
||||
|----------|-----|-------------|
|
||||
| Cohere Rerank | API | Коммерческий, высокое качество |
|
||||
| `bge-reranker-v2-m3` | Open-source | Мультиязычный, можно запустить локально |
|
||||
| `cross-encoder/ms-marco-MiniLM-L-6-v2` | Open-source | Лёгкий, быстрый |
|
||||
| Voyage Rerank | API | Code-aware |
|
||||
|
||||
### Metadata filtering
|
||||
|
||||
Reranking работает на уровне семантики. Но часто нужна фильтрация по метаданным *до* или *вместе* с semantic search. Паттерн: при поисковом запросе передайте вектор запроса, top-k и словарь фильтров (`source`, `updated_after`, `department`, `language`). Все major vector-базы (Qdrant, Weaviate, Pinecone, pgvector) поддерживают metadata-фильтры при search.
|
||||
|
||||
Фильтрация по дате, источнику, отделу, языку — снижает шум и повышает precision без дополнительных вычислений.
|
||||
|
||||
### The retrieval-generation gap
|
||||
|
||||
Важный нюанс: высокое качество retrieval не гарантирует высокое качество генерации. Модель может получить правильные чанки — и всё равно сгаллюцинировать, если:
|
||||
- Чанк содержит нужный факт, но в неочевидной формулировке.
|
||||
- Несколько чанков противоречат друг другу.
|
||||
- Модель «предпочитает» свои параметрические знания извлечённому контексту.
|
||||
|
||||
Этот зазор между retrieval quality и generation faithfulness — одна из центральных проблем RAG. Решение — в правильном prompt engineering (раздел 12.6) и в eval-фреймворках (раздел 12.8).
|
||||
|
||||
---
|
||||
|
||||
## 12.6. Генерация с контекстом: prompt engineering для RAG
|
||||
|
||||
### Инъекция контекста
|
||||
|
||||
RAG-промпт — это промпт с явно выделенной секцией для извлечённого контекста. XML-разметка (см. [Главу 7](07_markup_tags_and_prompt_architecture.md)) — идеальный формат:
|
||||
|
||||
```xml
|
||||
<system>
|
||||
Ты — ассистент технической поддержки. Отвечай ТОЛЬКО
|
||||
на основе предоставленных документов. Если ответа нет
|
||||
в документах — скажи "Информация не найдена в базе знаний".
|
||||
</system>
|
||||
|
||||
<retrieved_documents>
|
||||
<document id="1" source="docs/auth.md" updated="2025-11-15">
|
||||
OAuth 2.0 используется для авторизации внешних приложений.
|
||||
Токен обновления действует 30 дней. Для внутренних сервисов
|
||||
используется mTLS.
|
||||
</document>
|
||||
<document id="2" source="docs/api-limits.md" updated="2026-01-03">
|
||||
Rate limit для API v3: 1000 req/min для плана Enterprise,
|
||||
100 req/min для Free.
|
||||
</document>
|
||||
</retrieved_documents>
|
||||
|
||||
<user_query>
|
||||
Какой rate limit для Enterprise-клиентов?
|
||||
</user_query>
|
||||
|
||||
<instructions>
|
||||
Ответь на вопрос пользователя, цитируя конкретные документы.
|
||||
Формат: [doc_id] после каждого утверждения.
|
||||
</instructions>
|
||||
```
|
||||
|
||||
### Citation grounding
|
||||
|
||||
Требование цитировать источники — один из самых эффективных способов снизить галлюцинации в RAG. Когда модель должна указать `[doc_id]` после каждого утверждения, это:
|
||||
1. **Фиксирует attention** на извлечённых документах, а не на параметрической памяти.
|
||||
2. **Создаёт проверяемый артефакт** — можно программно верифицировать, что cited document действительно содержит claim.
|
||||
3. **Повышает калибровку** — модель реже выдумывает, если знает, что нужно привязать ответ к конкретному источнику.
|
||||
|
||||
### «Отвечай только по документам» — работает ли?
|
||||
|
||||
Инструкция «Answer ONLY based on provided context» снижает extrinsic hallucinations, но не устраняет их полностью. Модели с сильными параметрическими знаниями (GPT-5.4, Claude Opus 4.6) иногда «дополняют» ответ собственными знаниями, даже если промпт запрещает это.
|
||||
|
||||
Повышает надёжность:
|
||||
- Explicit «If the answer is not in the documents, say so» — модели лучше реагируют на явный fallback.
|
||||
- Structured output с полем `"source_doc_id"` — если поле обязательное, модель вынуждена привязаться к документу или вернуть null.
|
||||
- Верификация постфактум — второй вызов или regex-проверка наличия citation (см. [Главу 13](13_anti_hallucination_loop.md)).
|
||||
|
||||
### Handling «Я не знаю»
|
||||
|
||||
RAG-система, которая не умеет отказываться отвечать, — бомба замедленного действия. Если в извлечённых документах нет ответа, модель должна сказать об этом. Это проектируется явно через системный промпт:
|
||||
|
||||
```
|
||||
You are a support assistant.
|
||||
Rules:
|
||||
1. Answer ONLY from <retrieved_documents>.
|
||||
2. Cite [doc_id] for every claim.
|
||||
3. If no document answers the question, respond:
|
||||
{"answer": null, "reason": "Not found in knowledge base"}
|
||||
4. NEVER fabricate information.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 12.7. Продвинутые паттерны
|
||||
|
||||
Базовый RAG (single query → retrieval → generation) — отправная точка. Production-системы часто требуют более сложных архитектур.
|
||||
|
||||
### Multi-hop RAG
|
||||
|
||||
Некоторые вопросы невозможно ответить одним retrieval. «Какой бюджет был у проекта, руководитель которого ушёл в Q3?» — требует сначала найти руководителя, потом найти проект, потом найти бюджет.
|
||||
|
||||
Паттерн: **query decomposition → sequential retrieval → synthesis**.
|
||||
|
||||
```
|
||||
Вопрос: "Какой бюджет у проекта, руководитель которого ушёл в Q3?"
|
||||
|
||||
→ Подзапрос 1: "Кто из руководителей проектов ушёл в Q3?"
|
||||
→ Retrieval → "Иванов, проект Alpha"
|
||||
|
||||
→ Подзапрос 2: "Какой бюджет проекта Alpha?"
|
||||
→ Retrieval → "12.5M руб."
|
||||
|
||||
→ Синтез: "Бюджет проекта Alpha (руководитель Иванов, ушёл в Q3) — 12.5M руб."
|
||||
```
|
||||
|
||||
Это пересекается с chain-of-thought декомпозицией из [Главы 9](09_multistep_reasoning.md), но на уровне retrieval, а не рассуждения.
|
||||
|
||||
### GraphRAG
|
||||
|
||||
Edge et al. (2024) предложили строить **граф знаний** поверх чанков: извлекать сущности и отношения, строить граф, затем использовать community summaries для ответов на сложные вопросы, требующие «глобального» понимания корпуса.
|
||||
|
||||
```
|
||||
Документы → Чанки → LLM извлекает (сущность, отношение, сущность)
|
||||
→ Граф → Community detection → Summaries → Retrieval по summaries
|
||||
```
|
||||
|
||||
GraphRAG силён на вопросах вида «каковы основные темы в этом корпусе» или «как связаны X и Y через цепочку отношений» — то, что плоский vector search не покрывает.
|
||||
|
||||
### RAPTOR
|
||||
|
||||
Sarthi et al. (ICLR 2024): **рекурсивная абстрактивная обработка**. Чанки кластеризуются, для каждого кластера генерируется summary, summaries снова кластеризуются — и так до корневого уровня. Получается дерево абстракций, по которому retrieval может идти на разных уровнях детализации.
|
||||
|
||||
Полезно, когда вопросы варьируются от «что конкретно написано в параграфе 3.2?» до «о чём вообще эта документация?».
|
||||
|
||||
### Self-RAG
|
||||
|
||||
Asai et al. (ICLR 2024): модель сама решает, **когда нужен retrieval**, а когда — нет. На каждом шаге генерации модель выдаёт специальные токены: `[Retrieve]` (нужен поиск), `[No Retrieve]` (знаю сам), `[Relevant]`/`[Irrelevant]` (оценка полученного контекста), `[Supported]`/`[Not Supported]` (самопроверка faithfulness).
|
||||
|
||||
Это элегантнее, чем «всегда ищи» или «никогда не ищи» — модель адаптивно включает retrieval только там, где параметрической памяти недостаточно.
|
||||
|
||||
### HyDE
|
||||
|
||||
Gao et al. (ACL 2023): **Hypothetical Document Embeddings**. Вместо того чтобы искать по запросу пользователя напрямую, модель сначала генерирует *гипотетический документ*, который мог бы содержать ответ, а затем ищет по embedding этого документа.
|
||||
|
||||
```
|
||||
Запрос: "Как настроить mTLS между сервисами?"
|
||||
→ LLM генерирует гипотетический ответ (может быть неточным)
|
||||
→ Embedding гипотетического ответа → Vector search
|
||||
→ Находит реальные документы, семантически близкие к ответу
|
||||
```
|
||||
|
||||
HyDE помогает при vocabulary mismatch: запрос пользователя и документ корпуса могут описывать одно и то же разными словами. Гипотетический документ «переводит» запрос на язык корпуса.
|
||||
|
||||
### Corrective RAG (CRAG)
|
||||
|
||||
Базовый RAG предполагает, что retrieval уже принёс «достаточно хорошие» документы. CRAG (Yan et al., 2024) делает следующий шаг: **сначала оценивает качество retrieval, а потом решает, что делать дальше**.
|
||||
|
||||
Паттерн такой:
|
||||
- retriever возвращает top-k документов;
|
||||
- лёгкий retrieval evaluator выставляет confidence score;
|
||||
- при высоком confidence система сразу идёт в генерацию;
|
||||
- при низком confidence запускается коррекция: web search, альтернативный retriever, очистка или декомпозиция документов.
|
||||
|
||||
Это особенно полезно для шумных корпоративных корпусов, где часть документов устарела, дублируется или противоречит друг другу. CRAG переводит RAG из одношаговой схемы «нашли → сгенерировали» в более надёжную схему **«нашли → оценили → при необходимости исправили → только потом сгенерировали»**.
|
||||
|
||||
---
|
||||
|
||||
## 12.8. Оценка качества RAG-системы
|
||||
|
||||
Без метрик RAG — это чёрный ящик поверх чёрного ящика. Нужно измерять три независимых измерения.
|
||||
|
||||
### Три измерения качества
|
||||
|
||||
```
|
||||
┌─────────────────────┐
|
||||
│ Retrieval Quality │
|
||||
│ (нашли ли нужное?) │
|
||||
└──────────┬──────────┘
|
||||
│
|
||||
┌──────────────┼──────────────┐
|
||||
▼ ▼
|
||||
┌──────────────────────┐ ┌──────────────────────┐
|
||||
│ Faithfulness │ │ Answer Relevancy │
|
||||
│ (ответ верен │ │ (ответ полезен │
|
||||
│ контексту?) │ │ пользователю?) │
|
||||
└──────────────────────┘ └──────────────────────┘
|
||||
```
|
||||
|
||||
1. **Retrieval quality** — нашла ли система нужные документы? Измеряется через context precision (какая доля извлечённых чанков релевантна) и context recall (какая доля нужной информации извлечена).
|
||||
|
||||
2. **Faithfulness** — генерирует ли модель ответ, *верный* извлечённым документам? Или добавляет факты, которых в контексте нет? Это ключевая метрика для RAG: галлюцинация *при наличии правильных документов* — самый коварный режим отказа (см. [Главу 3](03_hallucinations.md)).
|
||||
|
||||
3. **Answer relevancy** — полезен ли ответ пользователю? Можно извлечь правильные документы и сгенерировать faithful ответ, который при этом не отвечает на вопрос.
|
||||
|
||||
Отдельная современная тонкость: retrieval и параметрическая память модели находятся в режиме **tug-of-war**. Даже если вы положили в контекст документ, модель не обязана ему подчиниться; и наоборот, неверный retrieved факт может «переписать» корректный prior модели. Поэтому в eval-наборе полезно иметь не только обычные вопросы, но и **conflict cases**, где retrieved context специально противоречит prior модели. Это быстро показывает, умеет ли система различать «контекст прав» и «контекст шумит».
|
||||
|
||||
### RAGAS framework
|
||||
|
||||
Es et al. (EACL 2024) предложили RAGAS — автоматический eval-framework для RAG, который оценивает все три измерения с помощью LLM-as-a-judge:
|
||||
|
||||
| Метрика | Что измеряет | Как считается |
|
||||
|---------|-------------|---------------|
|
||||
| Context Precision | Доля релевантных чанков в top-k | LLM оценивает каждый чанк |
|
||||
| Context Recall | Покрытие ground-truth ответа контекстом | LLM сопоставляет claims с чанками |
|
||||
| Faithfulness | Все ли claims в ответе подтверждены контекстом | LLM разбивает ответ на claims, проверяет каждый |
|
||||
| Answer Relevancy | Отвечает ли ответ на вопрос | LLM генерирует вопросы по ответу, сравнивает с оригиналом |
|
||||
|
||||
> **Промпт для генерации кода.** *«Настрой eval-пайплайн с RAGAS (ragas.io): подготовь датасет из вопросов, ground-truth-ответов, retrieved contexts и сгенерированных ответов. Оцени метрики faithfulness, context_precision, answer_relevancy. Покажи пример запуска evaluate() и интерпретацию результатов. Целевые значения: faithfulness ≥ 0.85, context_precision ≥ 0.70.»*
|
||||
|
||||
### RAGChecker и более тонкая диагностика
|
||||
|
||||
RAGAS хорошо подходит для быстрой итерации, но часто остаётся слишком грубым инструментом: видно, что «RAG плохой», но не видно, **какой модуль сломался**. Для этого появились более детальные фреймворки, например RAGChecker (Ru et al., 2024), который разносит диагностику по retrieval- и generation-модулю и даёт более точную картину причин деградации.
|
||||
|
||||
Практическое правило:
|
||||
- **RAGAS** — когда нужна быстрая обратная связь в цикле разработки;
|
||||
- **RAGChecker или аналогичная fine-grained диагностика** — когда нужно понять, почему система просела после изменения retriever, reranker, чанкинга или промпта.
|
||||
|
||||
### Ручная оценка
|
||||
|
||||
LLM-as-a-judge — удобно для итеративной разработки, но не заменяет human evaluation. Минимальный протокол:
|
||||
|
||||
1. Соберите 50–100 вопросов, покрывающих типичные сценарии.
|
||||
2. Для каждого зафиксируйте ground-truth ответ и релевантные документы.
|
||||
3. Прогоните RAG-пайплайн, соберите ответы.
|
||||
4. Оцените по шкале 1–5: faithfulness, completeness, relevancy.
|
||||
5. Посчитайте процент critical failures (полностью неверные ответы).
|
||||
|
||||
### Когда RAG проваливается
|
||||
|
||||
RAG не панацея. Типичные режимы отказа:
|
||||
|
||||
| Режим отказа | Причина | Как обнаружить |
|
||||
|-------------|---------|----------------|
|
||||
| Retrieval miss | Нужного документа нет в корпусе | Context recall → 0 |
|
||||
| Relevant but buried | Нужный чанк на позиции 50+, не попал в top-k | Увеличить k, добавить reranking |
|
||||
| Unfaithful generation | Модель игнорирует контекст | Faithfulness metric, citation check |
|
||||
| Contradictory chunks | Два чанка противоречат друг другу | Ручная проверка, metadata filtering по дате |
|
||||
| Bad chunking | Критическая информация разрезана | Проверить чанки вручную, увеличить overlap |
|
||||
| Wrong context dominates prior | Retriever принёс ошибочный факт, и модель послушно встроила его в ответ | Conflict-set eval, retrieval confidence, contradiction check |
|
||||
|
||||
---
|
||||
|
||||
## 12.9. Data layer: жизненный цикл знаний
|
||||
|
||||
В предыдущих секциях мы разобрали, как строить retrieval pipeline: чанкинг, embedding, reranking, генерация. Но в production качество RAG-системы чаще ломается не на этапе retrieval, а на этапе данных: документы устаревают, индекс загрязняется дубликатами, удалённые файлы продолжают отдаваться, а access control игнорируется. Эта секция — про инженерию данных в RAG.
|
||||
|
||||
### Ingestion pipeline: от источника до индекса
|
||||
|
||||
Ingestion — это не одноразовая загрузка, а постоянный pipeline. Источники разнообразны: файлы, базы данных, API, веб-сайты, корпоративные мессенджеры, email.
|
||||
|
||||
Этапы ingestion-конвейера:
|
||||
|
||||
```
|
||||
Источник → Extraction (парсинг формата) → Cleaning (удаление мусора, нормализация)
|
||||
→ Chunking → Enrichment (metadata: source, date, author, ACL)
|
||||
→ Embedding → Indexing
|
||||
```
|
||||
|
||||
Критический этап — **metadata enrichment**. Метаданные, добавленные при ingestion (источник, дата, автор, ACL-тег, версия документа), определяют качество фильтрации на этапе retrieval. Без metadata filtering релевантность падает: система отдаёт устаревшие документы наравне с актуальными, а чанки из разных контекстов смешиваются.
|
||||
|
||||
### Freshness: актуальность индекса
|
||||
|
||||
Документы устаревают. Регламент обновился, API поменялся, сотрудник уволился — а в индексе лежат старые чанки. Два паттерна обновления:
|
||||
|
||||
- **Incremental ingestion** — отслеживание изменений в источнике (webhooks, polling, Change Data Capture). Переиндексируются только изменённые документы. Эффективно, но требует, чтобы источник поддерживал change tracking.
|
||||
- **Full re-index** — периодическая полная переиндексация. Проще в реализации, но дороже по compute. Подходит для источников без change tracking или для небольших корпусов.
|
||||
|
||||
**Provenance tracking**: каждый чанк должен хранить ссылку на исходный документ, дату индексации и версию. Без provenance невозможно отличить свежий чанк от устаревшего — и невозможно корректно удалить данные.
|
||||
|
||||
**Deletion semantics**: при удалении документа из источника все его чанки должны удаляться из индекса. Типичный анти-паттерн — «призраки»: удалённые документы продолжают влиять на ответы, потому что их чанки остались в vector store.
|
||||
|
||||
### ACL-aware индексация и retrieval
|
||||
|
||||
В enterprise-среде не все документы доступны всем пользователям. RAG без access control — это потенциальная утечка данных.
|
||||
|
||||
Два подхода:
|
||||
|
||||
| Подход | Механизм | Плюсы | Минусы |
|
||||
|--------|----------|-------|--------|
|
||||
| Metadata-фильтрация | Запрос + ACL-фильтр при retrieval | Один индекс, проще поддерживать | Embedding «видит» все документы; фильтрация — на финальном этапе |
|
||||
| Tenant-изолированные индексы | Отдельный индекс на tenant/роль | Strict isolation, нет риска утечки | Дороже в поддержке, дублирование общих документов |
|
||||
|
||||
Metadata-фильтрация при retrieval — минимальное требование для production RAG в организациях. Для систем со strict compliance (финансы, медицина) tenant-изоляция надёжнее.
|
||||
|
||||
### Contextual retrieval и enrich-before-embed
|
||||
|
||||
Стандартный embedding чанка теряет контекст документа: чанк из середины регламента превращается в безликий фрагмент. Anthropic Contextual Retrieval (2024): перед embedding'ом каждый чанк обогащается кратким описанием контекста документа, из которого он извлечён (prepended context). LLM генерирует 1–2 предложения: «Этот фрагмент из регламента безопасности, раздел про доступ к production-среде».
|
||||
|
||||
Это улучшает retrieval accuracy без изменения retrieval-алгоритма — за счёт того, что embedding теперь кодирует не только содержание чанка, но и его место в документе. Стоимость: один LLM-вызов на чанк на этапе ingestion. Оправдано для корпусов с высокой ценностью (внутренняя документация, юридические базы); избыточно для ephemeral данных (логи, временные заметки).
|
||||
|
||||
### Re-embed и re-index: миграция embedding-модели
|
||||
|
||||
При смене embedding-модели (новая версия, другой провайдер) все чанки нужно перевекторизовать — старые и новые embeddings несовместимы.
|
||||
|
||||
Практическое правило: **хранить исходный текст чанка**, а не только embedding. Без исходного текста миграция невозможна — придётся заново проходить весь ingestion pipeline от источников.
|
||||
|
||||
**Blue-green indexing**: создаём новый индекс параллельно старому, прогоняем eval-сет на обоих, переключаем трафик после верификации. Это тот же паттерн, что blue-green deployment в backend — только для vector store.
|
||||
|
||||
### Hosted retrieval: File Search и managed RAG
|
||||
|
||||
OpenAI File Search, Google Vertex AI Search, Azure AI Search — managed-решения, где провайдер берёт на себя ingestion, chunking, embedding и retrieval.
|
||||
|
||||
Преимущество: zero-ops для retrieval pipeline — загрузил файлы, получил API для поиска. Недостаток: меньше контроля над chunking-стратегией, выбором embedding-модели и reranking.
|
||||
|
||||
Для быстрого старта и средних нагрузок hosted retrieval часто достаточен. Для тонкой настройки, strict data residency или корпусов с нестандартной структурой (код, таблицы, мультимодальные документы) — self-hosted pipeline даёт больше контроля.
|
||||
|
||||
Качество RAG-системы определяется не только retrieval-алгоритмом, но и дисциплиной управления данными. Ingestion pipeline, freshness, ACL-aware indexing и provenance — это infrastructure, без которой даже идеальный retriever будет отдавать мусор.
|
||||
|
||||
---
|
||||
|
||||
## 12.10. RAG failure diagnosis playbook
|
||||
|
||||
Когда RAG-система даёт неверный ответ, недостаточно сказать «RAG сломался». Нужно определить, *какой именно компонент* отказал. Этот playbook — пошаговая диагностика для каждого из восьми режимов отказа (§12.8).
|
||||
|
||||
### Диагностическая процедура
|
||||
|
||||
Для каждого инцидента фиксируйте в диагностической карточке:
|
||||
|
||||
1. **Вопрос пользователя** — точный текст.
|
||||
2. **Ответ системы** — что вернул RAG.
|
||||
3. **Эталонный ответ** — что должно было быть (из golden dataset или ручная разметка).
|
||||
4. **Извлечённые чанки** — top-k результатов retrieval (до reranking и после).
|
||||
5. **Промпт, отправленный в LLM** — с injected контекстом.
|
||||
6. **Метрики** — faithfulness, context_precision, answer_relevancy (из RAGAS или ручные).
|
||||
|
||||
Теперь — восемь режимов отказа и что делать в каждом.
|
||||
|
||||
---
|
||||
|
||||
### Режим 1: Retrieval miss — нужного документа нет в топе
|
||||
|
||||
**Симптомы:** RAGAS context_precision < 0.5. В извлечённых чанках нет информации, которая есть в корпусе.
|
||||
|
||||
**Диагностика:**
|
||||
1. Вручную проверьте корпус — есть ли в нём ответ на вопрос? Если нет → это не retrieval miss, это missing content (Режим 7).
|
||||
2. Найдите правильный чанк вручную. На какой он позиции в retrieval-результате?
|
||||
3. Проверьте embedding запроса: совпадает ли «язык» запроса с языком корпуса? (разные термины для одного понятия)
|
||||
|
||||
**Исправление:**
|
||||
- Позиция 11-20 → увеличьте k (retrieve top-30 вместо top-10), добавьте reranking.
|
||||
- Позиция 21+ → попробуйте HyDE (§12.7): сгенерируйте гипотетический ответ, ищите по нему.
|
||||
- Систематически → пересмотрите chunking (слишком мелкие чанки теряют контекст), попробуйте contextual retrieval (§12.9).
|
||||
- Разный «язык» → добавьте синонимы в запрос (query expansion), используйте hybrid search (dense + BM25).
|
||||
|
||||
---
|
||||
|
||||
### Режим 2: Relevant but buried — чанк найден, но не в топе
|
||||
|
||||
**Симптомы:** Ручная проверка показывает, что нужный чанк есть на позиции 8-15, но в генерацию попадают только top-5.
|
||||
|
||||
**Диагностика:** Проверьте позицию правильного чанка в retrieval results. Если она стабильно 6-15 → проблема в ранжировании.
|
||||
|
||||
**Исправление:**
|
||||
- Добавьте reranking (cross-encoder) — это самый эффективный способ поднять релевантные чанки.
|
||||
- Увеличьте k для reranking: retrieval top-50 → rerank → top-5.
|
||||
- Проверьте metadata filtering: возможно, правильный чанк имеет устаревшую дату и исключается фильтром.
|
||||
|
||||
---
|
||||
|
||||
### Режим 3: Unfaithful generation — модель игнорирует контекст
|
||||
|
||||
**Симптомы:** RAGAS faithfulness < 0.7. Правильные чанки в контексте есть, но модель генерирует ответ «мимо» них или дополняет своими знаниями.
|
||||
|
||||
**Диагностика:**
|
||||
1. Сравните claims в ответе с содержанием извлечённых чанков (вручную или через RAGAS).
|
||||
2. Есть ли в ответе факты, которых нет ни в одном чанке? → модель использует параметрическую память.
|
||||
3. Есть ли в ответе утверждения, противоречащие чанкам? → модель «переспорила» контекст.
|
||||
|
||||
**Исправление:**
|
||||
- Усилите промпт: `"Answer ONLY using the provided documents. If the answer is not in the documents, say 'Not found in knowledge base'."`
|
||||
- Добавьте citation grounding: требуйте `[doc_id]` после каждого утверждения (§12.6).
|
||||
- Используйте structured output с обязательным полем `source_doc_id` — модель вынуждена привязаться к документу.
|
||||
- Добавьте Verifier (Глава 13): второй LLM-вызов проверяет faithfulness ответа.
|
||||
- Проверьте conflict cases: возможно, retrieved context противоречит сильным prior модели — тогда модель «выбирает» prior.
|
||||
|
||||
---
|
||||
|
||||
### Режим 4: Contradictory chunks — чанки противоречат друг другу
|
||||
|
||||
**Симптомы:** Ответ модели непоследователен. В retrieved chunks есть взаимоисключающая информация (например, «API v1 активен» и «API v1 отключён с марта»).
|
||||
|
||||
**Диагностика:** Просмотрите retrieved chunks на предмет противоречий. Обратите внимание на даты — часто противоречие вызвано устаревшим документом.
|
||||
|
||||
**Исправление:**
|
||||
- Metadata filtering по дате: `updated_after: 2025-01-01` или `version: latest`.
|
||||
- Provenance tracking (§12.9): каждый чанк хранит дату индексации и версию исходного документа.
|
||||
- В промпт добавьте инструкцию: `"If documents contradict each other, prefer the most recent one (by date). If ambiguity remains, state both positions with sources."`
|
||||
- Deletion semantics: убедитесь, что удалённые документы действительно удалены из индекса.
|
||||
|
||||
---
|
||||
|
||||
### Режим 5: Bad chunking — информация разрезана
|
||||
|
||||
**Симптомы:** Извлечённый чанк содержит часть нужной информации, но ответ модели неполный или неверный. При ручной проверке видно, что соседний чанк содержит недостающую часть, но она не попала в контекст.
|
||||
|
||||
**Диагностика:** Просмотрите retrieved chunks. Есть ли «оборванные» предложения на границах? Числа, отделённые от единиц измерения? Таблицы, разрезанные пополам?
|
||||
|
||||
**Исправление:**
|
||||
- Увеличьте overlap до 20-25% от размера чанка.
|
||||
- Перейдите на семантический или document-aware chunking (§12.3).
|
||||
- Для таблиц: не нарезайте их — сериализуйте с повторением заголовков в каждом чанке.
|
||||
- Проверьте recursive splitting: правильный ли порядок разделителей? Добавьте domain-specific разделители.
|
||||
|
||||
---
|
||||
|
||||
### Режим 6: Missing content — ответа нет в корпусе
|
||||
|
||||
**Симптомы:** RAGAS context_recall = 0. Ручная проверка корпуса подтверждает: ответа на вопрос действительно нет в проиндексированных документах. RAG не сломан — просто знания отсутствуют.
|
||||
|
||||
**Диагностика:** Проверьте корпус вручную. Может ли человек найти ответ? Если нет → missing content.
|
||||
|
||||
**Исправление:**
|
||||
- Расширьте корпус: добавьте недостающие документы.
|
||||
- Настройте fallback: если retrieval confidence ниже порога → web search или «я не знаю».
|
||||
- Используйте Corrective RAG (CRAG, §12.7): при низком confidence retrieval → автоматический web search.
|
||||
- В промпте — явный fallback: `"If no document answers the question, respond: {'answer': null, 'reason': 'Not found in knowledge base'}"`.
|
||||
|
||||
---
|
||||
|
||||
### Режим 7: Wrong context dominates prior — неверный чанк «переубедил» модель
|
||||
|
||||
**Симптомы:** Retrieval принёс ошибочный или устаревший факт. Модель использовала его для ответа, проигнорировав свои (верные) параметрические знания. Ответ неверен, но faithful по отношению к неверному контексту.
|
||||
|
||||
**Диагностика:** Faithfulness высокий (> 0.85), но ответ фактически неверен. Проверьте: если убрать retrieved context и задать вопрос напрямую — модель отвечает правильно? Если да → проблема в контексте, не в модели.
|
||||
|
||||
**Исправление:**
|
||||
- Reranking: качественный reranker должен опустить неверный чанк.
|
||||
- Добавьте conflict cases в eval-набор: пары (правильный факт, контекст с неправильным фактом) — проверяйте, что модель выбирает контекст только когда он достовернее prior.
|
||||
- Retrieval confidence: если все retrieved chunks имеют низкий similarity score → fallback к «я не знаю».
|
||||
- Metadata filtering: исключите устаревшие документы по дате или версии.
|
||||
|
||||
---
|
||||
|
||||
### Режим 8: Query formulation mismatch — запрос и корпус на «разных языках»
|
||||
|
||||
**Симптомы:** Пользователь использует разговорные термины («как ускорить сайт»), а корпус — технические («оптимизация TTFB и LCP»). Embedding близости нет, retrieval пустой.
|
||||
|
||||
**Диагностика:** Сравните формулировку запроса с формулировками в корпусе. Есть ли семантическая близость? Проверьте cosine similarity запрос-чанк.
|
||||
|
||||
**Исправление:**
|
||||
- HyDE (§12.7): сгенерируйте гипотетический ответ «техническим языком», ищите по нему.
|
||||
- Query expansion: добавьте синонимы и технические термины к запросу.
|
||||
- Hybrid search: BM25 поймает точные совпадения терминов, dense — семантическую близость.
|
||||
- Multi-query retrieval: сгенерируйте 3-5 переформулировок запроса, объедините результаты.
|
||||
|
||||
---
|
||||
|
||||
### Диагностическая карточка инцидента
|
||||
|
||||
Используйте этот шаблон для каждого production-инцидента RAG:
|
||||
|
||||
```text
|
||||
## RAG Incident #NNN
|
||||
- Дата: [YYYY-MM-DD HH:MM]
|
||||
- Вопрос: [точный текст]
|
||||
- Ответ системы: [текст]
|
||||
- Эталонный ответ: [текст или null]
|
||||
- Режим отказа: [1-8]
|
||||
- Root cause: [конкретный компонент/настройка]
|
||||
- Исправление: [что изменено]
|
||||
- Верификация исправления: [повторный прогон на этом и похожих кейсах]
|
||||
- Добавлен в eval-набор: [да/нет, ID тест-кейса]
|
||||
```
|
||||
|
||||
> **Промпт для ИИ:** «Напиши Python-скрипт для автоматической диагностики RAG-инцидента. Принимает: запрос, ответ системы, retrieved chunks (до и после reranking), ground-truth ответ (опционально). Автоматически определяет вероятный режим отказа (1-8) по правилам: (1) нет релевантных чанков → режим 1/6/8; (2) чанки есть, но faithfulness низкий → режим 3; (3) в чанках противоречия → режим 4; (4) ответ faithful, но неверен → режим 7. Генерирует diagnostic report в Markdown. Используй RAGAS для расчёта faithfulness и context_precision.»
|
||||
|
||||
---
|
||||
|
||||
## Практический вывод
|
||||
|
||||
### Когда RAG, когда long context, когда fine-tuning
|
||||
|
||||
| Критерий | RAG | Long context | Fine-tuning |
|
||||
|----------|-----|-------------|-------------|
|
||||
| Данные обновляются часто | Индексируй заново | Перезагрузи весь контекст | Переобучи модель |
|
||||
| Нужна точная цитата | Citation grounding | Возможно, но сложнее | Модель не цитирует |
|
||||
| Объём данных > 1M токенов | Масштабируется | Не влезет в контекст | Ограничено |
|
||||
| Нужен специфический «тон» | RAG не меняет поведение | Аналогично | Обучает стилю |
|
||||
| Латенси критична | Retrieval добавляет ~100–300 мс | Prefill долгий | Нет overhead |
|
||||
| Простота реализации | Пайплайн из 6 компонент | Просто — запихни в контекст | Нужны данные и GPU |
|
||||
|
||||
**Правило:** RAG — для актуальных фактов из большого корпуса. Long context — для коротких документов (< 100K токенов), когда retrieval overhead не оправдан. Fine-tuning — для изменения поведения модели, а не для вливания фактов (факты забываются после fine-tuning — catastrophic forgetting).
|
||||
|
||||
### Чеклист: минимальный production RAG
|
||||
|
||||
1. **Чанкинг**: recursive splitting, 400–600 токенов, overlap 50–80. Проверьте вручную 20 чанков — читаемы ли они?
|
||||
2. **Embedding**: начните с `text-embedding-3-large` или `bge-m3`. Matryoshka-редукция до 512–1024 dim для экономии.
|
||||
3. **Vector store**: pgvector для MVP, Qdrant для production.
|
||||
4. **Hybrid search**: dense + BM25 + RRF. Это baseline, который обычно лучше чистого dense.
|
||||
5. **Reranking**: всегда. Даже лёгкий `bge-reranker` добавляет 3–8% к retrieval precision.
|
||||
6. **Prompt**: XML-разметка, citation grounding, explicit «I don't know» fallback.
|
||||
7. **Eval**: RAGAS + 50 ручных вопросов. Отслеживайте faithfulness ≥ 0.85.
|
||||
8. **Мониторинг**: логируйте retrieval results, latency, user feedback.
|
||||
|
||||
### Типичные ошибки
|
||||
|
||||
- **Нет reranking**. Top-k от embedding-поиска содержит 30–50% нерелевантного шума. Без reranking модель получает плохой контекст.
|
||||
- **Нет eval**. «Вроде работает» — это не метрика. Без faithfulness/relevancy вы не знаете, что сломалось.
|
||||
- **Слепое доверие retrieval**. Retrieval нашёл — значит, правда? Нет. Устаревший документ, чанк с противоречием, неполная информация — всё это попадает в контекст.
|
||||
- **Плохой чанкинг**. Разрезали таблицу пополам, потеряли заголовок, оторвали число от его описания — и модель галлюцинирует, потому что контекст бессмыслен.
|
||||
- **Игнорирование метаданных**. RAG без фильтрации по дате, источнику, версии — это поиск без фильтров: найдёт, но не обязательно то, что нужно *сейчас*.
|
||||
- **Нет систематической диагностики отказов**. Когда RAG ошибается, недостаточно править промпт наугад. Используйте **RAG failure diagnosis playbook** (§12.10): восемь режимов отказа с пошаговой процедурой диагностики и исправления для каждого.
|
||||
|
||||
### Задания
|
||||
|
||||
1. **Постройте минимальный RAG-пайплайн.** Возьмите 20–50 документов из вашего проекта (документация, FAQ, регламенты). Нарежьте recursive splitter'ом (400–600 токенов, overlap 50–80), проиндексируйте в pgvector или ChromaDB, подключите reranker. Составьте 10 вопросов с эталонными ответами. Измерьте faithfulness и context_precision через RAGAS. **Ожидаемый результат:** работающий пайплайн с базовыми метриками; понимание, где теряется качество — на этапе retrieval или генерации.
|
||||
|
||||
2. **A/B-тест dense vs. hybrid retrieval.** На том же корпусе сравните два режима: (a) только dense embedding search, (b) hybrid (dense + BM25 + RRF). Прогоните одинаковый набор из 10+ вопросов, сравните context_precision и answer_relevancy. **Ожидаемый результат:** количественная оценка прироста от гибридного поиска на ваших данных (типичный выигрыш — 5–15% precision).
|
||||
|
||||
3. **Проверьте чанкинг вручную.** Выберите 20 случайных чанков из индекса и оцените: читаемы ли они без окружающего контекста? Сохранён ли смысл? Не разрезана ли таблица или список? **Ожидаемый результат:** список проблемных чанков и скорректированные параметры splitter'а.
|
||||
|
||||
4. **Проведите диагностику RAG-инцидента.** Возьмите 3 реальных кейса, где RAG-система дала неверный ответ. Для каждого заполните диагностическую карточку, определите режим отказа, найдите root cause, предложите и примените исправление. Измерьте метрики до и после. **Ожидаемый результат:** 3 заполненные карточки + улучшение faithfulness/context_precision минимум на 10 п.п. для исправленных кейсов.
|
||||
|
||||
---
|
||||
|
||||
## Источники
|
||||
|
||||
- Lewis, P., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020.
|
||||
- Gao, Y., et al. (2024). "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997.
|
||||
- Edge, D., et al. (2024). "From Local to Global: A Graph RAG Approach to Query-Focused Summarization." Microsoft Research.
|
||||
- Sarthi, P., et al. (2024). "RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval." ICLR 2024.
|
||||
- Asai, A., et al. (2024). "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." ICLR 2024.
|
||||
- Yan, S., et al. (2024). "Corrective Retrieval Augmented Generation." arXiv:2401.15884.
|
||||
- Es, S., et al. (2024). "RAGAS: Automated Evaluation of Retrieval Augmented Generation." EACL 2024.
|
||||
- Ru, D., et al. (2024). "RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation." arXiv:2408.08067.
|
||||
- Wu, K., Wu, E., Zou, J. (2025). "ClashEval: Quantifying the tug-of-war between an LLM's internal prior and external evidence." arXiv:2404.10198.
|
||||
- Gao, L., et al. (2023). "Precise Zero-Shot Dense Retrieval without Relevance Labels." (HyDE) ACL 2023.
|
||||
- Liu, N., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." TACL.
|
||||
- Kwon, W., et al. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP 2023.
|
||||
- Kusupati, A., et al. (2022). "Matryoshka Representation Learning." NeurIPS 2022.
|
||||
- Robertson, S., et al. (1994). "Okapi at TREC-3." NIST Special Publication.
|
||||
- Anthropic. (2024). "Introducing Contextual Retrieval." Anthropic Blog.
|
||||
|
||||
---
|
||||
|
||||
**Навигация:**
|
||||
- Назад: [Глава 11. Не заставляй модель считать — дай ей инструмент](11_tools.md)
|
||||
- Далее: [Глава 13. Антигаллюцинационный контур и защита от деградации](13_anti_hallucination_loop.md)
|
||||
Reference in New Issue
Block a user