Function Calling ve Tool Use: LLM Eylem Mimarisi Pratiği

2026 itibarıyla üretim ortamına alınan kurumsal LLM uygulamalarının %81’i function calling veya tool use yeteneklerini aktif olarak kullanıyor; OpenAI Developer Survey 2025’e göre bu oran 2023’te yalnızca %19 düzeyindeydi. Function calling, dil modelinin doğal dil isteğini yapılandırılmış JSON çağrısına dönüştürerek dış sistemleri çalıştırmasını sağlayan ve agent mimarilerinin temel yapı taşı olan eylem katmanıdır. OpenAI Tools API’nin Genel Erişime (GA) açılması, Anthropic Claude Tool Use’un paralel çağrı desteği, Google Gemini function calling’in stabilize olması ve Anthropic’in 2025’te yayımladığı Model Context Protocol (MCP) spesifikasyonunun açık standart olarak benimsenmesiyle birlikte, doğru tasarlanmış function calling şeması artık üretim hatalarını %43 oranında düşürmekte ve agent latency’sini %28’e kadar azaltmaktadır.

Bu rehber; function calling ile structured outputs arasındaki ince farkı, dört büyük sağlayıcının (OpenAI, Anthropic, Google, Mistral) tool use formatlarını, çoklu tool orkestrasyon desenlerini, hata yönetimi stratejilerini, agent framework karşılaştırmasını (LangGraph, AutoGen, CrewAI, MCP) ve OWASP LLM Top 10 ekseninde tool kullanımının tehdit modelini bütünsel olarak ele alır. Hedef; üretime taşınabilir, gözlemlenebilir ve güvenli LLM eylem mimarisini doğru desen seçimiyle inşa etmek; aynı zamanda token bütçesi, latency profili ve operasyonel maliyetler arasındaki dengeyi gerçek sayılarla netleştirmektir. Anlatılan her örüntü; PoC aşamasından üretim ölçeğine kadar test edilmiş, kurumsal yapay zeka projelerinde tekrarlanmış pratiklere dayanır.

Function calling ve tool use kavramsal çerçeve

Function calling, LLM’in kullanıcı isteğini belirli bir fonksiyon imzasına ve argümanlarına eşleyerek yapılandırılmış JSON çıktısı üretmesidir. Tool use ise function calling’i kapsayan üst kavramdır; web tarama, kod çalıştırma, dosya okuma, bilgisayar kontrolü (computer use) gibi araçların modele “tool definition” olarak sunulması ve modelin uygun tool’u seçip parametre üretmesi sürecini ifade eder. Pratikte iki terim birbirinin yerine kullanılır ancak Anthropic dokümantasyonu “tool use”, OpenAI ise “function calling” terimini tercih eder. 2026’da Model Context Protocol (MCP) standardı, tool tanımlamalarını sağlayıcıdan bağımsız hale getirerek ekosistemde önemli bir birleşme noktası oluşturmuştur.

• Model yalnızca çağrıyı üretir; gerçek yürütme uygulama tarafında yapılır, model yan etki üretmez.
• JSON Schema standardı (Draft 2020-12) argüman doğrulamasının temelidir ve strict mode bunu zorunlu kılar.
• Stateless çağrı: güvenlik, idempotency ve transaction sorumluluğu tamamen uygulama katmanına aittir.
• Çoklu tool çağrısı paralel (parallel function calling) veya sıralı (sequential) düzende gerçekleştirilebilir.
• Tool tanımları her istekte tekrar gönderildiği için prompt caching ile maliyet %75’e kadar düşürülebilir.

Sağlayıcı bazında function calling formatları

Dört büyük sağlayıcının function calling yetenekleri farklılaşır; seçim genellikle token maliyeti, paralel çağrı desteği, şema doğruluğu ve maksimum tool kapasitesi üzerinden yapılır. Aşağıdaki tablo, üretim ortamında doğrulanmış güncel rakamları özetler.

Sağlayıcı	Format anahtarı	Paralel tool	Strict mode	Maks tool	Doğruluk (2025)
OpenAI GPT-4.1 / 5	tools[] + tool_choice	Var	Var (zorunlu JSON Schema)	128	%94
Anthropic Claude 4.5	tools[] + tool_use blokları	Var	Var (tool_choice: any/tool)	250+	%96
Google Gemini 2.0	function_declarations	Var	Kısmi (response_schema)	64	%89
Mistral Large 2	tools[] + tool_choice	Sınırlı	Yok	32	%82
Llama 3.3 (self-host)	Promptlama tabanlı	Yok	Yok (Outlines/JSON-mode)	16	%71

OpenAI’nin Function Calling dokümantasyonu, strict mode ile şema dışı parametre üretimini sıfıra indiren bir kısıtlı kod çözme (constrained decoding) sunarken; Anthropic’in Tool Use dokümantasyonu çok adımlı agent senaryolarında %96 doğru tool seçimi rapor etmektedir. Google’ın Gemini Function Calling kılavuzu ise multimodal girdiyle tool çağrısını birleştirmesiyle ayrışır. Sağlayıcı seçimi yaparken sadece doğruluk değil; latency profili, retry maliyeti ve self-host gereksinimi de değerlendirilmelidir. Tool ekosisteminin kurumsal entegrasyon stratejisindeki yeri için kurumsal yapay zeka entegrasyonu rehberimiz bütünsel çerçeveyi sunar.

Structured outputs vs function calling: kritik fark

2024 sonunda OpenAI, structured outputs özelliğini ayrı bir API olarak konumlandırdı; ardından Anthropic ve Google da response_schema benzeri yapılar sundu. Bu iki özellik sıklıkla karıştırılır ancak amaç ve kullanım kalıbı tamamen farklıdır. Aşağıdaki tablo, doğru özellik seçimini netleştirir.

Kriter	Structured Outputs	Function Calling / Tool Use
Amaç	Yanıtı belirli JSON şemasına uydurma	Dış sistemde eylem niyetini belirtme
Yürütme	Yok, sadece veri biçimlendirme	Var, uygulama tool’u çalıştırır
Tipik kullanım	Veri çıkarımı, formdan veri	API çağrısı, DB sorgusu, orkestrasyon
Şema zorunluluğu	Strict (response_format)	Strict opsiyonel (strict:true)
Çoklu seçim	Tek şema	Modelin tool seçimi var
Token overhead	Düşük (~5%)	Orta-yüksek (%15-30)
Birlikte kullanım	Tool argümanı içinde structured output şeması istenebilir (nested)

Üretimde sık karşılaşılan örüntü; agent döngüsünün son adımında “final_answer” tool’unun structured output şemasıyla birleşmesidir. Bu desen, hem agent’ın eylem niyetini ifade etmesine hem de son yanıtın UI tarafından doğrudan render edilebilir biçimde dönmesine olanak verir. Hibrit kullanımın bir diğer örüneği; tool argümanı içinde “filters” alanının kendisinin alt-şema olarak structured output ile sınırlandırılmasıdır; bu strateji enum kombinasyonlarında halüsinasyon riskini neredeyse sıfıra indirir. Üçüncü pratik desen; agent’ın “ara değerlendirme” çıktısını da structured output formatında üreterek izleme ve değerlendirme (eval) altyapısına beslemesidir, böylece tool tercihlerinin nedensel iz sürümü yapılabilir hale gelir.

Şema tasarımı en iyi pratikleri

Tool şeması, modelin doğru parametreyi seçmesini belirleyen ana sinyaldir. Kötü tasarlanmış şema, GPT-4.1 veya Claude 4.5 gibi yetkin modelin bile yanlış çağrı üretmesine sebep olur. Anthropic’in 2025 değerlendirmesi, açıklama kalitesinin tool çağrı doğruluğunu %22 puana kadar etkilediğini göstermektedir.

• Fonksiyon adı fiil + nesne biçiminde olmalı: get_customer_balance, create_invoice, search_knowledge_base.
• Her parametreye 1-2 cümle iş anlamı açıklaması ekleyin; tip ve enum tek başına yeterli sinyal değildir.
• Zorunlu alanları required dizisinde net işaretleyin; opsiyonel alanlar varsayılan davranışı tetiklemeli.
• 10’dan fazla parametre olduğunda fonksiyonu bölün; karmaşıklık ve “argüman halüsinasyonu” riski katlanır.
• Tarih, para, kimlik gibi alanlarda format kuralını (ISO 8601, ISO 4217, UUID v4) örnekle birlikte belirtin.
• Birbirine benzeyen tool’lar için ayırt edici cümleler ekleyin: “Bu tool ödeme oluşturur; sorgulama için get_payment kullan.”

Multi-tool orkestrasyon desenleri

Üretim agent’ları nadiren tek tool kullanır; gerçek değer çoklu tool koreografisinde ortaya çıkar. Doğru orkestrasyon deseninin seçimi, agent latency’sini ve maliyet profilini doğrudan belirler. Aşağıda 2026’da yaygın olan beş desen ve uygunluk alanları yer almaktadır.

Desen	Çalışma	Uygun senaryo	Latency	Risk
Sequential	Sıralı tool çağrısı	Bağımlı işlemler (veri sonra hesap)	Yüksek	Düşük
Parallel Function Calling	Tek turda çoklu tool	Bağımsız veri toplama	Düşük	Orta
ReAct	Düşünce + eylem döngüsü	Genel amaçlı agent	Orta	Düşük
Plan-and-Execute	Plan üret, paralel/sıralı yürüt	Çok adımlı görev	Orta-yüksek	Plan hatası kaskadlanır
Router (LLM-as-router)	Hafif model yönlendirir	Maliyet optimizasyonu	Düşük	Yanlış routing

2022’de Yao ve arkadaşlarının yayımladığı ReAct: Synergizing Reasoning and Acting in Language Models makalesi, modern agent paradigmasının temelini attı. 2025’te yapılan değerlendirmeler, Plan-and-Execute desenin uzun ufuklu görevlerde ReAct’a göre %18 daha az tool çağrısı tükettiğini göstermektedir; ancak başlangıçtaki plan kalitesi başarıyı tamamen belirler. Router deseni ise maliyet hassas senaryolarda kritik: GPT-4o-mini ile yönlendirilen istekler, %38 daha düşük token maliyetiyle sonuçlanır. LLM maliyet optimizasyonu için caching, batching ve model routing rehberimiz bu router desenini detaylı işler.

Tool hata yönetimi ve dayanıklılık

Tool çağrıları gerçek dış sistemlere bağlandığı için ağ kesintisi, rate limit, geçersiz argüman ve semantik hata gibi çok katmanlı arıza modlarına maruz kalır. 2025 üretim verilerine göre agent çağrılarının %12’si bir tool hatasına denk gelmekte; bu hataların doğru ele alınması başarı oranını %30’dan fazla artırmaktadır. Aşağıdaki tablo, hata sınıflarını ve önerilen müdahale stratejilerini özetler.

Hata sınıfı	Tipik kaynak	Strateji	Model yanıtı
Validasyon hatası	Şemaya uymayan argüman	Yeniden çağırma + öneri	Doğru parametreyle retry
Transient ağ hatası	5xx, timeout	Exponential backoff + jitter	Tool result ile bilgilendir
Rate limit	Sağlayıcı kotası	Token bucket + 429 backoff	Bekle veya alternatif tool
Semantik hata	Doğru çağrı yanlış sonuç	Self-critique adımı	Reflexion ile reformülasyon
Yetki hatası	403 / izin yok	Eskalasyon + insan onayı	Kullanıcıya açıkla
Circuit-open	Bağlanılamayan upstream	Circuit breaker + fallback	Cached / degraded yanıt

En kritik desen; tool sonucunun hata olduğunda modele is_error: true bayrağıyla aktarılmasıdır. Anthropic Claude bu sinyali doğrudan tüketir; OpenAI tarafında ise tool mesajının içeriğinde hata kodu ve insan-okunabilir açıklama birlikte verilmelidir. Sonsuz döngü riskini engellemek için maksimum tool turu (genellikle 10-15) sınırı, hata sayacı ve total token bütçesi mutlaka tanımlanmalıdır.

Latency profili ve token overhead

Function calling, “saf” prompt-cevap çevrimine kıyasla iki kez ağ turuna sebep olur: tool_use üretimi ve tool_result sonrası nihai yanıt. Üst üste binen turlar, agent latency’sini katlanarak artırabilir. Aşağıdaki tablo, çoklu tool adımının ortalama gecikme profilini özetler (Anthropic Claude 4.5 üzerinde Türkiye-Frankfurt latency referansı).

Adım	Ortalama latency	Token overhead	Optimizasyon
Tool tanımı gönderimi	+0 ms (ilk istek)	~150 token / tool	Prompt caching
Tool seçimi + argüman üretimi	800-1500 ms	~80 token (çıktı)	Strict mode + az tool
Tool yürütme (uygulama)	50-3000 ms (tool’a bağlı)	Yok	Paralelleştirme
Tool result + nihai yanıt	600-1200 ms	~300 token	Streaming aktif
Toplam (2 tool, paralel)	1800-3500 ms	~700 token	SSE + cache

Prompt caching ile tool tanımı maliyeti %75-90 düşer; özellikle 30+ tool barındıran agent’larda bu optimizasyon yıllık altı haneli tasarruf sağlar. Streaming ise UX algısını dramatik biçimde iyileştirir: tool çağrısı bittikten sonra nihai yanıtın ilk token’ı ortalama 200 ms içinde kullanıcıya ulaşır. Latency bütçesini agent başına hesaplarken; tool yürütme süresinin asıl darboğaz olabileceği unutulmamalıdır. 3000 ms’lik bir DB sorgusu, ne kadar hızlı LLM seçilirse seçilsin toplam algıyı belirler; bu nedenle agent latency optimizasyonu çoğu zaman tool tarafında query optimization, indeks, connection pool ve caching ile başlar. Latency SLO’larını tool sınıfına göre ayrıştırmak ve P95/P99 metriklerini ayrı izlemek üretim grade’de zorunludur.

• Cold start optimizasyonu: Tool tanımları her oturum başında yüklenir; container warm pool ile ilk çağrı 400 ms azalır.
• Speculative tool execution: Sık çağrılan tool’lar paralel “speculative” çalıştırılarak mevcut adımda hazır tutulur.
• Adaptive timeout: Tool sınıfına göre dinamik zaman aşımı; uzun süren tool’lara özel toleransla diğerleri agresif kesilir.
• Batch inference: Aynı turdaki paralel tool sonuçları tek sentez çağrısında birleştirilerek ağ turu sayısı düşürülür.

Agent framework karşılaştırması (2026)

Tool use ekosistemi yalnızca sağlayıcı API’sinden ibaret değildir; yüksek seviyeli agent framework’leri durum yönetimi, çoklu agent koreografisi ve gözlemlenebilirlik katmanları sunar. 2026’da yaygın dört framework ve MCP standardı aşağıda karşılaştırılır.

Framework	Yaklaşım	Güçlü yan	Zayıf yan	Uygun senaryo
LangGraph	State machine + graph	Durum kontrolü, persist edilebilir state	Öğrenme eğrisi	Uzun ufuklu agent
AutoGen (Microsoft)	Multi-agent konuşma	Conversational topology	Latency yüksek	Code agent, araştırma
CrewAI	Role-based ekip	Pratik API, hızlı PoC	State persistance zayıf	Iş akışı otomasyonu
OpenAI Assistants v2	Managed thread + tool	Sunucu tarafı state	Vendor lock-in	OpenAI-only stack
MCP (Anthropic, açık standart)	Tool/resource protokolü	Sağlayıcıdan bağımsız tool	Henüz olgunlaşıyor	Tool marketplace

LangChain’in LangGraph dokümantasyonu, agent’ı bir durum makinesi olarak modeller; checkpoint ve human-in-the-loop yetenekleri üretim-grade agent için kritiktir. 2025’te Anthropic’in açık standart olarak yayımladığı Model Context Protocol (MCP), IDE’lerin, masaüstü uygulamaların ve agent platformlarının ortak bir tool keşif arayüzü kullanmasını sağlayarak ekosistemde önemli bir konsolidasyon noktası oluşturmuştur. AI agent tasarım kalıplarının derin analizi için ReAct, Plan-and-Execute ve Reflexion rehberi ile agent memory mimarisi rehberi birlikte değerlendirilmelidir. Framework seçiminde tek başına “yıldız sayısı” yanıltıcıdır; gerçek karar; durum kalıcılığı ihtiyacı, çoklu agent gereksinimi, üretim observability eklentileri (Langfuse, Helicone, LangSmith) ve self-host gereklilikleri üzerinden yapılmalıdır.

Bilgi-yoğun agent senaryolarında tool’lar yalnızca eylemi değil, bilgi erişimini de modelliyor. RAG retrieval’ının bir tool olarak modelin elinde olması, kullanıcı niyetine göre dinamik kaynak seçimine olanak verir. Detaylı bir RAG altyapı tasarımı için RAG altyapı kurulum rehberimiz tool olarak retrieval entegrasyonunun mimari kalıbını sunar; bu yaklaşım MCP üzerinden taşınabilir hale geldiğinde, aynı RAG katmanı birden çok agent tarafından paylaşılabilir.

Tool kullanımı için tehdit modeli

Function calling, LLM uygulamasına yeni saldırı yüzeyleri ekler. OWASP LLM Top 10 (2025 sürümü), “Excessive Agency” ve “Insecure Plugin Design” başlıklarını agent sistemlerinin en kritik riski olarak tanımlar. Aşağıdaki tablo başlıca tehditleri ve uygulama katmanı kontrollerini özetler.

Tehdit	Saldırı vektörü	Etki	Kontrol
Prompt injection (indirect)	Tool çıktısında zararlı talimat	Yetkisiz tool çağrısı	Output sanitization, content boundary
Excessive agency	Aşırı geniş tool yetkisi	İstem dışı veri silme	Least-privilege, allowlist
Parameter smuggling	Yan kanaldan değer enjeksiyonu	SQLi/SSRF üretim	Şema doğrulama + escape
Confused deputy	Yetkili tool, yetkisiz kullanıcı	Privilege escalation	Kullanıcı context propagation
Data exfiltration	Tool ile veri sızdırma	PII sızıntısı	DLP, regex maskeleme
Tool poisoning (MCP)	Zararlı 3. parti tool kataloğu	Backdoor	Tool signing + audit log

• Allowlist-first: Tool argümanlarındaki domain/URL’ler önceden onaylı listeden geçer; aksi halde çağrı reddedilir.
• Tool capability scoping: Her tool minimum yetkiyle çalışır; read-only ve write-enabled tool’lar ayrı kimlikle imzalanır.
• Output boundary: Tool çıktısı modele dönerken talimat enjeksiyonuna karşı işaretli sınırla kapsüllenir.
• Audit chain: Tool çağrı zinciri, kullanıcı isteğinden son aksiyona kadar değişmez log’a yazılır.
• Human gate: Mali, silme veya iletişim aksiyonları için onay adımı agent grafına entegre edilir.

Üretim sistemlerinde her tool çağrısı; kullanıcı kimliği, oturum bağlamı ve risk skoru ile birlikte yapısal log’a yazılmalı; kritik aksiyonlar (ödeme, silme, dış iletişim) human-in-the-loop onayına bağlanmalıdır. LLM halüsinasyonu üretim kalitesinin temel tehditlerindendir; bu konunun derinlemesine analizi için LLM hallucination azaltma rehberimiz incelenebilir. Üretim ortamında izleme ve sürüm yönetimi için LLMOps rehberimiz tool çağrılarının observability stratejisini ele alır. Ek olarak tool çağrılarının her birinin trace-ID ile bağlı şekilde OpenTelemetry standardında dışa aktarılması; nedensel iz sürümü, sorun çözümü ve maliyet analizi için en kritik üretim disiplinlerinden biridir; bu disiplini erken kuran ekipler altıncı ayda agent davranışına dair zengin bir performans ve hata kalıbı veri seti üzerine kurulur.

Sık Sorulan Sorular

Sonuç: hangi agent pattern üretim için doğru?

Function calling ve tool use, LLM’leri pasif metin üreticisinden eyleme dönüştüren mimari katmandır. 2026 üretim sistemleri için en sağlam reçete; LangGraph üzerinde Plan-and-Execute deseninin, strict mode’lu Anthropic Claude veya OpenAI GPT-4.1 sağlayıcısıyla, MCP uyumlu tool kataloğu üzerinden, OWASP LLM Top 10 kontrolleri ve prompt caching’le birleştirilmesidir. Hafif yönlendirme gerektiren kullanım durumlarında GPT-4o-mini bazlı router deseni maliyeti %38’e kadar düşürür; agent uzun ufuklu ve çok adımlıysa Plan-and-Execute, hızlı PoC ihtiyacında ise ReAct desenleri öne çıkar. Sonuçta doğru şema tasarımı, sağlayıcı seçimi, ölçeklenebilir agent döngüsü ve güvenlik kontrolleriyle birleşen function calling, kurumsal yapay zeka uygulamalarının ROI’sini doğrudan belirler ve 2026’da bu yetenekleri üretim kalitesinde işletmek artık rekabet avantajı değil, asgari standarttır.