Google Discovery Bench cambia la evaluación de agentes: mide cuándo la consulta se vuelve demasiado ambigua
Google Cloud presentó en julio un enfoque para evaluar agentes de recuperación con consultas de ambigüedad calibrada. Discovery Bench y su bucle iSQR buscan mostrar dónde cae un agente, no solo si aprobó un benchmark.

Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Un benchmark que solo responde “aprobó” o “falló” puede ocultar el problema que más importa en producción: qué tan imprecisa puede ser una pregunta antes de que el agente elija el dataset equivocado. En un artículo del 10 de julio de 2026, el equipo Frontier AI de Google Cloud propuso medir ese borde con Discovery Bench, un meta-benchmark para agentes de recuperación.
La idea no es coronar otro modelo con una cifra única. Es construir un mapa de capacidad. El enfoque genera variantes de una misma consulta con distintos niveles de ambigüedad y observa cuándo el agente deja de encontrar la fuente correcta. Para quien construye agentes sobre bases de datos, catálogos o repositorios documentales, ese cambio de pregunta es más útil que celebrar un promedio estable.
De la nota final al terreno de fallos
Google llama iSQR al bucle de refinamiento iterativo basado en surprisal. En términos sencillos, el método estima cuánta incertidumbre queda sobre el dataset correcto y añade o retira términos informativos para fabricar consultas más fáciles o más difíciles. La misma tarea puede pasar de una frase que apunta a una tabla concreta a otra que coincide con muchas tablas parecidas.
El artículo muestra una prueba con un agente de recuperación basado en Gemini 3.1 Pro sobre KramaBench. En esa corrida, el F1 fue 0.34 con alta ambigüedad, 0.76 en una formulación neutral, 0.81 con ambigüedad media y 0.78 con baja ambigüedad. Esos números no son una tabla universal de modelos: son evidencia de que la dificultad no siempre aumenta o disminuye de forma lineal cuando agregas más contexto.

El valor práctico está en la caída. Un benchmark fijo puede probar justo la redacción que el agente ya aprendió a resolver y dibujar un terreno plano. Una batería con consultas calibradas puede revelar que una palabra de dominio, una partición temporal o el nombre de una métrica son el punto que separa una recuperación precisa de una explosión de contexto.
Cómo convertirlo en una prueba de tu agente
No necesitas esperar a que exista una implementación perfecta de Discovery Bench para adoptar la lógica. Toma una tarea real y construye tres versiones:
- Vaga: usa el lenguaje que emplearía una persona que conoce el negocio, pero no el esquema.
- Intermedia: conserva una pista distintiva y el periodo de interés.
- Específica: nombra la tabla, el identificador o la métrica cuando el usuario realmente los tendría disponibles.
Registra para cada variante si el agente eligió el dataset correcto, cuántas herramientas llamó, cuántos tokens de contexto reunió, cuánto tardó y qué parte del trayecto falló. Si existe código de referencia, evalúa también los pasos intermedios y no solo la respuesta final. KramaBench es una referencia útil porque sus tareas de ciencia de datos piden construir un pipeline completo y pueden revisar la corrección de pasos intermedios, no únicamente el resultado narrado.

Qué no debes concluir demasiado rápido
Una consulta más específica no siempre es mejor. Puede esconder si el agente sabe descubrir el esquema y puede generar dependencia de nombres que el usuario final nunca tendrá. Además, calibrar dificultad exige una verdad de referencia limpia: si el dataset correcto o las etiquetas están mal, el mapa de fallos mide el benchmark y no al agente.
También hay un costo operativo. Variantes adicionales significan más llamadas, más tokens y más revisión humana. El objetivo no es crear una prueba interminable, sino encontrar los bordes que cambian una decisión: cuándo pedir aclaración, cuándo limitar el número de resultados, cuándo dividir una búsqueda y cuándo detenerse antes de llenar el contexto con tablas irrelevantes.
La búsqueda Discovery Bench agentes, evaluar agentes de recuperación y ambigüedad en benchmarks IA tiene intención de evaluación y diseño de sistemas; la demanda se infiere del artículo técnico de Google Cloud, el repositorio KramaBench y la conversación creciente sobre contexto verificable —puedes seguir ese hilo en la nota sobre grounding con búsqueda web paralela—, no de volumen SEO inventado. Para aprender a diseñar el loop completo de herramientas, memoria y verificación, puedes continuar con el curso gratis.