Cómo evaluamos el retrieval: un golden set, una fila sin fuga y un banco de pruebas que se niega a correr

Nuestro sistema interno de conocimiento, Cortex, les sirve contexto a los agentes de código que trabajan en nuestros repositorios: reglas, decisiones pasadas, cosas que aprendimos a los golpes. Todo cambio en cómo busca pasa por un banco de pruebas antes de quedarse. Este artículo es el manual de ese banco: no los números, sino las tres decisiones que hacen que los números signifiquen algo.

Si te quedas con una sola idea: la mayor parte del trabajo en un banco de pruebas de retrieval es decidir cuándo no confiar en él.

1. El golden set sale de juicios que ya teníamos

No escribimos consultas de prueba a mano. Cada vez que Cortex le sirve contexto a un agente, registra la tarea en la que el agente estaba trabajando. Cuando el agente termina, marca cada ítem que recibió como helped, noise o wrong. Una tarea registrada más esos veredictos es un juicio de relevancia, así que el golden set se arma leyendo el registro como tal.

El set actual tiene 433 consultas de 35 proyectos, con 738 documentos marcados como útiles y 252 como ruido. Llegar ahí llevó cuatro filtros, y cada uno existe porque sin él la métrica miente:

• Se dejan afuera los ítems que se sirven siempre. Las reglas entran en todo brief sin pasar por el ranking. Contarlas como aciertos le daría al retrieval crédito por algo que no hizo.
• Una consulta necesita al menos un positivo. Un servicio donde todo fue ruido no dice nada sobre dónde debería haber estado el documento bueno.
• El positivo tiene que seguir existiendo. Un documento retirado ya no está en el índice. Pedirle a la búsqueda que lo devuelva le resta recall por algo que no puede hacer.
• Las tareas repetidas se cuentan una vez. Los agentes corren la misma tarea en varias sesiones. Conservar las repeticiones infla la muestra sin agregar información, y le da doble peso a lo más frecuente.

Queda un sesgo, y lo tenemos escrito para no engañarnos después: sólo tiene etiqueta lo que se sirvió alguna vez. Si existía un documento mejor y nunca llegó a un brief, nadie lo juzgó, y este banco no puede premiar que se lo encuentre. Es el problema clásico de los datos de clics. El set sirve para comparar dos rankings sobre los mismos pares, que es lo que pide decidir un cambio, y no para afirmar un número absoluto de calidad.

2. Una sola fila puede decidir

El banco imprime varias configuraciones de la misma búsqueda, y sólo una es la métrica principal.

Cortex tiene dos funciones que mejoran los resultados en producción: un salto por el grafo que trae documentos relacionados con los encontrados, y boosts que suben en el ranking a los documentos que ayudaron antes. Las dos se aprenden de los mismos veredictos helped / noise con los que se arma el golden set.

Medir con ellas encendidas es tomar el examen con las respuestas adentro. Un documento que ayudó en una consulta recibe un boost, y después el banco hace esa misma consulta y premia al boost por encontrarlo.

Así que las filas son:

fila	grafo	boosts	sirve para
core	no	no	decidir. Ciega a las etiquetas por construcción
+ grafo	sí	no	referencia
+ grafo + boosts	sí	sí	lo que ven los usuarios hoy — sólo referencia
+ grafo + boosts, honesta	sí	sí, menos los veredictos del propio servicio de esa consulta	referencia

La última fila es un leave-one-out parcial: para cada consulta, los boosts se calculan sin los juicios que vinieron del servicio de esa consulta. Es parcial, y lo decimos: los pesos de las aristas del grafo viven en una tabla y no se pueden desaprender por consulta, así que del lado del grafo queda algo de fuga difusa. La fuga directa, que era la fuerte, desapareció.

Un cambio en la búsqueda se juzga sobre core. Si sólo se ve bien en las filas con boosts, no se demostró que sea bueno.

3. El banco se niega a medir

Esta es la parte que construiríamos primero si empezáramos de nuevo. Hay cuatro controles. En dos de ellos el banco se detiene y sale con error en vez de imprimir un número; en los otros dos imprime el número con una advertencia encima. Cada uno viene de una vez que imprimió un número y el número estaba mal.

Un componente de la búsqueda está caído. Cortex es híbrido: un lado léxico (BM25) y un lado denso (embeddings), fusionados. Si un lado falla, la búsqueda sigue contestando con el otro. Eso es buen comportamiento en producción y veneno en un banco de pruebas: una vez medimos media hora de "retrieval híbrido" con el servidor de embeddings apagado, que era sólo búsqueda léxica. Antes de cada corrida el banco manda una consulta de sondeo y comprueba que contestaron todos los lados. Si uno no lo hizo, se detiene:

  COMPONENTE CAÍDO: dense
  El sistema se degrada en silencio, así que la medición sería de otra cosa.

Medir igual exige un flag que hay que escribir a propósito.

Adentro de esta hubo una segunda lección. El control sólo funciona si un componente puede decir que está caído. Nuestro lado léxico atrapaba sus propios errores y devolvía una lista vacía, que la búsqueda no puede distinguir de "busqué y no encontré nada". Seguía reportándose sano mientras aportaba cero. Lo descubrimos por casualidad al apagarlo para un experimento: la corrida decía estar sana, reportaba un recall top-24 de 0,443, y en realidad medía sólo embeddings, con 0,371. Un respaldo que devuelve un resultado vacío no es degradación elegante. Es un verde falso.

El golden set está viejo. El set de prueba se juzgó contra los documentos que existían el día que se armó. Cuando el corpus crece y el set no, los documentos nuevos suman competencia sin sumar respuestas que puedan contar como correctas. Lo aprendimos cuando poner al día el índice de embeddings agregó 238 documentos y el recall top-24 bajó, de 0,374 a 0,362, sin que nada empeorara. El golden set ahora lleva un archivo que dice cuándo se armó y qué tamaño tenía el corpus. Pasados 30 días el banco se niega a correr. Si el corpus se movió más de un 5 % desde entonces, avisa. Rearmar el set es parte de reindexar.

El corpus se movió entre dos corridas. Se aprueban documentos en Cortex mientras alguien está midiendo. Una vez se aprobaron tres entre dos corridas (de 193 a 196), el recall top-5 pasó de 0,332 a 0,377, y pasamos una tarde culpando a la base vectorial y al servidor de embeddings antes de mirar el corpus. Uno de los documentos nuevos trataba justamente del cambio que se estaba midiendo. Cada corrida ahora guarda una huella del corpus, y una comparación entre corridas con huellas distintas llega con una advertencia arriba.

La comparación no está pareada. Dos corridas se comparan consulta por consulta, con un intervalo de confianza del 95 % sobre las diferencias. Si el intervalo cruza el cero, el resultado es "indistinguible", digan lo que digan los promedios. Esta la aprendimos equivocándonos: anunciamos una mejora de la búsqueda léxica como "+27 % de recall@5, +22 % de recall@24, −36 % de ruido" comparando medias. Con 56 consultas en ese momento, el test pareado dijo que sólo una se sostenía: recall top-5, +0,102, intervalo de +0,033 a +0,172. La decisión igual fue correcta. El tamaño que anunciamos, no.

Lo que cuesta y lo que compra

Ninguno de estos controles es ingenioso. Cada uno son unas pocas líneas: una consulta de sondeo, un chequeo de fecha, una cuenta, una diferencia pareada. Lo que compran es que un número que sale del banco ya sobrevivió a las formas en que nos engañó antes.

Dos límites valen para todo. El set de prueba mide lo que a los agentes les resultó útil para sus tareas, no lo que se parece a la consulta, que es un objetivo más estricto y distinto del de la mayoría de los bancos públicos de retrieval. Y los intervalos de confianza son tan ajustados como la muestra: con 56 consultas sólo se detectaban efectos por encima de 0,07, más o menos, y por eso agrandar el golden set fue el cambio con más palanca sobre todo lo demás.

El banco dice si un cambio funcionó. Qué cambio probar después, y qué resultado nos haría abandonarlo, es otro proceso, contado en Cómo decidimos qué probar después en el retrieval.

Si estás construyendo el tuyo: escribe los controles antes del primer resultado en el que quieras creer.