Evaluaciones de agentes de Google ya disponibles; sus puntuaciones offline y en directo requieren versionado
Google ahora conecta las pruebas de agentes con los monitores de producción. Descubra qué versiones, muestras, evaluadores, trazas, costes y controles deben seguir visibles antes de comparar puntuaciones.
Google ha hecho que Agent and Model Evaluations de Gemini Enterprise Agent Platform estén disponibles de forma general. Los equipos ahora pueden reutilizar métricas registradas entre experimentos offline y monitores online, inspeccionar las trazas detrás de los fallos, generar casos sintéticos, simular usuarios y entornos de herramientas y vigilar si las puntuaciones de producción muestreadas sufren deriva.
Ese motor compartido elimina gran parte de la infraestructura de evaluación. No hace que dos puntuaciones sean comparables por sí solo. Una suite offline y el tráfico en directo pueden utilizar una métrica con el mismo nombre mientras prueban revisiones distintas del agente, poblaciones de casos, campos de traza, modelos evaluadores o reglas de muestreo. Una gráfica descendente puede reflejar el producto, el evaluador o la mezcla de tráfico.
Qué ha puesto Google a disposición general
El anuncio de Google del 31 de julio describe más de 20 métricas preconstruidas que cubren el éxito de las tareas, el uso de herramientas, la calidad de la trayectoria, el grounding, la seguridad y tareas lingüísticas basadas en referencias. Los equipos también pueden registrar métricas de Python y evaluadores personalizados basados en modelos lingüísticos grandes. Los experimentos del lado del servidor conservan artefactos en Cloud Storage, mientras que los monitores online pueden puntuar las trazas de producción recopiladas y enviar alertas de deriva.
La documentación actual de evaluación de agentes, actualizada el 26 de agosto, divide el proceso en casos, inferencia, trazas, puntuación, análisis y optimización. Admite tanto el desarrollo local como la evaluación de agentes desplegados. Ese ciclo de vida es más amplio que un benchmark de modelos porque la traza puede incluir la selección de herramientas, los argumentos, eventos intermedios y el estado de varios turnos, en lugar de solo la respuesta final.
Un límite de interfaz sigue siendo fácil de pasar por alto. La guía de GenAI Client de Google todavía etiqueta como Preview la interfaz recomendada y la somete a las condiciones de pre-GA. La descripción general del servicio etiqueta como GA el módulo antiguo vertexai.evaluation.EvalTask y lo mantiene por compatibilidad, pero dice que no admite métodos más recientes como las rúbricas adaptativas. El servicio de evaluación puede estar en GA mientras el cliente exacto que adopte un equipo no lo esté.
La guía independiente de implementación de AgentPedia llega a la misma conclusión operativa: fije la versión del SDK y oculte las llamadas que dependen de Preview detrás de un adaptador reemplazable. Una decisión de lanzamiento debe registrar el estado del ciclo de vida de la interfaz que realmente se utiliza, no heredar el estado más amplio de un titular de lanzamiento.
Una puntuación comparable necesita un paquete de medición versionado
La documentación del registro de métricas de Google dice que las definiciones registradas pueden aplicarse de forma coherente a evaluaciones offline y monitores continuos. Ese es el centro estable del ciclo. La medición que lo rodea sigue necesitando su propio registro.
| Componente de medición | Registre en el límite entre offline y producción |
|---|---|
| Sistema bajo prueba | Fije offline las revisiones del agente, el modelo, las instrucciones, el corpus de recuperación y los esquemas de herramientas. Registre online la revisión exacta desplegada y la asignación de tráfico. Un cambio del sistema puede mover la puntuación aunque la métrica no cambie. |
| Casos | Nombre la revisión del conjunto de datos offline, si es de reserva, el origen del escenario y los resultados esperados. Para producción, registre el filtro de trazas, la cohorte, el idioma, la ruta de herramientas, la región y la ventana temporal. Una suite fija y una población de usuarios cambiante responden preguntas distintas. |
| Métrica | Utilice el mismo recurso del registro y la misma revisión de definición en ambos lugares. Los criterios editados pueden parecer una deriva del producto. |
| Evaluador | Fije el ID del modelo evaluador, los parámetros, la revisión del prompt o la rúbrica y la política de reintentos durante la ventana de comparación. Una actualización del evaluador puede cambiar los veredictos sin que cambie el agente. |
| Evidencia | Defina los eventos de traza necesarios, las reglas de redacción, la política para campos ausentes y la ubicación de los artefactos. Confirme que producción expone los mismos campos observables; un evaluador no puede calificar una acción de herramienta que la traza en directo haya omitido. |
| Muestreo y resumen | Registre las repeticiones offline, las semillas, las reglas de ejecuciones no válidas, los segmentos y el estadístico. Combínelos con el porcentaje de muestreo en directo, el máximo de muestras, el calendario, las trazas no válidas, los segmentos y el estadístico. Una media muestreada puede cambiar porque cambió el volumen o la composición. |
Esta tabla es una recomendación de publicación, no una afirmación de que Agent Platform capture automáticamente todos los campos. El registro de Google proporciona recursos métricos reutilizables. El equipo sigue siendo responsable de conectar esos recursos con revisiones inmutables de la aplicación, los datos, la telemetría y el análisis.
Un identificador práctico puede ser un hash de ese paquete, en lugar de una etiqueta escrita a mano como quality-v3. Guarde a su lado los campos legibles. Cuando cambien el modelo evaluador o la rúbrica, puntúe un conjunto de calibración compartido y una muestra reciente de trazas de producción con ambas versiones. Una las series en la gráfica solo si el solapamiento muestra que se entiende el cambio de puntuación; de lo contrario, empiece una serie nueva y anote el cambio.
Las rúbricas adaptativas mejoran el ajuste, pero añaden otro artefacto generado
Una rúbrica adaptativa pide a un modelo evaluador que cree criterios de aprobado/suspenso específicos del caso a partir del caso de evaluación, la instrucción del desarrollador y las declaraciones de herramientas, y que después califique la traza resultante. Para un agente de reembolsos, un caso podría exigir comprobar el estado del envío antes de cancelar, hacer como máximo una mutación e informar del resultado real de la herramienta. Una puntuación genérica de “utilidad” pasaría por alto esos límites de estado y autorización.
La especificidad adicional solo sirve si se inspeccionan los criterios generados. Una rúbrica puede exigir un comportamiento que la tarea nunca pidió, premiar una explicación prolija por encima de un resultado correcto de la herramienta u omitir un invariante de autorización crítico. Trate el grupo de rúbricas generado como parte de la evidencia: póngale una versión, tome muestras para revisión humana y pruebe si el evaluador distingue entre casos conocidos de aprobado, suspenso y ambiguos.
La investigación anterior al lanzamiento de Google muestra por qué importa la calibración. El estudio revisado por pares sobre MT-Bench y Chatbot Arena descubrió que evaluadores potentes basados en modelos lingüísticos podían aproximar las preferencias humanas en su contexto de asistentes de chat, pero también documentó sesgos de posición, verbosidad, autoafirmación y razonamiento. Esos resultados no miden los evaluadores gestionados actuales de Google. Establecen el punto más limitado de que el acuerdo debe probarse para el evaluador, la tarea, las etiquetas y las condiciones que el equipo realmente utiliza.
Use comprobaciones programáticas siempre que la propiedad esperada sea exacta: nombres de herramientas permitidos, campos JSON obligatorios, totales aritméticos, límites de permisos, estado de una transacción o un efecto secundario prohibido. Use un evaluador basado en un modelo lingüístico para las propiedades semánticas que necesiten interpretación. Ninguna de las dos puntuaciones debe anular un invariante de seguridad determinista fallido.
Nuestro explicador general de evaluación de IA cubre la regla más amplia de que una métrica da forma a la decisión de producto. El análisis de HarnessRisk (en español) amplía el alcance a la configuración, la instalación de capacidades, el estado persistente, el control de acciones y la recuperación: áreas que una puntuación de calidad de respuesta no puede certificar.
La simulación amplía la cobertura; producción aporta otra distribución
Agent Platform puede generar casos, simular usuarios de varios turnos e interceptar llamadas a herramientas con datos, errores o latencia controlados. Esas funciones facilitan probar rutas infrecuentes y peligrosas sin romper un backend real. Pueden mostrar que un agente gestiona un tiempo de espera sintético, una denegación de permisos o un resultado mal formado en condiciones definidas.
Un simulador no establece la prevalencia de esos fallos en producción, la fidelidad de los efectos secundarios de un servicio real ni el comportamiento de los usuarios que el simulador no representó. Los casos generados también pueden repetir supuestos de la instrucción del agente y del esquema de herramientas utilizados para crearlos. Mantenga separados los casos sintéticos, los casos de reserva escritos por personas y los casos derivados de producción, en lugar de mezclarlos en una única tasa de aprobados.
La documentación de monitorización online de Google permite a los operadores filtrar trazas, establecer un porcentaje de muestreo y limitar el número de muestras por ejecución. Eso controla el coste, pero convierte la regla de muestreo en parte del resultado. Un monitor restringido a trazas lentas, largas o con muchos tokens sirve para el diagnóstico; su puntuación no estima todo el tráfico a menos que el análisis tenga en cuenta esa selección.
El puente más limpio es una comparación en sombra. Antes del lanzamiento, ejecute la versión candidata en la suite de reserva. Después del lanzamiento, envíe una pequeña muestra revisada de trazas elegibles mediante el mismo paquete de métricas y conserve una línea base aleatoria. Si cambia la puntuación en directo, desglósela por revisión del agente, ruta de herramientas, idioma, cohorte y completitud de la traza antes de llamarlo deriva del producto.
El coste, la telemetría y los controles de seguridad forman parte del resultado
Dos páginas actuales de Google discrepan sobre los cargos de las métricas de computación. La publicación de lanzamiento dice que las métricas basadas en código y en computación no añaden ningún coste. La página específica de precios de Agent Platform enumera cargos por caracteres para las métricas de computación y factura por separado las métricas basadas en modelos mediante el autorater subyacente. Trate la página de precios y la cuenta de facturación como autoridades para elaborar el presupuesto, y feche las tarifas utilizadas en cualquier cálculo del coste por traza evaluada.
El anuncio también dice que los conjuntos de datos y las trazas permanecen en el proyecto del cliente. Esa afirmación no debe ampliarse hasta convertirla en una garantía de que todos los controles deseados están disponibles. La tabla actual de soporte de seguridad empresarial de Google marca la evaluación de agentes como compatible con HIPAA, pero enumera VPC Service Controls, claves de cifrado gestionadas por el cliente, residencia de datos en reposo, Access Transparency y Access Approval como no compatibles con ese servicio. El soporte del producto puede cambiar, así que verifique la tabla, la región, el modelo objetivo, la ruta de Cloud Trace y la configuración de Cloud Storage para el despliegue exacto.
Las trazas de evaluación pueden contener prompts, respuestas, definiciones de herramientas, argumentos, identificadores de sesión y ejemplos de fallos. Por tanto, un monitor de producción necesita una lista de campos permitidos revisada, redacción antes de exportar, reglas de acceso y conservación, comportamiento de borrado y una política explícita para datos regulados o sujetos a contrato. Un porcentaje de muestreo mayor no es automáticamente mejor si copia más contenido sensible a una ruta de evidencia menos controlada.
Una misma familia de productos no hace idénticas las puntuaciones offline y en directo
El lanzamiento GA de Google facilita operar conjuntamente experimentos, trazas, métricas reutilizables y monitores online. El beneficio creíble es la continuidad de la evidencia, no la continuidad del nombre de una métrica.
Una puntuación en directo sigue dependiendo de qué trazas se muestrearon, qué campos sobrevivieron al registro y la redacción, qué versión del evaluador y de la rúbrica se ejecutó y si los usuarios de producción se parecen a los casos offline. Cuando cambia cualquiera de esos elementos, el número puede moverse aunque el agente no cambie, o mantenerse estable mientras empeora un segmento importante de fallos.
El producto cierra una brecha operativa. No elimina el trabajo analítico necesario para decidir si un cambio observado pertenece al agente, al evaluador o al tráfico.
Fuentes
- Google announcement: Agent and Model Evaluations are generally available
- Google Cloud agent evaluation overview
- Google Cloud metric registry documentation
- Google Cloud continuous online evaluation documentation
- Google Cloud GenAI Client agent evaluation documentation
- Google Cloud Gen AI evaluation service overview
- Gemini Enterprise Agent Platform pricing
- Google Cloud Agent Platform enterprise security support table
- AgentPedia independent implementation guide to Gemini agent evaluations
- NeurIPS paper: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena