Haz que la respuesta de tu RAG sea defendible: una lista de verificación que muestra su proceso

En la pantalla de un producto, una respuesta de RAG con confianza no es suficiente. Los usuarios necesitan pruebas de que la respuesta proviene de la evidencia. El fallo puede ser sutil: presentar la afirmación de 10x de una fuente como una cifra del 10 % es un fallo de fidelidad incluso cuando el fragmento relevante fue recuperado. El patrón a evitar es el asistente que suena seguro mientras oculta sus fuentes. El rediseño es una respuesta defendible: recupera la evidencia correcta, se mantiene fiel a esa evidencia, cita la afirmación exacta y se niega a responder cuando falta la evidencia.

Para los diseñadores de producto y los gerentes de producto de IA que lanzan funciones RAG, ese estándar debe estar en el proceso de lanzamiento, no en la puntuación de una demo. Si la respuesta no supera las comprobaciones siguientes, el producto no debe permitir que el usuario confíe en ella.

La confianza sin evidencia es un fallo de diseño

La recuperación ocurre antes de que aparezca la respuesta. Un fragmento incorrecto aún puede generar una respuesta plausible. Las evaluaciones de recuperación deben realizarse antes de que se genere la respuesta, porque un contexto deficiente hace que cada afirmación posterior sea más difícil de creer. Una prueba útil es sencilla: toma una pregunta conocida y verifica si la evidencia necesaria para responderla aparece en el contexto recuperado.

El método HyDE incrusta una respuesta hipotética generada por el modelo en lugar de la consulta cruda del usuario para recuperar fragmentos. Puede ayudar cuando la redacción del usuario es vaga, pero añade un paso entre la pregunta y la fuente. La evaluación aún debe preguntarse si el material recuperado puede respaldar la afirmación de la respuesta.

Un conjunto de datos de evaluación utilizó 66 preguntas RAG aleatorias recopiladas de internet. Para una configuración seria de evaluación RAG, las recomendaciones apuntan a usar 200-1.000 consultas reales emparejadas con respuestas de referencia. Las consultas deben provenir del uso real del producto, no de una muestra ordenada que oculta los fallos.

Muestra el proceso antes de que el usuario confíe en la respuesta

La lista de verificación siguiente hace que ese rediseño sea testeable. Cada elemento es una prueba rápida que protege un modo de fallo diferente. Mantén la lista de verificación junto a la pantalla de respuesta, porque el usuario debe poder ver las mismas pruebas que ve la evaluación.

• Recall de recuperación: ¿El contexto recuperado contiene la evidencia necesaria para responder? Revisa la pregunta, los fragmentos recuperados y la pieza faltante. Un fragmento ausente deja la respuesta sin respaldo.
• Fidelidad de la respuesta: ¿Cada afirmación de la respuesta se deriva de la evidencia recuperada? Compara cada oración con el fragmento de la fuente. La respuesta no debe reformular la afirmación de la fuente para adaptarla a la expectativa del usuario.
• Precisión de la cita: ¿Cada cita apunta a la afirmación exacta que respalda? La precisión de la cita significa más que tener una fuente adjunta. El texto citado debe contener la afirmación, no un tema cercano que simplemente suene relacionado.
• Negativa ante evidencia ausente: ¿El sistema indica que no puede responder cuando la evidencia no está presente? Haz una pregunta fuera del material de la fuente y verifica una negativa en lugar de una invención. Una negativa es una funcionalidad cuando el usuario está a punto de tomar una decisión.

Los umbrales iniciales de producción reportados por profesionales exigen revisión humana cuando la fundamentación es inferior a 0,80 y bloqueo de la entrega al usuario cuando la fidelidad es inferior a 0,70. Son un estándar temporal, no una regla permanente. Existen para mantener al equipo honesto mientras el producto aprende dónde la evidencia es débil.

Juzga al juez antes de confiar en la puntuación

Muchos equipos usan un juez de modelo para puntuar la fidelidad, la calidad de la cita o la negativa. Puede escalar, pero el juez tiene sus propios sesgos. Cuando un juez LLM compara dos opciones de forma pareada, la opción listada primero recibe una ventaja debido al sesgo de posición. Cuando tu evaluación compara respuestas lado a lado, rota el orden o usa una rúbrica de puntuación que no dependa de la posición.

El sesgo de autopreferencia hace que un juez LLM otorgue puntuaciones más altas a las salidas producidas por modelos de la misma familia. El riesgo es máximo cuando el generador de respuestas y el juez son de la misma familia. Usa una familia de juez diferente o combina la puntuación automatizada con revisión humana en una muestra que incluya fallos y negativas.