AbsenceBench: भाषा मॉडल गायब जानकारी की पहचान नहीं कर पाते

• बड़े भाषा मॉडल (LLM) लंबे इनपुट में विशेष जानकारी अच्छी तरह ढूंढ लेते हैं, लेकिन गायब जानकारी की पहचान करने में उनकी सीमाएँ हैं
• नया AbsenceBench benchmark sequence, poetry, और GitHub PR जैसे 3 क्षेत्रों में LLM की missing information detection क्षमता का मूल्यांकन करता है
• नवीनतम मॉडल Claude-3.7-Sonnet भी 5K token context में केवल 69.6% F1-score तक ही पहुंचता है
• Transformer-आधारित attention mechanism दस्तावेज़ के 'खाली स्थान' पर प्रभावी ढंग से काम नहीं कर पाता, यही इसकी सीमा है
• यह शोध LLM में inserted information detection और missing information detection के बीच मौजूद मूलभूत कठिनाई के अंतर को दिखाता है

---

अवलोकन

• बड़े भाषा मॉडल (LLM) लंबे दस्तावेज़ों में जानकारी खोजने के प्रदर्शन में काफी बेहतर हुए हैं
• मौजूदा 'Needle in a Haystack (NIAH)' टेस्ट लंबे इनपुट में चौंकाने वाली जानकारी ढूंढने की क्षमता को मापता है, और LLM इसमें बहुत अच्छा प्रदर्शन करते हैं
• लेकिन क्या LLM स्पष्ट रूप से गायब जानकारी को पहचान सकते हैं, यह एक अलग सवाल है
• इसी के लिए AbsenceBench benchmark प्रस्तावित किया गया है, जिसमें दस्तावेज़ के कुछ हिस्से जानबूझकर हटाने के बाद मॉडल से पूछा जाता है कि क्या गायब है

AbsenceBench benchmark की व्याख्या

• AbsenceBench poetry, numerical sequences, और GitHub Pull Request(PR) इन 3 domains में मॉडल की omission detection क्षमता को मापता है
• मूल दस्तावेज़ और जानबूझकर कुछ सामग्री हटाकर बनाई गई संशोधित प्रति, दोनों LLM को साथ में दी जाती हैं, फिर देखा जाता है कि वह गायब जानकारी पहचान पाता है या नहीं
• इसका औसत context length 5K tokens है, इसलिए यह पुराने long-context tests की तुलना में एक 'mid-context' benchmark है

मूल्यांकन परिणामों के मुख्य मुद्दे

• 14 प्रमुख LLMs (जैसे GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash आदि) पर मूल्यांकन किया गया, और नवीनतम मॉडल भी लगभग 69.6% F1-score जैसी कम संख्या पर रहे
• NIAH test में LLM पहले से ही 'superhuman level' तक पहुंच चुके हैं, फिर भी AbsenceBench में प्रदर्शन 56.9% गिर जाता है
• जैसे-जैसे context length बढ़ती है, खासकर poetry domain में प्रदर्शन और गिरता है
• inference-time compute का उपयोग करने पर भी प्रदर्शन केवल 7.9% बढ़ता है, जबकि औसतन 3 गुना अधिक chain-of-thought tokens खर्च होते हैं
• इसके उलट, omission rate जितनी कम होती है, आश्चर्यजनक रूप से LLM का प्रदर्शन उतना ही खराब होता है

कारण और गहन विश्लेषण

• Transformer-आधारित self-attention mechanism के लिए 'गायब जानकारी' (खाली स्थान) पर ध्यान देना कठिन है, क्योंकि key-based attention संरचना में जो मौजूद ही नहीं है उसे ट्रैक करना स्वाभाविक रूप से मुश्किल है
• परीक्षण के दौरान, गायब हिस्सों में placeholder string जोड़ने पर प्रदर्शन औसतन 35.7% तक काफी बढ़ गया

AbsenceBench की संरचना और उदाहरण

• हर task को इस तरह परिभाषित किया गया है
  • मूल दस्तावेज़ (Dorig) और संशोधित दस्तावेज़ (Dmodified) दिए जाते हैं
  • Dorig के p% elements हटाकर Dmodified बनाया जाता है, और दोनों की तुलना करके LLM को यह निकालना होता है कि कौन-सी जानकारी गायब है; सही उत्तर का सेट (Domit)
• तीनों domains के उदाहरण:
  • Poetry: Gutenberg Poetry Corpus से कविताएँ चुनी जाती हैं और यादृच्छिक रूप से पंक्तियाँ हटाई जाती हैं
  • Numerical Sequences: यादृच्छिक रूप से बनाई गई number sequences में कुछ संख्याएँ निश्चित संभावना पर हटाई जाती हैं
  • GitHub PRs: लोकप्रिय open source PRs की diff files से बदली गई कुछ पंक्तियाँ यादृच्छिक रूप से हटाई जाती हैं

मूल्यांकन टेम्पलेट उदाहरण (poetry domain)

• सिस्टम prompt: “एक छात्र ने कविता सुनाई, लेकिन कुछ पंक्तियाँ छूट गई हो सकती हैं। ठीक-ठीक पहचानो कि कौन-सी पंक्तियाँ गायब हैं।”
• मूल कविता और सुनाई गई version दोनों दिए जाते हैं, और केवल वही पंक्तियाँ उत्तर में देने को कहा जाता है जो वास्तव में गायब हैं

मुख्य प्रयोगात्मक परिणाम

• अलग-अलग domains में दस्तावेज़ की लंबाई और omission rate बदलकर प्रयोग किए गए
• GitHub PR, poetry, और numerical sequences—तीनों में LLM गायब हिस्सों को पूरी तरह पहचान नहीं पाए
• NIAH और AbsenceBench के बीच मुख्य अंतर: NIAH में मॉडल को मौजूद key/जानकारी पर ध्यान देना होता है, जबकि AbsenceBench में 'जो मौजूद नहीं है' उस पर ध्यान देना पड़ता है, इसलिए यह संरचनात्मक रूप से अधिक कठिन है

निष्कर्ष और संकेत

• AbsenceBench दिखाता है कि LLM अभी भी 'क्या गायब है?' जैसे सवालों में कमजोर हैं
• इससे संकेत मिलता है कि व्यावहारिक उपयोग में LLM को निर्णायक के रूप में इस्तेमाल करते समय (जैसे LLM-as-a-Judge) विश्वसनीयता को लेकर सावधानी जरूरी है
• Transformer architecture की इस डिजाइन-आधारित कमजोरी को दूर करने के लिए नए approaches की जरूरत है
• AbsenceBench dataset और code सार्वजनिक हैं, और इसे LLM की omission detection क्षमता पर आगे के शोध के शुरुआती आधार के रूप में पेश किया गया है

मुख्य योगदानों का सार

• mid-context (5K tokens) दस्तावेज़ों में स्पष्ट रूप से हटाए गए तत्वों का पता लगाने के लिए नया benchmark तैयार और सार्वजनिक किया गया
• 14 नवीनतम LLMs का मूल्यांकन करके पुष्टि की गई कि inserted information detection लगभग परफेक्ट है, लेकिन missing information detection अब भी कठिन है
• inference-time compute जैसी तकनीकों की वास्तविक प्रदर्शन सुधार में सीमाएँ भी दिखाई गईं
• गायब हिस्सों में स्पष्ट placeholder डालने पर प्रदर्शन में बड़ा सुधार देखा गया
• AbsenceBench Transformer attention mechanism की मूलभूत सीमा को उजागर करने वाला एक उदाहरण है

AbsenceBench dataset की संरचना

• Poetry: एक कविता को 100 से 1000 पंक्तियों के बीच काटकर अलग-अलग लंबाई के दस्तावेज़ बनाए जाते हैं, और हर पंक्ति के स्तर पर omissions किए जाते हैं
• Numerical Sequences: पहला नंबर यादृच्छिक रखा जाता है, फिर अलग-अलग नियमों (ascending, descending, random, अलग-अलग intervals) के अनुसार अगली संख्याएँ सजाई जाती हैं, जिनमें से कुछ हटाई जाती हैं
• GitHub PRs: शीर्ष 20 hot repositories के 10 से 200 पंक्ति वाले diffs में केवल बदली गई पंक्तियाँ चुनकर कुछ हटाई जाती हैं, ताकि वास्तविक स्थितियों को दर्शाया जा सके

वास्तविक benchmark उदाहरण

• Poetry उदाहरण
  • मूल: “And so, to you, who always were / To me, I give these weedy rhymes / In memory of early times...”
  • संशोधित: “And so, to you, who always were / In memory of early times...”
  • उत्तर: “To me, I give these weedy rhymes”
• Numerical Sequences उदाहरण
  • मूल: 117, 121, 125, 129, 133, 137 ...
  • संशोधित: 117, 125, 129, 133 ...
  • उत्तर: 121, 137
• GitHub PR उदाहरण
  • PR की code change lines में कुछ विशेष पंक्तियाँ गायब हैं

उपयोग और व्यावहारिक महत्व

• व्यावहारिक रूप से यह PR diff में change omissions या दस्तावेज़ों में आवश्यक जानकारी छूट जाने जैसी स्थितियों को पहचानने की क्षमता से सीधे जुड़ा है
• review/verification automation में LLM का उपयोग करते समय omission detection के लिए अलग पूरक उपायों की जरूरत होगी

[GN⁺]

Hacker News राय

• Gerald Sussman का व्याख्यान देखने के बाद Kanizsa triangle इमेज को Claude में डालकर एक अस्पष्ट सवाल पूछा गया, ताकि यह परखा जा सके कि Claude त्रिकोण को पहचानता है या नहीं। Claude ने इमेज को सही पहचाना और उसका सार भी दिया, इसलिए इमेज को 90 डिग्री घुमाकर फिर से परीक्षण किया गया। लेकिन Claude इमेज को पहचान नहीं पाया और तत्वों की संख्या भी गलत बताई। Claude के वर्णन में ‘Pac-Man जैसे चार आंशिक वृत्त, दो पतले काले त्रिभुज या तीर-जैसी आकृतियाँ, हल्की धूसर पृष्ठभूमि’ शामिल थे

  • आगे चलकर डेटा training प्रक्रिया में सभी इमेजों के 90 डिग्री घुमाए गए संस्करण जोड़कर इस तरह की समस्या हल होने की संभावना जताई गई

  • यह राय साझा की गई कि पेपर का दायरा text documents तक सीमित है, इसलिए Kanizsa triangle प्रयोग उस चर्चा पर सीधे लागू नहीं होता। image processing के मामले में LLM अभी भी पर्याप्त परिपक्व नहीं हैं। समझाया गया कि अधिकांश vision features अलग preprocessing के बाद tokenized होकर transformer में इनपुट किए जाते हैं, और OCR, CNN-आधारित pattern recognition, अलग-अलग कोणों तथा zoom की गई इमेज जैसी preprocessing की कई अवस्थाओं का उदाहरण दिया गया

  • computation की प्रकृति को लेकर समझ की कमी की ओर इशारा किया गया। पुराने विवाद से जुड़े Hacker News चर्चा और Strange Loop व्याख्यान वीडियो के लिंक, लिंक साझा किए गए

  • यह राय दी गई कि यदि 5 पैरों वाले कुत्ते की photo LLM को दिखाई जाए, तो वह पैरों की संख्या सही नहीं पहचान पाएगा

  • abstraction generalization के उदाहरण के रूप में कहा गया कि अगर बहुत सारे बिंदु त्रिभुज के रूप में रखे जाएँ, तो मनुष्य तुरंत त्रिभुज पहचान लेता है। ऐसा महसूस किया गया कि इस तरह के सरल उदाहरणों में बुद्धिमत्ता का सार दिखता है, और बहुत बड़ी जटिलता को भी सरल पैटर्न के रूप में पहचान पाना ही अंततः IQ का अर्थ है। यह दृष्टिकोण भी रखा गया कि अगर वे बिंदु 10-आयामी cube के vertices को थोड़ा घुमाकर बने हों, तो 10-आयामी सोच में वह बहुत आसान पैटर्न होगा

• यह सार साझा किया गया कि हाल के मॉडल भी original और modified version को साथ दिखाने पर missing information पहचानने में कमजोर हैं, और पेपर के लेखकों का तर्क है कि Transformer के attention mechanism से पहले से हटाए जा चुके tokens पर ध्यान देना संभव नहीं है

  • यह राय दी गई कि असल में key तो original text में होती है, इसलिए अगर दोनों इनपुट के रूप में दिए जाएँ, तो मॉडल उस key पर ध्यान दे सकता है। Attention के नज़रिए से

    Original: {सामान्य भाग} {हटाया गया भाग} {सामान्य पिछला भाग}
    Modified: {सामान्य भाग} {सामान्य पिछला भाग}
    

    और

    Original: {सामान्य भाग} {सामान्य पिछला भाग}
    Modified: {सामान्य भाग} {जोड़ा गया भाग} {सामान्य पिछला भाग}
    

    में बहुत बड़ा अंतर नहीं है। RASP के जरिए इस तरह का algorithm लागू किया जा सकता है, ऐसा एक ठोस तरीका सुझाया गया: चरण 1 में Original/Modified tokens की स्थिति पहचानना, चरण 2 में हर token का average value निकालकर अंतर निकालना, चरण 3 में इस अंतर के सबसे निकट token को {हटाया गया भाग}/{जोड़ा गया भाग} मानना। अंतर किस दिशा में घटाया जाए, बस यही सवाल है। अगर मॉडल additions तो पकड़ता है लेकिन deletions नहीं, तो विश्लेषण यह था कि LLM सिद्धांत समझता है, पर deletion data की कमी से उसकी training कम हुई होगी

  • यह इंगित किया गया कि नवीनतम शीर्ष मॉडल (OpenAI opus, o3, Gemini 25 pro आदि) के परीक्षण परिणाम पेपर में शामिल नहीं हैं

  • यह जिज्ञासा व्यक्त की गई कि अगर vision model हो, तो क्या photo negative, image rotation आदि से training देकर सुधार संभव होगा। madlib जैसी fill-in-the-blank Q/A शैली का प्रयोग भी संभव था, ऐसा उल्लेख किया गया

  • चूँकि मॉडल-दर-मॉडल प्रदर्शन में अंतर है, इसलिए अब जब benchmark और रुचि दोनों बढ़ रहे हैं, आगे performance improvement की उम्मीद जताई गई। सुधार की पर्याप्त गुंजाइश दिखती है

• यह दावा किया गया कि attention mechanism की संरचना के हिसाब से unclassified missing parts को न ढूँढ पाना स्वाभाविक है। needle-in-a-haystack समस्या में खोजने के लिए एक निश्चित target होता है, इसलिए attention अच्छा काम करता है; लेकिन omission के मामले में क्या गायब है, यह पता नहीं होता, इसलिए पूरे context की तुलना करनी पड़ती है, और मौजूदा attention layers की सीमा सामने आती है। इसे लंबे list sorting जैसे मुद्दों से मिलता-जुलता बताया गया

  • यह विचार रखा गया कि omission खोजने वाले प्रयोगों में वास्तव में LLM को आवश्यक जानकारी (जैसे original और modified दोनों) दी जा रही है, इसलिए यह architecture की सीमा नहीं बल्कि model tuning की समस्या है। उदाहरण के लिए, जब ML paper में omission खोजी जाती है, तो मस्तिष्क ML papers के बीच तुलना करता है, Star Wars या Top Gear जैसी अप्रासंगिक यादों से नहीं; इसलिए context narrowing के जरिए यह कुशलता से काम करता है

• पेपर अभी तक न पढ़ने के बावजूद, लेखक ने attention mechanism की सीमाओं पर दी गई व्याख्या से सहमति जताई। omission में क्या गायब है, यह पहले से पता नहीं होता, इसलिए उसे सीधे ढूँढना कठिन है, और पूरे context की तुलना आवश्यक है

• AbsenceBench जैसे नए benchmarking तरीकों पर कुछ आलोचना उचित मानी गई, लेकिन इस तरह के प्रयास हो रहे हैं, इसे अपने आप में सकारात्मक माना गया और इसे बेहतर दिशा में आगे बढ़ने का अवसर समझा गया

• पेपर लेखकों की इस राय से आंशिक सहमति जताई गई कि मनुष्यों के विपरीत LLM context में missing position के आसपास भी नहीं पहुँचते, लेकिन यह सवाल उठाया गया कि architecture गणितीय रूप से कम उपयुक्त क्यों है। इस तरह के कार्यों पर fine-tuning के असर को लेकर जिज्ञासा जताई गई। यह भी कहा गया कि input छोटा हो और omissions कम हों, तो मॉडल समस्या और खराब हल करता है; मनुष्य भी एक-दो शब्द गायब होने पर अक्सर तुरंत नहीं पकड़ पाता। reasoning models ने बेहतर किया, लेकिन 100% accuracy तक न पहुँच पाना आश्चर्यजनक बताया गया। यह भी रेखांकित किया गया कि पेपर जैसी समस्या साधारण program से आसानी से हल की जा सकती है। मानव बुद्धि के कई पहलू अब भी औपचारिक रूप से परिभाषित नहीं हैं, और पेपर यह संकेत देता है कि LLM उन हिस्सों में कमजोर हो सकते हैं

• literal string diff निकालना, LLM से arithmetic करवाने जैसा over-allocation of complexity है। इसके बजाय LLM को पूरा document सूचीबद्ध कराकर सीधे तुलना करवाने जैसी reasoning शैली अधिक उपयोगी देखी गई। यह arithmetic समस्याओं को step-by-step तोड़कर हल करने से performance बढ़ने वाली प्रवृत्ति जैसा है। अच्छा प्रदर्शन करने वाले मॉडल MoE(Mixture of Experts) architecture के हो सकते हैं, और Gemini Flash के बारे में भी MoE-आधारित होने का अनुमान लगाया गया

• यदि LLM को ‘meta’ approach की अनुमति दी जाए, तो omission detection के लिए Python script खुद लिखकर चलाने से समस्या हल हो सकती है

  • लेकिन यह चिंता जताई गई कि LLM algorithmic रूप से यह नहीं पहचान पाएगा कि Python कब उपयोग करनी चाहिए। यदि हमेशा code उपयोग करने का निर्देश दिया जाए, तो त्रुटियाँ घट सकती हैं, ऐसा माना गया। यह भी कहा गया कि trivial समस्याएँ भी LLM के लिए कठिन हो सकती हैं, और ऐसी कमजोरी coding क्षमता पर भी सीमा लगा सकती है

• विशिष्ट benchmark को लेकर असंतोष व्यक्त किया गया। prompt उदाहरण में qwq-32b मॉडल ने 3-item प्रयोग में omitted item पूरी तरह सही ढूँढ लिया। यह तर्क दिया गया कि 100 items भी सही तरह हल किए जा सकते हैं, लेकिन उसके लिए बहुत अधिक tokens चाहिए होंगे। reasoning model के लिए 5000-token सीमा बहुत कम बताई गई, और दावा किया गया कि अधिक batches और simplification प्रक्रिया दोहराने पर सही उत्तर हमेशा निकाला जा सकता है। सही उत्तर पाने के लिए पूरे document को tokenize करके बार-बार तुलना करने की कार्यप्रणाली सुझाई गई। [पूरा prompt उदाहरण साझा किया गया]

  • वास्तव में HN headline 26 में से 3 हटाई गई सूची लेकर qwq-32b पर स्वयं परीक्षण किया गया, और 50,000 tokens से कम उपयोग में सभी को सही पहचाना गया, ऐसा प्रयोग के जरिए दिखाया गया। प्रयोग सामग्री लिंक

  • संख्या गिनती से समस्या को थोड़ा सरल बनाना अर्थहीन शोध बताया गया; ज़ोर दिया गया कि इस अध्ययन का वास्तविक लक्ष्य LLM की उन सीमाओं को समझना है जिन्हें sorting/classification से हल नहीं किया जा सकता

• Hamlet के संवाद में ‘utter love’ होने-न होने पर ChatGPT से पूछने का वास्तविक अनुभव साझा किया गया। ChatGPT ने कहा कि उसने Hamlet के पूरे संवाद की जाँच की और वह शब्द नहीं है। लेकिन online मूल पाठ खोजने पर वह तुरंत मिल गया। वह अंश ChatGPT को दिखाने पर उसने तुरंत स्वीकार किया, माफी माँगी, और पूरा संवाद फिर से दिया। इसे “आख़िरकार मानव स्मृति ChatGPT index से बेहतर निकली” जैसा अनुभव बताया गया

  • वास्तविक सही उत्तर Act 2, Scene 1 है, और वक्ता Polonius है, यह सुधार भी जोड़ा गया

  • यह स्वीकार किया गया कि search loop या tools के बिना LLM की recall क्षमता बहुत कमजोर होती है। 4o मॉडल भी search के बिना विफल रहा, और सही उत्तर के लिए search फीचर ज़रूरी था। इससे यह insight निकाला गया कि “समस्या के अनुरूप सही tool का सही उपयोग” और अधिक महत्वपूर्ण होता जा रहा है

• LLM sensory input पर आधारित presence detection तो कुछ हद तक कर सकते हैं, लेकिन absence detection कठिन है क्योंकि वहाँ sensory input ही नहीं होता। उसे पहचानने के लिए बहुत मजबूत world model और expectation चाहिए। यह प्रस्ताव रखा गया कि इस प्रकार का higher-order neurological task अभी LLM की तुलना में केवल जैविक जीवों की विशिष्ट क्षमता हो सकता है

  • LLM में design के स्तर पर consistency समस्या संभव है; कुछ भाग साधारण memorization पर और कुछ मार्ग advanced pattern matching पर निर्भर हो सकते हैं

  • real-time thinking की तुलना में LLM ‘स्थिर और जमे हुए’ reality के आधार पर reasoning करते हैं, ऐसा कहा गया; temporal aspect भी एक सीमा है

  • वास्तविक absence detection memory से गहराई से जुड़ी है। उदाहरण के लिए, अगर मेज़ पर रखा पेन गायब हो जाए, तो मस्तिष्क पिछले sensory input (पेन देखने की स्मृति) और वर्तमान स्थिति की तुलना कर उसकी अनुपस्थिति पहचानता है। यह राय दी गई कि फिलहाल thinking स्वयं केवल जैविक जीवों की विशिष्ट विशेषता है