Resumen Técnico: PluginEval

Declaración del Problema

A medida que los Modelos de Lenguaje de Gran Escala (LLMs) funcionan cada vez más como agentes autónomos, la evaluación fiable del enrutamiento de herramientas (llamada a funciones) se vuelve crítica. Los benchmarks actuales sufren tres limitaciones estructurales:

1. Sesgo de Distribución de Datos: Las distribuciones de ley de potencia dejan subrepresentados los escenarios poco comunes y los casos de borde.
2. Falta de Rigor Adversario: La ausencia de negativos difíciles oculta las diferencias de rendimiento entre modelos.
3. Pipelines de Anotación no Validados: Muchos benchmarks dependen de juicios de LLMs para la anotación que no han sido validados mediante la ejecución real, lo que conduce a posibles errores semánticos a pesar de la corrección estructural.

Además, los benchmarks existentes suelen centrarse en tasas de éxito agregadas o en la sintaxis de la llamada, fallando al diagnosticar modos de fallo específicos como llamadas a herramientas omitidas, llamadas espurias o errores de fundamentación de parámetros (grounding). Existe una necesidad específica de un benchmark que combine una anotación fiable, basada en la ejecución, con una cobertura estructurada de los límites de activación y exclusión, particularmente para consultas en chino que suelen ser ambiguas o dependientes del contexto.

Metodología: El Marco de Construcción de Bucle Cerrado PluginEval (PCCF)

El artículo presenta PluginEval, un benchmark construido mediante un marco de bucle cerrado de dos etapas (PCCF) diseñado para separar la fiabilidad de la anotación de los requisitos de cobertura.

Formulación de la Tarea

El enrutamiento de herramientas se formula como una jerarquía de tres decisiones:

1. Necesidad ($f_1$): ¿Es necesaria una herramienta?
2. Relevancia ($f_2$): ¿Es relevante el plugin objetivo?
3. Invocación ($f_3$): ¿Puede la solicitud fundamentarse en una invocación válida con argumentos correctos, o debe ser rechazada?

Etapa I: Anotación de Conjunto Basada en la Ejecución

Esta etapa se centra en establecer anotaciones fiables tanto para consultas reales como sintéticas.

• Generación: Múltiples generadores proponen de forma independiente invocaciones completas.
• Verificación: Las propuestas se someten a un proceso de verificación de múltiples pasos:
  • Validación Determinista de Esquema: Comprueba la validez estructural.
  • Evaluación de Argumentos: Un evaluador LLM comprueba si los argumentos están respaldados por la consulta y son consistentes con la semántica del plugin.
  • Ejecución: Las propuestas se ejecutan mediante MCP (Protocolo de Contexto de Modelo).
  • Evaluación de Resultados: Un evaluador separado comprueba si la respuesta de la ejecución satisface la solicitud del usuario.
• Bucle de Refinamiento: Las propuestas que fallan la verificación (debido a violaciones de esquema, errores de ejecución o desajustes semánticos) se conservan como trazas. Estas trazas, junto con las puntuaciones de los evaluadores independientes, se retroalimentan a los generadores para su refinamiento. Este proceso se repite durante un máximo de $R_{max}$ rondas hasta que una propuesta cumple con un umbral de confianza $\tau$ o es rechazada como una abstención justificada.

Etapa II: Síntesis Basada en Escenarios y Calibración de Comportamiento

Esta etapa aborda las brechas de cobertura y la calibración de dificultad.

• Descomposición de Escenarios: Los plugins se descomponen en escenarios de activación (solicitudes soportadas) y escenarios de exclusión (solicitudes que requieren ninguna herramienta, otras herramientas o que exceden las capacidades).
• Síntesis Dirigida: El sistema identifica unidades subcubiertas (combinaciones de capacidad, intención y límite) y sintetiza nuevas consultas para llenar estos vacíos.
• Calibración de Dificultad:
  • Ejemplos Positivos: La dificultad se basa en la profundidad de inferencia (0, 1 o $\ge$2 pasos).
  • Ejemplos Negativos: La dificultad se calibra basándose en la evidencia conductual. Un enrutador de referencia congelado evalúa el negativo sintetizado $K$ veces. Si el enrutador falla consistentemente al rechazar el negativo (tasa alta de falsos positivos), el ejemplo se considera "Difícil". Si es fácilmente rechazado, es "Fácil".
• Bucle Cerrado: Los ejemplos sintetizados se devuelven a la Etapa I para su verificación. El bucle continúa hasta que se cumplen los presupuestos de cobertura o se alcanza un plateau de mejora.

Marco de Evaluación: Juez Anclado en Oro (Gold-Anchored Judge)

Para ir más allá de la precisión agregada, el artículo emplea un Juez LLM Anclado en Oro:

• Entrada: Llamadas predichas, llamadas de oro verificadas por humanos y la consulta del usuario.
• Restricción: El juez trata la lista de llamadas de oro como el único ancla. No puede extender ni sobrescribir las especificaciones de oro.
• Verificación Jerárquica:
  1. Alineación de Herramientas: Coincidencia de nombres de herramientas entre la predicción y el oro.
  2. Filtrado de Argumentos: Asegura conjuntos de argumentos no vacíos y comparables.
  3. Verificación Semántica: Determina si los argumentos predichos son semánticamente equivalentes a los argumentos de oro bajo la intención de la consulta (permitiendo alias y variaciones de formato pero evaluando estrictamente los ámbitos temporales).
• Atribución de Errores: Los fallos se clasifican en categorías mutuamente excluyentes:
  • Miss Recall (Olvido de Recuperación): Omisión de herramientas requeridas.
  • Error de Parámetro: Argumentos semánticamente incorrectos (subclasificados en errores temporales, argumentos faltantes, valores incorrectos).
  • Over Recall (Sobre-Recuperación): Activación espuria de herramientas en consultas negativas.

Contribuciones Clave

1. Benchmark PluginEval: Un benchmark de llamada a funciones en chino con 3,000 instancias verificadas por humanos que cubren 54 plugins, 63 herramientas y 9 dominios. Presenta escenarios de activación/exclusión explícitos, tres tipos de negativos de frontera y dificultad calibrada conductualmente.
2. Marco PCCF: Un método de construcción de bucle cerrado que desacopla la fiabilidad de la anotación (vía verificación basada en ejecución) de los requisitos de cobertura (vía síntesis de escenarios). Utiliza validación de esquemas, evaluación independiente y ejecución de herramientas para reparar anotaciones.
3. Atribución de Errores de Grano Fino: Un marco de evaluación que atribuye los fallos a causas específicas (olvido de recuperación, errores de parámetro, sobre-recuperación) en lugar de depender de métricas de éxito agregadas.
4. Análisis Empírico: Evaluación de cinco modelos de frontera (incluyendo modelos propietarios y de pesos abiertos) que revela que los puntajes agregados son altamente sensibles a la composición de la dificultad y que los modelos exhiben perfiles de fallo distintos.

Resultados

El artículo evalúa cinco modelos: GPT-5.4, Claude 4.6, Gemini 3.1 Pro, DeepSeek-V4-Pro y Qwen3-235B-A22B.

• Sensibilidad del Rendimiento: El rendimiento agregado depende altamente de la distribución de dificultad. En la distribución original (40% Fácil, 40% Medio, 20% Difícil), Claude Opus 4.6 logró el mejor rendimiento (67.60% de Recall, 68.17% de Precisión). Sin embargo, el rendimiento cae significativamente en instancias Difíciles (el Recall cae al 2.8%–10.8% entre los modelos).
• Impacto de la Dificultad: Cambiar la distribución para que esté ponderada hacia lo Fácil (60% Fácil) mejoró sustancialmente todos los modelos (el Recall aumentó en ~15–21 puntos), demostrando que los benchmarks actuales pueden sobreestimar las capacidades si no se calibran rigurosamente.
• Comparación con Benchmarks Existentes: Los modelos generalmente funcionaron peor en PluginEval que en BFCL, APIBench o NexusRaven. Por ejemplo, el Recall de Claude Opus 4.6 cayó del 73.04% en BFCL al 67.60% en PluginEval. Esto sugiere que PluginEval captura escenarios más desafiantes, realistas y adversarios.
• Perfiles de Error:
  • GPT-5.4: Exhibió el mayor Miss Recall (33.72%) y el mayor Over Recall (33.20%), indicando una dificultad sustancial tanto para identificar las herramientas requeridas como para evitar llamadas innecesarias.
  • Claude Opus 4.6: Tuvo el Miss Recall más bajo (13.95%) pero un alto índice de Over Recall (29.10%), que sigue siendo superior al de Gemini pero inferior al de GPT-5.4.
  • Gemini 3.1 Pro: Logró el Over Recall más bajo (18.55%), contribuyendo a una precisión competitiva a pesar de un menor recall.
  • Errores Temporales: En todos los modelos, los errores de fundamentación temporal fueron el subtipo de error de parámetro más frecuente, indicando una debilidad compartida en el manejo de restricciones basadas en el tiempo.
• Fiabilidad: Auditorías humanas confirmaron una alta concordancia (Fleiss' $\kappa$ hasta 0.9451) en las anotaciones de referencia y las atribuciones del juez, validando la fiabilidad del benchmark.

Significado y Reivindicaciones

El artículo afirma que PluginEval aborda la brecha crítica en la evaluación diagnóstica para el enrutamiento de herramientas. Al ir más allá de las tasas de éxito agregadas, revela que:

1. Los puntajes agregados ocultan distintos modos de fallo: Los modelos con puntajes generales similares pueden fallar por razones completamente diferentes (ej. selección de herramienta vs. fundamentación de parámetros).
2. La composición de la dificultad importa: Los rankings de rendimiento pueden cambiar según la proporción de ejemplos fáciles a difíciles, lo que requiere etiquetas de dificultad calibradas derivadas del comportamiento del modelo.
3. La ejecución es esencial para la confianza: Validar las anotaciones mediante la ejecución real de la API y las comprobaciones de esquema es necesario para asegurar la corrección semántica, no solo la validez sintáctica.

Los autores concluyen que la atribución de errores estructurada es necesaria para guiar el desarrollo de sistemas agénticos más robustos, y que su marco de bucle cerrado proporciona un método reproducible para construir tales benchmarks diagnósticos.