El bug de Ollama que hace que gemma4 invente datos

Ollama 0.33.3 tiene un bug confirmado en el renderer de gemma4: cualquier parámetro de tool calling llamado type, description, properties, required o nullable pierde su definición completa aunque siga listado en required:[...]. El modelo gemma4:e2b, sin ver esa definición, inventó “urgent” en vez del valor correcto urgent_A7, según el reporte técnico publicado el 16 de septiembre de 2026.

El bug de function calling de Ollama es un defecto en model/renderers/gemma4.go, el módulo que traduce las definiciones de herramientas (tools) al texto de prompt que recibe gemma4. Cuando un parámetro tiene el mismo nombre que una schema keyword de JSON Schema, el renderer filtra su definición entera mientras lo mantiene en la lista de campos obligatorios, dejando al modelo con una instrucción sin contenido.

¿Qué parámetros de tool calling elimina el renderer de gemma4 en Ollama?

El renderer de gemma4 elimina la definición completa de cualquier parámetro cuyo nombre coincida con una schema keyword de JSON Schema: type, description, properties, required o nullable. El nombre queda en required:[...], así que el modelo sabe que tiene que completar ese campo, pero no recibe ninguna pista sobre el tipo de dato, la descripción o los valores permitidos.

El caso documentado en el issue original usa un creador de tickets con dos parámetros obligatorios: title (string simple) y un segundo campo con un enum de dos valores, urgent_A7 y routine_B3. JSON Schema no prohíbe nombrar un parámetro igual que una keyword del propio schema, porque viven en namespaces distintos. El problema es específico de este renderer: ni la plantilla Jinja de referencia de gemma4 ni ningún validador de JSON Schema tienen ese conflicto.

¿Cómo se manifiesta el error en la práctica según las pruebas realizadas?

Con el parámetro llamado kind, gemma4:e2b devolvió urgent_A7 de forma correcta en las dos corridas registradas. Renombrado a type, el mismo modelo, con la misma pregunta y temperatura 0, generó “urgent”: una palabra que aparece en el mensaje del usuario pero no es ningún valor válido del enum. Renombrado a description, inventó directamente una oración. Ya lo cubrimos antes en nuestra guía completa de Ollama en 2026.

Ponele que sos vos el que arma ese tool y elegís type como nombre porque es lo más natural para un campo categórico (nadie llamaría a eso de otra forma). Subís el modelo, lo probás en local con un par de ejemplos que casualmente funcionan, lo mandás a producción, todo responde con HTTP 200, y recién semanas después alguien nota que el valor guardado como prioridad de un ticket es una palabra que el modelo sacó del aire.

La diferencia entre tamaños de modelo también quedó registrada: gemma4:26b, el modelo más grande usado por quien reportó el bug, prefirió omitir el argumento en vez de inventarlo. Un modelo más grande “declina adivinar”; uno más chico, no. Los números del reporte original son contundentes: 1 ticket creado sobre 14 intentos, con 35 fallos de validación de esquema, todos sobre un parámetro obligatorio llamado description.

Nombre del parámetro	¿Se renderiza la definición?	Resultado observado en gemma4:e2b
kind	Sí	urgent_A7 (correcto en ambas corridas)
type	No	“urgent” (inventado desde el mensaje del usuario)
description	No	Oración inventada como valor
properties	No	No probado end-to-end con modelo real
required	No	No probado end-to-end con modelo real
nullable	No	No probado end-to-end con modelo real
typo (control)	Sí	Se renderiza normalmente, no es una keyword

¿Qué causa técnica tiene este bug de function calling en el código de Ollama?

La causa es un argumento perdido al portar la plantilla Jinja de referencia de gemma4 a Go. La macro original, format_parameters(properties, required, filter_keys=false), se llama cuatro veces en el template: tres sin pasar filter_keys (parámetros de nivel superior, propiedades de objetos anidados, items de arrays) y una sola vez con filter_keys=true, en el caso puntual donde el macro recorre las keywords del propio schema. Te puede servir nuestra cobertura de montar un agente local con Hermes Desktop.

El puerto en Go, la función writeSchemaProperties en model/renderers/gemma4.go, tiene los mismos cuatro puntos de llamada y la misma lista de nombres a filtrar, pero no tiene el argumento. Filtra sin condición en las cuatro llamadas. Lo que en la plantilla era un filtro de una sola rama se convirtió en un filtro global.

El arreglo son 12 líneas: agregar un booleano filterKeys a la firma de la función y pasarlo en true solo en el call site que corresponde. Con el parche aplicado, el mismo request que antes devolvía “urgent” devuelve urgent_A7. Según el reporte, main en el commit a43fad18 (15/09/2026) seguía con el código sin corregir al momento de publicarse el análisis.

¿Alguien probó esto con un nombre de parámetro real antes de mergear el port? Los tests existentes del paquete pasan igual, con y sin el fix, así que evidentemente no: ninguno de los casos de prueba usaba un parámetro llamado como una keyword del schema. Para más detalles técnicos, mirá cómo bajar costos de API con Llama.

¿Qué límites tiene esta investigación sobre el bug?

Las pruebas end-to-end con un modelo real se hicieron únicamente sobre parámetros de nivel superior (top-level), no sobre objetos anidados ni items de arrays. El código sugiere el mismo comportamiento en esos casos, porque llaman a la misma función con el mismo filtro sin condición, pero eso quedó confirmado solo por lectura estática del código y por un test dentro del mismo paquete, no por una corrida real contra el modelo.

Vale la distinción: lo confirmado es el bug en parámetros top-level (con logs de request y response) y la causa en el código (con el diff de 12 líneas y su test). Lo no verificado end-to-end es el comportamiento en propiedades anidadas y en arrays. Tomalo con pinzas si tu tool usa objetos complejos.

¿Cómo solucionar el error de tool calling con parámetros llamados type o description en Ollama?

El workaround inmediato es renombrar el parámetro afectado, por ejemplo type a kind, y listo: eso alcanza para que el modelo vea la definición completa. Si el nombre original es parte de un contrato externo que no podés tocar (una API que ya recibe pedidos con ese campo), mapealo en tu handler: le declarás kind al modelo y lo traducís a type antes de invocar la función real. En migrar tus prompts desde Claude Opus profundizamos sobre esto.

• Detectá los nombres conflictivos primero: un script llamado check-tool-param-names.sh, mencionado en el reporte, recorre un archivo de definición de tools, incluyendo objetos anidados y arrays, e imprime el path JSON exacto de cada colisión.
• Probá contra un servidor real: el mismo script tiene un modo --probe http://host:11434 --model gemma4:e2b que manda el pedido dos veces (con un nombre de control y con el nombre sospechoso) y marca FAIL cuando el segundo pedido no trae el valor esperado.
• Esperá el parche upstream: el cambio de 12 líneas que agrega el booleano filterKeys es la solución de fondo, pero según el reporte todavía no estaba mergeado en main al 15/09/2026.

Un criterio práctico para verificar esto en tu propio setup: antes de asumir que “el modelo es malo” para function calling, corré el mismo tool con un nombre de parámetro neutro (algo como kind o value_x) y compará. Si con el nombre neutro el modelo acierta y con type o description falla, no es un problema del modelo, es el renderer comiéndose la definición. Esto es una propuesta editorial de diagnóstico, no algo que hayamos ejecutado nosotros.

Qué está confirmado y qué no

• Confirmado: el bug existe en Ollama 0.33.3 sobre gemma4, reproducido con logs de request/response y documentado en el issue #18468.
• Confirmado: la causa exacta en el código (falta de un argumento filter_keys al portar la plantilla Jinja a Go) y que el fix mínimo son 12 líneas.
• Confirmado: el mismo código sin corregir seguía en main en el commit a43fad18 del 15/09/2026.
• No confirmado / pendiente: el comportamiento del bug en parámetros dentro de objetos anidados o arrays con un modelo real corriendo (solo hay revisión de código, no prueba end-to-end).
• No confirmado / pendiente: si el parche llegó a una versión estable publicada de Ollama, o si el bug afecta a otras familias de modelos más allá de gemma4.

Errores comunes al diagnosticar este bug

• Validar solo la salida del modelo: si tu handler valida el JSON de respuesta contra el schema, vas a ver un error de validación y vas a terminar debuggeando el modelo (prompt, temperatura, si gemma4 “es malo” para tool calling) en vez de mirar qué prompt recibió en realidad.
• No tener forma de ver el prompt renderizado: Ollama no trae un debug setting que imprima la declaración final que recibe el modelo. La única forma de verla es leer el código del renderer o correrlo vos mismo.
• Saltarte el control con un nombre neutro: sin comparar contra un parámetro llamado, por ejemplo, kind, es imposible distinguir “el modelo no sabe hacer tool calling” de “el renderer le rompió la definición de este campo puntual”.
• Confiar en handlers que no validan: si tu código no valida el schema, el valor inventado (como “type”: “urgent”) se guarda sin que nadie lo note, y te enterás mucho después.

Preguntas Frecuentes

¿Por qué Ollama inventa valores en las llamadas a funciones?

Porque el renderer de gemma4 elimina la definición del parámetro antes de armar el prompt, pero lo deja en la lista de campos obligatorios. El modelo sabe que debe completar ese campo, no tiene ninguna información sobre qué poner ahí, y rellena el hueco con la palabra más obvia disponible en el contexto (por eso “urgent” en vez de urgent_A7).

¿Qué parámetros afecta el bug del renderer de gemma4?

Afecta a cinco nombres específicos: type, description, properties, required y nullable. Son las cinco schema keywords que la plantilla de referencia de gemma4 filtra en un solo caso puntual, y que el port en Go de Ollama filtra en los cuatro casos por error.

¿Cómo evito el error de tool calling con parámetros llamados type o description en Ollama?

Renombrá el parámetro (por ejemplo, type por kind) en la definición del tool que le mandás al modelo. Si necesitás mantener el nombre original en tu API, mapealo en el handler: declarás el nombre neutro al modelo y lo traducís al nombre real antes de ejecutar la función.

¿Está resuelto el bug de function calling de Ollama en gemma4?

No, según el reporte publicado el 16/09/2026, el commit a43fad18 de main (15/09/2026) todavía tenía el código sin corregir. Existe un parche de 12 líneas identificado y probado en el mismo reporte, pero no hay confirmación de que ya esté mergeado en una versión estable.

¿Qué modelos de Ollama tienen este problema de tool calling?

El bug está confirmado en gemma4:e2b y gemma4:26b, con comportamientos distintos entre ambos (el primero inventa un valor, el segundo omite el argumento). El reporte no prueba otras familias de modelos, así que no hay evidencia de que el problema se extienda más allá de gemma4 en Ollama.

Conclusión

El dato central acá no es que un modelo “alucine” (ojo con esa palabra, porque en este caso no hay nada místico: el modelo simplemente no vio el texto que necesitaba). El dato central es que Ollama devuelve HTTP 200 y un JSON bien formado incluso cuando la mitad de la información que el modelo necesitaba para responder bien nunca llegó al prompt. Si tenés tools con parámetros llamados type, description, properties, required o nullable corriendo sobre gemma4 en Ollama 0.33.3, revisalos hoy: el fix de renombrar toma minutos y el costo de no hacerlo es guardar datos inventados sin enterarte. Mientras el parche de 12 líneas no esté confirmado en una release estable, la salida más segura sigue siendo evitar esos cinco nombres en tus definiciones de tools.

Fuentes

• Issue oficial ollama/ollama#18468 – reporte del bug en el renderer de gemma4
• Análisis técnico completo del bug, causa y fix en dev.to (16/09/2026)