प्रॉम्प्ट से प्रोडक्ट तक: LLMs को असली ऐप्स में बदलना
LLM एप्लिकेशन बनाने की एक अभ्यासकर्ता की पद्धति: इवैल्स, गार्डरेल, लेटेंसी और लागत बजट, ह्यूमन-इन-द-लूप, और यह जानना कि क्या ऑटोमेट नहीं करना है।
द्वारा Vitor Lima
एक प्रॉम्प्ट जो प्लेग्राउंड में काम करता है, वह एक डेमो है, प्रोडक्ट नहीं। इन दोनों के बीच का अंतराल वही जगह है जहाँ ज़्यादातर AI प्रोजेक्ट चुपचाप मर जाते हैं। ऐसे LLM एप्लिकेशन बनाना जो असली उपयोगकर्ताओं के बीच टिके रहें, उसका चतुर प्रॉम्प्टिंग से उतना लेना-देना नहीं जितना डेमो सुझाते हैं, और साधारण सॉफ़्टवेयर अनुशासन से कहीं ज़्यादा लेना-देना है। हमने इनमें से इतने शिप किए हैं — Youp, MadaiOps, और अब Linea — कि इस बारे में हमारी राय बन गई है कि असल में उस अंतराल को क्या पाटता है। इसमें से कुछ भी चमकदार नहीं है।
जाल यह है कि पहला संस्करण पूरा हुआ-सा लगता है। आप एक चतुर प्रॉम्प्ट पेस्ट करते हैं, मॉडल कुछ प्रभावशाली लौटाता है, और उसे एक UI में लपेटकर उसे लॉन्च कहने का प्रलोभन होता है। फिर असली उपयोगकर्ता ऐसे इनपुट लेकर आते हैं जिनकी आपने कभी कल्पना नहीं की, मॉडल पूरे आत्मविश्वास से कुछ गलत कर देता है, और आपको पता चलता है कि आपके पास यह बताने का कोई तरीका ही नहीं कि आपके फ़िक्स ने चीज़ों को बेहतर बनाया या बदतर। यह लेख उस ढाँचे (scaffolding) के बारे में है जो उस प्रभावशाली डेमो को ऐसी चीज़ में बदल देता है जिसे आप प्रोडक्शन में चला सकें और रात भर चैन से सो सकें।
प्रॉम्प्ट से नहीं, इवैल्स से शुरू करें
जल्दी बनाने योग्य सबसे उच्च-लाभकारी चीज़ एक इवैल्यूएशन सेट है। कोई बेंचमार्क नहीं, कोई लीडरबोर्ड नहीं — बल्कि असली इनपुट्स का एक फ़ोल्डर जो इस बात के साथ जोड़ा गया है कि एक अच्छा आउटपुट कैसा दिखता है। बीस उदाहरण शून्य से बेहतर हैं, और पचास सावधानी से चुने गए उदाहरण, स्क्रैप किए गए हज़ार से बेहतर हैं।
कारण सरल है। एक बार जब आपके पास इवैल्स हों, तो प्रॉम्प्ट इंजीनियरिंग "वाइब्स" पर आधारित रहना बंद कर देती है। आप एक पंक्ति बदलते हैं, सेट चलाते हैं, और संख्या को हिलते हुए देखते हैं। इनके बिना, हर बदलाव एक अंधविश्वास है। हमने टीमों को एक हफ़्ता किसी प्रॉम्प्ट को सुधारने में लगाते देखा है, केवल इसलिए कि वे उन मामलों में पीछे चले गए जिन्हें उन्होंने महीनों पहले सुलझा लिया था, क्योंकि जिन मामलों को वे नहीं देख रहे थे, उन्हें कुछ भी नहीं माप रहा था।
कुछ राय जो हम मज़बूती से रखते हैं:
- शब्दों पर नहीं, परिणामों पर ग्रेड दें। किसी भी संरचित चीज़ के लिए — एक्सट्रैक्शन, वर्गीकरण, रूटिंग — स्ट्रिंग समानता पर नहीं, बल्कि पार्स किए गए परिणाम पर assert करें। खुले-अंत वाले टेक्स्ट के लिए, एक कसी हुई रुब्रिक के साथ LLM-as-judge ठीक है, पर पहले जज को कुछ मानव लेबल्स के विरुद्ध सत्यापित करें, वरना आप बस एक मॉडल के स्वाद को माप रहे हैं।
- एक रिग्रेशन फ़ाइल रखें। हर प्रोडक्शन फ़ेलियर एक स्थायी टेस्ट केस बन जाता है। इसी तरह आपका इवैल सेट ईमानदार बना रहता है — यह ठीक उन्हीं दिशाओं में बढ़ता है जिनकी ओर हकीकत धकेलती है।
- अपने इवैल्स को अपने प्रॉम्प्ट के साथ वर्शन करें। अपने इवैल सेट के बिना एक प्रॉम्प्ट एक बिना-टेस्ट किया गया कोड बदलाव है।
अगर आप इस लेख से एक चीज़ बनाते हैं, तो यही बनाएँ। नीचे की हर चीज़ इस बात पर निर्भर करती है कि आप इस सवाल का जवाब दे पाएँ: क्या इससे यह बेहतर हुआ?
गार्डरेल माफ़ी माँगने से सस्ते होते हैं
मॉडल उन तरीकों से विफल होते हैं जिनसे साधारण सॉफ़्टवेयर नहीं होता। वे एक ऐसा API गढ़ लेंगे जो मौजूद ही नहीं है, किसी उपयोगकर्ता की झूठी धारणा से सहमत हो जाएँगे, या एक झूठे (hallucinated) फ़ील्ड के साथ वैध दिखने वाला JSON उगल देंगे। गार्डरेल वह परत है जो इसे किसी उपयोगकर्ता तक पहुँचने से पहले, या उससे भी बदतर, किसी एग्ज़ीक्यूशन स्टेप तक पहुँचने से पहले पकड़ लेती है।
तीन जगहों में सोचें।
- इनपुट गार्डरेल मॉडल के चलने से पहले अस्वीकार या सैनिटाइज़ करते हैं: प्रॉम्प्ट-इंजेक्शन स्क्रीनिंग, PII रिडैक्शन, विषय-से-हटकर फ़िल्टरिंग।
- आउटपुट गार्डरेल जो लौटता है उसे सत्यापित करते हैं: स्कीमा वैलिडेशन, सिटेशन-ग्राउंडिंग जाँच, पॉलिसी फ़िल्टर।
- एक्शन गार्डरेल मॉडल और किसी भी साइड इफ़ेक्ट वाली चीज़ के बीच बैठते हैं।
वह तीसरा ही वह जगह है जहाँ असली जोखिम रहता है। हमारे वर्कफ़्लो-ऑटोमेशन एजेंट्स Linea में, मॉडल एक्शन प्रस्तावित कर सकता है — कोई API कॉल करना, कोई रिकॉर्ड हिलाना, कोई संदेश भेजना। प्रस्ताव और एग्ज़ीक्यूशन जानबूझकर अलग स्टेप हैं। हर परिणामकारी एक्शन कुछ भी चलने से पहले एक टाइप्ड कॉन्ट्रैक्ट और एक पॉलिसी जाँच से गुज़रता है, और विध्वंसक या अपरिवर्तनीय एक्शन के लिए एक स्पष्ट पुष्टिकरण गेट की ज़रूरत होती है। किसी एजेंट का गलत चीज़ सुझाना एक UX समस्या है जिस पर आप सुधार कर सकते हैं। किसी एजेंट का गलत चीज़ करना एक घटना है। इन दोनों फ़ेलियर मोड को एक कठोर सीमा के दो अलग किनारों पर रखें।
राय वाला संस्करण: संरचित आउटपुट को एक स्कीमा के विरुद्ध सत्यापित करें और विफलता पर रीट्राई करें, बजाय इसके कि मॉडल के संगत रहने पर भरोसा करें। और किसी मॉडल के कच्चे आउटपुट को कभी वह चीज़ न बनने दें जो किसी अपरिवर्तनीय एक्शन को ट्रिगर करती है। बीच में हमेशा एक निर्धारक (deterministic) जाँच रखें।
लेटेंसी और लागत को फ़ीचर की तरह बजट करें
लेटेंसी और लागत ऐसी चीज़ें नहीं हैं जिन्हें आप अंत में मापते हैं। ये वे बाधाएँ हैं जिनके विरुद्ध आप शुरू से डिज़ाइन करते हैं, क्योंकि ये आर्किटेक्चर बदलती हैं, केवल बिल नहीं।
हर उपयोगकर्ता-सामने वाले एक्शन के लिए स्पष्ट बजट तय करें: एक p95 लेटेंसी लक्ष्य और एक प्रति-कॉल लागत सीमा। एक बार ये लिख दिए जाएँ, तो डिज़ाइन के फ़ैसले आसान हो जाते हैं। कुछ पैटर्न जिनकी ओर हम बार-बार हाथ बढ़ाते हैं:
- हर स्टेप के लिए मॉडल को सही आकार दें। ज़्यादातर पाइपलाइनों में एक या दो स्टेप ऐसे होते हैं जिन्हें सचमुच फ़्रंटियर मॉडल की ज़रूरत होती है और कई ऐसे होते हैं जिन्हें एक छोटा, तेज़ मॉडल आराम से संभाल लेता है। सरल वर्गीकरण को किसी सस्ते मॉडल पर रूट करना और महँगे को कठिन तर्क वाले स्टेप के लिए आरक्षित रखना उपलब्ध सबसे उच्च-प्रतिफल वाला ऑप्टिमाइज़ेशन है, और आमतौर पर यह लेटेंसी भी सुधार देता है।
- पहला टोकन स्ट्रीम करें। किसी भी संवादात्मक चीज़ के लिए, अनुभूत लेटेंसी पर टाइम-टू-फ़र्स्ट-टोकन का दबदबा रहता है। चार सेकंड लेने वाला एक स्ट्रीम किया गया जवाब, दो सेकंड लेने वाले ब्लॉकिंग जवाब से बेहतर महसूस होता है।
- आक्रामक रूप से कैश करें। स्थिर सिस्टम कॉन्टेक्स्ट पर प्रॉम्प्ट कैशिंग, दोहराए गए इनपुट्स पर साधारण रिज़ल्ट कैशिंग। प्रोडक्शन ट्रैफ़िक का एक सार्थक हिस्सा लगभग-डुप्लिकेट होता है।
दिमाग में रखने वाला तालमेल (tradeoff): बड़े मॉडल आपकी इंजीनियरिंग मेहनत घटाते हैं पर आपकी मार्जिनल लागत और लेटेंसी हमेशा के लिए बढ़ाते हैं। सस्ते मॉडल काम को आप पर धकेलते हैं — ज़्यादा प्रॉम्प्ट सावधानी, ज़्यादा गार्डरेल, ज़्यादा इवैल्स — पर वह काम एक स्थायी बचत के बदले एक-बार की लागत है। किसी भी वॉल्यूम वाली चीज़ के लिए, इंजीनियरिंग खर्च करें।
जानबूझकर, इंसानों को लूप में रखें
"ह्यूमन इन द लूप" इतनी बार कहा जाता है कि इसका मतलब ही खत्म हो गया है। अच्छी तरह किया जाए तो यह AI के विफल होने पर एक फ़ॉलबैक नहीं है — यह श्रम का एक डिज़ाइन किया गया विभाजन है। सवाल यह नहीं है कि किसी इंसान को शामिल करना है या नहीं बल्कि यह है कि इंसान का निर्णय उस लेटेंसी से ज़्यादा मूल्यवान कहाँ है जो वह जोड़ता है।
जो पैटर्न हमारे लिए सबसे कारगर रहा है वह है कॉन्फ़िडेंस-गेटेड एस्केलेशन। सिस्टम आत्मविश्वास वाले बहुमत को स्वचालित रूप से संभालता है और अनिश्चित अल्पसंख्यक को किसी व्यक्ति की ओर रूट करता है, मॉडल के तर्क के साथ, ताकि इंसान मिनटों में नहीं, सेकंडों में फ़ैसला ले। MadaiOps में, सामान्य मापदंडों के भीतर के ऑर्डर ऑपरेशन बहते चले जाते हैं; कुछ भी असामान्य चुपचाप एग्ज़ीक्यूट होने के बजाय संदर्भ के साथ किसी ऑपरेटर के सामने आता है। समीक्षक मशीन की देखभाल नहीं कर रहा। वे अपना ध्यान केवल वहीं खर्च कर रहे हैं जहाँ वह दुर्लभ और मूल्यवान है।
एक और नियम: इंसान के सुधारों को इंस्ट्रुमेंट करें और उन्हें वापस अपने इवैल सेट और अपने प्रॉम्प्ट में फ़ीड करें। एक ह्यूमन-इन-द-लूप सिस्टम जो अपने इंसानों से नहीं सीखता, वह बस एक ही काम के लिए दो बार भुगतान कर रहा है।
जानें कि क्या ऑटोमेट नहीं करना है
इस अनुशासन में सबसे कठिन निर्णय है संयम। हर कार्य किसी मॉडल को नहीं सौंपा जाना चाहिए, और परिपक्वता यह जानने में है कि किन्हें अकेला छोड़ देना है।
हमारा मोटा परीक्षण: वहाँ ऑटोमेट करें जहाँ गलती की लागत कम है, या गलती को पकड़ना और पलटना आसान है। ड्राफ़्टिंग, सारांश बनाना, एक्सट्रैक्ट करना, वर्गीकरण, रूटिंग — अच्छे उम्मीदवार हैं। एक गलत ड्राफ़्ट संपादित हो जाता है; एक गलत सारांश पढ़ते समय पकड़ा जाता है। वहाँ कहीं ज़्यादा सावधान रहें जहाँ त्रुटियाँ महँगी, पकड़ने में मुश्किल, या अपरिवर्तनीय हैं: कुछ भी जो पैसा हिलाता है, कोई अपरिवर्तनीय संदेश भेजता है, या कोई कानूनी या चिकित्सीय निर्णय लेता है। वहाँ, मॉडल एक सहायक भूमिका में है — विकल्प सामने रखना, समीक्षा के लिए ड्राफ़्ट बनाना — चालक की सीट पर नहीं।
जो रेखा हम पकड़ते हैं: अगर आप यह वर्णन नहीं कर सकते कि आप मॉडल के गलत होने को कैसे पकड़ेंगे, तो आप उस स्टेप को ऑटोमेट करने के लिए तैयार नहीं हैं। विफलता को पकड़ने की क्षमता ही असली पूर्वापेक्षा है, सटीकता से भी ज़्यादा। एक 95%-सटीक स्टेप जिसे आप पूरी तरह सत्यापित कर सकते हैं, उस 99%-सटीक स्टेप से शिप करने में सुरक्षित है जिसे आप नहीं कर सकते।
काम का स्वरूप
एक प्रॉम्प्ट को प्रोडक्ट में बदलना ज़्यादातर वही अनाकर्षक हिस्सा है: इवैल्स ताकि आप माप सकें, गार्डरेल ताकि विफलताएँ काबू में रहें, बजट ताकि यह तेज़ और किफ़ायती बना रहे, इंसान वहाँ रखे जाएँ जहाँ निर्णय मायने रखता है, और कुछ चीज़ों को बिना-ऑटोमेट छोड़ने का अनुशासन। मॉडल शायद सिस्टम का बीस प्रतिशत है। बाकी अस्सी प्रतिशत वह इंजीनियरिंग है जो उसकी कभी-कभार की प्रतिभा को भरोसा करने लायक सुरक्षित बनाती है।
अच्छी खबर यह है कि यह जाना-पहचाना काम है। यह उन्हीं सहज-बोधों को पुरस्कृत करता है जो किसी भी तरह के अच्छे सॉफ़्टवेयर को बनाते हैं: बदलने से पहले मापें, अपने ब्लास्ट रेडियस को काबू में रखें, अपने उपयोगकर्ताओं के समय का सम्मान करें। मॉडल नया है। यह हुनर नहीं।