LLM सौंपे गए काम में दस्तावेज़ को नुकसान पहुँचाते हैं

 (arxiv.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DELEGATE-52 एक बेंचमार्क है जो यह मापता है कि जब उपयोगकर्ता लंबे दस्तावेज़ संपादन कार्य LLM को सौंपते हैं, तो delegated workflow में दस्तावेज़ कितनी निष्ठा से सुरक्षित रहता है
  • यह बेंचमार्क 52 विशेषज्ञ क्षेत्रों में गहन दस्तावेज़ संपादन की आवश्यकता वाले कार्यों को कवर करता है, जिनमें coding, crystallography और musical notation शामिल हैं, और उदाहरण simulation 20 लगातार कार्यों के delegation से बना है
  • 19 LLM पर किए गए प्रयोगों में Gemini 3.1 Pro, Claude 4.6 Opus और GPT 5.4 जैसे frontier models भी लंबे workflow के अंत तक औसतन दस्तावेज़ की सामग्री का 25% नुकसान पहुँचा देते हैं
  • दस्तावेज़ क्षति कम बार होती है, लेकिन गंभीर त्रुटियों के रूप में सामने आती है, और दस्तावेज़ का आकार, interaction की लंबाई, तथा distractor files बढ़ने पर यह degradation और बढ़ती है; agentic tools का उपयोग भी प्रदर्शन नहीं सुधारता
  • मौजूदा LLM को delegated document editing में भरोसेमंद प्रतिनिधि मानना कठिन है, और microsoft/DELEGATE52 तथा datasets/microsoft/DELEGATE52 को DELEGATE-52 से संबंधित सामग्री के रूप में सार्वजनिक किया गया है

delegated editing की विफलता के पैटर्न

  • delegated काम इस भरोसे पर आधारित होता है कि उपयोगकर्ता कार्य LLM को सौंपेगा और LLM दस्तावेज़ में त्रुटियाँ डाले बिना काम पूरा करेगा
  • 19 LLM पर किए गए बड़े पैमाने के प्रयोगों में मौजूदा models delegation की प्रक्रिया में दस्तावेज़ को degrade कर देते हैं
  • अन्य models frontier models की तुलना में और अधिक गंभीर रूप से विफल होते हैं
  • दस्तावेज़ क्षति लंबी interactions के दौरान जमा होती जाती है और चुपचाप दस्तावेज़ को खराब कर देती है

उदाहरण के रूप में दिखाए गए दस्तावेज़ परिवर्तन

  • Graph Diagrams क्षेत्र का Linux Kernel Architecture दस्तावेज़ Gemini 3.1 Pro में मूल की तुलना में 4 बार के बाद 79%, 10 बार के बाद 49%, 14 बार के बाद 48%, और 20 बार के बाद 48% स्तर पर दिखाया गया
  • Textile Patterns क्षेत्र का 12-Shaft Twill Diamond दस्तावेज़ Claude 4.6 Opus में मूल की तुलना में 4 बार के बाद 100%, 10 बार के बाद 40%, 14 बार के बाद 27%, और 20 बार के बाद 34% स्तर पर दिखाया गया
  • 3D Objects क्षेत्र का ActionBoy Palm Tree दस्तावेज़ GPT-5.2 में मूल की तुलना में 4 बार के बाद 100%, 10 बार के बाद 31%, 14 बार के बाद 15%, और 20 बार के बाद 6% स्तर पर दिखाया गया

सार्वजनिक सामग्री

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की टिप्पणियाँ

  • टूल उपयोग के नतीजों पर संदेह है

    लंबे टेक्स्ट को LLM से कई बार आगे-पीछे गुजारने पर वह खराब हो जाएगा, इसमें हैरानी की बात नहीं है। जो लोग LLM का अक्सर इस्तेमाल करते हैं, वे पहले से जानते हैं कि ऐसा नहीं करना चाहिए

    पेपर में यह देखकर हैरानी हुई कि टूल उपयोग से मदद नहीं मिली, लेकिन साथ ही यह भी बताया गया कि उन्होंने सिर्फ “बेसिक agent harness” लागू किया था और यह कोई आधुनिक, अच्छी तरह optimized सिस्टम नहीं था

    असली harness में सिर्फ read_file() और write_file() थे, इसलिए यह लगभग राउंड-ट्रिप प्रोसेसिंग में बस एक अतिरिक्त कदम जोड़ने जैसा है। आजकल coding agent harnesses फ़ाइल एडिटिंग टूल्स के डिज़ाइन पर बहुत मेहनत करते हैं, उदाहरण के लिए Claude edit tool bundle है: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    str_replace और insert कमांड पूरे फ़ाइल को दोबारा लिखने वाले जोखिमभरे एडिट से बचने में अहम हैं

    कम से कम run_python() टूल तो दिया गया है, इसलिए बेहतर मॉडल शायद इसका इस्तेमाल करके string replacement चला सकते थे। मैं देखना चाहूँगा कि क्या system prompt ने Python-आधारित manipulation को प्रोत्साहित किया था, या फिर फ़ाइल पढ़कर दोबारा लिखने की ओर धकेला था

    harness का कोड यहाँ मिला: https://github.com/microsoft/delegate52/blob/main/model_agen...

    संबंधित prompt अंश में कहा गया है कि “आप चाहे प्रोग्रामिंग तरीके से जाएँ या सीधे फ़ाइल लिखें, जो तरीका आपको सबसे प्रभावी लगे उसका उपयोग कर सकते हैं”

    अक्सर ऐसे पेपरों में होता यही है कि नतीजे मॉडल से ज़्यादा, पेपर लेखकों द्वारा इस्तेमाल किए गए harness डिज़ाइन को दर्शाते हैं। चाहे अनुभवी AI engineer हों या prompt engineer, मेरा मानना है कि harness को ही iterative तरीके से बेहतर बनाकर इस टेस्ट में और अच्छे नतीजे पाए जा सकते हैं

    • मैं ज़्यादातर सहमत हूँ, लेकिन “जो लोग LLM का अक्सर इस्तेमाल करते हैं, वे पहले से जानते हैं कि ऐसा नहीं करना चाहिए” वाली बात अपवाद है

      अभी जिस तरह संगठनों और टीमों में LLM अपनाने की लहर चल रही है, उसमें बहुत से लोग, शायद बहुमत भी, रोज़ LLM इस्तेमाल करते हैं लेकिन harness जैसी तकनीकी चीज़ों के पास भी नहीं गए हैं

      ऐसे लोगों के लिए यहाँ बताया गया व्यवहार बड़ी समस्या है

    • थोड़ी संबंधित बात है, लेकिन मैं ऐसा harness देखना चाहूँगा जो ed को डिफ़ॉल्ट फ़ाइल edit/read टूल की तरह इस्तेमाल करे। Claude जो bash चलाता है उसका आधा हिस्सा वैसे भी sed जैसा दिखता है, और अगर ed में state बनी रहे तो शायद मदद मिले

      जब पूरा editor बहुत ज़्यादा bandwidth^H tokens खा जाए तो क्या करें? मानक editor ed का इस्तेमाल करें

    • यह LLM कार्य को थोड़ा strawman बनाने जैसा मामला है

      editing task में सिर्फ programmatic edit commands की अनुमति होनी चाहिए, और टेक्स्ट को LLM के भीतर से नहीं गुजरना चाहिए। LLM को टेक्स्ट का विश्लेषण करना चाहिए और feedback के आधार पर लक्ष्य पूरा करने वाले commands आउटपुट करने चाहिए

    • HN पर लोग नतीजों की जितनी हो सके उतनी नकारात्मक व्याख्या करने की प्रवृत्ति रखते हैं। शायद इसलिए कि उन्हें यह अपने काम और पहचान के लिए खतरा लगता है

      सच तो यह है कि किसी दस्तावेज़ को पढ़ने के बाद उसमें बदलाव शामिल करके पूरे दस्तावेज़ को फिर से बोलकर edit करने में इंसान 25% degradation से भी बदतर परिणाम दे सकता है। इंसान 0% degradation भी हासिल कर सकता है, लेकिन उसके लिए दस्तावेज़ को सैकड़ों बार इनपुट लेकर कंठस्थ करना पड़ेगा। LLM में इसका समतुल्य training है, और अगर दस्तावेज़ को LLM में train कर दिया जाए तो इस मामले में वह कंठस्थ कर चुके इंसान की editing के बराबर हो सकता है

      लेकिन ऊपर की बात मुख्य मुद्दा नहीं है। LLM इंसानों से कुछ मायनों में मिलते-जुलते हैं, इसलिए harness को इस तरह डिज़ाइन करना चाहिए कि वह इंसानों की तरह retrieval और surgical edits के ज़रिए edit करे। सभी coding agents इसी तरह edit करते हैं, इसलिए यह पेपर ज़्यादा प्रासंगिक नहीं लगता

    • चाहे resource constraints की वजह से हो या simplification के लिए, लेकिन समझने में कठिन methodology की वजह से ऐसे पेपर दुर्भाग्य से अपनी क़ीमत खो देते हैं

  • मैं पहले से कहता आया हूँ कि किसी भी टेक्स्ट पर AI की परत चढ़ाने से गुणवत्ता घटती है, और दोहराव के साथ यह जमा होती जाती है

    इसके लिए मुझे “semantic ablation” शब्द सबसे पसंद है: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • मैं इसे औसत बुद्धिमत्ता की ओर प्रत्यावर्तन कहता रहा हूँ
    • मैं जानना चाहता हूँ कि “दोहराव के साथ” से मतलब एक ही session के भीतर दोहराव है, या हर बार नए session या नए context window में

  • बात यह है कि “delegation के लिए trust चाहिए। यह अपेक्षा होनी चाहिए कि LLM दस्तावेज़ में त्रुटियाँ डाले बिना काम ईमानदारी से पूरा करेगा”, और यही कारण है कि दर्जनों Markdown फ़ाइलों और prompt-ritual वाले harness विज्ञापन की तरह काम नहीं करते। असल में यह लगभग agent engineering नाम की छद्म-विज्ञान जैसी चीज़ है

    agent engineering भी अंततः तथाकथित prompt engineering से लगभग वही चीज़ है, बस अब prompts दर्जनों Markdown फ़ाइलों और directories में बिखरे हुए हैं

  • हाल में LLM पर जो कुछ पढ़ा है, उनमें यह सबसे कम चौंकाने वाली बात थी

    LLM कुछ-कुछ JPEG meme की तरह हैं। जैसे JPEG को हर बार save करने पर गुणवत्ता थोड़ा-थोड़ा गिरती है और आखिर में पहचानना मुश्किल हो जाता है, वैसे ही ये काम करते हैं

    बस LLM में शुरुआती बिंदु intent होता है। हर बार LLM से गुज़रने पर intent degrade होता है, और सटीक scientific paper जैसी चीज़ों में paraphrase करते समय सूक्ष्म nuance और precision थोड़ा-थोड़ा गायब हो जाते हैं

    LLM औसत की ओर लौटने वाली मशीनें हैं। जितना वर्तमान context या workload उनकी training range से बाहर होगा, उतनी ही वे उसे खींचकर एक समान, अमूर्त equilibrium की ओर ले जाने की प्रवृत्ति दिखाएँगी

    • LLM के साथ coding करते हुए मैंने यह साफ़ अनुभव किया है। feature work को तेजी से निपटाने के बाद, भले लगा हो कि मैं काफी सावधान था, बाद में जब छोटे code snippets को ध्यान से देखता हूँ तो अक्सर “हे भगवान” वाला पल आता है

      फिर कुछ घंटे लगाकर पूरी चीज़ दोबारा खंगालनी पड़ती है, और जहाँ चीज़ें मनचाहे तरीके से नहीं हुईं, जहाँ मैं अस्पष्ट था, या जहाँ LLM की अजीब आदतें सक्रिय हुईं, उन्हें सावधानी से ठीक करना पड़ता है

      code quality खुद में ज़रूरी है, लेकिन मुझे ठीक यही iterative compression समस्या परेशान करती है। अगर codebase साफ़ हो और दिमाग़ में उसका मॉडल updated हो, तो LLM feature work में तेजी से मदद करके भी codebase को ठीक-ठाक हालत में छोड़ सकता है। लेकिन जैसे ही LLM codebase को गंदा करना शुरू करता है, पुरानी गलतियाँ और गलतफ़हमियाँ जमा होने लगती हैं, और उसके ज़्यादा से ज़्यादा चीज़ें गलत करने की संभावना बढ़ जाती है। इसलिए LLM को फिर से इस्तेमाल करने से पहले उसे सही स्थिति में “restore” करना ज़रूरी लगता है

    • यह नतीजा वास्तव में दिलचस्प और प्रासंगिक तब होता है जब coding agent बड़े source files को कई छोटे files में तोड़ता है। Opus और Claude Code इंसान की तरह copy/paste जैसे ऑपरेशन इस्तेमाल करने के बजाय, source code के लंबे हिस्सों को याद से सुना कर नए files में डालने की कोशिश करते हैं

      फ़ाइल move करना थोड़ा आसान है। LLM कभी-कभी फ़ाइल को याद से दोबारा बोलने की कोशिश करता है, लेकिन अगर आप git mv इस्तेमाल करें और compiler errors ठीक करने को कहें, तो वह आम तौर पर ठीक कर लेता है

      इसके विपरीत, सामान्य editing उचित model और tool setup के साथ आमतौर पर अच्छी तरह काम करती है। Qwen3.6 27B भी इस स्तर तक ठीक है। in-place edits के लिए git diff से unexpected changes की समीक्षा भी की जा सकती है

    • इसे दिखाने वाला बच्चों का एक खेल भी है: https://en.wikipedia.org/wiki/Telephone_game

    • मेरे एक सहकर्मी LLM को “bullshit layer” कहते हैं। इसका मतलब पूरी तरह अपमान करना नहीं है, बल्कि यह रेखांकित करना है कि जब भी आप किसी चीज़ को LLM से गुजारते हैं, दूसरी तरफ़ से निकला परिणाम आपकी अपेक्षा या इच्छा से अलग हो सकता है

      यह कुछ वैसा है जैसे बार में कुछ पैग पी चुका कोई व्यक्ति आपको कहीं पढ़ी हुई ऑनलाइन जानकारी सुनाए। वह सही भी हो सकता है, लेकिन गलत होने का जोखिम भी काफ़ी है

      उदाहरण के लिए, API कॉल करके डेटा इकट्ठा करने और रिपोर्ट बनाने में LLM का उपयोग नहीं करना चाहिए। ऐसा करने का मतलब निर्णायक डेटा को bullshit layer से गुजारना है, इसलिए नतीजे पर भरोसा नहीं किया जा सकता। इसके बजाय LLM का उपयोग उस code को लिखने में करना बेहतर है जो निर्णायक डेटा से निर्णायक output बनाता हो

      मैंने सहकर्मियों को API से आए निर्णायक डेटा का सारांश LLM से बनवाते देखा है, और रिपोर्ट कभी सही होती है तो कभी उतनी ही बुरी तरह भटक जाती है। आप क्या देख रहे हैं, इस पर निर्भर करते हुए यह विनाशकारी जोखिम बन सकता है

    • मैंने यह resume editing में झेला है। LLM ने मेरी resume से वे सारी चीज़ें हटा दीं जो मुझे औसत अनुभव वाले junior engineer के ढेर से अलग बनाती थीं। जो भी खास, अनोखा या अलग था, आखिरकार सब सामान्य वाक्यांशों से बदल दिया गया

      मैंने वह आउटपुट इस्तेमाल नहीं किया, लेकिन LLM का बार-बार यह ज़ोर देना कि यह पुराने से बेहतर है, बेहद झुंझलाने वाला था

      पूरे resume की दिशा तय करने की बजाय, LLM मेरे लिए तब कहीं ज़्यादा उपयोगी रहा जब मैंने उससे बहुत छोटे हिस्सों पर सुझाव लिए, जैसे एक वाक्य या तीन वाक्यों के edit

  • समस्या यह है कि हम LLM से बहुत ज़्यादा काम करवा रहे हैं। agents को इस तरह डिज़ाइन करना चाहिए कि वे LLM का उपयोग natural language intent को deterministic process में अनुवाद करने वाली जितनी हो सके उतनी पतली परत के रूप में करें, और LLM राउंड-ट्रिप को न्यूनतम रखें

    • जो भी व्यक्ति थोड़ा भी जटिल काम करने की कोशिश करेगा, उसके लिए यह बात साफ़ हो जाती है। preprocessing flow, semantic targeting, और न्यूनतम context calls को LLM API के साथ जोड़कर pipeline बनाएं, तो एक शक्तिशाली automation step मिल सकता है

      अलग validation steps के साथ जोड़ने पर LLM एक खिलौने से उपयोगी टूल में बदल जाता है

    • जब तक इंसान भी ऐसे iterative process के भीतर न हो, तभी उसे सचमुच automated process कहा जा सकता है

  • मैं आम तौर पर agents को निर्देश देता हूँ कि document writing को सिर्फ अंतिम rendering stage की तरह लें। LLM बिखरे हुए ज्ञान को इकट्ठा करके बुनने में बहुत सक्षम हैं, इसलिए मैं ज्ञान को composable ideas और facts के रूप में संग्रहीत करना पसंद करता हूँ

    व्यवहार में जो तरीका अच्छा चला, वह यह था कि agent को एक directory दी जाए और कहा जाए कि हर मिले हुए fact या finding के लिए अलग Markdown फ़ाइल बनाए। हर फ़ाइल में खोजने में आसानी के लिए शुरुआत में metadata डाला जाए

    इससे ज़्यादातर काम “अंतिम document format में ही बार-बार शोध और संग्रह” करने वाले उलझे हुए रूप से अलग होकर, “दस्तावेज़ के काम आने वाले facts और findings की जाँच” और “दस्तावेज़ को assemble करना” जैसे अधिक cohesive कामों में बंट जाता है

    यह पूरा समाधान नहीं है, लेकिन इंसान के काम करने की तरह findings की reusability बेहतर हो जाती है

  • क्या यह इंसानों पर भी लागू नहीं होता? बच्चे “telephone game” खेलकर देखते ही हैं कि संदेश कैसे बिगड़ता है। समाधान है single source of truth देना

  • मैं इस तरह के degradation से लड़ने के लिए टूल बना रहा हूँ: https://github.com/JigSpec/JigSpec

  • यहाँ का evaluation method मुझे सचमुच बहुत पसंद आया। reversible steps की chain को आगे-पीछे चलाकर fidelity टेस्ट करने का तरीका है

    यह प्रभावशाली था कि ऐसे कामों में भी, जो ऊपर से कंप्यूटर के लिए आसान लगते हैं, frontier models errors जमा करते जाते हैं

    मैं जानना चाहूँगा कि Python में मिले मजबूत नतीजे सिर्फ Python-specific evaluation का असर हैं, या क्या वे दूसरी आम general-purpose भाषाओं में भी दिखते हैं, और क्या यह training process के किसी खास घटक की वजह से है

  • हमें पहले से मोटे तौर पर पता था कि मॉडल अनगिनत छोटी गलतियों, यानी “हज़ार कटों” से नहीं हारते। कुछ rounds में वे लगभग पूरी तरह पुनर्निर्माण कर लेते हैं, फिर कुछ rounds में एक ही बार में 10–30 से ज़्यादा points खो देने वाली catastrophic failure होती है

    इसी तरह, कमजोर models में degradation मुख्यतः content deletion से आता है, जबकि frontier models में degradation content corruption से आता है। यही वजह है कि हम harness, temperature जैसी चीज़ों को इधर-उधर समायोजित करते रहते हैं