Como el analisis de fallos en RAG reduce las respuestas sin respaldo del 34% al 9%

Cuando un sistema RAG comunica con seguridad un plazo, precio o regla incorrectos, la primera reaccion suele ser modificar el prompt. Se añade una frase como «responde solo a partir de los documentos», se endurece la redaccion y se vuelve a ejecutar la prueba. A veces funciona. Pero si el dato necesario nunca entro en el contexto, el modelo no podra utilizarlo, sea cual sea la instruccion.

La idea central del articulo es sencilla: una misma respuesta incorrecta puede ser consecuencia de fallos distintos. La recuperacion puede no haber encontrado el documento. El chunking puede haber partido una afirmacion importante. El reranker puede haber colocado en primer lugar un fragmento parecido, pero inadecuado. Por ultimo, el modelo puede haber recibido el contexto correcto, ignorarlo y responder de memoria. Cada caso exige una solucion diferente.

Una respuesta, tres posibles fallos

Imaginemos un asistente para la documentacion de un servicio en la nube. Un usuario pregunta si es posible restaurar un topic de Kafka eliminado. La documentacion indica que la eliminacion es irreversible, aunque los datos siguen almacenados fisicamente durante otros siete dias. El sistema responde: «El topic puede restaurarse desde la consola durante los siete dias siguientes, sin coste».

Aqui aparecen de inmediato tres afirmaciones sin confirmar: la posibilidad de restauracion, el metodo y el precio. Sin embargo, la expresion «siete dias» si figura en la fuente. Por eso, una comprobacion superficial basada en la coincidencia de palabras podria considerar que la respuesta esta respaldada.

Primero hay que examinar que fragmentos devolvio la recuperacion. Si no se encontro el parrafo sobre la irreversibilidad, el problema esta en el retrieval: conviene revisar el chunking, los embeddings, los filtros, la busqueda hibrida y el reranking. Si el fragmento correcto estaba presente, pero el modelo aun asi invento la restauracion, el fallo ya se encuentra en la generacion o en un conflicto entre el contexto y el conocimiento interno del modelo.

La ablacion muestra que influyo realmente en la respuesta

Una tecnica util consiste en repetir la consulta eliminando del prompt fragmentos individuales. Si, tras retirar el chunk sobre los siete dias de almacenamiento, el modelo deja de hablar de restauracion, significa que probablemente construyo una relacion causal incorrecta: convirtio el periodo de almacenamiento fisico en el plazo durante el cual una operacion seguia disponible para el usuario.

A continuacion, la respuesta se divide en afirmaciones verificables independientes. Cada cifra, plazo, precio y accion requiere un fragmento concreto que le sirva de respaldo. La mera mencion de una entidad no basta: que un documento contenga la palabra «Berlin» no demuestra que alli se identifique a Berlin como la capital de Alemania.

Por ultimo, conviene retirar todo el contexto relevante. Si la respuesta apenas cambia, probablemente el modelo la genero de memoria y utilizo el documento recuperado solo como una cita decorativa. Una comprobacion convencional de implicacion logica entre el texto y la fuente puede no detectar esta sustitucion, porque responde a la pregunta de si las afirmaciones son compatibles, pero no muestra si la fuente influyo en la generacion.

Que implementar en un sistema RAG de produccion

El conjunto minimo de observabilidad consiste en registrar la consulta, los fragmentos top-k recuperados, sus puntuaciones y el prompt final. Para las consultas etiquetadas, resulta util calcular Recall@k: si el fragmento necesario aparecio entre los resultados de busqueda. Es mejor medir esta metrica sobre trafico real y no solo con ejemplos sinteticos cuidadosamente preparados.

En las respuestas criticas, debe exigirse un fragmento de respaldo para cada afirmacion relevante. Si no existe apoyo directo, la respuesta honesta «no se especifica en la documentacion» es mas segura que una suposicion expresada con confianza. Las cifras, los plazos y los precios pueden enviarse automaticamente a una verificacion adicional.

El metodo tiene limitaciones. Las ablaciones requieren llamadas adicionales al modelo, aumentan la latencia y el coste, y un cambio en la respuesta no siempre demuestra causalidad de forma inequivoca. Por eso conviene ejecutarlas de manera selectiva: sobre una pequeña parte del trafico, en respuestas con citas y en escenarios de alto riesgo.

El resultado practico es que el equipo deja de tratar todos los errores con un mismo prompt. Si no se encontro la fuente, se corrigen la recuperacion y el chunking. Si se encontro el contexto, pero se ignoro, se trabaja sobre las instrucciones y la arquitectura de generacion. Si la cita se añadio a posteriori, se refuerza la verificacion de atribucion. En el ejemplo descrito por el autor, el conjunto de estas medidas redujo la proporcion de afirmaciones sin respaldo del 34% al 9%.