La mayoría de los fallos de RAG en las empresas empiezan en la búsqueda. Mídala como un sistema propio

Cuando un asistente corporativo da una mala respuesta, el primer sospechoso suele ser el modelo. Muchas veces el modelo hizo exactamente lo que se le pidió: resumió los documentos que recibió. El problema estaba en los documentos. La búsqueda devolvió una política desactualizada, la versión equivocada del contrato o nada relevante.

La mayoría de los equipos sigue evaluando solo la respuesta final. Eso hace que los fallos de búsqueda parezcan fallos del modelo, y lleva a la corrección equivocada. El nuevo método de Cohere para evaluar la búsqueda es una buena ocasión para separar ambas cosas.

Qué publicó Cohere

El 30 de septiembre, Cohere presentó RCP-nDCG@10 (Rubric-Calibrated Preferences nDCG@10), una forma de medir lo relevantes que son los diez primeros resultados de un sistema de búsqueda.

El problema que aborda es real. Las métricas habituales de búsqueda dependen de juicios de relevancia etiquetados de antemano para cada consulta. Cuando un sistema más nuevo encuentra documentos relevantes que nunca se etiquetaron, la métrica los cuenta como fallos. Cohere informa de que, entre los documentos que sus benchmarks marcaban como irrelevantes, las personas consideraron útil el 28%.

RCP-nDCG sustituye las etiquetas fijas por un juez de IA calibrado que valora cada documento recuperado con dos señales:

• una rúbrica de relevancia de cinco preguntas de sí o no, aplicada igual a todas las consultas;
• comparaciones por pares entre documentos, para estimar su orden relativo.

Un paso de calibración, basado en la teoría de respuesta al ítem, combina ambas. En palabras de Cohere, las comparaciones fijan el orden y la rúbrica lo sitúa en una escala común a todas las consultas.

Según Cohere, RCP-nDCG eligió el sistema que preferían los revisores humanos el 77% de las veces, frente al 52% del nDCG convencional, y en los márgenes más amplios los revisores coincidieron con él en el 97% de los casos. Son resultados de la propia Cohere. El artículo, el código y los datos están publicados, lo que permite una verificación independiente.

1. Pregunta
2. Búsqueda: los 10 primeros documentos
3. Generación: respuesta a partir de esos documentos
4. Respuesta al usuario

Medir la relevancia de lo encontradoMedir la fidelidad y la corrección de la respuesta

Por qué importa a los equipos

La búsqueda merece su propio marcador. Un sistema RAG (búsqueda en documentos de la empresa antes de responder) son dos sistemas: uno que encuentra y otro que redacta. Fallan de forma distinta y se corrigen de forma distinta. Un mejor chunking, filtros de metadatos, búsqueda híbrida o un reranker corrigen la búsqueda. Un prompt o un modelo mejor corrigen la generación. Sin métricas separadas, el equipo toca lo que no es.

Los conjuntos de prueba etiquetados envejecen. El contenido de una empresa cambia cada semana: nuevas políticas, productos y contratos. Un conjunto etiquetado hace seis meses penaliza al sistema por encontrar documentos que entonces no existían. Los jueces guiados por una rúbrica son una forma de mantener la evaluación al día sin volver a etiquetarlo todo a mano.

La rúbrica es un artefacto de negocio. “Relevante” significa una cosa para un analista de siniestros y otra para un abogado. Escribir las cinco preguntas que definen la relevancia en un caso de uso es trabajo de quien es dueño de ese caso, no solo de ingeniería.

Los jueces de IA también necesitan calibración. El método de Cohere es explícito sobre la calibración porque un juez sin calibrar solo cambia el problema de sitio. Cualquier juez LLM debe contrastarse con una muestra de juicios humanos, y volver a contrastarse cuando cambie el modelo del juez. Hicimos la misma advertencia en nuestro análisis sobre observabilidad de agentes.

España y Latinoamérica: evaluar en el español que se usa

Casi todos los benchmarks públicos de búsqueda están en inglés. Un sistema que puntúa bien en ellos puede fallar con documentos en español, con el vocabulario de cada sector y con las diferencias entre países: lo que en España es un “albarán” es un “remito” en Argentina y una “guía de remisión” en otros países. Para empresas de la región, eso implica:

• construir el conjunto de evaluación en español, con preguntas reales de los usuarios y documentos reales de la empresa;
• escribir la rúbrica con los términos de cada mercado cuando la misma aplicación sirve a varios países;
• comprobar cómo se comporta el juez de IA en español, comparando sus puntuaciones con las de revisores locales antes de confiar en ellas.

Qué hacer ahora

1. Registre los resultados de búsqueda por separado de las respuestas, en todas las pruebas y en una muestra de producción.
2. Escriba una rúbrica de relevancia con el responsable de negocio de cada caso de uso: qué hace útil un documento para esa pregunta.
3. Cree un pequeño conjunto etiquetado por personas y úselo para calibrar cualquier juez de IA antes de fiarse de sus puntuaciones.
4. Siga una métrica de ranking a lo largo del tiempo, como nDCG@10 o una variante calibrada, y repítala cuando cambien el contenido, los embeddings o el chunking.
5. Corrija la búsqueda antes de cambiar de modelo. Cuando las respuestas empeoren, revise primero qué se recuperó.

En resumen

RCP-nDCG@10 es una aportación de investigación, no un producto que haya que comprar. Su valor para las empresas está en la disciplina que propone: tratar la búsqueda como un sistema en producción, con su propia definición de calidad, sus propias pruebas y un responsable. Como defendimos en nuestro análisis de AIP Evolve, de Palantir, la evaluación se está convirtiendo en la superficie de control de los sistemas de IA. La búsqueda es donde deberían empezar muchos de esos controles.