Evaluación de la relevancia en búsquedas, parte 1: el índice de referencia BEIR

Conéctate fácilmente con las principales plataformas de inteligencia artificial y machine learning. Inicia una prueba gratuita en el cloud para explorar las capacidades de IA generativa de Elastic o pruébalo en tu máquina ahora mismo.

Esta es la primera de una serie de publicaciones del blog que analizan cómo evaluar tus propios sistemas de búsqueda en el contexto de una mejor comprensión del índice de referencia BEIR. Presentaremos consejos y técnicas específicas para mejorar tus procesos de evaluación de búsqueda en el contexto de una mejor comprensión de BEIR. También presentaremos errores comunes que hacen que la evaluación sea menos confiable. Finalmente, notamos que los LLM ofrecen una poderosa nueva herramienta en el repositorio de los ingenieros de búsqueda por lo que mostraremos, con un ejemplo, cómo se pueden usar para ayudar a evaluar la búsqueda.

Comprender el índice de referencia BEIR en la evaluación de la relevancia de búsqueda

Para mejorar cualquier sistema, debes poder medir su eficacia. En el contexto de una búsqueda, BEIR (o, de manera equivalente, la sección de recuperación de la tabla de clasificación de MTEB) se considera el “santo grial” para la comunidad de recuperación de información, y no es de extrañar. Es un índice de referencia muy bien estructurado con sets de datos variados para diferentes tareas. Más específicamente, se cubren las siguientes áreas:

• Recuperación de argumentos (ArguAna, Touche2020)
• QA de dominio abierto (HotpotQA, Natural Questions, FiQA)
• Recuperación de pasajes (MSMARCO)
• Recuperación de preguntas duplicadas (Quora, CQADupstack)
• Verificación de hechos (FEVER, Climate-FEVER, Scifact)
• Recuperación de información biomédica (TREC-COVID, NFCorpus, BioASQ)
• Recuperación de entidades (DBPedia)
• Predicción de citas (SCIDOCS)

Ofrece una única estadística, nDCG@10, relacionada con la capacidad de un sistema para encontrar los documentos más relevantes para cada ejemplo de tarea en los primeros resultados que devuelve. Para un sistema de búsqueda con el que interactúa un ser humano, la relevancia de los resultados principales es fundamental. Sin embargo, hay muchos matices a la hora de evaluar las búsquedas que una sola estadística resumida no refleja.

Estructura de un set de datos BEIR

Cada benchmark tiene tres artefactos:

• el corpus o los documentos que se van a recuperar
• las búsquedas
• los juicios de relevancia para las búsquedas (también conocidos como qrels).

Las evaluaciones de relevancia se ofrecen como una puntuación que es igual a cero o mayor. Las puntuaciones no nulas indican que el documento está algo relacionado con la búsqueda.

Tabla 1: Estadísticas de los sets de datos. Los números se calcularon en la parte de prueba de los sets de datos (dev para MSMARCO).

La Tabla 1 presenta algunas estadísticas para los sets de datos que comprenden el índice de referencia BEIR, como la cantidad de documentos en el corpus, la cantidad de búsquedas en el set de datos de prueba y la cantidad de pares positivos/negativos (búsqueda, documento) en el archivo qrels. Con una rápida mirada a los datos podemos inferir inmediatamente lo siguiente:

• La mayoría de los sets de datos no contienen relaciones negativas en el archivo qrels, es decir, puntuaciones cero, lo que indicaría explícitamente que los documentos son irrelevantes para la búsqueda dada.
• La cantidad promedio de relaciones de documentos por búsqueda (#qrels / #queries) varía desde 1.0 en el caso de ArguAna hasta 493.5 (TREC-COVID), pero con un valor de <5 para la mayoría de los casos.
• Algunos sets de datos tienen documentos duplicados en el corpus, lo que en algunos casos puede conducir a una evaluación incorrecta, es decir, cuando un documento se considera relevante para una búsqueda, pero su duplicado no lo es. Por ejemplo, en ArguAna hemos identificado 96 casos de pares de documentos duplicados con solo un documento por par marcado como relevante para una búsqueda. Al “expandir” la lista inicial de qrels para incluir también los duplicados, hemos observado un aumento relativo de ~1 % en la puntuación nDCG@10 en promedio.

Ejemplo de pares duplicados en ArguAna. En el archivo qrels solo el primero parece ser relevante (como contra-argumento) para la búsqueda (“test-economy-epiasghbf-pro02a”)

Al comparar modelos en la tabla de líderes de MTEB, es tentador centrarse en la calidad promedio de recuperación. Es un buen indicador de la calidad general del modelo, pero no necesariamente te dice cómo se aplicará en tu caso. Dado que los resultados se reportan por conjunto de datos, vale la pena entender hasta qué punto los diferentes conjuntos de datos se relacionan con tu tarea de búsqueda y volver a calificar modelos usando solo los más relevantes. Si quieres profundizar más, también puedes verificar si hay superposición de temas con los diversos conjuntos de datos. Estratificar las medidas de calidad por tema ofrece una evaluación mucho más detallada de sus fortalezas y debilidades específicas.

Una nota importante aquí es que cuando un documento no está marcado en el archivo qrels, por defecto, se considera irrelevante para la búsqueda. Nos adentramos un poco más en esta área y recopilamos algunas pruebas para aclarar la siguiente pregunta: “¿Con qué frecuencia se presentan pares al evaluador (búsqueda, documento) para los cuales no hay información fidedigna?”. La razón por la que esto es importante es que cuando solo se dispone de marcado superficial (y, por lo tanto, no todos los documentos relevantes están etiquetados como tales), un sistema de recuperación de información puede ser juzgado como peor que otro simplemente porque "elige" mostrar diferentes documentos relevantes (pero no marcados). Este es un problema habitual a la hora de crear conjuntos de evaluación de alta calidad, especialmente en el caso de sets de datos de gran tamaño. Para ser factible, el etiquetado manual generalmente se enfoca en los principales resultados devueltos por el sistema actual, por lo que potencialmente se pierden documentos relevantes en sus puntos ciegos. Por lo tanto, generalmente es preferible enfocar más recursos en un marcado más completo de menos búsquedas que en un marcado amplio y superficial.

Aprovechar el índice de referencia BEIR para la evaluación de relevancia en búsquedas

Para iniciar nuestro análisis implementamos el siguiente escenario (ver el cuaderno):

1. En primer lugar, cargamos el corpus de cada set de datos en un índice de Elasticsearch.
2. Para cada búsqueda en el conjunto de pruebas, recuperamos los 100 documentos principales con BM25.
3. Volvemos a clasificar los documentos recuperados utilizando una variedad de modelos de reclasificación SOTA.
4. Finalmente, presentamos el reporte de la “tasa de evaluación” para los 10 documentos principales que provienen de los pasos 2 (después de la recuperación) y 3 (después de la reclasificación). En otras palabras, calculamos el porcentaje promedio de los 10 documentos principales que tienen una puntuación en el archivo qrels.

La lista de reclasificación de modelos que utilizamos es la siguiente:

• rerank-english-v2.0 de Cohere y rerank-english-v3.0
• BGE-base
• mxbai-rerank-xsmall-v1
• MiniLM-L-6-v2

Tabla 2: Tasa de evaluación por pares (set de datos, reclasificador) calculada en los 10 primeros documentos recuperados/reclasificados

Desde Tabla 2, con la excepción de TREC-COVID (>90 % de cobertura), DBPedia (~65 %), Touche2020 y nfcorpus (~35 %), vemos que la mayoría de los sets de datos tienen una tasa de etiquetado entre el 5 % y un poco más del 10 % después de la recuperación o reclasificación. Esto no significa que todos estos documentos no marcados sean relevantes, pero podría haber un subconjunto de ellos, especialmente aquellos ubicados en las posiciones superiores, que podrían ser positivos.

Con la llegada de los modelos de lenguaje ajustados mediante instrucciones de propósito general, tenemos una nueva herramienta poderosa que potencialmente puede automatizar la evaluación de la relevancia. Estos métodos suelen ser demasiado costosos en cuanto a la complejidad de los procesos para ser utilizados en línea para la búsqueda, pero aquí nos preocupa la evaluación fuera de línea. A continuación, los usamos para explorar la evidencia de que algunos de los sets de datos BEIR tienen un marcado superficial.

Para investigar más a fondo esta hipótesis, decidimos centrarnos en MSMARCO y seleccionar un subconjunto de 100 búsquedas junto con los 5 principales documentos reclasificados (con Cohere v2) que actualmente no están marcados como relevantes. Seguimos dos caminos diferentes de evaluación: Primero, usamos un indicador cuidadosamente ajustado (veremos más sobre esto en una publicación posterior) para preparar el modelo Phi-3-mini-4k recientemente lanzado para predecir la relevancia (o no) de un documento para la búsqueda. Paralelamente, estos casos también se etiquetaron manualmente para evaluar la tasa de concordancia entre el resultado del LLM y el juicio humano. En general, podemos extraer estas dos conclusiones$\dag$:

• La tasa de acuerdo entre las respuestas de los LLM y los juicios humanos fue cercana al 80 %, lo que parece suficiente como punto de partida en esa dirección.
• En el 57.6 % de los casos (basado en el juicio humano) se descubrió que los documentos devueltos eran realmente relevantes para la búsqueda. Para decirlo de otra manera: Para 100 búsquedas tenemos 107 documentos considerados relevantes, ¡pero al menos 0.576 x 5 x 100 = 288 documentos adicionales que son realmente relevantes!

Aquí, algunos ejemplos extraídos del set de datos MSMARCO/dev que contienen la búsqueda, el documento positivo anotado (de qrels) y un documento falso negativo debido a un marcado incompleto:

Ejemplo 1:

Ejemplo 2:

La evaluación manual de búsquedas específicas como esta es una técnica generalmente útil para comprender la calidad de la búsqueda que complementa las medidas cuantitativas como nDCG@10. Si tienes un conjunto representativo de búsquedas que siempre ejecutas al hacer cambios en la búsqueda, te proporciona información cualitativa importante sobre cómo cambia el rendimiento, lo cual es invisible en las estadísticas. Por ejemplo, te da mucha más información sobre los resultados falsos que devuelve la búsqueda: puede ayudarte a detectar errores evidentes en los resultados recuperados, clases de errores relacionados, como malinterpretar terminología específica de un dominio, y así sucesivamente.

Nuestro resultado concuerda con la investigación relevante sobre la evaluación de MSMARCO. Por ejemplo, Arabzadeh et al. siguen un procedimiento similar en el que emplean trabajadores de crowdsourcing para hacer juicios de preferencia: entre otros puntos, muestran que en muchos casos se prefieren los documentos devueltos por los módulos de reclasificación en comparación con los documentos del archivo MSMARCO qrels. Otra evidencia proviene de los autores del reclasificador RocketQA quienes en su reporte indican que más del 70 % de los documentos reclasificados se consideraron relevantes luego de la inspección manual.

$\dag$ Actualización - 9 de septiembre: Tras una cuidadosa reevaluación del set de datos, identificamos 15 casos más de documentos relevantes, lo que aumenta el total de 273 a 288

Principales puntos clave y próximos pasos

• La búsqueda de mejores datos fidedignos es interminable, ya que es de vital importancia para la evaluación comparativa y la comparación de modelos. Los LLM pueden ayudar en algunas áreas de evaluación si se usan con precaución y se ajustan con las instrucciones adecuadas.
• De forma más general, dado que los índices de referencia nunca serán perfectos, podría ser preferible pasar de una comparación pura de puntaje a técnicas más sólidas que capturen diferencias estadísticamente significativas. El trabajo de Arabzadeh et al. ofrece un buen ejemplo de esto, donde, basándose en sus hallazgos, crean intervalos de confianza del 95 % que indican diferencias significativas (o no) entre las distintas secuencias. En el cuaderno adjunto se encuentra una implementación de intervalos de confianza usando bootstrapping.
• Desde la perspectiva del usuario final, es útil pensar en la alineación de tareas al leer los resultados de los índices de referencia. Por ejemplo, para un ingeniero de IA que crea una pipeline RAG y sabe que el caso de uso más típico implica ensamblar múltiple información de diferentes fuentes, sería más significativo evaluar el rendimiento de su modelo de recuperación en sets de datos de QA multisaltos, como HotpotQA, en lugar de la media global de todo el índice de referencia BEIR

En la próxima publicación del blog profundizaremos en el uso de Phi-3 como juez de LLM y en el proceso de ajustarlo para predecir su relevancia.

Preguntas frecuentes