Bir süredir yerel yapay zekâ araçlarını kurcalayan herkesin ortak bir derdi var. Model iyi olabilir. Ama iş akışının içine düzgün oturmazsa bütün keyif kaçıyor — bunu yaşamayan kalmamıştır. Ben de geçen ay Kadıköy’deki masamda tam bunu düşünüyordum; bir yandan OpenCode benzeri araçlarla oynuyor, bir yandan “neden bu işler hâlâ gereksiz yere kırılgan?” diye söyleniyordum. Wilmer’e tool calling eklenmesi işte o noktada dikkatimi çekti.
İşin aslı şu: dışarıdan bakınca “tool calling geldi” demek kolay. Perde arkasında ise streaming, farklı model sağlayıcıları, node bazlı akışlar. Çıktıların bozulmadan taşınması gibi küçük görünüp can sıkan tonla detay var — bunların her biri ayrı bir baş ağrısı (kendi tecrübem). Geçen hafta evde denediğim bir yerel ajan kurulumunda da aynı duvara tosladım: model doğru aracı çağırıyor gibi görünürken sonuç JSON değil, dümdüz çorba oluyordu. E peki, sonuç ne oldu? Neyse uzatmayalım; Wilmer tarafında mesele tam da bu çorbayı ayıklamak.
Tool calling neden bu kadar önemli?
Basit bir şey aslında — ama değil. Tool calling, LLM’in kendi başına konuşup durmak yerine dış dünyaya el uzatabilmesi demek. Model sadece metin üretmiyor; gerektiğinde veri çekiyor, hesap yapıyor, başka bir servisle konuşuyor ya da kullanıcıya özel bir işlemi tetikliyor (en azından benim deneyimim böyle). Kulağa basit geliyor, değil mi? Pratikte olay bayağı karışık.
Ben buna “akıllı garson” benzetmesini seviyorum — hani garson menüyü biliyor, mutfağa sipariş veriyor ve tabaktaki sonucu size getiriyor ama yemeği kendi pişirmiyor ya, işte tam o. Wilmer de model ile ön yüz arasında duran aracı katman rolünü üstleniyor. Kendisi aracı çalıştırmıyor, sadece talebi taşıyor ve cevabı geri aktarıyor.
Kritik nokta şu: Ara katman ne kadar az iş yaparsa o kadar iyi değil her zaman. Bazen tam tersine. Çünkü yanlış node’a giren bir tool call bütün pipeline’ı bozabiliyor; özellikle memory lookup, özetleme ya da sınıflandırma gibi iç süreçlerde bu istenmeyen bir durum oluyor —. Fark ettiğinizde genelde iş işten geçmiş oluyor.
Wilmer burada ne yapıyor?
Bunu yaşayan biri olarak söyleyeyim, Wilmer’in konumu aslında oldukça net: frontend ile LLM arasında duruyor ve iki yönlü trafik yönetiyor. Frontend’den gelen tool tanımlarını modele geçiriyor, modelden dönen tool call yanıtlarını da tekrar frontend’e iletiyor. Kağıt üstünde temiz bir tasarım. Pratikte ise ayrı bir sürü sürpriz çıkıyor — tabii ki.
Bunu ilk okuduğumda aklıma 2023 sonbaharında İstanbul’da yaptığım küçük bir RAG prototipi geldi (en azından benim deneyimim böyle). Orada da en büyük sorun model değildi; veri akışıydı (inanın bana). Bir yerde ufak bir format sapması oluyor ve tüm zincir bozuluyordu, saatlerce o sapmanın peşinde koşuyordun. Wilmer’deki yaklaşım bana o yüzden mantıklı geldi — işi parçalara bölüyor, her parçanın sorumluluğu net. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Evet, doğru duydunuz. Bu konuyla ilgili Karpathy’nin Defteri SEO’yu Nasıl Düzeltiyor? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili ABD’nin Yapay Zekâ Çip Planı: Neden Tıkanıyor? yazımıza da göz atmanızı tavsiye ederim.
Burada güzel olan şey şu: Wilmer’in tool’ları gerçekten anlaması gerekmiyor. O sadece taşıyıcı rolünde kalabiliyor. Mimari sadeleşiyor gibi görünüyor — ama hemen sevinmeyin — asıl zorluk yine de aktarım katmanında başlıyor. Bu konuyla ilgili Skyrim’in Havasını Değiştiren Küçük Ama Etkili Mod yazımıza da göz atmanızı tavsiye ederim.
| Katman | Ne yapıyor? | Zorluk seviyesi |
|---|---|---|
| Frontend | Kullanıcı isteğini alır | Düşük |
| Wilmer ara katmanı | Araç tanımlarını taşır, yanıtları yönlendirir | Orta-yüksek |
Burası özellikle karmaşıklaşabiliyor çünkü streaming sırasında gelen parçalar sıradan metin değil… yarım yamalak yapılandırılmış veri olabiliyor, (söylemesi ayıp) yani token token akan JSON parçaları. Siz hiç denediniz mi? Eğer bunu normal text processing pipeline’ına sokarsanız formatın ağzına ediyor diyeyim, açık konuşayım.
Neden bu entegrasyon zahmetli olmuş?
Sadece teknik değil, mimari mesele
Editör masasındaki haberi görünce ilk düşündüğüm şey “tamamdır” oldu, ama sonra detaylara indikçe iş değişti. En çok da per-node kontrol ihtiyacı burada belirleyici olmuş görünüyor. Her node aynı davranmamalı; bazıları tool bilgisini aynen geçirmeli, bazıları ise onu büyük ölçüde budayıp kendi iç işini halletmeli (bu beni çok şaşırttı) Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Hmm, bunu nasıl anlatsamdı…
Bunu kendi testlerimde de gördüm. Geçen cuma gece yarısı Ankara’da çalışan küçük bir denemede memory node’una istemeden araç bilgisi sızınca sonuçlar saçmaladı; model olmayan şeyi yorumlamaya başladı. İşte böyle anlarda insan şunu anlıyor: güçlü özelliklerden önce sınır çizmek gerekiyor.
Sürümler arası format farkı can sıkıyor
{
"frontend": "tool tanımı gönderir",
"wilmer": "passthrough veya filtre uygular",
"model": "tool call üretir",
"stream": "parça parça akar",
"backend": ["OpenAI", "Claude", "Ollama"]
}# Mantık kabaca şöyle:
# — izin verilen node'lar tool'u geçirir
# — diğerleri kaldırır
# — internal prompt türlerinde yalnızca gerekli output tutulur
# — streaming sırasında yapı korunur
pass_through = node.allow_tools and not node.is_internal_only
strip_tools = not pass_through
forward_output = extract_tool_result_if_needed()Aynı kavramın OpenAI’de başka, Claude’da başka, Ollama’da başka temsil edilmesi zaten yeterince yorucu. Bir de üstüne stream halinde gelince iş iyice hassaslaşıyor. Burada insan ister istemez şunu söylüyor: güzel özellik, ama henüz ham. Biraz daha pişmesi lazım.
Lokal modellerde kalite meselesi neden hâlâ kritik?
“Benim hedefim hızdan çok doğruluk oldu.” Bu cümle bence yazının omurgası gibi duruyor; çünkü yerel AI araçlarında çoğu kişi önce performansa bakıyor ama günlük kullanımda sizi kurtaran şey genelde daha az düzeltme gerektiren çıktı oluyor.
“Benim hedefim hızdan çok doğruluk oldu.” Bu cümle bence yazının omurgası gibi duruyor; çünkü yerel AI araçlarında çoğu kişi önce performansa bakıyor ama günlük kullanımda sizi kurtaran şey genelde daha az düzeltme gerektiren çıktı oluyor.
Buna kesinlikle katılıyorum. Hatta benzer hissi İzmir’deki ev ofisimde Qwen tabanlı birkaç yerel denemeyi yaparken yaşadım: hız fena değildi, ama sonuçların tutarlılığı dalgalanınca kullanıcı olarak sürekli müdahale etmek zorunda kaldım. İnsanı en çok yoran şey de o zaten — aracın kendisi değil, aracın sizden sürekli onay istemesi.
- Küçük startup için lokal kurulum ucuzlayabilir.
- Kurum içinde veri dışarı çıkmaz.
- Ekip üyeleri modeli farklı backend’lerle deneyebilir. — ciddi fark yaratıyor
- Maliyet kontrolü uzun vadede rahatlar. (bu kritik)
- Küçük startup için fayda nettir: hızlı prototip ve düşük bulut faturası.
- Kurum tarafında esas kazanç güvenlik ve denetimdir.
- Bireysel geliştirici için ise esneklik öne çıkar.
- Eksi taraf? Kurulum ve bakım yükü hafife alınacak gibi değil.
Nerede işe yarar, nerede tökezler?
Ne yalan söyleyeyim, Küçük ekiplerde Wilmer tarzı ara katmanlar bayağı işe yarar çünkü tek kişi bile farklı modeller arasında geçiş yapabiliyor. Bir gün Claude benzeri kaliteli cevap, ertesi gün bağlantısız ortamda lokal çalışma… hani hepimizin istediği esneklik bu. Gel gelelim enterprise tarafta tablo değişir; orada izleme, loglama, yetkilendirme ve hata toleransı devreye girer. Bambaşka bir oyun.
Kime göre nasıl konumlanır?
- İfade edilen ihtiyaç araç yönetimi ise araya koymak mantıklı olur. — ciddi fark yaratıyor
- Eğer amaç ham hızsa fazla soyutlama sizi yavaşlatabilir.
- Dış API maliyeti yüksekse lokal seçenekler cazipleşir.
- Düzenli çıktı istiyorsanız node bazlı filtreleme ciddi avantaj sağlar.
Sana ne kazandırır?
Size bir şey söyleyeyim, Bana kalırsa en büyük kazanç kontrol hissi. Modelin ne yaptığına dair görünürlük arttıkça debugging de kolaylaşıyor — bu küçük bir şey gibi görünüyor. Uzun vadede ciddi zaman kazandırıyor. Bir arkadaşım geçen ay Berlin’de buna benzer bir kurgu kurduğunu anlattı; harcadığı süre arttı, (inanın bana). Yanlış çağrı sayısı ciddi biçimde düştü. Açıkçası buna şaşmadım.
Bence, Ayrıca agentic coding tarafında kalite farkını kapatmaya çalışırken bazen hız kaybını kabul etmek gerekiyor. Hoş mu? Pek değil. Ama sağlamlık isteyen biriyseniz bedeli ödüyorsunuz — başka türlü olmuyor. Benim favori kısmım ise şu oldu: Wilmer artık işin merkezinde karar vermek zorunda kalmadan trafiği düzgün taşıyabiliyor. Küçük görünen bu şey aslında büyük rahatlık (kendi tecrübem)
Sıkça Sorulan Sorular
Tool calling tam olarak nedir?
Vallahi, Modelin dış araçları çağırıp sonuç almasını sağlayan mekanizmadır. Sadece sohbet etmez; gerektiğinde veri çeker veya işlem tetikler.
Neden ara katmana ihtiyaç var?Ara katman hem güvenlik hem düzen sağlar.
Hele bir de çok adımlı akışlarda hangi bilginin nereye gideceğini kontrol etmek kolaylaşır.
—
### Kaynaklar жәne İleri Okuma
– [OpenAI Function Calling Docs](https://platform.openai.com/docs/guides/function-calling)
– [Anthropic Tool Use Documentation](https://docs.anthropic.com/en/docs/build-with-claude/tool-use)
– [Ollama GitHub Sayfası](https://github.com/ollama/ollama)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
