Evaluación de agentes con un bot de viajes: resultado frente a trayectoria, puertas y pass^k

Los agentes no se limitan a llamar a las APIs. Ellos razonan, eligen herramientas sobre la marcha, crean planes de múltiples pasos y abordan tareas abiertas que antes consumían horas del tiempo humano. Sin embargo, en el momento en que uno de ellos entra en producción, surge una pregunta incómoda: ¿cómo sabes que funciona?

No con la prompt de demostración favorita de hoy, sino la próxima semana, después de que alguien edite las instrucciones del sistema, agregue una herramienta, cambie el modelo subyacente o modifique la prompt. ¿Ese cambio arregló algo y rompió silenciosamente tres cosas más?

El software ordinario cuenta con pruebas unitarias deterministas, como assert add(2, 2) == 4. Los agentes son probabilísticos y pueden seguir diferentes rutas hacia el mismo objetivo, por lo que una simple comparación de cadenas en el texto final resulta insuficiente. Agent evals llena ese vacío.

La analogía del examen de matemáticas

Imagina a un profesor que califica un examen mirando únicamente el número final. Dos cosas salen mal:

1. La suposición afortunada. El método es absurdo, dos errores aritméticos se anulan entre sí, y la respuesta surge por casualidad.
2. El error en la última línea. El método es impecable y el teorema está bien comprendido, pero un error tipográfico al final escribe 41 donde debería estar 42.

Un buen profesor evalúa tanto el método como la respuesta. Los agentes merecen el mismo trato, ya que un agente genera una secuencia de pasos: llamadas a herramientas, búsquedas, objetos formateados y decisiones sobre el estado. Evaluarlo de manera justa implica medir dos cosas:

• Resultado: el resultado empresarial que logró.
• Traectoria: el camino que siguió para llegar allí.

En pocas palabras, la evaluación de un agente es la evaluación del resultado más la evaluación de la trayectoria, medida en la misma prueba mediante una combinación de verificaciones por código fijo y juicios flexibles.

Dos ejes para la calificación

Cualquier agente puede ser evaluado según dos dimensiones independientes.

¿Qué se analiza?

• Las verificaciones de resultado buscan determinar si existe el resultado final correcto, como por ejemplo el vuelo adecuado, la tarifa del hotel correcta o el registro de reserva apropiado.
• Las verificaciones de trayectoria evalúan si el agente llegó allí de manera fiable: se utilizaron herramientas en un orden lógico, se pasaron parámetros válidos y no hubo bucles infinitos.

¿Cómo se califica?

• Las verificaciones deterministas abarcan hechos con una respuesta objetiva. Un precio es de 150 dólares o no lo es, y una herramienta se utilizó o no. Las afirmaciones de código simple se encargan de esto.
• Las verificaciones basadas en el juicio abarcan todo aquello que requiere contexto, intención o matices. ¿Se interpretó “presupuesto” como “economía”? ¿El hotel elegido coincide con lo que realmente quería el usuario? Un LLM que actúa como evaluador neutral califica estos casos.

Ejemplo práctico: un agente de reservas de viajes

Tomemos un agente que se encarga de los itinerarios. La solicitud es: un vuelo económico, tres noches en un hotel en Nueva York y un traslado desde el aeropuerto. Para ello puede utilizar herramientas llamadas search_flights, search_hotels, book_flight, book_hotel y book_airport_transfer.

Métricas de trayectoria: analizan el registro de ejecución, el orden de llamadas, los argumentos de las herramientas y las huellas del razonamiento. Preguntas típicas: ¿Formó un plan antes de actuar? ¿Se realizaron las búsquedas antes de hacer las reservas? ¿Las fechas del hotel coinciden con las fechas del vuelo? ¿Evitó llamadas redundantes?

Métricas de resultados: examinan los objetos de reserva que el agente creó realmente: la tarifa, la tasa por noche, el traslado, la moneda y las fechas.

Puertas de control antes de los promedios

Una lección que suele aprenderse a costa de errores: no toda métrica debe incluirse en una sola puntuación promedio. Imagine a un agente que obtiene un 95% en general gracias a un razonamiento elegante y un orden perfecto de herramientas, pero reserva el vuelo por 1,500 dólares en lugar de 150. En la práctica real eso no constituye un desempeño de primera categoría; es un desastre en cuanto a facturación.

Para evitar que las altas puntuaciones en razonamiento oculten fallas críticas para el negocio, la evaluación puede realizarse en dos etapas.

Etapa 1: la verificación inicial. Primero se realizan comprobaciones deterministas en campos críticos: precios, fechas, moneda, identificadores de facturación y criterios para calcular tarifas. Si alguna de estas comprobaciones falla, toda la prueba fracasa de inmediato. Ningún nivel elevado de razonamiento puede anular eso.

Etapa 2: la escala ponderada. Solo las pruebas que superan todas las verificaciones iniciales obtienen una puntuación de calidad, calculada a partir de métricas restantes como la eficiencia de la herramienta, la calidad del razonamiento, el cumplimiento del plan y la correspondencia semántica. La regla es sencilla: si se supera la verificación inicial y la puntuación ponderada es igual o superior al umbral, por ejemplo 0.85, se considera aprobada la prueba.

Diagnóstico de fallas con una matriz 2x2

Un simple “82% de tasa de éxito” no le proporciona información útil para depurar. Es necesario saber por qué fallaron las ejecuciones, para poder decidir si corregir el prompt, las herramientas o el conjunto de datos. Al graficar los resultados en función de la trayectoria, aparecen cuatro cuadrantes:

• Ruta adecuada, resultado bueno: se alcanzó el objetivo.
• Ruta incorrecta, resultado bueno: fue una suposición afortunada, y existe un riesgo de que vuelva a ocurrir.
• Ruta adecuada, resultado malo: hubo un error en la etapa final, generalmente por un problema con las herramientas o los datos.
• Ruta incorrecta, resultado malo: se produjo un fallo fundamental que requiere re trabajo.

Rastreo de extremo a extremo

Así es como el pipeline manejaría una prueba del agente de reservas. Comienza con la solicitud del usuario y el rastreo del agente, que inicia con un plan (buscar vuelos, buscar hoteles, reservar ambos, añadir el traslado) y luego registra cada pensamiento y llamada a herramienta en orden.

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

A continuación, el sistema examina los campos críticos para la misión: el precio del vuelo, la tarifa del hotel por noche y el costo del traslado. Supongamos que los tres valores coinciden con los esperados, es decir, 150 dólares, 120 dólares por noche y 35 dólares. El sistema aprueba la solicitud y la prueba pasa a la Etapa 2.

En la Etapa 2, cada métrica restante recibe una puntuación entre 0 y 1 que se multiplica por su peso, siendo la suma de los pesos igual a 1. Como ejemplo, supongamos que cinco métricas tienen pesos de 0.20, 0.20, 0.15, 0.15 y 0.30, y sus puntuaciones son 1.0, 1.0, 0.8, 1.0 y 0.95 respectivamente. La suma ponderada es 0.20 + 0.20 + 0.12 + 0.15 + 0.285, lo que equivale a 0.955. Dado umbral de 0.85 establecido antes de ejecutar la prueba, se considera una aprobación.

Finalmente, el sistema registra tres hechos: la solicitud fue aprobada, la puntuación ponderada superó el umbral y la matriz de diagnóstico clasificó la ejecución en la categoría de camino correcto y resultado positivo.

Medición de la varianza con pass@k y pass^k

Un solo intento no revela toda la historia, ya que los agentes son no deterministas. Si se ejecuta el mismo prompt con las mismas herramientas diez minutos después, el modelo podría buscar hoteles primero, formatear un argumento de manera diferente o razonar siguiendo otra secuencia. Una prueba que funcionó hoy puede fallar mañana con la misma entrada.

El documento técnico de Anthropic sobre la evaluación de agentes describe dos estadísticas para controlar esa variabilidad: pass@k y pass^k.

pass@k: capacidad

Aquí la pregunta es si al menos uno de los k intentos separados tiene éxito. A medida que aumenta k, la puntuación también sube, porque más intentos incrementan las posibilidades de éxito. Esta métrica se hizo popular gracias al trabajo de OpenAI en HumanEval relacionado con la generación de código, donde un sistema crea varios programas candidatos y verifica si alguno supera las pruebas unitarias.

Se adapta a configuraciones con intervención humana y sistemas con validadores automatizados: tres itinerarios preliminares entre los que elgerente de viajes puede elegir, o cinco consultas SQL candidatas donde un motor ejecuta la primera que sea válida.

pass^k: consistencia

Se trata de la probabilidad de que el agente tenga éxito en cada una de las k intentonas, lo cual corresponde a la tasa por prueba p elevada a la potencia k. A medida que k aumenta, la calificación disminuye rápidamente. Supongamos que el agente logra pasar el 75% de las pruebas individuales:

• una prueba: 75.0%,
• tres pruebas seguidas: aproximadamente 42.2%,
• cinco pruebas seguidas: aproximadamente 23.7%,
• diez pruebas seguidas: aproximadamente 5.6%.

Esa es la referencia para un uso en producción autónomo y crítico. Cuando el agente de reservas está conectado a tarjetas de pago y APIs de proveedores, a los usuarios no les importa que pueda tener éxito una vez cada cinco intentos; necesitan que funcione de manera fiable en cada ocasión.

Por qué es importante la elección

Cuando k es igual a 1, las dos métricas son idénticas y equivalen a la tasa de éxito base. A medida que k aumenta hasta 10, ellas muestran resultados opuestos: pass@k tiende al 100%, ya que con suficientes intentos eventualmente se logrará el éxito, mientras que pass^k tiende a cero, pues es difícil realizar diez ejecuciones impecables sin ninguna alucinación ni fallo del herramienta. Elegir la métrica que se ajuste a las promesas de su producto permite diferenciar los indicadores superficiales de la verdadera fiabilidad.

Consejos prácticos

1. No pruebe solo la respuesta final. Un agente que llega a la respuesta correcta mediante razonamientos erróneos representa un riesgo en el entorno de producción.
2. Combine código y evaluadores basados en LLM. Utilice código determinista para cálculos de precios, identificadores y verificaciones de presencia, y evaluadores basados en LLM para evaluar la calidad del razonamiento, el cumplimiento del plan y la correspondencia con la intención.
3. Asegúrate de que lo esencial nunca esté mal. Un razonamiento elegante no debería permitir que un precio incorrecto, una moneda deficiente o una fecha inválida afecten el promedio.
4. Trata las evaluaciones como pruebas de integración. Ejecuta el conjunto de pruebas cada vez que cambie una instrucción o un modelo, para detectar regresiones antes de que los usuarios las descubran.

Los agentes fiables no surgen de la esperanza de que el modelo se comporte bien hoy; provienen de un sistema que verifica, día tras día, que así sea.