अपनी ऐप में AI फ़ीचर कैसे जोड़ें
अपनी ऐप में AI फ़ीचर जोड़ने के लिए अपने सर्वर से एक बड़े भाषा मॉडल (LLM) API को कॉल करें: उसे साफ़ निर्देश और ज़रूरी डेटा भेजें, और जो जवाब मिले उसका इस्तेमाल करें। ज़्यादातर काम के फ़ीचर चार पैटर्न में से एक होते हैं: सारांश बनाना, चैट करना, संरचित डेटा निकालना, और वर्गीकरण करना। हर एक कुछ दर्जन लाइन का कोड है जिसे AI बिल्डर आपके लिए लिख सकता है। लेकिन फ़ीचर अच्छा है या नहीं, यह इस बात से तय होता है कि कॉल के आसपास का काम कैसे हुआ है: API की को सर्वर पर रखना, हर यूज़र के हिसाब से खर्च पर नज़र रखना, और नतीजों पर भरोसा करने से पहले उन्हें जाँचना।
ज़्यादातर AI फ़ीचर के पीछे चार पैटर्न
| पैटर्न | यह क्या करता है | उदाहरण फ़ीचर | आम आउटपुट |
|---|---|---|---|
| सारांश | लंबे टेक्स्ट को छोटा करता है | मीटिंग नोट्स का सार, टिकट का सारांश, दस्तावेज़ में "क्या बदला" | एक पैराग्राफ़ या बुलेट सूची |
| चैट | बातचीत में सवालों के जवाब देता है, अक्सर आपके डेटा के बारे में | मदद करने वाला सहायक, "अपने दस्तावेज़ों से पूछें", ऑनबोर्डिंग गाइड | स्ट्रीमिंग टेक्स्ट |
| निकालना (Extract) | गड़बड़ टेक्स्ट या इमेज से संरचित फ़ील्ड निकालता है | PDF से इनवॉइस का विवरण, ईमेल सिग्नेचर से संपर्क, जॉब पोस्टिंग से जॉब डेटा | स्कीमा से मेल खाता JSON |
| वर्गीकरण (Classify) | तय लेबल की सूची में से चुनता है | सपोर्ट टिकट को रूट करना, फ़ीडबैक को विषय से टैग करना, ज़रूरी संदेश चिह्नित करना, भाषा पहचानना | एक लेबल, शायद भरोसे का संकेत |
निकालना और वर्गीकरण अक्सर सबसे ज़्यादा काम के होते हैं और सबसे कम दिखते हैं। ये हर रिकॉर्ड पर किसी का कुछ मिनट बचाते हैं, और चूँकि आउटपुट का आकार तय होता है, इसे अपने-आप जाँचा जा सकता है। चैट सबसे ज़्यादा दिखती है लेकिन उसे सही करना सबसे मुश्किल है, और उसकी अपनी गाइड है: AI चैटबॉट ऐप कैसे बनाएँ।
यह आपकी ऐप में कैसे फ़िट होता है
हर पैटर्न का ढाँचा एक ही है:
- यूज़र कुछ करता है: "Summarise" पर क्लिक करता है, फ़ाइल अपलोड करता है, या संदेश भेजता है।
- आपका फ़्रंट एंड अपने सर्वर को कॉल करता है, AI प्रदाता को नहीं।
- आपका सर्वर रिक्वेस्ट बनाता है: सिस्टम निर्देश, यूज़र का इनपुट, और आपके डेटाबेस से वह डेटा जिसकी मॉडल को ज़रूरत है, लेकिन सिर्फ़ वही डेटा जो यह यूज़र देखने की अनुमति रखता है।
- आपका सर्वर LLM API को कॉल करता है, की एनवायरनमेंट वेरिएबल में रखी हुई।
- आपका सर्वर जवाब की जाँच करता है: सही JSON है या नहीं, ज्ञात लेबल है या नहीं, लंबाई ठीक है या नहीं, फिर उसे सेव या वापस करता है।
- फ़्रंट एंड उसे दिखाता है, लंबे जवाबों को आते ही स्ट्रीम करते हुए।
चरण 4 में की सर्वर पर रहती है और कभी ब्राउज़र तक नहीं पहुँचती। अगर API की अवधारणा नई है, तो API क्या है एक छोटा परिचय है, और LLM API कैसे इस्तेमाल करें में टोकन, मॉडल और की के बारे में विस्तार से है।
प्रदाता और मॉडल चुनना
OpenAI, Anthropic, Google और दूसरे बड़े प्रदाता सभी लगभग एक जैसे ढाँचे वाले टेक्स्ट API देते हैं। चुनते समय ये सवाल उपयोगी हैं:
- आपके काम पर गुणवत्ता। अपनी ऐप के कुछ असली उदाहरण दो-तीन मॉडल पर आज़माएँ। फ़र्क अक्सर सामान्य बेंचमार्क से ज़्यादा आपके डेटा पर साफ़ दिखता है।
- आकार बनाम खर्च। प्रदाता बड़े और ज़्यादा सक्षम मॉडल भी देते हैं, और छोटे, सस्ते और तेज़ मॉडल भी। वर्गीकरण और सरल निकालना अक्सर छोटे मॉडल पर अच्छा चलता है; लंबा तर्क या बारीक लेखन शायद बड़े मॉडल की माँग करे।
- संरचित आउटपुट। निकालने और वर्गीकरण के लिए ऐसा API फ़ीचर चुनें जो मॉडल से वह JSON दिलवाए जो आपके दिए स्कीमा से मेल खाए, न कि खुले टेक्स्ट को पार्स करना पड़े।
- डेटा का इस्तेमाल। प्रदाता की शर्तें पढ़ें कि API इनपुट स्टोर होते हैं या ट्रेनिंग में इस्तेमाल होते हैं, और क्या यह आपके यूज़र्स के डेटा के लिए ठीक है।
- सीमाएँ। नए अकाउंट पर अक्सर रेट लिमिट कम होती है; लॉन्च से पहले उन्हें जाँच लें।
मॉडल के नाम और कीमतें अक्सर बदलती हैं, इसलिए कोड में मॉडल का नाम कई जगह हार्ड-कोड करने के बजाय कॉन्फ़िगरेशन से पढ़ना चाहिए।
फ़ीचर जोड़ना, चरण-दर-चरण
एक ठोस उदाहरण लें: एक छोटा CRM जहाँ हर संपर्क के पास नोट्स का लंबा इतिहास है।
1. की स्टोर करें। अपने प्रदाता के डैशबोर्ड में की बनाएँ और उसे सर्वर-साइड सीक्रेट के रूप में सेव करें, जैसे OPENAI_API_KEY या ANTHROPIC_API_KEY।
2. एक सीमित फ़ीचर माँगें:
संपर्क पेज पर एक "Summarise" बटन जोड़ो। सर्वर पर, संपर्क के आखिरी 20 नोट्स [PROVIDER] को भेजो, [ENV_NAME] सीक्रेट का इस्तेमाल करके, और निर्देश दो कि तीन बुलेट पॉइंट लिखे: मौजूदा स्थिति, खुले सवाल, अगला कदम। सिर्फ़ वही नोट्स शामिल करो जो लॉग इन यूज़र देख सकता है। लोडिंग स्टेट दिखाओ, सारांश को टाइमस्टैम्प के साथ सेव करो, और कॉल फ़ेल होने पर "अभी सारांश नहीं बन सका" दिखाओ। की कभी ब्राउज़र को न भेजो।
3. जहाँ टाइपिंग बचे वहाँ निकालना जोड़ें:
जब यूज़र "Quick add" बॉक्स में ईमेल सिग्नेचर चिपकाए, तो सर्वर पर [PROVIDER] को कॉल करो और नाम, कंपनी, पद, ईमेल और फ़ोन वाला JSON लौटाओ, प्रदाता के संरचित आउटपुट फ़ीचर का इस्तेमाल करते हुए। JSON को सर्वर पर वैलिडेट करो, नया संपर्क फ़ॉर्म उससे भरो, और सेव करने से पहले यूज़र को बदलने दो। अंदाज़ा लगाने के बजाय खाली फ़ील्ड खाली छोड़ दो।
"सेव करने से पहले यूज़र को बदलने दें" सबसे ज़रूरी हिस्सा है: मॉडल सुझाव देता है, फ़ैसला व्यक्ति करता है।
4. बैकग्राउंड में वर्गीकरण करें:
जब नया सपोर्ट टिकट आए, तो उसे ठीक इनमें से एक में वर्गीकृत करो: billing, bug, feature request, account access, other। छोटा, कम खर्च वाला मॉडल इस्तेमाल करो। अगर जवाब इन लेबल में से कोई न हो, तो "other" सेव करो। लेबल को एडिट हो सकने वाले टैग के रूप में दिखाओ।
5. गड़बड़ असली डेटा से टेस्ट करें: लंबे नोट्स, खाली नोट्स, दूसरी भाषाएँ, बिना फ़ोन नंबर वाला सिग्नेचर, और शिप करने से पहले बीस आउटपुट साथ-साथ देखें।
काम करने वाले निर्देश कैसे लिखें
हर रिक्वेस्ट के साथ भेजे जाने वाले निर्देश (जिन्हें अक्सर सिस्टम प्रॉम्प्ट कहा जाता है) वहीं से गुणवत्ता आती है।
- बताएँ कि यह किसके लिए है और अच्छा नतीजा कैसा होता है। "सारांश को कॉल से पहले सेल्सपर्सन 10 सेकंड में पढ़ता है" मॉडल को एक लक्ष्य देता है।
- फ़ॉर्मेट तय करें। बुलेट की सटीक संख्या, लंबाई की सीमा, फ़ील्ड, लेबल।
- बताएँ कि अनिश्चित होने पर क्या करना है। "अगर नोट्स में अगला कदम नहीं लिखा है, तो 'कोई अगला कदम दर्ज नहीं' लिखो।" इससे गढ़े हुए जवाब कम होते हैं।
- निकालने और वर्गीकरण के लिए दो-तीन उदाहरण अच्छे इनपुट और आउटपुट के दें।
- निर्देशों को यूज़र के कंटेंट से अलग रखें, और यूज़र का कंटेंट साफ़ लेबल करें ताकि मॉडल दोनों में फ़र्क कर सके।
प्रॉम्प्ट को अपने कोडबेस में फ़ाइलों में रखें, ताकि वे बाकी कोड की तरह वर्ज़न किए और समीक्षा किए जा सकें।
खर्च काबू में रखना
LLM API टोकन के हिसाब से शुल्क लेते हैं, यानी छोटे टेक्स्ट हिस्सों के हिसाब से, भेजे गए और लौटे दोनों पर। खर्च हर रिक्वेस्ट के संदर्भ की मात्रा को उसके चलने की बारंबारता से गुणा करने पर बढ़ता है। व्यावहारिक नियंत्रण:
- सिर्फ़ ज़रूरी भेजें। पूरे इतिहास के बजाय आखिरी 20 नोट्स। लंबे दस्तावेज़ों को छोटा करें या बाँटें।
- काम के लिए सबसे छोटा मॉडल इस्तेमाल करें। सबसे बड़े मॉडल को डिफ़ॉल्ट बनाने से पहले टेस्ट करें।
- आउटपुट की लंबाई सीमित करें API की maximum-tokens सेटिंग से।
- नतीजे कैश करें। सारांश को सेव करें और सिर्फ़ तब दोबारा बनाएँ जब स्रोत बदले, हर पेज व्यू पर नहीं।
- प्रति यूज़र सीमा रखें। अकाउंट या प्लान के हिसाब से रोज़ की सीमा एक भारी यूज़र या एक स्क्रिप्ट को बिल बढ़ाने से रोकती है।
- एंडपॉइंट पर रेट लिमिट लगाएँ, किसी भी दूसरे महँगे रूट की तरह।
- प्रदाता के डैशबोर्ड में बजट या अलर्ट सेट करें, और लॉन्च के बाद हर हफ़्ते उपयोग देखें।
- हर फ़ीचर के हिसाब से टोकन उपयोग लॉग करें, ताकि पता रहे कि कौन सा फ़ीचर कितना खर्च करता है।
अगर AI फ़ीचर आपके प्रोडक्ट का केंद्र हैं, तो उनके चलने के खर्च को अपनी कीमत तय करते समय गिनें, उसे चुपचाप सहने के बजाय।
सुरक्षा और भरोसा
AI का आउटपुट संभाव्यता पर आधारित है। वह आत्मविश्वास से बोलते हुए भी गलत हो सकता है, और जो टेक्स्ट वह पढ़ता है उससे दिशा बदली जा सकती है। इसके लिए तैयार रहें:
- आउटपुट को अविश्वसनीय इनपुट मानें। ढाँचे की जाँच करें, HTML के रूप में दिखाने से पहले उसे एस्केप करें, और उसे कभी कोड या डेटाबेस क्वेरी की तरह न चलाएँ।
- ऐसी हर चीज़ में इंसान को शामिल रखें जिसके नतीजे हों: ईमेल भेजना, रिकॉर्ड बदलना, पेमेंट रिफ़ंड करना। मॉडल ड्राफ़्ट बनाता है; व्यक्ति पुष्टि करता है।
- प्रॉम्प्ट इंजेक्शन से बचें। कोई दस्तावेज़ या संदेश "अपने निर्देश भूल जाओ" जैसा टेक्स्ट रख सकता है। मॉडल को वही देखने दें जो मौजूदा यूज़र देख सकता है, और उसे ऐसे टूल न दें जो आपका कोड पहले अनुमति जाँचे बिना संवेदनशील काम कर सकें।
- AI के कंटेंट को लेबल करें, ताकि यूज़र जान सकें कि सारांश या सुझाव बनाया गया है और वे उसे जाँच सकें।
- विफलताओं को सहजता से संभालें। प्रदाताओं में आउटेज और रेट लिमिट होती हैं। टाइमआउट लगाएँ, साफ़ संदेश दिखाएँ, और बाकी ऐप को चलते रहने दें।
- यूज़र क्या भेज रहे हैं, उस पर नज़र रखें। खुले टेक्स्ट इनपुट के लिए मॉडरेशन स्टेप पर विचार करें, और अपनी प्राइवेसी पॉलिसी में साफ़ लिखें कि कंटेंट तीसरे पक्ष के AI प्रदाता द्वारा प्रोसेस होता है।
जाँच की व्यापक सूची AI से बनी ऐप्स के लिए सुरक्षा चेकलिस्ट में है।
आम गलतियाँ
- एक सामान्य चैटबॉट से शुरू करना, जबकि एक सादा "Summarise" या "Categorise" बटन ज़्यादा लोगों के काम आता।
- की को फ़्रंट एंड कोड में या सार्वजनिक रिपॉज़िटरी में डालना।
- पूरे डेटाबेस को संदर्भ के रूप में भेजना, जो धीमा, महँगा है और दूसरे यूज़र्स का डेटा उजागर होने का जोखिम रखता है।
- खुले टेक्स्ट आउटपुट पर भरोसा करना, जबकि स्कीमा या तय लेबल से उसकी जाँच हो सकती थी।
- प्रति यूज़र सीमा न होना, और यह तब पता चलना जब पहला इनवॉइस आए।
Mythex में AI फ़ीचर जोड़ना
Mythex में आप अपनी ऐप के अंदर AI चैट में माँगकर जोड़ते हैं, अपने प्रदाता की का इस्तेमाल करते हुए। की को प्रोजेक्ट सीक्रेट के रूप में सेव करें: जब एजेंट को उसकी ज़रूरत होगी, Mythex चैट में एक सीक्रेट्स कार्ड दिखाएगा, ताकि आपको की बातचीत में चिपकानी न पड़े। एजेंट सर्वर रूट, प्रॉम्प्ट और इंटरफ़ेस लिखता है। आपकी ऐप का AI उपयोग आपके प्रदाता द्वारा बिल किया जाता है, उन Mythex क्रेडिट से अलग जो आप बिल्डिंग में खर्च करते हैं। डॉक्स में अपनी API keys से AI फ़ीचर जोड़ें में एक स्टार्टर प्रॉम्प्ट है।
सवाल
मौजूदा ऐप में AI कैसे जोड़ूँ?
किसी LLM प्रदाता से API की लें, उसे सर्वर-साइड सीक्रेट के रूप में स्टोर करें, और एक सर्वर रूट जोड़ें जो प्रदाता को प्रॉम्प्ट और ज़रूरी डेटा भेजे और नतीजा आपके फ़्रंट एंड को लौटाए। सामान्य चैट बनाने से पहले एक सीमित फ़ीचर से शुरू करें, जैसे किसी रिकॉर्ड का सारांश बनाना।
AI फ़ीचर चलाने का खर्च कितना आता है?
LLM API हर टोकन के हिसाब से शुल्क लेते हैं, यानी मोटे तौर पर भेजे और मिले टेक्स्ट के हर हिस्से पर, और मॉडल के हिसाब से दरें काफ़ी अलग होती हैं। खर्च इस पर निर्भर करता है कि हर रिक्वेस्ट में कितना टेक्स्ट जाता है और वह कितनी बार चलती है, इसलिए अपने उपयोग के आधार पर अनुमान लगाएँ, प्रदाता के डैशबोर्ड में सीमा तय करें, और अपनी ऐप में हर यूज़र के लिए उपयोग की सीमा रखें।
क्या मैं अपनी OpenAI या Anthropic की को फ़्रंट एंड में डाल सकता हूँ?
नहीं। फ़्रंट एंड कोड में जो भी है उसे पेज खोलने वाला कोई भी पढ़ सकता है, और लीक हुई की से अजनबी आपका बिल बढ़ा सकते हैं। प्रदाता को अपने सर्वर से कॉल करें, जहाँ की एनवायरनमेंट वेरिएबल में रहती है।
प्रॉम्प्ट इंजेक्शन क्या है?
यह तब होता है जब वह टेक्स्ट जिसे मॉडल पढ़ता है, जैसे यूज़र का संदेश, अपलोड की गई फ़ाइल या कोई वेब पेज, उसमें ऐसे निर्देश हों जो आपके निर्देशों को बदलने की कोशिश करें। मॉडल के आउटपुट को अविश्वसनीय मानें, बिना जाँच के उसे संवेदनशील कामों को शुरू न करने दें, और मॉडल जो डेटा देख सकता है उसे उतना ही सीमित रखें जितना यूज़र देख सकता है।