Bir üniversite için başvuru chatbot'u yaptık. Aday öğrenci soruyor, sistem cevaplıyor. Basit görünüyordu.
Sorular geldikçe iki farklı türe ayrıldıklarını fark ettik.
Birinci tür: "Bilgisayar mühendisliği taban puanı kaçtı?" Bunun kesin bir cevabı var, bir tabloda duruyor ve yanlış söylerseniz insanlar tercih formunu yanlış dolduruyor.
İkinci tür: "Bölümde staj imkânı nasıl?" Bunun tek bir doğru cevabı yok. Cevap tanıtım metinlerine, yönergelere, sıkça sorulan sorulara dağılmış durumda.
Bu ikisini aynı mekanizmayla çözmeye çalışmak, projenin en pahalı hatası olurdu. Aşağıda üç yaklaşımı, hangisinin ne zaman doğru olduğunu ve maliyet farklarını anlatıyorum.
Üç yaklaşım, tek cümlelik özet
Function calling: Modele "şu isimde, şu parametreleri alan bir fonksiyonun var" diyorsunuz. Model ne zaman çağıracağına karar veriyor, siz çalıştırıyorsunuz, sonucu geri veriyorsunuz. Fonksiyon tanımları uygulamanızın içinde yaşıyor.
RAG: Metinleri parçalara bölüp vektöre çeviriyorsunuz. Soru geldiğinde en yakın parçaları bulup modelin bağlamına koyuyorsunuz. Model bulduğu metne dayanarak cevap yazıyor.
MCP: Function calling'in standartlaştırılmış ve dışarı çıkarılmış hali. Fonksiyonlar uygulamanızın içinde değil, ayrı bir sunucuda yaşıyor ve herhangi bir istemci onlara bağlanabiliyor.
Buradaki en yaygın kafa karışıklığı şu: MCP ile function calling rakip değil. MCP, function calling'i nasıl paketleyip dağıttığınıza dair bir protokol. RAG ise bambaşka bir problemi çözüyor.
Karar tablosu
| Soru | Yaklaşım |
|---|---|
| Cevap yapılandırılmış bir kaynakta mı duruyor (tablo, API, veritabanı)? | Function calling veya MCP |
| Cevap serbest metne mi dağılmış? | RAG |
| Cevabın kesin ve tekrarlanabilir olması şart mı? | Function calling veya MCP |
| Kaynak veri sık değişiyor mu? | Function calling veya MCP |
| Aynı yetenek birden fazla uygulamadan mı kullanılacak? | MCP |
| Yetenek sadece tek bir üründe mi kullanılacak? | Function calling |
| Yeteneği başka ekipler veya müşteriler de kullanacak mı? | MCP |
| Sistem bir eylem gerçekleştirecek mi (kayıt açma, e-posta gönderme)? | Function calling veya MCP |
Neden puan sorusuna RAG uygulamamalısınız
Bu, gördüğüm en yaygın hata. Ekip elindeki tüm PDF'leri, tabloları, katalogları vektör veritabanına atıyor ve her soruyu oradan cevaplamaya çalışıyor.
Sayısal ve tablosal veride bu yaklaşım şu yüzden çöküyor: embedding modeli anlamsal yakınlığa bakar, sayısal doğruluğa değil. "Bilgisayar Mühendisliği 412,5" ile "Biyomedikal Mühendisliği 412,8" satırları vektör uzayında birbirine son derece yakındır. Sistem yanlış satırı getirir, model kendinden emin bir cümle kurar ve aday öğrenci yanlış bilgiyle tercih yapar.
Üstelik puanlar her yıl değişir. RAG kullanırsanız her güncellemede yeniden parçalama ve yeniden embedding gerekir. Function calling kullanırsanız veritabanındaki satırı güncellersiniz, biter.
Bizim çözümümüz şuydu:
program_bilgisi_getir(bolum_adi, yil, bilgi_turu)
Model bu tool'u çağırıyor, biz SQL'i çalıştırıyoruz, kesin sayı dönüyor. Halüsinasyon ihtimali sıfır, çünkü model sayıyı üretmiyor, sadece iletiyor.
Neden staj sorusuna function calling uygulamamalısınız
Tersi de doğru. "Staj imkânı nasıl" sorusu için bir fonksiyon yazamazsınız, çünkü sorunun şekli belirsiz. Bugün staj sorulur, yarın yurt, öbür gün Erasmus, sonra kampüsteki yemekhane.
Her biri için tool yazmaya kalkarsanız iki hafta sonra kırk tool'unuz olur ve model hangisini çağıracağını şaşırmaya başlar. Bu gerçek bir sınır: tool sayısı arttıkça seçim isabeti düşer. Yirmi tool'un üzerine çıkıyorsanız, muhtemelen bazılarının RAG olması gerekiyor.
Serbest metin için RAG doğru araç. Metinleri makul boyutta parçalayın, embedding alın, sorguyu vektöre çevirip en yakın parçaları getirin.
Hibrit mimari nasıl kurulur
Bizim kurduğumuz yapı şuydu: model önce yönlendirme kararını veriyor.
Modele hem tool tanımlarını veriyoruz hem de bir dokuman_ara tool'u. Yani RAG'i de bir tool olarak sunuyoruz. Model soruyu okuyup hangisini çağıracağına kendisi karar veriyor.
program_bilgisi_getir(bolum_adi, yil, bilgi_turu)
kontenjan_getir(bolum_adi, yil)
burs_orani_getir(bolum_adi)
dokuman_ara(sorgu)
Bu yapının güzelliği, ayrı bir sınıflandırma adımı yazmak zorunda kalmamanız. Model zaten sınıflandırma yapıyor, siz sadece seçenekleri sunuyorsunuz.
İki pratik not:
Tool açıklamalarını çok net yazın. dokuman_ara için "diğer tool'ların kapsamadığı genel sorular için kullan" yazmak yeterli değil. Somut örnek verin: "kampüs olanakları, yurt, staj, kulüpler, ulaşım gibi tanıtıcı sorular için."
Model ikisini birden çağırabilsin. "Bilgisayar mühendisliğinin puanı kaç ve staj imkânı nasıl" sorusu tek soru gibi görünüyor ama iki farklı kaynağa gitmesi gerekiyor.
Maliyet ve gecikme
Ölçtüğümüz kaba rakamlar. Kendi sisteminizde farklı çıkacaktır ama büyüklük sırası fikir verir.
Function calling / MCP: Bir tur ek gidiş geliş. Model tool çağırma kararını üretiyor, siz çalıştırıyorsunuz, sonuç geri gidiyor, model cevabı yazıyor. Toplam gecikme, tool'unuzun kendi süresi artı bir model çağrısı. Bizim SQL sorgularımız otuz milisaniye sürdüğü için toplam ek yük neredeyse tamamen ikinci model çağrısıydı.
Token maliyeti düşük. Tool tanımları sistem promptunda sabit duruyor, dönen sonuç genelde küçük.
RAG: Embedding çağrısı artı vektör araması artı model çağrısı. Embedding çağrıları ucuz ve hızlı. Asıl maliyet, getirilen parçaların bağlama eklenmesi. Beş parça getiriyorsanız ve her parça iki bin token ise, her soruya on bin token ek maliyet biniyor.
Yani RAG, function calling'den belirgin şekilde pahalı. Sorularınızın çoğu yapılandırılmış veriye gidiyorsa ve siz her şeye RAG uyguluyorsanız, hem yanlış cevap veriyorsunuz hem de fazla ödüyorsunuz.
MCP'nin ek yükü: Function calling'e göre bir ağ atlaması daha var, çünkü tool sunucusu ayrı bir süreçte. Yeni durumsuz protokol modeliyle bu yük azaldı: artık her istek kendi kendine yeten tek bir POST, öncesinde bir handshake yok. Ayrıca tool listesi sonuçları ttlMs ile önbelleklenebiliyor, dolayısıyla istemci her seferinde tools/list çağırmak zorunda değil.
Aynı ağdaki bir MCP sunucusu için ek gecikme genelde ihmal edilebilir seviyede.
Ne zaman MCP'ye geçmeli
Function calling ile başlayan bir sistemi MCP'ye taşımak, doğru zamanda yapılırsa yarım günlük iş. Yanlış zamanda yapılırsa gereksiz karmaşıklık.
MCP'ye geçin, eğer:
- Aynı yeteneği birden fazla uygulamadan kullanacaksanız. Web chatbot'u, mobil uygulama ve iç panel aynı tool'lara ihtiyaç duyuyorsa, üç yerde aynı kodu yazmak yerine bir sunucu koyun.
- Tool'ları yazan ekiple onları kullanan ekip farklıysa. MCP burada bir sözleşme görevi görüyor.
- Kullanıcılarınızın Claude Desktop, Cursor gibi hazır istemcilerden sisteminize bağlanmasını istiyorsanız. Bu, function calling ile mümkün değil.
- Tool'ları bir ürün olarak dışarı açacaksanız.
MCP'ye geçmeyin, eğer:
- Tek bir üründe, tek bir ekip tarafından kullanılan üç beş fonksiyondan bahsediyorsak. Ek altyapı, dağıtım, kimlik doğrulama ve versiyon yönetimi getiriyor. Karşılığında ne alacağınız net değilse almayın.
- Gecikmenin milisaniye seviyesinde kritik olduğu bir senaryodaysanız.
Son bir uyarı
MCP hızla değişiyor. 28 Temmuz 2026 sürümü lansmandan bu yana yapılmış en büyük revizyon ve geriye dönük uyumsuz değişiklikler içeriyor. Oturum modeli kalktı, üç temel özellik deprecate edildi, Tasks çekirdekten çıkıp uzantı oldu.
Bu, MCP'den kaçınmak için bir sebep değil. Ama şunu söyleyebilirim: yeni bir projeye başlıyorsanız doğrudan yeni sürümü hedefleyin. Eski sürüm üzerine inşa edip altı ay sonra taşımak, baştan doğru sürümle başlamaktan pahalı.
Bundan sonrası için de bir güvence var: yeni gelen yaşam döngüsü politikasıyla her özelliğin deprecation ile kaldırılma arasında en az on iki ay süresi bulunuyor, ve yeni yetenekler artık opt-in uzantı olarak çıkıyor. Yani bu ölçekte bir kırılma bir daha kolay kolay yaşanmayacak.
Kendi projenizde bu üçünü nasıl kombine ettiğinizi merak ediyorum. Özellikle Türkçe içerikte RAG performansı üzerine deneyimlerinizi duymak isterim.