Evaluaciones de Agentes en Agent Platform ya son GA Rúbricas Adaptativas y Monitores en Vivo 🚀

¡Hola Devs! Evaluar un agente no es como evaluar un modelo

Puedes benchmarkear un modelo en un dataset estático y ya. Con un agente, olvídalo. Su calidad depende de las herramientas que llama, del flujo multi-turno que produce y de las entradas raras que manda el usuario real — nada de eso existe en tiempo de entrenamiento.

El equipo de Agent Platform en Google Cloud acaba de liberar Agent and Model Evaluations en GA, y el enfoque es honesto: un agente que pasa verde en todo tu suite todavía puede hacer drift una semana después del lanzamiento. Eso no es una falla de testing — es la realidad de producción, donde las tareas son más grandes y más extrañas que cualquier caso que hayas escrito.

En este post destripamos qué salió, cómo encajan las piezas y dónde están las aristas. Si te gusta este tipo de análisis de sistemas a escala, checa también nuestro texto sobre migración de sistemas de ingesta de datos a escala de petabytes en Meta.

El primitivo central: experimentos, métricas y traces

La unidad de trabajo es el experimento: un dataset de eval cases más un conjunto de métricas y scores que corres y revisas mientras iteras.

Tres cosas lo hacen usable en la práctica:

1. Mismo motor, offline y online. Las métricas que defines localmente corren sin cambios en los monitores de producción. Ese es el punto — si el score cambia en prod, el problema es el agente, no la medición.
2. Artefactos transparentes. Cada artefacto de experimento cae en Cloud Storage, así que puedes versionar y auditar runs para compliance.
3. Accesible desde donde ya construyes. SDK, agents-cli, consola de Cloud, ADK y hasta una skill reutilizable para agentes estilo Claude Code.

Trayendo tu propia métrica

Además de las 20+ métricas pre-hechas (ROUGE, BLEU, MetricX, COMET, exact match), defines las tuyas:

• Métrica code-based — una función Python pura. Match exacto de texto, chequeo de shape de JSON, lo que puedas expresar.
• Métrica LLM-as-a-judge — tus criterios, tu escala, tu modelo juez. Localmente usas cualquier provider; server-side acepta cualquier modelo de Model Garden, incluyendo Gemini y Anthropic.

# Ejemplo: métrica code-based que verifica cumplimiento de shape JSON
import json

def json_shape_metric(response: str, expected_keys: list[str]) -> float:
    """Devuelve 1.0 si la respuesta es JSON válido con todas las claves esperadas."""
    try:
        data = json.loads(response)
    except json.JSONDecodeError:
        return 0.0
    faltantes = [k for k in expected_keys if k not in data]
    return 1.0 if not faltantes else 0.0

Rúbricas adaptativas (la parte interesante)

Co-desarrolladas con investigadores de Google DeepMind, las rúbricas adaptativas generan tests pass/fail específicos por caso a partir de tres entradas:

• la definición del eval case,
• la instrucción del desarrollador,
• las declaraciones de las herramientas.

Luego califica los traces contra esas rúbricas y devuelve veredicto + rationale por rúbrica. Puedes dirigir la generación con guidelines en lenguaje natural, y el grupo de rúbricas resultante es revisable y reutilizable entre agentes.

De fábrica traes variantes calibradas para lo que normalmente quieres saber: Task Success, Tool Use Quality, Safety (hate speech, acoso, contenido peligroso, material explícito, PII), Trajectory Quality, Final Response Quality, Hallucination y Grounding.

Lo que falta (y dónde te va a doler)

Unos avisos honestos antes de tirar tu harness casero de eval:

Dos cosas que van a sorprender a quien migra de un setup casero:

1. Issue clustering es la feature escondida. En vez de encarar 4.000 evals fallidos, el sistema los agrupa en clusters interpretables según tu taxonomía — o una taxonomía lista de rúbricas adaptativas si todavía no tienes una. Es la diferencia entre "tenemos evals" y "actuamos con base en las evals".
2. El environment simulator es la pieza que faltaba para testear agentes. Apúntalo a una herramienta, dile que devuelva dato mockeado, error forzado o latencia extra, y él intercepta la llamada durante la run. Ahí por fin testeas cómo se comporta el agente cuando el backend está lento o roto — sin tocar producción.

Si te gusta este tipo de diseño de sistemas que fallan seguro bajo carga, checa también nuestro texto sobre cómo la protección avanzada de navegación de Messenger funciona sin comprometer la privacidad.

La conclusión

Las evaluaciones en Agent Platform ya están en GA, y las decisiones de diseño revelan una tesis clara:

• Consistencia le gana a sofisticación. Un solo motor para experimentos locales y tráfico real significa que el drift en producción apunta al agente, no a la medición.
• Trae todo a tu manera. Métricas de código, de LLM-judge, modelos jueces de cualquier provider, taxonomías — todo cae en el mismo registry versionado de la org.
• Genera, no escribas a mano. Case generators, user simulators y environment simulators existen porque un suite escrito a mano limita tu cobertura a lo que se te ocurrió teclear.

Próximos pasos

1. Si usas ADK, conecta los eval sets en pytest y corre en CI hoy — es el punto de entrada con menor fricción.
2. Si ya colectas traces vía Cloud Trace, dale click al botón de eval en la UI de traces en una sesión real y mira qué dicen las métricas por defecto.
3. Levanta un monitor online con sampling al 5–10% del tráfico y alertas de drift a Slack antes de escalarlo.

Fuente: Agent and Model Evaluations in Gemini Enterprise Agent Platform are now GA