Gemento: Küçük yerel LLM’lerin uzun görevlerini harici durum, araçlar, roller ve döngülerle güçlendirmeyi deneyen bir deney düzeneği

Merhaba.

Küçük yerel LLM’lerin uzun görevleri ne kadar sürdürebildiğini denemek için bir depo paylaştım.

Gemento
https://github.com/hang-in/gemento

Bu proje yeni bir model mimarisi değil, bir makale değil ve 4B modelin frontier modellerin yerini alacağını iddia etmiyor.

Daha çok, “modelin içinde olması gerektiğini düşündüğümüz şeylerin bir kısmını iş akışının dışına çıkarırsak, küçük modellerde performans bir ölçüde geri gelir mi?” sorusunu yeniden üretilebilir biçimde ölçmeye yarayan bir deney düzeneğine yakın.

Başlangıç noktası, seCall ve tunaFlow’u geliştirirken tekrar tekrar karşılaştığım problemlerdi.

• Uzun görevler oturumlar arasında hayatta kalmıyor
• Bağlam çok hızlı biçimde pahalı hale geliyor
• Model kendi hatalarını kendi başına iyi fark edemiyor
• Küçük yerel modellerde tek seferlik çıkarımın sınırları belirgin

Bu yüzden basit bir soruyla başladım.

Prompt bağlamını sürekli büyütmek yerine, bellek, durum, doğrulama, hesaplama ve döngü kontrolünü dışarı çıkarırsak ne olur?

Gemento’da bunu dört eksene ayırdım.

1. Tattoo
   Çalışma belleğini / ara durumu yapılandırılmış JSON durumu olarak dışsallaştırma

2. Tools
   Hesaplamayı fonksiyon çağrısı tabanlı araçlara dışsallaştırma

3. Role
   Öz denetimi Proposer / Critic / Judge rol ayrımıyla dışsallaştırma

4. Orchestrator
   Bitiş koşullarını ve yineleme kontrolünü Python döngüsüne dışsallaştırma

İsim, Memento filmindeki dövme, Polaroid ve not metaforundan geliyor.

Şimdiye kadar ağırlıklı olarak Gemma 4 E4B kullandım; bu, etkin olarak 4B sınıfı bir yerel model.

Örneklem sayısı hâlâ küçük ve bazı sonuçlar istatistiksel olarak anlamlı değil. Bu yüzden README’de supported / conditionally supported / inconclusive / rejected ayrımını özellikle belirttim.

Dikkat çeken sonuçlar kabaca şunlardı.

• Tek seferlik çıkarıma kıyasla çoklu döngü belirgin biçimde daha iyiydi.
  Exp02: 50% → 94.4%
  Exp10: 1-loop 41.3% → 8-loop ABC 78.1%

• Aynı modele “yanlış olup olmadığını kontrol et” demek neredeyse tamamen başarısız oldu.
  Exp03: yerleştirilmiş 15 hatanın 0’ı tespit edildi

• Buna karşılık, rolleri ayırınca hata tespiti ciddi biçimde iyileşti.
  Exp035: 15 hatanın 12’si tespit edildi, %80

• Matematik hesaplamalarında araçlara dışsallaştırmanın etkisi açıktı.
  Exp08 / Exp08b’de tool call ve error hint zorlandığında, belirli bir matematik görevi %0’dan %100’e kadar toparlandı.

• Uzun bağlamlı görevlerde basit dump yerine chunked ABC+Tattoo güçlü çıktı.
  Exp09 Large 20K koşulunda Solo %0, RAG %67, ABC+Tattoo %100
  Ancak ABC+Tattoo’nun RAG’den genel olarak daha iyi olduğu sonucuna henüz varmadım. H9b inconclusive.

• Güçlü bir modeli Judge olarak eklemek ise tersine başarısız oldu.
  Exp11’de yalnızca Judge’ı Gemini 2.5 Flash ile değiştirdim ama mixed condition, baseline all-Gemma’dan daha düşük çıktı.
  Gözlenen mekanizma şu yöndeydi: “güçlü bir Judge, zayıf modelin kendi kendine keşif sürecine yardım etmek yerine, ara durum şemasını ve sonuca yakınsamayı bozabiliyor.”

• Buna karşılık, baş tarafa Extractor rolü eklemek küçük ama olumlu bir etki gösterdi.
  Exp12: Δ +0.050
  Özellikle bazı katastrofik vakalarda toparlanma görüldü.

• Son taraftaki Reducer rolü ise tersine kötüydü.
  Exp13: Δ -0.053
  Nihai cevabı “daha temiz düzenleme” sürecinde, gerekçe yapısının sıkışması nedeniyle puanı düşüren bir abstraction loss gözlendi.

Bu nedenle şu anki yorumum şöyle.

Küçük bir modeli mutlaka daha güçlü bir modelle yargılatmaktan ziyade, aynı modelde bile rolleri nereye yerleştirdiğiniz daha önemli olabilir.

Özellikle pre-stage rol eklemek görece güvenliydi; post-stage özetleme/düzenleme ise riskliydi.

Bu projede henüz iddia etmediğim şeyleri de açıkça yazdım.

• 4B modelin büyük modellerin yerini alacağı iddiası değil
• ABC+Tattoo’nun RAG’den her zaman daha iyi olduğu iddiası değil
• Yeni bir mimari ya da eğitim yöntemi değil
• Makale düzeyinde istatistiksel testlerin tamamlandığı iddiası değil
• Related work’ün bir kısmında bibliographic verification henüz tamamlanmış değil

Şu anda daha çok “açık deney notları” niteliğinde.

Tek başına yapılan deneylerde yanılsama oluşması kolaydır. Özellikle böyle yapısal deneylerde, sonuçların taskset, scorer, prompt ve loop koşullarına göre kolayca oynayabileceğini düşünüyorum.

Bu yüzden polished paper olmadan önce yayımladım.

İstediğim geri bildirim kabaca şu alanlarda.

• Başka yerel modellerde yeniden üretilebiliyor mu
• taskset / scorer taraflı mı
• RAG baseline yeterince adil mi
• ABC+Tattoo gerçekten farklı hata modları mı gösteriyor
• Search Tool / Graph Tool / Evidence Tool eklenirse Tool ekseninde daha net bir etki görülür mü

Sıradaki aday deney Exp14 Search Tool.

İlgileniyorsanız README ya da docs/reference tarafına bakabilirsiniz.

Karşı örnekler, yeniden üretim başarısızlıkları ve eleştirilerin hepsi memnuniyetle karşılanır.