एआई एजेंटों को दोबारा प्रयास करने से पहले प्रमाण की ज़रूरत क्यों होती है

जवाब न मिलने पर दोहरी कार्रवाई होने से कैसे रोकें

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

यह केवल एक काल्पनिक स्थिति है। यह उदाहरण ऐसी समस्या दिखाता है जिसे सिर्फ़ मॉडल की सटीकता से हल नहीं किया जा सकता। अगर कोई एजेंट यह तय न कर पाए कि उसकी पिछली कार्रवाई से परिवेश की स्थिति बदली या नहीं, तो उसे क्या करना चाहिए?

Unite.AI ने मॉडल से आगे बढ़कर एजेंटों की विश्वसनीयता पर चर्चा की है। इन चर्चाओं में रिकवरी से जुड़ी समस्याओं के लिए अलग नियम होने चाहिए। किसी महत्वपूर्ण कार्रवाई को दूसरी बार करने से पहले एजेंट को यह पुष्टि करनी चाहिए कि क्या हुआ था, या यह सुनिश्चित करने की वैध गारंटी होनी चाहिए कि कार्रवाई का असर दोहराया नहीं जाएगा।

जवाब न मिलने का मतलब यह नहीं कि कार्रवाई विफल रही

जवाब न मिलने से यह साबित नहीं होता कि कार्रवाई विफल रही। इससे यह पता नहीं चलता कि कार्रवाई शुरू होने से पहले कोई त्रुटि हुई, कार्रवाई पूरी हुई लेकिन उसकी पुष्टि नहीं मिली, या प्रक्रिया अभी जारी है।

यह वितरित प्रणालियों की एक आम समस्या है, जैसा कि Amazon ने बताया है। Amazon बताता है कि दोबारा प्रयास करने की प्रणालियों में एक ही प्रभाव को दोहरने से रोकने के लिए विशेष सुरक्षा उपाय क्यों ज़रूरी हैं। एजेंट आपकी प्रणाली की रिकवरी प्रक्रिया में निर्णय लेने वाली एक नई इकाई जोड़ते हैं। वे यह भी तय कर सकते हैं कि त्रुटियों से उबरने के लिए और क्या किया जाए।

इन फैसलों से कारोबार चलाने का तरीका बदल सकता है। उदाहरण के लिए, अलग डॉलर राशि के साथ रिफंड का दोबारा अनुरोध करना उसी अनुरोध की एक और कोशिश भर नहीं है। इसी तरह, पहली भुगतान सेवा से जवाब मिलना बंद हो जाने पर दूसरी सेवा चुनना भी उसी अनुरोध की एक और कोशिश भर नहीं है।

टीमों को कार्रवाई करने की अनुमति देने और अनिश्चित नतीजे से उबरने की अनुमति देने के बीच अंतर करना चाहिए। मूल स्वीकृति का यह मतलब नहीं कि कार्रवाई को दोबारा करना सुरक्षित है।

हालिया शोध से जोखिम का आकलन

सितंबर 2026 के एक प्रीप्रिंट ने “Where Does Exactly-Once Live?” शीर्षक से LIMBO बेंचमार्क पेश किया और नौ मॉडलों पर 25,930 एपिसोड का परीक्षण किया। इसमें अनुरोध प्राप्त होने की पुष्टि खो जाने, प्रक्रिया में देरी होने और अनुरोधों की प्रतियाँ दोबारा पहुँचने की स्थितियों में सिम्युलेटेड सेवाओं का परीक्षण किया गया।

लेखकों के मुख्य परीक्षण में जिन 1,279 एपिसोड में दोहरा प्रभाव पैदा हुआ, उनमें एजेंटों ने 90% मामलों में काम पूरा होने की सूचना दी। इसलिए, गलत तरीके से प्रक्रिया पूरी होने पर भी कोई एजेंट सफलता की सूचना दे सकता है।

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

शोधपत्र यह भी बताता है कि मौजूदा स्थिति की जाँच करना क्यों नाकाफ़ी हो सकता है। जाँच के बाद भी प्रक्रिया में मौजूद अनुरोध का असर हो सकता है। स्थिति का जवाब खाली होने का यह मतलब भी नहीं कि अनुरोध का असर बाद में नहीं होगा।

दोबारा किए गए प्रयास उसी इरादे से जुड़े होते हैं

अनुरोध प्राप्त करने वाली सेवा किसी कार्रवाई के बार-बार किए गए प्रयासों को पहचानने के लिए इडेम्पोटेंसी कुंजी का इस्तेमाल कर सकती है। अगर यह तरीका ठीक से लागू किया गया हो, तो इससे यह सुनिश्चित होता है कि दोबारा किए गए प्रयासों से अतिरिक्त प्रभाव पैदा न हों। हर दोबारा प्रयास में इडेम्पोटेंसी कुंजी वही रहनी चाहिए।

Stripe के API दस्तावेज़ इडेम्पोटेंसी कुंजियों के काम करने के तरीके और उनकी सीमाओं, दोनों के उदाहरण देते हैं। API v1 में कुंजियों को कम-से-कम 24 घंटे बाद हटाया जा सकता है। हटाई जा चुकी कुंजी का दोबारा इस्तेमाल करने पर नया अनुरोध बनेगा। Stripe यह भी जाँचता है कि अनुरोधकर्ता ने जो पैरामीटर दिए हैं, वे मूल अनुरोध के पैरामीटर से मेल खाते हैं या नहीं।

इडेम्पोटेंसी का व्यावहारिक उपयोग केवल प्रॉम्प्ट तक सीमित नहीं है; यह आपकी इंटीग्रेशन परत में भी लागू होनी चाहिए। किसी कार्रवाई को भेजने से पहले, स्वीकृत कार्रवाई का रिकॉर्ड रखें। उसका पहचानकर्ता, सटीक पैरामीटर, लागू होने पर सेवा प्रदाता का संदर्भ और कार्रवाई की स्थिति दर्ज करें।

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

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

टूल के विवरण काफ़ी नहीं हैं

टूल के विवरण के साथ-साथ, यह भी जाँचें कि अनुरोध प्राप्त करने वाली सेवा की शर्तों में इडेम्पोटेंसी का समर्थन शामिल है या नहीं। उसके कार्यान्वयन का परीक्षण करके पुष्टि करें कि वास्तव में कौन-सी गारंटियाँ पूरी हो रही हैं।

अनिश्चितता को परिचालन स्थिति मानें

आकृति 1. महत्वपूर्ण कार्रवाइयों के लिए प्रस्तावित रिकवरी प्रक्रिया। हर दोबारा प्रयास के लिए मौजूदा अनुमति भी ज़रूरी है।

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

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

यदि सेवा प्रदाता प्रसंस्करण और उसकी दृश्यता की समय-सीमाएँ दर्ज करता है, तो काम रोकना भी उचित हो सकता है। इन सीमाओं के बिना, केवल बीता हुआ समय इस बात की पुष्टि नहीं करेगा कि कार्रवाई नहीं हुई। आपको यह तय करना होगा कि अनसुलझे मामलों की ज़िम्मेदारी किसकी होगी और उन ज़िम्मेदार लोगों को उनकी समीक्षा कब करनी होगी।

विफलता से उबरने के लिए अलग व्यावसायिक प्रक्रिया की ज़रूरत पड़ सकती है

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

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

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

परिनियोजन से पहले दूसरे प्रयास की जाँच करें

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

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

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

आपके मूल्यांकन का प्रश्न स्पष्ट रूप से बताया जाना चाहिए। क्या सिस्टम यह समझा पाया:

• किस कार्रवाई की अनुमति दी गई थी?
• उसके परिणाम का प्रमाण क्या था?
• एक और प्रयास करना क्यों उचित था?

अनसुलझी अनिश्चितता के कारण रुक जाने वाला एजेंट प्रदर्शनों के दौरान कम प्रभावी लग सकता है। लेकिन वास्तविक उपयोग के परिवेश में रुकने से ग्राहक की मूल मंशा सुरक्षित रह सकती है। उपयोगी दृढ़ता का अर्थ है कि सिस्टम अधिकृत कार्यों को पूरा करे, बिना चुपचाप उन्हें दोहराए।