Uno de los problemas más frecuentes al construir agentes de IA en producción no es que el modelo sea poco inteligente. Es que, cuando tiene acceso a docenas de herramientas internas, elige la equivocada. O la llama con argumentos incorrectos. O elige correctamente pero con parámetros en el formato incorrecto. El resultado es un agente que falla de forma opaca, en producción, con consecuencias reales.
Google lanzó FunctionGemma para atacar exactamente ese problema. Es una variante especializada de Gemma 3 con aproximadamente 270 millones de parámetros — pequeña en comparación con los modelos de referencia actuales — diseñada específicamente para tool calling: traducir instrucciones en lenguaje natural en llamadas precisas a APIs y funciones definidas.
Por qué el tamaño no es el problema
La intuición habitual es que necesitas un modelo más grande para resolver problemas más complejos. En tool calling, esa intuición falla. Lo que determina si un agente selecciona correctamente la herramienta no es el tamaño del modelo — es si el modelo fue ajustado para entender los esquemas, convenciones y patrones de error específicos de tus herramientas.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀Los datos de Google lo confirman: aplicar fine-tuning a FunctionGemma en el benchmark Mobile Actions elevó la precisión desde un 58% de línea base hasta un 85%. Un salto de 27 puntos porcentuales. Con un modelo de 270M parámetros que corre en hardware accesible, no en un cluster de H100.
La comparación relevante no es FunctionGemma vs GPT-5.4. Es FunctionGemma ajustado a tus esquemas vs un modelo genérico de varios billones de parámetros que no conoce la diferencia entre tu función create_ticket() y update_ticket(). En ese escenario, el modelo pequeño bien ajustado gana con frecuencia.
Cómo funciona el fine-tuning para tool calling
El proceso sigue tres etapas que cualquier equipo de producto puede implementar:
1. Definir los esquemas de herramientas: cada función disponible para el agente se especifica en JSON estándar — nombre, descripción, parámetros con tipos, valores permitidos y ejemplos. Esto no es documentación para humanos; es el vocabulario que el modelo va a aprender.
2. Construir ejemplos de entrenamiento: pares de (instrucción en lenguaje natural → llamada de función correcta). La clave está en cubrir casos límite: instrucciones ambiguas, herramientas similares que el modelo podría confundir, parámetros opcionales que se omiten frecuentemente, errores comunes de los usuarios.
3. Fine-tuning y evaluación: el ajuste usa un conjunto de entrenamiento de los ejemplos construidos, con evaluación en un conjunto de test que incluye instrucciones que el modelo no vio durante el entrenamiento. La métrica principal es precisión de selección de herramienta y corrección de argumentos.
Un agente para un sistema de soporte técnico con 40 herramientas internas puede necesitar solo 500-2.000 ejemplos de entrenamiento para ver mejoras significativas. El overhead de construir ese dataset es real pero manejable, especialmente si los logs de producción del sistema actual ya contienen ejemplos etiquetados.
Cuándo tiene sentido y cuándo no
FunctionGemma no es la respuesta para todos los casos de uso. El modelo es pequeño y especializado — excelente para tool calling, no para razonamiento complejo, generación de texto larga o análisis multimodal. Si tu agente necesita hacer ambas cosas, necesitarás una arquitectura que combine modelos o use FunctionGemma solo para el componente de selección de herramientas.
Tiene más sentido cuando: el agente tiene un conjunto acotado y bien definido de herramientas, la precisión de selección es el bottleneck principal de calidad, el costo de inferencia importa (270M params es significativamente más barato que 70B+ en producción a escala), y el dominio es estable (las herramientas no cambian cada semana).
Tiene menos sentido cuando: las herramientas cambian frecuentemente y el costo de reentrenar supera el beneficio, el agente necesita razonamiento profundo más allá de selección de herramienta, o el dataset de entrenamiento sería demasiado pequeño para capturar la variabilidad del dominio.
El principio más allá de FunctionGemma
Lo que ilustra FunctionGemma es más general que el modelo en sí: en ingeniería agentiva, la especialización controlada supera frecuentemente a la generalidad en tareas bien definidas. Un agente que hace una sola cosa bien — seleccionar la herramienta correcta y llamarla correctamente — es más confiable en producción que uno que intenta razonar todo desde cero cada vez.
Para los equipos que hoy sufren con agentes que fallan silenciosamente al seleccionar herramientas — uno de los patrones de fallo más difíciles de diagnosticar en producción, tal como documentamos al hablar del monitoring semántico de agentes — FunctionGemma ofrece una palanca concreta y medible. No requiere reemplazar el stack: puede actuar como un router especializado dentro de una arquitectura de agente más grande.
