Que el agente funcione es solo el primer paso.Autor del artículo: elune
Artículo compilado, fuente: ME News
Que el agente funcione es solo el primer paso.
Lo realmente difícil es determinar: si es estable, si es correcto, o si ha degradado silenciosamente debido a una sola instrucción o actualización del modelo.
Estos 10 métodos de evaluación son esenciales que todo ingeniero de IA debe conocer.
1. Conjunto de prueba de oro | Golden Set
Prepare a set of fixed and frozen test cases.
Después de cada modificación de las instrucciones, el modelo, las herramientas o el flujo de trabajo, vuelva a ejecutar este conjunto de casos para determinar si el sistema ha mejorado o si ha fallado silenciosamente en algunos escenarios.
Es la línea base más básica en el sistema de evaluación de Agent.
Herramienta recomendada: OpenAI Evals
Se puede utilizar para construir conjuntos de pruebas de referencia ejecutables repetidamente y comparar el rendimiento de diferentes modelos o versiones del sistema.
2. Juez LLM | LLM como juez
Utilice otro modelo de lenguaje grande para evaluar las respuestas abiertas según criterios de puntuación previamente establecidos.
Este método es especialmente efectivo cuando la tarea no tiene una respuesta única ni se puede determinar la corrección mediante coincidencia de cadenas o salida fija.
Por ejemplo, se puede hacer que el modelo evaluador determine si la respuesta es precisa, completa, relevante y si cumple con los requisitos del usuario.
Herramienta recomendada: OpenEvals
Proporciona evaluadores listos para usar para aplicaciones de LLM, para establecer rápidamente procesos de revisión automatizados.
3. Evaluación multidimensional | Rubric Scoring
No le des al agente solo una "puntuación de calidad" general.
Se deben evaluar por separado:
- Correctness
- Integridad
- Estilo de expresión
- Security
- Tiempo de respuesta
- Costo de llamada
Una puntuación compuesta puede ocultar problemas reales.
Por ejemplo, una disminución en la puntuación total podría no deberse a una respuesta incorrecta, sino a un aumento repentino en el costo de llamada a herramientas; un aumento en la puntuación total también podría basarse en una disminución de la seguridad.
Herramienta recomendada: DeepEval
Support for creating custom indicators and scoring different quality dimensions independently.
4. Evaluación de trayectoria | Trajectory Eval
No solo evalúe la respuesta final que proporciona el Agente, sino también todo el proceso que siguió para completar la tarea.
Incluye:
- ¿Se ha seleccionado la herramienta correcta?
- ¿Se están llamando las herramientas en orden adecuado?
- ¿Estás realizando una operación inválida repetidamente?
- ¿Se omitió algún paso necesario?
- ¿Se ajustan las decisiones correctamente según los resultados de la herramienta?
El agente podría terminar obteniendo la respuesta correcta, pero el proceso intermedio es ineficiente, frágil e incluso arriesgado.
Herramienta recomendada: AgentEvals
Puedes revisar las acciones, decisiones y llamadas a herramientas del agente en la trayectoria completa de ejecución.
5. Pruebas unitarias de herramientas | Tool Unit Tests
Escribe pruebas independientes para cada herramienta utilizada por el agente.
Use fixed input to verify fixed output, without involving the model.
Así se pueden separar los problemas:
¿Es un problema de razonamiento del agente, o hay un problema con las herramientas, interfaces o el servidor MCP subyacentes?
Solo tiene sentido evaluar si el agente llamó correctamente a la herramienta después de asegurar que la herramienta en sí es confiable.
Herramienta recomendada: MCP Inspector
可用于检查和测试 MCP Server、工具参数及返回结果。
6. Conjunto de pruebas de regresión | Regression Suite
Save past real execution cases and re-execute after each update to prompts, models, or toolsets.
Luego, compare los resultados de las versiones nueva y antigua, verifique:
- ¿Fracasó la tarea originalmente correcta?
- Does the output format change?
- ¿Se ha aumentado la llamada a herramientas?
- ¿Aumentaron la latencia y el costo?
- ¿Se degradan algunos casos límite?
El hecho de que la nueva versión tenga un rendimiento promedio mejor no significa que no haya roto capacidades anteriores.
Herramienta recomendada: Promptfoo
Support running reproducible evaluation suites, capturing regression issues, and integrating check processes into CI.
7. Pruebas A/B en producción | A/B Testing in Production
Asignar aleatoriamente el tráfico de usuarios reales a dos versiones diferentes para comparar su rendimiento en un entorno real.
Se puede probar:
- Dos conjuntos de indicaciones
- Dos modelos
- Dos flujos de trabajo de Agent
- Diferentes combinaciones de herramientas
- Diferentes estrategias de respuesta
La versión con puntuación offline más alta no necesariamente conlleva un mayor éxito de los usuarios.
Lo realmente importante son los resultados reales, como la tasa de finalización de tareas, la tasa de adopción de usuarios, la tasa de conversión, la tasa de transferencia a operadores humanos y la tasa de resolución de problemas.
Herramienta recomendada: GrowthBook
Proporciona funciones de activación, experimentos controlados y análisis de producto.
8. Revisión humana | Human Review
Se realizan muestras periódicas de registros de funcionamiento reales, que son evaluadas por revisores humanos.
La revisión humana no solo puede identificar problemas omitidos por la evaluación automatizada, sino que también se puede utilizar para calibrar los jueces de LLM.
Necesita revisión prioritaria:
- ¿Coinciden las puntuaciones del modelo con los juicios humanos?
- Are the evaluation criteria clear enough?
- ¿El modelo de evaluación favorece respuestas largas?
- Evaluar automáticamente si se omitieron errores graves
La evaluación automatizada no puede reemplazar completamente el juicio humano.
Herramienta recomendada: Argilla
Ayudar al equipo a recopilar retroalimentación humana, revisar la salida del modelo y consolidar los resultados en un conjunto de datos de alta calidad.
9. Shadow Run
Ejecutar la versión candidata en tráfico real, pero no mostrar su salida a los usuarios.
El entorno de producción aún utiliza la versión antigua, mientras que la nueva versión solo se ejecuta en segundo plano para comparar su rendimiento.
Este método es adecuado para actualizaciones de alto riesgo, como:
- Cambiar el modelo principal
- Reescribir el mensaje del sistema
- Conectar nuevas herramientas externas
- Modificar la lógica de decisión del Agente
- Ampliar permisos de herramientas
Shadow running helps teams identify issues in real traffic before the official release, while avoiding direct impact on users.
Herramienta recomendada: Langfuse
Rastree la ejecución de la producción, compare las versiones candidatas y monitoree los resultados de la evaluación.
10. Pruebas de equipo rojo | Red Teaming
Ataca tu propio sistema antes que el atacante.
El alcance de la prueba incluye:
- Jailbreak attack
- Prompt injection
- Fuga de datos sensibles
- Bypass de permisos
- Abuso de herramientas
- Archivos o contenido de páginas web maliciosos
- Operación externa no prevista
Las pruebas de red team son especialmente importantes para los Agentes que pueden llamar a la base de datos, enviar correos electrónicos, modificar archivos, ejecutar código o acceder a sistemas internos.
Herramienta recomendada: Garak
Puede escanear vulnerabilidades de seguridad y comportamientos inseguros en el sistema LLM.
Offline evaluation tells you: the system works normally in the testing environment.
La evaluación en línea te indica: el sistema sigue funcionando correctamente después del lanzamiento.
Actualmente, es posible que no necesites implementar las 10 mecanismos de evaluación de una sola vez.
Una aproximación más práctica es:
Revise el último fallo del Agente y priorice la implementación de los dos métodos de evaluación que podrían haber detectado el problema con anticipación.
A menudo, al establecer primero un conjunto de pruebas de oro y luego complementarlo con pruebas de regresión o inspecciones manuales, se pueden evitar numerosos errores básicos.
¡Vale la pena guardar!
