«Funciona bien» no es una métrica: cómo evaluar un RAG sin fiarse de la demo
Casi todos los proyectos de IA en medios se validan probando diez preguntas a mano. Así es como se descubren los fallos tarde y en público.
La forma habitual de comprobar si un sistema de recuperación aumentada funciona es sentarse delante, escribir diez preguntas que se le ocurren a uno, leer las respuestas y decidir que tiene buena pinta.
Es un método comprensible y es insuficiente por dos motivos. Las diez preguntas que se le ocurren a quien ha construido el sistema no se parecen a las que hace un lector real. Y, sobre todo, al cambiar cualquier cosa —el troceado, el modelo, el número de fragmentos recuperados— no hay forma de saber si se ha mejorado o empeorado. Se avanza a ciegas.
El conjunto de referencia
La herramienta básica para salir de ahí no requiere ninguna tecnología: una lista de preguntas con su respuesta correcta y el artículo del que debería salir. Entre cincuenta y cien basta para empezar.
En un medio hay una fuente de preguntas que no hay que inventar: los registros del buscador interno. Ahí está lo que la gente escribe de verdad, con sus faltas de ortografía, sus siglas y su falta de contexto. Es material mucho mejor que cualquier lista redactada en una reunión.
Conviene incluir deliberadamente preguntas cuya respuesta no está en el archivo. Son las más informativas de todas, porque miden si el sistema sabe decir que no sabe. Un sistema que nunca dice «no consta» es un sistema que se inventa cosas, solo que todavía no le has pillado.
Medir por separado las dos mitades
Un RAG falla en dos sitios distintos y conviene no confundirlos, porque se arreglan de forma diferente.
La recuperación. ¿Está el fragmento correcto entre los que el sistema ha traído? Se mide contando: de cien preguntas, en cuántas aparece el artículo esperado entre los recuperados. Si esta cifra es baja, el problema está en el troceado, en la búsqueda o en los metadatos. Cambiar de modelo de lenguaje no va a arreglar nada.
La redacción. Dado que el fragmento correcto sí estaba disponible, ¿la respuesta lo usa bien y sin añadir nada? Aquí se mira si cada afirmación está respaldada por lo recuperado y si se responde de verdad a lo que se preguntaba.
La mayoría de los proyectos que van mal descubren, al separar las dos medidas, que su problema estaba en la primera. Y llevaban meses ajustando la segunda.
Sobre usar un modelo como juez
Evaluar cien respuestas a mano cada vez que se toca algo no es sostenible, así que la práctica extendida es usar un modelo de lenguaje para puntuarlas automáticamente.
Funciona razonablemente y tiene una trampa conocida: los modelos tienden a premiar las respuestas largas, bien estructuradas y seguras de sí mismas, que no siempre son las más exactas. Sirve para detectar si un cambio ha movido las cosas a mejor o a peor, no para certificar calidad en términos absolutos.
La recomendación práctica es combinar: automático para todo el conjunto en cada cambio, y revisión humana de una muestra pequeña cada cierto tiempo, para comprobar que el juez automático no se ha desviado.
Lo que hay que vigilar cuando ya está en producción
Un sistema en marcha necesita tres cosas registradas: qué se preguntó, qué fragmentos se recuperaron y qué se respondió. Sin ese registro, cuando un lector avise de una respuesta mala no habrá forma de reconstruir qué pasó.
Y un dato que suele revelar más que ninguna métrica: el porcentaje de preguntas en las que el sistema no encontró nada. Si sube, o el archivo tiene un agujero o los lectores están preguntando por cosas que la casa no cubre. Las dos son informaciones editorialmente útiles, más allá del sistema.
El criterio para lanzar
La pregunta no es si el sistema es perfecto, no lo va a ser. La pregunta es si es mejor que lo que hay ahora, que en la mayoría de los medios es un buscador por palabras clave que devuelve cero resultados con frecuencia.
Ese listón es más bajo de lo que parece. Pero hay que medirlo, no suponerlo.
