अगर आप अपना खुद का open source ChatGPT-जैसा chatbot बनाना चाहते हैं
(hacks.mozilla.org)- Mozilla innovation group की एक छोटी टीम ने 1 सप्ताह के hackathon में internal-use chatbot prototype बनाया, और third-party API के बिना Mozilla cloud के अंदर open source LLM चलाने वाली configuration का प्रयोग किया
- बाहरी AI SaaS को हटाने के परिणामस्वरूप Mozilla के GCP account के अंदर सीधे server configure करना पड़ा, और Hugging Face text-generation-inference के बजाय ज्यादा जल्दी चल सकने वाले llama.cpp पर switch किया गया
- model selection पहले quality से ज्यादा license और runtime compatibility से बंधा था, और commercial use की अनुमति देने वाले LLaMA-family candidates का manual evaluation करने के बाद LLaMA 2 चुना गया
- internal knowledge integration को embedding और vector search से implement किया गया, और all-mpnet-base-v2, SentenceTransformers, LangChain, FAISS को जोड़कर company wiki के कुछ हिस्सों को answers में इस्तेमाल किया गया
- prototype पूरा हो गया, लेकिन भरोसेमंद open source chatbot बनाने के लिए hosting, model evaluation, bias, prompt, UI तक बहुत से क्षेत्रों में खुद निर्णय लेने पड़ते हैं
Mozilla जिस internal chatbot को बनाना चाहता था
- Mozilla trustworthy AI principles को आगे रखता है, जिनके अनुसार AI systems द्वारा इस्तेमाल किए जाने वाले data और decision-making में transparency होनी चाहिए, user privacy, agency और safety का सम्मान होना चाहिए, bias कम होना चाहिए और fairness बढ़नी चाहिए
- कई users के लिए latest AI का अनुभव करने का मुख्य रास्ता ChatGPT और Bard जैसे generative AI chatbots हैं, और dominant services अक्सर शक्तिशाली tech companies चलाती हैं और proprietary technology पर निर्भर रहती हैं
- Mozilla open source को users को सशक्त बनाने, transparency बढ़ाने और technology को केवल कुछ कंपनियों के worldview और financial motives के हिसाब से विकसित होने से रोकने का तरीका मानता है
- hackathon का सीधा लक्ष्य इन शर्तों को पूरा करने वाला internal chatbot prototype बनाना था
- Mozilla cloud infrastructure पर पूरी तरह चलता हो और third-party API या services पर निर्भर न हो
- free open source LLM और tools से बना हो
- Mozilla Manifesto और trustworthy AI principles को दर्शाता हो
- Mozilla की कुछ internal knowledge को integrate करके employee questions का जवाब दे सके
Hosting: बाहरी SaaS के बजाय अपना GCP server
- machine learning app hosting services बहुत हैं, लेकिन MLOps कठिन है, और खराब configuration वाला AI app धीमा, महंगा या low-quality हो सकता है
- team का स्पष्ट लक्ष्य ऐसी security और privacy था जिसमें कोई external party usage सुन न सके, user data collect न कर सके, या usage patterns में झांक न सके
- इसलिए third-party AI SaaS hosting का उपयोग नहीं किया गया और Mozilla के मौजूदा Google Cloud Platform account के अंदर अपना virtual server configure किया गया
- इस choice ने MLOps का बोझ खुद उठाने के बदले system को Mozilla के control में और private रखने की सुविधा दी
Runtime: Hugging Face से llama.cpp पर switch
- LLM app को model चलाने के लिए runtime engine चाहिए था, और time constraints के कारण team ने llama.cpp और Hugging Face ecosystem पर focus किया
- Hugging Face model library, documentation, tutorials और hosted inference API प्रदान करता है
- team ने hosted API के बजाय open source text-generation-inference आजमाया
- text-generation-inference कई models और model architectures को support करता है और Docker deployment संभव है, लेकिन server run करने की प्रक्रिया में environment setup issues बड़े थे
- यह GPU acceleration tool है, इसलिए server के OS, hardware और driver combination का match होना जरूरी था
- NVIDIA CUDA toolkit चाहिए था
- दिन का बड़ा हिस्सा setup में गया, और run होने के बाद भी output उम्मीद से धीमा था और results अच्छे नहीं थे
- time constraints के कारण Georgi Gerganov द्वारा शुरू किए गए llama.cpp की ओर रुख किया गया
- llama.cpp खास LLM families को consumer-grade hardware पर आसानी से चलाने देता है
- advanced GPU के बजाय CPU इस्तेमाल किया जा सकता है, और खासकर M1·M2 जैसे Apple Silicon CPU पर अपेक्षाकृत छोटे modern open source models अच्छी तरह चला सकता है
- llama-cpp-python OpenAI API specification implementation देता है, जिससे ChatGPT की जगह अपना LLM plug in करना आसान होता है
- अंत में CUDA version और महंगे hosting GPU से निपटने के बजाय AMD multicore CPU virtual server पर llama.cpp जल्दी चलाया गया
Model selection: license और architecture constraints
- llama.cpp चुनने के बाद इस्तेमाल किए जा सकने वाले models LLaMA architecture-based models तक सीमित हो गए
- Facebook ने 2022 के अंत में LLaMA announce किया था, और LLaMA को model data और architecture में बांटा जा सकता है
- LLaMA architecture open source के रूप में release हुआ, लेकिन model data यानी weights open source नहीं थे
- weights के उपयोग के लिए permission request जरूरी है और यह non-commercial purposes तक सीमित है
- LLaMA ने Stanford के Alpaca, LMSYS के Vicuna जैसे कई model innovations को trigger किया
- लेकिन ये models Facebook के weights का उपयोग करके develop हुए, इसलिए इन्हें original weights की legal restrictions विरासत में मिलीं
- इन्हें commercial purpose के लिए इस्तेमाल नहीं किया जा सकता था, इसलिए Mozilla team के candidates से बाहर कर दिया गया
- LLaMA architecture खुद open source code है, इसलिए दूसरे groups शुरुआत से models train करके उन्हें MIT, Apache 2.0, Creative Commons licenses के तहत release कर सके
- MPT, Falcon, Open Assistant जैसे दूसरी architecture पर आधारित models उस समय llama.cpp में run नहीं होते थे, इसलिए candidates से बाहर हो गए
Model quality, bias और safety evaluation
- model selection license और compatibility के साथ-साथ trustworthiness को भी सीधे प्रभावित करता है
- LLMs विशाल data पर train होते हैं, और खास behaviors और outputs बनाने के लिए अतिरिक्त input से fine-tune किए जाते हैं
- इस data selection में खुद curation शामिल है, और इसमें तरह-तरह के biases होते हैं
- models अपने training sources के अनुसार अलग-अलग characteristics दिखाते हैं
- hallucination की तरह meaningless answers बना सकते हैं
- toxic content, misinformation, dangerous या harmful information sharing तक ले जा सकते हैं
- concepts या groups of people के प्रति bias दिखा सकते हैं
- online learning materials का अधिकांश हिस्सा English में होना tool usability और सामने आने वाले worldview को प्रभावित करता है
- Hugging Face के Open LLM leaderboard जैसे performance और quality evaluate करने वाले resources हैं, लेकिन source और bias के आधार पर models की तुलना करना अभी भी कठिन है
- Mozilla team ने scope को commercial use योग्य और LLaMA architecture पर चलने वाले open models तक सीमित करने के बाद, toxicity, bias, misinformation और dangerous content resistance देखने के लिए कई questions पूछकर manual evaluation किया
- final choice Facebook का LLaMA 2 था, लेकिन limited time में evaluation methodology में flaws हो सकते हैं और license terms को लेकर भी पूरी सहजता नहीं है, इसलिए इसे recommendation मानना कठिन है
Internal knowledge integration: embedding और vector search
- Mozilla team employees के लिए accessible, लेकिन सामान्य LLM को ज्ञात न होने वाले internal Mozilla data को chatbot से आंशिक रूप से जोड़ना चाहती थी
- चुना गया तरीका external documents को answer generation में उपयोग कराने वाला embedding और vector search था
- basic flow इस प्रकार है
- इस्तेमाल किए जाने वाले data को original repository से लेकर embedding model से transform किया जाता है
- embeddings को chatbot-accessible vector database में index किया जाता है
- user question पूछता है तो chatbot vector database से relevant content search करता है
- retrieved relevant content को base model की context window में डालकर answer generation में इस्तेमाल किया जाता है
- team ने data control बनाए रखने के लिए third-party embedding service या vector database का उपयोग नहीं किया
- Python में सीधे implement किए गए solution ने ये tools इस्तेमाल किए
- all-mpnet-base-v2 embedding model
- SentenceTransformers embedding library
- LangChain
- FAISS vector database
- company internal wiki के केवल कुछ documents डाले गए थे, इसलिए scope सीमित था, लेकिन proof of concept के तौर पर यह काम किया
Prompt engineering और context window
- LLM हर बार previous conversation या user को याद रखे बिना start होता है, इसलिए chatbot को conversation जारी रखनी हो तो developer को memory management करना पड़ता है
- system prompt chatbot के features और behavior को plain text में specify करने वाली initial instruction है
- Mozilla team ने system prompt design किया ताकि chatbot Mozilla Manifesto, respectful behavior और non-discrimination policy का पालन करे
- Apollo moon landing conspiracy के बारे में पूछे गए question पर, misinformation answer reject करने का instruction होने पर इसने कहा कि moon landing fake नहीं थी
- उसी model में misinformation-ban wording हटाने पर इसने सामान्य Apollo denial theories की list दी
- system prompt में Mozilla Assistant नाम, Mozilla Manifesto principles का पालन, respect, professionalism और inclusion, harmful, immoral, unethical या potentially illegal actions से refusal, misinformation और discriminatory language पर ban शामिल था
- हर LLM में वर्तमान conversation में याद रखी जा सकने वाली maximum length, यानी context window, होती है
- यह अधिकतर training time पर तय होती है और बाद में बदली नहीं जा सकती
- context window जितनी बड़ी होगी, previous questions और answers को उतना लंबे समय तक refer किया जा सकेगा
- vector search से लाई गई content की बड़ी chunks भी डाली जा सकती हैं
- LLaMA 2 की context window 4096 tokens, लगभग 3000 words थी
- team ने context window बचाने के लिए system prompt length को बार-बार घटाया, और आगे बड़े context window support करने वाले models पर विचार करने की योजना है
Orchestration और UI selection
- पूरे chatbot को agent prompt injection, context window management, internal content embedding, LLM calls और response handling जैसी कई layers coordinate करने वाली orchestration चाहिए
- LLM field का prominent tool LangChain powerful और flexible है, लेकिन complexity भी अधिक है
- Mozilla team ने LangChain को केवल embedding और vector search में minimum रूप से इस्तेमाल किया
- project छोटा और बहुत constrained था, इसलिए अधिकांश काम hand-written Python code से किया गया
- समय ज्यादा होता तो संभवतः सब कुछ manually नहीं किया जाता
- UI को conversation display, past threads tracking, और uneven speed से output देने वाले backend को handle करने जैसी, दिखने में simple लगने वाली चीजों से ज्यादा functionality चाहिए
- open source chatbot UIs में chatbot-ui OpenAI API implement करता है, इसलिए इसे ChatGPT UI replacement की तरह इस्तेमाल किया जा सकता है और अपने LLM system के frontend के रूप में भी आसानी से उपयोग किया जा सकता है
- Mozilla team सामान्यतः chatbot-ui जैसे project का उपयोग करती, लेकिन internal experimental chatbot code Companion और उसके author दोनों मौजूद थे, इसलिए इसे UI के रूप में इस्तेमाल किया गया
- Companion की वजह से UI को तेजी से iterate और experiment किया जा सका
Hackathon result और बाकी tasks
- hackathon समाप्त होते समय Mozilla team ने internal-use prototype chatbot पूरा कर लिया
- यह Mozilla के भीतर पूरी तरह hosted था
- secure और private तरीके से इस्तेमाल किया जा सकता था
- अपने behavior में Mozilla के values दर्शाने की कोशिश करता था
- goal हासिल करने की प्रक्रिया में कई कठिन choices और trade-offs जरूरी थे
- सीखी गई बातें तीन points में summarized हैं
- open source chatbots अभी evolve हो रहे हैं, decisions बहुत हैं, clear documentation की कमी है और fail होने के तरीके भी कई हैं
- raw performance के अलावा criteria पर models को evaluate और select करना बहुत कठिन है, इसलिए trustworthy AI app के लिए सही choice भी कठिन है
- फिलहाल effective prompt engineering chatbot की सफलता के लिए महत्वपूर्ण है
- Mozilla ने developers के लिए open source machine learning ecosystem में आसानी से entry करने के तरीके बनाना शुरू किया है, और hackathon work के आधार पर open source community में contribute करना चाहता है
- open source LLMs व्यापक रूप से उपलब्ध होने की स्थिति में बेहतर भविष्य बनाने के लिए हम सभी को सामूहिक और सक्रिय रूप से इसकी shaping में भाग लेना होगा
1 टिप्पणियां
Hacker News की राय
किसी कंपनी से संपर्क करने की कोशिश इसलिए होती है क्योंकि साइट पर जवाब नहीं मिला, या वेबसाइट पर न हो सकने वाला काम किसी जिम्मेदार व्यक्ति से करवाना होता है। जैसे सेवा रद्द करना
बोलने वाला FAQ पेज खराब user experience की भरपाई करने की कोशिश जैसा लगता है, और अगर कंपनी ने मेरी खोजी हुई जानकारी वेबसाइट पर नहीं डाली, तो संभावना है कि उसने उसे chatbot में भी नहीं डाला होगा
हां, chatbot सही जिम्मेदार व्यक्ति तक जोड़ने में मदद कर सकता है, लेकिन इंसान की मदद मिलने से पहले उसे बाधा बनाना मुझे antipattern लगता है
इसलिए बहुत-सी sites support team से संपर्क करने से पहले description के आधार पर relevant answers सुझाने वाले ढेर सारे सवाल दिखाती हैं, और AWS Support भी ऐसा ही करता है
bots परेशान कर सकते हैं, लेकिन customer support की लागत काफी घटा भी सकते हैं। अगर user experience अच्छा हो, और bot जवाब न दे पाए तो जल्दी agent से connect कर सके, तो मैं इसके पक्ष में हूं। बेशक शर्त यह है कि bot hallucinate करके फर्जी जानकारी न दे
सवालों के जवाब देने के लिए support staff नहीं है, इसलिए chatbot इस्तेमाल करता हूं। bot न हो तो कुछ भी नहीं है
इसके बजाय bot logs monitor करता हूं। अगर product या website में कोई feature missing हो, तो उसे जोड़ देता हूं ताकि बाद में user पूरी तरह self-service से काम कर सके
user कभी भी account cancel कर सकता है या refund ले सकता है
ऐसे सवालों के लिए large language model लगभग perfect fit है। बस बेहतर हो कि bot उन सवालों को ज्यादा अच्छे से detect कर पाए जिनका वह सीधे जवाब नहीं दे सकता
बेशक कुछ मामलों में chatbot इंसान या अच्छे से लिखे FAQ की जगह ले सकता है। लेकिन यह आत्मसंतुष्टि support के खराब होने की मुख्य वजह को नजरअंदाज कर देती है। support शुरू से ही इसी तरह design किया गया होता है
“सिर्फ फोन पर cancel कर सकते हैं” का उदाहरण लें, तो signup या upsell तकनीकी रूप से ज्यादा कठिन समस्या होते हुए भी कहीं आसान बना दिया जाता है। मकसद उन actions में friction जोड़ना है जो short-term cost या loss जैसे दिखते हैं। कंपनियां जानती हैं कि friction होने पर बहुत-से लोग हार मान लेते हैं या टाल देते हैं
यह nudge और dark pattern का paradigm है। cookie banner में “सभी अस्वीकार करें” ज्यादातर छिपा होता है, बस उसे देखिए। nudge कंपनियों को कानून का पालन करती हुई दिखने देता है, लेकिन users के समय और ध्यान को लागत बनाकर उसके कुल प्रभाव से बच निकलने देता है
chatbot support maze में जोड़ी गई बस एक और layer है
ऐसा भविष्य बिल्कुल उत्साहित नहीं करता जिसमें हर कंपनी के पास chatbot support हो
यह पहले से काफी आम और frustrating है, लेकिन फिर भी लगभग आधे मामलों में उसे समझ नहीं आता कि सवाल क्या है, इसलिए इंसान तक निकलने का रास्ता रहता है
“computer कह रहा है कि नहीं हो सकता” वाला युग पहले ही आ चुका है
साथ ही, मैं सिर्फ negative और off-topic बात नहीं करना चाहता; article खुद काफी अच्छा लगता है। लेखक को बधाई। engineering शानदार है, बस इसका असल इस्तेमाल मुझे पसंद नहीं
chatbot हर चीज का हल नहीं है, लेकिन बहुत-सा अनावश्यक noise कम कर सकता है। जरूरत ऐसी चीज की है जो किसी specific domain में average user द्वारा पूछे जाने वाले basic questions का जवाब दे सके
मेरी पिछली job एक काफी बड़ी company में थी और उसका Confluence instance बहुत बड़ा था। उसमें information ढूंढने में बहुत समय बर्बाद होता था। अगर उस सारी information पर trained chatbot होता तो काफी उपयोगी रहा होता
Amazon याद आता है। मैं लंबे समय से customer था, और हाल ही में मुझे एक defective computer peripheral मिला
chatbot को समस्या संक्षेप में बताई तो तुरंत नया order place हो गया, जवाब मिला कि पहले मिला सामान अपने पास रख सकते हैं, और बिना extra cost के priority shipping होगी
बस इतना ही था, और वह अगले दिन आ गया और ठीक से काम किया
जाहिर है उसे पता होगा कि मैं पुराना customer हूं और पहले ही काफी पैसा खर्च कर चुका हूं, लेकिन यह लगभग उतना painless experience था जितना कल्पना की जा सकती है। कई webpages पर options click करते हुए आगे बढ़ने से कहीं बेहतर
“Your Honor, मेरी पूरी दलील बकवास थी और मैंने ऐसे legal provisions cite किए जो मौजूद ही नहीं हैं, लेकिन ऐसा इसलिए हुआ क्योंकि मैंने ChatGPT इस्तेमाल किया था” — यह एक असली वकील था, और उसकी वकालत की license तक रद्द नहीं हुई
“यह उस web को पहले ही बदल रहा है जिसे हम जानते और प्यार करते थे” वाली अभिव्यक्ति पर आपत्ति करना nitpicking है और साफ तौर पर off-topic भी, लेकिन मुझे मौजूदा web से प्यार नहीं है
web पर धीरे-धीरे कुछ कंपनियों का control बढ़ता जा रहा है। कौन-सा content दिखेगा (meta, google), कौन-सा email spam filter में जाएगा (ms, google), यह वे तय करती हैं
आज का web प्यार से बहुत दूर है। जिन लोगों ने मुझे follow करने का विकल्प चुना है, उन तक पहुंचने के लिए भी लगातार लड़ना पड़ता है
आखिरकार मेरी ज्यादातर communication real world या private chats में होती है। साथ ही यह भी कहना चाहता हूं कि business के लिए messenger कितना भयानक और unreliable है
आज के web में कुछ न कुछ होना चाहिए। क्या और कैसे, नहीं पता, लेकिन बदलाव का स्वागत जरूर है
फिर भी लोगों को follow करने के बाकी सभी तरीके देने चाहिए, लेकिन RSS feed को promote करेंगे तो लोग इस्तेमाल करना शुरू कर सकते हैं
अगर technical तौर पर कुछ करना चाहें, तो ActivityPub bridge set करके social media पर भी follow करने की सुविधा दे सकते हैं। अगर Wordpress इस्तेमाल करते हैं तो https://wordpress.org/plugins/activitypub/ है
ज़्यादातर टॉप-लेवल comments chatbot को लेकर नकारात्मक लग रहे हैं, तो कहना चाहूँगा कि मेरे workplace में वाकई एक बेहतरीन chatbot था
मेरे लिए वह Confluence में search करने से कहीं बेहतर था, और बचे हुए vacation days या working hours में कितना आगे/पीछे हूँ जैसे dynamic data से जुड़े सवालों के भी जवाब दे सकता था
जहाँ तक याद है, backend में technology का smart इस्तेमाल किया गया था, इसलिए natural language में पूछने पर भी वह ज़्यादातर समझ जाता था
Confluence की search तो पूरी तरह मज़ाक है, और वह भी खराब मज़ाक
Customers chatbot इसलिए इस्तेमाल करते हैं क्योंकि website का UI confusing होता है। वे जानकारी पाना चाहते हैं, लेकिन तरीका नहीं ढूँढ़ पाते
पहले लोग Google पर “service name + phone number” या “service name + cancel subscription” search करते थे
दस में से नौ बार website phone number आसानी से देना या subscription cancel करना आसान बनाना नहीं चाहती। अगर आप शुरू से ही नहीं चाहते कि customer कोई छिपाया गया action करे, तो chatbot आखिर किसलिए है?
मैंने chatbot hype के दौर में काम किया है, और कई client companies से कहना पड़ा कि अगर customers की सच में मदद करने की इच्छा नहीं है, तो हम ज़्यादा कुछ नहीं कर सकते
कम-से-कम लोगों से deal करने वाली companies में chatbot का असली लक्ष्य web और mobile app UI को first touchpoint से हटाना है
User को एक ही identity के साथ SMS या इसी तरह की chat, या phone call के ज़रिए company से बात कर पाने में सक्षम होना चाहिए
Web और mobile apps तो primary communication method को support करने वाली secondary, tertiary utilities भर हैं
Companies पहले यह नहीं कर पाईं क्योंकि language understanding accuracy पर्याप्त नहीं थी। large language models ने उस सीमा को हल कर दिया है
Bot अगर अनुभवजन्य तरीकों से agent interactions को थोड़ा कम कर देता है, तो वह bonus है। बेहतर large language models की वजह से deflection rate भी धीरे-धीरे बढ़ रहा है
नीचे दाईं ओर चिपका हुआ irritating chatbot widget तब तक का workaround है, जब तक एक single phone number उपलब्ध न हो जाए और उसके ज़रिए communication seamless न हो जाए
अंत में, title misleading है। बात open source chatbot बनाने की नहीं है, बल्कि community और तेज़ AI progress के लिए closed/proprietary tools की जगह सिर्फ open source libraries का इस्तेमाल करके chatbot बनाने की है
कहा गया है, “Mozilla के मौजूदा Google Cloud Platform(GCP) account के अंदर अपना virtual server बनाया। इस तरह हमने effectively MLOps खुद करने का फैसला किया। लेकिन हम इस भरोसे के साथ आगे बढ़ सके कि system private है और पूरी तरह हमारे control में है।” Google infrastructure के अंदर server बनाना कैसे private है और Mozilla के पूर्ण control में कैसे है?
Bare metal पर self-hosting तक समझाना chatbot बनाने वाले article के scope से बाहर है, और यह दिखाना कि Google Cloud का VPS सुरक्षित नहीं है, थोड़ा ज़बरदस्ती है
ISO 27001 information security management systems के लिए international standard है, और GCP का compliance information security के प्रति commitment दिखाता है
ISO 27017 cloud security के लिए खास है, और cloud service providers के लिए specific controls पर focus करता है
ISO 27018 public cloud में personally identifiable information की protection से जुड़ा standard है
SOC 2 reports security, availability, processing integrity, confidentiality और privacy से जुड़े controls पर assurance दे सकती हैं
अगर आप medical information handle करते हैं, तो HIPAA compliance ज़रूरी है, और अगर Europe या European citizens का data handle करते हैं, तो GDPR compliance महत्वपूर्ण है
US government customers के लिए FedRAMP compliance अनिवार्य हो सकता है, और credit card information process करते हैं तो PCI DSS compliance महत्वपूर्ण है
आपको यह verify करना चाहिए कि GCP के अंदर इस्तेमाल की जाने वाली services आपके industry या use case के लिए ज़रूरी certification scope में शामिल हैं। ये certifications आम तौर पर Google Cloud website पर देखे जा सकते हैं, और official documents की ज़रूरत हो तो Google sales या support team के ज़रिए भी मिल सकते हैं
अगर आप जानना चाहते हैं कि ऐसे vector database chat model को practically कैसे बनाया जाता है, तो पिछले हफ़्ते live stream में Colab environment में लगभग scratch से बनाकर Llama 2 से inference करने की प्रक्रिया दिखाई थी https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
इस setup की बड़ी चुनौती large scale पर semantic similarity search करना है। बड़े vector database को scale करने के लिए Pinecone के data structure docs काफ़ी अच्छे हैं
मैं इंतज़ार कर रहा था कि Mozilla इस trend में उतरे और अपना large language model develop करे। “internet को सभी के लिए open और accessible बनाए रखना” संगठन के mission को देखते हुए यह बहुत वाजिब है। हालांकि पता नहीं उनके पास इसके लिए resources या willingness है या नहीं
कहा गया है, “Machine learning operations, यानी MLOps, एक growing field है, इसकी वजह है। ऐसे apps को deploy और manage करना कठिन है। इसके लिए specific knowledge और skills चाहिए जो कई developers और operations staff के पास अभी नहीं हैं।” इसमें इतना कठिन या अलग क्या है?
मेरी समझ थी कि यह बस एक web API चलाना है जो compiled asset यानी model को load करता है। उस लिहाज़ से यह बहुत अलग नहीं दिखता