Rubricas de evaluación de agentes que viajan a través de pilas

Definiendo una rubrica lista para viajar

Comienzo escribiendo la rubrica antes de mirar cualquier salida del modelo. La rubrica debe contener tres ejes independientes: éxito de la tarea, corrección de la herramienta y fidelidad. Cada eje tiene su propia guía de puntuación que no menciona el nombre del modelo, la versión del marco o la redacción exacta de la solicitud. Mantengo las guías en un archivo de texto plano que vive junto a la suite de pruebas para que cualquier persona pueda verificarlas.

Propiedades básicas

- Criterios pre-registrados: las condiciones de éxito se escriben antes de la primera ejecución. - Aislamiento de ejes: las puntuaciones de un eje nunca se mezclan con otro. - Lenguaje libre de versiones: evitar frases como "a partir de GPT-4" o "al usar LangChain 0.1".

Cuando sigo estas propiedades, la misma rubrica me da números comparables ya sea que ejecute el agente con OpenAI's GPT-4o, Anthropic's Claude 3 o un modelo local Llama 3.

Por qué el éxito de la tarea debe ser basado en el resultado

El éxito de la tarea responde a la simple pregunta: ¿el agente completó lo que se le pidió? Juzgo esto contra una lista de verificación que mira el estado final del mundo, no la redacción de la respuesta. Por ejemplo, si la tarea es "actualizar la dirección de correo electrónico del usuario a alice@example.com", verifico el registro de la base de datos después de la ejecución. No me importa si el agente dijo "He actualizado su correo" o "Su correo electrónico ahora es alice@example.com".

Lista de verificación concreta

- Pre-condición verificada (por ejemplo, el usuario existe). - Post-condición verificada (por ejemplo, el campo de correo electrónico es igual a alice@example.com). - No hay efectos secundarios extra (por ejemplo, no se cambiaron otros campos). - Opcional: latencia por debajo de un umbral (por ejemplo, 2 segundos).

Registro de un resultado binario de aprobado/reprobado para cada trayectoria. Si el agente falla la post-condición, la puntuación de éxito de la tarea es cero, independientemente de lo fluida que se vea la prosa.

Corrección de la herramienta como un eje separado

La corrección de la herramienta mira las llamadas que el agente hace a APIs externas, funciones o bases de datos. Trato cada llamada como un mini-experimento: ¿el agente eligió la herramienta correcta, pasó los argumentos correctos y la llamó la cantidad correcta de veces? Sigo la guía de las hojas de trucos de OWASP sobre el uso seguro de herramientas, por ejemplo, la Hoja de trucos de prevención de inyección de solicitudes de LLM y la Hoja de trucos de prevención de inyección de SQL para evitar la inyección accidental.

Rubrica de puntuación

- Herramienta correcta seleccionada: 1 punto. - Todos los argumentos coinciden con el esquema: 1 punto por argumento. - No hay llamadas extra: 1 punto si el recuento de llamadas es igual al esperado. - No hay efectos secundarios prohibidos (por ejemplo, escribir en un registro que debería permanecer de solo lectura): 1 punto.

La puntuación del eje es la suma de los puntos dividida por la puntuación máxima posible. Mantengo este eje separado para que un error en el uso de la herramienta no oculte un éxito en la finalización de la tarea.

Fidelidad: trazando cada afirmación

La fidelidad pregunta si cada afirmación en la salida del agente se puede rastrear hasta los resultados de la herramienta o el contexto que se le dio al modelo. Trato la salida como un conjunto de afirmaciones y verifico cada una contra la evidencia. Si una afirmación no se puede respaldar, la marco como una alucinación. Este eje es más importante cuando el agente resume documentos, cita fuentes o responde preguntas que requieren datos externos.

Verificación paso a paso

- Dividir la salida en oraciones atómicas. - Para cada oración, listar los hechos que afirma. - Emparejar cada hecho con una línea en la salida de la herramienta o con un fragmento del contexto proporcionado. - Si un hecho no tiene coincidencia, contar como un fracaso. - Puntuación de fidelidad = (número de hechos respaldados) / (número total de hechos).

Registro de los recuentos brutos para que pueda ver si una disminución en la fidelidad proviene de unas pocas alucinaciones grandes o muchas pequeñas.

Qué no es esto

Quiero ser claro sobre los límites de una rubrica lista para viajar. No garantiza que el agente sea seguro, barato o rápido. No promete una precisión del 100% en cada entrada posible. No reemplaza una revisión de seguridad dedicada, un análisis de costos o una medición de latencia. La rubrica solo mide los tres ejes que definí anteriormente. Si necesitas saber si el agente filtra claves privadas, debes ejecutar una verificación de gestión de secretos por separado, por ejemplo, utilizando la Hoja de trucos de gestión de secretos. Si necesitas saber si el agente se mantiene dentro de un presupuesto, debes rastrear el uso de tokens o los costos de llamadas a APIs fuera de esta rubrica.

En resumen, la rubrica es una herramienta para comparar la calidad del agente a través de pilas, no una bala de plata para todas las preocupaciones de producción.

Construyendo trayectorias comparables

Una trayectoria es el registro completo de lo que sucedió durante una ejecución: la solicitud inicial, cada llamada a la herramienta con sus argumentos y resultados, y la salida final del modelo. Almaceno cada trayectoria como un objeto JSON con un esquema fijo para que pueda diferenciar ejecuciones automáticamente. A continuación, se muestra un ejemplo del esquema que uso.

Campo | Tipo | Descripción solicitud | cadena | La solicitud exacta del usuario o del sistema enviada al modelo. llamadas | matriz | Lista ordenada de ejecuciones de herramientas. llamadas[].herramienta | cadena | Nombre de la herramienta o API. llamadas[].args | objeto | Argumentos pasados a la herramienta. llamadas[].resultado | cualquier | Salida bruta de la herramienta. salida | cadena | Texto final devuelto por el modelo. metadatos | objeto | Etiquetas opcionales como el nombre del modelo, la versión del marco, la marca de tiempo.

Dado que el esquema nunca cambia, puedo calcular las puntuaciones de los tres ejes para cada trayectoria usando los mismos scripts. Mantengo un conjunto maestro de trayectorias que cubre las tareas básicas que envío y los modos de falla comunes que he visto. Cuando cambio el modelo, vuelvo a ejecutar las mismas trayectorias y comparo las nuevas puntuaciones con la línea de base.

Ejecutando evaluaciones en cada cambio

Integro el paso de evaluación en mi pipeline de integración continua. La pipeline hace lo siguiente en cada confirmación que puede afectar el comportamiento:

- Verificar el código más reciente. - Instalar las dependencias del agente. - Ejecutar el agente contra el conjunto fijo de trayectorias. - Analizar los registros y calcular las puntuaciones de éxito de la tarea, corrección de la herramienta y fidelidad. - Publicar los resultados en un panel y marcar cualquier eje que disminuya más del cinco por ciento en comparación con la última versión verde.

Esta práctica atrapa las regresiones temprano. Por ejemplo, cuando cambié la biblioteca de recuperación subyacente, el eje de corrección de la herramienta cayó de 0,96 a 0,82 porque la nueva biblioteca devolvió resultados en un orden diferente, lo que hizo que el agente realizara llamadas extra. La caída apareció en el informe de CI antes de que cualquier usuario notara un problema.

También mantengo un conjunto de retención de veinte trayectorias puntuadas por humanos. Cada mes, puntuo esas con una persona y comparo el promedio con las puntuaciones automáticas. Si el juez automático se desvía, recalibro la rubrica o vuelvo a entrenar el modelo del juez.

Lista de verificación del operador para rubricas de evaluación de agentes que viajan a través de pilas

Mantengo una lista de verificación escrita junto a cada lanzamiento que toca este tema. La lista es aburrida a propósito: nombrar al propietario, nombrar el artefacto de evidencia y nombrar la reversión. Si un paso no puede producir un archivo, un ticket o una línea de registro, no es un paso: es un deseo.

Antes de cambiar la producción

- Congelar la rama o la revisión de configuración que se medirá. - Registrar el modo de falla actual con una entrada concreta y una salida concreta. - Confirmar qué identidad ejecuta el trabajo y si esa identidad puede acceder a datos que no debería. - Abrir las referencias principales que se citarán: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Mientras se ejecuta la verificación

- Preferir un camino reproducible sobre diez capturas de pantalla anecdóticas. - Escribir el resultado seguro esperado antes de activar la herramienta o la consulta. - Capturar el comando exacto, la solicitud, el esquema o la expresión regular bajo prueba: no una paráfrasis. - Si el sistema puede actuar (enviar, escribir, eliminar, transferir), requerir un límite de confirmación en el mismo pase.

Después de terminar

- Archivar el riesgo residual con un propietario y una fecha, incluso cuando el análisis esté limpio. - No convertir una verificación verde en lenguaje de ventas que afirme la completitud. - Volver a ejecutar la misma lista de verificación cuando el modelo, el esquema de la herramienta o las reglas de validación cambien.

Señal | Qué registrar | Detener el envío? Escribir o enviar inesperado | Nombre de la herramienta, args, identidad | Sí hasta que se bloquee Falta de confirmación en acción destructiva | Ruta de llamada y salto | Sí Texto no confiable tratado como instrucción | Superficie de origen y acción resultante | Sí para el alcance del agente Análisis de escaneo limpio, juicio abierto | Artículos diferidos + propietario | Solo si la ruta principal es segura

agenteval ayuda con el primer pase medible. Las elecciones de arquitectura, el visto bueno legal y las afirmaciones que enfrentan al cliente aún necesitan un propietario humano. Tratar cada fila de la lista de verificación como soporte de decisión, no como certificado.

Cómo explico los límites a los compradores

Cuando un prospecto pregunta si el producto "cubre todo", respondo con el límite: las verificaciones automatizadas atrapan patrones conocidos; las cadenas y el juicio de política novel todavía necesitan revisión. Esa honestidad mantiene la carga de soporte baja y mantiene el blog alineado con lo que el producto realmente hace.

Si necesitas una segunda opinión, combina este escrito con las referencias a continuación y con tu propia reproducción de escenario. No omitas el paso de reproducción solo porque un modelo escribió un resumen confiado.

Referencias

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Preguntas frecuentes

¿Cuántos casos de prueba necesitamos?

Lo suficiente para cubrir las tareas que realmente envías y las formas en que fallan. Un puñado de trayectorias bien elegidas es mejor que un gran conjunto de trayectorias fáciles.

¿Podemos juzgar salidas con otro modelo?

Puedes, pero registra que el juez es un modelo y mantén un conjunto fijo puntuado por humanos, para que puedas decir si el juez en sí se desvió.

¿Qué es la fidelidad, concretamente?

Si cada afirmación en la salida del agente se puede rastrear hasta los resultados de la herramienta o el contexto que se le dio al modelo, en lugar de producirse a partir de los propios priores del modelo.

¿Debemos puntuar solo la respuesta final?

No. Puntuar la trayectoria también: las llamadas a la herramienta son donde se originan la mayoría de las fallas del agente.

¿Con qué frecuencia deben ejecutarse las evaluaciones?

En cada cambio que pueda afectar el comportamiento: solicitud, modelo, lista de herramientas o configuración de recuperación.

¿Significa una buena puntuación que el agente es seguro?

No. Significa que se desempeñó bien en las tareas que se probaron. La seguridad, el costo y el manejo de fallas son evaluaciones separadas.

Referencias

- NIST — Marco de gestión de riesgos de IA - Stanford CRFM — HELM (Evaluación holística de modelos de lenguaje)

Prueba el producto: AgentGrade

2026-09-20 · solo fuentes primarias · no métricas de tráfico fabricadas · solo soporte de decisión

Artículos relacionados

- Evaluación fuera de línea versus monitoreo en línea para agentes de IA - Explorar la matriz de temas de micro-SaaS de IA completa →