Ollama gemma4 renderer'ı type veya description adlı tool parametrelerini sessizce düşürüyor

Hata ne yapıyor

dev.to'da yayımlanan bir yazıya göre, Ollama'nın gemma4 modelleri için Go renderer'ı, bir tool parametresi type, description, properties, required veya nullable olarak adlandırıldığında parametrenin tanımını sessizce kaldırıyor. Parametrenin adı yine de render edilen required listesine yazılıyor; yani modele bu değeri mutlaka sağlaması gerektiği söylenirken, değerin neye benzemesi gerektiğine dair hiçbir şey gösterilmiyor. Dışarıdan bakıldığında hiçbir şey başarısız olmuyor: istek HTTP 200 dönüyor, tool çağrısı doğru fonksiyon adıyla iyi biçimlendirilmiş JSON olarak geliyor ve log sessiz kalıyor.

Gözlemlenebilir sonuç, modellerin görünmeyen alanı makul görünen herhangi bir şeyle doldurması. Yazar bunu Ollama 0.33.3 üzerinde, Debian 13'de, yalnızca CPU ile çalışan gemma4:e2b modeliyle, iki zorunlu string parametreli (biri enum ile urgent_A7 ve routine_B3 değerleriyle kısıtlı) bir ticket oluşturma tool'u (başlangıçta ollama/ollama issue #18468'den) kullanarak gösterdi. Temperature 0'da, her varyant için iki çalıştırma yapıldı:

• kind olarak adlandırıldığında parametre doğru render edildi ve model her iki seferde de urgent_A7 döndürdü.
• type olarak adlandırıldığında model "type": "urgent" döndürdü — kullanıcının mesajından alınmış, enum'da geçerli olmayan bir kelime.
• description olarak adlandırıldığında model serbest metin bir cümle üretti.

urgent_A7 dizgisi, prompt içinde yalnızca parametre tanımının içinde geçiyor; bu yüzden yalnızca tanım modele gerçekten ulaştığında üretilebiliyor. Yazıda alıntılanan başka bir muhabir, gemma4:26b çalıştırarak farklı bir başarısızlık modu gördü: argüman tamamen atlandı. On dört denemede bir ticket oluşturuldu ve 35 schema-validation hatası kaydedildi; hepsi description adlı zorunlu bir parametrede. Daha büyük model, küçük olanın doğaçladığı yerde tahmin etmeyi reddediyor; her iki davranış da aynı eksik metinden kaynaklanıyor.

Neden: bir template taşımacılığında kaybolan varsayılan argüman

Ollama, gemma4 promptlarını Go'da, model/renderers/gemma4.go dosyasında render ediyor ve renderer'ı, model/renderers/testdata/ içinde saklanan modelin referans Jinja template'ine karşı test ediyor. Jinja makrosu format_parameters, varsayılan olarak false olan bir filter_keys argümanı kabul ediyor ve dört kez çağrılıyor. Üç çağrı yeri hiçbir şey geçmiyor, çünkü o bağlamlarda anahtarlar parametre adlarıdır. Yalnızca tek bir çağrı yeri — kendi properties map'i olmayan bir object'i ele alan dal, anahtarların gerçekten schema anahtar kelimeleri olduğu yer — filter_keys=true geçiyor.

dev.to yazarı, Go portunun aynı dört çağrı yerini ve aynı skip listesini koruduğunu ama argümanı düşürdüğünü buldu. writeSchemaProperties, anahtar kelime adlı anahtarları koşulsuz olarak filtreliyor; yani template'in yalnızca tek bir durumda uyguladığı bir filtre her yerde uygulanıyor. Bu arada required listesi, hiçbir filtreleme yapmayan ayrı bir fonksiyon tarafından yayınlanıyor; parametre adının orada hayatta kalmasının nedeni bu. Model çelişkili bilgi alıyor: bildirimin bir kısmı bir type argümanı talep ederken, başka bir kısım onu hiç tanımlamıyor.

Skip listesinde olmayan typo adlı bir kontrol parametresi düzgün render ediliyor — bu da sorunun schema biçiminde değil, beş belirli adda olduğunu doğruluyor. Yazıda ayrıca, paketin mevcut referans testlerinin düzeltmeden önce ve sonra geçtiği, çünkü hiçbirinin anahtar kelime adında bir parametre bildirmediği ve upstream main'in a43fad18 commit'inde (2026-09-15) hâlâ aynı kodu içerdiği belirtiliyor.

Neden kolayca gözden kaçıyor

Söz konusu adlar gerçek schema'lar için doğal tercihler: kategorik bir alan için type, bir ticket, etkinlik veya ürün üzerindeki serbest metin alanı için description. JSON Schema'nın kendisinin, property adlarının anahtar kelimelerle çakışmasına karşı bir kuralı yok — properties içinde farklı bir namespace işgal ediyorlar ve validator'lar bunları doğru ele alıyor. Bir tool handler şemaya göre doğrulama yapıyorsa, hata ayıklama genellikle modele yöneliyor: prompt ifadeleri, temperature, gemma4'ün function calling'de iyi olup olmadığı. Doğrulama yapmıyorsa, urgent gibi bir değer öncelik kodu olarak saklanıyor ve daha sonra ortaya çıkıyor. Ayrıca Ollama'nın render edilmiş promptu yazdıran bir debug ayarı yok; yani modelin gerçekten aldığı bildirimi, renderer'ı okumadan veya doğrudan çalıştırmadan gözlemlemek mümkün değil.

Düzeltme ve geçici çözüm

Yazıya göre, filtre argümanını geri kazandıran on iki satırlık bir yama sorunu çözüyor: yama uygulandığında aynı istek urgent_A7 döndürüyor. Bu upstream'e ulaşana kadar pratik geçici çözüm, anahtar kelime listesiyle çakışan parametreleri yeniden adlandırmak. Adın dış bir sözleşme tarafından sabitlendiği durumlarda, yazar modele kind gibi güvenli bir ad bildirmeyi ve tool handler içinde onu type'a geri çevirmeyi öneriyor. Yazarın araç seti ayrıca çakışan adları işaretleyen check-tool-param-names.sh adlı bir script içeriyor.

Neden önemli

Tool calling, yerel modeller için birincil arayüz haline geliyor ve Ollama bunları çalıştırmanın yaygın bir yolu. Tool sözleşmesini herhangi bir hata sinyali vermeden bozan bir renderer hatası bir çöküşten daha kötü: sessiz veri bozulmasına davetiye çıkarıyor ve hata ayıklama çabasını yanlış yöne, runtime yerine model kalitesine yönlendiriyor. Aynı zamanda template'leri diller arasında taşırken yaşananlara bir ders — taşınmayan bir varsayılan argüman, tek bir dalın davranışını her dalın davranışına dönüştürdü — ve bir hatanın tam da içinde yaşadığı uç durumu hiç denemeyen test paketleri hakkında da öyle. Ollama üzerinde gemma sınıfı modellerle tool çağıran agent çalıştıran herkes, parametre adlarını şimdi gözden geçirmeli.