तुमच्या ॲपमध्ये AI फीचर्स कसे जोडायचे
तुमच्या ॲपमध्ये AI फीचर्स जोडण्यासाठी तुमच्या सर्व्हरवरून मोठ्या भाषा मॉडेलचा (LLM) API कॉल करा: त्याला स्पष्ट सूचना आणि संबंधित डेटा पाठवा, आणि जे परत येते ते वापरा. बहुतेक उपयुक्त फीचर्स चार पॅटर्नपैकी एक असतात — सारांश काढणे, चॅट, संरचित डेटा काढणे आणि वर्गीकरण — आणि प्रत्येक काही डझन ओळींचा कोड असतो, जो AI बिल्डर तुमच्यासाठी लिहू शकतो. फीचर चांगले आहे की नाही हे ठरवणारे काम त्या कॉलभोवती असते: API की सर्व्हरवर ठेवणे, प्रति वापरकर्ता खर्च नियंत्रित करणे, आणि त्यावर विश्वास ठेवण्यापूर्वी आउटपुट तपासणे.
बहुतेक AI फीचर्समागील चार पॅटर्न
| पॅटर्न | तो काय करतो | उदाहरण फीचर्स | ठराविक आउटपुट |
|---|---|---|---|
| सारांश | लांब मजकुराचे छोटा मजकूर बनवतो | मीटिंग नोट्सचा सारांश, तिकिटाचा सारांश, दस्तऐवजात "काय बदलले" | एक परिच्छेद किंवा बुलेट यादी |
| चॅट | संभाषणात प्रश्नांची उत्तरे देतो, अनेकदा तुमच्या डेटाबद्दल | मदत सहाय्यक, "तुमच्या डॉक्सना विचारा", ऑनबोर्डिंग मार्गदर्शक | स्ट्रीमिंग मजकूर |
| डेटा काढणे | गोंधळलेल्या मजकुरातून किंवा प्रतिमांमधून संरचित फील्ड्स काढतो | PDF मधील इनव्हॉइसचे तपशील, ईमेल स्वाक्षरीतून संपर्क, जॉब पोस्टिंगमधील डेटा | स्कीमाशी जुळणारा JSON |
| वर्गीकरण | निश्चित लेबल्सच्या संचातून एक निवडतो | सपोर्ट तिकिटे राउट करणे, अभिप्राय विषयानुसार टॅग करणे, तातडीचे संदेश चिन्हांकित करणे, भाषा ओळखणे | एक लेबल, कदाचित आत्मविश्वासाची नोंद |
डेटा काढणे आणि वर्गीकरण अनेकदा सर्वात मौल्यवान आणि सर्वात कमी दिसणारे असतात. ते प्रत्येक नोंदीवर कोणाचेतरी काही मिनिटे वाचवतात, आणि आउटपुटचा आकार निश्चित असल्यामुळे ते आपोआप तपासता येते. चॅट सर्वात दिसणारे पण योग्य करण्यास सर्वात कठीण आहे, आणि त्याचे स्वतःचे मार्गदर्शक आहे: AI चॅटबॉट ॲप कसे बनवायचे.
ते तुमच्या ॲपमध्ये कसे बसते
प्रत्येक पॅटर्नचा आकार सारखाच असतो:
- वापरकर्ता कृती करतो — "सारांश" वर क्लिक करतो, फाइल अपलोड करतो, संदेश पाठवतो.
- तुमचा फ्रंटएंड तुमच्या स्वतःच्या सर्व्हरला कॉल करतो, AI प्रदात्याला नव्हे.
- तुमचा सर्व्हर विनंती तयार करतो: सिस्टम सूचना, वापरकर्त्याचे इनपुट, आणि तुमच्या डेटाबेसमधून मॉडेलला लागणारा डेटा — फक्त तो डेटा जो या वापरकर्त्याला पाहण्याची परवानगी आहे.
- तुमचा सर्व्हर LLM API कॉल करतो, एन्व्हायर्नमेंट व्हेरिएबलमध्ये साठवलेल्या कीसह.
- तुमचा सर्व्हर प्रतिसाद तपासतो — वैध JSON, ओळखीचे लेबल, योग्य लांबी — आणि तो सेव्ह करतो किंवा परत करतो.
- फ्रंटएंड ते दाखवतो, मोठ्या उत्तरांसाठी येताना मजकूर स्ट्रीम करत.
पायरी 4 मध्ये की सर्व्हरवरच राहते आणि ती ब्राउझरपर्यंत कधीच पोहोचत नाही. API ही संकल्पना नवीन असल्यास, API म्हणजे काय हे छोटे प्राइमर आहे, आणि LLM API कसे वापरायचे टोकन्स, मॉडेल्स आणि कीज अधिक खोलात सांगते.
प्रदाता आणि मॉडेल निवडणे
OpenAI, Anthropic, Google आणि इतर प्रमुख प्रदाते सर्व मजकूर API देतात, ज्यांचा आकार साधारण सारखा आहे. निवड करताना उपयुक्त प्रश्न:
- तुमच्या कामावर गुणवत्ता. तुमच्या ॲपमधील काही खरी उदाहरणे दोन-तीन मॉडेल्सवर वापरून पहा. सामान्य बेंचमार्कपेक्षा तुमच्या डेटावर फरक अनेकदा अधिक स्पष्ट दिसतो.
- आकार विरुद्ध खर्च. प्रदाते मोठे, अधिक सक्षम मॉडेल्स आणि लहान, स्वस्त, वेगवान मॉडेल्स देतात. वर्गीकरण आणि सोपा डेटा काढणे अनेकदा लहान मॉडेलवर चांगले चालते; लांब तर्क किंवा सूक्ष्म लेखनाला मोठे मॉडेल लागू शकते.
- संरचित आउटपुट. डेटा काढणे आणि वर्गीकरणासाठी, मॉडेलला तुम्ही दिलेल्या स्कीमाशी जुळणारा JSON परत करायला लावणारे API फीचर वापरा, मोकळा मजकूर पार्स करण्याऐवजी.
- डेटा हाताळणी. API इनपुट साठवले जातात की प्रशिक्षणासाठी वापरले जातात याबाबतच्या प्रदात्याच्या अटी वाचा, आणि ते तुमच्या वापरकर्त्यांच्या डेटासाठी योग्य आहेत का ते तपासा.
- मर्यादा. नवीन खात्यांना अनेकदा कमी रेट मर्यादा असते; लाँचपूर्वी त्या तपासा.
मॉडेलची नावे आणि किंमती सतत बदलत असतात, म्हणून कोडने मॉडेलचे नाव अनेक ठिकाणी हार्ड-कोड न करता कॉन्फिगरेशनमधून वाचावे.
फीचर टप्प्याटप्प्याने जोडणे
एक ठोस उदाहरण घ्या: एक छोटा CRM जिथे प्रत्येक संपर्काचा नोट्सचा मोठा इतिहास आहे.
1. की साठवा. तुमच्या प्रदात्याच्या डॅशबोर्डमध्ये की तयार करा आणि ती सर्व्हर-बाजूच्या सिक्रेट म्हणून साठवा, उदाहरणार्थ OPENAI_API_KEY किंवा ANTHROPIC_API_KEY.
2. एक छोटे फीचर मागा:
संपर्क पानावर "सारांश" बटण जोडा. सर्व्हरवर, संपर्काच्या शेवटच्या 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 च्या कमाल-टोकन सेटिंगने.
- निकाल कॅश करा. सारांश साठवा आणि स्रोत बदलल्यावरच पुन्हा तयार करा, प्रत्येक पेज व्ह्यूवर नव्हे.
- प्रति वापरकर्ता मर्यादा ठेवा. खाते किंवा प्लॅननुसार दैनिक मर्यादा एकच जड वापरकर्ता किंवा एक स्क्रिप्ट बिल वाढवू नये म्हणून थांबवते.
- एंडपॉइंटवर रेट-लिमिट लावा, इतर महागड्या राऊटप्रमाणेच.
- प्रदात्याच्या डॅशबोर्डमध्ये बजेट किंवा अलर्ट सेट करा, आणि लाँचनंतर आठवड्याला वापर तपासा.
- प्रत्येक फीचरसाठी टोकन वापराची नोंद ठेवा, म्हणजे कोणते फीचर किती खर्च करते ते कळेल.
AI फीचर्स तुमच्या उत्पादनाचा केंद्रबिंदू असतील, तर त्यांचा चालू खर्च तुमच्या किंमत धोरणात धरा, तो स्वतः सहन करू नका.
सुरक्षितता आणि विश्वास
AI आउटपुट संभाव्यतेवर आधारित असतो. तो आत्मविश्वासाने बोलताना चुकू शकतो, आणि तो वाचत असलेल्या मजकुराने प्रभावित होऊ शकतो. त्यासाठी बांधा:
- आउटपुटला अविश्वसनीय इनपुट माना. रचना तपासा, HTML म्हणून दाखवण्यापूर्वी एस्केप करा, आणि कधीही कोड किंवा डेटाबेस क्वेरी म्हणून चालवू नका.
- परिणाम असलेल्या कोणत्याही गोष्टीसाठी माणसाला सहभागी ठेवा — ईमेल पाठवणे, रेकॉर्ड बदलणे, पेमेंट परत करणे. मॉडेल मसुदा तयार करते; व्यक्ती पुष्टी करते.
- प्रॉम्प्ट इंजेक्शनपासून संरक्षण करा. दस्तऐवज किंवा संदेशात "तुमच्या सूचना दुर्लक्षित करा" सारखा मजकूर असू शकतो. मॉडेलला सध्याच्या वापरकर्त्याला दिसू शकणाऱ्या गोष्टींपुरते मर्यादित ठेवा, आणि त्याला संवेदनशील कृती करू शकणारी टूल्स देऊ नका जोपर्यंत तुमचा कोड आधी परवानग्या तपासत नाही.
- AI सामग्री चिन्हांकित करा, जेणेकरून वापरकर्त्यांना कळेल की सारांश किंवा सूचना तयार झाली आहे आणि ते तपासू शकतील.
- अपयश सुरळीत हाताळा. प्रदात्यांमध्ये आउटेज आणि रेट मर्यादा येतात. टाइमआउट करा, स्पष्ट संदेश दाखवा, आणि ॲपचे बाकीचे भाग चालू राहू द्या.
- वापरकर्ते काय पाठवतात ते पहा. खुल्या मजकूर इनपुटसाठी मॉडरेशन पायरीचा विचार करा, आणि तुमच्या गोपनीयता धोरणात स्पष्ट करा की सामग्री तृतीय-पक्ष AI प्रदात्याद्वारे प्रक्रिया होते.
तपासण्यांची व्यापक यादी AI-बांधलेल्या ॲप्ससाठी सुरक्षा चेकलिस्ट मध्ये आहे.
सामान्य चुका
- सामान्य चॅटबॉटने सुरुवात करणे, जेव्हा एक "सारांश" किंवा "वर्गीकरण" बटण जास्त लोकांना मदत करेल.
- फ्रंटएंड कोडमध्ये किंवा सार्वजनिक रिपॉझिटरीमध्ये की ठेवणे.
- संपूर्ण डेटाबेस संदर्भ म्हणून पाठवणे, जे संथ, महाग आहे आणि इतर वापरकर्त्यांचा डेटा उघड करण्याचा धोका आहे.
- मोकळ्या मजकुराच्या आउटपुटवर विश्वास ठेवणे, जिथे स्कीमा किंवा निश्चित लेबल्स्चा संच त्याला तपासण्यायोग्य बनवेल.
- प्रति वापरकर्ता मर्यादा नसणे, जे पहिले बिल आल्यावरच लक्षात येते.
Mythex सह AI फीचर्स जोडणे
Mythex मध्ये तुमच्या स्वतःच्या ॲपमध्ये AI जोडण्यासाठी चॅटमध्ये मागा, तुमची स्वतःची प्रदात्याची की वापरून. की प्रोजेक्ट सिक्रेट म्हणून साठवा — एजंटला ती हवी असेल तेव्हा Mythex चॅटमध्ये सिक्रेट्स कार्ड दाखवते, त्यामुळे तुम्हाला की चॅटमध्ये पेस्ट करावी लागत नाही — आणि एजंट सर्व्हर राऊट, प्रॉम्प्ट्स आणि इंटरफेस लिहितो. तुमच्या ॲपचा AI वापर तुमच्या प्रदात्याकडून बिल होतो, बांधकामासाठी तुम्ही खर्च करता त्या Mythex क्रेडिट्सपासून वेगळा. डॉक्समध्ये तुमच्या स्वतःच्या API कीसह AI फीचर्स जोडा या मध्ये स्टार्टर प्रॉम्प्ट आहे.
प्रश्न
विद्यमान ॲपमध्ये AI कसे जोडायचे?
एखाद्या LLM प्रदात्याकडून API की मिळवा, ती सर्व्हर-बाजूच्या सिक्रेट म्हणून साठवा, आणि एक सर्व्हर राऊट जोडा जो प्रदात्याला प्रॉम्प्ट आणि संबंधित डेटा पाठवून निकाल तुमच्या फ्रंटएंडला परत करतो. सामान्य चॅटबॉटआधी एका छोट्या फीचरपासून सुरुवात करा, जसे एखाद्या रेकॉर्डचा सारांश.
AI फीचर्स चालवायला किती खर्च येतो?
LLM API प्रति टोकन शुल्क आकारतात — साधारणपणे पाठवलेल्या आणि परत आलेल्या मजकुराच्या प्रत्येक तुकड्यावर — आणि दर मॉडेलनुसार खूप बदलतात. खर्च प्रत्येक विनंतीत किती मजकूर जातो आणि ती किती वेळा चालते यावर अवलंबून असतो, म्हणून तुमच्या स्वतःच्या वापरावरून अंदाज घ्या, प्रदात्याच्या डॅशबोर्डमध्ये मर्यादा ठेवा, आणि तुमच्या ॲपमध्ये प्रति वापरकर्ता वापर मर्यादित करा.
मी माझी OpenAI किंवा Anthropic की फ्रंटएंडमध्ये ठेवू शकतो का?
नाही. फ्रंटएंड कोडमधील कोणतीही गोष्ट पेज उघडणारा कोणीही वाचू शकतो, आणि गळती झालेली की अनोळखी लोकांना तुमचे बिल वाढवू देते. प्रदात्याला सर्व्हरवरून कॉल करा, जिथे की एन्व्हायर्नमेंट व्हेरिएबलमध्ये राहते.
प्रॉम्प्ट इंजेक्शन म्हणजे काय?
मॉडेल वाचत असलेल्या मजकुरात — वापरकर्त्याचा संदेश, अपलोड केलेला दस्तऐवज, वेब पेज — तुमच्या सूचना बदलण्याचा प्रयत्न करणाऱ्या सूचना असतात तेव्हा ते होते. मॉडेलचा आउटपुट अविश्वसनीय माना, तपासणीशिवाय संवेदनशील कृती करू देऊ नका, आणि मॉडेलला दिसणारा डेटा वापरकर्त्याला दिसू शकणाऱ्या डेटापुरताच मर्यादित ठेवा.