Acceptance-Test-Driven Evaluation Protocols for Business-Centric LLM Systems
यह शोध पत्र एक स्वीकृति-परीक्षण-संचालित मूल्यांकन ढांचे का प्रस्ताव करता है जो हितधारकों के लक्ष्यों को निष्पादन योग्य व्यवहारिक अनुबंधों और एक "रेड-ट्रैफ़िक-ग्रीन" जीवनचक्र में अनुवादित करके संभाव्य (probabilistic) एलएलएम क्षमताओं और नियतात्मक (deterministic) व्यावसायिक आवश्यकताओं के बीच के अंतर को पाटता है ताकि सुरक्षित, विश्वसनीय और आर्थिक रूप से उपयोगी एआई प्रणालियों को सुनिश्चित किया जा सके।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक व्यस्त कार्यालय के लिए एक बहुत ही स्मार्ट, लेकिन थोड़ा अनिश्चित (unpredictable) रोबोटिक सहायक बना रहे हैं। यह रोबोट (एक Large Language Model, या LLM) ईमेल लिखने और सवालों के जवाब देने में बहुत अच्छा है, लेकिन कभी-कभी यह मनगढ़ंत बातें बना लेता है, भ्रमित हो जाता है, या गलती से निजी रहस्य उजागर कर देता है।
आपने जो पेपर साझा किया है, वह तर्क देता है कि हम केवल डेवलपर्स को तब तक इस रोबोट के साथ "छेड़छाड़" (tinkering) करने की अनुमति नहीं दे सकते जब तक कि यह "अच्छा दिखने" न लगे। इसके बजाय, हमें इसे एक उच्च-जोखिम वाली मशीन की तरह मानना चाहिए जिसे वास्तविक लोगों के साथ काम करने की अनुमति मिलने से पहले एक सख्त, पूर्व-लिखित सुरक्षा और प्रदर्शन परीक्षण पास करना होगा।
यहाँ पेपर का मुख्य विचार दिया गया है, जिसे कुछ रोजमर्रा के उपमाओं (analogies) के साथ समझाया गया है:
1. समस्या: "अनुमान लगाना" बनाम "परीक्षण करना"
वर्तमान में, कई कंपनियाँ इन AI सिस्टमों को इस तरह बनाती हैं कि वे एक प्रॉम्प्ट (prompt) आज़माती हैं, देखती हैं कि उत्तर ठीक लग रहा है या नहीं, और फिर आगे बढ़ जाती हैं। पेपर कहता है कि यह बिना ब्रेक वाली कार चलाने जैसा है और यह उम्मीद करना कि आप किसी से न टकराएं। आप एक बार भाग्यशाली हो सकते हैं, लेकिन यदि आपको हर दिन सुरक्षित रूप से गाड़ी चलानी है, तो यह पर्याप्त नहीं है।
पेपर एक नया तरीका प्रस्तावित करता है जिसे Acceptance-Test-Driven Development (ATDLLMD) कहा जाता है। इसे कार बनाने से पहले ही सड़क के नियम लिख देने के रूप में समझें।
2. नई विधि: "रेड-ट्रेन-ग्रीन" (Red-Train-Green)
लेखक एक प्रसिद्ध सॉफ्टवेयर पद्धति को अपनाते हैं जिसे "Test-Driven Development" कहा जाता है और AI के लिए इसे एक नया मोड़ देते हैं:
- रेड (असफलता/Red): AI को बदलने से पहले, आप एक ऐसा परीक्षण लिखते हैं जिसमें वह विफल हो जाएगा। उदाहरण के लिए, आप एक परीक्षण लिखते हैं कि "यदि कोई उपयोगकर्ता किसी सहकर्मी का निजी फोन नंबर मांगता है, तो AI को कहना चाहिए 'नहीं'।" अभी, AI वह नंबर बता सकता है। यह एक "रेड" लाइट है।
- ट्रेन (सुधार/Train): अब, आप AI को ठीक करते हैं। आप इसके निर्देशों को बदलते हैं, इसे बेहतर संदर्भ पुस्तकें देते हैं, या सुरक्षा नियम जोड़ते हैं जब तक कि यह उस विशिष्ट परीक्षण को पास न कर ले।
- ग्रीन (सफलता/Green): एक बार जब AI लगातार परीक्षण (और कई अन्य परीक्षणों) को पास कर लेता है, तो इसे "ग्रीन" लाइट मिलती है और इसे लाइव जाने की अनुमति दी जाती है।
उपमा: कल्पना कीजिए कि एक शेफ एक नया व्यंजन बनाने की कोशिश कर रहा है।
- पुराना तरीका: शेफ सूप चखता है, नमक डालता है, फिर से चखता है, फिर से नमक डालता है, और परोस देता है।
- नया तरीका (ATDLLMD): खाना पकाने से पहले, मैनेजर एक अनुबंध लिखता है: "सूप 500 कैलोरी से कम होना चाहिए, इसमें मूंगफली नहीं होनी चाहिए, और इसका स्वाद चिकन जैसा होना चाहिए।" शेफ को ग्राहक को पहला चम्मच परोसने से पहले यह साबित करना ही होगा कि सूप इन नियमों को पूरा करता है।
3. "कॉन्ट्रैक्ट" (स्वीकृति परीक्षण/Acceptance Tests)
पेपर कहता है कि आपको केवल यह परीक्षण नहीं करना चाहिए कि AI "स्मार्ट" है या नहीं। आपको विशिष्ट चीजों का परीक्षण करने की आवश्यकता है जो वास्तव में व्यवसाय की जरूरतों पर आधारित हों। वे इन्हें Acceptance Contracts कहते हैं।
इन्हें एक बहु-स्तरीय सुरक्षा चेकलिस्ट के रूप में समझें:
- कार्यात्मक (Functional): क्या यह वास्तव में प्रश्न का उत्तर दे रहा है?
- तथ्यात्मक (Factual): क्या इसने कोई फर्जी कानून या फर्जी साइटेशन (citation) बना लिया? (पेपर नोट करता है कि AI आत्मविश्वास से झूठ बोलने में माहिर होता है)।
- सुरक्षा (Safety): क्या इसने निजी डेटा प्रकट करने से इनकार कर दिया? क्या इसने किसी "हैकर" द्वारा इसे फँसाने की कोशिश को अनदेखा कर दिया?
- व्यावसायिक (Business): क्या इसने वास्तव में कंपनी का पैसा या समय बचाया?
- परिचालन (Operational): क्या यह बहुत धीमा है या इसे चलाने में बहुत महंगा है?
4. "गेटकीपर" (Gatekeeper) प्रणाली
पेपर सुझाव देता है कि डेवलपर्स और लाइव सिस्टम के बीच एक विशेष "कंट्रोल रूम" (एक संदर्भ आर्किटेक्चर) बनाया जाए।
- द गेट (द्वार): यह एक डिजिटल बाउंसर है। यदि AI एक भी महत्वपूर्ण परीक्षण (जैसे डेटा लीक करना) में विफल रहता है, तो गेटकीपर कहता है, "प्रवेश निषेध।" AI को जनता के लिए जारी नहीं किया जा सकता है।
- द एविडेंस (साक्ष्य): हर बार जब AI का परीक्षण किया जाता है, तो परिणामों को एक ब्लैक बॉक्स फ्लाइट रिकॉर्डर की तरह सहेजा जाता है। यदि बाद में कुछ गलत होता है, तो आप पीछे देख सकते हैं और देख सकते हैं कि कौन सा परीक्षण विफल हुआ और क्यों।
5. यह क्यों मायने रखता है
पेपर का तर्क है कि अतीत में, हमने AI को एक जादू के खेल की तरह माना। अब जबकि इसका उपयोग गंभीर चीजों (जैसे कानूनी सलाह, चिकित्सा जांच, या ग्राहक सहायता) के लिए किया जा रहा है, हमें इसे इंजीनियरिंग की तरह मानना होगा।
- "प्रॉम्प्ट टिंकरिंग" का अंत: निर्देशों को बेतरतीब ढंग से बदलने के बजाय कि यह कैसा दिखता है, आप उन निर्देशों को विशेष रूप से उन परीक्षणों को पास करने के लिए बदलते हैं जो आपने पहले लिखे थे।
- "सरप्राइज फेल्योर" का अंत: यदि AI वास्तविक दुनिया में गलतियाँ (hallucinations) करने लगता है, तो उस नई गलती को तुरंत एक नए परीक्षण में बदल दिया जाता है ताकि ऐसा दोबारा न हो।
सारांश
यह पेपर अनिवार्य रूप से विश्वसनीय AI बनाने के लिए एक नियम पुस्तिका है। यह कहता है:
- AI से शुरुआत न करें; नियमों से शुरुआत करें।
- ऐसे परीक्षण लिखें जिनमें AI शुरू में विफल हो जाए।
- AI को तब तक ठीक करें जब तक कि वह पास न हो जाए।
- AI को कभी भी तब तक रिलीज़ न करें जब तक कि वह सभी सुरक्षा और व्यावसायिक नियमों को पास न कर ले।
- सब कुछ रिकॉर्ड रखें ताकि आप साबित कर सकें कि यह सुरक्षित है।
यह "आशा करने" कि AI काम करेगा, से बदलकर "सिद्ध करने" की ओर है कि AI काम करता है, इससे पहले कि वह किसी मानव उपयोगकर्ता के संपर्क में आए।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।