एक सफलता विश्वसनीयता नहीं है: ऑपरेशंस सौंपने से पहले AI एजेंट का परीक्षण कैसे करें

सीधा जवाब: एक सफल डेमो किसी AI एजेंट की विश्वसनीयता के बारे में कुछ भी साबित नहीं करता, क्योंकि सही सवाल यह नहीं है कि उसने कार्य एक बार पूरा किया या नहीं, बल्कि यह है कि क्या वह उसे हर बार सही ढंग से पूरा करता है। Microsoft द्वारा 20 अगस्त 2026 को प्रकाशित एक अध्ययन में, जब हर कार्य एक बार चलाया गया तो सबसे मज़बूत मॉडल ने 65.36% स्कोर किया, लेकिन केवल 25.25% कार्यों में वह सभी बीस प्रयास पास कर सका। यही अंतर उस एजेंट के बीच की दूरी है जो किसी मीटिंग में आपको प्रभावित करता है और उस एजेंट के बीच जिस पर आप ग्राहकों का डेटा भरोसे से सौंप सकते हैं।

Microsoft ने वास्तव में क्या बनाया

इस टूल का नाम Thinkingbox है, जो GitHub पर MIT लाइसेंस के तहत जारी किया गया एक ओपन-सोर्स परीक्षण वातावरण है। विचार सरल और चतुर है: टूल्स को सीधे एजेंट से जोड़ने के बजाय, आप उन्हें MCP-संगत सर्वर के रूप में परिभाषित करते हैं, एजेंट को उसके अपने बैकिंग डेटाबेस वाले एक अलग सत्र में चलाते हैं, और निष्पादन का पूरा ट्रेस रिकॉर्ड करते हैं।

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

इस वातावरण के ऊपर टीम ने Thinkingbox-bench नाम का एक बेंचमार्क बनाया, जिसमें पाँच क्षेत्रों में 507 नीति-आधारित वर्कफ़्लो शामिल हैं: रिटेल और ई-कॉमर्स, यात्रा और आतिथ्य, ऑटो बीमा, एक नियोबैंक में आंतरिक IT सहायता, और एक कंसल्टिंग फर्म में IT और HR सहायता। हर कार्य को बारह मॉडलों पर बीस बार चलाया गया, जिनमें प्रोप्राइटरी और ओपन-वेट दोनों तरह के मॉडल शामिल थे।

यह संख्या एक व्यवसाय मालिक के लिए क्यों मायने रखती है

कल्पना कीजिए कि आप अपने स्टोर में रिटर्न अनुरोधों को प्रोसेस करने का काम एक एजेंट को सौंपते हैं। 65% की सफलता दर कागज़ पर स्वीकार्य लगती है। संचालन में इसका मतलब है कि एक-तिहाई अनुरोध गलत नतीजे पर खत्म होते हैं: एक रिफ़ंड दो बार जारी हो जाना, इन्वेंटरी वापस जोड़े बिना ऑर्डर बंद हो जाना, या किसी ऐसे ग्राहक को छूट दे दी जाना जिसके लिए आपकी नीति इसकी अनुमति नहीं देती।

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

जो विफलता सिस्टम को रोक देती है वह परेशान करने वाली है, लेकिन दिखाई देती है। जो विफलता प्रक्रिया पूरी कर देती है और आपका डेटा गलत छोड़ देती है, वही असल में आपको नुकसान पहुँचाती है, क्योंकि आपको उसका पता एक महीने बाद मिलान के दौरान चलता है।

इससे निराशा का एक आम कारण भी समझ आता है। पायलट इसलिए पास हो जाता है क्योंकि उसमें कार्य को साफ़ डेटा पर एक बार चलाया गया था। वास्तविक संचालन में वही कार्य हज़ारों बार बिखरी हुई संचित स्थिति पर चलता है, और ठीक वहीं 65% और 25% का अंतर सामने आता है।

किसी भी एजेंट को अपनाने से पहले क्या करें

• एक डेमो नहीं, बार-बार रन की माँग करें। एक ही डेटा पर एक ही कार्य के लगातार बीस रन को अपना स्वीकृति मानदंड बनाएँ। जो विक्रेता मना करता है, वह आपको कुछ बता रहा है।
• जवाब का टेक्स्ट नहीं, डेटा की स्थिति मापें। पहले से तय करें कि कार्य के बाद आपके डेटाबेस में रिकॉर्ड कैसा दिखना चाहिए, और वास्तविकता की उससे तुलना करें। एजेंट के अपने सारांश को पढ़कर संतुष्ट न हों।
• केवल आसान कार्य नहीं, नीतियों का परीक्षण करें। आपका अधिकांश काम खुला नहीं है; वह नियमों से बँधा है: रिटर्न की समय-सीमा, क्रेडिट सीमाएँ, प्राथमिकता वाले ग्राहकों के लिए अपवाद। जो एजेंट बिना प्रतिबंधों के सफल होता है, वह पहली वास्तविक शर्त पर ही ढह सकता है।
• परीक्षण सेट अपने ही मामलों से बनाएँ। पिछले कुछ महीनों के बीस वास्तविक मामले लें, जिनमें वे अजीब मामले भी हों जिन्होंने आपके कर्मचारियों को उलझन में डाला, और उन्हें एक स्थायी परीक्षण-सूट में बदल दें जिसे आप किसी भी मॉडल को अपनाने से पहले और हर अपडेट के बाद चलाएँ।
• अधिकार चरणों में दें। ऐसे एजेंट से शुरुआत करें जो सुझाव देता है पर अमल नहीं करता, फिर उसे कम प्रभाव वाले ऑपरेशन करने दें, फिर जैसे-जैसे माप का वास्तविक रिकॉर्ड जमा हो, उसका दायरा बढ़ाएँ। अधिकार डेटा से अर्जित होना चाहिए, धारणाओं से नहीं।

Origami में हम इसे कैसे संभालते हैं

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

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

स्रोत

• शोध पत्र: One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — arXiv (20 अगस्त 2026 को प्रकाशित)
• ओपन-सोर्स रिपॉज़िटरी: GitHub पर microsoft/thinkingbox