Daha İyi Modeller, Daha Kötü Araçlar

 (lucumr.pocoo.org)
1 puan yazan GN⁺ 6 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Pi’nin edit aracında Claude Opus 4.8 ve Sonnet 5, edits[] içine şemada olmayan alanlar eklediği için çağrıları reddedildi; en yeni modellerin belirli araç şemalarını önceki modellere göre daha kötü izlediği gözlemlendi
  • Araç çağrısı, modelin özel işaretleyiciler ve JSON biçiminde metin üretmesi süreci olduğundan, kısıtsız örneklemede öğrenilmiş teamüller şemanın önüne geçebiliyor
  • Başarısız örneklerde oldText ve newText doğru olmasına rağmen requireUnique, oldText2, matchCase, in_file gibi sahte anahtarlar eklendi; yeniden üretilebilirlik, ajan geçmişine ve thinking block içerip içermemesine göre değişti
  • Claude Code kapalı bir harness olsa da yanlış çağrıları yeniden deneme, parametre takma adları, tip düzeltme, Unicode onarma, bilinmeyen anahtarları filtreleme gibi pek çok gevşek düzeltme yapıyor ve strict modunu kullanmıyor
  • Anthropic’in strict araç çağrısı bu sorunu ortadan kaldırdı; model performansı arttıkça alternatif araç şemaları dezavantajlı hale gelebiliyorsa, harness tarafında sözdizimsel kısıtlar gibi daha güçlü güvencelere ihtiyaç var

Pi edit aracında görülen gerileme

  • Pi issue takip edilirken, en yeni Claude modellerinin Pi’nin edit aracını çağırırken edits[] dizisi içine var olmayan alanlar eklediği bir sorun bulundu
  • Bu durum küçük bir modelde değil, Opus 4.8’de ortaya çıktı; Sonnet 5’te de aynı davranış doğrulandı
  • Önceki Anthropic modellerinde aynı sorun görülmediği için, en yeni yüksek performanslı modeller bu belirli araç şemasında tersine daha kötü çalışıyor
  • Fable, sınıflandırıcının isteği sessizce Opus’a düşürme ihtimali nedeniyle test edilmedi

Araç çağrısı metin üretimine daha yakın

  • LLM araç çağrıları, modelin konuşma geçmişi, sistem prompt’u ve kullanılabilir araç listesini aldıktan sonra özel işaretleyiciler içeren büyük bir prompt içinde çağrı biçimini üretmesiyle çalışır
  • Dosya düzenleme aracının amaçlanan argümanları aşağıdaki gibi path ve edits dizisini içerebilir
{
  "path": "some/file.py",
  "edits": [
    {
      "oldText": "text to replace",
      "newText": "replacement text"
    }
  ]
}
  • Harness argümanları doğrular ve düzenlemeyi uygular; ardından sonucu tekrar modele verir, doğrulama başarısız olursa model hatayı görür ve genelde yeniden dener
  • Anthropic modellerinin iç biçimi açık değildir, ancak ANTML işaretleyicileri sızmış ya da kamuya açık iletişimlerde görünmüştür
  • Bu biçim XML’e benzer görünse de gerçek XML’den çok, tokenizasyon ve eğitim için uygun bir in-band sinyal gibidir
    • En üst düzey string parametreleri satır içinde yer alabilir
    • Nesne dizileri ise JSON serileştirme biçiminde giriyor gibi görünür

Kısıtsız üretim ve sözdizimsel kısıtlı üretim

  • Modelin yapılandırılmış çıktı üretmesinin temel olarak iki yolu vardır
    • Modelden şemaya uygun JSON üretmesi istenir ve sonradan doğrulanır
    • Örnekleyici, en baştan hatalı JSON ya da şema dışı biçimlerin örneklenmesini engeller
  • İkinci yaklaşım grammar-aware decoding ya da kısıtlı decoding olarak adlandırılır; grameri ihlal eden token’lar maskelenir
  • Şema yalnızca oldText ve newText alanlarına izin veriyorsa, örnekleyici "in_file" ya da "type" gibi anahtarların üretilmesini engelleyebilir
  • Böyle bir kısıt yoksa model, soyut sözleşmeyi sıkı biçimde izlemekten çok öğrendiği teamüllere göre üretim yapar

Gerçek başarısızlık kalıpları

  • Pi’nin edit aracı, tek çağrıda birden fazla tam string değiştirmeyi desteklediği için edits dizisini kullanır
  • Başarısız çağrılarda aşağıdaki gibi izin verilmeyen alanlar eklendi
{
  "oldText": "...",
  "newText": "...",
  "requireUnique": true
}

{
  "oldText": "...",
  "newText": "...",
  "oldText2": "",
  "newText2": ""
}
  • Tekrarlı deneylerde görülen sahte anahtarlar arasında type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2, event.0.additionalProperties gibi çok sayıda örnek vardı
  • Doğrulanan hatalı çağrılarda gerçek oldText ve newText payload’u bayt düzeyinde doğruydu, ancak nesnenin sonuna anlamsız anahtarlar eklendiği için çağrı reddedildi
  • Yeniden üretim büyük ölçüde bağlama bağlıydı
    • Yeni, tek turlu “edit this file” prompt’unda yeniden üretilemedi
    • Modelin dosyayı okuyup sorunu teşhis ettikten sonra çok satırlı düzenleme oluşturduğu ajan geçmişinde yeniden üretildi
    • Petr Baudis’in transcript’i olmadan yeniden üretilemedi
    • Aynı kullanıcı oturumu devam ettirildiğinde Opus 4.8 yaklaşık %20 olasılıkla başarısız oldu
    • Geçmişten thinking block çıkarıldığında hata oranı yarıya indi
    • strict araç çağrısı açıldığında o çalıştırmada sorun kayboldu

Neden daha kötü hale geldi?

  • En güçlü hipotez bunun rastgele bir performans düşüşü değil, eğitimin bir ürünü olduğu yönünde
  • Önceki Anthropic modelleri bazı araçlarla eğitilmişti, ancak Claude Code gibi kullanıcı tarafından sağlanan harness’lerin net bir hedef haline gelmesinden önceydi
  • En yeni Anthropic modelleri büyük olasılıkla Claude Code’u ya da ona çok benzeyen bir harness’i içeren sonradan eğitim aldı; bu ortamda başarılı araç çağrılarını ve tolere edilen hataları birlikte öğrenmiş olabilir
  • Claude Code’un edit aracı, Pi’nin iç içe edits[] yapısı yerine file_path, old_string, new_string ve isteğe bağlı replace_all alanlarına daha yakın düz bir yapı kullanır
  • Claude Code istemcisi, yanlış araç kullanımını yeniden deneme, parametre takma adları, tip zorlaması, Unicode onarma ve bilinmeyen anahtarları filtreleme gibi ciddi miktarda hata düzeltmesi yapar
  • Eğer reinforcement learning bu harness içinde ya da onun simülasyonunda gerçekleşiyorsa, biraz hatalı araç çağrıları bile işi tamamlayıp ödül alabilir
  • Başka bir harness aynı anlamdaki düzenleme aracını farklı bir şemayla sunduğunda, model açısından giderek dağılım dışı bir araca dönüşebilir
  • Opus 4.5’in çıktığı dönemde diğer edit araçlarına çok iyi uyum sağlıyordu, ancak şimdi gözlenen yön, alternatif araç şemalarının belirli hoşgörülü araç ekosistemlerinde dezavantajlı hale gelebileceğini gösteriyor
  • Belgelenmiş bir text editor tool var, ancak Claude Code bu biçimi birebir izlemiyor; Claude Code’un iç işleyişi kapalı kaynak bir harness olduğu için görülemiyor

Claude Code’un gevşek harness’i

  • Claude Code kapalı kaynak olsa da küçültülmüş kod incelendiğinde gelen veriye karşı oldukça hoşgörülü olduğu görülüyor
  • Modelin görünür metnine <invoke işaretlemesi sızıp sızmadığını kontrol ediyor; böyle bir durum varsa telemetry gönderiyor ve kendi durum makinesiyle hatalı çağrıyı yeniden deniyor
  • String değerler içindeki bozuk \uXXXX dizilerini ve lone surrogate’ları düzelten bir Unicode escape onarma mekanizması var
  • Araç bazında parametre takma adları da bulunuyor
    • Edit, old_str, old_string, new_str, new_string alanlarını kabul ediyor
    • path, file_path için takma ad olarak kabul ediliyor
  • Beklenmeyen anahtarlar sessizce filtreleniyor
  • strict modu kullanılmıyor
    • Anthropic, strict modunda araç tanımı karmaşıklığına sınır koyuyor ve bu yüzden API isteği başarısız olabiliyor
    • Claude Code’un strict modu denememesinin nedeni de bu gibi görünüyor

strict mod ve diğer ekosistemler

  • Hem Anthropic modelleri hem de harness kapalı olduğundan, aynı sorunun başka harness’lerde de sürüp sürmeyeceğini söylemek zor
  • Codex modelleri de kapalı, ancak harness kapalı değil
  • gpt-oss, OpenAI’nin harmony yanıt biçimini kullanmak üzere açıkça eğitildi ve OpenAI tarafının yaklaşımını gösteren çok sayıda belge bulunuyor
  • harmony, kanalları ve araç çağrısı içerik tiplerini prompt biçiminin bir parçası haline getiriyor; araç çağrısı gövdesinde <|constrain|>json gibi işaretleyiciler yer alabiliyor
<|start|>assistant<|channel|>commentary to=functions.get_weather
<|constrain|>json<|message|>{"location":"San Francisco"}<|call|>
  • <|constrain|>json, çıkarım yığınının araç çağrısı gövdesinde JSON kısıtlı örneklemeye geçeceği sınırı kolayca bulmasını sağlar
  • Barındırılan GPT modellerinde, kullanıcı araçlarının uyması gereken gramer için LARK grameri sağlama seçeneği de var
  • Anthropic de strict modunda benzer bir işlem yapıyor gibi görünüyor; ancak iç içe dizi parametrelerinde modelin, uzun çok satırlı dosya içeriğini string literal içinde escape edilmiş JSON olarak üretmesi gerekiyor
  • Sahte anahtarlar, yüzlerce token uzunluğundaki newText string’i kapandıktan hemen sonra modelin } ile , "..." arasında seçim yapmak zorunda kaldığı yüksek entropili noktada ortaya çıkıyor
  • Opus 4.8 ve Sonnet 5’in, edit aracı çağrı biçimine dair daha güçlü bir önsel dağılıma sahip olduğu ve bunun Claude Code’un düz edit şemasına daha yakın olduğu anlaşılıyor
  • Anthropic’in strict modunun sorunu çözmesi, sunucu tarafında JSON şeması yapısında izin verilmeyen anahtarların örneklenmesini reddetmesinden kaynaklanıyor olabilir
  • Test edilen Codex modellerinde bu tür bir gerileme görülmedi; erişim olmayan 5.6 hariç tutuldu

Harness tasarımına etkileri

  • Anthropic modellerinde araç şemaları tarafsız, soyut sözleşmeler olmayabilir
  • Bazı araç biçimleri sonradan eğitimde görülenlere yakındır, bazıları ise uzaktır
  • Bazı biçimler sağlayıcının gizli kodlamasında daha kolay olabilir; bazıları ise uzun çok satırlı string’lerden sonra iç içe diziler içinde büyük, escape edilmiş JSON nesneleri yazmayı gerektirdiği için daha zor çalışabilir
  • Model şemayı anlıyor olsa bile baskı altındaki durumlarda doğru yapıyı örneklemekte başarısız olabilir
  • Anthropic tarafında strict örnekleme açıldığında bu sorun ortadan kalkabilir
  • Ancak en yeni modellerin davranışı, reinforcement learning’in model üzerindeki etkisini gösteriyor; belirli bir harness’in önsel dağılımına karşı gelmek, en yüksek performansı elde etmek açısından dezavantajlı olabilir
  • Claude Code açık kaynak değil ve RL ortamında ne yaptığı da bilinmiyor; bu nedenle Claude Code’a uyacak şekilde eğitilmiş davranışların başka araçlara temiz biçimde aktarılacağını varsaymak zor
  • Sonradan eğitim tek bir baskın harness içinde ne kadar fazla gerçekleşirse, diğer harness’lerin o harness’in garip özelliklerini miras alma olasılığı da o kadar artar
  • Kısıtlı decoding’in kalite açısından bazı trade-off’ları olabilir; ancak en yeni modeller görev çözmede iyileşirken alternatif araç şemalarını sadık biçimde üretme yetenekleri kötüleşiyorsa, harness’in bir yerinde daha güçlü güvencelere ihtiyaç vardır

İlgili okumalar

1 yorum

 
GN⁺ 6 시간 전
Lobste.rs görüşleri

  • Fable’ı merak ediyorsanız, ben Fable’ın artık düşürme yaptığında bunu her zaman açıkça bildirdiğini anlıyorum
    Ben de bir kez sınıflandırıcıya takılmıştım; görünüşe göre “hataları önem derecesine göre sırala” ifadesi güvenlik araştırması gibi gelmiş

    • Biraz test etmeyi planlıyorum
      Bunu arkadan gizlice yapmayacaklarını söylediler ama düşürme için kullanılan mekanizmayı hâlâ doğrulayabilmiş değilim

  • Bu hipotez doğruysa etkisi kodlama ajanlarının ötesine geçebilir
    kararlı araç çağrılarına dayanan uygulamalar, model belirli bir sağlayıcının tercih ettiği yürütme ortamına göre sonradan eğitildikten sonra benzer performans düşüşleri yaşayabilir

  • Bu arada bu yazıyı vibecoding değil ai olarak gönderdim
    Bu sitede vibecoding sınırının nerede başladığını gerçekten anlamak çok zor
    Bu yazı temel LLM’ler, pekiştirmeli öğrenme ve bunların etrafındaki yürütme ortamlarının inşasıyla çok daha ilgili
    Eğer buna da vibecoding deniyorsa ai etiketi geriye tam olarak ne için kalıyor bilmiyorum

    • Burada vibecoding, üretken yapay zekaya az da olsa dokunan ya da dokunmuş gibi görünen her şeye yapıştırılan dev bir kızıl harfe dönüşmüş durumda
      Son birkaç haftada havalı blog yazıları, LLM katkılarını yasaklayan büyük projelerin README’leri ve “X değil Y” türü cümlelerle dolu yazıların hepsi vibecoding etiketi aldı
      Ben şahsen o etiketi ciddiye almayı tamamen bıraktım. Topluluk onu o kadar refleksif biçimde kullanıyor ki artık gerçek bir anlamı kalmadı
      Yine de bu özel yazının, tabir yerindeyse gerçekten bu amaçla kullanılan modellere dair olduğu için vibecoding etiketi almasına katılıyorum
      Aynı zamanda tam da belirtilen nedenlerden ötürü ai etiketinin kaldırılmaması gerektiğine de katılıyorum. Yeniden eklemek isterdim ama nedense bu yazıda o seçenek yok

  • Şaşırtıcı değil. Satıcıya bağımlılık muhtemelen planın bir parçası olabilir

    • Bir miktar maliyet düşürme de işin içindedir muhtemelen. Herkes Claude Code kullanırsa prompt caching iyileşir
      “Claude aboneliği ödeyip zaten tüm kodunuzu bize gönderiyorsanız, modelden bağımsız olarak yeterince güçlü bir bağımlılık aracı olmayabilecek ücretsiz UI’ı da mutlaka kullanmalısınız” yaklaşımı, saf satıcıya bağımlılığın genelde işleyiş biçimine pek benzemiyor

  • Modelin, eğitildiği yürütme ortamında, yani model geliştiricisinin yaptığı ortamda en iyi çalışması mantıklı
    Claude Code benzeri izler üzerinde çok yoğun pekiştirmeli öğrenme gördüyse, Claude Code gibi davranmayan yürütme ortamlarında belirgin biçimde kötüleşmesini beklersiniz
    Benim için daha şaşırtıcı olan, Pi gibi üçüncü taraf yürütme ortamlarında bile oldukça iyi görünmesi
    Hatanın yalnızca ajan izinin derinlerinde ortaya çıkması da makul görünüyor
    Bu yılın başlarında GPT 5.2 ve 5.3 modellerinde, izin sonraki bölümlerinde ajanın ls -la yerine ls -ლა yazdığı bir hatayla uğraştım
    Bunu kısaca burada kaydetmiştim: https://github.com/openai/codex/issues/7988
    Benim deneyimimde bu da yalnızca iz derinleştikten sonra ortaya çıkıyordu
    Uzun bağlamlarda model sanki net biçimde “düşünemiyor” ve ilkel içgüdülere geri dönüyor gibi görünüyor
    Muhtemelen modelin eğitim dağılımı ile yürütme ortamı ya da kullanıcının modele zorladığı görev arasındaki farkın performansı en dramatik biçimde etkilediği nokta da burasıdır

    • Sorun, pekiştirmeli öğrenme yapıp kendi yürütme ortamında daha iyi çalışması değil
      Sorun, fazla pekiştirmeli öğrenme yüzünden önceki sürümlere kıyasla diğer yürütme ortamlarında gerileme göstermesi
      Bu noktada “başka tür bir aşırı uyum da mı başlamış durumda?” gibi sorular sormamız gerekiyor