La trampa del 92%: tu modelo open-weight rinde peor de lo que dice el benchmark, y la culpa no es del modelo

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Estaba mirando los logs de un agente mío cuando me di cuenta de un patrón que me tenía intrigado hace rato: el modelo no era malo, pero cada cierto tiempo mandaba una llamada a herramienta con un JSON defectuoso. Parámetro que no existía, nombre de tool inventado, formato a medio cocer. Uno lo perdona como «cosas de la IA», pero el costo real es que ese error queda pegado en el contexto, el agente reintenta, se queman tokens, y la sesión se degrada paso a paso. Resulta que este problema está medido, y los números dan vergüenza.

2 de cada 25 llamadas salen malas

La gente de Ubicloud publicó su experiencia sirviendo Kimi K2.6 con vLLM 0.28: de las llamadas a herramientas que generaba el modelo, solo el 92% respetaba el schema declarado. Dicho en criollo: 2 de cada 25 llamadas de tool llegaban malformadas para un modelo que su mismo fabricante certifica de otra manera. La herramienta de medición es el benchmark K2VV ToolCall de Moonshot, con 2.000 requests, y existe justo para que los proveedores verifiquen que sirven el modelo con la misma calidad que la API de primera mano.

¿Y por qué pasa, si el modelo es el mismo? Porque un LLM no es un compilador con type-checker, es una máquina de probabilidades. Genera el token más probable, y listo. Estos modelos se entrenaron con montones de datasets de tool-calling distintos, con convenciones diferentes, así que tranquilamente te puede escupir search_web cuando la herramienta real se llama web_search, o city_name cuando el schema espera location. Salida plausible, llamada inválida.

La solución existe: constrained decoding

La técnica que arregla esto se llama constrained decoding y la idea es elegante: en vez de dejar muestrear libre y validar después, el motor de inferencia enmascara los tokens inválidos en cada paso. Si el agente está en la parte del índice de la llamada, solo puede muestrear dígitos; si está dentro del JSON, solo tokens que no lo saquen de la gramática del schema. vLLM lo implementa con structural tags de la librería XGrammar, y los masks se precomputan y se aplican en GPU con un costo despreciable. Con esto, la precisión de schema deja de ser best-effort y pasa a ser garantía de runtime, sin sacrificar rendimiento.

Y ahora la letra chica que nadie te cuenta

Aquí viene lo que más me gusta de esta historia. vLLM tiene la feature, pero la tiene apagada por defecto, y no por incompetencia: habilitarla destruye la calidad en otros modelos — con gpt-oss-20b, Qwen 3.6 y GLM 5.1 hay reportes de usuarios afectados — y además hay bugs de traducción de esquemas y de interacción con el decoding especulativo. Para un motor agnóstico a modelos, mantener el default conservador es lo correcto. La forma de activar el modo estricto es el flag --tool-strict-level, disponible desde vLLM 0.31. El equipo de Ubicloud mantuvo su propio fork, prendió constrained decoding explícitamente, y en el benchmark pasó de ese 92% a 100% de precisión de schema en Kimi y DeepSeek.

Mi lectura, con el sombrero de sysadmin: el modelo que corres es solo la mitad del producto. El motor, su versión y su configuración forman parte del resultado, igual que el driver de tu GPU forma parte de tu FPS. Si autoalojas LLMs para agentes, no te fíes del benchmark de marketing — corre una batería de tool-calls contra TU despliegue, con TU configuración, y mide cuántas llamadas respetan el schema. Yo tenía la sensación de un deterioro en mis sesiones; ahora sé que tiene nombre, y que probablemente lo estaba causando un default conservador que nunca revisé. Si tu benchmark dice 100% y tu pega se siente distinta, mira la configuración del motor antes de culpar al modelo.

Fuente de inspiración: Fixing Tool-Call Accuracy in vLLM