Podrías preguntarte, ¿por qué usar varios gráficos? Este es un efecto secundario de una elección arquitectónica en Lucene: segmentos inmutables. Como ocurre con la mayoría de las opciones arquitectónicas, hay pros y contras. Por ejemplo, recientemente lanzamos Elasticsearch sin servidor con GA. En este contexto, obtuvimos beneficios muy significativos de los segmentos inmutables, incluida la replicación eficiente de índices y la capacidad de desacoplar el índice y el proceso de consulta y escalarlos automáticamente de forma independiente. Para la cuantificación vectorial, las fusiones de segmentos nos dan la oportunidad de actualizar los parámetros para adaptarlos a las características de los datos. En este sentido, creemos que hay otros beneficios que ofrece tener oportunidades para medir las características de los datos y revisar las opciones de indexación.

En esta publicación, discutiremos el trabajo que estuvimos haciendo para reducir significativamente la sobrecarga de crear múltiples gráficos HNSW y, en individuo, para reducir el costo de fusionar gráficos.

Fondo

Para mantener un número manejable de segmentos, Lucene verifica periódicamente si debe fusionar segmentos. Esto equivale a comprobar si el recuento de segmentos actual supera un recuento de segmentos de destino, que está determinado por el tamaño del segmento base y la política de combinación. Si se supera el recuento, Lucene combina grupos de segmentos mientras se infringe la restricción. Este proceso se describió en detalle en otra parte.

Lucene elige fusionar segmentos de tamaño similar porque esto logra un crecimiento logarítmico en la amplificación de escritura. En el caso de un índice vectorial, la amplificación de escritura es el número de veces que se insertará un vector en un gráfico. Lucene intentará fusionar segmentos en grupos de aproximadamente 10. En consecuencia, los vectores se insertan en un gráfico aproximadamente veces, donde es el recuento de vectores índice y es el recuento de vectores de segmento base esperado. Debido al crecimiento logarítmico, la amplificación de escritura es de un solo dígito incluso para índices enormes. Sin embargo, el tiempo total dedicado a fusionar gráficos es linealmente proporcional a la amplificación de escritura.

Al fusionar gráficos HNSW ya hacemos una pequeña optimización: retener el gráfico para el segmento más grande e insertar vectores de los otros segmentos en él. Esta es la razón del factor 9/10 anterior. A continuación, mostramos cómo podemos hacerlo significativamente mejor empleando información de todos los gráficos que estamos fusionando.

Fusión de grafos HNSW

Antes conservábamos el grafo más grande e insertábamos vectores de los otros ignorando los gráficos que los contenían. La idea clave que aprovechamos a continuación es que cada grafo HNSW que descartamos contiene información importante de proximidad sobre los vectores que contiene. Nos gustaría usar esta información para acelerar la inserción, al menos algunos, de los vectores.

Nos enfocamos en el problema de insertar un gráfico más pequeño en un gráfico más grande , ya que esta es una operación atómica que podemos usar para construir cualquier política de combinación.

La estrategia consiste en encontrar un subconjunto de vértices de insertarlos en el gráfico grande. Luego usamos la conectividad de estos vértices en el gráfico pequeño para acelerar la inserción de los vértices restantes . A continuación, usamos y para denotar los vecinos de un vértice en el grafo pequeño y grande, respectivamente. Esquemáticamente, el proceso es el siguiente.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Calculamos el conjunto empleando un procedimiento que discutimos a continuación (línea 1). Luego insertamos cada vértice en en el gráfico grande usando el procedimiento de inserción HNSW estándar (línea 2). Para cada vértice que no insertamos encontramos sus vecinos que insertamos y sus vecinos en el gráfico grande (líneas 4 y 5). Usamos un procedimiento FAST-SEARCH-LAYER sembrado con este conjunto (línea 6) para encontrar los candidatos para el SELECT-NEIGHBORS-HEURISTIC del artículo HNSW (línea 7). En efecto, estamos reemplazando SEARCH-LAYER para encontrar el conjunto candidato en el método INSERT (Algoritmo 1 del artículo), que de lo contrario no cambia. Finalmente, agregamos el vértice que acabamos de insertar en (línea 8).

Está claro que para que esto funcione, cada vértice en debe tener al menos un vecino en . De hecho, requerimos que para cada vértice en que para algunos , la máxima conectividad de capa. Observamos que en los gráficos reales de HNSW vemos una gran dispersión de grados de vértice. La siguiente figura muestra una función de densidad acumulativa típica del grado de vértice para la capa inferior de un gráfico HNSW de Lucene.

Exploramos el uso de un valor fijo para así como convertirlo en una función del grado del vértice. Esta segunda opción conduce a mayores aceleramientos con un impacto mínimo en la calidad del gráfico, por lo que optó por lo siguiente

Tenga en cuenta que | es igual al grado del vértice en el gráfico pequeño por definición. Tener un límite inferior de dos significa que insertaremos cada vértice cuyo grado sea menor que dos.

Un argumento de conteo simple sugiere que si elegimos con cuidado, solo necesitamos insertar alrededor en directamente. Específicamente, coloreamos una arista del grafo si insertamos exactamente uno de sus vértices finales en . Entonces sabemos que para que cada vértice en tenga al menos vecinos en , necesitamos colorear al menos aristas. Además, esperamos que

Aquí, es el grado medio del vértice en la gráfica pequeña. Para cada vértice coloreamos como máximo Bordes. Por lo tanto, el número total de bordes que esperamos colorear es como máximo . Esperamos que al elegir con cuidado coloreemos cerca de este número de aristas y así cubrir todos los vértices necesidades para satisfacer

Esto implica que .

Siempre que SEARCH-LAYER domine el tiempo de ejecución, esto sugiere que podríamos lograr un aceleramiento de hasta en el tiempo de fusión. Dado el crecimiento logarítmico de la amplificación de escritura, esto significa que incluso para índices muy grandes, normalmente solo duplicaríamos el tiempo de construcción en comparación con la construcción de un gráfico.

El riesgo en esta estrategia es que dañamos la calidad del gráfico. Inicialmente lo intentamos con un FAST-SEARCH-LAYERsin operación. Descubrimos que esto degrada la calidad del gráfico en la medida en que la recuperación en función de la latencia se vio afectada, particularmente cuando se fusiona en un solo segmento. Luego exploramos varias alternativas empleando una búsqueda limitada del gráfico. Al final, la elección más efectiva fue la más simple. Usar SEARCH-LAYER pero con un ef_constructionbajo. Con esta parametrización pudimos lograr gráficos de excelente calidad y aún así disminuir el tiempo de fusión en un poco más del 30% en promedio.

Cálculo del conjunto de unión

Encontrar un buen conjunto de unión puede formular como un problema de cobertura de grafos HNSW. Una heurística codiciosa es una heurística simple y efectiva para aproximar cubiertas óptimas de grafos. El enfoque que tomamos elige vértices uno a uno para sumar a en orden decreciente de ganancia. La ganancia se define de la siguiente manera:

Aquí, denota el recuento de vecinos de un vector en y es la función indicadora. La ganancia incluye el cambio en el recuento del vértice que agregamos a , es decir, ya que nos acercamos a nuestro objetivo al agregar un vértice menos cubierto. El cálculo de la ganancia se ilustra en la siguiente figura para el vértice naranja central.

Mantenemos el siguiente estado para cada vértice :

1. Ya sea rancio,

2. Su ganancia

3. El recuento de vértices adyacentes en denotado

4. Un número aleatorio en el rango [0,1] que se usa para el desempate.

El pseudocódigo para calcular el conjunto de combinaciones es el siguiente.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Primero inicializamos el estado en las líneas 1-5.

En cada iteración del bucle principal extraemos inicialmente el vértice de ganancia máxima (línea 8), rompiendo los empates al azar. Antes de realizar cualquier cambio, debemos verificar si la ganancia del vértice está obsoleta. En individuo, cada vez que agregamos un vértice a afectamos la ganancia de otros vértices:

1. Dado que todos sus vecinos tienen un vecino adicional en , sus ganancias pueden cambiar (línea 14)

2. Si alguno de sus vecinos ahora está completamente cubierto, todas las ganancias de sus vecinos pueden cambiar (líneas 14-16)

Recalculamos las ganancias de manera perezosa, por lo que solo recalculamos la ganancia de un vértice si queremos insertarlo en (líneas 18-20). Dado que las ganancias solo disminuyen, nunca podemos perder un vértice que debamos insertar.

Tenga en cuenta que simplemente necesitamos realizar un seguimiento de la ganancia total de vértices que agregamos a para determinar cuándo salir. Además, al menos un vértice tendrá una ganancia distinta de cero, por lo que siempre progresamos.

Resultados

Realizamos experimentos en cuatro conjuntos de datos que juntos cubren nuestras tres métricas de distancia admitidas (euclidiana, coseno y producto interno):

1. quora-E5-small: 522931 documentos, 384 dimensiones y emplea la similitud del coseno,

2. cohe-wikipedia-v2: 1M de documentos, 768 dimensiones y emplea similitud de coseno,

3. gist: 1M documentos, 960 dimensiones y emplea la distancia euclidiana, y

4. cohe-wikipedia-v3: 1M de documentos, 1024 dimensiones y emplea el máximo producto interno.

Para cada conjunto de datos evaluamos dos niveles de cuantificación:

1. int8: que emplea un entero de 1 byte por dimensión y

2. BBQ: que emplea un solo bit por dimensión.

Finalmente, para cada experimento evaluamos la calidad de la búsqueda a dos profundidades de recuperación y examinamos luego de construir el índice y luego luego de forzar la fusión en un solo segmento.

En resumen, logramos aceleramientos sustanciales consistentes en la indexación y la fusión mientras mantenemos la calidad del gráfico y, por lo tanto, el rendimiento de búsqueda en todos los casos.

Experimento 1: cuantización int8

Los aceleramientos promedio desde la línea de base hasta el candidato, los cambios propuestos, son:

Aceleramiento del tiempo del índice: 1.28

Forzar la velocidad de combinación: 1.72

Esto corresponde al siguiente desglose en tiempos de ejecución

Para completar, los tiempos exactos son

Índice

Fusionar

Conjunto de datos

referencia

candidato

Desarrolla

candidato

quora-E5-pequeño

112.41s

81.55s

113.81s

70.87s

wiki-cohesión-v2

158.1s

122,95 segundos

425.20s

239.28s

quid

141.82s

119.26s

536.07s

279.05s

wiki-cohesión-v3

211.86s

168.22s

654,97 segundos

414.12s

A continuación, mostramos los gráficos de recuperación frente a latencia que comparan el candidato (líneas discontinuas) con la línea de base en dos profundidades de recuperación: recall@10 y recall@100 para índices con múltiples segmentos (el resultado final de nuestra estrategia de fusión predeterminada luego de indexar todos los vectores) y luego de forzar la fusión en un solo segmento. Una curva más alta y más a la izquierda es mejor, lo que significa una mayor recuperación con una latencia más baja.

Como puede ver, para índices de múltiples segmentos, el candidato es mejor para el conjunto de datos Cohere v3 y un poco peor, pero casi comparable, para todos los demás conjuntos de datos. Luego de fusionar en un solo segmento, las curvas de recuperación son casi idénticas para todos los casos.

Experimento 2: Cuantización de asado

Los aceleramientos promedio desde la línea de base hasta el candidato son:

Aceleramiento del tiempo de índice: 1.33

Forzar la velocidad de combinación: 1.34

Esto corresponde al siguiente desglose en tiempos de ejecución

Para completar, los tiempos exactos son

Índice

Fusionar

Conjunto de datos

referencia

candidato

Desarrolla

candidato

quora-E5-pequeño

70.71s

58.25s

59.38s

40.15s

wiki-cohesión-v2

203.08s

142.27s

107.27s

85.68s

quid

110.35s

105,52 segundos

323,66 segundos

202.2s

wiki-cohesión-v3

313.43s

190.63s

165,98 segundos

159,95 segundos

Para índices de segmentos múltiples, el candidato es mejor para casi todos los conjuntos de datos, excepto cohere v2, donde la línea de base es ligeramente mejor. Para los índices de un solo segmento, las curvas de recuperación son casi idénticas para todos los casos.

Conclusión

El algoritmo discutido en este blog estará disponible en el próximo Lucene 10.2 y en la versión de Elasticsearch que se basa en él. Los usuarios podrán aprovechar el rendimiento mejorado de la combinación y el tiempo de compilación de índices reducido en estas nuevas versiones. Este cambio es parte de nuestro esfuerzo continuo para hacer que Lucene y Elasticsearch sean rápidos y eficientes para la búsqueda vectorial e híbrida.

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.

Set de datos

Tamaño del corpus

#Búsquedas en el conjunto de pruebas

#qrels etiquetados positivamente

#qrels igual a cero

#duplicados en el corpus

Arguana

8,674

1,406

1,406

0

96

Climate-FEVER

5,416,593

1,535

4,681

0

0

DBPedia

4,635,922

400

15,286

28,229

0

FEVER

5,416,568

6,666

7,937

0

0

FiQA-2018

57,638

648

1,706

0

0

HotpotQA

5,233,329

7,405

14,810

0

0

Preguntas naturales

2,681,468

3,452

4,021

0

16,781

NFCorpus

3,633

323

12,334

0

80

Quora

522,931

10,000

15,675

0

1,092

SCIDOCS

25,657

1000

4,928

25,000

2

SciFact

5,183

300

339

0

0

Touche2020

382,545

49

932

1,982

5,357

TREC-COVID

171,332

50

24,763

41,663

0

MSMARCO

8,841,823

6,980

7,437

0

324

CQADupstack (suma)

457,199

13 145

23,703

0

0

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

Recuperación

Reclasificación

Set de datos

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

9.88

FiQA-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Preguntas naturales

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

SciFact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack (promedio)

5.47

6.32

6.87

5.89

6.22

6.16

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:

• 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.

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.