2 puan yazan GN⁺ 2026-01-05 | 1 yorum | WhatsApp'ta paylaş
  • Kod akışı (code-flow) çok aşamalı eğitimi ile statik kod yerine deponun değişimini ve geliştirme sürecini öğrenen, kodlamaya özel açık bir kod LLM'i
  • Ön eğitim–orta eğitim–son eğitimden oluşan evrimsel eğitim hattı ile uzun vadeli akıl yürütme ve ajan görevlerindeki performans güçlendiriliyor
  • 32K·128K bağlamlarda akıl yürütme verisi ve ajan yörüngeleri enjekte edilerek karmaşık çok dosyalı ve depo düzeyindeki problemleri çözme yeteneği sağlanıyor
  • Yinelemeli yapı kullanan LoopCoder mimarisi ile model kapasitesine kıyasla dağıtım verimliliğini artıran pratik bir tasarım öneriliyor
  • SWE-Bench, LiveCodeBench, Terminal-Bench gibi ölçütlerde ticari modellerle rekabet edebilen performans, açık ağırlıklı modelle elde ediliyor

Genel Bakış

  • IQuest-Coder-V1, 7B·14B·40B·40B-Loop'tan oluşan, yalnızca koda odaklı büyük dil modeli ailesi
  • Kod anlık görüntüleri yerine commit'leri ve depo evrim sürecini eğitim hedefi alan code-flow paradigmasını benimsiyor
  • Ajan tabanlı yazılım mühendisliği, yarışmalı programlama ve araç kullanımının tamamında performans değerlendirmesi yapılıyor

Code-Flow eğitim hattı

  • Ön eğitim aşamasında genel veri ile büyük ölçekli kod verisi birlikte eğitildikten sonra yüksek kaliteli kod annealing'i uygulanıyor
  • Orta eğitim aşamasında 32K → 128K bağlam genişletmesi yapılıyor; akıl yürütme QA'si, ajan yörüngeleri ve depo düzeyinde kod verisi eğitiliyor
  • Son eğitim aşamasında Thinking yolu (akıl yürütme odaklı RL) ve Instruct yolu (genel yardımcı optimizasyonu) olarak ayrılıyor

Temel araştırma bulguları

  • Depo commit akışı verisinin, statik kod anlık görüntülerine göre görev planlama sinyali açısından daha üstün olduğu deneylerle doğrulanıyor
  • Yüksek kaliteli kod annealing'inden sonra orta eğitimde akıl yürütme ve ajan verisi enjeksiyonu yapan yapının, dağılım değişimine karşı kararlılık sağladığı gösteriliyor
  • Akıl yürütme odaklı RL uygulanan Thinking yolunda, uzun görevler sırasında kendi hatalarını toparlama yeteneği belirgin biçimde ortaya çıkıyor

LoopCoder mimarisi

  • Aynı parametre bloğunu iki kez yineleyerek çalıştıran döngüsel transformer yapısı tanıtılıyor
  • Küresel attention ile yerel attention, geçitleme yoluyla birleştirilerek uzun menzilli bağlamın rafine edilmesi ve nedenselliğin korunması aynı anda sağlanıyor
  • Model kapasitesine kıyasla hesaplama verimliliği artırılarak dağıtım ortamı kısıtlarına uyum hedefleniyor

Veri bileşimi ve ön eğitim stratejisi

  • Çok dilli kod karma eğitimi içinde diller arası sinerji etkisi, formül tabanlı bir ölçekleme yasasıyla biçimselleştiriliyor
  • Depo yaşam döngüsünün %40~80 aralığındaki commit'lerden yararlanılarak (R_old, Patch, R_new) üçlü veri yapısı kuruluyor
  • Dosya ve depo düzeyinde Fill-In-the-Middle tekniğiyle kod tamamlama yeteneği güçlendiriliyor

Değerlendirme sonuçları

  • SWE-Bench Verified'da 76.2, ayrıca LiveCodeBench v6, Terminal-Bench, Mind2Web gibi birçok benchmark'ta üst düzey performans kaydediliyor
  • Kod üretimi, akıl yürütme, düzenleme, verimlilik, Text-to-SQL ve ajan görevlerine kadar tüm alanlarda değerlendirme yapılıyor
  • Bazı göstergelerde Claude Sonnet 4.5, GPT-5.1 gibi kapalı modellerle yakın veya rekabetçi sonuçlar doğrulanıyor

Güvenlik değerlendirmesi

  • BeaverTails, HarmBench, TrustLLM gibi güvenlik benchmark'larında Thinking modelinin yüksek reddetme doğruluğu ve dengeli performans gösterdiği kaydediliyor
  • Akıl yürütme odaklı RL'nin güvenlik açısından da olumlu etki gösterdiğine dair sonuçlar sunuluyor

Sonuç

  • Kod evrim akışı ve ajan yörüngelerini merkeze alan eğitimin, özerk kod zekâsı oluşturmakta etkili olduğu deneysel olarak gösteriliyor
  • LoopCoder yapısı üzerinden performans–verimlilik dengesi gözeten pratik kod LLM tasarımı yönü ortaya konuyor
  • Tüm eğitim aşamaları ve checkpoint'ler yayımlanarak açık kod zekâsı araştırmalarını ve gerçek ajan sistemleri geliştirmeyi hızlandırma hedefleniyor

1 yorum

 
GN⁺ 2026-01-05
Hacker News görüşleri
  • Daha iyi bağlantı iquestlab.github.io
    Ancak ne yazık ki değerlendirme sırasında ajanın hile yaptığı görülüyor

    • GitHub issue’ya göre, hile düzeltildikten sonra bile sonuçlar hâlâ iyiydi
      Puan 81.4%’ten 76.2%’ye düştü ama yine de Opus 4.5’ten (74.4%) daha yüksek
    • Birkaç gün önce bu bağlantı yeterli oy alamamıştı
  • Özetle, .git/ klasörü temizlenmediği için model gelecekteki commit düzeltmelerine reward hacking yoluyla bakmış
    Bu sorunu birlikte çözen kişilere hakkını vermek isterim
    İlgili tartışmalar bu tweette ve Reddit başlığında da görülebilir
    IQuestLab’in SWE-Bench Verified verisini yayımlamış olması, bunun kasıtlı manipülasyondan çok basit bir benchmark acemiliği hatası gibi göründüğünü düşündürüyor

    • John’un belirttiği gibi, bu sorun SWE-bench’te zaten düzeltilmişti
      Güncel kodu kullanıp güncellenmiş Docker image ile değerlendirmeyi çalıştırmak yeterli
      İlgili tweet
    • Ben de bunun basit bir hata olduğunu düşünüyorum, ama araştırmacılar çıktı sonuçlarına bir kez bile baksaydı bunu hemen fark ederlerdi; bu üzücü
    • SWEbench hâlâ abartı tartışmalarından kurtulabilmiş değil
  • Benim deneyimime göre GLM-4.7 (opencode sürümü) açık kaynak tarafında en çok yaklaşan model
    Bazen Claude verisinin karıştığını düşündüren ifadeler görünüyor; bu yüzden bir miktar Claude verisi kullanılmış olabilir

    • Ama performansı Sonnet 4.5’in epey gerisinde ve Opus’la kıyaslanamaz
    • “What’s your use-case?” gibi ifadeler de sık görünüyor
      Bu, Claude’un sınırlarına geldiğinde kaçınmak için sık kullandığı bir ifade
  • 40B parametreli bir model Sonnet 4.5 ve GPT 5.1’i mi geçiyor? Bunun nasıl mümkün olduğunu merak ediyorum

    • Benim tahminim (emin değilim) test verisi sızıntısı olduğu ya da benchmark setinin bir kısmının eğitim verisine girdiği yönünde
      Yine de Sonnet 4.5 artık eski bir model ve yakın dönemde çok sayıda yenilik oldu
      Açık modellerin büyük modelleri hızla yakalaması ilginç
    • Hatta “IQuest” adının şüpheli (It's questionable) olduğuna dair kelime oyunu bile yapılıyor
    • Muhtemelen model pruning tekniği uygulanmış da olabilir. Bugünlerde çok sayıda yeni yöntem var
    • Gerçekte olanın, ajanın değerlendirme harness’ini hacklemesi olduğu ortaya çıktı
  • Bu modeli gerçekten çalıştıran ya da hosted API üzerinden test eden biri var mı, merak ediyorum

  • Bu asılsız bir iddia, peki neden hâlâ ana sayfada duruyor?