RAG-пайплайн шаг за шагом

Две фазы, один пайплайн

У RAG две жизни. Индексация происходит заранее, офлайн: всякий раз, когда ваши документы меняются, вы нарезаете их на фрагменты (chunks), строите эмбеддинги и сохраняете их в векторной базе данных. Обработка запроса происходит онлайн, на каждый вопрос пользователя: вы строите эмбеддинг вопроса, находите ближайшие фрагменты, вставляете их в промпт — и модель отвечает.

Пройдите весь цикл по шагам:

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

Дальше в этом уроке мы подробно разберём два этапа, на которых инженеры ошибаются чаще всего: разбиение на фрагменты и сборку итогового промпта.

Почему бы не пропустить всё это и не вставить документ целиком?

Потому что вставка всего подряд ломается сразу тремя способами:

• Оно не помещается. Окно контекста — жёсткий бюджет. PDF на 50 страниц — это примерно 25–40 тысяч токенов, а настоящая база знаний — миллионы. Окна, достаточно большого для «всего», не существует.
• Это дорого на каждом вопросе. За эти токены вы платите при каждом вызове и ждёте, пока их прочитают. Отвечать на «какой срок возврата?» перечитыванием 500 страниц — невыгодная сделка, когда вопросов много.
• Ответы становятся хуже. Утопите единственный нужный абзац среди 500 страниц — и модель начнёт уклоняться, смешивать две политики или уверенно брать ответ не из того раздела. Несколько правильных фрагментов лучше пятисот не тех страниц.

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

Разбиение на фрагменты (chunking): единица поиска

Разбивать на фрагменты нужно по двум причинам. Во-первых, точность: PDF на 50 страниц содержит ответы на сотни разных вопросов, и если доставать его целиком на каждый из них, промпт забивается шумом. Во-вторых, эмбеддинги размываются на длинных текстах: один вектор на всё руководство усредняет и стирает всё, что характерно для отдельного раздела.

Размер фрагмента — это компромисс:

• Слишком маленькие (одно-два предложения) — фрагменты теряют контекст. «Возврат — 14 дней» ничего не значит, пока не знаете, что речь о годовых тарифах.
• Слишком большие (много страниц) — каждый фрагмент охватывает много тем, поэтому его вектор подходит ко всему и ни к чему, а вы платите за токены, которые вам не нужны.

Практическая отправная точка: 300–800 токенов на фрагмент с перекрытием 10–20% между соседними фрагментами, чтобы мысли, лежащие на границе, не терялись. Делите по естественной структуре — заголовкам, абзацам, пунктам списков, — а не по голому числу символов.

Сборка промпта: бюджет токенов

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

Обратите внимание, как это мало. Распространённое заблуждение — будто RAG означает набивать окно контекста огромными документами. Всё наоборот: RAG — это способ отвечать на вопросы по миллиону документов, отправляя всего несколько тысяч токенов. Векторная база — это фильтр; в промпт попадает только короткий список отобранных фрагментов.

Вот итоговый промпт в виде шаблона, который можно скопировать и адаптировать. Именно эта часть решает, скажет ли ваш бот «не знаю» или выдумает правило:

Ты отвечаешь на вопросы, используя только пронумерованные источники ниже.

Правила:
- Используй ТОЛЬКО источники. Если ответа в них нет, скажи
«Этого нет в нашей документации».
- Указывай номер источника, на который опираешься, вот так: [1].
- Никогда не смешивай факты из разных источников в одно утверждение.

Источники:
[1] <текст фрагмента 1>
[2] <текст фрагмента 2>
[3] <текст фрагмента 3>

Вопрос: <вопрос пользователя>

Ответь не более чем тремя предложениями.

Две детали этого шаблона делают основную работу: «если ответа нет, так и скажи» (это разрешает модели признать незнание вместо угадывания) и «указывай номер источника» (благодаря этому каждое утверждение можно проверить — человеком или вашими тестами).

Качество решается на этапе поиска

Модель может быть ровно настолько хороша, насколько хороши фрагменты, которые вы ей даёте. На практике это значит:

• Плохие фрагменты на входе — уверенная чепуха на выходе. Если поиск вернул не тот раздел, модель всё равно гладко ответит на основе вашего неверного контекста: возражать она не станет.
• Измеряйте поиск отдельно. Прежде чем винить LLM, проверьте, был ли нужный фрагмент хотя бы в первой пятёрке. Это вопрос качества поиска, поэтому и измерять его нужно поисковыми метриками.
• Усложняйте позже: гибридный поиск (векторы плюс поиск по ключевым словам), реранкинг 50 лучших кандидатов с помощью cross-encoder, фильтры по метаданным («только документы 2024 года»).