Imaginemos un equipo que desarrolla un agente de inteligencia artificial y lo somete a una batería de preguntas representativas en un entorno de prueba, observando cómo proporciona respuestas útiles. Si alguien plantea una consulta ligeramente más compleja y el agente responde correctamente, realizan una demostración, aprueban los cambios y lanzan el producto al mercado.
Sin embargo, tras realizar una actualización en la configuración de recuperación o en el modelo semanas después, el agente sigue respondiendo a las preguntas iniciales, pero comienza a cometer errores: omite citas obligatorias o utiliza herramientas inapropiadas para consultar datos de clientes. Estas deficiencias no siempre son visibles hasta que los usuarios reportan incidencias o un sistema de monitorización las detecta.
Un simple test demuestra que el agente funcionó en condiciones dadas, pero no garantiza que futuras versiones mantendrán la fiabilidad requerida por usuarios y operadores. Por ello, la evaluación debe formar parte integral del proceso de entrega del producto. 
“Si no puede reproducir una ejecución o detectar una regresión significativa en un flujo de trabajo crítico, el producto no está listo para pasar el control de calidad y salir al mercado.”
Un sistema de evaluación repetible ejecuta escenarios predefinidos, registrando evidencias suficientes para decidir si un lanzamiento es adecuado. Debe incluir la ejecución completa: desde la recopilación de contexto, la selección de herramientas por parte del agente, hasta la aplicación de permisos en tiempo real. Si no se reproducen correctamente las operaciones o se detectan fallos relevantes en procesos de alto riesgo, el producto no debe avanzar.
Definir el comportamiento correcto antes de crear pruebas
Evaluar con el criterio vago de «la respuesta fue buena» es insuficiente. Antes de seleccionar herramientas de evaluación, hay que documentar claramente las tareas que realiza el agente, sus límites y qué resultados quedan fuera del margen aceptado.
Por ejemplo, en un agente de soporte, una tarea podría ser responder preguntas de facturación usando datos precisos de la cuenta correcta, citando la normativa vigente. No puede modificar planes ni mostrar información de otros clientes. Si la normativa no está disponible, debe reconocerlo y no ofrecer respuestas erróneas. Además, puede requerir solicitar un número de cuenta o desviar excepciones a un responsable autorizado.
Es fundamental diferenciar el resultado del proceso que lo produjo. Un agente puede entregar la respuesta correcta tras consultar un documento erróneo, utilizar herramientas innecesarias o incluso escalar solicitudes que debería gestionar solo. Estos casos aparentan éxito en una transcripción pero esconden debilidades que emergen en otras circunstancias.
Empieza con requisitos observables para cada tarea: los datos esenciales deben tener fuentes identificadas y las acciones de escritura deben esperar confirmación. Cuando falte información, el agente debe preguntar en lugar de conjeturar. Para normas de alto riesgo, las afirmaciones han de ser exactas, aunque el lenguaje pueda variar.
Construir escenarios basados en el trabajo real del usuario
La primera batería de pruebas debe ser manejable y representativa. Diez tareas reales superan en valor a grandes benchmarks con preguntas irrelevantes para los usuarios.
“Diez tareas reales valen más que un gran conjunto de pruebas con consultas que los usuarios nunca realizan.”
Como fuente, se pueden usar tickets de soporte, registros de flujos de trabajo, informes de incidencias y conversaciones con usuarios. Incluye solicitudes frecuentes, casos con instrucciones ambiguas o datos faltantes, pruebas con documentos obsoletos o herramientas que fallan por tiempo de espera. Algunos escenarios demandan aprobación previa al agente, y otros deben cubrir peticiones inusuales pero válidas.
Los agentes suelen operar mediante diálogos en varias etapas. Por ejemplo, el usuario pide cambiar datos de cuenta, proporciona información clave después y confirma en otro mensaje. La prueba debe asegurar que el agente mantiene el contexto correcto sin arrastrar detalles ajenos en la acción final.
Cada escenario requiere fijar “fixtures”: congelar los documentos, respuestas de las herramientas y el estado de la cuenta en un instante conocido. También es fundamental fijar la versión de la normativa y los permisos del agente. Estas condiciones hacen que fallos sean reproducibles y analizados como problemas técnicos en lugar de debates imprecisos.
Las fallas detectadas en producción deben integrarse en la suite de pruebas para evitar regresiones futuras y para que el equipo aprenda de errores ya ocurridos.
Evaluar toda la ruta de ejecución
Calificar sólo la respuesta final omite el valor fundamental que diferencia a un agente de un chatbot pasivo. El agente recupera datos, decide qué herramientas usar, envía argumentos, interpreta respuestas y determina si continuar. Cualquier paso puede desviarse sin que la respuesta parezca incorrecta a simple vista.
Se deben registrar la solicitud y las instrucciones del sistema; especificar el modelo y la compilación de la aplicación; guardar versiones del prompt, configuración de recuperación y esquemas de herramientas; así como todas las fuentes consultadas, llamadas a herramientas, parámetros, resultados, control de permisos, respuesta final, latencia, uso de tokens y costes. Esta trazabilidad responde preguntas operativas sin necesidad de reconstruir la ejecución mediante registros dispersos.
“Evaluar sólo la respuesta final pasa por alto diferencias críticas: cualquier paso puede desviarse del camino correcto aunque la contestación parezca adecuada.”
Combinado con controles del servidor y registros de auditoría, este seguimiento debe verificar búsquedas dentro del cliente correcto, citar la normativa aprobada y los registros usados en la respuesta. Para acciones que modifican datos, debe asegurarse que el usuario confirmó el cambio y que pasó controles de permiso. Estas comprobaciones son deterministas: o se hicieron o no.
Los indicadores de claridad y utilidad requieren revisión humana o evaluadores automáticos. Se otorgan puntuaciones por si la respuesta resolvió la petición, explicó limitaciones o planteó preguntas pertinentes. Mantén estas valoraciones junto a la trazabilidad para detectar qué paso originó la variación cuando la calidad baja.
Esto facilita detectar errores en los evaluadores, que pueden cambiar su criterio tras una actualización o ante un nuevo esquema de evaluación. Guarda versión e instrucciones del evaluador y compara periódicamente las puntuaciones con evaluaciones humanas.
Separar normas fijas de puntuaciones variables
La calidad del agente no puede resumirse en un único número. Deben seguirse indicadores de finalización de tareas, soporte factual, calidad de recuperación, cumplimiento normativo, experiencia de usuario, latencia y coste, por separado.
Algunas señales tienen tolerancias aceptables, como demoras menores o respuestas más extensas si mejoran la comprensión. Otras, como modificaciones no autorizadas o violaciones de permisos, no toleran fallos y bloquean la liberación del producto.
Compara la versión candidata con una base conocida usando los mismos escenarios y condiciones. Presenta a los revisores las respuestas cambiadas y los documentos subyacentes para que puedan entender qué alteraciones produjo cada ruta de herramienta y puntuación individual. Por ejemplo, si mejora las tareas completadas pero duplica latencia, la decisión puede ser válida; si mejora la nota media pero pasa por alto una revisión de permisos, no.
Repite escenarios con comportamiento variable hasta que alcancen una atención fiable. Una tarea que sólo funciona una vez de cada diez pruebas no cumple el estándar para lanzamiento. Define umbrales según el riesgo y reserva bloqueos absolutos para reglas imprescindibles.
No es necesario desarrollar herramientas propias; existen plataformas como Promptfoo, DeepEval, LangSmith o Braintrust que permiten crear flujos de evaluación, ejecutar escenarios, capturar trazas y aplicar evaluadores automáticos.
También conviene conocer términos métricos como pass@k (éxito en al menos uno de k intentos) y pass^k (éxito en todos los intentos), siendo éste último fundamental cuando la coherencia es esencial, aunque no sustituye los controles estrictos para reglas obligatorias.
La evaluación tiene costes: cada ejecución consume tokens, y las valoraciones más complejas y extensas incrementan el gasto. Por ello, reserva juicios costosos para escenarios con riesgos reales.
Incorporar la evaluación como filtro antes del lanzamiento
Ejecuta la suite de pruebas cada vez que se modifique el modelo, prompt, configuración de recuperación o interfaz de herramientas. Usa un conjunto reducido para cambios menores y un conjunto más amplio antes de actualizaciones mayores. Si la modificación implica un cambio intencionado en el comportamiento, exige aprobación manual para actualizar las expectativas en lugar de modificar los tests automáticamente.
Los registros generados durante la evaluación pueden contener datos sensibles de clientes, por lo que deben contar con los mismos controles que el propio agente: versiones, acceso restringido, cifrado y políticas de retención adecuadas. Considera la posibilidad de anonimizar datos confidenciales antes de almacenarlos.
Acercar esta infraestructura a los datos operacionales agiliza el proceso. Por ejemplo, Oracle AI Vector Search almacena vectores junto con datos de negocio y acepta consultas SQL que combinan búsqueda semántica, filtros relacionales y búsquedas textuales. Esta plataforma también puede alojar trazas de evaluación y aplicar controles de acceso a nivel de fila y columna, garantizando así la integridad y seguridad de la información.
El objetivo del filtro de lanzamiento es bloquear versiones que presenten patologías de riesgo alto, mientras que se permite evaluar cambios que requieren contexto. Las validaciones exactas impiden regresiones de permisos y cumplimiento, los umbrales detectan bajadas de calidad mensurables y la revisión humana resuelve casos ambiguos.
Comenzar con diez casos reales y conservar cada fallo significativo
Identifica diez tareas reales en la semana, documenta los resultados esperados, las evidencias que debe utilizar el agente y las acciones que no puede realizar. Fija los escenarios, captura trazas y somete estas pruebas antes del siguiente lanzamiento.
“La confianza en un agente crece cuando el equipo puede reproducir lo ocurrido y demostrar que una nueva versión mantiene las garantías que los usuarios necesitan.”
Cada incidente detectado debe añadirse a la suite de evaluación para mejorar la fiabilidad y aprendizaje continuo.
La evaluación es parte inseparable del producto que se entrega, esencial para mantener una inteligencia artificial robusta y confiable en entornos críticos.
¿Necesitas apoyo para evaluar agentes? Existen ejemplos prácticos de estos patrones en Oracle AI Database, incluyendo patrones agentic RAG combinados con búsquedas híbridas, disponibles en Oracle’s AI Developer Hub.
