RAG-pipeline — это производственный конвейер, который связывает поиск знаний в внешнем корпусе с генерацией ответа языковой моделью. Он решает три проблемы, характерные для чистой генерации: устаревание знаний, «галлюцинации» и необъяснимость. Правильно спроектированный RAG-pipeline делает ответы проверяемыми (с цитатами), удешевляет инференс за счёт компактного контекста и упрощает обновление знаний без переобучения моделей.
RAG-pipeline — не одна библиотека, а совокупность этапов: сбор и подготовка данных, разбиение на фрагменты, вычисление векторов, индексация, извлечение кандидатов, гибридный поиск, переранжирование, сжатие выдержек, формирование подсказки, генерация, пост-валидация, логирование и наблюдаемость. В роли генератора выступает LLM, а факты подаются «извне» через хранилища и индексы.
В этой статье — практический взгляд: какие шаги есть в конвейере, какие решения принимаются на каждом шаге, какие метрики и компромиссы определяют качество, скорость и стоимость. Базовые понятия см. во термине «RAG», основы векторных представлений — в «Эмбеддинги», а устройства индексов — в «Векторная база данных». Низкоуровневые детали исполнения генерации — в стеке инференса LLM.
Картина целиком: какие этапы включает RAG-pipeline (Retrieval-Augmented Generation: сквозная архитектура)
Ниже — минимальная, но достаточная декомпозиция. Каждый блок можно улучшать независимо, сохраняя узкие интерфейсы.
- Ингест и очистка: сбор документов из источников, дедупликация, нормализация форматов.
- Разбиение (chunking): делим документы на фрагменты удобного размера.
- Векторизация: считаем эмбеддинги для фрагментов.
- Индексация: записываем (vector, id, metadata) в векторное хранилище; настраиваем индексы и фильтры.
- Извлечение (retrieval): по запросу находим кандидатов (vector/BM25), объединяем, применяем переранжирование.
- Сжатие выдержек: конденсируем кандидатов до фактов, релевантных запросу.
- Сборка подсказки: формируем промт для модели с цитатами/ограничениями.
- Генерация: выдаём ответ; стриминг и контроль декодирования.
- Пост-валидация: вера в источники (faithfulness), соответствие схеме/политикам.
- Наблюдаемость: метрики, трассировки, стоимость, управление версиями.
Часть этапов выполняется офлайн (ингест, индексация), часть — онлайн в критическом пути (retrieval → генерация → валидация).
Ингест, нормализация и контроль качества корпуса
Цель — превратить «сырой мир» документов в предсказуемый поток артефактов для индекса. Важные практики:
- Дедупликация: по хэшу тела и нормализованных заголовков; near-duplicate-поиск для слайдов и PDF.
- Нормализация: единый текстовый формат; сохранение структурных маркеров (заголовки, списки, таблицы).
- Версионность/свежесть: для каждого документа — source_id, version, ts, язык, права доступа (ACL).
- Каталоги/качество: отчёты о доле пустых/битых объектов, «черных списках» источников.
Анти-паттерны: индексация «всего подряд»; смешение приватного и публичного без ACL; хранение HTML-артефактов (баннеры, навигация) внутри чанков.
Разбиение (chunking): компромисс контекста и точности
Chunking определяет баланс между точностью поиска и целостностью фактов.
- Фиксированный размер: 500–1200 токенов; перекрытие 10–20% для сохранения связности.
- Структурный: режем по заголовкам/секциям/параграфам; хорошо для мануалов и политик.
- Семантический: динамические границы по тематическим «изломам»; требует доп. вычислений.
Рекомендация: старт с 700–900 токенов + 15% перекрытия; далее — A/B по Recall@k и стоимости.
Таблица: выбор стратегии chunking
| Корпус | Реком. стратегия | Плюсы | Риски |
| Тех. документация | Структурный + перекрытие | Легко цитировать | Потеря фактов между разделами |
| Статьи/новости | Фиксированный | Простой пайплайн | Дублирование при большом overlap |
| Справочники/нормы | Семантический | Высокая точность | Цена подготовки, контроль качества |
Векторизация и метаданные
Для каждого чанка считаем эмбеддинг, фиксируем метаданные и язык. Практики:
- Единая модель эмбеддингов для индекса и поиска; L2-нормализация векторов.
- Метаданные: source, lang, section, ts, version, acl, «тип» (таблица/код/текст).
- Кэш: повторно используйте векторы для версионных правок (minor edits).
Об основных решениях по векторизации см. «Эмбеддинги».
Индексация: структура хранения и фильтры
Индекс — это не только ANN-структура, но и политики фильтрации. Минимум — фильтры по языку, разделу, свежести и ACL. На больших корпусах полезно шардирование (по доменам/языкам/версиям), репликация для чтения и TTL/soft-delete для устаревших фрагментов. Обзор индексов (HNSW, IVF, PQ) — в «Векторной БД».
Извлечение (retrieval): гибрид всегда устойчивее
Базовые варианты:
- Векторный поиск: семантика и устойчивость к перефразировкам.
- Keyword (BM25): точные имена собственные, артикуля, коды.
- Гибрид: слияние (fusion) результатов; повышает «живучесть» к формулировкам запроса.
Далее — переранжирование компактной моделью или LLM-судьёй: сокращаем «ложноположительные» совпадения и улучшаем top-k. Практический старт: гибрид (веса 0.5/0.5), k_candidates = 50, rerank → top_k = 5.
Таблица: быстрые профили поиска
| Профиль | Что делаем | Когда | Комментарии |
| Семантический | ANN по эмбеддингам | Свободные формулировки | Риск по rare-terms |
| Keyword-центричный | BM25 + фильтры | Нормативы/коды | Быстро и дёшево |
| Гибрид | ANN + BM25 + fusion | Большинство задач | Стабильность к формулировкам |
| С rerank | + компактный ранкер | Длинные документы | ↑ P95, но ↑ точность top-k |
Сжатие выдержек: меньше токенов — ниже цена
Даже лучший top-k часто избыточен. Цель — превратить кандидатов в список фактов: короткие цитаты, поля и таблицы, которые покрывают вопрос. Способы:
- Heuristics: выделение предложений, где встречаются ключевые сущности.
- LLM-сжатие: из каждого чанка извлечь N фактов; объединить без повтора.
- Контекст-пересборка: «кластеризовать» факты по подпросятам (если вопрос сложный).
Сжатие уменьшает контекст и снижает вероятность «размывания» ответа.
Сборка подсказки (prompt assembly)
Подсказка — это контракт: формат ответа, стиль, список цитат с идентификаторами источников, запрет «выдумывать за пределами источников», условия молчания («если нет фактов — ответьте, что недостает данных»). Для структурированных задач задайте JSON-схему.
Минимальная заготовка:
- Инструкции и тон.
- Список выдержек вида [id: …, source: …, snippet: …].
- Требование ссылаться на id и не вводить новых фактов.
- Ограничение длины ответа.
Генерация и декодирование
Режимы декодирования (greedy/beam/top-p/top-k) влияют на стиль и риск «галлюцинаций». Для фактов — консервативные режимы. Экономить токены помогают KV-кэш и маршрутизация по сложности. Нюансы исполнения и оптимизации — см. стек инференса LLM и статью про инференс.
Пост-валидация, политика и безопасность
После генерации — автоматическая проверка:
- Faithfulness/Attribution: содержит ли ответ факты из цитируемых фрагментов; нет ли новых утверждений.
- Схема: соответствие JSON/табличному формату.
- Политики: фильтры тематики/тональности, запрет PII, защита от prompt-injection из документов.
- Ретраи/дополнительный шаг: при провале — запустить исправление (добавочный retrieval или уплотнение цитат).
Наблюдаемость, версии и стоимость
RAG-pipeline без наблюдаемости быстро деградирует. Обязательные артефакты:
- Трейсинг: сквозной trace_id, логи кандидатов, параметры андер-индексов и декодера.
- Версии: модель эмбеддингов, индекс, конфиги retrieval и формат подсказки.
- Стоимость: цена/1k токенов ввода/вывода, доля кэша, P50/P95 по шагам.
- Качество: Recall@k/NDCG@k, faithfulness, Citation@k, доля «безцитатных» ответов.
Таблица: ключевые метрики RAG-pipeline
| Этап | Метрики | Цель |
| Поиск | Recall@k, NDCG@k, MRR | Найти релевантные фрагменты |
| Сжатие | Δтокенов, покрытие фактов | Экономить контекст без потерь |
| Генерация | TTFT, токенов/сек, P95 | UX и SLA |
| Верность | Faithfulness, Citation@k | Проверяемость ответа |
| Стоимость | $/эпизод, $/1k токенов | Держать бюджет |
| Стабильность | Ошибки/ретраи, алерты | Инцидент-менеджмент |
12. Стоимость и производительность: где экономить
Рычаги экономии:
- Chunking и фильтры: меньше «мусора» на вход ANN.
- Гибрид: keyword как pre-filter уменьшает кандидатов.
- Rerank: точнее top-k → меньше контекста.
- Сжатие: короткие факты вместо длинных выдержек.
- Маршрутизация: компактная модель по умолчанию, тяжёлая — по сигналам сложности.
- Квантование: INT8/INT4 веса/кэш; особенно выгодно на длинных диалогах.
Таблица: влияние оптимизаций на стоимость (ориентиры)
| Оптимизация | Экономия токенов | Влияние на P95 | Риск |
| Pre-filter keyword | 10–40% | ↓ | Потеря редких синонимов |
| Rerank top-50→top-5 | 20–60% | ↑ умеренно | Цена ранкера |
| Сжатие выдержек | 30–70% | ↓ | Потеря нюансов |
| Маршрутизация моделей | 20–50% | ≈ | Сложность оркестрации |
| Квантование | — | ↓/≈ | Точность на «краях» |
Масштабирование и эксплуатация
- Шардирование индексов: по языкам/домейнам/версиям; маршрутизация запроса к профилю.
- Replica-read: чтение с реплик, отдельные профили для экспериментов.
- Двойной индекс при миграции эмбеддингов; атомарное переключение конфигов.
- Бэкапы и катастрофоустойчивость: горячие снимки индекса, резерв конфигов.
- A/B и регресс-наборы: слепые сравнения перед выкладкой.
Безопасность и комплаенс
- Источники: санкционированные реестры; лицензии и права использования.
- ACL-фильтры: на уровне индекса, а не пост-фактум.
- Prompt-injection: разделение инструкций и данных; строгий шаблон подсказки; «запрет на исполнение команд» из корпуса.
- PII/секреты: анонимизация, гео-локальные требования, журналы доступа.
Чек-лист внедрения RAG-pipeline
- Определите узкий сценарий и KPI (faithfulness, цена/эпизод, P95).
- Соберите и очистите корпус, зафиксируйте схемы и права.
- Настройте chunking и вычислите эмбеддинги; занесите метаданные.
- Постройте индекс с фильтрами и шардированием; измерьте Recall@k/NDCG@k.
- Включите гибрид (BM25+ANN) и переранжирование; зафиксируйте top-k=3–8.
- Введите сжатие выдержек и строгий шаблон подсказки с цитатами/id.
- Настройте декодирование и кэш; проверьте TTFT и токены/сек.
- Реализуйте пост-валидацию (faithfulness/схема/политики) и ретраи.
- Постройте наблюдаемость: трейсы, стоимость, алерты, отчёты.
- Проведите A/B и готовьте план отката конфигов/индексов.
Анти-паттерны и как их избегать
| Анти-паттерн | Симптом | Что делать |
| «Вектор — и точка» (без keyword) | Падают редкие термины | Включить гибрид и fusion |
| Одинаковый k=20 «на всё» | Дорогой контекст, шум | Жёсткий лимит k=3–8 + rerank |
| «Толстые» чанки | Релевантность падает | 700–900 ток., 15% overlap, A/B |
| Без цитирования | Непроверяемые ответы | Обязательные id-ссылки и атрибуция |
| Нет версионности | Невоспроизводимость | Логировать версии моделей/индексов |
| Один общий индекс | Перемешивание доменов | Шарды/профили и фильтры |
Примеры интерфейсов между шагами
| Откуда → Куда | Вход | Выход |
| Ингест → Индексация | {doc_id, text, lang, ts, acl, meta} | {chunk_id, text, meta} |
| Индексация → Retrieval | {query_vec, filters, k} | [(chunk_id, score, meta)] |
| Retrieval → Prompt | {question, top_k} | {prompt, [(id, source, snippet)]} |
| Генерация → Валидация | {answer, citations} | {ok, issues, fixed?} |
| Валидация → Ответ | {answer*, citations} | {final_answer} |
Звёздочка * — ответ после возможного исправления.
Расширенные варианты RAG
- Многошаговый RAG: последовательные уточнения, «детектив» по корпусу; полезно для сложных аналитических задач.
- Ре-источники: при противоречиях — запросить дополнительные фрагменты и выдать сравнительную таблицу.
- Доменные профили: отдельные индексы и веса для разных линий бизнеса; маршрутизация по языку/региону.
- Инструментальный RAG: помимо выдержек, запуск внешних инструментов (таблицы/конвертеры) по контрактам.
FAQ
Зачем вообще RAG, если можно обучить большую модель? Потому что знания меняются, а бюджет не бесконечен. RAG обновляется данными, а не переобучением, и делает ответы проверяемыми.
Нужна ли всегда переранжировка? Если документы длинные и похожие — почти всегда. Rerank повышает точность top-k и экономит токены.
Каким должен быть размер k? Чаще 3–8. Выше — растёт шум и стоимость, ниже — рискуете упустить факт. Ищите баланс на A/B.
Как бороться с «галлюцинациями»? Требовать цитирования, жёстко ограничивать к выход за контекст, применять валидацию и ретраи с добавочным retrieval.
Как понять, что пайплайн стал хуже? Смотрите на Recall@k/NDCG@k, faithfulness, долю «безцитатных» ответов и P95. Внесите изменения — проверяйте A/B и регресс-набором.
Можно ли обойтись без keyword-поиска? Технически — да, но гибрид почти всегда стабильнее, особенно для терминов/артикулов.
Словарь терминов
- Retrieval — извлечение релевантных фрагментов из индекса.
- Chunking — разбиение документов на фрагменты перед индексацией.
- Эмбеддинг — векторное представление фрагмента/запроса.
- ANN-индекс — структура для быстрого приблизительного поиска соседей.
- Гибридный поиск — объединение keyword и векторного поиска.
- Переранжирование (rerank) — уточняющий ранжировщик для top-N кандидатов.
- Сжатие выдержек — конденсация кандидатов до фактов.
- Faithfulness/Attribution — верность ответов источникам и наличие цитат.
- TTFT — время до первого токена в стриминге.
- A/B-тест — онлайн-сравнение вариантов пайплайна.