Как измерить полноту поиска в Haystack через DocumentRecallEvaluator

1. Составьте набор вопросов с однозначной разметкой релевантных ID вручную до эксперимента.
2. Сохраните полученную выдачу ретривера на том же корпусе и том же top_k.
3. Передайте выровненные по вопросам вложенные списки Document в Evaluator.
4. Выведите individual_scores и просмотрите ошибки, не ограничиваясь средним score.
5. Сравните SINGLE_HIT и MULTI_HIT на вопросе, которому нужны два фрагмента одного правила.

Готовый шаблон

from haystack import Document
from haystack.components.evaluators import DocumentRecallEvaluator
from haystack.components.evaluators.document_recall import RecallMode

r = Document(id="R7", content="Возврат 14 дней")
e = Document(id="E1", content="Исключение для цифрового товара")
wrong = Document(id="D9", content="Доставка по будням")
evaluator = DocumentRecallEvaluator(mode=RecallMode.MULTI_HIT)
result = evaluator.run(
    ground_truth_documents=[[r, e], [wrong]],
    retrieved_documents=[[r], [wrong]])
print(result["individual_scores"], result["score"])

Пример предназначен для контролируемого теста на своих данных. Установите зависимости в отдельном окружении и зафиксируйте версии; при использовании локальной embedding-модели отдельно проверьте её доступность и разрешённость для вашего проекта. Код был проверен на синтаксис Python, но его вызовы Haystack в данном материале не выдаются за выполненный runtime-тест.

Вход и ожидаемый результат

Первому вопросу требуются R7 и E1, выдача находит лишь R7; второму вопросу нужен D9, и он найден. При MULTI_HIT первый вопрос не получает полной единицы, второй получает 1; итоговый score — среднее по вопросам. Не подменяйте этим измерением проверку самого ответа генератора.

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

Разбор ограничений и ошибок

Recall оценивает полноту выдачи по заранее размеченным эталонам, а не истинность генерации. Если вопрос «применяется ли срок к цифровому товару?» требует одновременно общего правила и исключения, SINGLE_HIT может показать идеальный балл уже при одном найденном документе, хотя ответ по нему опасно неполон. MULTI_HIT помогает увидеть потерю второго фрагмента. Важно размечать ID или содержание эталонов согласованно с используемым алгоритмом сопоставления: случайная смена ID или переразбиение документа ломают сопоставимость метрик. На каждом прогоне фиксируйте corpus version, параметры top_k, модель embedding и набор вопросов. Рост recall при увеличении top_k может одновременно увеличить количество нерелевантного текста в промпте; измеряйте также точность и качество финального ответа.

Проверочный сценарий на реальном корпусе

Разметьте не только лёгкие вопросы, где имя товара есть в тексте, но и отрицание, перефразировку, ошибку в коде и запрос без разрешённого источника. Для последнего recall не заменяет тест безопасности: документ чужого tenant не должен появиться даже если «релевантен» по смыслу. Разделите ошибки на индексирование, поиск и оценку: если правильного документа нет в store, менять ранжирование бессмысленно; если он там есть, изучите токенизацию и embedding; если ID не совпадают после миграции, проверьте разметку. Не выбирайте конфигурацию по десяти вопросам, которые одновременно использовались для её настройки; держите отложенный набор. Статистически содержательный вывод потребует большего числа разнообразных размеченных запросов, а маленький пример демонстрирует лишь механику метода.

Критерии приёмки