RAG-система: пошаговый план от источников до проверяемых ответов

Какую задачу решает RAG

Retrieval-augmented generation соединяет поиск по управляемым источникам и формирование ответа. Система сначала выбирает релевантные фрагменты, а затем модель отвечает с их учётом. Это не гарантирует истинность автоматически: слабое извлечение, устаревший документ, неверные права или слишком широкий контекст способны дать уверенный, но непригодный результат.

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

Ошибки, которые создают убедительные галлюцинации

Большой контекст и сильная модель не компенсируют плохой корпус и отсутствие измеримого поиска.

• Загружать общую папку без владельцев, версий, сроков актуальности и правил удаления.
• Оценивать только стиль финального ответа и не проверять, были ли нужные источники среди найденных фрагментов.
• Смешивать права после retrieval или надеяться, что промпт запретит модели использовать закрытые сведения.
• Показывать ссылку на документ в целом, когда утверждение невозможно сопоставить с конкретным фрагментом.
• Менять модель, разбиение, поиск и промпт одновременно, теряя понимание причины улучшения или регрессии.

Что подготовить до выбора моделей

Качество начинается с владельцев источников и эталонных вопросов, а не с размера векторной базы.

• Выберите один рабочий процесс и пользователей пилота: поддержка, продажи, юристы, инженеры или внутренний сервис. Зафиксируйте решения, для которых ответ действительно нужен.
• Проведите инвентаризацию источников: владелец, формат, дата, период актуальности, язык, конфиденциальность, правила доступа и способ обновления.
• Соберите 100–300 реальных вопросов с ожидаемыми источниками. Добавьте неоднозначные, запрещённые, устаревшие и неразрешимые примеры.
• Определите границы ответа: когда система обязана цитировать, попросить уточнение, показать несколько вариантов или честно отказаться.
• Согласуйте метрики поиска, ответа, безопасности, задержки и стоимости, а также ручной процесс исправления источника или правила.

Архитектура обновлений и доступа

RAG должен обновляться предсказуемо и не смешивать знания разных ролей, подразделений и дат.

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

Пошаговый план внедрения RAG-системы

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

• Нормализуйте документы, сохраняя заголовки, разделы, таблицы, дату, владельца, версию и исходный URL или идентификатор. Удаляйте технический шум, но не происхождение.
• Разбейте содержание на фрагменты по смысловой структуре. Проверьте, что фрагмент содержит достаточно контекста и не смешивает разные правила или уровни доступа.
• Постройте базовый лексический и векторный поиск. Сравните их отдельно и в гибриде на эталонном наборе, прежде чем добавлять переранжирование.
• Применяйте фильтры доступа до передачи контекста модели. Пользователь не должен получить запрещённый фрагмент даже тогда, когда итоговый текст кажется безопасным.
• Сформируйте ответ только из найденных источников, добавьте ссылки на конкретные фрагменты и правило отказа при недостаточном доказательстве.
• Оцените retrieval: recall релевантных источников, позиции и лишний контекст. Отдельно оцените ответ: соответствие источнику, полноту, цитаты и корректность отказа.
• Добавьте журнал версии корпуса, запроса, найденных фрагментов, модели и конфигурации. Без этой трассы невозможно воспроизвести ошибку после обновления.
• Запустите ограниченный пилот с обратной связью по причине ошибки и регулярной разметкой новых вопросов, затем меняйте один слой за итерацию.

Что измерять на пилоте

Нужны отдельные показатели поиска, ответа, безопасности и операционной пригодности.

• Recall@k и MRR по эталонным источникам, долю запросов без подходящего фрагмента и объём лишнего контекста.
• Фактическую согласованность ответа с источником, полноту, точность цитат и корректность отказа по размеченной выборке.
• Нарушения доступа, утечки через кэш или журнал, долю документов без владельца и задержку удаления устаревшей версии.
• Медианную и хвостовую задержку, стоимость одного завершённого задания и стабильность после обновления корпуса.
• Долю ответов, которые пользователь применил без повторного поиска, и причины ручного исправления.

Итог

Внедрение RAG начинается с ограниченного процесса, качественных источников и эталонных вопросов. Проверяйте retrieval до генерации, применяйте доступ до модели и сохраняйте трассу каждого ответа.

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

Дорожная карта RAG-пилота на восемь недель

• Недели 1–2 — выбрать процесс, источники, права, владельцев и эталонные вопросы с ожидаемыми доказательствами.
• Недели 3–4 — построить разбор документов, версии, базовый поиск и метрики retrieval на контрольном наборе.
• Недели 5–6 — добавить ответы, цитаты, отказ, журнал трассы и проверки доступа до модели.
• Недели 7–8 — закрытый пилот, разметка ошибок и поочерёдная настройка корпуса, поиска и ответа.