Forge - Guardrail'lerle 8B modeli ajan görevlerinde %53'ten %99'a çıkaran araç

• Forge, kendi barındırılan LLM'lerde araç çağırma için bir güvenilirlik katmanıdır; çok adımlı ajan iş akışlarında küçük yerel modellerin kararlılığını artırmaya odaklanır
• Temel özellikleri; hatalı araç çağrılarını kurtaran rescue parsing, yeniden deneme yönlendirmesi, zorunlu adım dayatma, VRAM farkındalıklı token bütçesi ve hiyerarşik bağlam sıkıştırmadan oluşur
• Şu anda en güçlü kendi barındırılan yapılandırma olan Ministral-3 8B Instruct Q8 on llama-server, 26 değerlendirme senaryosunda %86,5 ve en zor kademede %76 elde ediyor
• Kullanım üç şekilde mümkün: tüm ajan döngüsünü WorkflowRunner ile devralmak, mevcut orkestrasyon döngüsüne Guardrails middleware eklemek veya OpenAI uyumlu bir proxy sunucusuyla şeffaf biçimde uygulamak
• WorkflowRunner; sistem prompt'unu, araç yürütmeyi, bağlam sıkıştırmayı ve guardrail'leri yönetirken, SlotWorker paylaşımlı GPU çıkarım yuvalarına öncelik kuyruğu ve otomatik ön alma özellikleri ekler
• Proxy sunucusu python -m forge.proxy ile çalıştırılır ve opencode, Continue, aider gibi OpenAI uyumlu istemciler ile yerel model sunucusu arasına girerek guardrail uygular
• Proxy, araç içeren isteklere sentetik respond aracını otomatik olarak enjekte ederek modelin düz metin yerine respond(message="...") çağırmasını sağlar; yanıtta ise bunu kaldırarak istemci tarafında normal metin yanıtı gibi görünmesini sağlar
• Desteklenen backend'ler Ollama, llama-server (llama.cpp), Llamafile ve Anthropic'tir; llama-server en yüksek performans ve kontrolü, Ollama kolay kurulumu, Llamafile tek ikili dosyayla çalıştırmayı, Anthropic ise frontier temel çizgisi ve hibrit iş akışlarını sağlar
• Kurulum pip install forge-guardrails ile yapılabilir; Anthropic istemcisi pip install "forge-guardrails[anthropic]" ile eklenir ve gereksinimler Python 3.12+ ile çalışan bir LLM backend'idir
• Değerlendirme harness'i, model ve backend kombinasyonlarının çok adımlı araç çağırma kararlılığını 26 senaryoda ölçer; OG-18 tabanlı kademeler ve 8 adet advanced_reasoning kademesine ayrılır
• Test yapılandırması, LLM backend'i gerektirmeyen 865 deterministik birim testi ile gerçek backend'ler üzerinde çalışan değerlendirme harness'ini içerir
• Forge guardrail çerçevesi ve ablation study, Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling adıyla yayımlandı ve lisansı MIT'tir

[GN⁺]

Hacker News yorumları

• Bu alandaki işleri seviyorum ve faydalı buluyorum, ancak bulut tabanlı LLM’lerden kaçınıp çoğunlukla 4B~30A3B parametreli yerel modeller kullanıyorum
  Bu yüzden en yeni LLM performansı ya da doğruluk hissiyatım eksik olabilir, ama yerel modellerden ne beklenebileceğini ve darboğazların ne olduğunu iyi bildiğimi düşünüyorum
  Yazıya hızlıca göz gezdirip özeti okudum; basit ayarlarla 10 kat hızlanma ya da yavaşlama olabileceğine dair ifadeler var ama metrikler ve veriler neredeyse sadece doğruluk üzerine odaklanmış gibi görünüyor. Hızın da ele alınması gerekiyor
  Özellikle ajan tipi iş akışlarında ve yerel modellerde, fonksiyon/araç çağırma doğruluğu benim açımdan QwenCoder3 civarından beri son 6~12 aydır büyük bir sorun olmadı; asıl mesele bağlam yönetimi ve zaman etkisi. Ajan istemi sık sık değiştirirse, prompt caching gibi zaman optimizasyonları bozuluyor
  Buraya guardrail ve yeniden deneme gibi katmanlar ve wrapper’lar da ekleniyor gibi görünüyor; bu da yerel modellerde, özellikle ajan kullanımında, gecikme yüzünden kullanılamaz seviyeye gelebilir
  Bunu zaten doğrudan ele aldıysanız kusura bakmayın ama zaman etkisinden çok az bahsedilmesi, gerçek iyileşme miktarını gizliyormuş ya da abartıyormuş gibi hissettiriyor. Hız deneyimini duymak isterim. Başkalarının bunu gündeme getirmemesi de biraz endişe verici; ben mi bir şeyi yanlış yapıyorum yoksa kimse yerel modelleri gerçekten kullanmıyor mu diye düşündürüyor

• Düzgün bir harness varsa küçük yerel modellerin bile şaşırtıcı derecede iyi iş çıkarabildiğini hep söylüyorum
  Her şeyi deneyebilen bir sistemse, arada yanlış sonuç üretmesini engelleyebilirseniz sonunda doğruya ulaşabilir

  • Sorun, bir junior’a sınırsız zaman verip hedefe ulaşana kadar farklı yöntemleri denemeye devam etmesini söyleyince ortaya çıkan kaliteye benzer sonuçlar vermesi
    İş yeterince karmaşıksa en yeni modellerde de bu sorun var, küçük modellerde ise daha da büyüyor
  • Bu çerçeveleme hoşuma gitti. Bu işle uğraşırken küçük modeller oldukça etkileyiciydi
    Muhakeme de oldukça iyi ve çoğu durumda yeterli. Bazen sadece yeniden doğru yola itmek yetiyor, gerisini kendi çözüyorlar
  • Doğru anladıysam, modelin doğruyu bulabilmesinin sebebi ne zaman yanlış yaptığını bilmesi

• Zaman ayırıp yapmak istediğim şeyi çok daha iyi yapmış olmanıza sevindim. Bir sorum var: örneğin yeniden deneme döngüsü içinde paralelleştirme fırsatı var mı?
  Yerel modeller genelde tüketici donanımında bile sınırlı sayıda, kabaca iki haneli eşzamanlı isteği oldukça iyi kaldırabiliyor ve bu durumda efektif token/saniye 10 katın üzerine çıkabiliyor
  Bir süredir bundan faydalanan iş akışları düşünüyorum ve “bu hatayı düzelt” yaklaşımı mükemmel olmasa da uygulanabilecek bir yer gibi görünüyor. Siz nasıl görüyorsunuz merak ettim

• Bu alanda birkaç fikrim var, onları kendi harness’ime ekliyorum. Harness’im oldukça özelleşmiş olduğu için genellenebilir mi emin değilim
  Problemi planlanmış yürütmelere bölüyorum ve yürütme ajanına, hangi araçları çağıracağı ve başarılı yürütmenin ölçütünün ne olduğu gibi açık hedefleri içeren bir başlangıç planı veriyorum. Harness bu planı sırayla çalıştırıyor
  Araç çağrısı içeren her adımda, araç çağrısını bileşenlerine ayırıyorum. Harness, ajan’a mevcut araç argümanı için geçerli parametre değerlerini soruyor ve araç tanımında her argüman için doğrulayıcılar bulunuyor. Doğrulama başarısız olursa harness konuşmayı geri sarıyor ve başarısızlık nedenini bir sonraki denemeye enjekte ediyor
  Argüman için geçerli bir yanıt gelirse sonraki argümana geçiliyor ve tüm argümanlar dolunca araç çağrılıyor. Ajanın ilk beklentileriyle gerçek değerler ve oluşan hatalar birlikte verilip sonuçtan memnun olup olmadığı soruluyor
  Memnun değilse ajan gerekçesini sunuyor, harness de konuşmayı geri sarıp yeniden deneme nedenini ekledikten sonra araç çağırma sürecini baştan başlatıyor
  Ajan başlangıç planındaki kusurları fark ederse yeniden planlama isteyebiliyor, harness de art arda çok fazla başarısızlık olursa yeniden planlamayı deniyor
  Bu yöntem araç çağırma hatalarını azaltmada oldukça etkili. Avantajlarından biri, alt ajanların hatasız ve tertemiz bir konuşma geçmişi alması. Ama gerçek görev tamamlama oranının daha iyi olup olmadığını henüz benchmark etmedim

  • Küçük model tabanlı ajan tipi bir kodlama harness’inde benzer bir felsefeyle deneyler yaptım ve bunu forge üzerine kurdum
    Konuşmayı geri sarma tarafında, ana ajan yani kullanıcıyla konuşan ajan için benzer bir araç çağrısı katlama uyguladım. İş bitince araç çağrısı geçmişini katlayıp bağlamı temiz tuttum; bu daha çok boyuttan ziyade hijyenle ilgiliydi
    Harness’in modeli sıkıştırarak sorguladığı kısım biraz farklı ve o yaklaşımı denemedim. Forge, özel hata modlarından kaçınmak için modelin kendi kendini düzeltmesine dayanıyor ama şema gibi şeylere dayanarak soru sorma süreci soyutlanıp otomatikleştirilebilirse mümkün görünüyor
    Genel olarak temiz bir konuşma geçmişi fikrini seviyorum ama çok sayıda argümanı olan araçlarda, “önce bırak başarısız olsun sonra bir kez dürt” yaklaşımına kıyasla çok daha fazla gidip gelme olabilir gibi duruyor. Yine de daha zor senaryolar ve görevler için ilginç bir fikir
  • Strix Halo kullanıyorum ve uzun bağlamda yavaş olduğu için ben de aynı yaklaşımı düşünmüştüm. Bu yöntemle 10 bin tokenın altında bağlam korunabilir gibi görünüyor
    Küçük modellerle 50k token/saniyenin üzerine çıkılabiliyorsa bu oldukça büyük olur
    Ama şu anda iş ve başka projeler yüzünden yoğunum, bu yüzden uygulanabilir mi diye sadece birkaç düzine prompt denedim
  • Meraktan gemma4 ile kendim bir şeyler yapıyorum ve düşündüğümden çok daha ileri gittiğini görmek şaşırttı

• Harika. Şu anda maliyet nedeniyle yerel çıkarım kullanamıyorum ama OpenRouter üzerinden küçük modeller kullanırken araç çağırma beni endişelendiriyordu
  pytest öncelikli argüman test çerçevesi Dokimasia’yı (do-kee-ma-see-ah) geliştiriyorum, görüşlerinizi duymak isterim: https://github.com/deevus/dokimasia
  Argüman testi Forge için gerekli olmayabilir ama AI araçlarını derinlemesine geliştirdiğiniz için bir fikriniz olabileceğini düşündüm

  • İlginç bir fikir. Özünde AI ekosistemindeki farklı entegrasyon türlerini, örneğin MCP ya da skills gibi şeyleri test etmeye yönelik bir soyutlama katmanını resmileştiriyor gibi görünüyor
    Sanki Forge’un bir katman üzerinde duruyor ve daha çok gerçek iş akışlarını ve bunların içinden görünen entegrasyon noktalarını, örneğin hangi aracın MCP erişimi sunduğunu, test etmeye yakın
    İkisini birlikte üst üste kullanmak da büyük bir sorun gibi görünmüyor
    Merak ettiğim şey, bu modellerin deterministik olmama durumunu nasıl ele aldığınız. Bazen araç çağrısını doğru yapıyorlar, bazen bozuk JSON üretiyorlar. Test paketi birden fazla deneme yapıyor mu?

• Araç çağırmadaki belirsizliği frontier ölçekli modellerde de yaşıyorum. Claude Code, Codex ve Gemini CLI’yi her gün geliştirmede paralel kullanıyorum; en yaygın hata modu grep/find’in çıkış kodu 1, yani eşleşme yok ile bitmesi
  Model bunu “arama çalıştı ve bir şey bulunamadı” diye değil “araç başarısız oldu” diye okuyup ya vazgeçiyor ya da aramayı genişletmek yerine sözdizimini hafifçe değiştirip tekrar deniyor
  yeniden deneme-dürtme katmanı, benim saatte birkaç kez elle yaptığım şeyle neredeyse bire bir örtüşüyor. “Hayır, araç başarısız olmadı; o dosyada o desen yok. X’i dene” demek gibi
  Bunu framework seviyesinde kodlamak doğru yön gibi görünüyor
  Bu tür guardrail’lerin, uzun görevlerde küçük frontier modellerle aradaki farkı azaltıp azaltmadığını gördünüz mü merak ediyorum. İçgüdüm, Sonnet’teki 87→99 farkının yaklaşık 50 adımı geçince olduğu gibi kalmayacağı yönünde. Ondan sonra yeniden deneme semantiğinden çok bağlam sürüklenmesi baskın hale geliyor

  • En azından büyük frontier modellerde kesinlikle orada öndeler. Ama zaman kısıtı nedeniyle o sonucu resmileştirmedim
    Gerekli ipucu olarak, forge teknik olarak model kalitesinden çok araç çağırma yürütmesiyle ilgileniyor. Asıl yanıt şu
    14B sınıfı küçük modellerde sınırlayıcı etken etkili dikkat idi. Eğitimdeki bağlam penceresinin boyutuna rahatça sığsa bile belli bir noktadan sonra performans düşüşü görünmeye başlıyordu. Elimde kesin sayılar yok ama Opus gibi modeller o noktadan sonra çok daha uzun süre dayanabiliyor
    Bir gün doğrudan forge’da da kullanabileceğim, araç çağırma mesaj geçmişini katlama özelliği de geliştirdim. Özünde mesaj geçmişini akıllıca toparlayarak modelin takibi daha az kaybetmesini sağlıyor
    Yine de ajan tipi kodlama harness’inin kodlama değerlendirme paketinde refactoring görevleri ve özellik ekleme görevleri var ve hepsi gerçek sandbox depolarında yapılıyor. Küçük modeller bile 50~60 araç çağrısı boyunca zorlayınca bu tür işleri başarabiliyor. Ama aynı oturum içinde onlara bundan iki tane birden vermezdim

• Konudan biraz farklı ama Texas Instruments’ta biriyseniz, TI Explorer Lisp makinesinin fikri mülkiyet durumunun ne olduğunu öğrenme şansınız olur mu diye merak ediyorum
  Genera’nın fikri mülkiyet haklarının kimde olduğunu biliyorum ama TI’nin Lisp OS’i konusunda bunu öğrenemedim

  • Genera’nın fikri mülkiyet hakları kimde?

• “Ajan güvenliği” yığınını daha geniş düşünenler için bu yön, Kontext’in kontext-cli’si (github.com/kontext-dev/kontext-cli) ya da OneCLI (github.com/onecli/onecli) gibi şeylerle tamamlayıcı hissettiriyor

• “Aynı Mistral-Nemo 12B ağırlıkları llama-server’ın yerel fonksiyon çağrısında %7 doğruluk verirken, Llamafile’ın prompt modunda %83 veriyor” kısmı var
  Ben Llamafile’ı sadece model ile llama.cpp’nin tek bir binary’de paketlenmiş hâli sanıyordum; bu fark, Llamafile’ın varsayılan sistem prompt’u enjekte etmesiyle ham llama-server endpoint’ini harness olmadan çağırmak arasındaki fark mı?
  Bu bana elma ile elmalı turtayı karşılaştırmak gibi geliyor ve aradaki malzemeler eksik

  • Ben de şaşırdım. Yazı, uç ama gerçek bir örnek veriyordu. Bu durumda yerel fonksiyon çağırma şablonunun çalışmış olması muhtemel
    Ama bu tek başına Lamaserver prompt’u ile llamafile arasındaki yaklaşık +4 yüzde puan farkı ya da llamaserver yerel ile llamafile’ın neredeyse ortasında duran Ollama’nın yaklaşık +30 yüzde puan farkını açıklamıyor
    sunum backend’i neredeyse tüm model ailelerini etkiledi ve bu kısmın gerçekte neredeyse hiç konuşulmadığını gördüm

• Bu gerçekten harika bir yön. 1 bitlik bonsai modellerinde bile absürt derecede iyi sonuçlar alınıyor ve lmstudio ile de iyi çalışıyor
  Artık elde kalan bir makineye 7900XTX takıp bodruma koymak, ona saçma hedefler verip sonra unutmak tamamen gerçekçi bir şey haline geldi