30 अग॰ 2025·8 मिनट
ऐप बनाते समय AI कैसे "सोचता" है — एक सरल मानसिक मॉडल
AI किस तरह से कोड और फैसले बनाता है—टोकन, संदर्भ विंडो, टूल्स, टेस्ट—सीधे उपयोगी मानसिक मॉडल, सीमाएँ और प्रैक्टिकल प्रॉम्प्टिंग सुझाव।
AI किस तरह से कोड और फैसले बनाता है—टोकन, संदर्भ विंडो, टूल्स, टेस्ट—सीधे उपयोगी मानसिक मॉडल, सीमाएँ और प्रैक्टिकल प्रॉम्प्टिंग सुझाव।
जब लोग कहते हैं “AI सोचता है,” तो वे आमतौर पर ऐसा मानते हैं कि यह आपकी बात समझता है, उस पर तर्क करता है, और फिर कोई उत्तर तय करता है।
आधुनिक टेक्स्ट-आधारित AI (LLMs) के लिए एक उपयोगी मानसिक मॉडल सरल है: मॉडल यह भविष्यवाणी करता है कि अगला टेक्स्ट क्या होना चाहिए।
यह कम रोमांचक लग सकता है—तब तक जब तक आप नहीं देखते कि “अगला टेक्स्ट” कितनी दूर तक जा सकता है। अगर मॉडल ने प्रशिक्षण से पर्याप्त पैटर्न सीखे होते हैं, तो अगले शब्द (और उसके बाद के शब्द) की भविष्यवाणी से व्याख्याएँ, योजनाएँ, कोड, सार, और यहां तक कि संरचित डेटा भी बन सकता है जिसका आपकी ऐप उपयोग कर सकती है।
आपको अच्छे AI फीचर बनाने के लिए अंतर्निहित गणित सीखने की ज़रूरत नहीं है। ज़रूरत है एक व्यावहारिक तरीका जो व्यवहार की उम्मीद करने में मदद करे:
यह लेख वैसा ही मॉडल देता है: न तो हाइप, न कोई गहरा टेक्निकल पेपर—सिर्फ़ वे अवधारणाएँ जो भरोसेमंद प्रोडक्ट एक्सपीरियंस डिजाइन करने में मदद करें।
ऐप बिल्डर के नजरिए से, मॉडल का “सोचना” वह टेक्स्ट है जो यह आपके दिए गए इनपुट (प्रॉम्प्ट, यूज़र मैसेज़, सिस्टम नियम, और कोई भी निकाला गया कंटेंट) के जवाब में जनरेट करता है। मॉडल डिफ़ॉल्ट रूप से तथ्य की जाँच नहीं कर रहा होता, वेब ब्राउज़ नहीं कर रहा होता, और आपके डेटाबेस में क्या है यह “नहीं जानता” जब तक आप वह जानकारी पास न करें।
उम्मीदें उसी के अनुसार सेट करें: LLMs ड्राफ्टिंग, ट्रांसफ़ॉर्मिंग, और टेक्स्ट क्लासिफाई करने तथा कोड-जैसे आउटपुट जनरेट करने में बेहद उपयोगी हैं। वे जादुई सत्य इंजन नहीं हैं।
हम मानसिक मॉडल को कुछ हिस्सों में तोड़ेंगे:
इन विचारों से आप प्रॉम्प्ट, UI, और सेफ़गार्ड्स डिजाइन कर सकते हैं जो AI फीचर्स को स्थिर और भरोसेमंद बनाते हैं।
जब लोग कहते हैं कि कोई AI “सोचता” है, तो यह कल्पना करना आसान है कि यह इंसान की तरह तर्क कर रहा है। एक उपयोगी मानसिक मॉडल सरल है: यह बेहद तेज़ ऑटो‑कम्प्लेट—एक छोटा टुकड़ा एक बार में—कर रहा है।
एक टोकन वह टेक्स्ट का टुकड़ा है जिसके साथ मॉडल काम करता है। कभी यह पूरा शब्द होता है ("apple"), कभी शब्द का हिस्सा ("app" + "le"), कभी विराम चिन्ह, और कभी व्हाइटस्पेस। टोकनाइज़र पर निर्भर करता है कि कैसे टुकड़े बनते हैं, लेकिन मुख्य बात यह है: मॉडल वाक्यों के रूप में नहीं बल्कि टोकनों के रूप में टेक्स्ट प्रोसेस करता है।
मॉडल का मूल लूप है:
बस इतना ही। हर पैराग्राफ, बुलेट लिस्ट, और “रिजनिंग” चेन आप देखते हैं वो इस अगले‑टोकन प्रेडिक्शन को कई बार दोहराकर बनता है।
क्योंकि मॉडल ने प्रशिक्षण में बड़े पैमाने पर टेक्स्ट देखे हैं, उसने पैटर्न सीखे हैं—कैसे व्याख्याएँ बहती हैं, एक शिष्ट ईमेल कैसा लगता है, या बग फिक्स आमतौर पर कैसे लिखा जाता है। जब आप कोई प्रश्न पूछते हैं, तो यह उस तरह का जवाब जनरेट करता है जो सीखे गए पैटर्न और दिए गए संदर्भ से मेल खाता है।
इसीलिए यह आत्मविश्वासी और सुसंगत सुन सकता है भले ही यह गलत हो: यह अगले टेक्स्ट के लिए अनुकूलित है—सत्य की जाँच के लिए नहीं।
कोड मॉडल के लिए विशेष नहीं है। JavaScript, SQL, JSON, और एरर मैसेज सब टोकनों का सिलसिला हैं। मॉडल उपयोगी कोड इसलिए दे सकता है क्योंकि उसने सामान्य कोडिंग पैटर्न सीखे हैं, न कि इसलिए कि वह आपकी ऐप को एक इंजीनियर की तरह सचमुच “समझता” है।
जब लोग पूछते हैं "मॉडल ने वह उत्तर कहाँ से लिया?", उपयोगी मानसिक मॉडल यह है: उसने विशाल उदाहरणों से पैटर्न सीखे और अब उन पैटर्नों को मिलाकर अगले टेक्स्ट की भविष्यवाणी करता है।
प्रशिक्षण के दौरान मॉडल को कई टेक्स्ट स्निपेट दिखाए जाते हैं (किताबें, लेख, कोड, डॉक्यूमेंटेशन, प्रश्नोत्तर, और भी बहुत कुछ)। यह बार‑बार एक सरल कार्य का अभ्यास करता है: कुछ टेक्स्ट दिया गया है, अगला टोकन क्या होगा इसे भविष्यवाणी करो। जब यह गलत होता है, प्रशिक्षण प्रक्रिया मॉडल के अंदर के पैरामीटर को थोड़ा बदल देती है ताकि अगली बार बेहतर भविष्यवाणी हो।
समय के साथ, वे बदलाव इकट्ठा हो जाते हैं और मॉडल उन रिश्तों को एन्कोड करने लगता है जैसे:
क्योंकि यह सांख्यिकीय नियमितताओं को सीख रहा है—न कि एक तय स्क्रिप्ट—इसलिए यह पैटर्न्स को नए तरीकों से जोड़ सकता है। अगर उसने “किसी अवधारणा की व्याख्या” के कई उदाहरण देखे हैं और “आपके ऐप परिदृश्य” के कई उदाहरण भी, तो यह अक्सर उन्हें जोड़कर एक मुफ़्त‑निर्मित उत्तर दे सकता है।
इसीलिए LLM एक निच ниш प्रोडक्ट के लिए प्रासंगिक ऑनबोर्डिंग ईमेल लिख सकता है, या सामान्य API इंटीग्रेशन स्पष्टीकरण को किसी विशेष स्टैक के अनुसार अनुकूलित कर सकता है। यह किसी एक संग्रहीत पैराग्राफ को पुनः प्राप्त नहीं कर रहा; यह नया अनुक्रम बना रहा है जो सीखे पैटर्न से मेल खाता है।
यह मान लेना कि मॉडल किसी विशिष्ट तथ्य (जैसे प्राइसिंग टियर या आंतरिक नीति) को विश्वसनीय रूप से "लुक अप" कर सकता है, गलत होगा। प्रशिक्षण इंडेक्सिंग की तरह काम नहीं करता—यह कंप्रेशन के जैसा है: बहुत से उदाहरण वज़न में समाहित होते हैं जो भविष्य की भविष्यवाणियों को प्रभावित करते हैं।
इसका मतलब है कि मॉडल अक्सर ऐसे विवरणों के बारे में आत्मविश्वास से बोल सकता है जो वह समान संदर्भों में आम तौर पर दिखाई देने वाले पैटर्न के आधार पर अनुमान कर रहा है।
पैटर्न सीखना प्रवाहपूर्ण, प्रासंगिक टेक्स्ट बनाने में शक्तिशाली है, पर प्रवाह और सच्चाई एक समान नहीं हैं। मॉडल कर सकता है:
ऐप बिल्डरों के लिए मुख्य संदेश: LLM के उत्तर सामान्यतः सीखे पैटर्नों से आते हैं, न कि सत्यापित तथ्यों से। अगर सटीकता मायने रखती है, तो आप आउटपुट को अपने डेटा और चेक्स से ग्राउंड करना चाहेंगे (बाद के सेक्शन्स में कवर किया गया)।
जब एक LLM उत्तर लिखता है, यह एक "सही वाक्य" किसी डेटाबेस से नहीं निकाल रहा। हर चरण पर यह संभावित अगले टोकन का एक सेट भविष्यवाणी करता है, जिनमें से प्रत्येक की एक संभाव्यता होती है।
अगर मॉडल हमेशा केवल सबसे संभावित अगले टोकन चुने, तो उत्तर बहुत संगत होते—पर अक्सर नीरस और कठोर हो सकते थे। अधिकतर सिस्टम इसके बजाय संभावनाओं से सैंपल करते हैं, जो नियंत्रित यादृच्छिकता लाता है।
दो सामान्य सेटिंग्स आउटपुट की विविधता तय करती हैं:
यदि आप ऐप बना रहे हैं, तो ये नॉब्स "रचनात्मक होने" से ज़्यादा निम्न के बीच चुनाव हैं:
क्योंकि मॉडल "उचित टेक्स्ट" के लिए अनुकूलित है, यह ऐसे वक्तव्य बना सकता है जो निश्चित सुनते हैं—यह सत्यापित होने का सबूत नहीं है। इसलिए ऐप्स में अक्सर ग्राउंडिंग (जैसे रिट्रीवल) या सत्यापन स्टेप्स चाहिए होते हैं।
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 मॉडल आपकी बातचीत "याद" रखता है, वास्तविकता में उसके पास संदर्भ होता है: वह टेक्स्ट जिसे वह अभी देख सकता है—आपका नवीनतम संदेश, कोई सिस्टम निर्देश, और उस चैट का वह हिस्सा जो अभी विंडो में फिट होता है।
संदर्भ विंडो यह तय सीमा है कि मॉडल एक बार में कितनी टेक्स्ट देख सकता है। जैसे ही बातचीत लंबी होती है, पुराने हिस्से विंडो से बाहर चले जाते हैं और मॉडल की दृष्टि से गायब हो जाते हैं।
इसीलिए आप कभी‑कभी ऐसे व्यवहार देखते हैं:
यदि आप थ्रेड में लगातार संदेश जोड़ते रहते हैं, तो आप सीमित स्थान के लिए प्रतिस्पर्धा कर रहे हैं। महत्वपूर्ण प्रतिबंध हाल के बैक‑एंड‑फोर्थ द्वारा बाहर धकेल दिए जाते हैं। बिना सारांश के, मॉडल को जो कुछ भी दिखाई देता है उससे ही inference करना पड़ता है—इसलिए यह आत्मविश्वासी सुन सकता है पर चुपचाप महत्वपूर्ण विवरण खो सकता है।
व्यावहारिक समाधान है समय-समय पर सारांश बनाना: लक्ष्य, फैसलों और प्रतिबंधों को संक्षेप में दोहराना, और उसके बाद जारी रखना। ऐप्स में यह अक्सर एक ऑटोमैटिक “कॉन्वर्सेशन सारांश” के रूप में लागू होता है जो प्रॉम्प्ट में इंजेक्ट किया जाता है।
मॉडल उन निर्देशों का पालन करने की प्रवृत्ति रखते हैं जो उस आउटपुट के पास होते हैं जो वे बनाते जा रहे हैं। इसलिए यदि आपके पास अनिवार्य नियम हैं (फॉर्मेट, टोन, एज‑केस), तो उन्हें प्रॉम्प्ट के अंत के पास रखें—सीधे "अब उत्तर बनाइए" से पहले।
यदि आप ऐप बना रहे हैं, तो इसे इंटरफ़ेस डिज़ाइन की तरह मानें: तय करें क्या चीजें संदर्भ में हमेशा रहनी चाहिए (आवश्यकताएं, उपयोगकर्ता प्राथमिकताएँ, स्कीमा) और सुनिश्चित करें कि वे हमेशा शामिल रहें—या चैट इतिहास को ट्रिम करके या एक संकुचित सारांश जोड़कर। संरचित प्रॉम्प्टिंग पर अधिक के लिए देखें /blog/prompting-as-interface-design।
LLMs टेक्स्ट बनाने में बेहद कुशल हैं जो किसी कुशल डेवलपर जैसा जवाब देने जैसा लगता है। पर "सही लगना" और "सही होना" समान नहीं हैं। मॉडल अगले‑टोकन की भविष्यवाणी कर रहा है, न कि आपके कोडबेस, आपकी निर्भरताओं, या वास्तविक दुनिया के खिलाफ आउटपुट की जाँच कर रहा है।
यदि मॉडल कोई फिक्स, रिफैक्टर या नया फ़ंक्शन सुझाता है, तब भी वह सिर्फ़ टेक्स्ट है। यह आपकी ऐप को रन नहीं करता, पॅकेजेस इम्पोर्ट नहीं करता, आपका API कॉल नहीं करता, या प्रोजेक्ट कंपाइल नहीं करता—जब तक आप इसे ऐसे टूल से स्पष्ट रूप से कनेक्ट न करें जो ये सब कर सके (उदा., टेस्ट रनर, लिंटर, बिल्ड स्टेप)।
यह प्रमुख अंतर है:
AI गलतियाँ अक्सर अनुमानित तरीकों से होती हैं:
ये त्रुटियाँ नोटिस करना कठिन हो सकता है क्योंकि आस‑पास की व्याख्या आमतौर पर सुसंगत होती है।
AI आउटपुट को ऐसे टीम‑सदस्य के ड्राफ्ट की तरह मानें जिसने लोकल प्रोजेक्ट नहीं चलाया। आत्मविश्वास तब तेज़ी से बढ़े जब आप:
अगर टेस्ट पास नहीं होते, तो मॉडल का उत्तर केवल एक शुरुआत मानें—अंतिम फिक्स नहीं।
एक भाषा मॉडल यह सुझाने में बेहतर है कि "क्या काम कर सकता है"—पर अकेले वह अभी भी सिर्फ टेक्स्ट है। टूल्स वे चीज़ें हैं जो AI‑बैक्ड ऐप को उन प्रस्तावों को सत्यापित और निष्पादित करने देती हैं: कोड चलाना, डेटाबेस क्वेरी करना, डॉक्यूमेंटेशन लाना, या बाहरी API कॉल।
ऐप‑बिल्डिंग वर्कफ़्लोज़ में, टूल्स सामान्यतः दिखते हैं जैसे:
महत्वपूर्ण बदलाव यह है कि मॉडल अब न तो नाटक कर रहा कि उसे परिणाम पता है—यह जाँच सकता है।
एक उपयोगी मानसिक मॉडल है:
यही तरीका "अनुमान" घटाता है। अगर लिंटर अनयूज़्ड इम्पोर्ट रिपोर्ट करे, मॉडल कोड अपडेट करता है। अगर यूनिट टेस्ट फेल हों, तो यह उन फेलर‑केस पर काम करता है या समझाता है कि क्यों पास नहीं हो रहा।
eslint/ruff/prettier चलाकर स्टाइल और मुद्दे पकड़े जाते हैं।टूल्स शक्तिशाली—और खतरनाक—हो सकते हैं। least privilege का पालन करें:
टूल्स मॉडल को "ज़्यादा स्मार्ट" नहीं बनाते, पर वे आपकी ऐप के AI को अधिक ग्राउंडेड बनाते हैं—क्योंकि अब यह सिर्फ़ बताने की बजाय जाँच भी कर सकता है।
एक भाषा मॉडल अच्छे से तब काम करता है जब वह उस टेक्स्ट पर reasoning कर सकता है जिसे वह "देख" रहा है। पर यह अपने आप आपकी लेटेस्ट प्रोडक्ट चेंजिस, कंपनी नीतियाँ, या किसी ग्राहक के अकाउंट‑डिटेल्स नहीं जानता। Retrieval‑Augmented Generation (RAG) साधारण समाधान है: सबसे पहले प्रासंगिक तथ्य निकालो, फिर मॉडल से उन तथ्यों का उपयोग करते हुए लिखवाओ।
RAG को “ओपन‑बुक AI” समझें। मॉडल से याददाश्त पर निर्भर रहने के बजाय, आपकी ऐप तेजी से भरोसेमंद स्रोतों से कुछ प्रासंगिक पैसैज (स्निपेट्स) खींचती है और उन्हें प्रॉम्प्ट में जोड़ती है। मॉडल फिर उन दी गई सामग्रियों के आधार पर उत्तर बनाता है।
RAG एक अच्छा डिफ़ॉल्ट है जब भी सटीकता बाहरी जानकारी पर निर्भर हो:
अगर आपकी ऐप का वैल्यू "हमारे बिजनेस के लिए सही उत्तर" पर निर्भर है, तो RAG आमतौर पर मॉडल के अनुमान लगाने से बेहतर होता है।
RAG उतना ही अच्छा है जितना उसकी रिट्रीवल। अगर सर्च स्टेप पुराना, अप्रासंगिक, या अधूरा सामग्री लौटाए, तो मॉडल आत्मविश्वास से गलत उत्तर दे सकता है—अब वह "गलत स्रोत" में ग्राउंडेड दिखेगा। व्यवहार में, रिट्रीवल की गुणवत्ता (चंकिन्ग, मेटाडेटा, ताज़गी, रैंकिंग) सुधारना अक्सर प्रॉम्प्ट ट्वीक से अधिक सटीकता बढ़ाता है।
“एजेंट” मूलतः LLM का एक ऐसा चलन है जो लूप में चलता है: यह योजना बनाता, एक कदम उठाता, क्या हुआ देखता, और आगे क्या करना है तय करता है। एक बार में सिर्फ़ जवाब देने की बजाय यह तब तक दोहराता है जब तक लक्ष्य पूरा न हो।
एक उपयोगी मानसिक मॉडल है:
Plan → Do → Check → Revise
यही लूप किसी सिंगल प्रॉम्प्ट को छोटे‑वर्कफ़्लो में बदल देता है। यही कारण है कि एजेंट अधिक “स्वतंत्र” दिख सकते हैं: मॉडल केवल टेक्स्ट ही नहीं बना रहा, यह कार्रवाइयाँ चुन और क्रमबद्ध कर रहा है।
एजेंट्स को रोकने के स्पष्ट नियम चाहिए। सामान्य स्टॉप कंडीशन्स में शामिल हैं:
गार्डरेल्स वे प्रतिबंध हैं जो लूप को सुरक्षित और अनुमाननीय बनाते हैं: अनुमत टूल, स्रोतों का दायरा, अप्रूवल स्टेप (मानव‑इन‑द‑लूप), और आउटपुट फ़ॉर्मैट्स।
क्योंकि एजेंट हमेशा "एक और कदम" प्रस्ताव कर सकता है, आपको विफलता मोड के लिए डिजाइन करना चाहिए। बजट, टाइमआउट, और स्टेप लिमिट के बिना, एजेंट दोहराव में फँस सकता है या लागत बढ़ा सकता है।
व्यावहारिक डिफॉल्ट: इटरैशन्स को कैप करें, हर एक्शन को लॉग करें, टूल रिज़ल्ट्स की वैलिडेशन मांगें, और आंशिक उत्तर + क्या प्रयास हुआ यह बताकर graceful fail करें। यह अक्सर बेहतर प्रोडक्ट डिज़ाइन है बनाम एजेंट को अनंत लूप में छोड़ देना।
यदि आप Koder.ai जैसी vibe‑coding प्लेटफ़ॉर्म के साथ बना रहे हैं, तो यह “एजेंट + टूल्स” मानसिक मॉडल खासकर व्यावहारिक है। आप सिर्फ़ सुझाव नहीं ले रहे—आप एक वर्कफ़्लो उपयोग कर रहे हैं जहाँ असिस्टेंट फीचर‑प्लान कर सकता है, React/Go/PostgreSQL या Flutter कम्पोनेन्ट जेनरेट कर सकता है, और चेकपॉइंट्स (जैसे स्नैपशॉट और रोलबैक) के साथ इटरेट कर सकता है ताकि आप तेज़ी से आगे बढ़ें बिना कंट्रोल खोए।
जब आप किसी ऐप फ़ीचर के पीछे LLM रखते हैं, आपका प्रॉम्प्ट "बस टेक्स्ट" नहीं रह जाता। यह आपके प्रोडक्ट और मॉडल के बीच इंटरफ़ेस कॉन्ट्रैक्ट बन जाता है: मॉडल क्या करने की कोशिश कर रहा है, उसे किन चीज़ों की अनुमति है, और उसे किस तरह जवाब देना चाहिए ताकि आपका कोड भरोसेमंद तरीके से उसे खा सके।
एक उपयोगी मानसिकता है प्रॉम्प्ट्स को UI फॉर्म की तरह मानना। अच्छे फॉर्म अस्पष्टता घटाते हैं, विकल्पों को सीमित करते हैं, और अगला कदम स्पष्ट करते हैं। अच्छे प्रॉम्प्ट भी ऐसा ही करते हैं।
शिप करने से पहले सुनिश्चित करें कि प्रॉम्प्ट स्पष्ट रूप से कहता है:
मॉडल पैटर्न्स का पालन करता है। आप जो पैटर्न चाहते हैं उसे “सिखाने” का एक मजबूत तरीका है एक अच्छा इनपुट‑आउट उदाहरण शामिल करना (खासकर यदि आपके टास्क के एज‑केस हों)।
एक उदाहरण भी बैक‑एंड‑फोर्थ कम कर सकता है और मॉडल को उस फ़ॉर्मैट को अपनाने से रोक सकता है जिसे आपकी 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” यह दिखाने का एक अच्छा उदाहरण है कि प्रक्रिया को स्पष्ट चरणों में बदलने से ड्रिफ्ट कम हो सकता है और टीमें बदलावों की समीक्षा कर सकती हैं।
भरोसा मॉडल के "आत्मविश्वासी" दिखने से नहीं आता। यह एक निर्भरता की तरह मापा, मॉनीटर और सीमित होने से आता है।
छोटे सेट से शुरू करें उन असली टास्क के साथ जिन्हें आपकी ऐप अच्छी तरह करना चाहिए। फिर उन्हें दोहराने योग्य चेक में बदल दें:
"यह अच्छा है" पूछने के बजाय ट्रैक करें "कितनी बार यह पास होता है?" उपयोगी मेट्रिक्स:
जब कुछ गलत हो, आपको उसे रिप्ले करने योग्य होना चाहिए। लॉग करें (उचित रिडैक्शन के साथ):
यह डिबगिंग को व्यावहारिक बनाता है और आपको यह उत्तर देने में मदद करता है "क्या मॉडल बदला, या हमारा डेटा/टूल बदला?"
कुछ डिफॉल्ट्स सामान्य घटनाओं को रोकते हैं:
इसका मतलब आमतौर पर यह है कि मॉडल ऐसा सारगर्भित, उद्देश्य-उन्मुख टेक्स्ट बना सकता है जो समझ और तर्क जैसा दिखता है। व्यवहार में, एक LLM अगले-टोकन की भविष्यवाणी कर रहा है: यह आपके प्रॉम्प्ट, निर्देशों और दिए गए संदर्भ के आधार पर सबसे संभावित जारी रखने को जनरेट करता है。
ऐप बिल्डर्स के लिए उपयोगी निष्कर्ष यह है कि “सोचना” वह आउटपुट व्यवहार है जिसे आप आकार दे और प्रतिबंधित कर सकते हैं—यह आंतरिक सच्चाई की गारंटी नहीं है।
टोकन वह टेक्स्ट का टुकड़ा है जिसे मॉडल प्रोसेस और जनरेट करता है (पूरा शब्द, शब्द का हिस्सा, विराम चिन्ह, या वाइटस्पेस)। चूंकि मॉडल टोकन पर काम करता है, इसलिए लागत, सीमाएँ और कटौती सब टोकन-आधारित होती हैं。
व्यवहारिक रूप से:
क्योंकि जेनरेशन संभाव्य है। हर कदम पर मॉडल कई संभावित अगले टोकन को संभाव्यता देता है, और अधिकांश सिस्टम हमेशा सबसे संभावित शीर्ष विकल्प नहीं चुनते—वे उस वितरण से सैंपल करते हैं।
आउटपुट अधिक पुनरुत्पाद्य बनाने के लिए:
LLM सुगठित टेक्स्ट बनाने के लिए अनुकूलित होते हैं, न कि तथ्यों की जाँच के लिए। वे निश्चित शब्दावली का उपयोग इसलिए करते हैं क्योंकि आत्मविश्वासी टोन प्रशिक्षण डेटा में सामान्य पैटर्न है—even जब मूल दावा अनुमान पर आधारित हो।
उत्पाद डिज़ाइन में, प्रवाह को “अच्छी लेखनी” मानें, न कि “सत्यापन”, और जब सटीकता आवश्यक हो तो रिट्रीवल, टूल्स, टेस्ट या अप्रूवल जैसी जाँच जोड़ें।
संदर्भ विंडो वह अधिकतम टेक्स्ट सीमा है जिसे मॉडल एक बार में देख सकता है (सिस्टम निर्देश, बातचीत का इतिहास, निकाले गए स्निपेट)। जब थ्रेड बहुत लंबा हो जाता है, तो पुरानी जानकारी विंडो से बाहर चली जाती है और मॉडल उसे नहीं देख पाता।
राहत उपाय:
नहीं—स्वतः नहीं। डिफ़ॉल्ट रूप से मॉडल वेब ब्राउज़ नहीं कर रहा होता, आपकी डेटाबेस पढ़ नहीं रहा होता, और कोड निष्पादित नहीं कर रहा होता। मॉडल को सिर्फ वही जानकारी मिलती है जो आप प्रॉम्प्ट के माध्यम से देते हैं और जो टूल्स आपने स्पष्ट रूप से कनेक्ट किए होते हैं।
यदि उत्तर आंतरिक या अद्यतित तथ्यों पर निर्भर करता है, तो उसे RAG या किसी टूल कॉल के जरिए पास करें—“ज्यादा पूछने” पर नहीं।
जब आपको सत्यापित परिणामों या असल कार्रवाई की जरूरत हो, तो टूल्स का उपयोग करें। सामान्य उदाहरण:
एक अच्छा पैटर्न है propose → check → adjust, जहाँ मॉडल टूल आउटपुट के आधार पर पुनरावृत्ति करता है।
RAG (Retrieval‑Augmented Generation) “ओपन‑बुक AI” है: आपकी ऐप पहले विश्वसनीय स्रोतों से प्रासंगिक स्निपेट्स खींचती है और फिर मॉडल से कहती है कि केवल उन तथ्यों का उपयोग करके जवाब दे।
इसे लागू करने लायक है जब:
मुख्य विफलता: खराब रिट्रीवल—सर्च, चंकिन्ग और ताज़गी में सुधार अक्सर प्रॉम्प्ट ट्वीक से बेहतर परिणाम देते हैं।
एजेंट एक ऐसा LLM है जो लूप में चलता है: योजना बनाता है, एक कदम उठाता है, परिणाम देखता है, और फिर अगला कदम तय करता है। यह बहु‑चरण वर्कफ़्लो के लिए उपयोगी है (जैसे “जानकारी खोजो → ड्राफ्ट बनाओ → सत्यापित करो → भेजो”)।
एजेंट को नियंत्रित रखने के उपाय:
प्रॉम्प्ट को एक इंटरफ़ेस कॉन्ट्रैक्ट की तरह ट्रीट करें: लक्ष्य, इनपुट, प्रतिबंध और आउटपुट फ़ॉर्मेट स्पष्ट करें ताकि आपकी ऐप परिणामों को भरोसेमंद तरीके से इस्तेमाल कर सके।
व्यावहारिक भरोसा निर्माण: