यह डायग्राम भरोसे की सीमा (trust boundary) को दिखाता है। यूज़र इनपुट पर भरोसा नहीं किया जा सकता क्योंकि कोई भी कॉलर कुछ भी टाइप कर सकता है, और टूल के नतीजों पर भी भरोसा नहीं किया जा सकता क्योंकि टूल ऐसा चौंकाने वाला कंटेंट दे सकता है जो वापस मॉडल में भेजा जाता है।
इस लूप का सुरक्षा के लिहाज़ से अहम मतलब यह है कि मॉडल न तो डेटाबेस पढ़ता है, न रिफंड जारी करता है और न ही पॉलिसी लागू करता है। मॉडल सिर्फ़ ऐसा टेक्स्ट बनाता है जो बताता है कि आगे क्या करना है, और ShopEasy एप्लिकेशन कोड वह हिस्सा है जो असल में काम करता है और टूल के ज़रिए डेटा देता है।
यह अंतर तभी साफ़ रहता है जब हम तीन पहचानों को अलग-अलग रखें। एंड यूज़र वह कस्टमर है जो ऑर्डर के बारे में पूछ रहा है, और एंड यूज़र की अनुमतियों (permissions) से यह तय होना चाहिए कि वे कौन से ऑर्डर देख सकते हैं और क्या काम करने के लिए कह सकते हैं। ShopEasy सर्विस हमारा बैकएंड है, जिसके पास डेटाबेस एक्सेस और request_refund चलाने जैसी ज़्यादा क्षमताएँ होती हैं। LLM प्रोवाइडर क्रेडेंशियल वह API की (API key) या सर्विस टोकन है जिसका इस्तेमाल ShopEasy मॉडल एंडपॉइंट को कॉल करने के लिए करता है, और वह क्रेडेंशियल सिर्फ़ मॉडल के इस्तेमाल की इजाज़त देता है, कस्टमर के कामों की नहीं। इन पहचानों को मिलाने से ऐसी गड़बड़ियाँ हो सकती हैं जहाँ बैकएंड पैसे खर्च करता है, डेटा दिखाता है, या ऐसे यूज़र की तरफ़ से काम करता है जिसे वे काम शुरू करने की इजाज़त नहीं होनी चाहिए। अगर कुछ गलत होता है, तो कौन सा हिस्सा असल में नियम लागू कर सकता है: प्रॉम्प्ट टेक्स्ट, LLM, या ShopEasy एप्लिकेशन कोड?
ShopEasy का सपोर्ट चैटबॉट “मेरा ऑर्डर कहाँ है?” सवाल का जवाब lookup_order जैसे बैकएंड फ़ंक्शन को कॉल करके दे सकता है, और फिर नतीजे को एक ऐसे काम के वाक्य में बदल सकता है जिसे यूज़र पढ़ सके।
इस कोर्स में, लार्ज लैंग्वेज मॉडल (LLM) क्या है, इसे आसान शब्दों में ऐसे समझा जा सकता है: LLM हमारे भेजे गए टेक्स्ट को लेता है और आगे भेजे जाने वाले टेक्स्ट का अनुमान लगाता है। यह एक बहुत शक्तिशाली ऑटो-कम्प्लीट फ़ीचर की तरह है जो पूरे पैराग्राफ़ बना सकता है।
ऑर्डर से जुड़े उस एक सवाल में भी, ShopEasy के पास पहले से ही कुछ अलग-अलग इनपुट होते हैं। सिस्टम प्रॉम्प्ट वह प्राइवेट निर्देश है जिसे ShopEasy हर रिक्वेस्ट के साथ भेजता है, जैसे “आप ShopEasy सपोर्ट हैं। कम शब्दों में बात करें। अगर ऑर्डर नंबर न हो, तो उसे मांगें।” बातचीत का इतिहास (conversation history) पिछली बातचीत का रिकॉर्ड होता है जिसे ShopEasy शामिल करता है ताकि मॉडल एक जैसा व्यवहार बनाए रख सके। यूज़र इनपुट नया मैसेज होता है, जैसे “मेरा ऑर्डर कहाँ है?” टूल्स सर्वर-साइड फ़ंक्शन होते हैं जिन्हें ShopEasy चला सकता है, जैसे lookup_order और request_refund, जब चैटबॉट को डेटा की ज़रूरत होती है या कोई काम करना होता है।
एक बार जब ShopEasy के पास ये हिस्से आ जाते हैं, तो एक रिक्वेस्ट एक ऐसे लूप से गुज़रती है जिसे बार-बार दोहराया जा सकता है। यूज़र का मैसेज ShopEasy API पर आता है, और एप्लिकेशन सिस्टम प्रॉम्प्ट, बातचीत का इतिहास और नए यूज़र इनपुट को मिलाकर मॉडल के लिए एक प्रॉम्प्ट तैयार करता है। एप्लिकेशन उस प्रॉम्प्ट को LLM प्रोवाइडर को भेजता है, और प्रोवाइडर मॉडल का आउटपुट देता है जो या तो सीधा टेक्स्ट जवाब होता है या आर्ग्युमेंट्स के साथ सुझाया गया टूल कॉल।
जब मॉडल किसी टूल कॉल का सुझाव देता है, तो ShopEasy एप्लिकेशन कोड तय करता है कि उसे चलाना है या नहीं, और फिर शिपिंग स्टेटस जानने के लिए lookup_order या रिफ़ंड शुरू करने के लिए request_refund जैसा कोई खास फ़ंक्शन चलाता है। इसके बाद ShopEasy टूल के नतीजे को एक और मैसेज के तौर पर मॉडल को वापस भेजता है ताकि मॉडल यूज़र के लिए आखिरी जवाब लिख सके, और सिर्फ़ वही आखिरी जवाब यूज़र तक पहुँचता है। सुरक्षा और बाद में डीबगिंग के लिए एक बात ज़रूरी है। कॉल्स के बीच मॉडल की अपनी कोई मेमोरी नहीं होती, इसलिए ShopEasy को हर बार बातचीत का इतिहास फिर से भेजना पड़ता है, वरना मॉडल ऐसे जवाब देता है जैसे उसने यूज़र को पहले कभी देखा ही न हो। आइए इस लूप को एक रिक्वेस्ट-पाथ डायग्राम में समझते हैं।