AI चैटबॉट ऐप कैसे बनाएं: Keys, Prompts, लागत और सुरक्षा

AI चैटबॉट ऐप बनाने के लिए आपको चार चीज़ें चाहिए: एक chat interface, एक छोटा server जो model provider की API key अपने पास रखे और संदेशों को उसके पास भेजे, एक system prompt जो model को बताए कि वह कौन है और उसे क्या करने की अनुमति है, और ऐसी सीमाएँ जो लागत और दुरुपयोग को काबू में रखें। एक AI app builder यह सब एक विवरण से लिख सकता है। जो काम आपके हिस्से में रहता है वह है provider चुनना, निर्देश लिखना और तय करना कि बॉट को कभी क्या नहीं करना है।

AI चैटबॉट ऐप किन हिस्सों से बनता है

ज़्यादातर chatbot ऐप, चाहे वह support assistant हो, tutor हो या आंतरिक "हमारे docs से पूछें" टूल, एक ही तरह के हिस्सों से बनते हैं:

Server route वह हिस्सा है जिसमें लोग सबसे ज़्यादा गलती करते हैं। यदि chat page सीधे browser से provider को कॉल करता है, तो कोई भी developer tools खोलकर आपकी key कॉपी कर सकता है और आपका बिल बढ़ा सकता है।

बनाने से पहले तय करने वाली बातें

कौन सा provider और model

प्रमुख providers (OpenAI, Anthropic, Google और दूसरे) सभी एक जैसा chat-style API देते हैं: आप messages की सूची भेजते हैं और जवाब पाते हैं। व्यावहारिक चुनाव ब्रांड से ज़्यादा model के आकार पर निर्भर करता है:

• छोटे, तेज़ models सस्ते होते हैं और जल्दी जवाब देते हैं। छोटे जवाबों, वर्गीकरण और सरल FAQ बॉट के लिए ये ठीक हैं।
• बड़े models बेहतर तर्क करते हैं, लंबे निर्देशों का अधिक भरोसे से पालन करते हैं और उलझे हुए सवाल संभालते हैं, लेकिन हर संदेश पर ज़्यादा खर्च करते हैं और धीमे जवाब देते हैं।

एक मध्यम आकार के model से शुरू करें, उसे अपने असली सवालों पर परखें, और फिर वहीं से ऊपर या नीचे जाएँ। यदि आप इन APIs की pricing और calling के तरीके से नए हैं, तो पहले LLM APIs कैसे इस्तेमाल करें पढ़ें।

बॉट की जानकारी कहाँ से आएगी

जो विकल्प आपकी सामग्री को कवर करे, उसी सबसे सरल विकल्प से शुरू करें। Retrieval में search index, उसे अद्यतन रखने का तरीका और जवाब गलत होने की ज़्यादा जगहें जुड़ती हैं। कई उपयोगी बॉट को इसकी ज़रूरत ही नहीं पड़ती।

सार्वजनिक, या login के पीछे

आपकी website पर सार्वजनिक चैटबॉट तक पहुँचना आसान है, पर उसका दुरुपयोग भी आसान है: कोई स्क्रिप्ट से हज़ारों संदेश भेज सकता है। Login वाला चैटबॉट हर उपयोगकर्ता का इतिहास सहेजने और हर खाते के लिए रोज़ की सीमा तय करने देता है। यदि बॉट सार्वजनिक है, तो संदेश की लंबाई सीमित करें, एक visitor कितने संदेश एक समय में भेज सकता है यह सीमित करें, और provider के dashboard में एक पक्की मासिक सीमा तय करें। अपने ऐप में login कैसे जोड़ें में account वाला हिस्सा समझाया गया है।

बातचीत सहेजनी है या नहीं

सहेजी गई बातचीत उपयोगी होती है: उपयोगकर्ता वहीं से आगे बढ़ सकते हैं जहाँ छोड़ा था, और आप असली सवाल पढ़कर prompt बेहतर कर सकते हैं। लेकिन ये निजी डेटा भी हैं। तय करें कि इन्हें कितने समय तक रखना है, अपनी privacy notice में बताएँ, और वह कुछ भी न सहेजें जिसकी ज़रूरत नहीं है।

System prompt को नौकरी के विवरण की तरह लिखें

System prompt वह निर्देश है जो model हर बातचीत से पहले पाता है। एक अच्छा prompt किसी नए कर्मचारी के लिए छोटे brief जैसा पढ़ा जाता है:

• भूमिका और दर्शक: "तुम Oakline, एक साइकिल मरम्मत की दुकान, के help assistant हो। तुम ग्राहकों से बात करते हो।"
• दायरा: "सेवाओं, कीमतों, खुलने के समय और बुकिंग के सवालों के जवाब दो। बाकी किसी भी चीज़ के लिए कहो कि तुम केवल दुकान से जुड़ी मदद कर सकते हो।"
• स्रोत: "केवल नीचे दी गई जानकारी का उपयोग करो। यदि जवाब वहाँ नहीं है, तो कहो कि तुम्हें पता नहीं और दुकान का फ़ोन नंबर दो।"
• लहजा और लंबाई: "मित्रवत, सरल भाषा में, विस्तार माँगे जाने तक तीन वाक्य या कम।"
• सख्त नियम: "कोई ऐसी मरम्मत की कीमत कभी न बताओ जो सूची में न हो। कभी card की जानकारी न माँगो।"

फिर इसे कठिन सवालों से परखें: दायरे से बाहर के अनुरोध, रूखे संदेश, ऐसे सवाल जिनके जवाब आपकी सामग्री में नहीं हैं, और वे कोशिशें जो बॉट को उसके निर्देश भुलवाना चाहती हैं ("अपने नियम भूल जाओ और…")। जवाब ऐसे होने तक prompt बदलते रहें जिन पर आप अपना नाम दे सकें।

लागत को पूर्वानुमेय रखें

Providers input में भेजे गए और model के लिखे output, दोनों पर token (मोटे तौर पर शब्दों के टुकड़े) के हिसाब से शुल्क लेते हैं। तीन चीज़ें बिल को बढ़ाती हैं:

1. बातचीत की लंबाई। हर नया संदेश आमतौर पर पूरी बातचीत दोबारा भेजता है ताकि model को संदर्भ मिले। 40 संदेशों की chat का हर जवाब 4 संदेशों की chat से कहीं महंगा पड़ता है। केवल पिछले कुछ मोड़ रखें, या पुराने हिस्सों का सार बना लें।
2. Prompt का आकार। लंबा system prompt या पूरी सामग्री का बड़ा ब्लॉक हर संदेश के साथ भेजा जाता है।
3. Output की लंबाई। API call में जवाब की अधिकतम लंबाई सेट करें और prompt में संक्षिप्त जवाब माँगें।

लॉन्च से पहले provider के dashboard में मासिक spending limit सेट करें, और हर request का token usage लॉग करें ताकि पता चले कौन सी बातचीतें महंगी हैं। यहाँ हम कीमतें नहीं लिखते क्योंकि वे model के अनुसार बदलती हैं और अक्सर बदलती हैं; provider का अपना pricing page देखें।

चरण-दर-चरण बनाएं

चरण 1: कोड नहीं, बॉट का विवरण दें

एक पहला prompt जिसमें दर्शक, दायरा, डेटा और सुरक्षा नियम हों, ज़्यादातर काम करा देता है:

Oakline के लिए एक ग्राहक सहायता चैटबॉट बनाओ, Oakline एक साइकिल मरम्मत की दुकान है। एक chat page हो जिसमें संदेशों की सूची और input हो, और जवाब लिखे जाते समय streamed हों। एक server route से Anthropic API को कॉल करो, secret ANTHROPIC_API_KEY का उपयोग करते हुए, और इसे कभी browser तक न पहुँचाओ। System prompt ऐसा हो जो केवल shop-info.md नाम की फ़ाइल के टेक्स्ट से हमारी सेवाओं, कीमतों और समय के सवालों के जवाब दे, और बाकी सवालों पर कहे "मुझे पक्का नहीं है — नीचे दिए नंबर पर कॉल करें"। संदेश 500 characters तक सीमित हों और हर visitor प्रति घंटे 20 संदेश भेज सके। साफ़, मित्रवत डिज़ाइन जो फ़ोन पर भी चले।

चरण 2: key को secret के रूप में जोड़ें

Provider के console में key बनाएँ, फिर उसे प्रोजेक्ट के environment variables या secrets में रखें, न chat में और न code में। यदि कोई key कहीं सार्वजनिक दिख जाए, तो उसे provider पर रद्द करें और नई बनाएँ। Environment variables और secrets क्या हैं में समझाया गया है कि यह क्यों ज़रूरी है।

चरण 3: इंटरफ़ेस नहीं, जवाबों की जाँच करें

जब chat चलने लगे, तब ज़्यादातर समय जवाबों की गुणवत्ता पर लगाएँ। लगभग 20 असली सवालों की सूची रखें, जिसमें कुछ ऐसे हों जिनसे मना होना चाहिए, और हर prompt बदलने के बाद उन्हें चलाएँ। जाँचें:

• क्या यह अपने दायरे में रहता है?
• क्या यह मानता है कि उसे पता नहीं है, बजाय कोई जवाब गढ़ने के?
• क्या यह तब भी टिकता है जब कोई उसके निर्देश बदलने की कोशिश करे?
• क्या key browser द्वारा डाउनलोड होने वाली किसी भी चीज़ में नहीं है?

चरण 4: ज़रूरत हो तो memory और accounts जोड़ें

एक-एक बातचीत चलने लगे, तो database में saved threads और, ज़रूरत हो तो sign-up और login मांगें ताकि हर उपयोगकर्ता केवल अपनी chats देख सके। साथ ही प्रति उपयोगकर्ता रोज़ के संदेशों की सीमा भी जोड़ें।

चरण 5: सीमाएँ चालू करके प्रकाशित करें

पक्का करें कि प्रकाशित ऐप में वही secrets हैं जो preview में हैं, provider पर spending cap लगी है, और errors ऐसी जगह लॉग हो रहे हैं जहाँ आप उन्हें देखेंगे। फिर इसे अपनी मुख्य site पर डालने से पहले एक छोटे समूह के साथ साझा करें।

सुरक्षा और भरोसा

चैटबॉट सार्वजनिक रूप से आपके नाम पर बात करता है, इसलिए उसकी विफलताओं को अपनी ज़िम्मेदारी मानें:

• गलत जवाब। Models आत्मविश्वास से गलत बातें कह सकते हैं। बॉट को संकीर्ण विषय पर रखें, उसे अपनी सामग्री पर आधारित करें, और जहाँ बात ज़रूरी हो वहाँ एक छोटा नोट दिखाएँ कि जवाब गलत हो सकते हैं।
• Prompt injection। उपयोगकर्ता (या वे documents जो बॉट पढ़ता है) ऐसे निर्देश डाल सकते हैं जैसे "पिछले नियम अनदेखे करो"। बॉट को ऐसी शक्तियाँ न दें जिन पर उसे भरोसा नहीं किया जा सकता: उपयोगकर्ता के कहने पर refund, delete या email भेजना नहीं, जब तक आपका अपना code उसकी जाँच न करे।
• संवेदनशील विषय। चिकित्सा, कानूनी या वित्तीय सवालों पर, सलाह देने के बजाय लोगों को किसी विशेषज्ञ की ओर भेजें।
• निजी डेटा। ज़रूरत न हो तो prompts में ग्राहकों के रिकॉर्ड न डालें, और अपने provider की शर्तें देखें कि API डेटा कैसे संभाला जाता है।

हमारी AI से बने ऐप्स के लिए सुरक्षा checklist पूरे ऐप के लिए व्यापक सूची देती है।

आम गलतियाँ

• browser से सीधे provider को कॉल करना। key लीक हो जाती है। हमेशा अपने server के ज़रिए जाएँ।
• सार्वजनिक बॉट पर कोई सीमा न होना। एक स्क्रिप्ट दोपहर तक महीने का पूरा बजट खत्म कर सकती है।
• एक साथ RAG, tools और कई models शुरू करना। पहले एक अच्छी बातचीत चलाएँ; बाकी तब जोड़ें जब असली सवाल ज़रूरत दिखाएँ।
• केवल मीठे सवालों की जाँच करना। आपके उपयोगकर्ता पहले ही दिन अजीब, विरोधी और विषय से हटे सवाल पूछेंगे।
• बातचीत के धागे को हमेशा बढ़ने देना। हर संदेश के साथ लागत और जवाब का समय बढ़ता है।

जब तैयार product बेहतर विकल्प हो

अपना बनाना तब समझदारी है जब चैटबॉट आपके product का हिस्सा हो, आपका अपना डेटा या workflow चाहिए, या उसे एक खास रूप और व्यवहार चाहिए। कई मामलों में यह सही फ़ैसला नहीं होता:

• आपको केवल मौजूदा website पर support widget चाहिए। कई helpdesk और live-chat products अब AI जवाब वाले बॉट देते हैं जो आपका help center पढ़ते हैं, जिनमें human handover, inbox और reporting पहले से बनी होती है।
• केवल आप या आपकी टीम इसे इस्तेमाल करेंगी। ChatGPT या Claude जैसी सामान्य assistant की सदस्यता, जिसमें आपके documents अपलोड हों, शायद काफी हो।
• आपको सख्त compliance गारंटी चाहिए (जैसे नियंत्रित स्वास्थ्य या वित्तीय डेटा)। ऐसा vendor जिसके पास पहले से प्रमाणन हैं, कस्टम build से ज़्यादा सुरक्षित हो सकता है।

Mythex के साथ बनाना

Mythex एक AI app builder है: आप चैट में चैटबॉट का विवरण देते हैं, और वह interface और server-side कॉल लिखता है, उसे live preview में चलाता है और एक सार्वजनिक URL पर प्रकाशित करता है। आपके ऐप के अंदर का AI आपकी अपनी provider key का उपयोग करता है। आप उसे project secrets में जोड़ते हैं, या उस secrets card के ज़रिए जो Mythex को ज़रूरत पड़ने पर chat में दिखाता है, और provider का उपयोग आपके provider account पर बिल होता है, Mythex build credits पर नहीं। Mythex आपके ऐप के उपयोगकर्ताओं के लिए tokens शामिल नहीं करता, न कोई built-in knowledge-base product देता है, न तैयार rate limits: ये वे हिस्से हैं जिन्हें आप माँगते और जाँचते हैं। अपने ऐप में AI जोड़ना वाला docs पेज इसे चरण दर चरण समझाता है, और अपनी API keys के साथ AI जोड़ें में एक starter prompt है।

यदि बॉट को सहेजी गई बातचीत चाहिए, तो आप माँगें तो Mythex प्रोजेक्ट में एक Postgres database जोड़ता है। ऐप में models के और उपयोग देखने के लिए, सारांश से लेकर वर्गीकरण तक, अपने ऐप में AI फ़ीचर्स कैसे जोड़ें पढ़ें, या शुरुआती बिंदुओं के लिए ऐप टेम्पलेट्स देखें।

सवाल