RAG: контекст перед генерацией

Что делает слой

RAG — архитектура, в которой перед генерацией ответа система достаёт релевантный контекст из векторной базы или другого хранилища и подставляет его в запрос к модели. Это основной способ снизить галлюцинации и работать с актуальными и приватными данными, которые модель никогда не видела.

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

Фреймворки и их характер

Инструмент	Сильная сторона
LlamaIndex	Загрузка, парсинг и индексация документов
LangChain + LangGraph	Гибкость и агентные сценарии с состоянием
Haystack	Явные, прозрачные пайплайны со встроенной оценкой
RAGFlow, DSPy, LightRAG	Специализированные и более сложные схемы
GraphRAG-подходы	Связи между сущностями, а не только похожесть фрагментов

Фреймворк определяет удобство сборки, но не качество. Качество определяется тем, что происходит до и после поиска.

Где RAG деградирует

• Чанкинг. Слишком крупные чанки размывают смысл и съедают контекст, слишком мелкие теряют связность. Резать по заголовкам и логическим блокам обычно лучше, чем по числу символов.
• Эмбеддинг-модель. Домен важнее рейтинга: документация по WordPress и юридические договоры по-разному ведут себя на одной и той же модели.
• Reranking. Первичный поиск даёт кандидатов, reranker выстраивает их по релевантности к конкретному запросу. Часто даёт больший прирост, чем смена базы.
• Отсутствие оценки retrieval. Если не измерять, находит ли поиск нужный документ, любые изменения — гадание. Метрики и инструменты — в разделе Оценка качества.
• Игнорирование «не найдено». Система обязана уметь сказать «в базе нет ответа», иначе она будет достраивать факты.

RAG без векторной базы

Не всякий retrieval требует эмбеддингов. Рабочие варианты для проекта:

• Структурированный контекст — файлы-контракты (PRODUCT.md, DESIGN.md, AGENTS.md), которые агент читает целиком. Подробнее — Контекст для агентов.
• Публикация для агентов — llms.txt отдаёт карту документации так, чтобы внешний ассистент нашёл нужный раздел без индексации.
• Wiki LLM — курируемая вики на Markdown, где одна страница отвечает за одну тему: агент открывает нужное по каталогу вместо поиска фрагментов, а синтез происходит при записи страницы, а не на каждом запросе. Сравнение с RAG и векторной базой — в разделе Три способа дать агенту знания.
• Точный поиск по коду и документации — grep, glob, полнотекстовый индекс. Для технических задач часто точнее семантики.
• Гибрид — ключевые слова для идентификаторов, векторы для смысла, reranker поверх.

Практика: начинайте с самого дешёвого механизма, который закрывает задачу. Векторная база нужна, когда корпус большой, разнородный и меняется.

Что проверить в проекте

• Обновляется ли индекс. Устаревший RAG опаснее отсутствующего: он уверенно цитирует отменённые правила.
• Видно ли, откуда взят ответ. Ссылки на источники в выдаче — не украшение, а способ разобрать ошибку.
• Совпадает ли язык запроса и документов. Смешанные языки на одной эмбеддинг-модели дают просадку, которую легко принять за «модель тупит».
• Есть ли лимит на объём контекста. Десять найденных чанков вместо трёх удорожают каждый запрос и часто ухудшают ответ.

Материалы и источники

• Системное мышление для агентного ИИ — статья WPCraft, раздел «RAG»