30 अग॰ 2025·8 मिनट
ऐप बनाते समय AI कैसे "सोचता" है — एक सरल मानसिक मॉडल
AI किस तरह से कोड और फैसले बनाता है—टोकन, संदर्भ विंडो, टूल्स, टेस्ट—सीधे उपयोगी मानसिक मॉडल, सीमाएँ और प्रैक्टिकल प्रॉम्प्टिंग सुझाव।
“AI सोचता है” का मतलब ऐप बिल्डरों के लिए क्या है
जब लोग कहते हैं “AI सोचता है,” तो वे आमतौर पर ऐसा मानते हैं कि यह आपकी बात समझता है, उस पर तर्क करता है, और फिर कोई उत्तर तय करता है।
आधुनिक टेक्स्ट-आधारित AI (LLMs) के लिए एक उपयोगी मानसिक मॉडल सरल है: मॉडल यह भविष्यवाणी करता है कि अगला टेक्स्ट क्या होना चाहिए।
यह कम रोमांचक लग सकता है—तब तक जब तक आप नहीं देखते कि “अगला टेक्स्ट” कितनी दूर तक जा सकता है। अगर मॉडल ने प्रशिक्षण से पर्याप्त पैटर्न सीखे होते हैं, तो अगले शब्द (और उसके बाद के शब्द) की भविष्यवाणी से व्याख्याएँ, योजनाएँ, कोड, सार, और यहां तक कि संरचित डेटा भी बन सकता है जिसका आपकी ऐप उपयोग कर सकती है।
लक्ष्य: बिल्डर का मॉडल, गणित नहीं
आपको अच्छे AI फीचर बनाने के लिए अंतर्निहित गणित सीखने की ज़रूरत नहीं है। ज़रूरत है एक व्यावहारिक तरीका जो व्यवहार की उम्मीद करने में मदद करे:
- क्यों एक ही प्रॉम्प्ट अलग उत्तर दे सकता है
- क्यों उत्तर आत्मविश्वासी सुनते हुए भी गलत हो सकते हैं
- क्यों छोटे प्रॉम्प्ट बदलाव नतीजों को नाटकीय रूप से बदल सकते हैं
- कब आप "कठिन पूछने" के बजाय बाहरी डेटा या टूल जोड़ें
यह लेख वैसा ही मॉडल देता है: न तो हाइप, न कोई गहरा टेक्निकल पेपर—सिर्फ़ वे अवधारणाएँ जो भरोसेमंद प्रोडक्ट एक्सपीरियंस डिजाइन करने में मदद करें।
ऐप में “सोचना” कैसा दिखता है
ऐप बिल्डर के नजरिए से, मॉडल का “सोचना” वह टेक्स्ट है जो यह आपके दिए गए इनपुट (प्रॉम्प्ट, यूज़र मैसेज़, सिस्टम नियम, और कोई भी निकाला गया कंटेंट) के जवाब में जनरेट करता है। मॉडल डिफ़ॉल्ट रूप से तथ्य की जाँच नहीं कर रहा होता, वेब ब्राउज़ नहीं कर रहा होता, और आपके डेटाबेस में क्या है यह “नहीं जानता” जब तक आप वह जानकारी पास न करें।
उम्मीदें उसी के अनुसार सेट करें: LLMs ड्राफ्टिंग, ट्रांसफ़ॉर्मिंग, और टेक्स्ट क्लासिफाई करने तथा कोड-जैसे आउटपुट जनरेट करने में बेहद उपयोगी हैं। वे जादुई सत्य इंजन नहीं हैं।
जिन टुकड़ों का हम उपयोग करेंगे
हम मानसिक मॉडल को कुछ हिस्सों में तोड़ेंगे:
- टोकन (वह टेक्स्ट के टुकड़े जिन्हें वह भविष्यवाणी करता है)
- संदर्भ विंडो (वह जो यह एक बार में “दिमाग में रख” सकता है)
- प्रायिकता (क्यों आउटपुट बदलते हैं)
- टूल्स और रिट्रीवल (मॉडल को असल कार्रवाई और तथ्यों से कैसे जोड़ें)
- फीडबैक और मूल्यांकन (आप आउटपुट को कैसे भरोसेमंद बनाते हैं)
इन विचारों से आप प्रॉम्प्ट, UI, और सेफ़गार्ड्स डिजाइन कर सकते हैं जो AI फीचर्स को स्थिर और भरोसेमंद बनाते हैं।
कोर लूप: नेक्स्ट‑टोकन प्रेडिक्शन
जब लोग कहते हैं कि कोई AI “सोचता” है, तो यह कल्पना करना आसान है कि यह इंसान की तरह तर्क कर रहा है। एक उपयोगी मानसिक मॉडल सरल है: यह बेहद तेज़ ऑटो‑कम्प्लेट—एक छोटा टुकड़ा एक बार में—कर रहा है।
टोकन क्या है?
एक टोकन वह टेक्स्ट का टुकड़ा है जिसके साथ मॉडल काम करता है। कभी यह पूरा शब्द होता है ("apple"), कभी शब्द का हिस्सा ("app" + "le"), कभी विराम चिन्ह, और कभी व्हाइटस्पेस। टोकनाइज़र पर निर्भर करता है कि कैसे टुकड़े बनते हैं, लेकिन मुख्य बात यह है: मॉडल वाक्यों के रूप में नहीं बल्कि टोकनों के रूप में टेक्स्ट प्रोसेस करता है।
अगले टोकन की भविष्यवाणी, फिर दोहराएँ
मॉडल का मूल लूप है:
- दिए गए टोकन पढ़ें (आपका प्रॉम्प्ट और किसी पिछले कॉन्वर्सेशन)।
- सबसे संभावित अगले टोकन की भविष्यवाणी करें।
- उस टोकन को टेक्स्ट में जोड़ें।
- नए लंबे टेक्स्ट को इनपुट मानकर फिर से करें।
बस इतना ही। हर पैराग्राफ, बुलेट लिस्ट, और “रिजनिंग” चेन आप देखते हैं वो इस अगले‑टोकन प्रेडिक्शन को कई बार दोहराकर बनता है।
“सोचना” = गाइडेड ऑटो‑कम्प्लेट
क्योंकि मॉडल ने प्रशिक्षण में बड़े पैमाने पर टेक्स्ट देखे हैं, उसने पैटर्न सीखे हैं—कैसे व्याख्याएँ बहती हैं, एक शिष्ट ईमेल कैसा लगता है, या बग फिक्स आमतौर पर कैसे लिखा जाता है। जब आप कोई प्रश्न पूछते हैं, तो यह उस तरह का जवाब जनरेट करता है जो सीखे गए पैटर्न और दिए गए संदर्भ से मेल खाता है।
इसीलिए यह आत्मविश्वासी और सुसंगत सुन सकता है भले ही यह गलत हो: यह अगले टेक्स्ट के लिए अनुकूलित है—सत्य की जाँच के लिए नहीं।
कोड भी टोकन है
कोड मॉडल के लिए विशेष नहीं है। JavaScript, SQL, JSON, और एरर मैसेज सब टोकनों का सिलसिला हैं। मॉडल उपयोगी कोड इसलिए दे सकता है क्योंकि उसने सामान्य कोडिंग पैटर्न सीखे हैं, न कि इसलिए कि वह आपकी ऐप को एक इंजीनियर की तरह सचमुच “समझता” है।
उत्तर कहाँ से आते हैं: प्रशिक्षण में सीखे पैटर्न
जब लोग पूछते हैं "मॉडल ने वह उत्तर कहाँ से लिया?", उपयोगी मानसिक मॉडल यह है: उसने विशाल उदाहरणों से पैटर्न सीखे और अब उन पैटर्नों को मिलाकर अगले टेक्स्ट की भविष्यवाणी करता है।
प्रशिक्षण पैटर्न सीखना है, याद करना नहीं
प्रशिक्षण के दौरान मॉडल को कई टेक्स्ट स्निपेट दिखाए जाते हैं (किताबें, लेख, कोड, डॉक्यूमेंटेशन, प्रश्नोत्तर, और भी बहुत कुछ)। यह बार‑बार एक सरल कार्य का अभ्यास करता है: कुछ टेक्स्ट दिया गया है, अगला टोकन क्या होगा इसे भविष्यवाणी करो। जब यह गलत होता है, प्रशिक्षण प्रक्रिया मॉडल के अंदर के पैरामीटर को थोड़ा बदल देती है ताकि अगली बार बेहतर भविष्यवाणी हो।
समय के साथ, वे बदलाव इकट्ठा हो जाते हैं और मॉडल उन रिश्तों को एन्कोड करने लगता है जैसे:
- किसी अवधारणा को आमतौर पर कैसे समझाया जाता है ("एक संदर्भ विंडो है…")
- कौन‑से शब्द अक्सर साथ आते हैं (API, authentication, token)
- उत्तरों की सामान्य संरचनाएँ (परिभाषाएँ, कदम, उदाहरण)
- कोड के पैटर्न (SQL क्वेरी आमतौर पर कैसे बनती है)
क्यों यह सामान्यीकरण कर सकता है
क्योंकि यह सांख्यिकीय नियमितताओं को सीख रहा है—न कि एक तय स्क्रिप्ट—इसलिए यह पैटर्न्स को नए तरीकों से जोड़ सकता है। अगर उसने “किसी अवधारणा की व्याख्या” के कई उदाहरण देखे हैं और “आपके ऐप परिदृश्य” के कई उदाहरण भी, तो यह अक्सर उन्हें जोड़कर एक मुफ़्त‑निर्मित उत्तर दे सकता है।
इसीलिए LLM एक निच ниш प्रोडक्ट के लिए प्रासंगिक ऑनबोर्डिंग ईमेल लिख सकता है, या सामान्य API इंटीग्रेशन स्पष्टीकरण को किसी विशेष स्टैक के अनुसार अनुकूलित कर सकता है। यह किसी एक संग्रहीत पैराग्राफ को पुनः प्राप्त नहीं कर रहा; यह नया अनुक्रम बना रहा है जो सीखे पैटर्न से मेल खाता है।
यह एक बिल्ट‑इन सटीक उत्तरकोश नहीं है
यह मान लेना कि मॉडल किसी विशिष्ट तथ्य (जैसे प्राइसिंग टियर या आंतरिक नीति) को विश्वसनीय रूप से "लुक अप" कर सकता है, गलत होगा। प्रशिक्षण इंडेक्सिंग की तरह काम नहीं करता—यह कंप्रेशन के जैसा है: बहुत से उदाहरण वज़न में समाहित होते हैं जो भविष्य की भविष्यवाणियों को प्रभावित करते हैं।
इसका मतलब है कि मॉडल अक्सर ऐसे विवरणों के बारे में आत्मविश्वास से बोल सकता है जो वह समान संदर्भों में आम तौर पर दिखाई देने वाले पैटर्न के आधार पर अनुमान कर रहा है।
पैटर्न उपयोगी हैं—पर गारंटीड नहीं
पैटर्न सीखना प्रवाहपूर्ण, प्रासंगिक टेक्स्ट बनाने में शक्तिशाली है, पर प्रवाह और सच्चाई एक समान नहीं हैं। मॉडल कर सकता है:
- समान‑ध्वनि की अवधारणाएँ गड़बड़ा दे
- कमी हुई विशेषताओं को "सबसे संभावित" अनुमान से भर दे
- आउटडेटेड या संदर्भ‑अनुचित विवरण दे
ऐप बिल्डरों के लिए मुख्य संदेश: LLM के उत्तर सामान्यतः सीखे पैटर्नों से आते हैं, न कि सत्यापित तथ्यों से। अगर सटीकता मायने रखती है, तो आप आउटपुट को अपने डेटा और चेक्स से ग्राउंड करना चाहेंगे (बाद के सेक्शन्स में कवर किया गया)।
प्रायिकता, यादृच्छिकता, और क्यों उत्तर बदलते हैं
जब एक LLM उत्तर लिखता है, यह एक "सही वाक्य" किसी डेटाबेस से नहीं निकाल रहा। हर चरण पर यह संभावित अगले टोकन का एक सेट भविष्यवाणी करता है, जिनमें से प्रत्येक की एक संभाव्यता होती है।
अगर मॉडल हमेशा केवल सबसे संभावित अगले टोकन चुने, तो उत्तर बहुत संगत होते—पर अक्सर नीरस और कठोर हो सकते थे। अधिकतर सिस्टम इसके बजाय संभावनाओं से सैंपल करते हैं, जो नियंत्रित यादृच्छिकता लाता है।
“रचनात्मकता बनाम स्थिरता” के नॉब
दो सामान्य सेटिंग्स आउटपुट की विविधता तय करती हैं:
- Temperature: अधिक temperature संभावनाओं को फैलाता है (अधिक विविधता); कम temperature विकल्पों को शीर्ष के पास केंद्रित करता है (अधिक स्थिरता)।
- Top‑p (nucleus sampling): मॉडल केवल उन टोकनों के सबसे छोटे सेट पर विचार करता है जिनकी संभावनाएँ मिलकर p बनाती हैं (उदा. 0.9)। कम top‑p सेट को पहले के, सुरक्षित विकल्पों तक सीमित कर देता है।
यदि आप ऐप बना रहे हैं, तो ये नॉब्स "रचनात्मक होने" से ज़्यादा निम्न के बीच चुनाव हैं:
- स्थिर, दोहराने योग्य वाक्य (ग्राहक सहायता, नीतियाँ, सारांश के लिए बढ़िया)
- विस्तृत खोज (ब्रेनस्टॉर्मिंग, नामकरण, वैकल्पिक समाधान के लिए उपयोगी)
आत्मविश्वासी शिल्प भी गलत हो सकती है
क्योंकि मॉडल "उचित टेक्स्ट" के लिए अनुकूलित है, यह ऐसे वक्तव्य बना सकता है जो निश्चित सुनते हैं—यह सत्यापित होने का सबूत नहीं है। इसलिए ऐप्स में अक्सर ग्राउंडिंग (जैसे रिट्रीवल) या सत्यापन स्टेप्स चाहिए होते हैं।
एक सरल उदाहरण: एक ही फ़ंक्शन लिखने के कई सही तरीके
LLM से पूछें: “जावास्क्रिप्ट फ़ंक्शन लिखें जो एक एरे से डुप्लिकेट हटाए।” आपको इनमें से कोई भी मिल सकता है, सभी मान्य हैं:
// Option A: concise
const unique = (arr) =\u003e [...new Set(arr)];
// Option B: explicit
function unique(arr) {\n return arr.filter((x, i) =\u003e arr.indexOf(x) === i);\n}
विभिन्न सैंपलिंग विकल्प विभिन्न शैलियाँ (संक्षिप्त बनाम स्पष्ट), विभिन्न ट्रेडऑफ़ (स्पीड, पठनीयता), और यहां तक कि विभिन्न किनारे‑केसे व्यवहार उत्पन्न करते हैं—बिना मॉडल "अपना मन बदलने" के। यह बस कई उच्च‑संभाव्यता जारीखियों में से चयन कर रहा होता है।
संदर्भ विंडो: AI की वर्किंग मेमोरी
RAG फ्लो जल्दी प्रोटोटाइप करें
मिनटों में रिट्रीवल और जेनरेशन टेस्ट करें—ऐसा ऐप जिसे आप तैनात और सुधार सकते हैं।
जब लोग कहते हैं कि एक AI मॉडल आपकी बातचीत "याद" रखता है, वास्तविकता में उसके पास संदर्भ होता है: वह टेक्स्ट जिसे वह अभी देख सकता है—आपका नवीनतम संदेश, कोई सिस्टम निर्देश, और उस चैट का वह हिस्सा जो अभी विंडो में फिट होता है।
संदर्भ विंडो क्या है
संदर्भ विंडो यह तय सीमा है कि मॉडल एक बार में कितनी टेक्स्ट देख सकता है। जैसे ही बातचीत लंबी होती है, पुराने हिस्से विंडो से बाहर चले जाते हैं और मॉडल की दृष्टि से गायब हो जाते हैं।
इसीलिए आप कभी‑कभी ऐसे व्यवहार देखते हैं:
- यह किसी प्रारंभिक आवश्यकता को भूल जाता है ("मित्रवत टोन इस्तेमाल करो", "सिर्फ JSON लौटाओ")।
- यह पहले के फैसलों का विरोधाभास करता है (भिन्न वेरिएबल नाम, बदली हुई धारणाएँ)।
- छोटी गलतफहमियाँ समय के साथ चैट को भटका देती हैं।
लंबे chats क्यों बहक जाते हैं बिना सारांश के
यदि आप थ्रेड में लगातार संदेश जोड़ते रहते हैं, तो आप सीमित स्थान के लिए प्रतिस्पर्धा कर रहे हैं। महत्वपूर्ण प्रतिबंध हाल के बैक‑एंड‑फोर्थ द्वारा बाहर धकेल दिए जाते हैं। बिना सारांश के, मॉडल को जो कुछ भी दिखाई देता है उससे ही inference करना पड़ता है—इसलिए यह आत्मविश्वासी सुन सकता है पर चुपचाप महत्वपूर्ण विवरण खो सकता है।
व्यावहारिक समाधान है समय-समय पर सारांश बनाना: लक्ष्य, फैसलों और प्रतिबंधों को संक्षेप में दोहराना, और उसके बाद जारी रखना। ऐप्स में यह अक्सर एक ऑटोमैटिक “कॉन्वर्सेशन सारांश” के रूप में लागू होता है जो प्रॉम्प्ट में इंजेक्ट किया जाता है।
प्रॉम्प्ट टिप: प्रतिबंधों को अंतिम भाग के करीब रखें
मॉडल उन निर्देशों का पालन करने की प्रवृत्ति रखते हैं जो उस आउटपुट के पास होते हैं जो वे बनाते जा रहे हैं। इसलिए यदि आपके पास अनिवार्य नियम हैं (फॉर्मेट, टोन, एज‑केस), तो उन्हें प्रॉम्प्ट के अंत के पास रखें—सीधे "अब उत्तर बनाइए" से पहले।
यदि आप ऐप बना रहे हैं, तो इसे इंटरफ़ेस डिज़ाइन की तरह मानें: तय करें क्या चीजें संदर्भ में हमेशा रहनी चाहिए (आवश्यकताएं, उपयोगकर्ता प्राथमिकताएँ, स्कीमा) और सुनिश्चित करें कि वे हमेशा शामिल रहें—या चैट इतिहास को ट्रिम करके या एक संकुचित सारांश जोड़कर। संरचित प्रॉम्प्टिंग पर अधिक के लिए देखें /blog/prompting-as-interface-design।
AI गलत क्यों हो सकता है: प्रवाहपूर्ण टेक्स्ट बनाम वास्तविकता
LLMs टेक्स्ट बनाने में बेहद कुशल हैं जो किसी कुशल डेवलपर जैसा जवाब देने जैसा लगता है। पर "सही लगना" और "सही होना" समान नहीं हैं। मॉडल अगले‑टोकन की भविष्यवाणी कर रहा है, न कि आपके कोडबेस, आपकी निर्भरताओं, या वास्तविक दुनिया के खिलाफ आउटपुट की जाँच कर रहा है।
यह डिफ़ॉल्ट रूप से कुछ भी निष्पादित नहीं करता
यदि मॉडल कोई फिक्स, रिफैक्टर या नया फ़ंक्शन सुझाता है, तब भी वह सिर्फ़ टेक्स्ट है। यह आपकी ऐप को रन नहीं करता, पॅकेजेस इम्पोर्ट नहीं करता, आपका API कॉल नहीं करता, या प्रोजेक्ट कंपाइल नहीं करता—जब तक आप इसे ऐसे टूल से स्पष्ट रूप से कनेक्ट न करें जो ये सब कर सके (उदा., टेस्ट रनर, लिंटर, बिल्ड स्टेप)।
यह प्रमुख अंतर है:
- प्रवाहपूर्ण टेक्स्ट: "यह एक वैध समाधान लगता है।"
- निष्पादित और सत्यापित: "कोड कंपाइल हुआ, टेस्ट पास हुए, और व्यवहार उम्मीद के अनुसार है।"
ऐप‑बिल्डिंग में सामान्य विफलता मोड
AI गलतियाँ अक्सर अनुमानित तरीकों से होती हैं:
- बनावटी APIs या पैरामीटर (हैलुसिनेटेड लाइब्रेरी मेथड, गलत फ़ंक्शन सिग्नेचर)
- गलत एज‑केस (खाली स्टेट्स, टाइमज़ोन, null हैंडलिंग, पेजिनेशन सीमाएँ)
- मिसिंग इम्पोर्ट्स या सेटअप (भुला हुआ निर्भरता, गलत फ़ाइल पाथ, गायब env vars)
- सूक्ष्म लॉजिक त्रुटियाँ (ऑफ‑बाय‑वन, गलत बूलियन शर्तें, असंगत नामकरण)
- पुरानी धारणाएँ (फ्रेमवर्क बिहेवियर बदल गया, डिप्रीकेटेड कॉन्फ़िग)
ये त्रुटियाँ नोटिस करना कठिन हो सकता है क्योंकि आस‑पास की व्याख्या आमतौर पर सुसंगत होती है।
नियम: सत्यापन के बाद भरोसा करें
AI आउटपुट को ऐसे टीम‑सदस्य के ड्राफ्ट की तरह मानें जिसने लोकल प्रोजेक्ट नहीं चलाया। आत्मविश्वास तब तेज़ी से बढ़े जब आप:
- यूनिट/इंटीग्रेशन टेस्ट चलाएँ,
- लिंट/फॉर्मैट/बिल्ड करें,
- और परिणाम को वास्तविक इनपुट्स के खिलाफ वैधेट करें।
अगर टेस्ट पास नहीं होते, तो मॉडल का उत्तर केवल एक शुरुआत मानें—अंतिम फिक्स नहीं।
टूल्स: शब्दों को कार्रवाई में बदलना (और अनुमान घटाना)
एक भाषा मॉडल यह सुझाने में बेहतर है कि "क्या काम कर सकता है"—पर अकेले वह अभी भी सिर्फ टेक्स्ट है। टूल्स वे चीज़ें हैं जो AI‑बैक्ड ऐप को उन प्रस्तावों को सत्यापित और निष्पादित करने देती हैं: कोड चलाना, डेटाबेस क्वेरी करना, डॉक्यूमेंटेशन लाना, या बाहरी API कॉल।
व्यावहारिक रूप में “टूल्स” क्या होते हैं
ऐप‑बिल्डिंग वर्कफ़्लोज़ में, टूल्स सामान्यतः दिखते हैं जैसे:
- कोड चलाना (उदा., एक Python स्निपेट निष्पादित करना, प्रोजेक्ट कंपाइल करना, माईग्रेशन चलाना)
- डॉक्स सर्च करना (आपका आंतरिक नॉलेज बेस, प्रोडक्ट मैनुअल, API रेफरेंस)
- API कॉल करना (पेमेंट्स, ईमेल, CRM, फीचर फ्लैग्स, एनालिटिक्स)
- फाइल पढ़ना/लिखना (कॉनफ़िग संपादित करना, टेस्ट फ़ाइल जेनरेट करना)
महत्वपूर्ण बदलाव यह है कि मॉडल अब न तो नाटक कर रहा कि उसे परिणाम पता है—यह जाँच सकता है।
लूप: प्रस्ताव → जाँच → समायोजित
एक उपयोगी मानसिक मॉडल है:
- मॉडल प्रस्ताव करता है ("निष्क्रिय उपयोगकर्ता खोजने के लिए यह SQL चलाएँ…")
- टूल निष्पादित करता है (क्वेरी रन होती है, टेस्ट सूट चलता है, डॉक्स लौटते हैं)
- मॉडल वास्तविक आउटपुट के आधार पर समायोजित करता है (एरर मैसेज, क्वेरी परिणाम, फेलिंग टेस्ट)
यही तरीका "अनुमान" घटाता है। अगर लिंटर अनयूज़्ड इम्पोर्ट रिपोर्ट करे, मॉडल कोड अपडेट करता है। अगर यूनिट टेस्ट फेल हों, तो यह उन फेलर‑केस पर काम करता है या समझाता है कि क्यों पास नहीं हो रहा।
असली ऐप्स से जुड़े उदाहरण
- डेटाबेस क्वेरीज: मॉडल SQL ड्राफ्ट करता है, DB टूल रो काउंट या एरर लौटाता है, और मॉडल सुरक्षित रूप से क्वेरी संशोधित करता है।
- लिंटिंग/फॉर्मैटिंग: मॉडल कोड एडिट करता है, फिर
eslint/ruff/prettierचलाकर स्टाइल और मुद्दे पकड़े जाते हैं। - यूनिट टेस्ट: मॉडल फ़ंक्शन और टेस्ट लिखता है, टेस्ट सूट चलाता है, फिर विफलताओं के अनुसार एज़‑केस ठीक करता है।
परमिशन: टूल्स को प्रोडक्शन‑एक्सेस की तरह ट्रीट करें
टूल्स शक्तिशाली—और खतरनाक—हो सकते हैं। least privilege का पालन करें:
- AI को डिफ़ॉल्ट रूप से रीड‑ओनली एक्सेस दें (विशेषकर डेटाबेस के लिए)
- API कीज़ को न्यूनतम परमिशन और आवश्यक वातावरण तक सीमित करें
- विनाशकारी कार्रवाइयों (डिलीट, रिफंड, ईमेल भेजना) के लिए पुष्टि और लोगिंग आवश्यक करें
टूल्स मॉडल को "ज़्यादा स्मार्ट" नहीं बनाते, पर वे आपकी ऐप के AI को अधिक ग्राउंडेड बनाते हैं—क्योंकि अब यह सिर्फ़ बताने की बजाय जाँच भी कर सकता है।
रिट्रीवल (RAG): मॉडल को सही तथ्य देना
बिल्ड शेयर करने पर क्रेडिट कमाएँ
कॉन्टेंट बनाएं या दूसरों को रेफर करें और बिल्ड करते रहने के लिए क्रेडिट कमाएँ।
एक भाषा मॉडल अच्छे से तब काम करता है जब वह उस टेक्स्ट पर reasoning कर सकता है जिसे वह "देख" रहा है। पर यह अपने आप आपकी लेटेस्ट प्रोडक्ट चेंजिस, कंपनी नीतियाँ, या किसी ग्राहक के अकाउंट‑डिटेल्स नहीं जानता। Retrieval‑Augmented Generation (RAG) साधारण समाधान है: सबसे पहले प्रासंगिक तथ्य निकालो, फिर मॉडल से उन तथ्यों का उपयोग करते हुए लिखवाओ।
RAG साधारण भाषा में
RAG को “ओपन‑बुक AI” समझें। मॉडल से याददाश्त पर निर्भर रहने के बजाय, आपकी ऐप तेजी से भरोसेमंद स्रोतों से कुछ प्रासंगिक पैसैज (स्निपेट्स) खींचती है और उन्हें प्रॉम्प्ट में जोड़ती है। मॉडल फिर उन दी गई सामग्रियों के आधार पर उत्तर बनाता है।
इसे कब उपयोग करें
RAG एक अच्छा डिफ़ॉल्ट है जब भी सटीकता बाहरी जानकारी पर निर्भर हो:
- आपकी प्रोडक्ट डॉक्यूमेंटेशन, रिलीज नोट्स, या हेल्प‑सेंटर आर्टिकल्स
- आंतरिक नीतियाँ (रिफंड, सुरक्षा नियम, कंप्लायंस भाषा)
- उपयोगकर्ता‑विशिष्ट डेटा (ऑर्डर, टिकट, अकाउंट सेटिंग्स)
- बड़े नॉलेज बेस जहाँ सर्च करना प्रॉम्प्ट में सब कुछ चिपकाने से तेज़ है
अगर आपकी ऐप का वैल्यू "हमारे बिजनेस के लिए सही उत्तर" पर निर्भर है, तो RAG आमतौर पर मॉडल के अनुमान लगाने से बेहतर होता है।
बुनियादी फ्लो
- Retrieve: उपयोगकर्ता के प्रश्न को सर्च क्वेरी में बदलें और अपनी कंटेंट स्टोर (डॉक्स, DB, वेक्टर इंडेक्स) से शीर्ष संबंधित चंक्स निकालें।
- Snippet / cite: उन चंक्स को मॉडल इनपुट में शामिल करें, अक्सर शीर्षक, टाइमस्टैम्प, या पहचानकर्ता के साथ ताकि आप दिखा सकें "यह कहाँ से आया।"
- Generate: मॉडल से कहें कि वह केवल प्रदान किए गए संदर्भ का उपयोग करके उत्तर दे और कहे अगर संदर्भ में पर्याप्त जानकारी नहीं है।
सबसे बड़ी सीमा
RAG उतना ही अच्छा है जितना उसकी रिट्रीवल। अगर सर्च स्टेप पुराना, अप्रासंगिक, या अधूरा सामग्री लौटाए, तो मॉडल आत्मविश्वास से गलत उत्तर दे सकता है—अब वह "गलत स्रोत" में ग्राउंडेड दिखेगा। व्यवहार में, रिट्रीवल की गुणवत्ता (चंकिन्ग, मेटाडेटा, ताज़गी, रैंकिंग) सुधारना अक्सर प्रॉम्प्ट ट्वीक से अधिक सटीकता बढ़ाता है।
एजेंट्स: जब मॉडल बहु‑चरण वर्कफ़्लो चलाता है
“एजेंट” मूलतः LLM का एक ऐसा चलन है जो लूप में चलता है: यह योजना बनाता, एक कदम उठाता, क्या हुआ देखता, और आगे क्या करना है तय करता है। एक बार में सिर्फ़ जवाब देने की बजाय यह तब तक दोहराता है जब तक लक्ष्य पूरा न हो।
सबसे सरल एजेंट साइकिल
एक उपयोगी मानसिक मॉडल है:
Plan → Do → Check → Revise
- Plan: लक्ष्य को कुछ कदमों में तोड़ें ("डेटा ढूँढो, उसका सार बनाओ, ईमेल ड्राफ्ट करो")।
- Do: एक कदम निष्पादित करें—अकसर किसी टूल को कॉल करके (सर्च, DB क्वेरी, कैलेंडर API) या ड्राफ्ट जेनरेट करके।
- Check: परिणाम की तुलना लक्ष्य से करें ("क्या मैंने वास्तव में ग्राहक की पिछली इनवॉइस पाई?")।
- Revise: योजना समायोजित करें और अगला कदम लें।
यही लूप किसी सिंगल प्रॉम्प्ट को छोटे‑वर्कफ़्लो में बदल देता है। यही कारण है कि एजेंट अधिक “स्वतंत्र” दिख सकते हैं: मॉडल केवल टेक्स्ट ही नहीं बना रहा, यह कार्रवाइयाँ चुन और क्रमबद्ध कर रहा है।
स्टॉपिंग कंडीशन्स और गार्डरेल्स
एजेंट्स को रोकने के स्पष्ट नियम चाहिए। सामान्य स्टॉप कंडीशन्स में शामिल हैं:
- सफलता मानदंड पूरा हो गया (उदा., "ईमेल ड्राफ्ट में ऑर्डर नंबर और डिलीवरी तारीख शामिल है")।
- अधिकतम चरणों की संख्या पहुँच गई।
- टोकन बजट या समयसीमा खत्म।
- आवश्यक टूल कॉल बार‑बार फेल हो रहे हों।
गार्डरेल्स वे प्रतिबंध हैं जो लूप को सुरक्षित और अनुमाननीय बनाते हैं: अनुमत टूल, स्रोतों का दायरा, अप्रूवल स्टेप (मानव‑इन‑द‑लूप), और आउटपुट फ़ॉर्मैट्स।
रनअवे लूप से बचना
क्योंकि एजेंट हमेशा "एक और कदम" प्रस्ताव कर सकता है, आपको विफलता मोड के लिए डिजाइन करना चाहिए। बजट, टाइमआउट, और स्टेप लिमिट के बिना, एजेंट दोहराव में फँस सकता है या लागत बढ़ा सकता है।
व्यावहारिक डिफॉल्ट: इटरैशन्स को कैप करें, हर एक्शन को लॉग करें, टूल रिज़ल्ट्स की वैलिडेशन मांगें, और आंशिक उत्तर + क्या प्रयास हुआ यह बताकर graceful fail करें। यह अक्सर बेहतर प्रोडक्ट डिज़ाइन है बनाम एजेंट को अनंत लूप में छोड़ देना।
Koder.ai जैसे प्लेटफ़ॉर्म कहाँ फिट होते हैं
यदि आप Koder.ai जैसी vibe‑coding प्लेटफ़ॉर्म के साथ बना रहे हैं, तो यह “एजेंट + टूल्स” मानसिक मॉडल खासकर व्यावहारिक है। आप सिर्फ़ सुझाव नहीं ले रहे—आप एक वर्कफ़्लो उपयोग कर रहे हैं जहाँ असिस्टेंट फीचर‑प्लान कर सकता है, React/Go/PostgreSQL या Flutter कम्पोनेन्ट जेनरेट कर सकता है, और चेकपॉइंट्स (जैसे स्नैपशॉट और रोलबैक) के साथ इटरेट कर सकता है ताकि आप तेज़ी से आगे बढ़ें बिना कंट्रोल खोए।
प्रॉम्प्टिंग को इंटरफ़ेस डिजाइन की तरह देखें
अपना Flutter ऐप ड्राफ्ट करें
अपने मोबाइल फ्लो का वर्णन करें और Koder.ai ऐसे Flutter स्क्रीन ड्राफ्ट करे जिन्हें आप एडिट कर सकें।
जब आप किसी ऐप फ़ीचर के पीछे LLM रखते हैं, आपका प्रॉम्प्ट "बस टेक्स्ट" नहीं रह जाता। यह आपके प्रोडक्ट और मॉडल के बीच इंटरफ़ेस कॉन्ट्रैक्ट बन जाता है: मॉडल क्या करने की कोशिश कर रहा है, उसे किन चीज़ों की अनुमति है, और उसे किस तरह जवाब देना चाहिए ताकि आपका कोड भरोसेमंद तरीके से उसे खा सके।
एक उपयोगी मानसिकता है प्रॉम्प्ट्स को UI फॉर्म की तरह मानना। अच्छे फॉर्म अस्पष्टता घटाते हैं, विकल्पों को सीमित करते हैं, और अगला कदम स्पष्ट करते हैं। अच्छे प्रॉम्प्ट भी ऐसा ही करते हैं।
एक व्यावहारिक प्रॉम्प्ट चेकलिस्ट
शिप करने से पहले सुनिश्चित करें कि प्रॉम्प्ट स्पष्ट रूप से कहता है:
- Goal: सफलता कैसी दिखे, एक वाक्य में।
- Inputs: मॉडल को क्या डेटा मिलता है (और क्या उसे इग्नोर करना चाहिए)।
- Constraints: टोन, सुरक्षा नियम, लंबाई सीमाएँ, जरूरी/नजरअंदाज़ करने योग्य चीजें।
- Output format: उत्तर की सटीक संरचना ताकि आपकी ऐप उसे पार्स कर सके।
व्यवहार-anchor करने के लिए एक उदाहरण दिखाएँ
मॉडल पैटर्न्स का पालन करता है। आप जो पैटर्न चाहते हैं उसे “सिखाने” का एक मजबूत तरीका है एक अच्छा इनपुट‑आउट उदाहरण शामिल करना (खासकर यदि आपके टास्क के एज‑केस हों)।
एक उदाहरण भी बैक‑एंड‑फोर्थ कम कर सकता है और मॉडल को उस फ़ॉर्मैट को अपनाने से रोक सकता है जिसे आपकी UI प्रदर्शित नहीं कर सकती।
गद्य के बजाय संरचित आउटपुट पसंद करें
यदि किसी सिस्टम द्वारा उत्तर पढ़ा जाएगा, तो उसे संरचित बनाइए। JSON, टेबल, या सख्त बुलेट अपेक्षा करें।
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
\"result\": \"string\",
\"confidence\": \"low|medium|high\",
\"warnings\": [\"string\"],
\"next_steps\": [\"string\"]
}
यह “प्रॉम्प्टिंग” को अनुमानित इंटरफ़ेस डिज़ाइन में बदल देता है।
ज़रूरत होने पर क्लैरिफाइंग प्रश्न माँगें
एक स्पष्ट नियम जोड़ें जैसे: "यदि प्रमुख आवश्यकताएँ गायब हैं, तो उत्तर देने से पहले क्लैरिफाइंग प्रश्न पूछो।"
यह एक पंक्ति गलत‑लगने वाले, आत्मविश्वासी आउटपुट को रोक सकती है—क्योंकि मॉडल अनुमान लगाने के बजाय रुककर पूछ सकता है।
प्रॉम्प्टिंग को अपने बिल्ड वर्कफ़्लो से मिलाएँ
वास्तव में, सबसे भरोसेमंद प्रॉम्प्ट वे होते हैं जो आपके प्रोडक्ट के बिल्ड और डिप्लॉय वर्कफ़्लो से मेल खाते हैं। उदाहरण के लिए, यदि आपका प्लेटफ़ॉर्म पहले योजना, फिर परिवर्तन जनरेट करना, फिर सोर्स कोड निर्यात/डिप्लॉय करना सपोर्ट करता है, तो आप प्रॉम्प्ट कॉन्ट्रैक्ट में वही चरण (plan → produce diff/steps → confirm → apply) दर्शा सकते हैं। Koder.ai का “planning mode” यह दिखाने का एक अच्छा उदाहरण है कि प्रक्रिया को स्पष्ट चरणों में बदलने से ड्रिफ्ट कम हो सकता है और टीमें बदलावों की समीक्षा कर सकती हैं।
भरोसा बनाने के तरीके: टेस्ट, इवाल्स, और ऐप्स में सुरक्षित उपयोग
भरोसा मॉडल के "आत्मविश्वासी" दिखने से नहीं आता। यह एक निर्भरता की तरह मापा, मॉनीटर और सीमित होने से आता है।
क्या मायने रखता उसे मूल्यांकित करें (सब कुछ नहीं)
छोटे सेट से शुरू करें उन असली टास्क के साथ जिन्हें आपकी ऐप अच्छी तरह करना चाहिए। फिर उन्हें दोहराने योग्य चेक में बदल दें:
- Golden prompts: चुने हुए प्रॉम्प्ट्स + अपेक्षित लक्षण (या जहाँ संभव हो सटीक उत्तर)। इन्हें हर रिलीज़ से पहले चलाएँ।
- यूनिट‑टेस्ट शैली चेक: अगर मॉडल संरचित डेटा (JSON, फील्ड्स, निर्णय) आउटपुट करता है, तो शेप, आवश्यक कीज़, रेंज, और अनुमति मूल्यों को असर्ट करें।
- स्पॉट चेक्स: हाल की बातचीत का हल्का साप्ताहिक रिव्यू ताकि नए फेलर‑मोड पकड़ में आ सकें जो आपके टेस्ट सेट से छुट गए हों।
समय के साथ विश्वसनीयता मापें
"यह अच्छा है" पूछने के बजाय ट्रैक करें "कितनी बार यह पास होता है?" उपयोगी मेट्रिक्स:
- आपकी गोल्डन प्रॉम्प्ट्स पर पास रेट (कुल और श्रेणीवार)।
- रिग्रेशन चेक्स आज बनाम पिछले सप्ताह (या पिछले मॉडल संस्करण) ताकि साइलेंट व्यवहार परिवर्तन नोटिस हों।
- टूल सक्सेस रेट (% टूल कॉल्स जो उपयोगी परिणाम लौटाते हैं)।
मुद्दे दोहराने के लिए पर्याप्त लॉग रखें
जब कुछ गलत हो, आपको उसे रिप्ले करने योग्य होना चाहिए। लॉग करें (उचित रिडैक्शन के साथ):
- प्रॉम्प्ट टेम्पलेट और अंतिम रेंडर्ड प्रॉम्प्ट।
- मॉडल नाम/संस्करण, temperature, और कोई भी सिस्टम निर्देश।
- टूल कॉल्स और टूल परिणाम (इनपुट, आउटपुट, एरर्स, लेटेंसी)।
यह डिबगिंग को व्यावहारिक बनाता है और आपको यह उत्तर देने में मदद करता है "क्या मॉडल बदला, या हमारा डेटा/टूल बदला?"
प्रोडक्शन ऐप्स के लिए सुरक्षा‑बेसिक्स
कुछ डिफॉल्ट्स सामान्य घटनाओं को रोकते हैं:
- कभी भी सीक्रेट्स न रखें (API कीज़, पासवर्ड, प्राइवेट टोकन) प्रॉम्प्ट या चैट इतिहास में।
- संवेदनशील आउटपुट (पर्सनल डेटा, मेडिकल/कानूनी दावे, पॉलिसी उल्लंघन) दिखाने से पहले फ़िल्टर/ब्लॉक करें।
- एक स्पष्ट fallback path जोड़ें: जब आत्मविश्वास कम हो, तो क्लैरिफाइंग प्रश्न पूछें, स्रोत दिखाएँ, या मानव को रूट करें।
अक्सर पूछे जाने वाले प्रश्न
LLM के संदर्भ में “AI सोचता है” का असल मतलब क्या है?
इसका मतलब आमतौर पर यह है कि मॉडल ऐसा सारगर्भित, उद्देश्य-उन्मुख टेक्स्ट बना सकता है जो समझ और तर्क जैसा दिखता है। व्यवहार में, एक LLM अगले-टोकन की भविष्यवाणी कर रहा है: यह आपके प्रॉम्प्ट, निर्देशों और दिए गए संदर्भ के आधार पर सबसे संभावित जारी रखने को जनरेट करता है。
ऐप बिल्डर्स के लिए उपयोगी निष्कर्ष यह है कि “सोचना” वह आउटपुट व्यवहार है जिसे आप आकार दे और प्रतिबंधित कर सकते हैं—यह आंतरिक सच्चाई की गारंटी नहीं है।
एक टोकन क्या है, और ऐप बिल्डर्स को इसकी परवाह क्यों करनी चाहिए?
टोकन वह टेक्स्ट का टुकड़ा है जिसे मॉडल प्रोसेस और जनरेट करता है (पूरा शब्द, शब्द का हिस्सा, विराम चिन्ह, या वाइटस्पेस)। चूंकि मॉडल टोकन पर काम करता है, इसलिए लागत, सीमाएँ और कटौती सब टोकन-आधारित होती हैं。
व्यवहारिक रूप से:
- जो प्रॉम्प्ट छोटा दिखता है वह टोकन-भार में भारी हो सकता है (कोड, JSON, लंबे आईडी)।
- आउटपुट और संदर्भ सीमाएँ टोकनों में मापी जाती हैं, इसलिए UI और प्रॉम्प्ट की योजना उसी के अनुसार बनाएं।
एक ही प्रॉम्प्ट अलग-अलग उत्तर क्यों दे सकता है?
क्योंकि जेनरेशन संभाव्य है। हर कदम पर मॉडल कई संभावित अगले टोकन को संभाव्यता देता है, और अधिकांश सिस्टम हमेशा सबसे संभावित शीर्ष विकल्प नहीं चुनते—वे उस वितरण से सैंपल करते हैं।
आउटपुट अधिक पुनरुत्पाद्य बनाने के लिए:
- temperature घटाएँ।
- top‑p घटाएँ।
- सख्त फॉर्मेटिंग निर्देश और उदाहरण दें।
- आवश्यक संदर्भ (स्कीमा, नियम, बाध्यताएँ) प्रदान करके अस्पष्टता कम करें।
AI आत्मविश्वासी लगे और फिर भी गलत कैसे हो सकता है?
LLM सुगठित टेक्स्ट बनाने के लिए अनुकूलित होते हैं, न कि तथ्यों की जाँच के लिए। वे निश्चित शब्दावली का उपयोग इसलिए करते हैं क्योंकि आत्मविश्वासी टोन प्रशिक्षण डेटा में सामान्य पैटर्न है—even जब मूल दावा अनुमान पर आधारित हो।
उत्पाद डिज़ाइन में, प्रवाह को “अच्छी लेखनी” मानें, न कि “सत्यापन”, और जब सटीकता आवश्यक हो तो रिट्रीवल, टूल्स, टेस्ट या अप्रूवल जैसी जाँच जोड़ें।
संदर्भ विंडो क्या है, और लंबी बातचीत को यह कैसे प्रभावित करती है?
संदर्भ विंडो वह अधिकतम टेक्स्ट सीमा है जिसे मॉडल एक बार में देख सकता है (सिस्टम निर्देश, बातचीत का इतिहास, निकाले गए स्निपेट)। जब थ्रेड बहुत लंबा हो जाता है, तो पुरानी जानकारी विंडो से बाहर चली जाती है और मॉडल उसे नहीं देख पाता।
राहत उपाय:
- निर्णयों और आवश्यकताओं का रोलिंग सारांश रखें।
- हर टर्न में प्रमुख प्रतिबंधों को फिर से इंजेक्ट करें।
- अपनी ऐप में अप्रासंगिक चैट इतिहास को ट्रिम करें।
क्या मॉडल मेरा डेटाबेस, कोडबेस, या नवीनतम प्रॉडक्ट परिवर्तनों को जानता है?
नहीं—स्वतः नहीं। डिफ़ॉल्ट रूप से मॉडल वेब ब्राउज़ नहीं कर रहा होता, आपकी डेटाबेस पढ़ नहीं रहा होता, और कोड निष्पादित नहीं कर रहा होता। मॉडल को सिर्फ वही जानकारी मिलती है जो आप प्रॉम्प्ट के माध्यम से देते हैं और जो टूल्स आपने स्पष्ट रूप से कनेक्ट किए होते हैं।
यदि उत्तर आंतरिक या अद्यतित तथ्यों पर निर्भर करता है, तो उसे RAG या किसी टूल कॉल के जरिए पास करें—“ज्यादा पूछने” पर नहीं।
कब मुझे मॉडल के टेक्स्ट पर भरोसा करने के बजाय टूल्स का उपयोग करना चाहिए?
जब आपको सत्यापित परिणामों या असल कार्रवाई की जरूरत हो, तो टूल्स का उपयोग करें। सामान्य उदाहरण:
- कोड को चलाकर/टेस्ट चलाकर पुष्टि करना कि यह सचमुच काम करता है।
- वास्तविक काउंट्स के लिए डेटाबेस क्वेरी करना।
- पुरानी धारणाओं से बचने के लिए डॉक्यूमेंटेशन/पॉलिसी खीचना।
एक अच्छा पैटर्न है propose → check → adjust, जहाँ मॉडल टूल आउटपुट के आधार पर पुनरावृत्ति करता है।
RAG क्या है, और इसे कब लागू करना चाहिए?
RAG (Retrieval‑Augmented Generation) “ओपन‑बुक AI” है: आपकी ऐप पहले विश्वसनीय स्रोतों से प्रासंगिक स्निपेट्स खींचती है और फिर मॉडल से कहती है कि केवल उन तथ्यों का उपयोग करके जवाब दे।
इसे लागू करने लायक है जब:
- सटीकता कंपनी-विशिष्ट या उपयोगकर्ता-विशिष्ट डेटा पर निर्भर करे।
- ज्ञान तेजी से बदलता हो।
- कॉर्पस इतना बड़ा हो कि सब कुछ प्रॉम्प्ट में चिपकाना संभव न हो।
मुख्य विफलता: खराब रिट्रीवल—सर्च, चंकिन्ग और ताज़गी में सुधार अक्सर प्रॉम्प्ट ट्वीक से बेहतर परिणाम देते हैं।
AI एजेंट क्या है, और मैं उसे रनअवे व्यवहार से कैसे बचाऊं?
एजेंट एक ऐसा LLM है जो लूप में चलता है: योजना बनाता है, एक कदम उठाता है, परिणाम देखता है, और फिर अगला कदम तय करता है। यह बहु‑चरण वर्कफ़्लो के लिए उपयोगी है (जैसे “जानकारी खोजो → ड्राफ्ट बनाओ → सत्यापित करो → भेजो”)।
एजेंट को नियंत्रित रखने के उपाय:
- चरण सीमाएँ और टाइमआउट सेट करें।
- टूल परमिशन को न्यूनतम रखें (least privilege)।
- विनाशकारी कार्रवाइयों के लिए पुष्टि आवश्यक करें।
- हर क्रिया और टूल रिज़ल्ट को लॉग करें ताकि डिबग आसान हो।
उत्पादन ऐप्स में AI फीचर्स को विश्वसनीय कैसे बनाएं?
प्रॉम्प्ट को एक इंटरफ़ेस कॉन्ट्रैक्ट की तरह ट्रीट करें: लक्ष्य, इनपुट, प्रतिबंध और आउटपुट फ़ॉर्मेट स्पष्ट करें ताकि आपकी ऐप परिणामों को भरोसेमंद तरीके से इस्तेमाल कर सके।
व्यावहारिक भरोसा निर्माण:
- गोल्डन प्रॉम्प्ट्स और रिग्रेशन टेस्ट।
- संरचित आउटपुट पर स्कीमा वैलिडेशन (JSON शेप, आवश्यक कीज़)।
- लॉगिंग (प्रॉम्प्ट टेम्पलेट, मॉडल/संस्करण, टूल कॉल/रिज़ल्ट) साथ में रिडैक्शन।
- सुरक्षित फॉलबैक: क्लैरिफाइंग प्रश्न, स्रोत दिखाना, या मानव को सौंपना।