Новый документ уже загружен в хранилище, но отвечает ли по нему RAG-система? Проверка статуса задачи индексации не гарантирует, что нужный текст доступен поиску: файл мог не пройти фильтр, распасться на неудобные чанки или получить метаданные, по которым запрос исключает его из выдачи.
Проверить это можно без большой тестовой платформы. Достаточно нескольких контрольных документов, вопросов с заранее известными ответами и сравнения результатов до и после обновления индекса. Такой тест помогает отделить сбой ingestion-процесса от проблем retrieval и генерации.
Что именно означает «документ проиндексирован»
В типичном RAG-процессе исходный текст извлекают из файла, делят на фрагменты, преобразуют фрагменты в эмбеддинги и сохраняют вместе с идентификаторами и метаданными. При запросе система ищет подходящие фрагменты, а затем передаёт их модели. Pinecone описывает этот цикл как отдельные этапы извлечения, хранения и поиска: руководство по RAG.
Поэтому один зелёный статус может подтверждать лишь завершение отдельной операции. Он не доказывает, что:
- все страницы или записи были прочитаны;
- текст не потерялся при разборе;
- чанки содержат нужный факт в пригодном контексте;
- векторная запись сохранилась под ожидаемым ID;
- фильтр по источнику, дате или доступу не исключает документ;
- запрос действительно находит нужный фрагмент.
Для диагностики разделите проверку на два вопроса: присутствуют ли ожидаемые записи в хранилище и извлекаются ли они запросом, похожим на пользовательский.
Тест индексации новых документов: подготовьте контрольный набор
Создайте несколько небольших документов, которые можно однозначно отличить от остального корпуса. Например, добавьте записи с редкими, но реалистичными сочетаниями слов:
- «Отчёт „Маяк-17“: окно обслуживания — 14:30–15:10»;
- «Заявка QZ-4821 назначена группе поддержки „Север“»;
- «Для версии 3.7 используется резервный регион eu-west-2».
Не используйте секреты, персональные данные или выдуманные утверждения о реальном продукте. Контрольные фразы нужны только для тестовой среды. Сохраните точный текст, идентификатор документа и ожидаемые метаданные в отдельном файле тестов.
Для каждого документа подготовьте несколько запросов:
Точный: «Какое окно обслуживания указано в отчёте „Маяк-17“?»
Перефразированный: «Когда запланировано обслуживание по отчёту Маяк-17?»
3. С опечаткой или изменённой формой: «Во сколько окно обслуживания Маяк 17?»
Первый запрос проверяет базовую доступность. Второй показывает, находит ли система смысловой вариант формулировки. Третий полезен как дополнительная проверка, но не должен быть единственным критерием: качество такого поиска зависит от модели эмбеддингов и конкретного языка.
Снимите результаты до загрузки и после неё
Выполните каждый контрольный запрос до добавления документа и сохраните top-k результатов: текст фрагмента, ID, метаданные и оценку релевантности, если система её показывает. После загрузки и завершения обновления запустите те же запросы с теми же параметрами.
Сравнивайте не только ответ LLM. Сначала проверьте сам список найденных фрагментов. Если нужного текста нет среди кандидатов, проблема возникла до генерации ответа. Если он найден, но итоговый ответ неверный, исследуйте сбор контекста, инструкцию модели и формат ответа.
Записывайте для каждого запроса:
- попал ли нужный документ в top-k;
- на каком месте он оказался;
- содержит ли найденный чанк полный ответ;
- совпадают ли ID и метаданные с исходной записью;
- сколько времени прошло между завершением загрузки и появлением результата.
Для небольшого теста удобно считать долю запросов, где нужный документ попал в top-k:
Recall@k = число запросов с целевым документом в top-k / общее число запросов.
Например, если из восьми контрольных вопросов нужный фрагмент найден в первых пяти результатах для шести, Recall@5 равен 0,75. Это оценка конкретного набора, а не универсальная характеристика системы: результат зависит от формулировок запросов, размера корпуса и выбранного k.
Проверьте записи отдельно от семантического поиска
Когда поиск не находит контрольный текст, сначала выясните, существует ли соответствующая запись в коллекции. В Chroma документация описывает получение, добавление и обновление записей коллекции; в Qdrant точками называются единицы хранения, содержащие вектор и связанный payload. Сверьте ID, число ожидаемых записей и сохранённый текст или payload там, где это позволяет схема хранилища.
Проверьте четыре условия:
- ID стабилен и уникален. Повторная загрузка не должна незаметно создавать дубликаты или перезаписывать чужую запись.
- Запись относится к нужной коллекции. В приложении и тестовом скрипте может быть настроено разное окружение.
- Payload содержит ожидаемый текст и метаданные. Векторная запись без полезного содержимого может успешно участвовать в поиске, но не дать модели ответа.
- Обновление действительно выполнено. Некоторые системы разделяют отправку операции и её фактическую доступность для запросов; учитывайте поведение конкретного API и используйте предусмотренный документацией способ подтверждения.
Документации Chroma по обновлению данных и Qdrant по точкам полезны как примеры того, какие сущности стоит сверять. Их API и гарантии нельзя автоматически переносить на другое хранилище.
Отделите ошибку чанкинга от ошибки поиска
Наличие исходного текста ещё не означает, что нужный факт попал в пригодный фрагмент. Посмотрите на сохранённые чанки вокруг целевого места. Если значение оказалось в одном фрагменте, а название объекта — в другом, запрос может не связать их. Заголовки, таблицы, подписи и границы страниц тоже могут теряться при разборе.
Для диагностики временно используйте запрос с редкой контрольной фразой и просмотрите top-k фрагменты целиком. Затем проверьте:
- сохранилась ли фраза без искажений;
- достаточно ли контекста вокруг ответа;
- не обрезано ли начало или окончание документа;
- можно ли найти название раздела вместе с нужным значением;
- не перемешались ли страницы или записи разных источников.
Если разбиение — причина сбоя, меняйте один параметр за раз: размер чанка, перекрытие или способ обработки структуры. После изменения повторите тот же набор запросов. Иначе нельзя понять, какой именно фактор изменил результат.
Не подбирайте размер фрагмента только по одному удачному примеру. Слишком крупные чанки могут добавлять нерелевантный контекст, а слишком мелкие — разделять связанные факты. Для стабильного сравнения сохраните исходные запросы и фиксируйте параметры индексации вместе с результатами.
Фильтры и метаданные: частая причина пустой выдачи
Запись может находиться в коллекции, но не появляться в поиске из-за ограничений по метаданным. Например, приложение ищет только документы с `status=published`, `tenant_id` текущего клиента или датой не старше заданного порога.
Сделайте два одинаковых запроса: сначала без необязательных фильтров, затем с фильтрами, которые использует приложение. Если нужный фрагмент появляется только в первом случае, проблема не в эмбеддингах. Сверьте значения полей в хранилище с условиями фильтра, включая типы данных и точное написание.
Особенно внимательно проверьте:
- строку и число, которые выглядят одинаково, но сравниваются по-разному;
- часовой пояс и формат даты;
- несовпадающие ID арендатора или источника;
- фильтры, добавленные на уровне приложения и не отражённые в тестовом запросе;
- метаданные, которые не обновляются при переиндексации документа.
Не отключайте проверки доступа в рабочей системе ради диагностики. Сравнение без фильтра допустимо только в изолированной тестовой среде и на данных, которыми разрешено пользоваться.
Воспроизводимый мини-бенчмарк для обновлений
Чтобы тест не превратился в разовую ручную проверку, храните контрольный набор вместе с кодом приложения. Запись теста может содержать ID документа, вопрос, ожидаемую ключевую фразу и допустимые метаданные. Тестовый скрипт должен:
сохранить состояние до загрузки;
добавить документ тем же путём, что и обычный ingestion-процесс;
3. дождаться подтверждения завершения операции согласно документации хранилища;
4. выполнить retrieval-запросы с производственными фильтрами;
5. сохранить найденные фрагменты, ID, оценки и время;
6. сравнить результат с ожиданиями.
Проверяйте не только точное совпадение строк. Если в запросе ищется документ, ожидаемым результатом может быть присутствие нужного ID в top-k и наличие в чанке целевого факта. Это позволяет избежать ложного провала из-за незначительных различий в форматировании.
Для сравнения алгоритмов поиска можно использовать принципы наборов оценки retrieval, например подход BEIR: важно фиксировать коллекцию, запросы и метрику, а не менять их вместе с настройками системы. Репозиторий BEIR предлагает набор задач для исследований информационного поиска; его результаты не заменяют тест на собственных документах, языке и фильтрах.
Как интерпретировать результат и что проверить дальше
Если запись отсутствует в хранилище, начинайте с загрузчика, обработки файла и подтверждения операции. Если запись есть, но нужный текст не сохранён, проверяйте парсер и преобразование в чанки. Если текст сохранён, но не попадает в top-k, сравните запрос, модель эмбеддингов, настройки поиска и фильтры. Если фрагмент найден, а ответ неверный, изучайте передачу контекста генератору и то, не противоречат ли друг другу найденные источники.
Перед изменением production-индекса сохраните параметры текущей конфигурации и сделайте тест на копии или отдельной коллекции. После изменения повторите прежний набор вопросов, а не только новый пример, на котором система должна была улучшиться.
Такой тест не доказывает, что RAG найдёт любой будущий документ. Он отвечает на более полезный вопрос: проходит ли конкретная новая запись весь путь от загрузки до выдачи, и на каком этапе она исчезает.
