पिछले महीने मैंने एक नए स्थानांतरित सहकर्मी के साथ एक स्मार्ट कस्टमर सर्विस प्रोटोटाइप बनाया, आवश्यकता बहुत सरल थी: उपयोगकर्ता प्रश्न पूछता है, मॉडल उत्तर देता है, थोड़ी संदर्भ स्मृति के साथ, स्ट्रीमिंग टाइपिंग प्रभाव के साथ। सुनने में लगा कि दो दिन में हो जाएगा, लेकिन उसने API Key हार्डकोडिंग, रीट्राई लॉजिक और स्ट्रीमिंग इंटीग्रेशन में अलग-अलग गलतियाँ कीं। मैंने पूरी प्रक्रिया को इस लेख में संजोया है, इसे नए लोगों के प्रशिक्षण नोट्स की तरह पढ़ें।
पहला कदम: पहले आवश्यकताएँ तोड़ें, फिर मॉडल चुनें
सीधे कोड लिखना शुरू न करें। स्मार्ट कस्टमर सर्विस की क्षमता आवश्यकताएँ मोटे तौर पर तीन भागों में बँटती हैं: इंटेंट पहचान, ज्ञान प्रश्नोत्तर, बहु-दौर बातचीत। इंटेंट पहचान तेज़ और सस्ती होनी चाहिए, DeepSeek-V3 या Qwen API काफी है; ज्ञान प्रश्नोत्तर में आपके निजी दस्तावेज़ शामिल हैं, RAG से जाना होगा, मॉडल को लंबे संदर्भ को समझने की आवश्यकता होती है; बहु-दौर बातचीत में लहजे की माँग अधिक होती है, Claude 4 Sonnet या GPT-4o अधिक स्थिर हैं।
मेरा तरीका यह था कि पहले एक सामान्य मॉडल से पूरी श्रृंखला चलाऊँ, फिर एक-एक करके बदलूँ। SiCore TokenWorks का मल्टी-मॉडल रूटिंग इस समय सुविधाजनक है, एक ही कोड सेट में मॉडल का नाम बदलकर प्रभावों की तुलना कर सकते हैं, प्रमाणीकरण बदलने की ज़रूरत नहीं। बड़े मॉडल API का चयन सबसे मज़बूत चुनना नहीं है, बल्कि कार्य के लिए सबसे उपयुक्त चुनना है।
दूसरा कदम: Key प्रबंधन, कोड में न लिखें
Key को सोर्स कोड में हार्डकोड करना नए लोगों की सबसे आम गलती है। एक बार git में कमिट हो गया, तो सार्वजनिक हो गया। सही तरीका है पर्यावरण चर और कॉन्फ़िगरेशन फ़ाइल का स्तरीकरण: स्थानीय में .env उपयोग करें, परीक्षण और उत्पादन में कॉन्फ़िगरेशन केंद्र या Key प्रबंधन सेवा उपयोग करें।
बहु-पर्यावरण अलगाव में तीन बातें याद रखें: विकास, परीक्षण, उत्पादन के लिए अलग-अलग Key उपयोग करें; प्रत्येक Key पर स्वतंत्र कोटा सीमा सेट करें; उत्पादन Key केवल सर्वर को दें, फ्रंटएंड कभी न पाए। हमारे प्रोजेक्ट में SiCore TokenWorks उपयोग करते हैं, एक Key से GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao आदि प्रमुख मॉडल कॉल कर सकते हैं, कई प्रमाणीकरण बनाए रखने की परेशानी बचती है, बहु-पर्यावरण Key स्विच करना बस एक चर बदलना है।
तीसरा कदम: कॉल रैपिंग और त्रुटि रीट्राई
सीधे SDK कॉल करने वाला कोड रखरखाव योग्य नहीं है। एक परत रैप करें, टाइमआउट, रेट लिमिट, रीट्राई को समान रूप से संभालें। सोच यह है: मॉडल कॉल को एक फ़ंक्शन में लपेटें, पैरामीटर messages और मॉडल नाम हैं, अंदर तीन प्रकार की त्रुटियाँ कैच करें——नेटवर्क टाइमआउट, 429 रेट लिमिट, 5xx सर्वर त्रुटि।
रीट्राई रणनीति एक्सपोनेंशियल बैकऑफ़ उपयोग करें, पहली बार 1 सेकंड प्रतीक्षा, दूसरी बार 2 सेकंड, तीसरी बार 4 सेकंड, अधिकतम तीन बार। 429 को विशेष रूप से संभालें, लौटाए गए retry-after हेडर को देखें। सभी त्रुटियों पर रीट्राई न करें, पैरामीटर त्रुटि पर सौ बार रीट्राई करने से भी कोई फ़ायदा नहीं। मॉडल गेटवे का मूल्य इसी परत में है, रीट्राई, डिग्रेडेशन, लॉग को एक जगह केंद्रित करें, व्यावसायिक कोड बस परिणाम ले।
गलती की चेतावनी: रीट्राई आइडेम्पोटेंट होनी चाहिए। यदि कॉल में साइड इफेक्ट है (जैसे डेटाबेस में लिखना), तो रीट्राई से पहले पुष्टि करें कि पिछली बार वास्तव में विफल हुई थी या नहीं।
चौथा कदम: स्ट्रीमिंग आउटपुट और फ्रंटएंड एकीकरण
कस्टमर सर्विस अनुभव का मुख्य केंद्र "टाइपराइटर प्रभाव" है। सर्वर SSE का उपयोग करके token को टुकड़ों में फ्रंटएंड को भेजता है, फ्रंटएंड EventSource या fetch के ReadableStream से प्राप्त करता है।
बैकएंड मुख्य बिंदु: stream=True सेट करें, लौटाए गए delta को टुकड़ों में पार्स करें, [DONE] पर समाप्त करें। फ्रंटएंड मुख्य बिंदु: प्रत्येक अक्षर प्राप्त होने पर setState न करें, 20 से 50 मिलीसेकंड जमा करके बैच में रेंडर करें, अन्यथा पेज स्लाइड शो की तरह अटक जाएगा।
एक और गलती, स्ट्रीमिंग के दौरान उपयोगकर्ता पेज बंद कर सकता है। सर्वर को कनेक्शन डिस्कनेक्ट इवेंट सुनना चाहिए, समय पर अपस्ट्रीम अनुरोध रद्द करना चाहिए, अन्यथा token व्यर्थ जलेंगे। पे-एज़-यूज़ बिलिंग में, यह बर्बादी बूँद-बूँद से इकट्ठा होती है।
पाँचवाँ कदम: लागत निगरानी और अलर्ट
लॉन्च से पहले इंस्ट्रुमेंटेशन अनिवार्य है। प्रत्येक कॉल में रिकॉर्ड करें: मॉडल नाम, इनपुट token संख्या, आउटपुट token संख्या, समय, रीट्राई हुई या नहीं। यह डेटा एक सप्ताह जमा करें, तभी आपको पता चलेगा कि पैसा कहाँ खर्च हो रहा है।
अलर्ट की दो रेखाएँ सेट करें: एकल दिन की लागत सीमा से अधिक होने पर चेतावनी, एकल कॉल token असामान्य होने पर चेतावनी। एक बार एक उपयोगकर्ता ने पूरा दस्तावेज़ पेस्ट कर दिया, एकल इनपुट में दसियों हज़ार token, अलर्ट न होता तो महीने के अंत का बिल बहुत बुरा दिखता।
पैसे बचाने का अनुभव: इंटेंट पहचान जैसे उच्च-आवृत्ति कम-कठिनाई कार्यों के लिए, सस्ते घरेलू मॉडल पर स्विच करें, लागत काफी कम हो सकती है। थोक खरीद और हरित ऊर्जा शेड्यूलिंग, SiCore TokenWorks जैसे एग्रीगेशन प्लेटफ़ॉर्म की कीमत आधिकारिक सीधी खरीद से कम होने का कारण है, हमारी तुलना में, उच्च-आवृत्ति कॉल परिदृश्यों में अंतर स्पष्ट है।
एक वाक्य में सारांश: स्मार्ट कस्टमर सर्विस प्रोटोटाइप की कठिनाई मॉडल में नहीं, इंजीनियरिंग विवरणों में है। Key ठीक से प्रबंधित करें, रीट्राई सही लिखें, स्ट्रीमिंग स्थिर जोड़ें, लागत पर नज़र रखें, बाकी बस prompt ट्यून करना है। बहु-मॉडल एकीकृत एक्सेस और मॉडल रूटिंग के कार्यान्वयन को गहराई से समझना चाहते हैं, तो बड़े मॉडल API गेटवे की इस दिशा में आगे देख सकते हैं।