Cuando se habla de agentes de IA, lo realmente útil no es que “conversen bonito”, sino que conviertan una petición en una acción ejecutable. En la práctica, eso significa llamadas a funciones: el modelo decide qué herramienta usar y con qué argumentos, como si fuese un operador de centralita que conecta tu llamada con el departamento adecuado sin hacerte perder tiempo.
Con esa idea en mente, Google presentó FunctionGemma, una variante especializada de Gemma 3 (en el tamaño de 270M parámetros) afinada específicamente para tool calling. La apuesta es clara: modelos más pequeños y rápidos, pensados para ser rentables y funcionar con soltura cuando el flujo de trabajo depende de invocar APIs, funciones internas o acciones concretas.
Por qué el fine-tuning sigue siendo necesario si el modelo ya “sabe” llamar herramientas
Que un modelo tenga habilidad genérica para llamadas a funciones no implica que entienda tus reglas. Un asistente público puede optar por “buscar en internet” casi por inercia, porque es una salida segura para responder preguntas abiertas. En una empresa, ese mismo comportamiento puede ser justo lo contrario de lo deseable: hay políticas, fuentes internas, restricciones de seguridad y, sobre todo, una expectativa de cumplimiento.
Aquí entra el fine-tuning como una forma de educar al modelo en “las normas de la casa”. En el texto de Google se ilustran tres motivaciones habituales que se parecen mucho a situaciones del día a día: resolver ambigüedades cuando hay herramientas parecidas, entrenar una ultraespecialización para formatos propietarios o tareas de nicho, y destilar el comportamiento de un modelo grande en otro más pequeño que ejecute un flujo concreto con rapidez y coste contenido. Dicho con una metáfora doméstica: no basta con que alguien sepa cocinar; en tu cocina quieres que siga tu receta, con tus alergias, tus utensilios y tu orden de limpieza.
El dilema más común: base de conocimiento interna vs búsqueda en Google
El caso práctico del artículo plantea una disyuntiva que cualquiera que haya trabajado con documentación corporativa reconoce al instante. Se definen dos herramientas: una para consultar documentos internos, tipo base de conocimiento (“search_knowledge_base”), y otra para información pública (“search_google”). La pregunta “¿Cuál es la política de viajes?” debería ir a lo interno; la pregunta “¿Buenas prácticas para una función recursiva en Python?” suele tener sentido en lo público.
El problema aparece cuando el modelo, por costumbre, se inclina por la vía abierta aunque el usuario esté preguntando por una norma interna. Es como pedirle a alguien de tu oficina “¿dónde está la plantilla del informe?” y que te conteste “voy a buscar en la web”, ignorando que la respuesta correcta está en el drive corporativo. El tool calling es la mecánica; la “educación” para decidir bien es el fine-tuning.
Datos de entrenamiento: lo que parece un detalle y termina siendo una trampa
Para evaluar esa capacidad de enrutado, el ejemplo usa el dataset bebechien/SimpleToolCalling, que contiene conversaciones diseñadas para forzar la elección entre dos herramientas. Esto es importante porque el aprendizaje no va de memorizar frases, sino de captar la lógica subyacente: “pregunta de política interna” frente a “pregunta de conocimiento general”.
El artículo describe una división de datos al 50/50 entre entrenamiento y prueba, no como receta de producción, sino para hacer visible la mejora en una gran cantidad de ejemplos no vistos. En contextos reales se suele ver algo más parecido a 80/20, pero el mensaje de fondo es otro: la separación entre train y test es el cinturón de seguridad que evita autoengañarse con resultados inflados.
La advertencia más jugosa, por práctica, tiene que ver con la distribución del dataset y el parámetro de barajado. Si tus ejemplos están ordenados por categorías, y entrenas sin mezclar, puedes terminar alimentando al modelo con un solo tipo de herramienta durante el entrenamiento y evaluándolo con la otra. El resultado es el equivalente a enseñar a alguien únicamente a atender llamadas del departamento de contabilidad y luego ponerlo a prueba en soporte técnico: no es que sea “malo”, es que nunca vio esos casos. La recomendación que se desprende del texto es sencilla: asegúrate de que tus datos estén premezclados o habilita el “shuffle” para evitar una caída de rendimiento que puede parecer misteriosa, cuando en realidad es un problema de dieta informativa.
Entrenamiento supervisado con SFTTrainer: qué cambia en el comportamiento
En el ejemplo, el ajuste se realiza con un esquema de fine-tuning supervisado usando Hugging Face TRL y un entrenador de tipo SFTTrainer, durante 8 épocas. Más allá del detalle numérico, lo relevante es lo que se observa en la curva de pérdida: al inicio suele haber una caída marcada, señal de que el modelo se adapta rápido a la nueva regla de enrutado. Es como cuando aprendes un atajo para llegar a casa: los primeros días notas una mejora enorme; luego afinas pequeños detalles.
Tras el entrenamiento, el cambio de conducta que se busca es muy concreto: menos charla y más ejecución. Donde el modelo base podía dudar, sugerir “hablar del tema” o escoger la herramienta equivocada, el modelo afinado se ciñe a la política. En términos de interfaz, eso se traduce en generar una llamada estructurada del estilo:
<start_function_call>
call:search_knowledge_base{query:"proceso para crear un proyecto en Jira"}
<end_function_call>
La idea no es el formato literal, sino el giro mental: la respuesta correcta no es un párrafo, sino activar la herramienta adecuada con argumentos bien formados.
FunctionGemma Tuning Lab: afinar sin pelearse con el entrenamiento
No todo el mundo quiere montar dependencias, pelear con configuraciones o construir bucles de entrenamiento. Para ese público, Google presenta FunctionGemma Tuning Lab, una demo alojada en Hugging Face Spaces que pretende bajar la barrera de entrada. Si el entrenamiento “manual” se parece a montarte un gimnasio en casa con pesas, banco y rutina personalizada, el laboratorio sería más bien una máquina guiada: eliges el peso, sigues el movimiento, y ves métricas sin tocar demasiada ingeniería.
Según la descripción, el flujo se centra en definir esquemas de funciones en JSON dentro de la interfaz, subir datos en CSV con el prompt del usuario, el nombre de la herramienta y sus argumentos, y lanzar el proceso ajustando parámetros como tasa de aprendizaje y número de épocas con controles visuales. También se destaca la visualización en tiempo real de logs y curvas de pérdida, junto con una evaluación automática antes y después para medir si el modelo mejora en la selección de herramientas. Incluso se menciona la opción de ejecutar el laboratorio en local descargando el Space y levantando la app, pensado para quien quiere experimentar sin depender de un entorno remoto.
Qué se lleva un desarrollador a casa: menos “magia” y más política aplicada
El mensaje que atraviesa todo el ejemplo es que el tool calling es una habilidad base, pero la diferencia entre un asistente genérico y un agente útil está en el cumplimiento de reglas específicas. Afinar FunctionGemma no va de hacerlo “más inteligente” en abstracto; va de hacerlo fiable en una tarea muy concreta: enrutar correctamente intenciones hacia herramientas, incluso cuando las preguntas se parecen.
Si estás construyendo un agente para empresa, ese matiz puede ser la frontera entre un prototipo simpático y un sistema que de verdad se integra en procesos. Y si tu objetivo es correr modelos más pequeños en entornos limitados, la promesa de un modelo pequeño que actúe con disciplina, guiado por datos cuidadosamente preparados, tiene bastante sentido.