%96 Token Tasarrufunu Neden Reddettik

Token kullanımında %96 tasarruf sağlayan bir MCP sunucusu bulduk. Tek bir araç kullanıyor: execute_code. Ajan, belirli fonksiyonları çağırmak yerine veri almak için JavaScript yazıyor.

Kağıt üzerinde bu yöntem kazanıyor. Karmaşık görevler için kod yürütme, verimlilik açısından araç çağırmayı (tool-calling) geride bırakıyor.

Ancak bunu benimsemedik. Bunun yerine ayrı, isimlendirilmiş araçlarımızı kullanmaya devam ettik.

İşte bariz görünen seçimin ajanımız için neden yanlış seçim olduğunun nedeni.

Hedef, Tasarımı Belirler

Çoğu insan, bir sohbet penceresindeki frontier modeller için geliştirme yapar. Bu modellerin devasa token bütçeleri vardır. Onlar için kod yürütme kraldır.

Biz ise bir teknede, küçük bir yerel model (Hermes 3 8B) üzerinde çalışan, önceliği ses olan (voice-first) bir ajan için geliştirme yapıyoruz.

Küçük bir model için kısıtlama tokenlar değildir. Kısıtlama güvenilirliktir.

Eğer küçük bir model basit bir aracı çağırmakta zorlanıyorsa, ondan doğru JavaScript yazmasını istemek çok daha zor bir görevdir. execute_code, güvenilirlikten feragat ederek token tasarrufu sağlar. Biz bu takası göze alamayız.

Son Aşama Problemi

Kod yürütme, işin "son aşamasını" ajana yükler. Ajan şunları yapmalıdır:

  • Veriyi filtrelemek
  • Sonuçları sıralamak
  • Çıktıyı formatlamak

Araçlarımız bu işi sunucu içinde yapar. Örneğin, pil durumu sorulduğunda, aracımız metinden sese (text-to-speech) hazır bir dize döndürür. Ham sayılar yerine "yüzde 68, 12,8 volt" der.

Eğer execute_code kullanırsak, ajan bu konuşmayı formatlayacak mantığı yazmak zorunda kalır. Küçük modeller bu konuda sürekli başarısız olur.

Yokluk Kuralı

Bir teknede sensörler çevrimdışı kalabilir. Bizim sistemimizde, eksik bir sensör temiz bir null döndürür. Bu, başarılı bir çağrıdır.

Kod yürütme modelinde, eksik bir sensör genellikle bir hata fırlatır. Eğer küçük bir model birkaç yanlış yol tahmin ederse, hata limitlerini tetikler ve ajanı bozar. İsimlendirilmiş araçlar, yokluğu bir hata değil, bir başarı olarak kabul etmemize olanak tanır.

Benimseme vs. İnşa Etme Kontrol Listesi

Bir MCP sunucusunu benimsemeden veya inşa etmeden önce şu soruları sorun:

• Hedef ajan kim? (Frontier model vs. Küçük yerel model) • Temel kısıtlama nedir? (Tokenlar vs. Güvenilirlik) • Son aşamayı kim yapar? (Veriyi araç mı formatlar yoksa ajan mı?) • Yokluğu nasıl yönetir? (Eksik bir değer hata mıdır yoksa bir null mı?) • Bakım maliyeti nedir? (Atıl bir kod tabanını mı devralıyorsunuz?)

Diğer projeyi görmezden gelmedik. Fikirlerinden yararlandık. Onların alarm yönetimi ve yol keşfi mantığını aldık ve yol haritamıza ekledik.

Verimlilik harikadır, ancak suyun üzerindeyken güvenilirlik bir zorunluluktur.

Kaynak: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

İsteğe bağlı öğrenme topluluğu: https://t.me/GyaanSetuAi