🤖 AI

When Helping Hurts and How to Fix It: Multi-Agent Debate for Data Cleaning

यह शोध पत्र प्रकट करता है कि जहाँ मल्टी-एजेंट डिबेट अक्सर आलोचना-प्रेरित भ्रम के कारण डेटा जनरेशन को कमतर कर देती है, वहीं यह त्रुटि का पता लगाने में महत्वपूर्ण रूप से सुधार करती है, जिससे एक व्युत्पन्न स्थिति और कोड-एग्जीक्यूशन ग्राउंडिंग के साथ एक विशिष्ट एडवरसैरियल कॉन्फ़िगरेशन प्राप्त होता है जो जनरेटिव कार्यों पर सिंगल-एजेंट मॉडल से बेहतर प्रदर्शन करने के लिए डिबेट का सफलतापूर्वक लाभ उठाता है।

मूल लेखक: Chirag Parmar, Akshat Mehta, Henglin Wu, Jagadish Ramamurthy, Shweta Medhekar

प्रकाशित 2026-06-03

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Chirag Parmar, Akshat Mehta, Henglin Wu, Jagadish Ramamurthy, Shweta Medhekar

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आपके पास एक बहुत ही बुद्धिमान, मेहनती सहायक है (मान लीजिए कि वे जेनरेटर (Generator) हैं) जिनका काम एक बिखरी हुई स्प्रेडशीट को साफ करना है। वे अपने काम में बहुत अच्छे हैं, लेकिन कभी-कभी वे भ्रमित हो जाते हैं या तथ्य बना लेते हैं (हैलुसिनेशन/hallucinations), जैसे कि किसी ऐसे कॉलम को ठीक करने की कोशिश करना जो मौजूद ही नहीं है।

मदद के लिए, आपने एक क्रिटिक (Critic) को काम पर रखा है—एक अन्य बुद्धिमान सहायक जिसका एकमात्र काम यह है कि आपके द्वारा "सेव" बटन दबाने से पहले पहले वाले सहायक के काम की दोबारा जांच करना। आप सोच सकते हैं, "दो सिर एक से बेहतर होते! अगर वे आपस में बहस करेंगे, तो अंतिम परिणाम एकदम सटीक होगा।"

यह शोध पत्र पूछता है: क्या यह "दो-लोगों की बहस" वास्तव में मदद करती है, या यह चीजों को और बिगाड़ देती है?

इसका उत्तर आश्चर्यजनक रूप से "यह निर्भर करता है" है। वास्तव में, बहस वास्तव में काम को उतना ही नुकसान पहुँचा सकती है जितना कि वह मदद करती है, यह कार्य के प्रकार पर निर्भर करता है।

यहाँ उनके निष्कर्षों का सरल उपमाओं (analogies) का उपयोग करके विवरण दिया गया है:

1. "मदद बनाम नुकसान" का स्विच

शोधकर्ताओं ने इस सेटअप का परीक्षण 6,000 से अधिक अलग-अलग सफाई कार्यों पर किया। उन्होंने एक अजीब सा उतार-चढ़ाव प्रभाव पाया:

जब यह नुकसान पहुँचाता है (द "कन्फ्यूज्ड शेफ" परिदृश्य):
कल्पना कीजिए कि जेनरेटर एक जटिल रेसिपी बनाने वाला शेफ है। क्रिटिक एक फूड क्रिटिक है जो कहता है, "मुझे नहीं लगता कि आपको नमक की आवश्यकता है," या "यह सामग्री मौजूद ही नहीं है।"
- यदि रेसिपी ओपन-एंडेड है (जैसे "एक नया व्यंजन बनाएं"), तो क्रिटिक केवल अनुमान लगा रहा हो सकता है। शेफ, क्रिटिक को खुश करने के चक्कर में, नमक हटा देता है या गलत सलाह के आधार पर रेसिपी बदल देता है।
- परिणाम: शेफ अकेले खाना बनाने की तुलना में एक खराब व्यंजन तैयार करता है। क्रिटिक के "गलत अनुमान" शेफ को भ्रमित कर देते हैं, जिससे शेफ अपने अच्छे विचारों को त्याग देता है। शोध पत्र इसे क्रिटीक-इंड्यूस्ड कन्फ्यूजन (CIC) कहता है।
जब यह मदद करता है (द "स्पॉट द डिफरेंस" परिदृश्य):
अब कल्पना कीजिए कि जेनरेटर दो चित्रों के बीच "अंतर पहचानो" (Spot the Difference) खेल खेल रहा है। यहाँ क्रिटिक का काम यह बताना है कि त्रुटियाँ कहाँ हैं।
- यहाँ, उत्तर या तो "हाँ, यह एक त्रुटि है" या "नहीं, यह ठीक है" होता है। यह एक तथ्य है।
- परिणाम: क्रिटिक तथ्यों की आसानी से जांच कर सकता है। यदि जेनरेटर कोई त्रुटि छोड़ देता है, तो क्रिटिक उसे पकड़ लेता है। यदि जेनरेटर किसी ऐसी जगह की ओर इशारा करता है जो त्रुटि नहीं है, तो क्रिटिक कहता है, "नहीं, यह वास्तव में ठीक है।"
- परिणाम: बहस यहाँ पूरी तरह से काम करती है, त्रुटियों को पकड़ती है और गलत चेतावनियों को हटाती है।

2. बहसों के लिए "स्वर्ण नियम"

लेखकों ने एक सरल फॉर्मूला बनाया है जिससे यह तय किया जा सके कि कब एक बहस टीम का उपयोग करना है और कब कार्यकर्ता को अकेले काम करने देना है। इसे बचाव बनाम क्षति (Rescue vs. Damage) स्केल की तरह समझें:

बहस टीम का उपयोग तब करें यदि:
1. क्रिटिक आसानी से तथ्यों की जांच कर सके (जैसे कि मानचित्र देखना या कोड टेस्ट चलाना)।
2. यदि क्रिटिक को कोई गलती मिलती है, तो उसे ठीक करना आसान हो।
3. जेनरेटर पहले से ही पूर्ण नहीं है (सुधार की गुंजाइश है)।
- उपमा: यदि क्रिटिक आवर्धक लेंस (magnifying glass) के साथ एक जासूस है और जेनरेटर एक गवाह है, तो जासूस मदद कर सकता है।
बहस टीम को छोड़ दें यदि:
1. क्रिटिक को काम की जांच करने के लिए अनुमान या "अंतर्ज्ञान" (gut feeling) का उपयोग करना पड़ता है।
2. जेनरेटर पहले से ही बहुत अच्छा काम कर रहा है।
- उपमा: यदि क्रिटिक केवल अनुमान लगा रहा है और जेनरेटर पहले से ही एक मास्टर शेफ है, तो क्रिटिक शेफ के आत्मविश्वास को बिगाड़ देगा और भोजन खराब कर देगा।

3. "सेल्फ-चेकिंग" क्यों काम नहीं करती

आप सोच सकते हैं, "क्यों न जेनरेटर से ही अपने काम की जांच करवाई जाए?"

शोध पत्र का निष्कर्ष: नहीं। यदि जेनरेटर अपने काम की जांच करता है, तो यह एक छात्र द्वारा अपना स्वयं का टेस्ट ग्रेड करने जैसा है। वे उन्हीं गलतियों को मिस कर देते हैं जो उन्होंने पहली बार में की थीं।
समाधान: आपको एक अलग व्यक्ति (क्रिटिक) की आवश्यकता है जो ताजी आँखों से काम को देखे। लेकिन, उस क्रिटिक को प्रमाण की आवश्यकता होगी।

4. जादुई समाधान: "एविडेंस-गेटेड" बहस (Evidence-Gated Debates)

शोध पत्र ने एक तरीका खोजा जिससे कठिन "कुकिंग" (जेनरेटिव) कार्यों के लिए भी बहस को सफल बनाया जा सके।

समस्या: क्रिटिक चीजों को बदलने के लिए कारण बना रहा था।
समाधान: क्रिटिक को अपना काम साबित करने के लिए मजबूर करें। क्रिटिक को यह साबित करने के लिए कोड लिखना होगा या स्प्रेडशीट के किसी विशिष्ट सेल की ओर इशारा करना होगा कि कुछ गलत क्यों है।
परिणाम: जब क्रिटिक को अपने तर्क के लिए सबूत देने होते हैं, और जेनरेटर केवल साबित किए गए बिंदुओं को ही सुनता है, तो बहस अचानक बहुत प्रभावी हो जाती है। यह एक अदालती मामले की तरह है जहाँ वकील को केवल भाषण देने के बजाय भौतिक साक्ष्य दिखाने होते हैं।

सारांश

बहस डेटा में त्रुटियां खोजने के लिए बेहतरीन है (जैसे टाइपो या गायब नंबर को पहचानना) क्योंकि तथ्यों की जांच करना आसान है।
बहस नई चीजें बनाने के लिए खतरनाक है (जैसे पूरी नई सफाई योजना लिखना) क्योंकि क्रिटिक गलत अनुमान लगा सकता है, और जेनरेटर बिना सोचे-समझे गलत सलाह का पालन करेगा।
सीक्रेट सॉस (Secret Sauce): यदि आपको रचनात्मक कार्यों के लिए बहस का उपयोग करना ही है, तो क्रिटिक को अपने दावों के समर्थन में ठोस सबूत (जैसे कोड या डेटा पॉइंट) अवश्य प्रदान करने चाहिए, अन्यथा पूरी प्रक्रिया विफल हो जाएगी।

संक्षेप में: अपने सहायक के साथ बहस तब तक न करें जब तक वे आपको रसीदें (सबूत) न दिखा सकें।

तकनीकी सारांश: जब मदद नुकसान पहुँचाती है और इसे कैसे ठीक करें: डेटा क्लीनिंग के लिए मल्टी-एजेंट डिबेट

समस्या विवरण

डेटा क्लीनिंग ऐतिहासिक रूप से एक डेटा इंजीनियर के समय का 60-80% हिस्सा लेती है। जबकि वर्कफ्लो जनरेशन, विसंगति पहचान (anomaly detection), और पाइपलाइन ऑर्केस्ट्रेशन के माध्यम से इसे स्वचालित करने के लिए लार्ज लैंग्वेज मॉडल्स (LLMs) को तेजी से तैनात किया जा रहा है, वे मतिभ्रम (hallucination) के प्रति संवेदनशील बने हुए हैं। एक महत्वपूर्ण विफलता मोड तब होता है जब एक LLM गैर-मौजूद कॉलमों को प्रस्तावित करता है या वैध रिकॉर्ड को हटा देता है, जिससे डेटा चुपचाप दूषित हो जाता है।

मल्टी-एजेंट डिबेट, जहाँ एक प्रतिकूल क्रिटिक (Critic) एक जनरेटर (Generator) के प्रस्तावों को चुनौती देता है, एक शमन रणनीति (mitigation strategy) के रूप में प्रस्तावित की गई है। हालाँकि, मौजूदा मूल्यांकन सीमित तर्क कार्यों (जैसे अंकगणित, तथ्यात्मक QA) पर केंद्रित हैं जिनका उत्तर स्थान छोटा होता है। डेटा क्लीनिंग मौलिक रूप से भिन्न है, जिसमें विशिष्ट टेबल स्कीमा में ग्राउंडिंग की आवश्यकता होती है और निष्पादन योग्य संचालन (executable operations) उत्पन्न करने होते हैं। पिछले अध्ययनों ने यह निर्धारित नहीं किया है कि क्या डिबेट डेटा क्लीनिंग के पूर्ण स्पेक्ट्रम में मदद करती है या नुकसान पहुँचाती है, और न ही उन्होंने इसके प्रभाव की भविष्यवाणी करने के लिए एक सिद्धांत-आधारित ढांचा स्थापित किया है। ऐसे ढांचे के बिना, अभ्यासकर्ताओं को महंगे परीक्षण-और-त्रुटि (trial-and-error) का सामना करना पड़ता है, जिससे जेनरेटिव कार्यों पर डिबेट तैनात करने का जोखिम बढ़ जाता है जहाँ यह कंप्यूट लागत को 4-7 गुणा बढ़ाते हुए आउटपुट गुणवत्ता को कम कर सकता है।

कार्यप्रणाली

लेखकों ने तीन बेंचमार्क, चार मॉडल परिवारों (Claude 4 Sonnet, Gemini 3.1 Pro, Qwen3 235B, DeepSeek R1) और 6,000 से अधिक टास्क-कंडीशन पेयर्स पर एक नियंत्रित प्रयोग किया।

बेंचमार्क:

AutoDCWorkflow: मल्टी-स्टेप क्लीनिंग वर्कफ्लो जनरेशन से जुड़े 142 कार्य (फैक्टुअल कंसिस्टेंसी और सेल-लेवल एक्यूरेसी के माध्यम से मूल्यांकित)।
MMTU: टेबल समझने के कार्यों (एरर डिटेक्शन, डेटा इम्प्यूटेशन, एंटिटी मैचिंग, स्कीमा मैचिंग) को कवर करने वाले 200 प्रश्न।
MaTElDa: इंजेक्ट की गई त्रुटियों के साथ 1,173 वास्तविक दुनिया की टेबल्स, सेल-लेवल प्रिसिजन, रिकॉल और F1 के लिए मूल्यांकित।

प्रायोगिक डिजाइन:

टोपोलॉजी: एक जनरेटर-क्रिटिक आर्किटेक्चर जहाँ एक जनरेटर स्ट्रक्चर्ड JSON आउटपुट प्रस्तावित करता है और एक प्रतिकूल क्रिटिक उन्हें चुनौती देता है।
चर (Variables): अध्ययन ने प्रतिकूल तीव्रता (6 क्रिटिक प्रॉम्प्ट वेरिएंट), गुमनामी (anonymity), कार्य अलगाव (task isolation), और आउटपुट कार्डिनैलिटी को मैनिपुलेट किया।
ग्राउंडिंग: एक फैक्टोरियल प्रयोग ने कोड-एग्जीक्यूशन ग्राउंडिंग (क्रिटिक सैंडबॉक्स में पायथन/पैंडास क्वेरी चलाता है) और एविडेंस-गेटेड जनरेशन (जनरेटर केवल विशिष्ट डेटा साक्ष्य उद्धृत करने वाले फीडबैक को स्वीकार करता है) के प्रभाव का परीक्षण किया।
नियंत्रण (Controls): तुलनाओं में सिंगल-एजेंट बेसलाइन, सेल्फ-वेरिफिकेशन (समान टूल के साथ सिंगल एजेंट), और सेल्फ-कंसिस्टेंसी (मेजॉरिटी वोटिंग) शामिल थे।

मुख्य योगदान

1. डिबेट बेनिफिट कंडीशन (Debate Benefit Condition)

पेपर एक औपचारिक स्थिति (condition) व्युत्पन्न करता है जो भविष्यवाणी करती है कि कब डिबेट आउटपुट की गुणवत्ता में सुधार करती है। डिबेट तब सहायक होती है जब गलत आउटपुट को बचाने की संभावना, सही आउटपुट को नष्ट करने की संभावना से अधिक होती है। औपचारिक रूप से, डिबेट तब फायदेमंद होती है जब:
$\frac{p_c}{1 - p_c} \times p_r > \frac{p_g}{1 - p_g}$
जहाँ:

$p_g$ : जनरेटर की बेसलाइन एक्यूरेसी।
$p_c$ : क्रिटिक की वेरिफिकेशन एक्यूरेसी (किसी आइटम को सही ढंग से आंकने की क्षमता)।
$p_r$ : रिपेयर प्रोबेबिलिटी (एक सही आलोचना दिए जाने पर जनरेटर द्वारा सही फिक्स उत्पन्न करने की संभावना)।

यह स्थिति मानती है कि डिबेट तब मदद करती है जब क्रिटिक की वेरिफिकेशन ऑड्स (fixability के भारित होने पर) जनरेटर की बेसलाइन एक्यूरेसी ऑड्स से अधिक होती है।

2. क्रिटीक-इंड्यूस्ड कन्फ्यूजन (Critique-Induced Confusion - CIC)

लेखक जेनरेटिव कार्यों में एक संरचनात्मक विफलता मोड के रूप में क्रिटीक-इंड्यूस्ड कन्फ्यूजन (CIC) की पहचान करते हैं। इन कार्यों में, क्रिटिक अक्सर मतिभ्रम युक्त फीडबैक उत्पन्न करता है जिसे अनुपालन करने वाला जनरेटर बिना किसी जांच के स्वीकार कर लेता है। इसके कारण जनरेटर वैध ऑपरेशन्स को वापस ले लेता है और मतिभ्रम वाले विकल्पों को प्रतिस्थापित कर देता है। अध्ययन पुष्टि करता है कि CIC संरचनात्मक है, न कि प्रॉम्प्ट-निर्भर; यह सभी 6 क्रिटिक प्रॉम्प्ट वेरिएंट और 3 जनरेटर वेरिएंट में बना रहता है।

3. समाधान: ग्राउंडिंग और कैलिब्रेशन

पेपर प्रदर्शित करता है कि CIC को एक विशिष्ट आर्किटेक्चरल कॉन्फ़िगरेशन के माध्यम से संबोधित किया जा सकता है:

एडवर्सरियल सेपरेशन (Adversarial Separation): एक अलग क्रिटिक आवश्यक है; समान टूल्स के साथ सेल्फ-वेरिफिकेशन विफल रहता है क्योंकि $p_c \approx p_g$ है।
कोड-एग्जीक्यूशन ग्राउंडिंग: क्रिटिक को दावों को निष्पादन योग्य साक्ष्य (जैसे, डेटा के विरुद्ध कोड चलाना) के विरुद्ध सत्यापित करना चाहिए।
एविडेंस-गेटेड जनरेशन: जनरेटर को केवल वही फीडबैक स्वीकार करना चाहिए जो विशिष्ट डेटा साक्ष्य का हवाला देता है।
यह संयोजन पहले ऐसे डिबेट कॉन्फ़िगरेशन को देता है जो जेनरेटिव टास्क पर सिंगल-एजेंट प्रदर्शन को महत्वपूर्ण रूप से पार करता है (+5.3pp फैक्टुअल कंसिस्टेंसी, $p<0.05$ )।

मुख्य परिणाम

डिबेट साइन को उलट देती है (Debate Reverses Sign)

डिबेट का प्रभाव एकसमान नहीं है; यह कार्य प्रकार के आधार पर साइन को उलट देता है:

डिटेक्शन टास्क (मदद करती है): MaTElDa (एरर डिटेक्शन) पर, डिबेट ने F1 में +27.4pp ( $d=1.0$ ) का सुधार किया। क्रिटिक ने प्रभावी रूप से फॉल्स पॉजिटिव्स को कम किया।
जनरेशन टास्क (नुकसान पहुँचाती है): AutoDCWorkflow (वर्कफ्लो जनरेशन) पर, डिबेट ने सभी मॉडल्स के प्रदर्शन को कम कर दिया, जिसमें फैक्टुअल कंसिस्टेंसी −1.6 से −15.5pp तक गिर गई।
- मैकेनिज्म: डिबेट एक वेरिएंस एम्पलीफायर के रूप में कार्य करती है। यह परफेक्ट-स्कोर वाले आउटपुट की संख्या तो बढ़ाती है, लेकिन पूर्ण विफलताओं (वैध ऑपरेशन्स को वापस लेना) को भी पेश करती है।
- स्केल: टोकन ओवरहेड 4-7× बढ़ गया।

टास्क स्ट्रक्चर एक महत्वपूर्ण मॉडरेटर है

मदद और नुकसान के बीच की सीमा प्रति-आइटम वेरिफिएबिलिटी और आंसर-स्पेस कंस्ट्रेंट पर टिकी है:

कंस्ट्रेंड/वेरिफिएबल: वे कार्य जहाँ आउटपुट को स्रोत डेटा के विरुद्ध स्वतंत्र रूप से जांचा जा सकता है (जैसे, "क्या यह सेल एक त्रुटि है?"), डिबेट से लाभान्वित होते हैं।
ओपन-एंडेड/डिपेंडेंट: नए मान उत्पन्न करने या ऑपरेशन्स की निर्भर श्रृंखलाओं की आवश्यकता वाले कार्य (जैसे, "इस सेल को कौन सा मान भरता है?") CIC से पीड़ित होते हैं क्योंकि एक मतिभ्रम युक्त आलोचना पूरे वर्कफ्लो में कैस्केड (cascade) हो जाती है।

फैक्टोरियल एक्सपेरिमेंट के निष्कर्ष

एक 2x2 फैक्टोरियल डिजाइन (एडवर्सरियल सेपरेशन $\times$ टूल ऑगमेंटेशन) ने एक एपिस्टैटिक इंटरैक्शन (epistatic interaction) का खुलासा किया:

टूल्स अकेले (सेल्फ-वेरिफिकेशन): सिंगल-एजेंट से कोई सुधार नहीं ( $\Delta \approx -1.3$ pp)।
सेपरेशन अकेले (टेक्स्ट डिबेट): महत्वपूर्ण गिरावट ( $\Delta \approx -7.0$ pp)।
सेपरेशन + टूल्स + एविडेंस गेटिंग: महत्वपूर्ण सुधार ( $\Delta \approx +5.3$ pp)।
दोनों में से कोई भी घटक अकेला पर्याप्त नहीं था; शोर को फिल्टर करने और सेल्फ-वेरिफिकेशन की समरूपता (symmetry) को तोड़ने के लिए संयोजन आवश्यक था।

क्रॉस-डोमेन वैलिडेशन

डिबेट बेनिफिट कंडीशन ने अध्ययन किए गए सभी नौ टास्क प्रकारों के लिए डिबेट के प्रभाव के साइन की सही भविष्यवाणी की और सात डोमेन (कोड जनरेशन, गणितीय तर्क और QA सहित) में 19 प्रकाशित तुलनाओं में जीरो फॉल्स पॉजिटिव्स के साथ सामान्यीकरण किया।

महत्व और दावे

पेपर दावा करता है कि यह डेटा क्लीनिंग और, डेटा क्लीनिंग के विस्तार के रूप में, अन्य जेनरेटिव कार्यों में मल्टी-एजेंट डिबेट के फायदेमंद होने की भविष्यवाणी करने के लिए पहला सिद्धांत-आधारित ढांचा प्रदान करता है।

व्यावहारिक निर्णय नियम: अभ्यासकर्ता यह तय करने के लिए डिबेट बेनिफिट कंडीशन का उपयोग कर सकते हैं कि क्या डिबेट में निवेश करना है। यदि $p_g$ उच्च है, $p_c$ कम है, या $p_r$ कम है (जो ओपन-एंडेड जनरेशन में सामान्य है), तो सिंगल-एजेंट दृष्टिकोण अधिक प्रभावी और 4-6× सस्ता है।
संरचनात्मक अंतर्दृष्टि: निष्कर्ष इस धारणा को चुनौती देते हैं कि डिबेट सार्वभौमिक रूप से फायदेमंद है या केवल प्रॉम्प्ट इंजीनियरिंग ही डिबेट की विफलताओं को ठीक कर सकती है। विफलता मोड (CIC) जेनरेटिव कार्यों और प्रतिकूल दबाव के बीच का एक संरचनात्मक संबंध है।
आर्किटेक्चरल पथ: उन जेनरेटिव कार्यों के लिए जहाँ डिबेट वांछित है, पेपर का तर्क है कि CIC को दूर करने के लिए एडवर्सरियल सेपरेशन के साथ ग्राउंडेड वेरिफिकेशन और एविडेंस-गेटेड कंप्लायंस आवश्यक कॉन्फ़िगरेशन है।

लेखक निष्कर्ष निकालते हैं कि मल्टी-एजेंट डिबेट एक सार्वभौमिक सुधार नहीं है, बल्कि एक उपकरण है जिसकी उपयोगिता कार्य की वेरिफिएबिलिटी और जनरेटर तथा क्रिटिक की सापेक्ष क्षमताओं द्वारा सख्ती से शासित होती है।