RAG — способ дать языковой модели доступ к актуальным материалам компании без попытки «запомнить» их внутри модели. Перед каждым ответом система ищет подходящие фрагменты в документах, добавляет их к запросу и просит сформулировать ответ только на этой основе. Поэтому изменение инструкции может попасть в ответы после переиндексации, а не после отдельного обучения модели.
Для бизнеса это полезно там, где сотрудники или клиенты задают повторяющиеся вопросы по регламентам, каталогам, инструкциям и правилам. Но RAG не исправляет беспорядок в документах. Если одновременно действуют три версии прайса, права доступа не размечены, а исключения живут в переписке, поиск аккуратно принесёт противоречия модели. Ответ станет гладким, но не надёжным.
Из каких шагов состоит RAG#
Рабочая цепочка включает семь операций:
- документы попадают в управляемое хранилище;
- текст извлекается из файлов и очищается от служебного мусора;
- материал делится на фрагменты с заголовками и метаданными;
- запрос пользователя преобразуется в форму, удобную для поиска;
- поиск выбирает несколько наиболее подходящих фрагментов;
- фильтр прав и правил исключает недоступное и устаревшее;
- модель формулирует ответ и указывает использованные источники.
Ошибка возможна на каждом звене. Скан документа может распознаться неверно. Деление разорвёт условие и исключение. Поиск поднимет похожий, но старый регламент. Фильтр прав пропустит отделу чужие сведения. Модель добавит правдоподобную деталь поверх найденного текста. Поэтому «модель ответила неправильно» — слишком общий диагноз: сначала нужно определить сломанный этап.
RAG не равен поисковой строке с пересказом. Обычный поиск показывает документы, а человек сам выбирает и читает. RAG делает ещё один рискованный шаг — собирает итоговую формулировку. Пользователю удобнее, но цена неверно объединённых фрагментов выше. Для важных тем источники должны оставаться видимыми, чтобы ответ можно было быстро сверить.
Когда RAG подходит задаче#
Используйте матрицу до разработки:
| Признак процесса | RAG подходит | Нужен другой подход |
|---|---|---|
| Ответ уже содержится в текстах | да | если правило нигде не записано, искать нечего |
| Материалы регулярно меняются | да, при управлении версиями | если версии нельзя различить, ответ ненадёжен |
| Пользователю нужен краткий ответ | да, со ссылкой на источник | если нужен полный документ, лучше обычный поиск |
| Есть разные уровни доступа | да, если фильтр стоит до выдачи | если права нельзя перенести в индекс, запуск опасен |
| Нужен расчёт по данным | только для поиска правил расчёта | вычисление выполняет отдельная проверяемая логика |
| Нужны действия в системе | RAG даёт справку | действие выполняет интеграция с отдельными полномочиями |
| Требуется управленческое решение | может собрать основания | решение остаётся человеку |
Хорошие первые сценарии — ответы сотрудникам по внутренним инструкциям, навигация по технической документации, подготовка черновика ответа поддержки по утверждённым правилам. Плохие — самостоятельный возврат денег, оценка сотрудника, юридическое заключение или выбор поставщика. Там модель не только извлекает сведения, но и принимает решение, которого в источнике может не быть.
Если документов мало и они короткие, RAG может быть лишним. Поддерживаемая страница с оглавлением и обычный поиск дадут более прозрачный результат. Сложность оправдана, когда объём уже мешает человеку быстро найти нужный фрагмент, а вопросы повторяются достаточно часто.
Подготовьте документы до индексации#
База для RAG начинается с владельцев, а не с загрузки файлов. Для каждого документа нужны название, ответственный, статус, дата вступления, дата следующей проверки и область действия. Черновики, архив и отменённые версии отделяют физически или явной меткой. «Последний» в имени файла не является статусом.
Проведите инвентаризацию:
- удалите точные копии;
- определите действующую версию каждого правила;
- вынесите исключения рядом с основным правилом;
- расшифруйте непонятные заголовки и внутренние сокращения;
- превратите таблицы и изображения в доступный для поиска текст;
- укажите подразделение, продукт, регион и аудиторию;
- перенесите важные договорённости из чатов в официальный материал;
- назначьте порядок отзыва ошибочного документа.
Отдельная инструкция по этой работе есть в статье как собрать базу знаний для ИИ-ассистента. Важно не перепутать задачи: база знаний отвечает за содержание и жизненный цикл, RAG — за доставку нужного фрагмента в нужный запрос.
Не индексируйте всё хранилище «на пробу». Начните с одной темы, по которой есть владелец и понятный набор вопросов. Так ошибки поиска можно связать с конкретным документом, а не разбирать океан неоднородного текста.
Деление на фрагменты и метаданные#
Система ищет не документ целиком, а куски. Слишком короткий фрагмент теряет условие: срок окажется отдельно от того, к какому продукту он относится. Слишком длинный приносит много лишнего, и модель может выбрать не то положение. Универсального размера нет; его проверяют на своих вопросах.
Полезное правило — фрагмент должен содержать одно законченное положение вместе с заголовком, условиями и исключениями. Если таблица читается только вместе с подписью и вводным абзацем, их нельзя разрывать. Ссылки внутри текста должны сохранять адрес исходной страницы и место, откуда взят кусок.
Минимальные метаданные:
| Поле | Для чего нужно |
|---|---|
| идентификатор документа | найти и отозвать все его фрагменты |
| версия и статус | не смешивать действующее с архивом |
| дата действия | выбирать правило для нужного периода |
| владелец | направлять вопрос об ошибке |
| подразделение или продукт | фильтровать область применения |
| уровень доступа | исключать недоступное до передачи модели |
| ссылка на оригинал | дать пользователю проверяемую цитату |
Права применяются на этапе поиска, а не просьбой в инструкции модели «не показывать секретное». Модель уже не должна получать запрещённый фрагмент. Проверяйте не только прямой запрос, но и косвенные формулировки, сокращения и просьбы сравнить подразделения.
Поиск: не только смысловая близость#
Смысловой поиск полезен для вопросов, сформулированных не так, как документ. Но он может плохо работать с артикулами, точными названиями, номерами пунктов и редкими терминами. Поэтому в деловых базах часто нужен комбинированный поиск: по смыслу и по точным словам, а затем повторное ранжирование кандидатов.
Перед генерацией полезно определить минимальную уверенность. Если подходящего источника нет, правильный результат — «в базе не найден подтверждённый ответ» и маршрут к владельцу темы. Попытка отвечать из общих знаний разрушает смысл RAG: система выглядит подключённой к вашим документам, но фактически додумывает.
В запрос модели передают ограниченное число лучших фрагментов. Чем больше контекста, тем не обязательно лучше: противоречивые и слабосвязанные куски повышают вероятность смешанного ответа. Логируйте, какие фрагменты были выбраны, иначе воспроизвести ошибку невозможно.
Как тестировать качество по этапам#
Соберите 50–100 вопросов из реальной работы и добавьте контрольный ответ, источник и допустимые варианты формулировки. В набор должны войти:
- частые простые вопросы;
- вопросы с профессиональными сокращениями;
- запросы, где важна точная версия или дата;
- вопросы с ответом в таблице;
- формулировки с опечатками;
- вопросы без ответа в базе;
- запросы к документу без прав;
- противоречие между действующей и архивной версией.
Для каждого примера ставьте отдельные отметки:
- найден ли правильный документ;
- найден ли фрагмент с нужным условием;
- не попал ли недоступный или устаревший материал;
- соответствует ли ответ фрагментам;
- указана ли рабочая ссылка;
- отказалась ли система от ответа, когда основания нет.
Такая разметка сразу показывает лекарство. Если источник не найден, правят индекс, запрос или метаданные. Если источник найден, но итог неверен, правят инструкцию формирования и границы ответа. Если ответ верен, а ссылка ведёт не туда, исправляют связь с оригиналом. Замена модели на каждом сбое — дорогая попытка лечить все причины одним средством.
Запуск и эксплуатация#
Первую версию держите в режиме подсказки: сотрудник видит ответ, источники и решает, использовать ли их. Не отправляйте результат клиенту автоматически, пока не накоплена собственная статистика по критическим ошибкам и отказам. Журналируйте запрос, найденные фрагменты, версию индекса, ответ и обратную связь.
Назначьте владельцев трёх контуров: содержание документов, технический поиск и качество ответов. Один человек может совмещать роли, но ответственность должна быть названа. При изменении правила документ обновляют, старую версию отзывают, индекс перестраивают, затем прогоняют связанные контрольные вопросы.
Чек-лист готовности RAG:
- выбран один сценарий и описана цена ошибки;
- у документов есть статусы, версии и владельцы;
- архив исключён из действующей выдачи;
- права доступа применяются до модели;
- фрагменты сохраняют условия и исключения;
- ответ содержит ссылку на исходный материал;
- отсутствие источника приводит к честному отказу;
- есть контрольный набор с вопросами без ответа;
- каждую ошибку можно воспроизвести по журналу;
- обновление документа запускает повторный тест.
RAG даёт ценность не потому, что модель «знает компанию», а потому, что путь от вопроса до основания становится коротким и проверяемым. Если основания нет, система должна это показать. Если оно есть, пользователь должен открыть его одним действием. Именно эти два поведения отличают рабочий поиск по знаниям от уверенного генератора ответов.
Как разбирать ошибки после запуска#
Заведите журнал с полями «вопрос — ожидаемый источник — найденные фрагменты — ответ — решение». Каждая ошибка получает один основной класс. Это важно: без класса обсуждение быстро сводится к впечатлению, что «модель стала хуже».
Нет документа. Пользователь задал рабочий вопрос, но утверждённого ответа не существует. Задача уходит владельцу процесса; добавлять импровизированный текст в инструкцию нельзя.
Документ есть, поиск его не поднял. Проверьте извлечение, заголовок, синонимы, метаданные и комбинирование точного и смыслового поиска. Такой сбой не исправляется литературной правкой ответа.
Найден не тот документ. Разберите статус, версию, область действия и повторное ранжирование. Часто причина — дубль или слишком общая страница, которая совпадает со многими запросами.
Нужный фрагмент найден, ответ неверен. Проверьте, не потеряно ли исключение при делении, не передано ли слишком много противоречивого контекста, соблюдает ли модель запрет на добавление сведений.
Ответ верен, но бесполезен. Пользователю может не хватать шага, ссылки или ясного языка. Это отдельная продуктовая проблема, не фактическая ошибка.
Раскрыт недоступный материал. Немедленно остановите затронутый контур, сохраните допустимые журналы для разбора и исправьте фильтр до поиска. Переформулировка системной инструкции не является достаточным исправлением прав доступа.
Еженедельно переносите подтверждённые сбои в контрольный набор. Но сохраняйте исходные вопросы: если заменять старые новыми, можно улучшить вчерашнюю ошибку и незаметно вернуть предыдущую. Набор растёт по типам риска, а не по каждому случайному неудачному слову.
После каждого исправления прогоняйте не только новый пример, но и соседнюю группу: точные названия, исключения, отсутствие ответа и ограничения доступа. Локальная правка ранжирования способна поднять нужный документ и одновременно ухудшить другие темы. Версия индекса, настроек поиска и инструкции должна быть общей меткой релиза.