Схему RAG обычно рисуют из трёх блоков: поиск, модель, ответ. Работающая система состоит примерно из десяти шагов, и разница между тремя и десятью — это и есть разница между демонстрацией и промышленной эксплуатацией.
Ниже — полная схема с указанием, что делает каждый шаг и что происходит, если его выбросить. Вводное объяснение самого подхода — «RAG простыми словами».
Два контура
Система живёт в двух режимах, и их полезно различать.
Подготовка идёт заранее и повторяется при изменении документов: извлечь текст, нарезать, векторизовать, положить в хранилище.
Обработка запроса идёт на каждый вопрос: разобрать вопрос, найти, отобрать, собрать контекст, сформулировать, проверить.
Ошибки первого контура обнаруживаются во втором, но чинятся в первом. Это главная причина, по которой диагностика RAG идёт от начала цепочки, а не от модели.
Контур подготовки
Шаг 1. Извлечение текста
Из исходных форматов достаётся текст с сохранением структуры: заголовков, списков, таблиц. Для обычных документов делается автоматически, для PDF со сложной вёрсткой и сканов — отдельная задача, «OCR и PDF».
Если пропустить структуру: таблица превращается в поток чисел без привязки к строкам и столбцам, и ответы по ней становятся случайными.
Шаг 2. Нарезка на фрагменты
Документ режется на куски. Размер, границы и перекрытие определяют, что вообще сможет найтись — «Чанкинг документов».
Если резать механически по числу символов: правило окажется в одном фрагменте, а исключение к нему — в другом, и система будет отвечать половиной правды.
Шаг 3. Обогащение фрагментов
Шаг, который чаще всего пропускают, а он даёт заметный прирост. К каждому фрагменту добавляется контекст: название документа, путь по заголовкам, дата редакции, метки доступа.
Зачем. Фрагмент «срок составляет 5 рабочих дней» бесполезен. Тот же фрагмент с приписанным заголовком «Регламент поставки → Доставка в регионы» уже отвечает на вопрос. Метки доступа нужны для разграничения прав, дата — чтобы отличать редакции при обновлении корпуса.
Шаг 4. Векторизация
Каждый фрагмент переводится в числовой вектор моделью-энкодером. Выбор модели для русского языка — «Эмбеддинги для русского».
Важное правило: вопрос и фрагменты должны векторизоваться одной и той же моделью. Смена модели требует переиндексации всего корпуса — старые векторы с новыми несравнимы.
Шаг 5. Запись в хранилище
Векторы и тексты кладутся в базу с поддержкой поиска по близости. Варианты и критерии выбора — «pgvector или Qdrant».
Вместе с векторами сохраняется словесный индекс — он понадобится на шаге поиска.
Контур обработки запроса
Шаг 6. Разбор вопроса
Первый шаг, который почти всегда выбрасывают из схемы. Что тут делается:
- Развёртывание местоимений. «А для юрлиц?» без предыдущей реплики не ищется вообще. Вопрос переписывается в самодостаточный: «Каковы условия поставки для юридических лиц?».
- Отсев неподходящего. Приветствия, благодарности и вопросы не по теме не должны запускать поиск.
- Определение области. Если корпус разделён по темам, ограничение области поиска резко повышает точность.
Если пропустить: система работает только на первый вопрос диалога, а на уточняющие отвечает мимо. Это одна из самых частых причин жалоб на «бот не понимает контекст».
Шаг 7. Поиск
Находятся кандидаты — обычно два поиска одновременно: смысловой по векторам и словесный по точным совпадениям, с объединением результатов. Разбор — «Гибридный поиск».
Если только смысловой: артикулы, номера договоров, названия моделей не находятся. Если только словесный: не находятся переформулировки.
На этом же шаге применяются фильтры: по правам доступа, по дате, по разделу. Права — именно фильтром при поиске, а не инструкцией модели.
Шаг 8. Переоценка найденного
Кандидаты пересортировываются моделью, которая оценивает пару «вопрос — фрагмент» напрямую и потому точнее векторной близости. Из двух-трёх десятков остаётся три-пять. Разбор — «Реранкинг».
Если пропустить: в модель уходит много посторонних фрагментов, и точность ответа падает. Больше контекста не значит лучше ответ — как правило, наоборот.
Шаг 9. Сборка контекста
Отобранные фрагменты складываются в запрос к модели вместе с инструкцией. Здесь решается:
- сколько фрагментов передавать — каждый лишний повышает стоимость и снижает точность;
- в каком порядке — модели неравномерно внимательны к разным частям длинного контекста, и самое важное разумно ставить ближе к краям;
- как пометить источники, чтобы модель могла на них сослаться;
- что делать, если не нашлось ничего — сценарий отказа.
Сценарий отказа — обязательный элемент. Если модели не оставлено возможности сказать «не знаю», она заполнит пробел. Механизм — «Почему нейросеть выдумывает».
Шаг 10. Формулирование и проверка
Модель составляет ответ по переданным фрагментам и указывает источники — «Цитирование источников».
В ответственных сценариях добавляется проверка: подтверждается ли каждое утверждение переданными фрагментами. Стоит дополнительного обращения к модели, поэтому применяется выборочно или в темах с высокой ценой ошибки.
Шаг 11. Журналирование
Не влияет на ответ, но без него систему нельзя сопровождать. Записываются: вопрос, переписанный вопрос, найденные фрагменты с оценками, переданный контекст, ответ, источники.
Если пропустить: при жалобе «система ответила неверно» вы видите неверный ответ и не видите причину. Диагностика превращается в перебор.
Разбор: что дал каждый шаг
Внутренняя база знаний технической компании, около 2 000 страниц документации. Порядок, в котором собиралась система, и что менялось.
Версия 1: поиск по векторам + модель. Три шага из одиннадцати. Работало на общих вопросах, проваливалось на любом, где упоминалась конкретная модель оборудования: обозначения вида «ТМ-40/6» смысловому поиску безразличны.
Версия 2: добавлен словесный поиск. Обозначения находиться стали. Появилась другая проблема: на популярные темы находилось много всего, ответ получался расплывчатым и иногда смешивал условия разных продуктов.
Версия 3: добавлена переоценка. Из двадцати кандидатов стали отбираться четыре. Ответы стали точнее, расход на обращение снизился — передавалось меньше текста.
Версия 4: добавлено обогащение фрагментов заголовками. Закрыло класс ошибок, который до этого выглядел необъяснимо: фрагменты с параметрами находились правильно, но модель не понимала, к какому изделию они относятся, потому что название было в заголовке раздела, а не в самом фрагменте.
Версия 5: добавлен разбор вопроса. Заработали уточняющие вопросы. До этого второй вопрос диалога обрабатывался как самостоятельный и терял тему.
Что из этого следует. Ни один шаг не был лишним, но и ни один не был обязательным на старте. Разумный порядок — собрать минимальную версию, измерить, добавлять шаги под конкретные наблюдаемые провалы. Добавлять всё сразу — значит не понимать, что именно даёт результат.
Какие шаги можно пропустить
Честный ответ: зависит от материалов и вопросов.
| Шаг | Когда можно обойтись |
|---|---|
| Обогащение фрагментов | документы плоские, без вложенных разделов |
| Словесный поиск | в текстах нет артикулов, кодов, номеров |
| Переоценка | корпус маленький, кандидатов и так мало |
| Разбор вопроса | вопросы одиночные, без диалога |
| Проверка ответа | цена ошибки невелика |
| Журналирование | никогда |
Последняя строка не преувеличение. Без журнала любая жалоба на качество превращается в гадание.
Частые вопросы
Из каких этапов состоит RAG-система?
Из двух контуров. Подготовка: извлечь текст, нарезать на фрагменты, обогатить контекстом, векторизовать, записать в хранилище. Обработка запроса: разобрать вопрос, найти кандидатов, переоценить их, собрать контекст, сформулировать ответ, записать в журнал. Демонстрационные прототипы обычно содержат три-четыре шага из этого списка.
Какой шаг чаще всего пропускают?
Разбор вопроса и обогащение фрагментов. Первый нужен, чтобы работали уточняющие вопросы в диалоге, второй — чтобы фрагмент нёс с собой контекст документа. Оба недороги в реализации и дают заметный прирост качества.
Правда ли, что чем больше контекста передать модели, тем лучше ответ?
Нет, обычно наоборот. Лишние фрагменты размывают ответ и увеличивают стоимость обращения. Поэтому в схеме есть отдельный шаг переоценки: из двух-трёх десятков кандидатов отбираются три-пять действительно относящихся к вопросу.
Можно ли собрать RAG на готовых конструкторах?
Для простых случаев да. Ограничение в том, что настройки поиска и нарезки там обычно закрыты, а именно они определяют качество. Пока ответы устраивают — вопросов нет; когда перестанут, повлиять будет почти не на что.
Обязательно ли иметь векторную базу данных?
Не обязательно. При небольшом корпусе достаточно расширения для обычной PostgreSQL — отдельное хранилище оправдано на больших объёмах и при сложной фильтрации. Сравнение с порогами — «pgvector или Qdrant».
Сколько шагов нужно нашей системе?
Столько, сколько требуют ваши вопросы и материалы. Разумный порядок — собрать минимальную версию, измерить качество на реальных вопросах и добавлять шаги под наблюдаемые провалы, а не про запас.
Что дальше
Первый по важности шаг — нарезка: «Чанкинг документов». Дальше поиск: «Гибридный поиск» и «Реранкинг». Чтобы понимать, работает ли собранное, нужны измерения — «Метрики RAG».
Проектирование таких систем целиком, от корпуса до эксплуатации, — часть работы по разработке и внедрению ИИ.