असली चैटबॉट बनाने के लिए जो कुछ चाहिए, वह सब यहाँ है। यह लेख लार्ज लैंग्वेज मॉडल से चलने वाले चैटबॉट के लिए मॉडल चुनने, सिस्टम प्रॉम्प्ट डिज़ाइन करने, बातचीत की मेमोरी, Python में API इंटीग्रेशन, प्रोडक्शन में बॉट क्रैश करने वाली आम गलतियों, और बिना API बजट फूँके टेस्ट व स्केल करने के तरीकों को कवर करता है।
चैटबॉट बनाने का मतलब पहले सालों की NLP रिसर्च और ढेर सारा ट्रेनिंग डेटा होता था। आज LLM API को कॉल करके आप एक दोपहर में काम करने वाला बातचीत करने वाला बॉट खड़ा कर सकते हैं। अब मुश्किल यह नहीं कि बॉट जवाब दे। मुश्किल यह है कि वह अच्छा जवाब दे, लगातार दे, विषय से न भटके और तथ्य गढ़े नहीं। यह लेख उस समस्या की हर परत से गुज़रता है, सही मॉडल चुनने से लेकर ऐसे सिस्टम प्रॉम्प्ट डिज़ाइन करने तक जो प्रोडक्शन में टिकें।
ज़्यादातर लोग LLM को ब्लैक बॉक्स मानते हैं। आप टेक्स्ट भेजते हैं, टेक्स्ट वापस आता है। लेकिन अंदर क्या होता है, यह समझने से आप बेहतर बनाते हैं, और जब चीज़ें बिगड़ें तो उन्हें डीबग करना भी आसान होता है।
LLM शब्द नहीं पढ़ता। वह टोकन पढ़ता है, जो लगभग 3-4 अक्षरों के टुकड़े होते हैं। हर मॉडल की एक कॉन्टेक्स्ट विंडो होती है: एक अनुरोध में वह अधिकतम जितने टोकन प्रोसेस कर सकता है। GPT-4o 128,000 टोकन संभालता है। Llama 2 7B Chat की सीमा 4,096 है। मल्टी-टर्न बातचीत बनाते समय यह फ़र्क बहुत मायने रखता है।
💡 मोटा नियम: 1,000 टोकन लगभग 750 शब्दों के बराबर होते हैं। लंबी बातचीत डेवलपर्स की उम्मीद से कहीं जल्दी कॉन्टेक्स्ट सीमा तक पहुँच जाती है।
जब कॉन्टेक्स्ट विंडो भर जाती है, तो मॉडल पहले की बातें याद नहीं रख सकता। यह कोई बग नहीं है। ट्रांसफ़ॉर्मर ऐसे ही काम करते हैं। मेमोरी को संभालना आपके एप्लिकेशन कोड का काम है, मॉडल का नहीं।
एक बात हर पहली बार बनाने वाले को चौंकाती है: LLM स्टेटलेस होते हैं। हर API कॉल पूरी तरह स्वतंत्र होती है। जब तक आप पिछले संदेश मौजूदा अनुरोध में साफ़-साफ़ शामिल नहीं करते, मॉडल को नहीं पता होता कि पाँच संदेश पहले क्या कहा गया था।
इसका मतलब है कि आपके चैटबॉट की "मेमोरी" पूरी तरह आपकी ज़िम्मेदारी है। आप संदेशों की सूची रखते हैं। हर कॉल पर पूरी सूची भेजते हैं। मॉडल कॉन्टेक्स्ट देखता है, इतिहास नहीं। यही एक आर्किटेक्चरल तथ्य पूरे चैटबॉट एप्लिकेशन को बनाने का तरीका बदल देता है।
अगर आप इसे भूल जाएँ और बातचीत की स्थिति सिर्फ़ फ़्रंटएंड पर रखें, तो पेज रिफ़्रेश होते ही बॉट सारी मेमोरी खो देगा। अगर आप इतिहास को बिना काटे ज़्यादा जमा करें, तो लंबे सत्रों में कॉन्टेक्स्ट सीमा तक पहुँच जाएँगे। सही तरीका यह है कि सर्वर-साइड सेशन स्टोर हो जो संदेशों की सूची को सहेजे, उसे समझदारी से काटे, और हर कॉल पर मॉडल को सही हिस्सा भेजे।
आप जो मॉडल चुनते हैं, वही तय करता है कि आपके चैटबॉट की क्षमता की सीमा कहाँ तक जाएगी। कोई एक सही उत्तर नहीं है, लेकिन कुछ साफ़ ट्रेड-ऑफ़ हैं जिन्हें किसी इन्फ़्रास्ट्रक्चर की दिशा तय करने से पहले समझना ज़रूरी है।
| ओपन-सोर्स | प्रोप्राइटरी | |
|---|---|---|
| लागत | मुफ़्त या सस्ती होस्टिंग | प्रति टोकन भुगतान |
| प्राइवेसी | डेटा आपके सर्वर पर रहता है | डेटा प्रदाता तक भेजा जाता है |
| परफ़ॉर्मेंस | मॉडल के आकार पर निर्भर | आम तौर पर ज़्यादा मज़बूत |
| कंट्रोल | फ़ुल फाइन-ट्यूनिंग की पहुँच | सिर्फ़ API |
| सेटअप समय | इन्फ़्रास्ट्रक्चर चाहिए | कुछ ही मिनटों में तैयार |
प्रोटोटाइप के लिए प्रोप्राइटरी मॉडल रफ़्तार में जीतते हैं। GPT-5 और Claude 4 Sonnet आपको जल्दी काम करने वाला डेमो दे देते हैं। सख़्त प्राइवेसी ज़रूरतों या बहुत ज़्यादा वॉल्यूम वाले प्रोडक्शन के लिए, Llama 4 Maverick Instruct या Mistral 7B v0.1 जैसे मॉडल, जो आपके अपने इन्फ़्रास्ट्रक्चर पर चलें, लागत काफ़ी कम कर देते हैं।
चैटबॉट तीन चीज़ों का मेल है: एक मैसेज स्टोर, एक सिस्टम प्रॉम्प्ट, और एक API कॉल। ये तीनों सही हों तो बाकी सब पॉलिश है।
सिस्टम प्रॉम्प्ट आपके चैटबॉट की पर्सनैलिटी और उसके संचालन के नियम हैं। यह हर बातचीत से पहले चलता है और सभी जवाबों के लिए फ़्रेम तय करता है। चैटबॉट प्रोजेक्ट अक्सर यहीं सफल या असफल होते हैं।
एक कमज़ोर सिस्टम प्रॉम्प्ट: "You are a helpful assistant."
एक मज़बूत सिस्टम प्रॉम्प्ट:
You are a customer support agent for a SaaS product called Orbit.
You only answer questions about Orbit's features, pricing, and troubleshooting.
If a user asks about something outside Orbit, politely redirect them.
Keep responses under 150 words unless the user explicitly asks for more detail.
Never make up pricing figures. If you do not know the answer, say so clearly
and offer to escalate to a human agent.
फ़र्क स्पेसिफ़िसिटी का है। मॉडल को बाधाएँ चाहिए, सिर्फ़ एक भूमिका नहीं। बाधाएँ लगातार और अनुमानित व्यवहार देती हैं। धुंधली भूमिकाएँ धुंधले नतीजे देती हैं।
💡 अपने सिस्टम प्रॉम्प्ट का टेस्ट करें: बॉट से वे काम करवाने की कोशिश करें जिन्हें उसे मना करना चाहिए। जो प्रॉम्प्ट विरोधी इनपुट के सामने टिके, वह प्रोडक्शन में भी टिकेगा।
सिस्टम प्रॉम्प्ट को ऐसे लिखें जैसे किसी बहुत शाब्दिक कर्मचारी के लिए नौकरी का विवरण लिख रहे हों, जो बस वही करता है जो आप कहते हैं और उससे आगे कुछ नहीं। हर वाक्य जो कोई बाधा जोड़ता है, वह अनिश्चितता कम करता है।
आपका मैसेज स्टोर ऐसी वस्तुओं की सूची है, जिनमें से हर एक की एक भूमिका (system, user, या assistant) और कंटेंट होता है। एक सामान्य बातचीत कुछ ऐसी दिखती है:
messages = [
{"role": "system", "content": "You are a helpful support agent..."},
{"role": "user", "content": "How do I reset my password?"},
{"role": "assistant", "content": "To reset your password, click..."},
{"role": "user", "content": "I do not see that button anywhere."},
]
हर नया यूज़र संदेश और हर असिस्टेंट जवाब आप इस सूची में जोड़ते हैं। हर API कॉल पर पूरी सूची भेजते हैं। मॉडल पूरी बातचीत पढ़ता है और संदर्भ में अगला जवाब बनाता है।
ट्रिमिंग रणनीति: जब सूची बड़ी हो जाए, तो कॉन्टेक्स्ट विंडो की गलतियों से बचने के लिए भेजने से पहले उसे काटें। तीन विकल्प हैं:
स्लाइडिंग विंडो लागू करने में सबसे आसान है और ज़्यादातर उपयोग मामलों में काम करती है। सारांश सबसे ज़्यादा संदर्भ बचाता है, लेकिन इसमें अतिरिक्त API कॉल और देरी लगती है।
टेम्परेचर रैंडमनेस को नियंत्रित करता है। 0.0 पर जवाब निर्धारित और अक्सर दोहराव वाले होते हैं। 1.0 पर वे रचनात्मक होते हैं, पर विषय से भटकने की संभावना रहती है। ज़्यादातर चैटबॉट के लिए सही दायरा 0.3 से 0.7 है।
| पैरामीटर | क्या नियंत्रित करता है | आम मान |
|---|---|---|
temperature | रैंडमनेस और रचनात्मकता | 0.3 से 0.7 |
max_tokens | जवाब की लंबाई की सख़्त सीमा | 512 से 2048 |
top_p | टोकन सैंपलिंग की चौड़ाई | 0.9 |
frequency_penalty | दोहराए गए वाक्यांशों पर दंड | 0.1 से 0.3 |
असली कोड ज़्यादातर ट्यूटोरियल के सुझाव से सरल है। यहाँ OpenAI क्लाइंट का उपयोग करके एक न्यूनतम काम करने वाला इम्प्लीमेंटेशन है, जो ज़्यादातर LLM प्रदाताओं के साथ काम करता है।
pip install openai
from openai import OpenAI
client = OpenAI(api_key="your-api-key-here")
लोकल API (जैसे Ollama या LM Studio) के ज़रिए चलने वाले ओपन-सोर्स मॉडल के लिए आप base_url पैरामीटर बदलते हैं। बाकी कोड वही रहता है, और यही OpenAI-कम्पैटिबल API मानक का एक असली फ़ायदा है, जिसे ज़्यादातर प्रदाता अपना चुके हैं।
class Chatbot:
def __init__(self, system_prompt: str, max_turns: int = 20):
self.system_prompt = system_prompt
self.max_turns = max_turns
self.history = []
def chat(self, user_message: str) -> str:
self.history.append({"role": "user", "content": user_message})
# Keep only the last N turns to avoid context overflow
recent = self.history[-(self.max_turns * 2):]
messages = [
{"role": "system", "content": self.system_prompt}
] + recent
response = client.chat.completions.create(
model="gpt-5",
messages=messages,
temperature=0.5,
max_tokens=1024,
)
reply = response.choices[0].message.content
self.history.append({"role": "assistant", "content": reply})
return reply
यह मुख्य लूप है। हर प्रोडक्शन चैटबॉट इसी पैटर्न का एक रूप है, जिसके ऊपर अतिरिक्त लॉजिक जुड़ा होता है।
जब यूज़र देखते हैं कि टेक्स्ट असली समय में आ रहा है, तो वे जवाब का इंतज़ार बहुत बेहतर झेलते हैं। स्ट्रीमिंग हर बड़े LLM API में पहले से मौजूद है और पहले दिन से लागू करने लायक है:
stream = client.chat.completions.create(
model="gpt-5",
messages=messages,
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].delta.content
if delta:
print(delta, end="", flush=True)
Server-Sent Events (SSE) या WebSockets के ज़रिए जवाब को फ़्रंटएंड पर स्ट्रीम करें। महसूस होने वाली देरी कई सेकंड से घटकर लगभग तुरंत हो जाती है, और यूज़र पूरे जवाब का इंतज़ार करने के मुकाबले स्ट्रीम किए गए जवाबों से कहीं ज़्यादा संतुष्ट होने की बात करते हैं।
PicassoIA 65+ लार्ज लैंग्वेज मॉडल सीधे ब्राउज़र में उपलब्ध कराता है, बिना API सेटअप, बिलिंग कॉन्फ़िगरेशन या किसी इन्फ़्रास्ट्रक्चर के। इससे एक भी लाइन कोड लिखने से पहले अपने सिस्टम प्रॉम्प्ट और चैटबॉट लॉजिक को टेस्ट करना व्यावहारिक हो जाता है।
PicassoIA पर Large Language Models सेक्शन में जाएँ। वहाँ हर बड़ा मॉडल परिवार मिलेगा: OpenAI के GPT-5 और GPT-4o, Anthropic का Claude 4 Sonnet, Google का Gemini 2.5 Flash, Meta का Llama 4 Maverick Instruct, और DeepSeek R1 तथा Kimi K2 Instruct जैसे रीज़निंग विशेषज्ञ।
💡 जब आपके चैटबॉट को कोड लिखना या उसकी समीक्षा करनी हो, तब Kimi K2 Instruct इस्तेमाल करें। जब उसे बहु-चरणीय समस्याओं पर क्रम से तर्क करना हो, तब DeepSeek R1 इस्तेमाल करें।
प्रोडक्शन चैटबॉट में सबसे बड़ी विफलता यह है कि बिना हैंडलिंग कोड के कॉन्टेक्स्ट विंडो की सीमा तक पहुँच जाना। ऐसा होने पर API context_length_exceeded एरर फेंकता है, और आपका चैटबॉट क्रैश हो जाता है या एक सामान्य एरर पेज लौटाता है। शिप करने से पहले हमेशा ट्रिम या सारांश की रणनीति लागू करें।
सरल नियम: अगर टोकन गिनती के आधार पर आपकी बातचीत की हिस्ट्री मॉडल की कॉन्टेक्स्ट सीमा के 80% के करीब पहुँच रही है, तो हिस्ट्री सूची से सबसे पुराने गैर-सिस्टम संदेश हटाना शुरू करें।
tiktoken जैसी लाइब्रेरी (OpenAI मॉडल के लिए) हर API कॉल से पहले टोकन सटीक रूप से गिनने देती हैं। उनका इस्तेमाल करें।
धुंधले निर्देश धुंधला व्यवहार पैदा करते हैं। इनसे बचने के तीन पैटर्न:
"Be helpful and friendly." इससे मॉडल को यह पता नहीं चलता कि उसे क्या करना चाहिए या क्या नहीं करना चाहिए।बड़े पैमाने पर हर अनावश्यक टोकन का खर्च बढ़ाता है। जो सिस्टम प्रॉम्प्ट ज़रूरत से 800 टोकन लंबा है, वह हर एक API कॉल पर उन 800 टोकन का खर्च आता है। 10,000 दैनिक बातचीत पर यह हर दिन 80 लाख अतिरिक्त इनपुट टोकन होते हैं, जिनका बिल मॉडल की इनपुट दर पर बनता है। लॉन्च से पहले अपने सिस्टम प्रॉम्प्ट का सख़्ती से ऑडिट करें और हर अनावश्यक या बहुत लंबे निर्देश हटा दें।
हर LLM API की रेट लिमिट होती है: प्रति मिनट अनुरोध, प्रति मिनट टोकन, और कुछ मामलों में दैनिक सीमा। लॉन्च से पहले इनके लिए योजना बनाएँ। कम ट्रैफ़िक पर गुणवत्ता और रफ़्तार के लिए प्रोप्राइटरी API सही विकल्प हैं। ज़्यादा ट्रैफ़िक पर, Llama 4 Maverick Instruct जैसे ओपन-सोर्स मॉडल को खुद होस्ट करना अक्सर काफ़ी सस्ता पड़ता है।
10,000 दैनिक बातचीत वाले चैटबॉट के लिए, जिसमें हर बातचीत का औसत 500 आउटपुट टोकन हो, मोटी लागत तुलना:
| मॉडल | लगभग लागत प्रति 1M आउटपुट टोकन | दैनिक आउटपुट लागत |
|---|---|---|
| GPT-4o | ~$15 | ~$75 |
| GPT-4o Mini | ~$0.60 | ~$3 |
| Claude 4 Sonnet | ~$15 | ~$75 |
| Llama 4 (self-hosted) | केवल इन्फ़्रास्ट्रक्चर | परिवर्तनशील |
जिन हाई-वॉल्यूम उपयोग मामलों में GPT-4o की पूरी क्षमता ज़रूरी नहीं है, वहाँ GPT-4o Mini को गंभीरता से परखना चाहिए। FAQ का जवाब देने या सरल रूटिंग जैसे कई चैटबॉट कार्यों को फ़्रंटियर मॉडल की ज़रूरत नहीं होती।
शिप करना अंत नहीं है। आपको यह देखने की ज़रूरत है कि आपका बॉट असली यूज़र्स से वास्तव में क्या कह रहा है। कम से कम, हर बातचीत के टर्न को इन चीज़ों के साथ लॉग करें:
पहले हफ़्ते में हर दिन बातचीत का एक रैंडम सैंपल देखें। आपको प्रॉम्प्ट की विफलताएँ, हैलुसिनेशन और वे किनारे के मामले मिलेंगे जो टेस्टिंग के दौरान सामने नहीं आए।
💡 रिव्यू ट्रिगर सेट करें: अगर कोई यूज़र "यह गलत है" या "आपने यह गढ़ा है" जैसा वाक्यांश भेजे, तो उस बातचीत को तुरंत मैन्युअल रिव्यू के लिए फ़्लैग करें।
एक बार आपका चैटबॉट काम करने लगे और डिप्लॉय हो जाए, तो ये तीन जोड़ इसे डेमो से प्रोडक्ट बनाते हैं:
1. Retrieval Augmented Generation (RAG): अपने बॉट को अपने दस्तावेज़ों के वेक्टर डेटाबेस से जोड़ें। मॉडल के ट्रेनिंग डेटा पर निर्भर रहने के बजाय, वह प्रासंगिक अंश खोजता है और जवाब बनाने से पहले उन्हें कॉन्टेक्स्ट के रूप में इस्तेमाल करता है। इसी तरीके से आप ऐसा चैटबॉट बनाते हैं जो आपके प्रोडक्ट, आंतरिक नीतियों या ज्ञान आधार के बारे में सवालों का सटीक जवाब देता है, बिना विवरण गढ़े।
2. गार्डरेल्स: एक सेकंडरी जाँच जोड़ें जो यूज़र के इनपुट और बॉट के आउटपुट, दोनों को, कुछ भी यूज़र तक पहुँचने से पहले जाँचे। इससे प्रॉम्प्ट इंजेक्शन की कोशिशें, पॉलिसी उल्लंघन और विषय से बाहर के जवाब दर्शकों तक पहुँचने से पहले पकड़े जाते हैं। एक सरल नियम-परत या एक दूसरी हल्की मॉडल कॉल ज़्यादातर मामलों को संभाल लेती है।
3. इवैल्यूएशन सूट: अपने चैटबॉट के मुख्य उपयोग मामलों को कवर करने वाले 50-100 इनपुट/अपेक्षित आउटपुट जोड़ियों का टेस्ट सेट लिखें। हर सिस्टम प्रॉम्प्ट बदलाव के बाद इसे अपने आप चलाएँ। यूज़र्स के सामने आने से पहले रिग्रेशन पकड़ने का यही एकमात्र भरोसेमंद तरीका है। इतने पैमाने पर मैन्युअल टेस्टिंग पहले हफ़्ते के बाद व्यावहारिक नहीं रहती।
आर्किटेक्चर साफ़ है। कोड जटिल नहीं है। जो चैटबॉट डेमो में लोगों को प्रभावित करता है और जो प्रोडक्शन में भरोसेमंद ढंग से चलता है, उनमें अंतर दोहराव (iteration) का है। ख़ास तौर पर सिस्टम प्रॉम्प्ट, ट्रिमिंग रणनीति, मॉडल चुनाव और मॉनिटरिंग सेटअप पर दोहराव, जो असली बातचीत के डेटा से चलता है।
इस दोहराव के लिए पहले कोड लिखना ज़रूरी नहीं है। सबसे मूल्यवान हिस्सा, यानी सही मॉडल और ऐसा सिस्टम प्रॉम्प्ट खोजना जो सचमुच टिके, आप IDE खोलने से पहले ब्राउज़र में कर सकते हैं।
PicassoIA आपको ब्राउज़र में 65+ लार्ज लैंग्वेज मॉडल की सीधी पहुँच देता है, जिनमें GPT-5, Claude 4 Sonnet, Llama 4 Maverick Instruct, Kimi K2 Instruct, DeepSeek R1 और Gemini 2.5 Flash शामिल हैं।
सिस्टम प्रॉम्प्ट लिखें। मॉडल चुनें। देखें कि वह असल में कैसे जवाब देता है। किनारे के मामले टेस्ट करें। जानबूझकर उसे तोड़ने की कोशिश करें। फिर सुधारें। असली चैटबॉट की गुणवत्ता इसी दोहराव के चक्र में बनती है, और किसी एक भी API कॉल या लाइन कोड पर पैसा लगाने से पहले आप पूरी प्रक्रिया PicassoIA पर चला सकते हैं।
मॉडल तैयार हैं। आपका चैटबॉट अपने आप तो बनेगा नहीं।
अपनी भाषा चुनें
