AWS muestra cómo una precisión de búsqueda del 100% puede ocultar el fallo de un agente de IA

Su agente responde con seguridad a las preguntas de los empleados, adjunta enlaces y supera las comprobaciones de recuperación. ¿Está listo para lanzarse? En un ejemplo de AWS, los fragmentos recuperados alcanzaron una precisión del 100% según una de las métricas, pero no contenían la información necesaria para responder a una pregunta sobre una baja por enfermedad. Tras modificar el prompt, la respuesta empeoró todavía más. La lección práctica: antes de volver a cambiar las instrucciones, conviene comprobar si los documentos contienen la respuesta.

AWS describió este caso en un artículo sobre el Agent Development Lifecycle, o Agent DLC. Es un enfoque de desarrollo de agentes en el que el equipo define de antemano los criterios de aceptación, comprueba cada cambio e incorpora los problemas detectados en producción al conjunto de pruebas. Para quienes desarrollan estos sistemas, su valor está en ofrecer un método concreto para identificar qué componente necesita corregirse.

Por qué el 100% del informe no fue suficiente

Los autores crearon un agente de consultas de recursos humanos y lo probaron con tres preguntas. Entre las mediciones figuraban el respaldo de las afirmaciones en las fuentes, la utilidad de los fragmentos recuperados y la presencia de una respuesta para cada parte de la consulta del usuario.

Imaginen que un empleado pregunta cuándo debe presentar un certificado médico. La búsqueda devuelve un documento general sobre permisos y ausencias que menciona de pasada las bajas por enfermedad. El fragmento guarda relación con el tema y recibe una valoración positiva. Sin embargo, no indica el plazo para presentar el certificado. Esa es precisamente la diferencia que ocultaba la métrica de precisión aplicada a fragmentos completos.

Para la pregunta problemática, esa precisión fue del 100%, la proporción de datos útiles dentro del material recuperado fue del 9% y la cobertura de las subpreguntas, del 0%. Los autores revisaron después los documentos originales: efectivamente, el corpus no incluía una política específica sobre bajas por enfermedad.

El equipo cambió únicamente el prompt del sistema: exigió basarse estrictamente en las fuentes, ignorar la información irrelevante y responder de forma directa. En la pregunta sobre la evaluación de empleados, la proporción de afirmaciones respaldadas aumentó del 83% al 87%. En la pregunta sobre la baja por enfermedad, cayó del 39% al 31%. Las instrucciones no podían aportar la información que faltaba. El siguiente paso debería haber sido ampliar la base de conocimiento y comprobar la recuperación.

Qué comprobar antes del lanzamiento

En Agent DLC, el punto de partida es un conjunto acordado de criterios, umbrales y casos de prueba. Por ejemplo, para un agente de soporte hay que definir qué afirmaciones requieren una referencia, cuándo debe reconocer que no dispone de información y qué datos del cliente puede utilizar.

A continuación, el equipo evalúa una versión, reconstruye el recorrido hasta el error, cambia un componente y repite la evaluación con las mismas reglas. Este orden ayuda a vincular el resultado con un cambio concreto. Si se reescribe el prompt, se actualiza la base y se modifican los criterios al mismo tiempo, será mucho más difícil explicar la variación de la puntuación.

Se propone ejecutar cada caso varias veces: una misma consulta puede llevar al agente a dar respuestas distintas y a realizar diferentes llamadas a herramientas. También hay que comprobar a los propios evaluadores. Si otro modelo juzga las respuestas, conviene contrastar sus puntuaciones con ejemplos revisados por personas y medir su variabilidad.

Los criterios tienen distinto peso. Incumplir la prohibición de revelar datos de otras personas bloquea el lanzamiento. Para la calidad de las respuestas, se puede fijar un umbral de ejecuciones satisfactorias. Al principio, basta con observar algunos indicadores hasta que el equipo tenga la certeza de que puede medirlos de forma fiable.

Los límites de las conclusiones del experimento

Una puntuación alta de respaldo en las fuentes tampoco garantiza una respuesta aceptable. En un caso, el agente afirmó conocer el método de contacto preferido del usuario. No disponía de un perfil del usuario: el modelo combinó información de distintos documentos y la presentó como un dato personal. La respuesta obtuvo un 90% de respaldo en las fuentes, por lo que este tipo de invenciones requiere una comprobación específica.

El estudio tiene un alcance modesto: tres preguntas en una implementación de demostración. No es un resultado obtenido con un cliente ni demuestra que el enfoque esté listo para cualquier despliegue en producción. Los autores también advierten de que las puntuaciones varían entre ejecuciones.

Un paso práctico para el equipo es incorporar al conjunto de pruebas fallos reales de su propio agente. En cada caso, hay que determinar si las fuentes eran suficientes, si las herramientas se utilizaron correctamente y si apareció información inventada. Después, corregir la causa identificada y repetir las pruebas. También conviene programar comprobaciones periódicas: un modelo externo, una API o una base de conocimiento pueden cambiar sin que haya un solo commit en el repositorio.