Что такое RAG, как устроен пайплайн и от чего зависит качество ответов?
Короткий ответ
- LLM отвечает по найденным документам, а не по памяти
- Индексация: чанкинг, эмбеддинги, векторная база
- Поиск: векторный плюс BM25, затем реранкер
- Найденный контекст подставляется в промпт с инструкциями
- Качество решается на этапе retrieval, не генерации
- Снижает галлюцинации и даёт актуальность без дообучения
- Оценка: метрики поиска и верность ответа источникам
RAG соединяет поиск по базе знаний с генерацией LLM, и качество системы определяется прежде всего качеством чанкинга и retrieval, а не только моделью.
Как сказать вслух
пример ответаRAG — это схема, где модель отвечает не из памяти, а по документам, которые мы для неё нашли. Сначала базу знаний режут на фрагменты и превращают в векторы, потом по запросу находят релевантные куски и подкладывают их в промпт. Это даёт актуальные ответы со ссылками на источники без дообучения модели. По опыту, большинство проблем таких систем — это плохой поиск, а не плохая генерация.
Подробный ответ
Основной ответ
RAG (retrieval-augmented generation) — архитектура, где перед генерацией ответа система находит релевантные фрагменты базы знаний и передаёт их LLM в контексте. Пайплайн: офлайн — документы чистятся, режутся на чанки (с перекрытием, по структуре документа), кодируются embedding-моделью и складываются в векторный индекс с метаданными; онлайн — запрос кодируется, выполняется поиск (часто гибрид: векторный плюс лексический BM25), кандидаты пересортировываются cross-encoder-реранкером, топ попадает в промпт с инструкцией отвечать только по источникам и цитировать их. Качество определяют: стратегия чанкинга, выбор embedding-модели под язык и домен, гибридный поиск и реранкинг, обработка запроса (переформулировка, разбиение сложных вопросов). Оценивают раздельно retrieval (recall@k, MRR) и генерацию (faithfulness — верность источникам, relevance), часто с LLM-судьёй.
Ключевые моменты
- Зачем RAG вместо fine-tuning. Знания обновляются переиндексацией за минуты, есть ссылки на источники и контроль доступа к документам.
- Чанкинг решает. Слишком мелкие чанки теряют контекст, крупные размывают поиск; резать лучше по структуре документа с перекрытием.
- Гибрид и реранкер. Векторный поиск ловит смысл, BM25 — точные термины и артикулы; cross-encoder заметно поднимает точность топа.
- Оценка по частям. Сначала измерить, находится ли нужный фрагмент (recall@k), потом — отвечает ли модель верно по найденному.
Практический контекст
К 2026 году RAG — самая массовая прикладная LLM-задача: базы знаний, саппорт-боты, поиск по внутренним документам. На собеседовании ждут не пересказ аббревиатуры, а инженерные детали: как резать документы, зачем гибридный поиск, как померить качество и как дебажить «модель не нашла ответ». Сильный сигнал — рассказ о конкретных граблях: таблицы в PDF, устаревшие версии документов, дубли.
Частые ошибки
- Описывают RAG одной фразой, но не могут объяснить ни чанкинг, ни реранкинг
- Все проблемы качества пытаются чинить промптом генератора, не измеряя retrieval
- Не знают, как оценивать систему, кроме «посмотреть глазами на ответы»