RAG простыми словами: как научить модель отвечать по своим документам

Языковая модель ничего не знает о ваших регламентах, договорах и инструкциях. Дообучать её на внутренних документах дорого, долго и, как правило, не нужно. Обычно хватает другого подхода: перед каждым вопросом находить нужные куски документов и подкладывать их модели вместе с вопросом. Этот подход называется RAG — генерация с дополнением найденным.

Звучит просто, и прототип действительно собирается за день. А вот чтобы система отвечала правильно не в демо, а на реальных вопросах сотрудников, придётся разобраться в нескольких деталях.

Как это работает в целом

Представьте стажёра, которому дали шкаф с документами. На каждый вопрос он сначала ищет подходящие страницы, раскладывает их перед собой и только потом отвечает, опираясь на то, что прочитал. RAG делает то же самое:

1. Подготовка. Документы разбиваются на фрагменты, для каждого фрагмента вычисляется числовой «отпечаток смысла» — эмбеддинг. Всё это складывается в базу.
2. Поиск. Когда приходит вопрос, для него тоже вычисляется эмбеддинг, и из базы достаются фрагменты с самыми близкими отпечатками.
3. Генерация. Найденные фрагменты и вопрос собираются в промпт, и модель формулирует ответ, опираясь на них.

Каждый из трёх шагов может сломать результат. Пройдём по ним.

Шаг 1. Чанкинг: как резать документы

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

Слишком мелкие чанки теряют смысл. Фраза «срок составляет 10 рабочих дней» без указания, срок чего именно, бесполезна. Модель получит цифру, но не поймёт, к чему она относится.

Слишком крупные чанки размывают поиск. Если в одном куске и правила командировок, и порядок оформления отпуска, его отпечаток будет «про всё сразу» и хуже совпадёт с конкретным вопросом. Кроме того, крупные чанки быстро съедают контекст модели.

Что обычно работает:

• резать по структуре документа — разделам, подзаголовкам, пунктам, а не тупо по количеству символов;
• держать размер в пределах от абзаца до пары страниц, подбирая под тип документов;
• делать небольшое перекрытие между соседними чанками, чтобы мысль на границе не потерялась;
• добавлять к каждому чанку контекст: название документа, раздел, дату редакции. Строка «Положение о командировках, раздел 4. Возмещение расходов» в начале чанка сильно помогает и поиску, и модели.

Отдельная боль — таблицы и сканы. Таблицу, разрезанную пополам, модель не поймёт. Скан без распознанного текста вообще невидим для поиска. Перед запуском RAG стоит потратить время на нормальное извлечение текста, это окупается многократно.

Шаг 2. Эмбеддинги: отпечатки смысла

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

Что важно при выборе модели для эмбеддингов:

• Поддержка русского языка. Многие модели обучены в основном на английском и с русским работают заметно хуже. Проверяйте на своих текстах.
• Длина входа. У модели эмбеддингов есть свой предел, и всё, что длиннее, будет обрезано. Чанки должны в него укладываться.
• Где она работает. Модели эмбеддингов маленькие, их легко запустить локально даже без мощной видеокарты. Это хороший способ не отправлять все документы наружу.

И правило, которое нельзя нарушать: документы и вопросы должны векторизоваться одной и той же моделью. Сменили модель — пересчитайте всю базу.

Шаг 3. Поиск: найти правильное

Векторный поиск хорошо ищет по смыслу, но плохо — по точным совпадениям. Номер договора, артикул, фамилия, аббревиатура внутреннего отдела — всё это он может пропустить, потому что для него «ДС-2024/117» и «ДС-2024/118» почти одно и то же.

Поэтому рабочие системы почти всегда используют гибридный поиск: векторный плюс обычный полнотекстовый по ключевым словам. Результаты объединяются, и в выдачу попадают как смысловые совпадения, так и точные.

Ещё два приёма, которые заметно улучшают качество:

• Переранжирование. Сначала быстрым поиском достаётся, скажем, пара десятков кандидатов, затем отдельная модель внимательнее оценивает каждый на соответствие вопросу и оставляет лучшие несколько. Это дороже по вычислениям, но точнее.
• Фильтры по метаданным. Если пользователь из отдела продаж спрашивает про скидки, искать стоит в документах продаж и только в актуальных редакциях. Метаданные — отдел, тип документа, дата, статус — дешёвый и очень эффективный способ сузить поиск.

Шаг 4. Сборка промпта и ответ

Найденные чанки нужно правильно подать модели. Минимальный набор инструкций:

• отвечай только на основе приведённых фрагментов;
• если ответа во фрагментах нет — так и скажи, не додумывай;
• указывай, из какого документа и раздела взята информация.

Последний пункт особенно важен. Ссылка на источник позволяет человеку проверить ответ за десять секунд, и это главная защита от галлюцинаций. Если система не показывает источники, ей быстро перестанут доверять — и правильно сделают.

Типичные ошибки

Нет тестового набора. Систему собрали, задали пять вопросов, ответы понравились — запустили. Через неделю выясняется, что на половину реальных вопросов она отвечает мимо. Соберите 50–100 настоящих вопросов с правильными ответами и указанием, в каком документе ответ лежит. Проверяйте отдельно: нашёл ли поиск нужный фрагмент и правильно ли модель по нему ответила. Это две разные ошибки, и чинятся они по-разному.

Устаревшие и дублирующиеся документы. Если в базе лежат три редакции одного положения, модель может взять старую. Наведите порядок в источниках до индексации и настройте обновление базы при изменении документов.

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

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

Слишком много контекста. Кажется логичным отдать модели не пять, а тридцать фрагментов — вдруг поможет. Обычно не помогает: модель теряется в шуме, ответ становится расплывчатым, а запрос дорожает. Лучше найти меньше, но точнее.

С чего начать

Не пытайтесь сразу проиндексировать весь файловый сервер. Возьмите одну узкую область — регламенты отдела кадров, техническую документацию одного продукта, базу ответов поддержки. Наведите порядок в документах, соберите тестовый набор, запустите простую версию и улучшайте её по одному шагу, каждый раз проверяя результат на наборе. Через пару итераций станет понятно, стоит ли расширяться и на что тратить силы дальше.