Mejores modelos para tool calling: cómo comparar con BFCL y pruebas propias

El mejor modelo para tus herramientas es el que completa tu tarea con permisos, presupuesto y latencia aceptables. Un ranking público ayuda a elegir candidatos, pero no sabe cómo describes tus funciones, qué datos faltan en tus solicitudes ni cuánto cuesta un reintento en tu negocio.

Aquí no publicamos un ganador obtenido de pruebas que no hemos realizado. Descarga casos-stock.jsonl y comparar-modelos.csv: ocho escenarios sintéticos y una hoja vacía para registrar tu comparación. Puedes usarlos con el agente de stock en Python o adaptar criterios a tu backend.

Qué puedes concluir de BFCL

El Berkeley Function Calling Leaderboard evalúa llamadas a funciones con un dataset y un harness publicados. La página consultada para esta revisión presenta BFCL V4 y diferencia modo FC nativo de modo Prompt. También describe coste estimado de la suite y latencias; esos valores no son el precio por conversación de tu producto.

Antes de copiar una fila, registra:

• Fecha de consulta y fecha de actualización que muestra el leaderboard; no son lo mismo.
• ID completo del modelo, modalidad y columnas concretas.
• Versión del dataset/harness y subconjunto evaluado.
• Tarifas y condiciones usadas para estimar coste.

Si una página dice “actualizado en abril”, una consulta realizada en septiembre no convierte sus resultados en una comparación nueva de septiembre. Por eso sustituimos la tabla estática anterior por un método reproducible: consulta las filas vigentes en la fuente y valida después con tu suite.

Nativo, prompt y schema no son equivalentes

En modo nativo, la API acepta definiciones de herramientas y devuelve estructuras específicas para llamadas. En modo prompt, el harness pide al modelo serializar una acción como texto o JSON. Ambos pueden tener resultados distintos incluso usando el mismo nombre comercial del modelo.

Compara el modo que realmente usará tu aplicación. Si utilizas Responses API y function_call_output, no traslades sin más una puntuación obtenida con un parser de texto. Verifica también si el proveedor admite tu schema estricto, llamadas paralelas y el tamaño de contexto requerido. “Compatible con OpenAI” no garantiza todos los campos de todas las APIs.

El modelo no ejecuta la función: tu aplicación valida y despacha. Ningún score sustituye autorización, aprobación e idempotencia.

Una comparación pequeña, con control de variables

Elige dos candidatos disponibles en tu cuenta: uno que cumpla el presupuesto y otro que quieras contrastar. La plantilla no los preselecciona. Conserva el mismo dataset, herramientas, instrucciones y límites; si necesitas cambiar el adaptador por proveedor, documenta esa diferencia.

1. Ejecuta cada uno de los ocho casos tres veces por candidato: 24 ejecuciones por candidato como exploración inicial.
2. Usa modelo_id efectivo, no solo “modelo rápido”. Registra fecha, versión de prompt y modo.
3. Marca éxito solo si llamada, argumentos, ejecución y respuesta cumplen el criterio del caso.
4. Conserva errores, rechazos y timeouts. Eliminarlos del denominador hace que el modelo parezca más fiable.
5. Registra coste total y latencia end-to-end por intento, incluida recuperación y reintentos.
6. Repite los casos que discrepan y amplía la suite antes de tomar una decisión de alto riesgo.

La hoja CSV contiene campos vacíos: completarlos es parte de tu experimento. No hay llamadas a modelos ni mediciones de pago realizadas por el sitio en este recurso. Los casos de fallos técnicos necesitan inyección en el harness, no únicamente pedirle al modelo que imagine un error.

La métrica que evita una comparación engañosa

Calcula directamente:

éxito end-to-end = intentos que cumplen todos los criterios / intentos totales
coste por éxito = coste de todos los intentos / éxitos

No multipliques tasas marginales de “función correcta”, “argumentos correctos” y “respuesta correcta” como si fueran independientes. Puedes descomponer una probabilidad usando tasas condicionales sucesivas, pero es más sencillo puntuar el éxito completo de cada ejecución.

Ejemplo aritmético, no un benchmark real: candidato A completa 18 de 24 intentos y cuesta USD 0,24 en total; son aproximadamente USD 0,0133 por éxito. B completa 22 y cuesta USD 0,44; son USD 0,02 por éxito. A es más barato por éxito, B tiene mayor tasa de resolución en esa muestra. No puedes elegir sin conocer el coste de los fallos y si hubo un incidente crítico.

Con pocas observaciones, diferencias pequeñas pueden ser ruido. No declares “superior en producción” por dos respuestas más en una suite de 24. Amplía los casos representativos y repite con condiciones controladas.

Criterios de descarte y elección

Si tu agente necesita…	Descarta cuando…	Después compara…
Consultar datos privados	No puedes imponer permisos en backend	Respuesta con evidencia y abstención
Ejecutar una escritura	El flujo omite aprobación o duplica efectos	Éxito con guardas activas y recuperación
Chat interactivo	Incumple tu presupuesto de latencia	Distribución de latencia, no solo media
Muchas tareas económicas	Excede el gasto disponible por tarea	Coste total por éxito y escalados
Conversaciones largas	Pierde estado o repite herramientas	Casos multiturno de tu dominio

Un fallo crítico es una barrera del sistema, no un número que se compensa con promedios altos. Si todos los modelos fallan el mismo caso, revisa el contrato, la evidencia disponible y el flujo de permisos antes de añadir candidatos.

Qué conservar después de elegir

Guarda dataset, configuración, salidas sanitizadas y decisión: qué ganaste, qué perdiste y cuándo reabrirás la comparación. Repite ante cambios de modelo, prompt, herramientas o datos importantes, no solo por calendario. Una actualización silenciosa puede cambiar el comportamiento aunque mantengas el nombre del modelo.

La guía de evals prácticos explica cómo convertir este ensayo en regresión; la calculadora de costes añade hosting y horas humanas al precio de tokens. Si todavía no tienes un agente que medir, empieza por el curso gratuito o el ejemplo Python. La comparación sirve para decidir sobre un sistema concreto, no para mantener una lista de ganadores sin pruebas.