6.3 जेनेरेटिव AI और LLM एप्लिकेशन

अवलोकन और प्रेरणा

जेनेरेटिव AI, और विशेष रूप से लार्ज लैंग्वेज मॉडल (LLM), प्राकृतिक-भाषा निर्देशों से धाराप्रवाह पाठ, कोड, सारांश, और संरचित डेटा उत्पन्न कर सकते हैं। यह उन्हें सहायकों, खोज, दस्तावेज़ प्रोसेसिंग, और स्वचालन के लिए शक्तिशाली निर्माण खंड बनाता है। लेकिन ये शक्तियाँ एक विशिष्ट जोखिम प्रोफ़ाइल के साथ आती हैं। LLM प्रायिकतावादी (probabilistic) हैं। वे आत्मविश्वासी असत्यताएँ (मतिभ्रम) उत्पन्न कर सकते हैं। वे इस बात के प्रति संवेदनशील हैं कि आप उन्हें कैसे प्रॉम्प्ट करते हैं। और वे प्रॉम्प्ट इंजेक्शन (मॉडल के व्यवहार को हाईजैक करने के लिए इनपुट में तस्करी किए गए दुर्भावनापूर्ण निर्देश) जैसे नए हमला सतहें खोलते हैं। इसलिए निर्भर करने योग्य LLM एप्लिकेशन बनाना मॉडल के बारे में कम और इसके इर्द-गिर्द की इंजीनियरिंग के बारे में अधिक है: आप संदर्भ कैसे प्रदान करते हैं, विश्वसनीय ज्ञान में उत्तरों को कैसे आधारित करते हैं, आउटपुट को कैसे सीमित करते हैं, और गुणवत्ता का मूल्यांकन कैसे करते हैं।

बड़ी टीमों के लिए, LLM एप्लिकेशन नए पैटर्न की माँग करते हैं जो पारंपरिक सॉफ़्टवेयर और शास्त्रीय मशीन लर्निंग दोनों से भिन्न हैं। अक्सर कोई प्रशिक्षण चरण नहीं होता। इसके बजाय, व्यवहार प्रॉम्प्ट, प्राप्त संदर्भ, टूल परिभाषाओं, और गार्डरेल (रनटाइम जाँचें जो मॉडल के इनपुट और आउटपुट को सीमित करती हैं) द्वारा आकार दिया जाता है। यह इंजीनियरिंग प्रयास को संदर्भ प्रबंधन, प्राप्ति गुणवत्ता, ऑर्केस्ट्रेशन, और मूल्यांकन की ओर स्थानांतरित करता है। बड़े पैमाने पर LLM अपनाने वाले उद्यमों को साझा पैटर्न की आवश्यकता है ताकि हर टीम उन्हीं विफलता मोड को कठिन तरीके से फिर से न खोजे।

सरकार और विनियमित संगठनों को अतिरिक्त माँगों का सामना करना पड़ता है। एक LLM जो एक नीति उद्धरण गढ़ता है या संवेदनशील डेटा लीक करता है वह केवल एक बग नहीं है; यह एक कानूनी या सुरक्षा घटना हो सकती है। इन सेटिंग को आधिकारिक स्रोतों में आधारीकरण, सख्त आउटपुट सत्यापन, महत्वपूर्ण आउटपुट के लिए मानवीय निगरानी, और यह स्पष्ट रिकॉर्ड चाहिए कि सिस्टम से क्या पूछा गया और इसने क्या उत्पन्न किया। इस अध्याय की तकनीकें (रिट्रीवल-ऑगमेंटेड जनरेशन, गार्डरेल, और कठोर मूल्यांकन) वे हैं जो LLM को उच्च-दांव वाले संदर्भों में डिप्लॉय करने के लिए पर्याप्त सुरक्षित बनाती हैं। Anthropic के Claude मॉडल कई सक्षम प्रदाताओं में से एक अग्रणी विकल्प हैं; यहाँ की प्रथाएँ लागू होती हैं चाहे आप कोई भी मॉडल चुनें।

मुख्य सिद्धांत

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

सिफारिशें

प्रॉम्प्ट इंजीनियर करें और संदर्भ को जानबूझकर प्रबंधित करें

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

रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) के साथ उत्तरों को आधारित करें

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

संयम के साथ एजेंट और टूल उपयोग बनाएँ

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

गार्डरेल जोड़ें और आउटपुट सत्यापित करें

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

ऑफ़लाइन, ऑनलाइन, और मनुष्यों के साथ मूल्यांकन करें

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

ट्रेड-ऑफ़: पक्ष और विपक्ष

विकल्प	पक्ष	विपक्ष	कब सबसे अच्छा
शुद्ध प्रॉम्प्टिंग	सरल, तेज़, बदलने में सस्ता	सीमित आधारीकरण, मतिभ्रम कर सकता है	व्यापक कार्य, कम दांव
RAG	वर्तमान, आधारित, उद्धरण योग्य	प्राप्ति को सही पाना कठिन है	ज्ञान-भारी, तथ्यात्मक कार्य
टूल वाले एजेंट	शक्तिशाली, कार्य कर सकते हैं	बड़ी हमला सतह, नियंत्रित करना कठिन	गार्डरेल के साथ अच्छी तरह दायरे वाला स्वचालन
बड़ा, मज़बूत मॉडल	बेहतर गुणवत्ता और तर्क	अधिक लागत और लेटेंसी	जटिल या उच्च-दांव वाले कार्य
छोटा, सस्ता मॉडल	तेज़ और सस्ता	कठिन कार्यों पर कमज़ोर	उच्च मात्रा, सरल कार्य

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. एक LLM सुविधा को जनता के सामने आने से पहले कौन सी सटीकता और आधारीकरण सीमा पार करनी होगी, और कौन इसे स्वीकृत करता है? एक धाराप्रवाह उत्तर जो गलत स्रोत उद्धृत करता है या एक नीति गढ़ता है वह बिना उत्तर से बदतर है, और सरकार में एक गढ़ा हुआ उद्धरण एक कानूनी घटना है, बग नहीं। एक बड़ी टीम के लिए, एक स्पष्ट सीमा हर समूह को मूड के अनुसार अपनी खुद की निजी सीमा तय करने से रोकती है। “पर्याप्त आधारित” की अपनी परिभाषा लाएँ: क्या हर दावे को एक प्राप्त, सत्यापित स्रोत तक ट्रेस होना चाहिए, क्या सिस्टम को इनकार करना चाहिए जब प्राप्ति खाली आए, और आपका प्रतिकूल मूल्यांकन सेट वास्तव में क्या कवर करता है। देखने का संकेत यह है कि क्या कोई वर्तमान में बिना किसी रिग्रेशन रन के सीधे उपयोगकर्ताओं को एक प्रॉम्प्ट परिवर्तन शिप कर सकता है। यदि दांव कानूनी या सुरक्षा से संबंधित हैं, तो उत्तर को रिलीज़ से पहले सबसे उच्च-जोखिम वाले आउटपुट को वास्तविक अधिकार वाले एक मानवीय समीक्षक के माध्यम से रूट करना चाहिए।

2. हमारी कौन सी LLM सुविधाएँ गुप्त रूप से एजेंट हैं, और क्या हर टूल को न्यूनतम विशेषाधिकार और अपरिवर्तनीय क्रियाओं पर एक मानवीय गेट दिया गया है? कोई भी सुविधा जो मॉडल को टूल कॉल करने या कई चरणों में कार्य करने देती है वह एजेंट क्षेत्र में पार कर गई है, और हर टूल एक गलत या हेरफेर किए गए मॉडल के नुकसान पहुँचाने का एक और तरीका है। LLM को आंतरिक API में जोड़ने वाले उद्यमों के लिए, यह प्रश्न उस जोखिम को सामने लाता है जिसे एक “सरल सहायक” लेबल छिपाता है। मॉडल जो भी टूल आमंत्रित कर सकता है उसकी एक सूची लाएँ, इसका आर्गुमेंट सत्यापन, इसका विशेषाधिकार दायरा, और कौन सी क्रियाएँ (संचार भेजना, पैसा स्थानांतरित करना, रिकॉर्ड बदलना) पुष्टि की माँग करती हैं। चर्चा करें कि क्या एजेंट लूप बाध्य, अवलोकनीय, और बाधित करने योग्य हैं। उत्तर को दायरे कसने चाहिए और जहाँ भी वर्तमान में बिना किसी के एक महत्वपूर्ण या अपरिवर्तनीय क्रिया पहुँच योग्य है वहाँ मानवीय स्वीकृति गेट जोड़ने चाहिए।

3. हमें एक दिन के भीतर कैसे पता चलेगा कि हमारी प्राप्ति गुणवत्ता गिर गई है, यह देखते हुए कि गलत अंश पर बना एक आत्मविश्वासी उत्तर ठीक दिखता है? RAG उत्तरों को केवल तभी विश्वसनीय बनाता है जब प्राप्ति वास्तव में उस अंश को सामने लाती है जिसमें उत्तर होता है, और जैसे-जैसे दस्तावेज़ बदलते हैं, चंक बासी होते हैं, या एम्बेडिंग आपके डोमेन से बहती है, प्राप्ति चुपचाप सड़ती है। क्योंकि मॉडल अभी भी खराब संदर्भ पर धाराप्रवाह लिखता है, उपयोगकर्ता तब तक शिकायत नहीं कर सकते जब तक भरोसा पहले ही खो न जाए। प्राप्ति लेटेंसी और रीकॉल के अपने वर्तमान माप लाएँ, आप कैसे जाँचते हैं कि प्राप्त अंश वास्तव में उत्तर रखते हैं, और इंडेक्स ताज़गी दस्तावेज़ परिवर्तनों के साथ कैसे गति रखती है। उच्च-दांव या सार्वजनिक डिप्लॉयमेंट के लिए, ऑडिट के लिए प्राप्त स्रोतों को लॉग करने पर चर्चा करें ताकि आप एक खराब उत्तर को उसके खराब अंश तक ट्रेस कर सकें। यदि आपके पास कोई प्राप्ति मूल्यांकन बिल्कुल नहीं है, तो आप आस्था पर आधारीकरण कर रहे हैं।

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

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

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

क्षेत्र लेंस

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

लघु व्यवसाय। आपके पास संभवतः कोई ML विशेषज्ञ नहीं है, इसलिए एक निर्माण को स्टाफ करने के बजाय उन टूलों में एम्बेडेड LLM सुविधाएँ खरीदें जिनका आप पहले से उपयोग करते हैं। जोखिम को एक सादे प्रश्न के रूप में तैयार करें: एक आत्मविश्वासी गलत उत्तर आपको कहाँ एक ग्राहक की कीमत चुका सकता है, और आउटपुट के बाहर जाने से पहले इसे कौन जाँचता है। उन विक्रेताओं को प्राथमिकता दें जो अपने स्रोत दिखाते हैं, आपको लूप में एक मानव रखने देते हैं, और जब AI गलत व्यवहार करे तो इसे बंद करना आसान बनाते हैं।

उद्यम। समस्या कई टीमों में पैमाना है: RAG, गार्डरेल, और टूल स्कीमा के लिए साझा पैटर्न प्रकाशित करें, साथ ही एक सामान्य मूल्यांकन हार्नेस और प्रॉम्प्ट रजिस्ट्री ताकि हर समूह उन्हीं विफलता मोड को फिर से खोजना बंद कर दे। अनुमान लागत और मानवीय समीक्षा को स्पष्ट रूप से बजट करें, इंटरफ़ेस परत को मानकीकृत करें ताकि मॉडल बदलने योग्य बने रहें, और न्यूनतम विशेषाधिकार, बाध्य लूप, और ऑडिट लॉगिंग के साथ एजेंट को केंद्रीय रूप से गवर्न करें। LLM सुविधाओं को मीट्रिक और किल मानदंड वाले एक पोर्टफ़ोलियो के रूप में प्रबंधित करें, पायलटों के बिखराव के रूप में नहीं।

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

उदाहरण

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

उद्यम। एक सॉफ़्टवेयर कंपनी ने अपने उत्पाद दस्तावेज़ीकरण पर एक आंतरिक सहायता सहायक बनाया। इसने RAG का उपयोग किया ताकि उत्तर विशिष्ट दस्तावेज़ पेज उद्धृत करें, मॉडल को “मुझे नहीं पता” कहने के लिए कहा जब प्राप्ति विफल हुई, और सत्यापित किया कि हर उद्धृत स्रोत वास्तव में मौजूद था। प्रॉम्प्ट वर्जन-नियंत्रित थे और हर परिवर्तन पर वास्तविक सहायता प्रश्नों के एक सुइट के खिलाफ़ परीक्षित थे। सहायक ने नियमित टिकट को टाला और किसी भी कम-विश्वास वाली चीज़ को मानवीय एजेंटों तक बढ़ाया, जबकि ऑनलाइन मीट्रिक ने समाधान और सुधार दरों को ट्रैक किया।

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

LLM एप्लिकेशन भाषा-भारी काम को स्वचालित करके ROI देते हैं: प्रश्नों का उत्तर देना, दस्तावेज़ों को सारांशित करना, सामग्री का मसौदा तैयार करना, और असंरचित पाठ से संरचना निकालना। मूल्य टाले गए टिकट, तेज़ मसौदा तैयार करना, कम मैनुअल समीक्षा, और नई स्व-सेवा क्षमताओं के रूप में सामने आता है। क्योंकि अक्सर कोई प्रशिक्षण चरण नहीं होता, पहले मूल्य का समय छोटा होता है, एक प्रमुख आकर्षण।

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

1. आरंभ। अलग-थलग परियोजनाओं में तदर्थ प्रॉम्प्टिंग; कोई आधारीकरण, गार्डरेल, या मूल्यांकन नहीं; प्रॉम्प्ट जहाँ भी किसी ने उन्हें पेस्ट किया वहाँ रहते हैं, और मतिभ्रम उत्पादन में खोजे जाते हैं।
2. विकास। कुछ टीमें RAG और प्रॉम्प्ट वर्जनिंग, बुनियादी आउटपुट सत्यापन, और एक छोटा मैनुअल मूल्यांकन सेट जोड़ती हैं, लेकिन प्रथाएँ टीम दर टीम भिन्न होती हैं और साझा अपेक्षा के बजाय व्यक्तिगत चैंपियन पर टिकी होती हैं।
3. मानकीकरण। RAG, गार्डरेल, टूल स्कीमा, और प्रॉम्प्ट वर्जनिंग के लिए दस्तावेज़ीकृत पैटर्न संगठन भर में लागू हैं; स्वचालित ऑफ़लाइन मूल्यांकन हर प्रॉम्प्ट या मॉडल परिवर्तन पर चलता है; उच्च-दांव वाले प्रवाह ऑनलाइन मीट्रिक और मानवीय समीक्षा रखते हैं।
4. प्रबंधन। पोर्टफ़ोलियो को बेसलाइन के मुकाबले मापा जाता है: प्राप्ति रीकॉल, मतिभ्रम और इनकार दरें, इंजेक्शन-रक्षा कवरेज, प्रति-कॉल लागत और लेटेंसी, और एस्केलेशन और सुधार दरें डैशबोर्ड पर ट्रैक की जाती हैं; रिलीज़ गेट और किल मानदंड राय के बजाय साक्ष्य पर चलते हैं, और एक रिग्रेशन रन किसी भी ऐसे परिवर्तन को अवरुद्ध करता है जो एक मीट्रिक को गलत दिशा में ले जाता है।
5. ऑर्केस्ट्रेशन। निरंतर ऑफ़लाइन और ऑनलाइन मूल्यांकन व्यावसायिक परिणामों से जुड़ा है; इंजेक्शन रक्षा, एजेंट, और आधारीकरण गवर्न्ड और अवलोकनीय हैं; संगठन नियमित रूप से LLM सुविधाओं को सेवानिवृत्त, पुनः-ट्यून, और पुनः-दायरा देता है, और गुणवत्ता, लागत, और जोखिम बदलने पर मॉडल बदलता है।

चर्चा के लिए विचार

• आप कैसे तय करते हैं कि किन आउटपुट को उपयोग से पहले मानवीय समीक्षा की आवश्यकता है?
• उपयोगकर्ताओं को एक उत्तर दिखाए जाने से पहले “पर्याप्त आधारित” के लिए आपका मानक क्या है?
• जब अविश्वसनीय सामग्री को संदर्भ में प्रवेश करना ही चाहिए तो आप प्रॉम्प्ट इंजेक्शन के खिलाफ़ कैसे बचाव करते हैं?
• एक सरल, एकल-कॉल डिज़ाइन के मुकाबले एक एजेंट कब अपने अतिरिक्त जोखिम के लायक है?
• मॉडल-आधारित ग्रेडिंग पर अत्यधिक निर्भर हुए बिना आप पैमाने पर व्यक्तिपरक गुणवत्ता का मूल्यांकन कैसे करते हैं?
• आप कई टीमों में प्रॉम्प्ट को अनुरक्षणीय और संगत कैसे रखते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
• Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.
• OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
• Chip Huyen, AI Engineering: Building Applications with Foundation Models.
• Anthropic, Building Effective Agents (engineering guidance).
• Louis-François Bouchard and Louie Peters, Building LLMs for Production.