Оценка качества ретривера

Сценарий использования ретривера

В кулинарной системе порядок результатов поиска важен, так как на следующий этап попадет только ограниченное число рецептов или советов. Если наиболее подходящий рецепт (например, соответствующий набору ингредиентов и кухонной утвари) находится ниже в выдаче, он не будет использован, несмотря на свою релевантность. Это приводит к ухудшению качества итогового ответа.

Выбор метрик оценки

Условия выбора: Q - число тестовых запросов K - число выбираемых документов P - число всех документов K << P - число выбираемых значительно меньше, чем число всех

MRR@k

Поскольку наболее подходящих результат должен находиться как можно выше в выдаче, то целесообрано использовать MRR@k, которая и отражает данный показатель. При расчете метрики достаточно оставиться на первом найденном документе в выдаче. Это означает, что в худшем случае придется разметить Q×K записей.

mAP@k

Также стоит оценить общую релевантость всех выбранных документов, что осуществимо через mAP@k, поскольку она учитывает вес не только первого, а всех релевантых документов в полученной выборке. При расчете этой метрики придется разметики Q×K записей.

NDCG@k

С одной стороны NDCG@k идеально подходит для данной задачи, поскольку можно назначить степень релеватности документа, например от 0 до 4, где 0 - нереватный, а 4 - 100% попадание. Однако с другой же стороны нужна большая разметка. Чтобы показать это рассмотрим саму формулу метрики:

NDCG@k = DCG@k / IDCG@k

  1. При расчете DCG@k проблем нет, так какждому из k документов мы можем назначить степень соотвествия. Для всех запросов это займет Q×K просмотров
  2. При расчете IDCG@k начинаются проблемы. Для расчета нужно найти все документы с ненулевой степенью релеватности, которые также нужно расположить по убыванию этой степени релеватности. Значит, в идеале, нужно просмотреть все P документов для каждого запроса, чтобы найти эти заветные документы. А для всех запросов это требует Q×P просмотров, что значительно больше, чем Q×K (K << P => Q×K << Q×P). Примерная оценка ряда идельных рангов, кончено, возможна, однако это искажает точность IDCG@k и как следствие NDCG@k.

Вывод

Исходя из вышеперечисленных рассуждений выберем метрики MRR@k и mAP@k, потому что их можно рассчитать наиболее точно при относительно меньших трудозатратах.

Формирование данных для оценки

  1. Составим тестовые запросы, форматы которых:
{"q_id": number, "query": "string"}
  1. Скопируем базу документов, которую мы используем для ретривера.
  2. Для каждого запроса выполняем вызов ретривера с K.
  3. Во время шага 3 формируем два списка:

Формат списка результатов запуска (runs):

[{"q_id": number, "r_id": number, "score": number, "rank": number}]

Формат списка для разметки (qrels):

[{"q_id": number, "r_id": number, "score": number}]
  1. Размечаем релевантность извлеченных документов, определяя значения поля score. 0 - нерелевантен, 1 - релевантен

Анализ результатов

Условия оценки №0

  • corpus: "tests/eval_retriever/data/recipes" - рецепты (70 шт.)
  • queries: "tests/eval_retriever/queries/queries.json" - запросы (50 шт.)
  • db: "tests/eval_retriever/data/sqlite_test.db" - файл с бд рецептов, составленных на основе рецептов
  • faiss: "tests/eval_retriever/data/faiss_test.db" - файл векторной бд, составленной с опорой на бд рецептов
  • embed_model: "BAAI/bge-m3" - модель для создания эмбеддингов
  • k: 3 - число возвращаемых документов

Результаты оценки

  • MRR@3 = 0.823
  • mAP@3 = 0.815

Дальнейшее направление развития

Для текущего набора документов показатели оказались достаточно неплохими. Однако в будущем необходимо проверить, как изменятся метрики, если привести документную базу ближе к реалиям (~ 1000 рецептов). Это также необходимо для того, чтобы покрыть наибольшее число нужд пользователей, поскольку выявлены запросы, для которых не было найдено ни одного подходящего документа (рецепт в базе отсутсвует). Помимо этого также можно поэксперементировать с параметрами k и embed_model