किन notebook एउटा प्रणाली होइन · AI प्रणाली शिप गर्ने

Nepal मा हरेक AI परियोजना उसै तरिकाले सुरु हुन्छ। कसैले notebook लेख्दछ। यसले काम गर्दछ। तिनीहरूले सहकर्मीलाई देखाउँछन्। यसले काम गर्दछ। तिनीहरूले notebook एक हप्ता पछि खोल्दछन् — र यसले काम गर्दैन। यो Python मा bug होइन; यो तपाईंको लागि चल्ने कोड र प्रयोगकर्ताहरूको लागि, सधैँ चल्ने प्रणाली बीचको खाडल हो। यो पाठ्यक्रम त्यो खाडल हो। र यो पहिलो खण्ड shipped AI प्रणाली वास्तवमै के हो त्यसको ईमानदार नक्शा हो, ताकि तपाईंलाई थाहा हुन्छ कि तपाईंलाई के निर्माण गर्न भनिँदैछ।

Notebook के हो

Notebook भनेको राम्रो output भएको script हो। यो एउटा process मा, एउटा machine मा, एउटा moment मा माथिबाट तलसम्म चल्दछ। यसले काम गर्दछ किनकि तपाईं त्यहाँ हुनुहुन्छ — तपाईंले अन्तिम त्रुटि ठीक गर्नुभयो, तपाईंले environment सेट गर्नुभएको छ, तपाईंलाई थाहा छ कुन cell पहिले क्लिक गर्ने, र तपाईं काम सकिएपछि browser tab बन्द गर्नुहुन्छ।

यो कुनै पनि प्रणालीको लागि सत्य होइन। एउटा प्रणाली तपाईं हेर्दै नहुनुहुँदा चल्दछ। यो नछानेको request बाट चल्दछ। यो API ढिलो हुँदा, disk भरिँदा, मोडेलले फोहोर फर्काउँदा चल्दछ। यो बुटवलमा राति २ बजे कमजोर संकेत भएको फोनमा चल्दछ। यो एक असन्तुष्ट प्रयोगकर्ताले button फेरि क्लिक गर्दा चल्दछ।

Notebook अन्वेषणको लागि उपकरण हो। प्रणाली सेवाको लागि उपकरण हो। तिनीहरू बीचको engineering यो पाठ्यक्रमको सार हो।

Notebook मा नभएका सात कुराहरू

जब “notebook production मा जान्छ,” सातवटा चीजहरू आवश्यक हुन्छन् — सामान्यतया छुटाइन्छ, र पछि तिर्नु पर्दछ:

एउटा interface। प्रयोगकर्तालाई request पठाउने र प्रतिक्रिया प्राप्त गर्ने तरिका चाहिन्छ। HTTP boring, universal जवाफ हो।
चलिरहेको process। Notebooks बन्द हुन्छन्; सेवाहरूले सुन्न जारी राख्दछन्।
एक hosted environment। कोडलाई एक computer मा बस्नुपर्दछ जसमा power, internet, र Python छ — तपाईंको laptop होइन।
समवर्ती requests को लागि handling। एकैचोटि दुई प्रयोगकर्ताहरूले तेस्रो लाई तोड्न सक्दैनन्।
Logging। हरेक interaction को छाप छोड्दछ, ताकि तपाईं debug र सुधार गर्न सक्नुहुन्छ।
Cost नियन्त्रण। हरेक LLM call को पैसा लाग्दछ; अनियन्त्रित traffic ले परियोजनालाई रातारात bankruptcy बनाउन सक्दछ।
कुराहरू सुरक्षित रूपमा बदल्ने तरिका। तपाईंले prompts, models, र कोड अपडेट गर्न आवश्यक हुनेछ — प्रयोगकर्ताहरूलाई नबिगारेर।

यी प्रत्येक एक खण्ड, अध्याय, वा यस पाठ्यक्रमको विषय हो। तिनीहरू मध्ये कुनै पनि glamorous छैनन्। तिनीहरू सबै एक demo र एक उत्पाद बीचको फरक हुन्।

एक Nepal कथा

काठमाडौँका दुई विद्यार्थीहरूले Streamlit notebook मा एउटा नेपाली-भाषा document Q&A बोट निर्माण गर्दछन्। यो demo मा सुन्दरतापूर्वक काम गर्दछ। तिनीहरूले Facebook मा URL share गर्दछन्। चार घण्टा भित्र:

Streamlit app crash हुन्छ किनकि free hosting tier मा memory सकिन्छ जब ४० प्रयोगकर्ताहरूले एकैचोटि प्रयास गर्दछन्।
पहिलो दिनको लागि OpenAI बिल Rs 3,000 मा पुग्दछ — कसैले load-testers को लागि budget गरेको छैन।
एक प्रयोगकर्ताले report गर्दछ कि बोटले नेपालीमा अनुपयुक्त केही भन्यो। तिनीहरूसँग logs छैनन्, त्यसैले तिनीहरूले जाँच गर्न सक्दैनन्।
अर्को बिहान, तिनीहरूले फिक्स push गर्दछन्। फिक्सले यसलाई प्रयोग गरिरहेका सबैको लागि बोट तोड्दछ। तिनीहरूसँग rollback छैन।

यीमध्ये कुनै पनि कोड bug होइन। यी सबै “काम गर्ने notebook” र “सेवा गर्ने प्रणाली” बीचको फरक हो। टिम न त अक्षम थियो न त बदकिस्मत — तिनीहरूले अझै त्यो खाडल पार गरेका थिएनन् जुन यो पाठ्यक्रम भन्दै छ।

प्रणाली कस्तो देखिन्छ

Notebook लाई वास्तविक deployed AI प्रणालीको आकारसँग तुलना गरौँ:

[ user ]
    │  HTTP request (question)
    ▼
[ load balancer ]
    │  routes to healthy instance
    ▼
[ your API server (running always) ]
    │  authenticate user
    │  check rate limit
    │  log request
    ▼
[ retrieval / preprocessing ]
    │  fetch documents, format prompt
    ▼
[ model call ]  ←──── retry on failure, fallback if slow
    │
    ▼
[ post-processing / validation ]
    │  check output is safe
    │  log response
    ▼
[ response ] ──→ [ user ]
    │
    ▼
[ metrics + traces + billing ] ──→ [ your dashboards ]

प्रत्येक तीर तपाईंले लेख्ने कोड वा configure गर्ने infrastructure हो। प्रत्येक बक्सको failure modes छन् जुन तपाईंले सम्हाल्नुहुन्छ। प्रत्येक तहमा cost implications छन् जुन तपाईंले monitor गर्नुहुन्छ।

Notebook बीचमा एउटा बक्स हो। प्रणाली यसको वरिपरि सबै कुरा हो।

किन “बस Vercel मा deploy गर्नुहोस्” जवाफ होइन

तपाईंले सुन्नुभएको हुनसक्छ आधुनिक platforms ले deployment लाई trivial बनाउँछन्। कोड push गर्नुहोस्, र साइट live हुन्छ। यो सत्य हो — तर यसले सातमध्ये दुई (एक interface, चलिरहेको process) मात्र सम्हाल्दछ। अन्य पाँच — hosted environment garanties, concurrency, logging, cost नियन्त्रण, सुरक्षित परिवर्तन — अझै तपाईंको हुन्।

राम्रा platforms ले infrastructure सजिलो बनाउँछन्। तिनीहरूले engineering discipline लाई वैकल्पिक बनाउँदैनन्। यो पाठ्यक्रमले discipline सिकाउँछ, र तपाईंले यसलाई तपाईंले चाहनुभएको platform मा लागू गर्न सक्नुहुन्छ।

Course 05 मा तपाईंले के सिक्नुहुनेछ

छ अध्यायहरू, प्रत्येक खाडलको एउटा टुक्रा:

Chapter 1 (यो एक): Notebook बाट service सम्म। एउटा मोडेल wrap गर्ने, यसलाई deploy गर्ने, कतै वास्तविक मा चलाउने।
Chapter 2: Cost, quotas, र rate limits। LLM हरू चलाउने economics, र कसरी टाट नपल्टिने।
Chapter 3: Reliability र observability। Logs, metrics, र तपाईंको प्रणाली स्वस्थ छ भनेर कसरी थाहा पाउने।
Chapter 4: Production मा मूल्यांकन। निरन्तर परीक्षण, A/B, र feedback loops।
Chapter 5: Versioning र rollouts। कुराहरूलाई बिगारे बिना बदल्ने।
Chapter 6: Nepal मा एउटा AI उत्पाद चलाउने। Trust, गोपनीयता, law, र closing playbook।

अन्तमा, तपाईंले एउटा notebook लिनुभएको हुनेछ र एउटा साना, real service उत्पादन गर्नुभएको हुनेछ — API पछाडि चलिरहेको, deployable, monitored, र बदल्न सुरक्षित। यो shipped AI प्रणाली हो। यो जहाँ Course 04 chatbots र RAG सहायकहरू उत्पादहरू बन्दछन्।

Mindset shift

केही निर्माण गर्नुअघि, एउटा आन्तरिक shift। Notebook सोचाइले सोध्दछ: के यो कोडले काम गर्दछ? System सोचाइले सोध्दछ: म हेर्दै नहुँदा यो कोडले के गर्दछ?

तपाईंले यस पाठ्यक्रममा लेख्ने हरेक function को लागि, ईमानदार प्रश्न हो:

Input खाली हुँदा के हुन्छ?
API डाउन हुँदा के हुन्छ?
एउटै request एक मिनेटमा 10,000 पटक आउँदा के हुन्छ?
मैले यसलाई अर्को महिना बदल्न आवश्यक भएमा के हुन्छ?

यी boring प्रश्नहरू हुन्। यीमध्ये हरेक जहाँ उत्पादहरू मर्दछन् जब तिनीहरूका निर्माताहरूले तिनीहरूलाई छोडेका थिए।

आफ्नो बुझाइ जाँच्नुहोस्

Quick check

—

एउटा टिम सदस्यले भन्दछ कि तिनीहरूको AI परियोजना 'launch गर्न तयार' छ — notebook काम गर्दछ, मोडेलले सही जवाफ फर्काउँछ, र तिनीहरूले २० उदाहरण inputs मा परीक्षण गरेका छन्। सबैभन्दा ईमानदार जवाफ के हो?

त्यो तयार छ — ship गर्नुहोस्।
Demo गर्न तयार, launch गर्न तयार होइन। एक launched प्रणालीलाई प्रयोगकर्ताहरूको लागि interface, चलिरहेको hosted process, समवर्ती requests को handling, हरेक interaction को logging, मोडेल calls मा cost नियन्त्रण, र कुराहरूलाई सुरक्षित रूपमा बदल्ने तरिका चाहिन्छ। यीमध्ये प्रत्येक 'notebook काम गर्दछ' र 'प्रयोगकर्ताहरूले यसमा भरोसा गर्न सक्दछन्' बीचको वास्तविक काम हो। ईमानदार जवाफले demo राम्रो छ भन्ने कुरा स्वीकार गर्दछ र वास्तविक प्रयोगकर्ताहरूलाई पहुँच पाउनुअघि के बाँकी छ त्यो लेइ-आउट गर्दछ।
थप tests लेख्नुहोस्।
एक frontend थप्नुहोस्।

Quick check

—

यीमध्ये कुन system-thinking मा सम्बन्धित छ, notebook-thinking मा होइन?

'के मोडेलले यो input को लागि सही जवाफ दिन्छ?'
'यो function एक सेकेन्डमा १०० पटक कल गरिँदा, वा खाली input मा, वा API ढिलो हुँदा के हुन्छ?' System-thinking भनेको तपाईंले नहेरेको बेला कोडको व्यवहारको बारेमा हो — load अन्तर्गत, edge cases मा, failure modes भर। Notebook-thinking ले operator उपस्थित भएको happy path लाई मान्दछ। दुबै महत्त्वपूर्ण छन्, तर 'के यसले काम गर्दछ?' बाट 'मैले नहेरेको बेला यसले के गर्दछ?' मा shift यो पाठ्यक्रमले सिकाइरहेको मौलिक परिवर्तन हो।
'के notebook मा राम्रो टिप्पणी छ?'
'के म आफ्नो टीममेटलाई यो व्याख्या गर्न सक्दछु?'

अब के आउँछ

खण्ड 1.2 पहिलो व्यावहारिक चरण हो: बाहिरी requests पुग्न सक्ने गरी सानो API server मा एउटा मोडेल wrap गर्ने। हामी FastAPI (Python को standard modern विकल्प) प्रयोग गर्नेछौँ र एक न्यूनतम तर ईमानदार उदाहरण बनाउनेछौं। यो notebook बाट system सम्मको सम्भावित सबैभन्दा सानो पुल हो — र यो अनुसरण गर्न सबै कुराको आधार हो।