AbsenceBench: Dil modelleri eksik bilgiyi tespit edemiyor

 (arxiv.org)
1 puan yazan GN⁺ 2025-06-22 | 1 yorum | WhatsApp'ta paylaş
  • Uzun bağlamda “var olan bilgiyi” bulmaya yönelik değerlendirmeler hızla iyileşirken, AbsenceBench orijinal ve değiştirilmiş sürümleri karşılaştırarak eksik bilgiyi bulma yeteneğinin hâlâ zayıf olduğunu gösteriyor
  • Benchmark; şiir, sayı dizileri ve GitHub PR diff olmak üzere 3 alandan oluşuyor, 4.302 örnek ve ortalama 5K token bağlam kullanıyor; varsayılan eksiklik oranı %10
  • GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash, o3-mini, Grok-3-mini, DeepSeek-R1 dahil 14 LLM değerlendirildiğinde bile en yeni modellerin performansı sınırlı kalıyor; Claude-3.7-Sonnet ortalama 5K token’da yalnızca %69,6 F1-score elde ediyor
  • AbsenceBench’in F1-score’u NIAH’ye kıyasla ortalama %56,9 düşüyor; çıkarım anında hesaplama yapan modeller de ortalama 8K ek thinking token kullanmasına rağmen performans artışı %7,9’da kalıyor
  • Eksik konumlara açık placeholder eklendiğinde performans ortalama %35,7 artıyor; bu da Transformer attention’ın belge içindeki “gap”lere odaklanmakta zorlandığı yorumunu destekliyor

AbsenceBench’in sorduğu soru

  • Son dönemde LLM’ler uzun bağlam görevlerinde yüksek performans gösteriyor ve Needle-in-a-Haystack(NIAH) testlerinde çok uzun girdiler içindeki küçük, ayırt edici bilgiyi bulabildiklerini gösteriyor
  • AbsenceBench bunun ters yönündeki problemi değerlendiriyor
    • Girdi içinde yer alan bilgiyi bulmak yerine, açıkça eksik olan bilgiyi bulmak gerekiyor
    • Modele orijinal belge ve bazı öğeleri silinmiş değiştirilmiş belge birlikte veriliyor
    • Çıktı, değiştirilmiş belgede eksik olan öğelerin tam kümesi olmalı
  • Bu görevde kurallar basit ve doğru cevap da net olsa da, en ileri kapalı kaynak modeller bile düşük performans gösteriyor

Görev tanımı ve veri yapısı

  • AbsenceBench, orijinal belge Dorig içinden bazı öğeleri Domit kasıtlı olarak kaldırıp değiştirilmiş belge Dmodified oluşturan ve modelden kaldırılan öğeleri bulmasını isteyen kontrollü üretim biçiminde bir benchmark
  • “document length” orijinal belgenin token sayısını, “context length” ise model girdisinin tamamındaki token sayısını ifade ediyor
  • Tüm benchmark 4.302 örnekten oluşuyor; ortalama bağlam uzunluğu 5K token
  • Kod deposu harvey-fin/absence-bench adresinde yayımlandı
  • Token uzunluğu ölçümünde GPT-4 Tokenizer kullanılıyor

Şiir, sayı dizileri, GitHub PR diff

  • Şiir(Poetry)

    • Gutenberg Poetry Corpus’taki şiirler kullanılıyor
    • Eksiltme satır bazında uygulanıyor; satır ayırıcı newline karakteri
    • Belge uzunluğu çeşitliliği için her şiirin satır sayısı 100~1000 arasında eşit dağılacak şekilde kesiliyor

  • Sayı dizileri

    • Toplam 1.200 sentetik sayı dizisi oluşturuluyor
    • Sayılar artan, azalan veya rastgele sıralardan biriyle diziliyor
    • Ardışık sayılar arasındaki step size 1, 4, 7, 13 değerlerinden biri
    • İlk sayı 0~9999 arasından rastgele seçiliyor

  • GitHub PR diff

    • Herkese açık GitHub verileri ve GitHub API kullanılarak en çok PR’a sahip ilk 20 deponun PR’ları toplanıyor
    • Diff içinde güncellenmiş satır sayısı 10~200 olan PR’lar tutuluyor
    • + veya - ile başlayan güncelleme satırları arasından, her PR diff içinde benzersiz olan satırlar eksiltme hedefi yapılıyor
    • Merge conflict’i çözen ve doğrulayan bir LLM’in dosya diff’lerinde eksikleri tespit edebilmesi gerektiğinden, bu gerçek kullanım senaryolarıyla bağlantılı

14 LLM değerlendirmesinde görülen sınırlar

  • Değerlendirilen toplam 14 LLM var
    • GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash gibi en yeni modeller dahil
    • o3-mini, Grok-3-mini, DeepSeek-R1 gibi çıkarım anında hesaplama yapan modeller dahil
    • Claude-3.7-Sonnet ve Gemini-2.5-flash, çıkarım anında hesaplama kullanıp kullanmamasına göre ayrı değerlendiriliyor
  • En yeni modeller bile AbsenceBench’te istikrarlı performans üretemiyor
    • Claude-3.7-Sonnet ortalama 5K token bağlamda %69,6 F1-score kaydediyor
  • Bağlam uzunluğu arttıkça görev daha da zorlaşıyor; fark özellikle şiir alanında belirgin
  • Çıkarım anında hesaplama ortalama yalnızca %7,9 performans artışı sağlıyor
    • Buna karşılık ortalama 8K ek thinking token üretiyor
    • Bu, ortalama belge uzunluğunun neredeyse 3 katına karşılık geliyor
  • Eksiklik oranı düştükçe model performansının tersine kötüleştiği sonuçlar da görülüyor

NIAH’den farklı başarısızlık biçimi

  • AbsenceBench, LLM’ler için NIAH’den çok daha zor bir görev olarak ortaya çıkıyor
    • Üç LLM AbsenceBench ayarı ile özgün NIAH ayarında karşılaştırıldığında, F1-score ortalama %56,9 düşüyor
  • Transformer attention, belge içindeki gapleri ele almakta zorlanıyor olabilir
    • Çünkü eksiklik, attention’ın yönelebileceği belirli bir key’e karşılık gelmiyor
  • Eksik konuma placeholder dizgesi eklenen deneyde performans ortalama %35,7 artıyor
    • Örnek olarak eksik satır konumuna <missing line> gibi token’lar ekleniyor
  • Bu sonuç, LLM’lerin bilginin “eklenmiş” olduğu durumları tanımaya kıyasla bilginin “eksik” olduğu durumları belirlemekte daha zayıf olabileceğini gösteriyor
  • LLM-as-a-Judge gibi eksik bilgiyi doğru fark etmeyi gerektiren kullanım biçimlerinde bu sınır pratik bir riske dönüşebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-22
Hacker News yorumları

  • Gerald Sussman’ın bir konuşmasını izledikten sonra Kanizsa triangle görselini Claude’a verdim ve çıkarımsanan üçgeni “görüp” göremediğini epey muğlak biçimde sordum; görseli tanıdı ve hemen bir özet çıkardı
    Bu yüzden görseli 90 derece döndürüp yeni bir sohbet içinde tekrar denedim; bu kez görseli tanıyamadı ve öğe sayısını da yanlış verdi
    Döndürülmüş görsel için Claude, dört köşede Pac-Man’e benzeyen 4 siyah şekil, yukarıyı gösteren 1 ince üçgen ve sağı gösteren 1 ince üçgen, ayrıca açık gri bir arka plan olduğunu söyledi

    • Şimdi bu tür boşlukları kapatmak için eğitim verisindeki tüm görselleri 90 derece döndürülmüş hâlleriyle de ekleyecekler gibi
    • Bir LLM’e 5 bacaklı bir köpek fotoğrafı gösterirseniz, sayma işini hiç beceremediğini görebilirsiniz
    • Gerçekten hesaplama yapmayı bilmiyormuşuz gibi geliyor
      Ekim 2011, 30 yorum
      https://news.ycombinator.com/item?id=3163473
      Strange Loop videosu:
      Temmuz 2011, 36 yorum
      https://news.ycombinator.com/item?id=2820118
    • Bana kalırsa makale yalnızca metin belgelerini ele aldığı için bu örnek tam oturmuyor
      LLM’lerin metin ya da sesi işlediği gibi görselleri işlemesi konusunda hâlâ gidilecek çok yol olduğu iyi biliniyor
      Görüntü piksellerini doğrudan alıp iyi performans veren çok modlu modellerin neredeyse hiç olmadığını düşünüyorum. Görsel yeteneklerin çoğu hack’e yakın ya da mühendislikle sonradan eklenmiş yöntemler; görsel, birkaç işleme adımından geçiyor ve ardından her işlemcinin çıktısı token olarak transformer’a giriyor. Bu tek bir ağ içinde gerçekleşebilir ama transformer olmayan ağlar da devreye giriyor. Ön işleme örnekleri arasında OCR, çeşitli büyütme oranları·açılar·kesitler kullanan CNN’ler (2D örüntü tanıyıcılar) ve başka şeyler olabilir
    • Bu fikri genelleştirirsek, bir üçgeni kabaca dolduran 1.000 nokta gördüğümüzde şekli hemen tanırız
      Bence bu basit örnek zekânın özünü ortaya koyuyor. 1.000 noktalık büyük karmaşıklık, basit ve düşük entropili geometrik bir biçime uyduğu için üçgeni tanıyoruz
      IQ dediğimiz şeyin, fark edebildiğimiz örüntü karmaşıklığının üst sınırına yakın olduğunu düşünüyorum. Örneğin o 1.000 nokta aslında hafifçe döndürülmüş 10 boyutlu bir hiperküpün köşeleri olabilir ve 10 boyutlu bir zihin için kolayca görülebilen bir örüntü olabilir

  • İlginç. En yeni modeller bile hem özgün bağlam hem de düzenlenmiş bağlam verildiğinde, bağlamdan hangi bilginin silindiğini belirleme konusunda nispeten düşük performans gösteriyor
    Yazarlar, transformer’ın dikkat mekanizmasının silinmiş token’lar için anahtar bulunmadığından onlara dikkat yöneltemediği için performansın düşük olduğunu düşünüyor

    • Dikkat yöneltilecek anahtarlar var. Sadece düzeltilmiş metinde değil, özgün metnin içinde. Model ikisini de girdi olarak aldığına göre teoride bu anahtarlara dikkat yöneltebilir
      Dikkat mekanizması açısından Original: {ortak önek} {silinen bölüm} {ortak sonek} Modified: {ortak önek} {ortak sonek} ile Original: {ortak önek} {ortak sonek} Modified: {ortak önek} {eklenen bölüm} {ortak sonek} arasında büyük fark yok
      RASP (transformer’ları elle programlamak için kullanılan dil) ile kabaca şöyle bir algoritma yapılabilir gibi. 1. katman, "Original:" ve "Modified:" token’larına dikkat ederek mevcut token’ın özgün tarafta mı, düzeltilmiş tarafta mı olduğunu belirler. 2. katmanda bir head tüm özgün token’lara eşit biçimde dikkat yöneltip değerlerin ortalamasını alır, başka bir head tüm düzeltilmiş token’ların ortalamasını alır ve sonra iki ortalama arasındaki farkı hesaplar. 3. katman bu farka benzeyen token’lara dikkat yöneltir; bu da {silinen bölüm} ya da {eklenen bölüm} olur
      Sıraya bağlı tek kısım, farkın özgün ortalama - düzeltilmiş ortalama olarak mı yoksa tersi yönde mi hesaplandığıdır
      Model eklemeleri algılayıp silmeleri algılayamıyorsa, ilkesel olarak böyle bir algoritmayı ya da benzerini öğrenme kapasitesi var ama silme türü veri yetersiz olduğundan gerekli devreler gelişmemiş olabilir
    • Görsel modellerin fotoğraf negatifleri, döndürülmüş görseller gibi şeylerle eğitilip eğitilemeyeceğini merak ediyorum. Ya da “the _____ took first place in the horse show” gibi boşluk doldurma cümleleri de mümkün olabilir
    • Son dönemin en üst seviye modellerini pek kullanmamışlar gibi. Opus, o3, Gemini 2.5 Pro yok
    • Yine de modeller arasında göze çarpan farklar var; artık bir benchmark oluştuğuna ve bu sorun ilgi gördüğüne göre ne kadar daha iyi hâle gelebileceğini merak ediyorum. Kesinlikle yapılabilecek bir şeyler var

  • Çok ilginç. 1) Yazarlar, boşluk bir token olmadığı için dikkat mekanizmasının boşluğun konumuna dikkat edemeyebileceğini söylüyor; ama iyi bir LLM transformer’ının en azından boşluğun yakınına epey yaklaşabilmesini beklerdim
    Matematiksel olarak bu mimarinin neden daha az uygun olduğunu tam anlayamıyorum. Boşluğun bulunabileceği bölgeye dikkat yöneltmek mümkün görünüyor. Böyle görevlerle ince ayar yapmanın yardımcı olup olmayacağını da merak ediyorum
    2) Girdi ne kadar kısa ve eksik kısım ne kadar azsa görev o kadar zordu. İnsan bu işi yaptığında da tek bir kelimenin eksik olduğunu fark etmek daha zor; bir satırın eksikliği, on satırın eksikliğinden daha zor, bu yüzden tamamen şaşırtıcı değil. Yine de LLM’lerin böyle bir sorun yaşaması ilginç
    3) Akıl yürütme modelleri belgeyi doğrudan yazıp ilerleyerek çözebildiği için daha iyi performans gösteriyor. Buna rağmen doğruluğun %100 olmaması hâlâ çok şaşırtıcı. Bu önemsiz bir görev olmalı ve makalenin dediği gibi basit bir programla çözülebilir. ChatGPT gibi bir ajan, eğitim sırasında bu makaleyi okuyup böyle sorunları çözerken Python yazıp çalıştırması gerektiğini öğrenebilir gibi geliyor
    En ilginç kısım, zekânın henüz açıkça tanımlamadığımız başka hangi yönleri olduğu ve LLM’ler ile mevcut yapay zekanın bunlarda çok zayıf olup olmadığı. Bu makale böyle yönlerin çok olabileceğine işaret ediyor ve genel olarak benchmark hazırlayanlar için oldukça eğlenceli bir dönem gibi görünüyor

  • Adil olmak gerekirse, kelimenin tam anlamıyla dize farkı bulma işini LLM’ye mekanik aritmetik yaptırmakla aynı kategoriye koyarım.
    Dikkat mekanizması, böyle aptalca işler için gereğinden fazla karmaşık düşünür. Böyle durumlarda üst düzey bir sonraki token tahmini yapmaktansa, kasıtlı olarak basitleştirip odaklanmak ve disiplinli şekilde işlemek gerekir.
    LLM’den tüm belgeyi listeleyip karşılaştırmasını gerçekten istemek faydalı olur. Bu, akıl yürütmede olduğu gibi adımlara bölme yaklaşımıdır; LLM’lerin aritmetik ya da cebir problemlerini küçük adımlara ayırdığında daha iyi yapmasına benzer.
    İyi performans gösteren modellerin MoE modelleri olabileceğini tahmin ediyorum. Sezgiden çok odak gerektiren işlere uygun bir iki uzman olabilir. Gemini Flash’ı hiç bilmiyorum ama MoE modeli olabilir diye düşünüyorum.

  • Makaleyi henüz okumadım ama yapısal dikkat mekanizması açısından sınıflandırılmamış eksikleri tespit edememek tamamen beklenen bir şey. Yine de bunun yapılandırılmış düşünmeyle çözülebileceğini düşünüyorum.
    İğne arama probleminde, aradığınız şeye dikkat vermeniz yeterlidir; dikkat bunu oldukça iyi yapar.
    Bir eksiği ararken o eksik herhangi bir şey olabilir; dolayısıyla ancak bir bütün bağlamı başka bir bütün bağlamla karşılaştırarak çıkarım yapılabilir. Dikkat katmanının bunu düzgün yapması zordur.
    Bu, “uzun bir öğe kümesini sıralama” problemine benzer. Bir tür üstbilişsel süreç yoksa basitçe yapılamaz.

    • “Eksik herhangi bir şey olabilir” deniyor ama bu benchmark’ta LLM’ye neyin eksik olduğunu değerlendirmek için gereken bilgi veriliyor.
      Örneğin “Burada bir şiir var ve aynı şiirin bazı dizeleri eksik olabilecek bir sürümü var. Eksik dize var mı?” gibi.
      Bana göre bu, LLM’nin özsel bir zayıflığından çok bir ince ayar sorununa yakın.
      Bir makine öğrenimi makalesinde eksik bulmam istenirse, beynim onu diğer makine öğrenimi makaleleriyle karşılaştırır; Star Wars, Top Gear, Yunan tarihi, seramik ve bildiğim binlerce başka bağlamla karşılaştırması gerekmez.

  • AbsenceBench yöntemine yönelik eleştiri yerinde, ama böyle bir şeyi benchmark etmeleri başlı başına çok sevindirici. Kesinlikle doğru yöne iten bir hareket.

  • Varlığı tespit ederken gerçek beyin duyusal girdi alır, bunu beklentilerle karşılaştırır, sakinliğini korur ya da şaşkınlığı kaydeder ve zaman zaman organizmayı yönlendirecek tahminler üretir.
    Yokluğu tespit ederken ise tanım gereği beyin duyusal girdiye dayanamaz. Duyusal kanıt yokken şaşırabilmek için, duyusal ipuçları olmadan da beklentinin karşılanmadığına şaşıracak kadar güçlü bir dünya modeli gerekir.
    Yokluk tespiti, duyusal girdiyi işlemeye göre kesinlikle daha yüksek düzeyli bir nörolojik görev gibi görünüyor.
    LLM bu daha yüksek düzeyli nörolojik görevi yapamıyorsa, bu şu anda yalnızca canlılarda bulunan bir yetenek değil mi?

    • Düşünmenin kendisi şimdilik zaten yalnızca canlılarda var, bu yüzden insan beyninin benzersizliğini bulmak için ille de böyle bir açıklamaya gitmeye gerek yok.
      Anlattığınız şey bellek ile ilgili. Bellek, duyusal girdi yokken duyusal girdiyi depolayıp yeniden oynatır. Bu yüzden beyin geçmiş duyusal girdiyi yeniden oynatır ve mevcut duyusal girdiyle karşılaştırır.
      Örneğin kalemi masanın üzerine bırakıp dışarı çıkarsanız ve döndüğünüzde kalem yoksa, beyin masanın üzerinde kalem olduğuna dair depolanmış anıyla o an gördüğünü karşılaştırır.
    • LLM, öğrenilmiş yapının geneli boyunca pek tutarlı olmayabilir. Bazı yollar ezberlenmiş bilgiye, bazı yollar ise gelişmiş örüntü eşlemeye çıkabilir.
    • Bu alanı neredeyse hiç bilmiyorum ama sadece zamansal boyutun bile sorun olabileceğini düşünüyorum. Bu tür ajanlar gerçek zamanlı ayarlama yapmak yerine sabitlenmiş ya da donmuş bir “gerçeklik” sürümü üzerinde akıl yürütmüyor mu?

  • LLM’ler dize farkı konusunda zayıf gibi görünüyor. Yan konu olarak, LLM’lerin neleri iyi ve kötü yaptığına dair bu tür bulguları derleyen bir GitHub deposu gibi bir kaynak var mı merak ediyorum.

  • Kötü bir benchmark.
    Onların istemini [1] numaralandırılmış 3 öğeyle denedim; qwq-32b hiçbir sorun yaşamadan doğru bildi. 100 öğeyi de %100 doğrulukla çözebilir gibi geliyor, ama muhtemelen 1 milyon token gerekir. Belki 10 milyondan fazla bile olabilir.
    Akıl yürütme modelleri için 5.000 token sınırı çok az. Test zamanı hesaplamasına bolca alan vermek gerekir; 5.000 token’ın 10 katı bile hâlâ yetersiz.
    Yazarlar uzun girdiden söz ediyorsa, 100 sayfa için 1 milyar token vermek gerekir.
    Doğru uygulama biçimi toplu işlemedir. Eksik giriş metninde ilk 5 numaralı öğeyi bulmak, bulunursa giriş öğelerini ve eksik giriş öğelerini basitleştirip devam etmek gibi.
    Girdi boyutuna bağlı olarak her zaman hatırı sayılır miktarda token gerekecektir, ama basitleştirme düzgün şekilde geriye dönmeye ve bağlamı tamamen kaybetmemeye yardımcı olur.
    [1] Bir öğrencinin şiir ezberi çalışmasına yardım ediyorsunuz. Öğrenci şiiri okuyor ama bazı dizeleri atlamış olabilir. Göreviniz, okumada tam olarak hangi dizelerin eksik olduğunu belirlemek. Yalnızca eksik dizeleri listeleyin, başka hiçbir şey yazmayın. Kullanıcı mesajı: İşte tam özgün şiir: 1)Quisella's lashes fluttered panic-morse. 2)The Moisture Vampires leeches that sucked humidity. 3)Lysandra's nostrils flared precisely one degree. Şimdi bazı dizeleri eksik olabilecek okumam: Quisella's lashes fluttered panic-morse. Lysandra's nostrils flared precisely one degree. Hangi dizeyi atladım? Yalnızca eksik dizeyi listeleyin, başka hiçbir şey yazmayın.

    • Problemi sayma işine indirgemekte neyin ilginç olduğunu bilmiyorum. Bu çalışmanın açık hedefi, önemsiz biçimde maddelendirilemeyen ya da sıralanamayan görevlerde LLM’nin sınırlarını anlamak gibi görünüyor.
    • Az önce HN’deki mevcut numaralandırılmış 26 başlıkla [1] qwq-32b’yi denedim ve 3 başlığı çıkardım; ilk denemede eksik 3 öğenin tamamını kusursuzca buldu. 50.000 token da kullanmadı.
      [1] https://gist.github.com/pramatias/fee1391ad08c7b965f435f3af1...

  • Bunun görsel modellere nasıl uygulanacağını merak ediyorum. Tek görüntülü birkaç örnekle denediğimde iyi yapıyor gibi görünüyordu.
    Birkaç oyuncak örnekte Claude ve Gemini fark bulmada oldukça iyi gibiydi. Örnek görsel: https://www.pinterest.com/pin/127578601938412480/
    Görüntüyü ters çevirince daha çok zorlanıyor gibi göründüler; daha az fark bulmaları ya da halüsinasyon üretmeleri de mümkündü.