लीगल AI हैलुसिनेशन के मामले 2,000 के पार: क्या बनाना चाहिए
AI हैलुसिनेशन वाली सामग्री पर अदालती निर्णय 2,000 के पार हो चुके हैं। अकेले RAG से यह क्यों नहीं सुलझा, और अनुबंध AI पर मेरे काम से निकले डिज़ाइन पैटर्न।
14 सितंबर 2026 तक, डेमियन शार्लोटिन (Damien Charlotin) का AI Hallucination Cases डेटाबेस AI हैलुसिनेशन (मतिभ्रम) वाली सामग्री से जुड़े अदालतों और न्यायाधिकरणों के 2,041 निर्णय दर्ज करता है। इनमें से ज़्यादातर में अदालत ने पाया, या संकेत दिया, कि किसी पक्ष ने ऐसी सामग्री पर भरोसा किया था; अपवाद के तौर पर डेटाबेस में कुछ ऐसे निर्णय भी शामिल हैं जिनमें AI के उपयोग का आरोप तो लगा, पर पुष्टि नहीं हुई। अकेला रिट्रीवल इसका इलाज नहीं है: 2024 में स्टैनफ़र्ड के नेतृत्व वाले एक अध्ययन में परखे गए क़ानूनी शोध के तीन प्रमुख टूल्स में से हर एक ने 17–33% बार हैलुसिनेट किया। बनाना यह चाहिए: ऐसी संरचना जो आउटपुट को जाँचने लायक बनाए, एक इंसान जो निर्णय ले, और सबसे पहले बनाया गया मूल्यांकन सेट।
मैं Kartez Contract पर AI इंजीनियर था; यह लेख बताता है कि उस काम में से मैं क्या बनाए रखता और सबसे पहले क्या करता।
AI हैलुसिनेशन मामलों का डेटाबेस AI टूल बनाने वालों को क्या बताता है, और क्या नहीं
शार्लोटिन की गिनती 2,000 के पार जा चुकी है। किसी पिच या जोखिम-मेमो में इसे उद्धृत करने से पहले तीन बातें समझ लेना ज़रूरी है।
यह निर्णय गिनता है, ग़लतियाँ नहीं। डेटाबेस “अदालत में दाख़िल दस्तावेज़ों में सभी फ़र्ज़ी हवालों या AI के उपयोग के (अनिवार्य रूप से कहीं बड़े) पूरे दायरे को ट्रैक नहीं करता”। यह उन विफलताओं का रिकॉर्ड है जो किसी न्यायाधीश तक पहुँचीं, हैलुसिनेशन की दर नहीं।
यह टूल्स पर दोष नहीं डालता। डेटाबेस की अपनी टिप्पणी कहती है कि किसी टूल के ज़िक्र का “यह अर्थ ज़रूरी नहीं कि संबंधित हैलुसिनेशन के लिए वही टूल ज़िम्मेदार था”, इसलिए इस लेख में कुछ भी डेटाबेस के किसी निर्णय को किसी टूल से नहीं जोड़ता। आगे जिन टूल्स के नाम आए हैं, वे स्टैनफ़र्ड अध्ययन से लिए गए हैं, डेटाबेस से नहीं।
कुल संख्या से ज़्यादा अहम उसकी श्रेणियाँ हैं। शार्लोटिन के डेटाबेस में 1,690 निर्णयों पर Fabricated (गढ़ा हुआ), 854 पर Misrepresented (ग़लत ढंग से प्रस्तुत) और 548 पर False Quotes (झूठे उद्धरण) का टैग है, और एक निर्णय पर कई टैग हो सकते हैं। जिस स्रोत का हवाला दिया गया है वह सचमुच मौजूद है या नहीं — यह जाँच पहली श्रेणी के, यानी गढ़े गए क़ानूनी स्रोतों (authorities) के, ज़्यादातर मामले पकड़ सकती है। बाक़ी दो श्रेणियाँ इस जाँच से तब बच निकलती हैं जब स्रोत तो असली हो, पर उद्धरण गढ़ा गया हो या उसकी व्याख्या ग़लत हो। अनुबंध का कोई टूल ऐसे खंड की ओर इशारा करते हुए भी ये दोनों ग़लतियाँ कर सकता है जो सचमुच मौजूद है।
शार्लोटिन 1,174 ऐसे निर्णय भी दर्ज करते हैं जिनमें AI का उपयोग करने वाला पक्ष pro se litigant था (यानी बिना वकील के अपनी पैरवी ख़ुद करने वाला पक्षकार), और 811 ऐसे जिनमें वह एक वकील था। इसलिए कोई लीगल AI टूल न तो यह मान सकता है कि प्रक्रिया में कोई वकील शामिल है, न यह कि वकील होगा तो उसकी ग़लतियाँ पकड़ ही लेगा। शार्लोटिन के डेटाबेस में 449 निर्णयों के साथ Contract (अनुबंध) सबसे बड़ा क़ानूनी क्षेत्र है। ये ऐसे अनुबंध-विवाद हैं जिनमें AI हैलुसिनेशन वाली सामग्री मुद्दा बनी, न कि AI से तैयार किए गए अनुबंध।
क्या RAG से लीगल AI का हैलुसिनेशन रुकता है?
नहीं। नीचे जिस स्टैनफ़र्ड अध्ययन की चर्चा है, उसका निष्कर्ष है कि क़ानूनी retrieval-augmented generation (RAG) “सामान्य-उद्देश्य वाले AI सिस्टम (यहाँ, GPT-4) की तुलना में हैलुसिनेशन कम कर सकता है, लेकिन हैलुसिनेशन अब भी काफ़ी ज़्यादा, कई तरह के और संभावित रूप से छिपे ढंग से नुकसान पहुँचाने वाले (insidious) बने रहते हैं।” यहाँ “insidious” बिल्कुल सही शब्द है: ग़लत आधार वाला उत्तर अपने साथ एक असली स्रोत लेकर आता है। गार्डरेल का सामान्य डिज़ाइन RAG हैलुसिनेशन गार्डरेल में है।
स्टैनफ़र्ड के नेतृत्व वाला अध्ययन: 17–33%
30 मई 2024 को arXiv पर पोस्ट किए गए एक पेपर में स्टैनफ़र्ड और येल के शोधकर्ताओं ने “AI-संचालित क़ानूनी शोध टूल्स के पहले प्रीरजिस्टर्ड अनुभवजन्य मूल्यांकन” की रिपोर्ट दी। प्रीरजिस्टर्ड का अर्थ है कि अध्ययन और 200 से अधिक क़ानूनी प्रश्नों वाला उसका डेटासेट मूल्यांकन चलाने से पहले ही पंजीकृत कर दिए गए थे, ताकि नतीजों के हिसाब से प्रश्न चुनने की गुंजाइश न रहे। कुछ प्रदाताओं ने रिट्रीवल का प्रचार हैलुसिनेशन को “ख़त्म करने” या उनसे “बचने” के उपाय के रूप में किया था। अध्ययन ने पाया कि Lexis+ AI, Westlaw AI-Assisted Research और Ask Practical Law AI में से हर एक ने 17–33% बार हैलुसिनेट किया, और यह भी कि “प्रदाताओं के दावे बढ़ा-चढ़ाकर किए गए हैं”।
इस रेंज से ज़्यादा अहम हैलुसिनेशन की परिभाषा है। किसी उत्तर को हैलुसिनेटेड तब गिना गया “अगर वह या तो ग़लत है या misgrounded (ग़लत आधार वाला)”, और misgrounded का अर्थ है कि प्रमुख कथनों का “हवाला तो दिया गया है, पर वे स्रोत की ग़लत व्याख्या करते हैं या किसी ऐसे स्रोत का संदर्भ देते हैं जो लागू नहीं होता”। टूल्स 2024 में परखे गए थे, और वह भी अनुबंधों पर नहीं बल्कि क़ानूनी शोध पर, इसलिए यह रेंज आज के लीगल AI का आँकड़ा नहीं है। पर यह श्रेणी अनुबंधों पर भी लागू होती है: अनुबंध में ग़लत आधार वाला उत्तर सुनने में सही लगता है और ग़लत खंड की ओर इशारा करता है।
पर्याप्त संदर्भ पर Google का निष्कर्ष: ज़्यादा संदर्भ, उत्तर से कम परहेज़
“Sufficient Context” पेपर उन ग़लतियों को, जिनमें मॉडल अच्छे संदर्भ का ग़लत इस्तेमाल करता है, उन ग़लतियों से अलग करता है जिनमें संदर्भ उत्तर देने के लिए कभी पर्याप्त था ही नहीं। उसमें परखे गए बड़े मॉडल, जो Google, OpenAI और Anthropic के थे, “जब संदर्भ [पर्याप्त] नहीं होता, तब अक्सर उत्तर देने से परहेज़ करने के बजाय ग़लत उत्तर देते हैं”।
इस काम पर Google Research के लेख (14 मई 2025) के अनुसार, RAG जहाँ “आम तौर पर समग्र प्रदर्शन सुधारता है”, वहीं वह “विरोधाभासी रूप से, उचित स्थिति में उत्तर देने से परहेज़ करने की मॉडल की क्षमता घटा देता है”। Google के उदाहरण में Gemma ने बिना संदर्भ के 10.2% प्रश्नों पर और अपर्याप्त संदर्भ के साथ 66.1% प्रश्नों पर ग़लत उत्तर दिए।
रिट्रीवल यह बदलता है कि मॉडल क्या देखता है, यह नहीं कि मॉडल को पता हो कि उसके पास पर्याप्त जानकारी है या नहीं। अनुबंध समाप्ति (termination) के बारे में कोई प्रश्न किसी ऐसी परिभाषा या नोटिस खंड पर टिका हो सकता है जो कभी रिट्रीव ही नहीं हुआ। डिज़ाइन ऐसा होना चाहिए कि “मुझे एक और अनुभाग चाहिए” एक सामान्य आउटपुट हो, और मूल्यांकन को इसकी जाँच करनी होगी।
AI से अनुबंध समीक्षा: कौन-सी विफलताएँ मायने रखती हैं
गढ़ा हुआ खंड हस्ताक्षर करने वाले के लिए क़ानूनी दायित्व बन जाता है, इसलिए जो मॉडल अपनी ओर से खंड गढ़ दे, वह किसी मॉडल के न होने से भी बदतर है। डिज़ाइन करते समय सबसे पहले मैं इन्हीं विफलताओं से बचने का इंतज़ाम करता। नीचे का कोई भी पैटर्न किसी उत्तर को सही साबित नहीं करता; ज़्यादातर पैटर्न ग़लत उत्तर को पकड़ में आने लायक बनाते हैं।
विफलता | अनुबंध में | वह पैटर्न जो इसे जाँचने लायक बनाता है |
|---|---|---|
गढ़ी हुई सामग्री | ऐसा खंड या समय-सीमा जो दस्तावेज़ में है ही नहीं | चुने हुए खंडों से उत्तर; हर संपादन उपयोगकर्ता स्वीकार करता है |
ग़लत उद्धृत शब्दावली | ऐसा सुधार जो उस टेक्स्ट को बदलता है जो वहाँ है ही नहीं | हर सुधार मौजूदा शब्दावली को हूबहू उद्धृत करता है |
ग़लत आधार वाला उत्तर | ग़लत खंड से, या कभी न दिखाए गए अनुभाग से दिया गया उत्तर | खंडों का चयन; छूटे हुए अनुभाग माँगने का निर्देश |
टूटा हुआ आउटपुट | बीच में कटी जोखिम-सूची, जो पूरी सूची की तरह दिखाई जाए | तय स्कीमा, कच्चा आउटपुट कभी प्रदर्शित नहीं; मरम्मत किए गए जवाबों की पूर्णता-जाँच (अनुशंसित) |
अधूरे संपादन | किसी पक्ष का नाम केवल एक अनुभाग में बदला गया | पूरे अनुबंध के संपादनों की पहले योजना, हर जगह लागू, हाइलाइट |
बदले हुए मान | पुनर्लेखन में बदली गई कोई राशि, तारीख़ या नाम | मानों की अक्षरशः जाँच (अनुशंसित, नीचे देखें) |
Kartez Contract से अनुबंध AI के डिज़ाइन पैटर्न
नवंबर 2025 से जुलाई 2026 तक मैंने Kartez Contract पर AI इंजीनियर के रूप में काम किया। यह एक त्रिभाषी, दाएँ-से-बाएँ अनुबंध वर्कस्पेस था, जिसमें मसौदा विज़ार्ड, समीक्षा प्रक्रिया और अनुबंध स्टूडियो थे। इन वर्कफ़्लो के पीछे के AI इंजन को मैंने क्लाइंट की शुरुआती बुनियादी AI चेन से शुरू करके नए सिरे से बनाया और उसका विस्तार किया, और वह कोपायलट बनाया जो हर अनुरोध का वर्गीकरण करता है, प्रासंगिक खंड ढूँढता है और पूरे अनुबंध में संपादनों की योजना बनाता है।
सबसे कठिन समस्याएँ दो थीं: रिट्रीवल, और मॉडल को अनुबंध के अपने टेक्स्ट से बाँधे रखना (anchoring)। यह बंधन भरोसे के बजाय संरचना से हासिल किया गया। नीचे के छह पैटर्न में से कोई भी मापी गई गारंटी नहीं है; पहले चार ख़ुद वही बाध्यताएँ हैं जो मॉडल को टेक्स्ट से बाँधे रखती थीं।
केवल उन्हीं खंडों से उत्तर जिन्हें कोपायलट ने चुना
उपयोगकर्ता का अनुबंध उसकी अपनी संरचना के अनुसार बाँटा गया, जिसमें वे अनुच्छेद, खंड और टिप्पणियाँ (ماده، بند، تبصره) भी शामिल थीं जिन्हें फ़ारसी अनुबंध अपने ढंग से क्रमांकित करते हैं। किसी प्रश्न का उत्तर देने के लिए केवल उससे जुड़े अनुभागों का उपयोग हुआ, और कोपायलट को निर्देश था कि जब उसे ऐसे अनुभाग चाहिए हों जो उसे दिखाए नहीं गए, तो वह यह बात कहे।
खंड वह इकाई है जिसमें वकील पहले से काम करते हैं, इसलिए खंडों से बने रिट्रीवल सेट पर मूल्यांकन करने वाला लेबल लगा सकता है और उसकी जाँच कर सकता है। यह निर्देश अंदाज़ा लगाने का एक विकल्प देता है, पर यह अनिवार्य रूप से लागू होने वाला कोई गेट नहीं है, इसलिए मूल्यांकन सेट में ऐसे प्रश्न भी होने चाहिए जिनका उत्तर चुने गए खंडों से न दिया जा सके। फ़ारसी रिट्रीवल के अपने जाल हैं, जिन पर एक अलग सिस्टम के संदर्भ में फ़ारसी RAG के लिए हाइब्रिड सर्च में बात की गई है।
अनुबंध को हूबहू उद्धृत करने वाले सुधार
हर सुझाए गए सुधार के लिए मौजूदा शब्दावली को हूबहू उद्धृत करना अनिवार्य था, ताकि उसे ढूँढकर बदला जा सके, और उसके साथ उपयोग के लिए तैयार प्रतिस्थापन टेक्स्ट आता था। यही अनिवार्यता हूबहू उद्धरण की जाँच (exact-quote validation) को संभव बनाती है: सुधार लागू होने से पहले कोई प्रोग्राम पुष्टि कर सकता है कि उद्धृत टेक्स्ट मौजूद है।
कोई पुनर्लेखन समझदारी भरा है या नहीं, यह क़ानूनी विवेक का प्रश्न है। जिस वाक्य को वह बदलता है, वह मौजूद है या नहीं, यह स्ट्रिंग मैच का प्रश्न है। LLM से जुड़ी ग़लत जानकारी (misinformation) पर OWASP का मार्गदर्शन यही बात सामान्य रूप में कहता है: “मुख्य आउटपुट को, विशेषकर उच्च-जोखिम वाले परिवेशों के आउटपुट को, स्वचालित रूप से सत्यापित करें”। अगर मैं इसे फिर से बनाता, तो हर उस सुधार को छोड़ देता जिसका उद्धरण न मिले, उसे कभी अनुमानित ढंग से लागू नहीं करता, और छोड़े गए सुधारों की गिनती को शुरुआती चेतावनी मानता।
ये सुधार समीक्षा प्रक्रिया में आते हैं, और काम रुकने तक उस प्रक्रिया का पूरा परीक्षण नहीं हुआ था, इसलिए यह पैटर्न अपने तर्क पर टिका है, किसी माप पर नहीं।
तय आउटपुट स्कीमा, कच्चा आउटपुट कभी प्रदर्शित नहीं
हर विश्लेषण एक तय संरचना में लौटता था, ताकि टाइमलाइन, जोखिम रजिस्टर और सुधार हर बार एक ही ढंग से सजे हों। ग़लत ढाँचे वाला जवाब कई चरणों वाली पार्स-और-रिपेयर प्रक्रिया से गुज़रता था, जिसमें बीच में कटे जवाबों की मरम्मत भी शामिल थी, और ज़रूरत पड़ने पर ज़्यादा गुंजाइश के साथ दोबारा आज़माया जाता था। उसे उपयोगकर्ता को कभी कच्चे रूप में नहीं दिखाया गया।
यह पैटर्न एक ख़ामोश विफलता को निशाना बनाता है: बीच में कटी जोखिम-सूची पाठक को पूरी लगती है। अकेली मरम्मत इसे हल नहीं करती, क्योंकि कटी हुई सूची का ढाँचा बंद कर दिया जाए तो वह फिर भी पार्स हो जाती है; इसलिए मरम्मत की गई कटी हुई सूची को पूरी बताकर दिखाने के बजाय मैं दोबारा आज़माता, या उस पर चिह्न लगाता। स्कीमा से बाक़ी जाँचों को भी देखने के लिए एक तय जगह मिल जाती है।
मसौदा लिखते समय कम यादृच्छिकता
मसौदा लिखते समय मॉडल कम यादृच्छिकता (randomness) के साथ चलता था। इससे नतीजों को दोहराने की क्षमता मिलती है, उनके सही होने की नहीं: एक ही इनपुट से प्रायः एक जैसा मसौदा बनता है, इसलिए विफलताओं को दोबारा पैदा किया जा सकता है और मूल्यांकन के रन आपस में तुलना योग्य रहते हैं।
मार्गदर्शित वर्कफ़्लो, हर काम के लिए एक ही चैट बॉक्स नहीं
मसौदा तैयार करना, समीक्षा करना और संपादन करना अलग-अलग काम हैं, और हर एक को अपना मार्गदर्शित वर्कफ़्लो चाहिए, न कि एक चैट विंडो। उदाहरण के लिए, समीक्षा उपयोगकर्ता के पक्ष से लिखी जाती है, इसलिए उसका पहला चरण सौदे में उपयोगकर्ता की भूमिका पूछता है।
Anthropic अपने लेख “Building effective agents” में workflow शब्द को ऑर्केस्ट्रेशन के अर्थ में लेता है: “ऐसे सिस्टम जिनमें LLM और टूल्स पहले से तय कोड पाथ के ज़रिये ऑर्केस्ट्रेट किए जाते हैं”। लेख के अनुसार वे “स्पष्ट रूप से परिभाषित कार्यों के लिए पूर्वानुमेयता और एकरूपता देते हैं”। हर तय चरण के इनपुट और आउटपुट का ढाँचा पहले से ज्ञात होता है, जिसे जाँचा जा सकता है। ख़ाली चैट बॉक्स कुछ भी स्वीकार कर लेता है और कुछ भी लौटा देता है।
हाइलाइट किए गए संपादन, जिन्हें उपयोगकर्ता स्वीकार या अस्वीकार करता है
तीनों वर्कफ़्लो में नियम एक ही था: AI सुझाव देता है और निर्णय उपयोगकर्ता लेता है। कोपायलट के संपादन एडिटर में हाइलाइट होते थे, ताकि उपयोगकर्ता उन्हें स्वीकार या अस्वीकार कर सके। पूरे अनुबंध पर लागू होने वाले किसी निर्देश (जैसे किसी पक्ष का नाम बदलना) की पहले योजना बनती थी, फिर उसे हर प्रभावित अनुभाग पर लागू करके हाइलाइट किया जाता था।
उपयोगकर्ता पूरा दस्तावेज़ दोबारा पढ़ने के बजाय चिह्नित बदलावों को परखता है, और नाम का बदलाव जहाँ-जहाँ लागू हुआ, हर उस जगह हाइलाइट होता है, न कि बाद में किसी असंगति के रूप में पकड़ में आता है।
एक अलग सिस्टम: इस साइट के सहायक के गेट
इस अनुभाग में बताई गई कोई भी चीज़ Kartez Contract का हिस्सा नहीं थी। इस साइट का सहायक, जिसे मैंने बनाया है और जिसका रखरखाव मैं करता हूँ, केवल साइट की अपनी सामग्री से उत्तर देता है, और वह भी नियतात्मक (deterministic) गेटों के पीछे।
कुछ सवाल रिट्रीवल से पहले ही पैटर्न के आधार पर ठुकरा दिए जाते हैं: शुल्क और उपलब्धता, निजी जानकारी, अटकलें, सिस्टम प्रॉम्प्ट को निशाना बनाने की कोशिशें, और काम करवाने के अनुरोध, जैसे कोड लिखना या किसी टेक्स्ट का अनुवाद करना। अगर सवाल मेरे बारे में नहीं है और रिट्रीव की गई कोई भी सामग्री रिट्रीवल स्कोर की न्यूनतम सीमा पार नहीं करती, तो सहायक मना कर देता है और मॉडल बुलाया ही नहीं जाता। मेरे बारे में सवाल भी पैटर्न से पहचाने जाते हैं, जैसे मेरे नाम या अन्य पुरुष (third person) के किसी सर्वनाम से, और उन्हें सिर्फ़ इसलिए नहीं ठुकराया जाता कि कोई भी अंश न्यूनतम सीमा पार नहीं कर पाया। इसके बजाय मॉडल को साइट के अपने रिकॉर्ड दिए जाते हैं, यानी बायोडाटा, केस स्टडी, लेखों और परामर्श सेवाओं की प्रविष्टियाँ, और उसे निर्देश दिया जाता है कि अगर ये रिकॉर्ड सवाल का जवाब नहीं देते, तो वह केवल एक तय टोकन लौटाए; तब पाठक को वही इनकार दिखता है। जब उत्तर स्ट्रीम हो रहा होता है, तब एक वाक्य-गेट हर पूरे वाक्य को दिखाए जाने से पहले जाँचता है:
उद्धरण का दायरा। हर उद्धरण-चिह्नक किसी ऐसे स्रोत की ओर इशारा करता है जो मॉडल को दिया गया था।
उद्धरण अनिवार्य। हर ठोस वाक्य में एक चिह्नक होता है।
मानों का समर्थन। हर संख्या, URL और ईमेल पता उन स्रोतों में से किसी एक में मौजूद होता है जिनका वाक्य हवाला देता है।
उत्तम पुरुष। कोई भी वाक्य उत्तम पुरुष (first person) के सर्वनामों, जैसे अंग्रेज़ी के I, me या we, का इस्तेमाल नहीं करता।
एक भी वाक्य जाँच में विफल हुआ तो उत्तर वहीं रुक जाता है, और वह वाक्य कभी नहीं दिखाया जाता। उद्धरण-चिह्नकों की पहले जाँच होती है, फिर उन्हें हटा दिया जाता है, इसलिए पाठक उन्हें कभी नहीं देखते।
यह तंत्र स्ट्रीमिंग LLM गार्डरेल में समझाया गया है। RAG बनाम बिना रिट्रीवल डेमो स्रोतों पर आधारित एक असली उत्तर स्ट्रीम करता है, और उसके बगल में बिना रिट्रीवल वाला एक स्तंभ है जो डिज़ाइन के तहत ख़ाली रहता है; ऐसा कुछ पूछें जो न मेरे बारे में हो और न ही यह साइट उसे समेटती हो, और किसी मॉडल तक पहुँचने से पहले ही प्रयास रुक जाएगा। अगर मैं अनुबंध के लिए कोई टूल बना रहा होता, तो राशियों, तारीख़ों और पक्षों के नामों के लिए भी इसी तरह की जाँच जोड़ता, जिसमें हर मान का स्रोत से अक्षरशः मेल खाना अनिवार्य होता।
लीगल AI का मूल्यांकन कैसे करें: सबसे पहले मूल्यांकन सेट बनाएँ
आम क्रम है: पहले बनाना, फिर मापना। लीगल AI के लिए मैं यह क्रम उलट देता।
डिज़ाइन की बाध्यता एक परिकल्पना है। “सुधार अनुबंध को हूबहू उद्धृत करें” एक नियम है। मॉडल इसे कितनी बार तोड़ता है, यह एक संख्या है, और वह संख्या केवल मूल्यांकन सेट से मिलती है।
हर बदलाव के लिए रिग्रेशन जाँच चाहिए। तय सेट के बिना मॉडल, प्रॉम्प्ट या रिट्रीवल के हर बदलाव को अंदाज़े से आँका जाता है।
सेट परियोजना के बाद भी बचा रहता है। लेबल किया गया सेट और उसका आख़िरी रन ऐसा प्रमाण है जिसका उपयोग कोई और कर सकता है। डिज़ाइन सिद्धांतों की सूची ऐसा प्रमाण नहीं है।
Kartez Contract में क्या हुआ
पूरा होने से एक महीने पहले क्लाइंट ने यह काम रोक दिया, जब युद्ध से जुड़ी वित्तीय कठिनाइयों के कारण फ़ंडिंग रुक गई। यह क्लाइंट की ओर से फ़ंडिंग की विफलता थी, डिलीवरी की नहीं। तब तक मसौदा विज़ार्ड, कोपायलट सहित अनुबंध स्टूडियो और त्रिभाषी इंटरफ़ेस बनकर तैयार थे और शुरू से अंत तक आपस में जुड़े हुए थे। समीक्षा प्रक्रिया के पाँचों चरण बन चुके थे, लेकिन जब काम रुका, तब तक उसका पूरा परीक्षण नहीं हुआ था और उसमें सुधार जारी था।
सटीकता का कोई आँकड़ा मौजूद नहीं है, क्योंकि औपचारिक मूल्यांकन सेट बनने से पहले ही काम रुक गया। डिज़ाइन की बाध्यताएँ वास्तविक थीं; वह संख्या, जो उन्हें एक दावे में बदल देती, कभी तैयार ही नहीं हुई।
अनुबंध AI के लिए पहले हफ़्ते का मूल्यांकन सेट
यह सलाह है, Kartez Contract में मौजूद किसी चीज़ का विवरण नहीं। हर आइटम का नतीजा बाइनरी है: पास या फ़ेल।
उत्तर दिए जा सकने वाले प्रश्न, उनके खंड के लेबल के साथ। उत्तर सही होना चाहिए और उसी खंड पर आधारित होना चाहिए।
ऐसे प्रश्न जिनका उत्तर अनुबंध में नहीं है। कोई उत्तर नहीं, बल्कि “मुझे अनुभाग X चाहिए” या “अनुबंध इस बारे में कुछ नहीं कहता” अपेक्षित है।
संपादन के अनुरोध। प्रस्तावित सुधार में उद्धृत हर अंश का स्रोत दस्तावेज़ से स्ट्रिंग मैच होना चाहिए।
पूरे अनुबंध के संपादन। किसी पक्ष के नाम का बदलाव हर जगह होना चाहिए, और उसके अलावा कुछ नहीं बदलना चाहिए।
वे मान जो नहीं बदलने चाहिए। राशियाँ, तारीख़ें, नोटिस अवधियाँ और पक्षों के नाम, हर पुनर्लेखन से पहले और बाद में अक्षरशः मिलाए जाएँ।
टूटे हुए आउटपुट। बीच में कटे और ग़लत ढाँचे वाले जवाब कभी कच्चे रूप में स्क्रीन तक नहीं पहुँचने चाहिए, और मरम्मत किया गया कटा जवाब कभी पूरा बताकर नहीं दिखाया जाना चाहिए।
फ़ारसी संरचना। ماده (अनुच्छेद), بند (खंड) और تبصره (टिप्पणी) के अनुसार क्रमांकन, मिश्रित दिशा वाली पंक्तियाँ और फ़ारसी अंक।
सौदे के दोनों पक्ष। एक ही अनुबंध की समीक्षा, हर पक्ष की स्थिति से।
Digital Omnibus के बाद EU AI Act की समय-सीमाएँ: इंजीनियरिंग की नज़र से
यूरोपीय संसद ने अंतिम पाठ 16 जून 2026 को और परिषद ने 29 जून 2026 को पारित किया।
2 अगस्त 2026 से पहले बाज़ार में लाए गए सिस्टमों के लिए AI-जनित सामग्री पर चिह्न लगाने (marking) की समय-सीमा 2 दिसंबर 2026 है।
अनुच्छेद 50 के अन्य पारदर्शिता दायित्व, जैसे उपयोगकर्ताओं को यह बताना कि उनका सामना एक AI सिस्टम से है, 2 अगस्त 2026 से लागू होते हैं।
Annex III के स्टैंड-अलोन उच्च-जोखिम दायित्व खिसककर 2 दिसंबर 2027 पर चले गए हैं। Annex I के सुरक्षा क़ानूनों के दायरे में आने वाले उत्पादों में अंतर्निहित AI के लिए यह तारीख़ 2 अगस्त 2028 है।
कोई सिस्टम इसके दायरे में आता है या नहीं, यह क़ानूनी सलाहकार से पूछने का सवाल है। ऊपर का कोई भी पैटर्न अनुपालन (compliance) का उपाय नहीं है।
लीगल AI बनाने या ख़रीदने के लिए चेकलिस्ट
हर उत्तर किस पर आधारित है? किसी खंड या अनुभाग पर, “दस्तावेज़” पर नहीं।
क्या हर संपादन की जगह ढूँढी जा सकती है? हर बदलाव उस टेक्स्ट को उद्धृत करता है जिसे वह बदलता है, और दस्तावेज़ से उसका मिलान होता है।
क्या वह कह सकता है कि उत्तर दस्तावेज़ में नहीं है? इसका प्रदर्शन माँगें।
क्या आउटपुट दिखाने से पहले सत्यापित होता है? टूटे जवाबों की मरम्मत होती है या उन्हें रोक लिया जाता है।
क्या कुछ भी स्वीकृति के बिना बदलता है? कुछ भी नहीं बदलना चाहिए।
क्या हर काम के लिए अलग वर्कफ़्लो है? मसौदा, समीक्षा और संपादन एक ही चैट बॉक्स में नहीं होने चाहिए।
क्या मानों की अक्षरशः जाँच होती है? राशियाँ, तारीख़ें और पक्षों के नाम, स्रोत से मिलाकर।
क्या मूल्यांकन सेट देखा जा सकता है? उसमें क्या है, कौन-से आइटम उत्तर देने से परहेज़ (abstention) की जाँच करते हैं, और वह आख़िरी बार कब चला।
अगर आप अनुबंध या लीगल AI सिस्टम का दायरा तय कर रहे हैं, तो परियोजना निदान पाँच सवालों से एक शुरुआती आर्किटेक्चर तैयार करता है।
अक्सर पूछे जाने वाले सवाल
अदालतों तक AI हैलुसिनेशन के कितने मामले पहुँचे हैं?
14 सितंबर 2026 तक, डेमियन शार्लोटिन का AI Hallucination Cases डेटाबेस AI हैलुसिनेशन वाली सामग्री से जुड़े अदालतों और न्यायाधिकरणों के 2,041 निर्णय दर्ज करता है। इनमें से ज़्यादातर में अदालत ने पाया, या संकेत दिया, कि किसी पक्ष ने ऐसी सामग्री पर भरोसा किया था; अपवाद के तौर पर कुछ ऐसे निर्णय भी शामिल हैं जिनमें AI के उपयोग का आरोप लगा, पर पुष्टि नहीं हुई। यह डेटाबेस निर्णय दर्ज करता है, अदालत में दाख़िल दस्तावेज़ों में हर फ़र्ज़ी हवाला या AI का हर उपयोग नहीं।
क्या RAG लीगल AI में हैलुसिनेशन कम करता है?
कम करता है, पर रोकता नहीं। स्टैनफ़र्ड के नेतृत्व वाले एक प्रीरजिस्टर्ड अध्ययन में रिट्रीवल-आधारित क़ानूनी शोध के तीन टूल्स ने GPT-4 से कम हैलुसिनेट किया, फिर भी 2024 में परखे जाने पर उनमें से हर एक ने 17–33% बार हैलुसिनेट किया। पर्याप्त संदर्भ (sufficient context) पर Google के शोध ने पाया कि रिट्रीव किया गया संदर्भ पर्याप्त न होने पर बड़े मॉडल अक्सर उत्तर देने से परहेज़ करने के बजाय ग़लत उत्तर देते हैं।
क्या AI भरोसेमंद ढंग से अनुबंधों की समीक्षा कर सकता है?
केवल भरोसे के सहारे नहीं। जो बनाया जा सकता है, वह ऐसी समीक्षा है जो ग़लतियों को जाँचने लायक बनाए: चुने हुए खंडों से उत्तर, अनुबंध को हूबहू उद्धृत करने वाले सुधार, तय आउटपुट स्कीमा, और एक इंसान जो हर बदलाव को स्वीकार या अस्वीकार करे। कोई टूल वास्तव में ग़लतियाँ पकड़ता है या नहीं, यह माप का विषय है, इसलिए उसका मूल्यांकन सेट माँगें।
हूबहू उद्धरण की जाँच (exact-quote validation) क्या है?
यह इस बात की जाँच है कि प्रस्तावित सुधार जिस टेक्स्ट को उद्धृत करता है, वह सुधार लागू होने से पहले मौजूदा दस्तावेज़ में हूबहू मौजूद है। इसके लिए यह नियम ज़रूरी है कि हर सुधार उस शब्दावली को उद्धृत करे जिसे वह बदलता है, और यह जाँच क़ानूनी संपादन के एक हिस्से को स्ट्रिंग मैच में बदल देती है।
Kartez Contract के लिए सटीकता का कोई आँकड़ा क्यों नहीं है?
क्लाइंट ने युद्ध से जुड़े फ़ंडिंग कारणों से यह काम पूरा होने से एक महीने पहले रोक दिया, औपचारिक मूल्यांकन सेट बनने से पहले ही। यह साइट ऐसी संख्याओं का अनुमान नहीं लगाती जिन्हें मापा न गया हो। यही कमी इस बात का कारण है कि यह लेख मूल्यांकन सेट सबसे पहले बनाने की वकालत करता है।
स्रोत
डेमियन शार्लोटिन (Damien Charlotin), AI Hallucination Cases Database, अंतिम अपडेट 14 सितंबर 2026, 17 सितंबर 2026 को जाँचा गया (CC BY 4.0)।
Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning और Daniel E. Ho, “Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools” (2024)।
Hailey Joren, Jianyi Zhang, Chun-Sung Ferng, Da-Cheng Juan, Ankur Taly और Cyrus Rashtchian, “Sufficient Context: A New Lens on Retrieval Augmented Generation Systems” (2024)।
Google Research, “Deeper insights into retrieval augmented generation: The role of sufficient context” (14 मई 2025)।
OWASP GenAI Security Project, “LLM09:2025 Misinformation”।
Anthropic, “Building effective agents” (19 दिसंबर 2024)।
Freshfields, “EU AI Act unpacked #34: The final Digital Omnibus on AI” (10 जुलाई 2026)।
Kartez Contract केस स्टडी, इसी साइट पर।