LLM'ler delege edildiğinde belgeleri bozuyor

 (arxiv.org)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • DELEGATE-52, kullanıcıların uzun belge düzenleme işlerini LLM'lere devrettiği delege temelli iş akışlarında belgenin ne kadar sadakatle korunduğunu değerlendiren bir benchmark'tır
  • Bu benchmark, kodlama, kristalografi, nota yazımı gibi 52 uzmanlık alanında derin belge düzenlemesi gerektiren görevleri ele alır ve örnek simülasyon 20 ardışık görevin devredilmesinden oluşur
  • 19 LLM denemesinde Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4 gibi frontier modeller bile uzun iş akışının sonunda ortalama olarak belge içeriğinin %25'ini bozmuştur
  • Belge bozulması seyrek ama ciddi hatalar şeklinde ortaya çıkar; belge boyutu, etkileşim uzunluğu ve dikkat dağıtan dosya sayısı arttıkça bozulma büyür ve ajan tipi araçların kullanımı da performansı iyileştirmez
  • Mevcut LLM'ler, delege temelli belge düzenlemede güvenilir bir vekil olarak görülmekten uzaktır; microsoft/DELEGATE52 ve datasets/microsoft/DELEGATE52, DELEGATE-52 ile ilgili kaynaklar olarak yayımlanmıştır

Delege temelli düzenlemenin başarısızlık örüntüsü

  • Delege temelli işlerde kullanıcı, görevi LLM'e bırakır ve LLM'in belgeye hata sokmadan işi yürüteceğine dair güvene dayanır
  • 19 LLM üzerinde yapılan büyük ölçekli deneylerde, mevcut modellerin delege sürecinde belgeyi bozduğu görülmüştür
  • Diğer modeller, frontier modellere kıyasla daha ağır şekilde başarısız olur
  • Belge bozulması, uzun etkileşimler boyunca birikerek belgeyi sessizce kullanılmaz hale getirir

Örnek olarak gösterilen belge değişimleri

  • Graph Diagrams alanındaki Linux Kernel Architecture belgesi, Gemini 3.1 Pro'da orijinale kıyasla 4 turun ardından %79, 10 turun ardından %49, 14 turun ardından %48, 20 turun ardından %48 düzeyinde gösterilmiştir
  • Textile Patterns alanındaki 12-Shaft Twill Diamond belgesi, Claude 4.6 Opus'ta orijinale kıyasla 4 turun ardından %100, 10 turun ardından %40, 14 turun ardından %27, 20 turun ardından %34 düzeyinde gösterilmiştir
  • 3D Objects alanındaki ActionBoy Palm Tree belgesi, GPT-5.2'de orijinale kıyasla 4 turun ardından %100, 10 turun ardından %31, 14 turun ardından %15, 20 turun ardından %6 düzeyinde gösterilmiştir

Açık kaynaklar

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Araç kullanımına ilişkin sonuçlar konusunda şüpheliyim

    Uzun içeriğin LLM üzerinden ileri geri geçirilince bozulması şaşırtıcı değil. LLM’leri sık kullananlar, bunun yapılmaması gerektiğini zaten biliyor

    Makalede araç kullanımının yardımcı olmadığının söylenmesine şaşırdım, ama aynı zamanda sadece “temel bir ajan harness’i” uyguladıklarını ve bunun son teknolojiye göre optimize edilmiş bir sistem olmadığını da belirtiyorlar

    Gerçekte harness yalnızca read_file() ve write_file() içeriyor; yani aslında ileri geri geçişe eklenmiş tek bir adım gibi. Günümüzün kodlama ajanı harness’leri dosya düzenleme araçlarının tasarımına çok emek harcıyor; örneğin Claude’un düzenleme araçları paketi var: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    str_replace ve insert komutları, tüm dosyayı yeniden yazan riskli düzenlemelerden kaçınmak için kritik

    En azından run_python() aracı sağlanmış, dolayısıyla daha iyi modellerin bunu kullanarak string replacement yapmış olması mümkün. Sistem prompt’unun Python tabanlı işlemleri teşvik edip etmediğini, yoksa dosyayı okuyup yeniden yazmaya mı yönlendirdiğini görmek isterdim

    Harness kodunu burada buldum: https://github.com/microsoft/delegate52/blob/main/model_agen...

    İlgili prompt parçasında, “ister programatik olarak ister dosyaya doğrudan yazarak, en etkili olduğunu düşündüğün şekilde yaklaşabilirsin” deniyor

    Bu tür makalelerde sık olduğu gibi, sonuçlar modelin kendisinden çok makale yazarlarının kullandığı harness tasarımını yansıtıyor. İster deneyimli bir yapay zeka mühendisi ister prompt mühendisi olsun, biri harness’in kendisini yinelemeli olarak iyileştirirse bu testte daha iyi sonuçlar alabilir diye düşünüyorum

    • Büyük ölçüde katılıyorum, ama “LLM’leri sık kullananlar, bunun yapılmaması gerektiğini zaten biliyor” kısmı hariç

      Şu anda kurumlar ve ekipler genelinde LLM benimsenmesi dayatılırken, her gün LLM kullanan ama harness gibi teknik şeylere hiç dokunmamış çok insan var; hatta çoğunluk bile olabilir

      Burada anlatılan davranış, bu insanlar için büyük bir sorun

    • Biraz ilişkili bir konu ama, varsayılan dosya düzenleme/okuma aracı olarak ed kullanan bir harness görmek isterim. Claude’un çalıştırdığı bash komutlarının yarısı zaten sed gibi görünüyor; ed içinde durum korunursa faydalı olabilir

      Tam teşekküllü bir editör çok fazla bant genişliği^H token tükettiğinde ne yaparsın? Standart editör ed kullanırsın

    • Bu, LLM görevlerini biraz korkuluk gibi göstermeye yakın bir örnek

      Düzenleme işlerinde sadece programatik düzenleme komutlarına izin verilmeli; metin LLM’in içinden geçmemeli. LLM metni analiz etmeli ve geri bildirime göre hedefe ulaşacak komutları üretmeli

    • HN’de sonuçları olabildiğince olumsuz yorumlama eğilimi var. Çünkü bunu kendi işleri ve kimlikleri için bir tehdit olarak görüyorlar

      Aslında, bir belgeyi okuyup değişiklikleri uygulayarak tüm belgeyi baştan söyleyerek düzenlemek zorunda olsa, bir insan %25 bozulmadan daha kötü sonuç verebilir. Elbette bir insanın %0 bozulma sağlaması mümkün, ama bunun için belgeyi yüzlerce kez alıp ezberlemesi gerekir. LLM’de bunun karşılığı eğitimdir; belgeyi LLM’e öğretirseniz, bu durumda ezberlemiş bir insanın düzenlemesine eşdeğer olabilir

      Ama yukarıdaki asıl mesele değil. LLM’ler insanlara benzediği için, harness’i de insanların belge düzenlediği gibi; arama yapıp cerrahi düzeltmeler uygulayacak şekilde tasarlamak gerekir. Bütün kodlama ajanları zaten böyle düzenleme yapıyor, bu yüzden bu makale pek ilgili değil

    • Kaynak kısıtı yüzünden ya da basitleştirme amacıyla olsun, anlaşılması zor metodolojiler yüzünden bu tür makalelerin değeri ne yazık ki düşüyor

  • Uzun zamandır söylediğim gibi, herhangi bir metni AI cilasından geçirirsen kalite düşer ve tekrarlandıkça bu birikir

    Buna verilen isimlerden en çok “semantic ablation” hoşuma gidiyor: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • Ben buna ortalama zekaya regresyon diyordum
    • “Tekrarlandıkça” derken aynı oturum içinde tekrarlamayı mı kastediyorsun, yoksa her seferinde yeni bir oturum ya da yeni bir bağlam penceresi mi?

  • Argüman şu: “Delege etmek güven gerektirir. LLM’in belgeye hata katmadan işi sadakatle yapacağına dair bir beklenti olmalı.” Ve tam da bu yüzden, onlarca Markdown dosyası yazan harness’ler ve prompt ritüelleri reklam edildiği kadar işe yaramıyor. Bu neredeyse ajan mühendisliği adı altındaki bir sahte bilime benziyor

    Ajan mühendisliği de sonuçta sözde prompt mühendisliğiyle neredeyse aynı şey; sadece artık prompt onlarca Markdown dosyasına ve dizine dağılmış durumda

  • Son zamanlarda LLM’ler hakkında okuduğum en az şaşırtıcı şey buydu

    LLM’ler JPEG mem’lerine benziyor. Bir JPEG’i her kaydettiğinde kalitesi biraz daha düşer ve sonunda tanınmaz hale gelir ya, aynı şekilde çalışıyorlar

    Ancak LLM’lerde başlangıç noktası niyet. LLM’den her geçişte niyet bozuluyor; özellikle hassas bilimsel makaleler gibi şeylerde yeniden ifade etme sürecinde ince nüanslar ve kesinlik azar azar kayboluyor

    LLM’ler ortalamaya regresyon makineleri. Mevcut bağlam ya da iş yükü eğitim dağılımının dışına ne kadar çıkarsa, onu giderek daha homojen, soyut bir denge durumuna çekme eğilimleri o kadar artıyor

    • LLM ile kod yazarken bunu kesinlikle yaşadım. Özellik işlerini hızlıca peş peşe bitirdikten sonra oldukça dikkatli olduğumu düşünsem bile, sonradan küçük kod parçalarına yakından bakınca sık sık “aman Tanrım” dedirten anlar oluyor

      Sonra saatler harcayıp her şeyi tekrar gözden geçirmem; istediğim gibi olmayan kısımları, benim belirsiz olduğum yerleri ve LLM’in tuhaf alışkanlıklarının devreye girdiği noktaları dikkatle düzeltmem gerekiyor

      Kod kalitesi başlı başına önemli ama beni asıl kaygılandıran tam olarak bu tekrarlı sıkıştırma sorunu. Kod tabanı temizse ve zihinsel modelin güncelse, LLM özellik geliştirmede hızlı yardım edip yine de kod tabanını makul durumda bırakabilir. Ama LLM kod tabanını kirletmeye başladığında geçmiş hatalar ya da yanlış anlamalar birikiyor ve giderek daha fazla şeyi yanlış yapma ihtimali artıyor. Bu yüzden LLM’i tekrar kullanmadan önce her şeyi doğru duruma “restore” etmeden rahat edemiyorum

    • Bu sonucun gerçekten ilginç ve ilgili olduğu yer, kodlama ajanlarının büyük kaynak dosyalarını birçok küçük dosyaya böldüğü durumlar. Opus ve Claude Code, insanların yaptığı gibi kopyala/yapıştır türü işlemler kullanmak yerine, uzun kaynak kod parçalarını hafızadan okuyup yeni dosyalara koymaya çalışıyor

      Dosya taşımak biraz daha kolay. LLM bazen yine dosyayı hafızadan yeniden söylemeye çalışıyor ama ona git mv kullanıp derleyici hatalarını düzeltmesini söylersen genelde iyi iş çıkarıyor

      Buna karşılık sıradan düzenlemeler, makul bir model ve araç yapılandırmasıyla genelde iyi çalışıyor. Qwen3.6 27B bile bu seviyede yeterli. Yerinde değişikliklerde beklenmedik farkları gözden geçirmek için git diff kullanılabilir

    • Bunu gösteren bir çocuk oyunu bile var: https://en.wikipedia.org/wiki/Telephone_game

    • Bir iş arkadaşım LLM’i “saçmalık katmanı” diye tanımlıyor. Tam anlamıyla küçümsemek için değil; LLM’den bir şey geçirdiğinde öbür taraftan çıkan sonucun beklediğin ya da istediğin şeyden farklı olabileceğini vurgulamak için

      Bara gidip birkaç kadeh içmiş birinin internette bir yerde gördüğünü iddia ettiği bilgiyi aktarması gibi. Doğru da olabilir, ama yanlış olma riski de oldukça yüksek

      Örneğin API çağırıp veri toplarken ve rapor oluştururken LLM kullanmamalısın. Çünkü kritik veriyi saçmalık katmanından geçiriyorsun ve sonuca güvenemezsin. Bunun yerine LLM’i, kritik veriden kritik çıktı üreten kodu yazmak için kullanmak daha iyi

      İş arkadaşlarımın API’den gelen kritik veriyi LLM’e özetlettirdiğini ve raporun, doğru olduğu durumlar kadar büyük ölçüde sapabildiğini de gördüm. Neyle uğraştığına bağlı olarak bu felaket düzeyinde risk olabilir

    • Bunu özgeçmiş düzenlerken yaşadım. LLM, özgeçmişimi ortalama deneyime sahip junior mühendis kalabalığından ayıran her şeyi kaldırıyor. Özel, benzersiz ya da farklı olan her şey sonunda genel geçer ifadelerle değiştiriliyor

      Elbette ortaya çıkan sonucu kullanmadım, ama LLM’in bunun mevcut halden daha iyi olduğunu ısrarla savunması gerçekten sinir bozucuydu

      LLM, özgeçmişin genel yönünü belirlemekten ziyade, çok küçük parçalar için; örneğin tek bir cümle ya da üç cümlelik bir düzenleme önerisi almakta çok daha faydalıydı

  • Sorun, LLM’lere fazla iş yüklememiz. Ajanlar, LLM’i doğal dildeki niyeti deterministik bir sürece çeviren mümkün olduğunca ince bir katman olarak kullanacak şekilde tasarlanmalı ve LLM üzerinden ileri geri geçişler en aza indirilmeli

    • Biraz karmaşık herhangi bir şey yapmaya çalışan herkes için bu açık hale geliyor. Ön işleme akışları, anlamsal tabanlı hedefleme ve asgari bağlam çağrılarını LLM API’siyle birleştiren bir pipeline kurarsan, güçlü bir otomasyon adımı elde edersin

      Ayrı doğrulama adımlarıyla birleştiğinde, LLM bir oyuncaktan faydalı bir araca dönüşüyor

    • İnsan da bu kadar tekrar içeren sürecin içinde olmamalı ki buna otomasyon denebilsin

  • Genellikle ajanlara, belge yazımını yalnızca son render etme aşaması olarak ele almalarını söylerim. LLM’ler dağınık bilgiyi toplayıp örmede çok iyidir, bu yüzden bilgiyi birleştirilebilir fikirler ve olgular halinde saklamayı tercih ederim

    Pratikte işe yarayan yöntem, ajana bir dizin verip bulduğu her olgu ya da keşif için bağımsız bir Markdown dosyası oluşturmasını söylemek oldu. Her dosyanın başına da aramayı kolaylaştıracak metadata eklemesini isterim

    Bu sayede işin büyük kısmı, “araştırıp doğrudan son belge biçiminde kaydetme” gibi karmaşık bir süreçten çıkıp, “belgeye yardımcı olacak olgu ve keşifleri araştırma” ve “belgeyi birleştirme” şeklinde daha tutarlı iki göreve ayrılıyor

    Tam bir çözüm değil, ama insanlar çalışırken olduğu gibi bulguların yeniden kullanılabilirliğini artırıyor

  • Bu insanlara da uygulanmıyor mu? Çocukların “kulaktan kulağa” oynarken mesajın nasıl bozulduğunu görmelerinin nedeni de bu. Çözüm, tek bir doğruluk kaynağı sağlamaktır

  • Bu tür bozulmalarla mücadele edecek araçlar geliştiriyorum: https://github.com/JigSpec/JigSpec

  • Buradaki değerlendirme yöntemini gerçekten beğendim. Geri alınabilir adımlar zincirini ileri geri çalıştırarak sadakati test ediyor

    Yüzeyde bilgisayarların rahatça halledeceği gibi görünen işlerde bile en ileri modellerin hata biriktirmesi etkileyiciydi

    Python’da daha güçlü sonuçlar çıkmasının sadece Python’a özgü değerlendirmeden mi kaynaklandığını, bunun diğer yaygın genel amaçlı dillere de uzanıp uzanmadığını ve eğitim sürecindeki belirli unsurlardan mı geldiğini merak ediyorum

  • Modelin sayısız küçük hatadan, yani “bin kesikten” dolayı değil, daha çok birkaç turda yaşanan ölümcül başarısızlıklar nedeniyle çöktüğünü zaten büyük ölçüde biliyorduk. Bazı turlarda neredeyse kusursuz yeniden kurarken, birkaç turda bir seferde 10–30 puandan fazla kaybediyor

    Daha zayıf modellerdeki bozulmanın ağırlıklı olarak içerik silinmesinden, en ileri modellerdeki bozulmanın ise içerik tahrifinden gelmesi de aynı şekilde. Bu yüzden harness, temperature gibi şeylerle sürekli oynayıp duruyoruz