LLM-फ़र्स्ट या कोड-फ़र्स्ट? उत्पादन एआई में बुद्धिमत्ता कहाँ स्थित है

मॉडल को क्या संभालना चाहिए, आपका कोड क्या संभाले, और दोनों को कैसे जोड़ना है, यह तय करने का तरीका।

कुछ साल पहले, AI एप्लिकेशन की आर्किटेक्चर इस प्रकार दिखती थी: प्रॉम्प्ट को बड़े भाषा मॉडल को भेजें → प्रतिक्रिया प्राप्त करें → उपयोगकर्ता को दिखाएँ। यह अब पूरी कहानी नहीं है। मॉडलों को इरादा समझने, जानकारी प्राप्त करने, टूल चुनने, API कॉल करने, योजनाएँ बनाने और बहु‑चरणीय वर्कफ़्लो चलाने के लिए कहा जाता है।

उस बदलाव ने इस क्षेत्र को दो भागों में बाँट दिया – LLM-फ़र्स्ट या कोड-फ़र्स्ट

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

कोड-फ़र्स्ट आर्किटेक्चर में, सॉफ़्टवेयर/कोड अनुक्रम, व्यावसायिक नियम, वैधता, अनुमतियों और निष्पादन का प्रबंधन करता है। यहाँ LLM एक विशेषज्ञ की तरह है, जिसे कोड तब बुलाता है जब भाषा समझ या उत्पादन की आवश्यकता होती है।

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

LLM-फ़र्स्ट इतना आकर्षक क्यों है

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

प्राकृतिक भाषा ऐसा सहयोग नहीं करती। कल्पना करें कि एक उपयोगकर्ता टाइप करता है: “ऐसे लेनदेन खोजें जो असामान्य लगते हैं, क्या हुआ समझाएँ, और मुझे बताएं कि मुझे पहले क्या जांचना चाहिए।”

उस अनुरोध के लिए कोई निश्चित मार्ग नहीं है। यहाँ सिस्टम को यह तय करना पड़ता है कि “असामान्य” का क्या अर्थ है, कौन सा डेटा महत्वपूर्ण है, शायद कई टूल कॉल करने हों, प्रतिक्रिया का मूल्यांकन करना हो, और एक ऐसा स्पष्टीकरण लिखना हो जिसे व्यक्ति उपयोग कर सके। इंजीनियरों की कोई टीम/कोड हर अभिव्यक्ति और हर संयोजन की अग्रिम भविष्यवाणी नहीं कर पाएगी।

यह वह जगह है जहाँ LLM एक महत्वपूर्ण भूमिका निभाता है, मानव भाषा और आपके निर्धारक सेवाओं के बीच एक लचीला तर्कशील परत के रूप में कार्य करता है। यही कारण है कि एजेंट्स को बहुत ध्यान मिल रहा है। Google Cloud की एजेंटिक एआई आर्किटेक्चर गाइडेंस एक एजेंट को ऐसे अनुप्रयोग के रूप में वर्णित करता है जहाँ एआई मॉडल तर्क इंजन के रूप में कार्य करता है, जबकि टूल्स इसे बाहरी सिस्टम और डेटा तक पहुँचने देते हैं।

Anthropic की इफ़ेक्टिव एआई एजेंट्स बनाने की गाइडेंस एक अंतर बताता है जिस पर मैं बार‑बार लौटता हूँ। एक वर्कफ़्लो में, मॉडल और टूल आपके कोड द्वारा परिभाषित मार्गों का अनुसरण करते हैं। एक एजेंट में, LLM अपनी प्रक्रिया को स्वयं निर्देशित करता है और तय करता है कि टूल्स का कैसे उपयोग किया जाए। वही गाइडेंस समस्या को हल करने वाली सबसे सरल वास्तुकला से शुरू करने की सलाह देती है, बजाय इसके कि रिफ्लेक्स द्वारा एजेंटिक जटिलता जोड़ी जाए। मैं इस सलाह को दो बार रेखांकित करूँगा।

“मॉडल को निर्णय लेने दो” की सीमाएँ

एक मॉडल यह तर्क कर सकता है कि क्या होना चाहिए। तर्क करना नियम लागू करने के समान नहीं है।

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

शायद नहीं। ये कार्य निर्धारित, परीक्षण योग्य, ऑडिटेबल और लागू करने योग्य हैं, और यही पारंपरिक सॉफ़्टवेयर की ताकत है। जोखिम बढ़ता है जब मॉडल टूल्स तक पहुँच प्राप्त करते हैं। OWASP की जनरेटिव AI सुरक्षा मार्गदर्शिका संकेत करती है अत्यधिक एजेंसी को एक महत्वपूर्ण जोखिम के रूप में: LLM‑आधारित सिस्टम को उसके कार्य की आवश्यकता से अधिक कार्यक्षमता, अनुमतियाँ या स्वायत्तता देना। एक अजीब या हेरफेर किया गया मॉडल आउटपुट केवल तब समस्या है जब वह केवल टेक्स्ट उत्पन्न करता है। यह बहुत बड़ी समस्या बन जाती है जब मॉडल वास्तविक दुनिया में कार्य कर सकता है।

इन सबका मतलब यह नहीं है कि मॉडलों को कभी कार्रवाई नहीं करनी चाहिए। इसका अर्थ है कि मॉडल की स्वायत्तता को निर्धारक अधिकार द्वारा सीमित किया जाना चाहिए।

कोड-फ़र्स्ट अभी भी महत्वपूर्ण है

AI इतनी तेज़ी से विकसित हो रहा है, इसलिए यह महसूस करना आसान है कि पारंपरिक इंजीनियरिंग अब पुरानी हो गई है। मैं इसके विपरीत तर्क दूँगा। AI deterministic सिस्टम को अधिक महत्वपूर्ण बनाता है, कम नहीं।

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

यह व्यापक शासन सोच के साथ मेल खाता है। NIST AI Risk Management Framework संगठनों को डिजाइन, विकास, तैनाती और उपयोग के सभी चरणों में AI जोखिम प्रबंधन करने के लिए कहता है। इसका साथी Generative AI Profile जोड़ता है कि जनरेटिव सिस्टम को जोखिम के आधार पर अतिरिक्त निगरानी, दस्तावेज़ीकरण, समीक्षा और नियंत्रण की आवश्यकता हो सकती है।

इसलिए मैं प्रत्येक डिजाइन निर्णय को दो प्रश्नों में विभाजित करना उपयोगी पाता हूँ:

क्या होना चाहिए?

और

क्या इसे होने की अनुमति है?

एक LLM अक्सर पहले प्रश्न में मदद कर सकता है। निर्धारक प्रणालियों को आमतौर पर दूसरे प्रश्न का उत्तर देना चाहिए।

हाइब्रिड पैटर्न: संभाव्यात्मक रूप से तर्क करें, निर्धारक रूप से निष्पादित करें

अधिकांश एंटरप्राइज़ अनुप्रयोगों के लिए व्यावहारिक उत्तर एक हाइब्रिड है। LLM व्याख्या और तर्क का स्तर प्रदान करता है। निर्धारक सेवाएँ निष्पादन और प्रवर्तन का स्तर प्रदान करती हैं।

एक उदाहरण देखें। मान लीजिए एक AI सहायक डेवलपर्स को अस्थायी API‑परीक्षण वातावरण बनाने में मदद करता है, और एक डेवलपर टाइप करता है: “ग्राहक ऑनबोर्डिंग वर्कफ़्लो के लिए एक सैंडबॉक्स दें।”

LLM इसे समझ सकता है, यह अनुमान लगा सकता है कि कौन‑सा वर्कफ़्लो अभिप्रेत है, दस्तावेज़ पढ़ सकता है, और संभावित प्रासंगिक API सुझा सकता है। लेकिन वास्तविक वातावरण बनाना मुक्त‑रूप उत्पन्न पाठ पर निर्भर नहीं होना चाहिए। कोड यह पुष्टि कर सकता है कि अनुरोधित API मौजूद हैं, उनके अनुबंध सत्यापित कर सकता है, प्राधिकरण जांच सकता है, संसाधन सीमाएँ लागू कर सकता है, एक स्वीकृत कॉन्फ़िगरेशन उत्पन्न कर सकता है, और तैनाती चला सकता है।

कच्चा विभाजन इस प्रकार दिखता है:

• LLM: समझना, तर्क करना, वर्गीकृत करना, प्रस्ताव देना, सारांश बनाना।
• कोड: सत्यापित करना, प्राधिकृत करना, गणना करना, स्थायी बनाना, प्रवर्तन करना, निष्पादित करना।

प्रत्येक पक्ष वह काम करता है जिसमें वह सबसे अच्छा है, और किसी को भी दूसरे की ताकत का नकल करने के लिए नहीं कहा जाता।

एजेंट्स के अधिक शक्तिशाली होने पर सीमाएँ अधिक महत्वपूर्ण हो जाती हैं

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

समाधान जरूरी नहीं कि स्वायत्तता को पूरी तरह हटाना हो। यह स्वायत्तता को धीरे‑धीरे जोड़ना है जबकि स्पष्ट नियंत्रण बिंदुओं को बनाए रखा जाए। Google की मल्टी‑एजेंट सिस्टम्स पर मार्गदर्शिका व्यवसाय‑महत्वपूर्ण परिदृश्यों के लिए गतिशील AI व्यवहार को निर्धारित सुरक्षा नियंत्रणों, अवलोकनशीलता, स्पष्ट रूप से परिभाषित स्वायत्तता और मानव निगरानी के साथ जोड़ने की सलाह देती है।

मानव स्वीकृति को कार्य‑प्रवाह में ही निर्मित किया जा सकता है, न कि केवल अनौपचारिक सुरक्षा जाल के रूप में। Microsoft’s agent framework documentation उदाहरण के लिए, ऐसे टूल कॉल का समर्थन करता है जो तब तक रुकते हैं जब तक कोई व्यक्ति स्पष्ट रूप से अनुरोधित ऑपरेशन को स्वीकृत नहीं करता।

सिद्धांत सरल है: किसी कार्रवाई के परिणाम जितने गंभीर हों, उसके आसपास निर्धारक नियंत्रण उतने ही मजबूत होने चाहिए।

LLM को कार्य सौंपने से पहले पूछने के पाँच प्रश्न

जब मैं तय करता हूँ कि कोई घटक LLM‑first होना चाहिए या code‑first, मैं इन प्रश्नों से गुजरता हूँ:

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

आखिरी प्रश्न विशेष ध्यान का हकदार है। एजेंट इसलिए शक्तिशाली होते हैं क्योंकि वे उन स्थितियों को संभाल सकते हैं जहाँ आप हर चरण की भविष्यवाणी नहीं कर सकते। लेकिन यदि आप कर चरणों की भविष्यवाणी कर सकते हैं, तो उन्हें एक खुली‑समाप्ति तर्क समस्या में बदलना अक्सर परिवर्तनशीलता जोड़ता है बिना बुद्धिमत्ता बढ़ाए।

विश्वसनीयता एक वास्तुशिल्प गुण है, प्रॉम्प्ट नहीं

कई टीमें शुरुआत में विश्वसनीयता को लगभग पूरी तरह प्रॉम्प्ट इंजीनियरिंग के माध्यम से सुधारने की कोशिश करती हैं। प्रॉम्प्ट महत्वपूर्ण हैं, लेकिन वे पूरी जिम्मेदारी नहीं ले सकते।

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

यह आपके पूछे जाने वाले प्रश्न को बदल देता है। “मैं ऐसा प्रॉम्प्ट कैसे लिखूँ जो हमेशा मॉडल को नियम का पालन करने के लिए मजबूर करे?” के बजाय, पूछें “मैं प्रणाली को इस तरह कैसे डिज़ाइन करूँ कि नियम मॉडल की गलती होने पर भी तोड़ा न जा सके?”

यह एक सॉफ़्टवेयर आर्किटेक्चर समस्या है, न कि प्रॉम्प्टिंग समस्या। एक प्रॉम्प्ट एजेंट को अनधिकृत कार्रवाई न करने के लिए बता सकता है। एक प्राधिकरण सेवा वास्तव में इसे रोक सकती है। ये दो नियंत्रण समान नहीं हैं।

बहस से परे: इंटेंट-फ़र्स्ट सिस्टम

इन सबके बारे में सोचते हुए, मैं मानता हूँ कि LLM‑फ़र्स्ट बनाम कोड‑फ़र्स्ट बहस एक तीसरे विचार की ओर इशारा करती है: इंटेंट‑फ़र्स्ट आर्किटेक्चर।

इंटेंट‑फ़र्स्ट सिस्टम में, एप्लिकेशन उपयोगकर्ता के लक्ष्य को समझकर शुरू होता है। यही वह जगह है जहाँ LLM सबसे मूल्यवान होता है, क्योंकि लोग अक्सर अपने इच्छित लक्ष्य को सटीक रूप से नहीं बताते। वहाँ से, सिस्टम धीरे‑धीरे उस अस्पष्टता को संरचित, निर्धारक संचालन में बदलता है।

“ग्राहक की भुगतान समस्या को हल करने में मदद करें” जैसी अनुरोध को एक पाइपलाइन में बदला जा सकता है: इंटेंट समझें, लेन‑देन प्राप्त करें, विफलता का कारण पहचानें, समाधान की सिफ़ारिश करें, अनुमोदन का अनुरोध करें, अनुमोदित ऑपरेशन को निष्पादित करें।

इन चरणों में से कुछ भाषा‑मॉडल तर्क से लाभान्वित होते हैं। अन्य को स्थिर सेवाओं के रूप में होना चाहिए। आर्किटेक्चर यह नहीं तय करता कि AI या कोड “जीतेगा”। यह इस बात से निर्धारित होता है कि अनिश्चितता कहाँ स्वीकार्य है।

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

जैसे मॉडल सुधारते हैं, उन्हें स्टैक के बड़े‑बड़े हिस्सों पर नियंत्रण देना आकर्षक लगेगा। कभी‑कभी यह सही निर्णय होगा। अन्य सिस्टमों में, सबसे परिष्कृत डिजाइन वह होगी जो जानबूझकर मॉडल को कम अधिकार।

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

एंटरप्राइज़ AI का भविष्य संभवतः पूरी तरह LLM‑फ़र्स्ट या पूरी तरह कोड‑फ़र्स्ट नहीं होगा। यह वह LLM है जहाँ अनिश्चितता के लिए बुद्धिमत्ता की आवश्यकता होती है, और कोड जहाँ निश्चितता के लिए नियंत्रण की आवश्यकता होती है।

यह अंतर संभवतः उस मॉडल से अधिक महत्वपूर्ण हो सकता है जिसे आप चुनते हैं।