🔧 Function Calling: Agent'ın Elleri

Function Calling: Agent'ın Elleri: Function calling, sadece bir talep formu doldurabilen ("lütfen X hesabından Y hesabına 50 dolar transfer et") ve bunu bir insan veznedara elden

Function calling, sadece bir talep formu doldurabilen ("lütfen X hesabından Y hesabına 50 dolar transfer et") ve bunu bir insan veznedara elden veren bir çağrı merkezi operatörüne benzer — operatör formu ne kadar kendinden emin doldurursa doldursun kasaya ASLA kendisi dokunmaz. Mekanizma birebirdir: LLM, bir aracın adı ve beklenen parametreleri verildiğinde, aracı adlandıran ve argüman değerlerini dolduran yapılandırılmış bir istek (genelde JSON) üretir — function calling'de "LLM'in yaptığı"nın TAMAMI budur; ayrı bir kod parçası (senin kodun) o yapılandırılmış isteği okur ve gerçekten bir şey çalıştıran tek şey odur. Üzerinde durulmaya değer soru şu: model bir dosyayı silmek için kusursuz biçimlendirilmiş bir istek yazabiliyorsa, bu modelin dosyayı gerçekten silmesinden neden temelde farklıdır? Çünkü modelin çıktısı hâlâ sadece METİNDİR (yapılandırılmış metin, ama metin) — bir dosya sistemine, bir veritabanına veya bir ağ soketine kendi başına dokunma yeteneği sıfırdır; "bir istek yazdı" ile "dosya silindi" arasındaki boşluk tamamen senin yazıp çalıştırmayı SEÇTİĞİN kodla köprülenir, ki bu da modelin isteğinin çalıştırılacak kadar güvenilir olup olmadığına, hangi izinlerle, ve önce onay istenip istenmeyeceğine SENİN karar verdiğin anlamına gelir. Java karşılaştırması: bu tam olarak bir interface/implementation ayrımıdır — LLM, çağıran kodun bir Java interface'i gördüğü gibi bir interface görür (bir aracın adı, parametre tipleri ve ne yapması gerektiğinin bir açıklaması), ama LLM implementasyonu asla sağlamaz; senin kodun, "metod" çağrıldığında gerçekte ne olacağını uygulayan somut sınıftır, ve modelin o implementasyona görünürlüğü veya kontrolü yoktur. QA tarafındaki bedel: bu ayrım, Claude AI sayfasında ele alınan izin modlarının arkasındaki güvenlik modelinin tamamıdır — çünkü model bir araç çağrısını sadece İSTEYEBİLİR, asla çalıştırmasını zorlayamaz, her gerçek güvenlik sınırı tamamen o isteği onaylayıp onaylamayacağına karar veren kodda yaşar, modelde değil.

Model İster, Kodun Çalıştırır

Ayrım tam olarak iki adımdır: (1) bir aracı adını, parametrelerini ve ne yaptığını tanımlayarak — genelde bir JSON şema olarak — kaydedersin, böylece model onun var olduğunu ve nasıl isteneceğini bilir; (2) model o aracın gerekli olduğuna karar verdiğinde, hiçbir şey çalıştırmaz — aracı ve kullanmak istediği argüman değerlerini adlandıran yapılandırılmış bir nesne üretir. Kodun sonra o nesneyi okur, gerçek fonksiyonu gerçekten çağırıp çağırmayacağına karar verir, öyleyse çalıştırır, ve gerçek sonucu bir önceki sekmedeki döngünün sıradaki gözlemi olarak modele geri besler.

Akıl yürütme: modelin ne yapmak istediğini düz İngilizce anlatmasına izin vermek yerine katı bir JSON şemasıyla uğraşmaya neden değer? Çünkü düz dil belirsizdir ve kodun gerektirdiği güvenilirlik seviyesinde makine tarafından ayrıştırılamaz — "flaky test log'unu kontrol et", farklı parametrelerle bir düzine farklı fonksiyon çağrısı anlamına gelebilir. Bir şema, modeli niyetin belirsiz bir doğal-dil açıklaması yerine kesin, ayrıştırılabilir, çalıştırılabilir bir isteğe (araç adı + tipli parametreler) angaje olmaya zorlar — tıpkı güçlü tipli bir metod imzasının çağıranı belirli argüman tiplerine angaje olmaya zorlaması gibi.

Bir Araç Tanımı, JSON Şemasında

Adım Adım: Araç İsteğinden Gerçek Çalıştırmaya

Kodun, bir aracın adını, parametrelerini ve amacını modele tanımlar.

Bir görev verildiğinde, model bu aracın gerekli olduğuna karar verir.

Model, aracı ve argüman değerlerini adlandıran YAPILANDIRILMIŞ bir istek üretir — bu hâlâ sadece metindir.

Kodun isteği okur ve gerçek fonksiyonu GERÇEKTEN çağırır.

Gerçek sonuç, modelin sıradaki gözlemi olur.

Bir araç isteğinin gerçek çalıştırmaya giden akışını doğru sıraya diz.

Kod, aracın adını ve parametrelerini modele tanımlar

Model bu aracın gerekli olduğuna karar verir