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

RAG простыми словами

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

Это решает две проблемы обычного чат-бота. Он не знает внутренних документов компании и может уверенно выдумать ответ. RAG даёт ему нужные знания в момент вопроса и позволяет проверить ответ по источнику. При этом RAG не делает модель умнее: если ответа в документах нет или он сформулирован противоречиво, система его не найдёт. Зато она делает видимым, на чём основан каждый ответ.

Почему не дообучение и не «всё в контекст»

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

Передавать в модель все документы целиком при каждом вопросе дорого и медленно, а на больших объёмах невозможно. Кроме того, модели хуже находят нужное в очень длинном контексте. RAG отбирает немногие действительно нужные фрагменты, и это оказывается и дешевле, и точнее.

Когда RAG нужен, а когда нет

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

Из каких частей состоит система RAG

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

1. 01Сбор и очистка. Документы из разных источников приводятся к тексту с сохранением структуры.
2. 02Разбиение на фрагменты. Текст режется на смысловые куски с сохранением заголовков и названия документа.
3. 03Метаданные. К каждому фрагменту прикрепляются источник, дата, версия, отдел и права доступа.
4. 04Индексация. Фрагменты переводятся в векторные представления для смыслового поиска и добавляются в полнотекстовый индекс.
5. 05Поиск. По вопросу находятся кандидаты с учётом прав текущего пользователя.
6. 06Переранжирование. Кандидаты упорядочиваются по реальной релевантности, лишнее отсекается.
7. 07Генерация. Модель получает вопрос и отобранные фрагменты и отвечает только по ним, со ссылками.
8. 08Проверка и журнал. Ссылки проверяются, использованные фрагменты записываются для разбора и аудита.

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

Как обновлять индекс

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

Подготовка документов: самая недооценённая часть

Большинство проблем RAG начинается задолго до модели — на этапе превращения документов в текст. Если текст извлечён плохо, никакой поиск и никакая модель этого не исправят.

Форматы и структура

Документы приходят в разных форматах: текстовые файлы, презентации, PDF, страницы вики, письма. Важно сохранить структуру: заголовки разделов, нумерацию пунктов, списки. Фраза «срок — пять рабочих дней» бесполезна без заголовка, к какой процедуре она относится.

Таблицы и сканы

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

Версии и дубли

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

Разбиение на фрагменты

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

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

Условный пример. В регламенте отпусков раздел «Перенос отпуска» содержит три абзаца. Если нарезать текст строго по длине, второй абзац окажется отдельно от заголовка, и на вопрос «можно ли перенести отпуск» поиск найдёт фрагмент без слова «перенос». Если сохранить заголовок раздела в каждом фрагменте, совпадение станет очевидным.

Поиск: смысловой, полнотекстовый и гибридный

Смысловой поиск

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

Полнотекстовый поиск

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

Гибридный поиск и переранжирование

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

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

Переформулировка запроса

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

Генерация ответа и цитирование

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

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

Условный пример ответа

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

Ответ «не найдено» — не провал системы, а полезный сигнал. Такие вопросы показывают пробелы в документах, и их стоит собирать и передавать владельцам знаний. Ссылки полезны и самой команде: по ним видно, какие документы используются чаще всего, а какие никогда не попадают в ответы и, возможно, устарели.

Права доступа: фильтровать до поиска

В компании разные люди видят разные документы: зарплаты, договоры, кадровые решения, переписку руководства. Если система ищет по всему корпусу, а потом просит модель «не показывать лишнее», конфиденциальные данные уже попали в контекст и могут просочиться в ответ — прямо или в пересказе.

• Храните права в метаданных каждого фрагмента и фильтруйте по ним при каждом запросе.
• Синхронизируйте права с исходной системой: если доступ к папке отозвали, индекс должен узнать об этом без ручных действий.
• Удаляйте из индекса фрагменты удалённых документов, а не только скрывайте их.
• Не кэшируйте ответы между пользователями с разными правами.
• Логируйте, какие фрагменты использовались в ответе, — это нужно и для разбора ошибок, и для аудита.
• Тестируйте права негативными сценариями: пользователь без доступа задаёт вопрос, ответ на который есть только в закрытом документе, и не получает его.

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

Отдельно продумайте персональные данные внутри документов: паспортные данные в договорах, контакты клиентов, сведения о здоровье в кадровых документах. Даже если сотрудник имеет право видеть документ, поиск по таким данным может стать новым способом их массового извлечения. Иногда разумнее не индексировать такие поля или скрывать их при извлечении текста, а также определить, сколько хранятся журналы запросов, в которых эти данные могут оказаться.

Как проверить качество RAG

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

1. 01Соберите набор реальных вопросов сотрудников и для каждого отметьте, в каком документе и разделе правильный ответ.
2. 02Проверьте поиск: оказывается ли нужный фрагмент среди первых найденных для каждого вопроса.
3. 03Проверьте ответ: опирается ли он только на переданные фрагменты, полон ли он, верны ли ссылки.
4. 04Добавьте вопросы, на которые ответа в документах нет, и проверьте, что система честно говорит «не найдено».
5. 05Добавьте вопросы для проверки прав: от имени пользователя без доступа к нужному документу.
6. 06Прогоняйте весь набор при каждом изменении: нарезки, поиска, инструкции, модели.

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

Каждый проваленный вопрос полезно относить к одной из категорий: нужный фрагмент не найден; найден, но модель им не воспользовалась; ответа нет в документах; ответ есть, но документ устарел или противоречив. Такая разметка сразу показывает, куда вкладывать усилия: в подготовку данных, в поиск, в инструкцию или в работу с владельцами документов.

Типовые проблемы и как их поймать

• Цитируется устаревшая версия документа. Ловится вопросами о недавно изменённых правилах в проверочном наборе. Лечится метаданными версий и правилом актуальности.
• Ответ верный по смыслу, но со ссылкой не на тот документ. Ловится проверкой ссылок на эталонных вопросах. Часто причина — дубли документов.
• Неверные значения из таблиц. Ловится вопросами о конкретных цифрах из таблиц. Лечится отдельным извлечением таблиц.
• Поиск не находит очевидный ответ. Ловится проверкой поиска отдельно от генерации. Причины — плохая нарезка, жаргон, точные идентификаторы без полнотекстового поиска.
• Модель добавляет знания «от себя». Ловится проверкой верности источнику. Лечится строгой инструкцией и проверкой ссылок.
• Многие из этих проблем не видны на демонстрации с несколькими аккуратными документами и проявляются только на настоящем архиве. Поэтому пилот лучше запускать на реальных данных одного отдела и с его реальными вопросами.

Чек-лист запуска поиска по документам

1. 01Определите круг источников и владельцев каждого из них.
2. 02Убедитесь, что задача действительно про поиск по тексту, а не про подсчёты по данным.
3. 03Соберите набор реальных вопросов сотрудников с правильными ответами и ссылками.
4. 04Настройте извлечение текста с сохранением структуры и проверьте его глазами на сложных документах.
5. 05Отдельно обработайте таблицы и сканы.
6. 06Определите правило актуальной версии и уберите дубли.
7. 07Режьте текст по структуре, сохраняя заголовки и название документа во фрагментах.
8. 08Добавьте метаданные: источник, версия, дата, права доступа.
9. 09Используйте гибридный поиск и переранжирование.
10. 10Требуйте ссылки на фрагменты и проверяйте их программно.
11. 11Фильтруйте по правам до поиска и синхронизируйте права с источниками.
12. 12Протестируйте права негативными сценариями.
13. 13Разрешите ответ «не найдено» и собирайте такие вопросы.
14. 14Прогоняйте проверочный набор при каждом изменении системы.

Короткий словарь терминов

• RAG — генерация ответа с опорой на найденные фрагменты документов.
• Фрагмент (чанк) — кусок документа, с которым работает поиск.
• Векторное представление (эмбеддинг) — числовое представление смысла текста для смыслового поиска.
• Гибридный поиск — сочетание смыслового и полнотекстового поиска.
• Переранжирование — повторная, более точная оценка релевантности небольшого числа кандидатов.
• Метаданные — сведения о фрагменте: источник, дата, версия, права доступа.
• Верность источнику — свойство ответа опираться только на переданные фрагменты.

Вывод

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

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