RAG — это способ дать языковой модели доступ к внешним документам во время ответа: приложение ищет подходящие фрагменты и добавляет их в запрос. Обычно модель не переобучают на каждом новом документе. Но надпись «ответ по базе» ещё не доказывает, что поиск нашёл правильный файл или что вывод точно следует из найденного текста.
IBM описывает retrieval-augmented generation как подключение модели к внешним базам знаний, позволяющее использовать доменные данные без дополнительного обучения модели (IBM overview). Anthropic отдельно описывает retrieval в Projects: поиск получает релевантные части вместо загрузки всего содержимого разом (Claude Help Center). Это описание конкретной реализации, а не универсальная гарантия всех RAG-систем.
Путь одного ответа
1. Подготовка источников. PDF, DOCX или HTML извлекаются в текст; таблицы, заголовки и метаданные сохраняются настолько, насколько позволяет парсер.
2. Разбиение и индекс. Документы делятся на фрагменты и добавляются в индекс. Слишком крупный фрагмент приносит лишний контекст; слишком маленький может разорвать определение и оговорку.
3. Поиск. Запрос превращается в поисковый ключ, система выбирает несколько подходящих фрагментов. Ошибка здесь — нерелевантный источник, пропущенная версия или устаревшая политика.
4. Генерация. Модель формирует ответ на основе запроса и выбранных фрагментов. Она всё ещё может неверно объединить их или добавить неподтверждённый вывод.
5. Ссылка и проверка. Приложение возвращает названия документов, страницы или ссылки, чтобы человек мог сверить вывод.
Проверяй две разные вещи
Оценка ответа «правильный/неправильный» не показывает, где сбой. Раздели тест:
- Retrieval: попал ли нужный фрагмент в найденные материалы? Есть ли актуальная версия? Не смешались ли документы с похожими заголовками?
- Generation: действительно ли ответ следует из найденного текста? Сохранились ли исключения, даты и отрицания?
Сделай небольшой набор вопросов с заранее известными источником и ответом. Для каждого запуска сохраняй ожидаемый документ, фактический top-k/ранг фрагментов и ответ. Включи вопросы без ответа в базе: система должна сообщить, что подтверждение не найдено. Это предложенный тестовый протокол, а не измеренный результат конкретной RAG-системы.
Практический тестовый шаблон
| Вопрос | Ожидаемый документ/раздел | Что фактически вернул поиск | Обязательная оговорка | Сбой для проверки |
|---|---|---|---|---|
| Каков срок процедуры? | Действующая версия регламента | Запиши top-k документов и ранг нужного раздела | Условия исключения | Выбрана старая версия |
| Кто согласует изменение? | Таблица ролей | Название и версия найденного файла | Только для этого типа изменения | Перепутана роль |
| Есть ли правило X? | В источниках не найдено | Сохрани возвращённые фрагменты | Не выводить «нет» из молчания | Уверенный вымысел |
Для каждого ответа проверь цитату вручную: она может не подтверждать весь абзац. Применяй правила доступа (ACL) до или во время retrieval, чтобы закрытые фрагменты не попали в контекст ответа пользователю без доступа. Фильтрация только после retrieval не защищает от утечки через генерацию, логи или citations.
Когда RAG — не волшебная кнопка
Нужны обновление и удаление источников, контроль версий, права доступа, обработка сканов и таблиц, а также мониторинг качества поиска. Если база состоит из пяти стабильных страниц, ручная ссылка на нужный документ может быть проще. Для фактов, где важны точность и актуальность, отображай дату источника и путь к оригиналу.
Перед индексацией удали дубликаты и обозначь владельца источника. Для каждой записи полезны дата документа, версия, тип аудитории, подразделение и статус «действует/архив». Эти метаданные могут участвовать в фильтрации; если забыть фильтр, система найдёт точный, но устаревший фрагмент. При удалении документа выясни, удаляется ли его представление из индекса и кэша, а не только из исходной папки.
Разделяй тестовые ошибки: «правильный документ не найден», «не тот фрагмент попал в prompt», «ответ неправильно понял цитату» и «ссылка ведёт не туда». Без этой диагностики неясно, что менять — подготовку файла, разбиение, поиск, инструкцию модели или UI цитат.
Если вопрос требует расчёта по таблице или строгого сравнения версий, retrieval может подобрать документы, но не заменить детерминированный расчёт и проверку доступа. Не делай высокорисковое действие только потому, что ответ сопровождён источником.
Не маскируй отсутствие источника
В инструкции можно потребовать указывать страницу или название документа для каждого важного утверждения и явно сообщать, когда подтверждения не найдено. Но не доверяй фразе «согласно документу» без ссылки: проверь, что цитата существует и относится к тому же правилу. Для ответа из нескольких источников сохраняй происхождение каждой части, чтобы заметить конфликт версий.
Сложный запрос можно разбить: сначала определить, какие документы нужны; затем посмотреть, нашёлся ли правильный фрагмент; только после этого просить итог. Если retrieval возвращает неправильный кусок, переписывание prompt может не помочь — нужно исправить метаданные, индекс или стратегию поиска. Для понятия активного контекста рядом смотри память и контекстное окно.
Пример диагностики одной ошибки
Вопрос: «Можно ли продлить договор после даты окончания?» Ожидаемый источник — актуальный регламент с разделом об исключениях. Если retrieval вернул старую редакцию, проверь метаданные и фильтр по статусу. Если он нашёл правильный раздел, но ответ потерял оговорку, проверяй генерацию и формат цитирования. Если нужного правила нет, ожидай уточнение у владельца документа, а не универсальный ответ.
До запуска запиши ожидаемый источник и отметь, должен ли агент ответить или воздержаться. «В базе не найдено» и «документ подтверждает отсутствие правила» — разные результаты.
При каждом релизе сохрани commit или версию индекса, чтобы связать неожиданный ответ с обновлением источников. Если источник изменился, проверь, что новая редакция индексируется, а устаревшая больше не участвует в поиске.
Проектирование workflow и agent-систем разбирается на странице MK Ultra.