Cómo escribir tu primera evaluación de IA - SallyAnn DeLucia, Arize AI

원제 · How to Write Your First AI Eval - SallyAnn DeLucia, Arize AI

35:204분 읽기AI Engineer2026. 10. 25.컴퓨터/소프트웨어 · AI/미래기술

핵심 요약

La evaluación sistemática de agentes exige reemplazar las comprobaciones intuitivas por observabilidad basada en trazas y evaluadores LLM calibrados sobre un único criterio concreto.

하이라이트

  • Las pruebas unitarias tradicionales fallan con agentes de IA porque el código genera múltiples respuestas válidas y la lógica interna solo se revela a posteriori mediante trazas.

  • Un evaluador de tipo LLM como juez funciona mejor cuando analiza una sola cualidad específica a la vez.

  • El agente interno Alex comenzó con un conjunto básico de comprobaciones y actualmente ejecuta 32 evaluaciones simultáneas en producción.

  • Los modelos de decisión devuelven probabilidades directas de verdadero o falso de forma rápida y económica, pero omiten el razonamiento explicativo que aporta un LLM como juez.

  • El mapeo de variables desacopla las plantillas de evaluación de los nombres de campo exactos presentes en los registros o conjuntos de datos.

  • Una métrica convencional señala si el sistema falla, mientras que una evaluación revela el modo exacto de la falla.

타임라인

  1. Por qué las evaluaciones superan a las sensaciones y a las pruebas tradicionales

    Modificar prompts basándose en que el resultado parece correcto introduce fallos silenciosos a los pocos días sin forma de auditar el origen del error. En software clásico, una función expone su lógica directamente en código con entradas y salidas unívocas. Los sistemas de IA distribuyen su razonamiento a lo largo de múltiples pasos no deterministas, lo que vuelve indispensables las trazas completas para inspeccionar el flujo operativo.

    • Las comprobaciones intuitivas impiden detectar regresiones al modificar prompts o alternar modelos de lenguaje.
    • Las pruebas unitarias deterministas exigen una única salida correcta, algo incompatible con la diversidad de respuestas válidas de un agente.
    • Las trazas constituyen los registros de ejecución de la inteligencia artificial y sirven como requisito previo para cualquier evaluación.
  2. Taxonomía de evaluadores en desarrollo y producción

    Existen diversas categorías de evaluación según la fase del ciclo de vida del agente. Métodos como LLM como juez, modelos de decisión, aserciones en código y anotaciones con datos de referencia deben mantenerse activos tanto en desarrollo como en producción. Evaluaciones más complejas, como agentes evaluando a otros agentes o métricas de negocio y retroalimentación de usuarios, complementan las fases de despliegue continuo.

    • El método de LLM como juez califica tareas complejas y devuelve tanto una etiqueta de clasificación como una explicación detallada del razonamiento.
    • Los modelos de decisión ofrecen verificaciones binarias rápidas y económicas basadas en probabilidades sin emitir texto explicativo.
    • Las evaluaciones deterministas basadas en código resuelven validaciones rígidas como comprobaciones de formato JSON, presencia de palabras clave o métricas ROUGE y BLEU.
  3. Exploración de trazas y descomposición de spans en sistemas multiagente

    La inspección de una traza permite reconstruir la secuencia cronológica de un planificador de viajes ante solicitudes con variables de destino, presupuesto y preferencias de estilo. Dentro del árbol, el span raíz carece de identificador padre y agrupa el proceso total. Los spans anidados muestran cómo un agente de investigación invoca herramientas meteorológicas y pasa los datos crudos a llamadas secundarias de LLM para sintetizar la respuesta final.

    • Un span raíz representa el punto de entrada y salida final del flujo completo de interacción con el usuario.
    • Los spans hijos dividen la ejecución del sistema en unidades de trabajo discretas como llamadas a herramientas, agentes especializados o consultas a LLMs.
    • La instrumentación del sistema permite personalizar qué atributos y metadatos se capturan a lo largo del árbol de ejecución.
  4. Diseño de criterios de evaluación concretos e iterativos

    Establecer reglas operativas claras evita inconsistencias en las sentencias de los evaluadores automatizados. En un planificador de viajes, un criterio concreto comprueba que el itinerario respete exactamente los días solicitados y mantenga la suma de gastos dentro del presupuesto indicado. Las plantillas de criterios estructuran el prompt del evaluador enumerando al menos tres condiciones explícitas de aprobación y tres escenarios típicos de reprobación.

    • Los criterios de éxito exigen reglas medibles específicas en lugar de objetivos vagos como ofrecer una respuesta útil.
    • Limitar cada evaluación a una sola cualidad maximiza la precisión y coherencia del veredicto del evaluador.
    • La definición del evaluador requiere describir la tarea, la condición de éxito, el modo de fallo y listas detalladas de verificación para aprobado o desaprobado.
  5. Construcción y calibración del evaluador en entorno de pruebas

    La creación de un evaluador funcional comienza aislando spans en la plataforma mediante filtros como identificadores nulos para spans raíz o nombres específicos de herramientas. Al trasladar el conjunto de datos al entorno de pruebas de prompts, se redacta una directiva que asigna el rol evaluador al modelo y se vinculan las variables de entrada y salida. Ejecutar pruebas con modelos compactos como GPT-4o-mini permite inspeccionar la etiqueta y su justificación antes de almacenar el juez para su uso global.

    • El filtrado de trazas por tipo de span permite crear conjuntos de datos específicos para validar componentes aislados como herramientas o salidas completas.
    • El mapeo de variables conecta los atributos de las trazas con los nombres de variables definidos en el prompt de evaluación.
    • El evaluador puede configurarse con etiquetas binarias, clasificaciones multietiqueta y parámetros de dirección de optimización.
  6. Alineación continua y ciclo de vida de la evaluación

    El ciclo de mantenimiento de agentes se sostiene integrando la evaluación en pipelines automatizados de ejecución continua. Empezar con una muestra acotada de unas 20 trazas y un único criterio facilita ajustar las instrucciones a partir de las explicaciones generadas. Mientras las métricas tradicionales solo alertan sobre anomalías globales, las evaluaciones continuas exponen los modos concretos de fallo operativo para cada componente del sistema.

    • La alineación de evaluaciones compara los veredictos automáticos del juez contra anotaciones de retroalimentación humana.
    • Las evaluaciones en línea auditan automáticamente cada traza entrante en producción conforme el agente opera.
    • Equipos multidisciplinarios que abarcan producto, ingeniería, soporte y seguridad deben definir conjuntamente los criterios de éxito del agente.

설명

A hands-on workshop from SallyAnn DeLucia, head of product at Arize AI, on moving from vibe checks to real evals. She covers what an eval is and how it differs from a unit test, the main types (LLM as a judge, decision models, code evals, annotations, agent as a judge), how to read a trace, how to write concrete pass/fail criteria, and how to build and iterate on an LLM judge in Arize's prompt playground. Chapters 00:00 Intro and agenda 02:06 Why vibe checks don't scale 03:08 Is an eval just a unit test? 04:13 Why agents make evals harder 05:15 Types of evals 07:29 Workshop setup 10:16 Exploring the travel agent's traces 14:20 How to read a trace 19:03 Defining what good means 22:02 Writing pass/fail criteria 25:19 Building a dataset from traces 26:53 Building and testing an LLM judge 32:08 Next steps: alignment, online evals, Signal SallyAnn DeLucia, Arize AI Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

이 영상에 대해 글쓰기