Evaluar agentes por trayectoria, no solo por la respuesta final

El agente que acertó sin querer

Tu agente responde bien en el 92 % de los casos del golden set. Lo despliegas. A la semana, alguien nota que para contestar una consulta de facturación ha llamado cinco veces a la misma herramienta, ha leído un documento de otro cliente y ha acabado dando con la respuesta correcta por pura suerte.

La respuesta final era buena. El proceso, no. Y en un agente el proceso es el producto: cuesta dinero, toca datos y puede romper cosas por el camino.

Evaluar solo la salida funciona con un modelo que contesta una pregunta. Con un agente que decide, llama herramientas y corrige sobre la marcha, hay que mirar la trayectoria.

Qué es una trayectoria

Es la secuencia completa de pasos que da el agente desde la petición hasta la respuesta: cada razonamiento visible, cada llamada a herramienta con sus argumentos y cada resultado que recibe.

Dos agentes pueden terminar en la misma respuesta con trayectorias muy distintas:

Si tu métrica es “¿acertó?”, son idénticos. Si pagas la factura o respondes por los datos, no lo son.

Cuatro cosas que merece la pena medir

No hace falta puntuar cada paso con un juez. Con cuatro comprobaciones baratas se cubre casi todo.

1. Herramientas obligatorias. ¿Llamó a las que el caso exige? Una consulta sobre un pedido sin consultar el pedido es una alucinación con buena presencia.
2. Herramientas prohibidas. ¿Tocó algo que no debía? Aquí entran las escrituras, los borrados y cualquier lectura fuera del ámbito del usuario.
3. Presupuesto de pasos. ¿Resolvió en un número razonable de llamadas? Un tope por caso detecta bucles antes de que lo hagan tus costes.
4. Orden y dependencias. Algunas acciones solo tienen sentido tras otras: verificar identidad antes de consultar datos personales, por ejemplo.

Fíjate en que ninguna de las cuatro es subjetiva. Son aserciones sobre un registro, igual que un test unitario.

Un evaluador de trayectoria en Python

La base es registrar la trayectoria como datos y escribir las reglas como código. Un esquema mínimo:

from dataclasses import dataclass, field

@dataclass
class Paso:
    herramienta: str   # nombre de la herramienta llamada
    args: dict         # argumentos enviados
    error: bool = False

@dataclass
class Caso:
    id: str
    obligatorias: set[str]                 # deben aparecer
    prohibidas: set[str]                   # no pueden aparecer
    max_pasos: int                         # presupuesto de llamadas
    orden: list[tuple[str, str]] = field(default_factory=list)  # (antes, después)

def evaluar(caso: Caso, pasos: list[Paso]) -> list[str]:
    """Devuelve la lista de fallos; vacía si la trayectoria es válida."""
    usadas = [p.herramienta for p in pasos]
    fallos = []

    faltan = caso.obligatorias - set(usadas)
    if faltan:
        fallos.append(f"faltan herramientas: {sorted(faltan)}")

    sobran = caso.prohibidas & set(usadas)
    if sobran:
        fallos.append(f"herramientas prohibidas: {sorted(sobran)}")

    if len(pasos) > caso.max_pasos:
        fallos.append(f"{len(pasos)} pasos (tope {caso.max_pasos})")

    for antes, despues in caso.orden:
        if despues in usadas:
            # la primera aparición de 'antes' debe preceder a la de 'después'
            if antes not in usadas or usadas.index(antes) > usadas.index(despues):
                fallos.append(f"'{despues}' sin '{antes}' previo")

    return fallos

Lo importante no es el código, que es trivial, sino lo que obliga a hacer: definir antes de ejecutar qué trayectorias son aceptables para cada caso.

Cómo conseguir la trayectoria

La parte incómoda es el registro. Tres consejos prácticos:

• Registra en el arnés, no en el prompt. Pedirle al modelo que “cuente lo que ha hecho” mezcla la evaluación con la generación. Captura las llamadas reales en el bucle del agente.
• Guarda argumentos y resultados. Un nombre de herramienta no basta; saber qué pidió a una herramienta de búsqueda explica la mitad de los fallos.
• Usa los mismos trazos que en producción. Si ya tienes observabilidad con OpenTelemetry, las trazas de producción son tu mejor fuente de casos nuevos.

Lo que la trayectoria no sustituye

Evaluar el camino no reemplaza evaluar el destino. Una trayectoria impecable que acaba en una respuesta equivocada sigue siendo un fallo. Combina ambas:

• Respuesta final con tu golden set y, donde haga falta, un LLM como juez.
• Trayectoria con aserciones deterministas como las de arriba.

Y ojo con el exceso de rigidez. Si exiges una secuencia exacta de herramientas, penalizas al agente que encuentra un camino más corto y válido. Fija restricciones (qué debe pasar, qué no puede pasar, cuánto puede costar), no un guion.

Por dónde empezar

No montes un marco de evaluación. Empieza con esto, un viernes por la tarde:

1. Toma diez casos reales que ya conozcas.
2. Para cada uno, anota herramientas obligatorias, prohibidas y un tope de pasos.
3. Ejecuta el agente, registra los pasos y pasa evaluar.
4. Mira qué casos “correctos” fallan en trayectoria. Ahí está tu próxima semana de trabajo.

La respuesta correcta te dice que el agente puede acertar. La trayectoria te dice si puedes fiarte de que lo haga siempre igual.