इन कंपनियों ने पिछले दो वर्षों में कई AI टूल्स खरीदे हैं: चैट असिस्टेंट, राइटिंग प्लगइन, कस्टमर सर्विस रोबोट, इंटरनल नॉलेज क्वेश्चन-एंड-आंसर। लेकिन असली तकनीकी क्षमता बहुत कम ही जमी है। प्रॉम्प्ट्स अभी भी व्यक्तिगत कंप्यूटर में हैं, बिज़नेस प्रोसेस डॉक्यूमेंट्स के कोनों में बिखरे हुए हैं, इंटेलिजेंट एजेंट के लॉन्च होने के बाद फीडबैक और संशोधन की कमी है, और बिज़नेस के अनुभवी कर्मचारी अभी भी एक ही तरह की पूछताछ में अपने समय का अधिकांश हिस्सा बिता रहे हैं। समस्या अक्सर यह नहीं होती कि मॉडल पर्याप्त बुद्धिमान नहीं है, बल्कि यह होती है कि सिस्टम “काम करने” को प्रबंधनीय पद क्षमता के रूप में डिज़ाइन नहीं करता है।
पहले स्पष्ट करें: चैट विंडो क्यों पद नहीं बन सकता है
चैट रोबोट एक बार सवाल का जवाब देकर खत्म हो जाता है। लेकिन पद को लगातार काम संभालना होता है: जानकारी एकत्र करना, नियमों का निर्णय लेना, सिस्टम को बुलाना, स्थिति को वापस लिखना, और अपवाद के मामले में आगे बढ़ना। ट्रैवल रिइम्बर्समेंट एक ठीक उदाहरण है—उपयोगकर्ता पहले कह सकता है, “मेरा ट्रैवल रिइम्बर्समेंट कर दो”, फिर बीच में पूछ सकता है, “इस महीने का क्रेडिट कितना बचा है?”, और फिर एक और इनवॉइस जोड़ सकता है। अगर सिस्टम हर बार की बातचीत को नया सेशन मानता है, तो प्रोसेस टूट जाएगा, कंटेक्स्ट गायब हो जाएगा, और बाद में यह पता लगाना भी मुश्किल हो जाएगा कि गलती नियमों की थी या इंटरफ़ेस की।
इंडस्ट्री में पहले से ही इंटेलिजेंट एजेंट को “डिजिटल एम्प्लॉयी” के रूप में डिज़ाइन करने की प्रथा है: उसे पद, वर्क नंबर, क्षमता की सीमा और कार्य रिकॉर्ड दिया जाता है, फिर संशोधनीय SOP, नॉलेज बेस, टूल्स और एक्सीक्यूशन ट्रैक के साथ जोड़ा जाता है। ओपन सोर्स की दिशा में, OpenBMB जैसी संस्थाओं द्वारा जारी StaffDeck एजेंट को एक ऑपरेशनल रिसोर्स कॉम्बिनेशन के रूप में लिखता है, न कि एक प्रॉम्प्ट के टुकड़े के रूप में। कंपनियों के लिए अपने द्वारा विकसित या कस्टमाइज़्ड सिस्टम के लिए, जिसे उधार लेने की जरूरत है, वह उत्पाद का नाम नहीं है, बल्कि यह ऑब्जेक्ट मॉडल है।
बिज़नेस लॉजिक: सिस्टम में कम से कम सात प्रकार के ऑब्जेक्ट होने चाहिए
डिजिटल एम्प्लॉयी सिस्टम बनाने के लिए, पहले बिज़नेस ऑब्जेक्ट को स्पेसिफ़िकेशन में लिखें, फिर मॉडल के चयन पर बात करें।
- पद का फ़ाइल: नाम या रोल नाम, वर्क नंबर, जिम्मेदारी, ऑनलाइन स्टेटस, सर्विस ऑब्जेक्ट। बिना फ़ाइल के, अधिकार और मूल्यांकन का कोई आधार नहीं है।
- क्षमता की सीमा: किन दस्तावेज़ों को पढ़ा जा सकता है, किन फ़ील्ड्स को लिखा जा सकता है, और किस बात का वादा नहीं किया जा सकता है। यह सीमा एडमिनिस्ट्रेटर द्वारा संशोधित की जा सकती है, न कि प्रॉम्प्ट में लिखी गई हो।
- SOP / प्रोसेस-ओरिएंटेड स्किल: जटिल प्रोसेस को नोड्स में तोड़ दें, शर्तों के आधार पर ब्रांचिंग, टूल्स के उपयोग, नॉलेज रिसर्च और मैनुअल ट्रांसफर का समर्थन करें।
- नॉलेज ऑन्टोलॉजी: विषय, नियम, स्रोत और ऑपरेशनल मैनुअल को अलग-अलग संग्रहीत करें; जवाब ज़रूरी रूप से स्रोत की ओर इशारा करे, और रिसर्च में ट्यूनिंग की ज़रूरत हो।
- टूल्स का एक्सेस: HTTP इंटरफ़ेस या MCP, क्रेडिट की जाँच, दस्तावेज़ बनाने और स्थिति बदलने के लिए इस्तेमाल करें, न कि सिर्फ एक वाक्य जनरेट करने के लिए।
- टाइमिंग टास्क: डेली रिपोर्ट अग्रेज़मेंट, टाइमआउट के लिए रिमाइंडर, स्टॉक इंस्पेक्शन जैसे आवर्ती कार्य, जिन्हें उपयोगकर्ता के बोलने का इंतज़ार नहीं करना चाहिए।
- ट्रेस और फीडबैक: रूट, स्टेप्स, टूल्स, नॉलेज और जवाब का रिकॉर्ड रखें; लाइक, डिसलाइक और मैनुअल टेकओवर अगले संशोधन चक्र में जाएं।
एक वास्तविक रिक्वेस्ट में अक्सर कई कार्य होते हैं। डिजिटल एम्प्लॉयी को पहले रिइम्बर्समेंट SOP में जाना चाहिए, सभी फ़ील्ड्स एकत्र करना और नियमों का निर्णय लेना चाहिए, फिर क्रेडिट चेक SOP में जाकर इंटरफ़ेस को बुलाना चाहिए। उपयोगकर्ता बीच में नीति के बारे में पूछता है, तो वर्तमान नोड को सेव करना चाहिए, जवाब देने के बाद फिर पुराने प्रोसेस में लौटना चाहिए। नियमों से बाहर के मामले में, कंटेक्स्ट को बनाने वाले या ड्यूटी पर रहने वाले को सौंप देना चाहिए, बिना आधार के जबरन जवाब देने की अनुमति नहीं है।
डिज़ाइन लॉजिक: रोल, स्टेट मशीन, नॉलेज की लेयरिंग
रोल कैसे बदला जाता है
कम से कम चार प्रकार के लोग होने चाहिए: बनाने वाले (अनुभव को निश्चित करने वाले कर्मचारी), एडमिनिस्ट्रेटर (अधिकार, प्रकाशन, क्रेडिट का प्रबंधन करने वाले), उपयोगकर्ता (डिजिटल एम्प्लॉयी को काम देने वाले), ड्यूटी पर रहने वाले (अपवाद को संभालने वाले)। बनाने वाले को डिफ़ॉल्ट रूप से स्टॉक और कीमत में बदलाव का अधिकार नहीं होना चाहिए; उपयोगकर्ता को पूरी प्रॉम्प्ट और कीज़ नहीं दिखाई जानी चाहिए। ओपन इंटरफ़ेस भी लेयर्ड होना चाहिए: अकाउंट लेवल की कीज़ संसाधनों के प्रबंधन का अधिकार रखती हैं, जबकि कर्मचारी लेवल की कीज़ सिर्फ सेशन बनाने और अपने ट्रैक को पढ़ने का अधिकार रखती हैं।
SOP में स्टेट मशीन का इस्तेमाल करें, सिर्फ डायलॉग मेमोरी का इस्तेमाल न करें
प्राकृतिक भाषा से ड्राफ्ट तैयार किया जा सकता है, लेकिन एक्सीक्यूशन स्टेट मशीन के ज़रिए होना चाहिए: वर्तमान नोड, एकत्र किए गए स्लॉट्स, उपयोग के लिए उपलब्ध टूल्स, फेल्योर रिट्राय, मैनुअल नोड। कार्य बाधित होने पर कंटेक्स्ट को सीरियलाइज़ करना चाहिए, ताकि वापस पुराने नोड में जा सके और जारी रखा जा सके। कई SOP के लिए रीयल-टाइम स्विचिंग की अनुमति है, लेकिन स्विचिंग के दौरान “कहाँ से आया, किस जानकारी को पुष्टि के लिए लाया गया” का रिकॉर्ड रखना चाहिए, ताकि उपयोगकर्ता को दोबारा फॉर्म भरने की ज़रूरत न पड़े। वर्जन और ब्रांच को रोलबैक करने की सुविधा होनी चाहिए; एक बार एक प्रॉम्प्ट में बदलाव कर देने पर लॉन्च हो जाता है, लेकिन बाद में जिम्मेदारी नहीं ली जा सकती।
नॉलेज को एक बड़े मिक्स में न बनाएं
डॉक्यूमेंट, चैप्टर, पेज, अब्स्ट्रैक्ट के आधार पर नेविगेशनल इंडेक्स बनाएं, पहले यह तय करें कि जानकारी किस कैटेगरी में हो सकती है, फिर असली टेक्स्ट को लोकेट करें। नॉलेज को बकेट्स में बांटें: नियमों का फ्रेमवर्क, प्रोडक्ट डिस्क्रिप्शन, आफ्टर-सेल्स टॉक, अपवाद केसेज़ अलग-अलग हों, और डायरेक्ट रिसर्च वर्सेस ऑल-राउंड कीवर्ड्स से ज़्यादा स्टेबल हो। हर जवाब को स्रोत, नियम और बिज़नेस थीम से जोड़ें; टेस्टिंग एनवायरमेंट में यह देखना चाहिए कि “यह टुकड़ा क्यों हिट हुआ”। रिसर्च ट्यूनिंग एक बड़े मॉडल को बदलने से ज़्यादा बार समस्या का हल करती है।
डेवलपमेंट और लॉन्च: इंटरफ़ेस, आइसोलेशन, ऑब्जर्वेशन, एक्सेप्टेंस
रनटाइम में एकीकृत एंट्री पॉइंट की सिफारिश करें, ताकि हर स्किल अलग-अलग लिंक न बनाकर स्टेट ड्रिफ्ट से बचा जा सके। क्षमता की खोज, आइसोलेशन एक्सीक्यूशन, वर्क पीस इंटेग्रिटी, क्रेडिट कैलकुलेशन रनटाइम में ही पूरे जाने चाहिए, न कि अनुमानों पर निर्भर रहना चाहिए। स्किल को इंटरनल मार्केट में लॉन्च करने से पहले अधिकार स्कैन करें: ऑथेंटिकेशन हेड, एनवायरमेंट वेरिएबल्स, कनेक्शन क्रेडेंशियल्स को सामान्य रीडिंग इंटरफ़ेस में नहीं दिखाना चाहिए।
- एक्सीक्यूशन चैनल: सिंक्रोनस फ्लो चैट के लिए उपयुक्त है; एसिंक्रोनस रन + इवेंट फ्लो ब्रेकड लाइन और टास्क लाइन के लिए उपयुक्त है, दोनों एक ही कर्नेल का इस्तेमाल करते हैं।
- चैनल आइडेंटिटी: वीचैट, एंटरप्राइज़ वीचैट, फ़्लाइट, डिंगडिंग एंट्री पॉइंट बना सकते हैं, लेकिन कर्मचारी आइडेंटिटी, सेशन और ट्रेस को एकीकृत करना चाहिए, हर चैनल के अलग-अलग मेमोरी बनाने की अनुमति नहीं है।
- सिक्योरिटी: मॉडल कॉन्फ़िगरेशन में सिर्फ पहले से मौजूद कॉन्फ़िगरेशन नंबर का उल्लेख करें, आपूर्तिकर्ता की कीज़ को वापस न भेजें; टूल्स के नतीजे ट्रेस में जाते समय डिसएनोनाइज़ कर दें।
- मैनुअल बैकअप: टाइमआउट, लो वेलिडिटी, अनधिकृत एक्सेस, उपयोगकर्ता के मैनुअल ट्रांसफर, चारों को कंटेक्स्ट पूरी तरह से सौंपना चाहिए।
एक्सेप्टेंस में सिर्फ “चैट करने की क्षमता” का टेस्ट न करें। एक समूह रिपीटेबल स्क्रिप्ट्स दें: नॉर्मल क्लोज्ड लूप, बीच में पूछताछ, क्रेडिट की कमी, इंटरफ़ेस का टाइमआउट, अनधिकृत राइटिंग, बिना स्रोत के जवाब देना। हर स्क्रिप्ट को चेक करें: नोड रिकवरी हुई है या नहीं, दस्तावेज़ सही लिखा गया है या नहीं, ट्रेस पूरी हुई है या नहीं, अपवाद को किसी व्यक्ति तक पहुंचाया गया है या नहीं। सैंपलिंग पास रेट, टाइमआउट हैंडलिंग रेट, बिना आधार के जवाब देने की बार बार गिनती, सेटिस्फैक्शन स्टार रेट से ज़्यादा उपयुक्त हैं लॉन्च के लिए गेटकीपर के रूप में।
लॉन्च का क्रम: पहले एक रिपीटेबल वर्क सेगमेंट
शुरू में ही ऑल-राउंड असिस्टेंट न बनाएं। सेल्स फ़ॉलोअप रिपोर्ट, एप्रूवल रिमाइंडर, नियमों के सवाल, फ़ीस प्री-एप्रूवल में से एक ऐसा सेगमेंट चुनें, जिसमें रोज़ाना आधे घंटे से ज़्यादा रिपीट होता है; इनपुट, आउटपुट, अधिकार, अपवाद को चार वाक्यों में लिखें, फिर SOP और दो-तीन रीड-ऑनली या लिमिटेड राइटिंग इंटरफ़ेस के साथ जोड़ें। मेन डेटा गंदा हो, एप्रूवल नोड क्लियर न हो, तो पहले ऑब्जेक्ट और स्टेट को फिक्स करें, फिर इंटेलिजेंट एक्सीक्यूशन को ओवरलैप करें—गंदे डेटा के बाद ऑटोमेटेड तरीके से पूरे कंपनी में फैल जाएगा, जिससे ज़्यादा तेज़ी से फैलेगा।
डिज़ाइन को सही मानने का तरीका: जो ग्रुप के रिमाइंडर और फॉर्म भरने पर निर्भर था, वह अब मुख्य पथ नहीं है; रिपोर्ट, रिमाइंडर, अग्रेज़मेंट को दस्तावेज़ों के साथ सैंपलिंग करना चाहिए; अस्पष्ट मामलों के लिए अपग्रेड ऑब्जेक्ट है; संवेदनशील ऑपरेशन के लिए कोई सेंसर है, लॉग्स चेक करने की सुविधा है। डेवलपमेंट की योग्यता को मापने के लिए, देखें एक ही SOP के बाधित होने के बाद रिकवरी हो सकती है या नहीं, जवाब का स्रोत की ओर इशारा करने की क्षमता है या नहीं, बाउंड्री केसेज़ के अगले संशोधन चक्र में जाने की क्षमता है या नहीं। ये तीन चीज़ें पार हो गईं, तो फिर पदों का विस्तार करें, जो बहुत सारे चैट एंट्री पॉइंट बनाने से ज़्यादा स्टेबल है।
डिजिटल एम्प्लॉयी सिस्टम की तकनीकी कठिनाई, डायलॉग जनरेशन में नहीं है, बल्कि पद, प्रोसेस, नॉलेज, टूल्स और ट्रैक को वर्जनेबल सॉफ़्टवेयर ऑब्जेक्ट्स में बदलने में है। प्रॉम्प्ट्स हफ़्ते में दस बार बदले जा सकते हैं, लेकिन ऑब्जेक्ट मॉडल एक बार बिखर गया, तो बाद में हर स्किल अलग-अलग लिखेगी।पहले इन सात प्रकार की वस्तुओं और स्टेट मशीनों को चला लें, तभी मॉडल अपग्रेड करना संभव है; अन्यथा हर बार मॉडल बदलने पर, यह एक नया प्रोजेक्ट होगा, न कि किसी कॉन्फ़िगरेशन बदलाव का।