RAG

RAG (Retrieval-Augmented Generation) — техника, в которой LLM перед ответом достаёт из внешней базы релевантные документы и использует их как контекст. Это помогает работать с обновляемыми знаниями и проверяемыми источниками, но не устраняет ошибки автоматически. Система может использовать векторный, полнотекстовый, графовый или гибридный поиск, а затем добавляет найденное в контекст модели.

Коротко

Коротко. RAG — это «модель плюс библиотека». Перед ответом система ищет в базе документов те, что относятся к вопросу, и подсовывает их LLM как контекст. Модель отвечает не «из памяти весов», а по конкретным фрагментам с возможностью указать источник. Это убирает галлюцинации, не требует переобучения и позволяет работать с свежими данными.

Что это такое

Лето 2023-го. Стартап делает чат-бот для службы поддержки. Через месяц модель готова — и тут же выясняется, что половина продукта изменилась. Дообучать заново? Это дорого, долго, и каждое изменение в продукте требует нового обучения.

Тогда команда смотрит в сторону другого подхода. Вместо того чтобы «запихнуть знания внутрь модели», она хранит документы отдельно. Перед ответом система ищет релевантные фрагменты и подаёт их LLM как контекст. Модель остаётся той же, а документы можно обновлять и переиндексировать независимо.

Это и есть RAG. Retrieval (поиск) + Augmented (расширение) + Generation (генерация). Идея простая, но именно она сделала LLM пригодными для бизнеса: компания не отдаёт данные в обучение OpenAI, не платит за fine-tuning, может обновлять базу как обычные документы — а модель отвечает поверх них.

Платный ChatGPT с подключением Google Drive — это RAG. Cursor IDE с пониманием вашего кода — это RAG. Perplexity, которая отвечает с источниками — RAG.

Весь pipeline — от нарезки документов до reranking и ответа с источниками — показан в большом разборе «RAG и AI-поиск». Эта статья объясняет сам термин, а разбор показывает, как из компонентов собирается поисковая система.

Как это работает

Базовый RAG-пайплайн — 5 шагов.

1. Indexing (заранее). Все документы базы превращаются в embedding'и. Длинные документы разбиваются на куски (chunks) по 200–800 токенов. Каждый чанк хранится в векторной БД вместе с исходным текстом и метаданными.
2. Embedding запроса. Когда пользователь задаёт вопрос, его текст превращается в embedding той же моделью, которой индексировали базу.
3. Vector search. Векторная БД находит top-K самых близких embedding'ов (обычно 3–10). Это потенциально релевантные куски.
4. Augmented prompt. Найденные тексты подставляются в промпт LLM перед самим вопросом:

   Используя контекст ниже, ответь на вопрос.
   Если ответа нет в контексте — скажи «не знаю».
   
   Контекст:
   [фрагмент 1]
   [фрагмент 2]
   ...
   
   Вопрос: ...
   
   

5. Generation. LLM генерирует ответ, опираясь на поданные документы. Часто просят указать источник для каждого факта.

Что делает RAG мощным:

• Свежие данные. Обновили документы → следующий запрос уже использует новое.
• Цитируемость. Модель может указать, из какого документа взяла факт. Это критично в юридических, медицинских, корпоративных задачах.
• Контроль источников. В обучение модели вы не лезете, но контролируете, какие документы доступны.
• Снижение галлюцинаций. Когда модель отвечает на основе конкретного текста, она реже выдумывает.

Простой технологический стек:

Компонент	Open-source	Облако
Embedding-модель	bge-small, all-MiniLM	OpenAI text-embedding-3-small, Cohere
Векторная БД	Chroma, Qdrant, Weaviate	Pinecone, Weaviate Cloud, Vespa
LLM	локальная instruct-модель	облачная модель через API
Оркестрация	LangChain, LlamaIndex	те же

Пример на практике

Видеомонтажёр строит AI-помощника по своей базе знаний — 200 markdown-файлов с приёмами, чек-листами, настройками плагинов. Хочет задавать вопросы и получать ответы с цитатами из своих заметок.

Стек:

• Embedding: bge-small-en-v1.5 (130 МБ, CPU).
• Vector DB: Chroma (in-memory, потом на диск).
• LLM: совместимая локальная или облачная модель, выбранная по качеству ответа и инфраструктуре.

Шаг 1 — Indexing. Скрипт читает набор документов, делит их на фрагменты, считает embeddings и сохраняет их в индекс. Размер chunk и overlap выбираются по структуре текста и проверяются retrieval-тестом; время зависит от корпуса, модели и устройства.

Шаг 2 — запрос. Вопрос: «как я настраивал звук для интервью под открытым небом».

Шаг 3 — vector search. Chroma находит 5 ближайших векторов. Это куски из заметок: «работа с RODE NTG», «де-эссинг в DaVinci», «выезд на пленер», «контроль ветра микрофоном».

Шаг 4 — augmented prompt:

Ответь на основе контекста ниже. Цитируй каждый факт указанием [номер фрагмента].

Контекст:
[1] Использую RODE NTG-3 с ветрозащитой Rycote Softie...
[2] В DaVinci для голоса: компрессор 4:1, де-эссер 6–8 kHz...
[3] На улице — ветрозащита Mute Box или Dead Cat...

Вопрос: как я настраивал звук для интервью под открытым небом?

Шаг 5 — ответ модели:

«Для интервью под открытым небом ты использовал RODE NTG-3 с ветрозащитой Rycote Softie [1] и дополнительной Mute Box на сильный ветер [3]. В постпродакшене в DaVinci: компрессор 4:1, де-эссер на 6–8 kHz [2].»

Ответ конкретный, цитирует фрагменты, говорит только о том, что есть в заметках. Если бы Llama отвечала «из памяти весов», получили бы общее «используйте качественный микрофон» без привязки к вашим реалиям.

В ComfyUI весь этот пайплайн собирается визуально: ноды Document Loader → Text Splitter → Embedding → Vector Store → LLM. Тот же подход — для image-RAG (искать похожие картинки) или мультимодального (текст ↔ картинка).

С чем часто путают

• RAG и Fine-tuning — fine-tuning меняет параметры модели. RAG не меняет ничего — добавляет внешний контекст. Дешевле, быстрее, обновляемо.
• RAG и semantic search — semantic search это половина RAG (этап retrieval). RAG = semantic search + LLM, который формулирует ответ.
• RAG и context window — context window это вместимость одного запроса. RAG помещает в этот контекст только релевантные куски, а не всю базу.
• RAG и веб-поиск с LLM — Perplexity, ChatGPT Browse, Gemini с Google — это RAG, где источник — интернет, а не локальная база.
• RAG и memory в чат-ботах — memory обычно тоже использует RAG: хранит факты о пользователе как документы, перед каждым запросом достаёт релевантные.

Частые ошибки и заблуждения

• «RAG — это сложно». Базовая реализация — 100 строк Python с LangChain или LlamaIndex. Сложности возникают на масштабе и в продакшене, не на старте.
• «RAG полностью убирает галлюцинации». Нет. Он даёт модели источники, но поиск может вернуть не тот фрагмент, а модель — неверно его прочитать или добавить лишнее утверждение.
• «Чем больше документов передать модели, тем лучше ответ». Не работает. Слишком много контекста → «lost in the middle», деградация качества. Оптимум — 3–7 самых релевантных кусков.
• «RAG работает с любыми документами». PDF, презентации, скриншоты требуют сначала извлечения текста (OCR, парсинг таблиц). Качество извлечения — отдельная проблема.
• «Embedding-модель не важна, лишь бы была сильная LLM». Нерелевантные фрагменты ограничивают любой генератор. Retrieval оценивают recall и качеством кандидатов до генерации ответа.

Связанные термины

• Embedding — фундамент RAG: превращает текст в вектор для поиска.
• Vector Database — хранилище embedding'ов и поиск по близости.
• Chunking — разбиение длинных документов на части для индексации.
• Reranking — пере-сортировка найденных кусков более точной моделью.
• Hybrid search — комбинация keyword-поиска и векторного.
• LLM — модель, генерирующая финальный ответ из retrieved-контекста.
• Prompt Engineering — критично для качества augmented prompt'а.
• Hallucination — основная проблема, которую RAG смягчает.

Частые вопросы

Сколько документов можно держать в RAG? В Chroma локально — до миллиона chunks комфортно. Qdrant, Pinecone, Weaviate в облаке — миллиарды. Латентность поиска даже на больших объёмах остаётся в пределах секунды.

RAG требует больше токенов на запрос? Да. К промпту добавляются 1–5 тысяч токенов retrieved-контекста. Это удорожает каждый запрос, но обычно выгоднее fine-tuning'а.

Как обновлять документы в RAG? Изменённый документ переразбивается на куски, embedding пересчитывается, старые вектора удаляются из БД и заменяются новыми. Все vector DB поддерживают это нативно.

Чем хорош Reranking поверх retrieval'а? Vector search быстрый, но не самый точный. Reranking берёт top-50 от vector search и пересортирует через более точную (и медленную) cross-encoder модель. Получаем top-5 высокого качества. Стандарт в production.

Можно ли использовать RAG только для собственных документов? Конечно. Это и есть основной use-case: компанийная база, личная коллекция заметок, корпус кода, документация продукта. Главное — embedding не «утекает» в OpenAI (если использовать локальную модель).

Главное

RAG связывает LLM с внешними данными через понятный пайплайн: найти материалы → добавить их в контекст → подготовить ответ. Он особенно полезен, когда сведения часто обновляются или ответ должен опираться на документы. Fine-tuning решает другую задачу: меняет поведение модели, но сам по себе не превращает её в надёжный источник актуальных фактов.