Model provider drift सम्हाल्ने

Drift का प्रकारहरू

Provider-side परिवर्तनहरू केही आकारहरूमा आउँछन्:

1. Silent model updates। उही model name फरक व्यवहार गर्दछ। Anthropic मा दुर्लभ (तिनीहरू सामान्यतया घोषणा गर्दछन्), OpenAI को “gpt-4o” family मा अधिक सामान्य।
2. Announced deprecations। Provider ले “हामी मोडेल X लाई मिति Y मा retiring गर्दैछौँ” भन्दछ। तपाईंसँग migrate गर्न 3-12 महिना छ।
3. API contract परिवर्तनहरू। नयाँ request fields, नयाँ response formats, कहिलेकाहीँ breaking परिवर्तनहरू (दुर्लभ, तर हुन्छन्)।
4. Pricing परिवर्तनहरू। दर बढ्छ वा घट्छ; तपाईंको cost model रातारात परिवर्तन हुन्छ।
5. Availability / rate limits। नयाँ usage tiers, नयाँ regional restrictions।

प्रत्येकलाई फरक प्रतिक्रिया चाहिन्छ। सबैलाई तिनीहरू भएको थाहा पाउन चाहिन्छ।

Informed रहने

Provider drift को लागि हेर्नु एक साना monthly बानी हो:

• Provider changelogs मा subscribe गर्नुहोस्।

  • Anthropic: docs.anthropic.com/en/release-notes र तिनीहरूको status page।
  • OpenAI: तिनीहरूको changelog page र email announcements।
  • हरेक गम्भीर provider को घोषणा channel छ; subscribe गर्नुहोस्।

• Model pinning जाँच गर्नुहोस्। महिनामा एकपटक, आफ्नो MODEL = "..." constants हेर्नुहोस्। के pinned संस्करणहरू अझै fresh छन्? तिनीहरूसँग जोडिएका कुनै deprecation notices छन्?

• Pricing pages हेर्नुहोस्। Providers ले कहिलेकाहीँ मूल्यहरू घटाउँछन् (दुर्लभ तर अद्भुत) वा तिनीहरू बढाउँछन् (सामान्यतया notice सँग)। तदनुसार आफ्नो cost projections update गर्नुहोस्।

• Community forums monitor गर्नुहोस्। Reddit, HackerNews, र Discord servers ले providers ले आधिकारिक रूपमा स्वीकार गर्नु अघि व्यवहार परिवर्तनहरू surface गर्दछन्। Primary sources होइनन्, तर उपयोगी early signals।

महिनामा 15 मिनेट। “किन हाम्रो service टुटेको छ र कसैलाई थाहा छैन?” scenario लाई रोक्दछ।

नयाँ मोडेल संस्करण test गर्ने

जब Anthropic वा OpenAI ले नयाँ मोडेल release गर्दछ (वा अवस्थित pinned संस्करण update गर्दछ), यसको विरुद्ध आफ्नो eval set चलाउनुहोस्:

# In your eval runner
CANDIDATE_MODELS = {
    "current":    "claude-3-5-sonnet-20241022",
    "candidate":  "claude-3-5-sonnet-20250115",
}

for name, model in CANDIDATE_MODELS.items():
    results = run_eval(eval_set, model=model)
    print(f"{name}: correctness={results['correctness']}, cost=${results['cost']}")

तीन प्रश्नहरू:

1. के quality maintained वा improved छ?
2. के cost कम, बराबर, वा उच्च छ?
3. के latency comparable छ?

यदि quality बराबर वा राम्रो छ, cost बराबर वा कम छ, र latency comparable छ भने, migrate गर्नुहोस्। यदि यीमध्ये कुनै regress गर्दछ भने, निर्णय गर्नुहोस्: अन्य dimensions मा सुधार regression को लायकको छ कि छैन?

“newest मोडेल best हो” भनेर andhali migrate नगर्नुहोस्। Real projects ले nominally-राम्रो मोडेलहरूमा quality drops देखेका छन् किनकि नयाँ training data (वा नयाँ safety fine-tuning) ले तिनीहरूको use case मा विशिष्ट तरिकाहरूमा व्यवहार परिवर्तन गर्यो।

Deprecation notices सम्हाल्ने

Anthropic र OpenAI ले मोडेलहरू retiring गर्नुभन्दा अघि पर्याप्त notice (सामान्यतया 3-12 महिना) दिन्छन्। जब तपाईंले एउटा प्राप्त गर्नुहुन्छ:

1. Roadmap मा migration थप्नुहोस्। “कहिलेकाहीँ” होइन — एक specific target मिति, deprecation भन्दा कम्तिमा एक महिना अघि।
2. सिफारिस गरिएको replacement test गर्नुहोस्। नयाँ मोडेलमा eval set चलाउनुहोस्।
3. पहिले staging मा test गर्नुहोस्। एक हप्ताको लागि नयाँ मोडेल लाई staging मा deploy गर्नुहोस्। Metrics monitor गर्नुहोस्।
4. Canary सँग production मा roll out गर्नुहोस्। एक हप्ता भर 5%, 25%, 50%, 100%।
5. Configuration बाट पुरानो मोडेल reference retire गर्नुहोस्। एकपटक पूर्ण रूपमा migrated, कोडबाट पुरानो pinned संस्करण हटाउनुहोस्।

“Deprecation announced” र “deprecation happens” बीचको window पर्याप्त छ। असफल migrations लगभग सधैँ असफल हुन्छन् किनकि टिमले notice लाई अन्तिम हप्तासम्म ignore गर्यो।

API contract परिवर्तनहरू सम्हाल्ने

दुर्लभ, तर real। कहिलेकाहीँ provider ले API को request वा response आकार परिवर्तन गर्दछ।

Mitigation:

• SDK संस्करण pin गर्नुहोस्। मोडेल जस्तै, requirements.txt मा SDK लाई specific release मा pin गर्नुहोस् (anthropic==0.40.0, anthropic होइन)। SDK upgrades आफ्नै scheduled work हुन्।
• Upgrade गर्नुभन्दा अघि SDK changelog पढ्नुहोस्। नयाँ SDK versions मा कहिलेकाहीँ breaking परिवर्तनहरू हुन्छन्; changelog ले तिनीहरूलाई list गर्दछ।
• Integration tests राख्नुहोस्। एउटा सानो test जुन real API लाई call गर्दछ र response आकार assert गर्दछ, यसले हुँदा API-contract परिवर्तनहरू क्षणमै catch गर्दछ। यिनलाई रातभर चलाउनुहोस्।

जब provider drift खराब हुन्छ

कहिलेकाहीँ drift ले साँच्चै तपाईंको उत्पाद damage गर्दछ:

• नयाँ मोडेल संस्करणले तपाईंको eval मा 10% कम score गर्दछ।
• Pricing दोब्बर हुन्छ।
• Provider ले तपाईंको उत्पाद निर्भर feature deprecate गर्दछ।

विकल्पहरू:

• पुरानो संस्करणमा रहनुहोस् (यदि यो deprecated छैन भने)। कहिलेकाहीँ जवाफ “हामी upgrade गर्दैनौं” हुन्छ।
• फरक provider मा migrate गर्नुहोस्। Cross-provider migration real काम हो, तर यो long-term drift dependence विरुद्ध सबैभन्दा बलियो defence हो।
• Open-source मा migrate गर्नुहोस्। Local models (Llama, Mistral, Qwen) धेरै workloads को लागि बढ्दो रूपमा viable छन्। Trade-off हो कि तपाईं serving infrastructure लिनुहुन्छ।

Provider drift हो किन केही टिमहरूले दिन एकबाट multi-provider infrastructure को बोझ लिन्छन् — abstraction ले तिनीहरूलाई जब तिनीहरू must गर्दा switch गर्न दिन्छ। Nepal-scale उत्पादहरूको लागि, single-provider सामान्यतया ठीक छ, तर escape hatch लाई दिमागमा राख्नुहोस्।

Migration playbook

जब तपाईंले models, providers, वा embedding models switch गर्नुपर्दछ, ठोस चरणहरू:

1. परिवर्तन window freeze गर्नुहोस्। Migration को समयमा कुनै असम्बन्धित परिवर्तनहरू छैनन्।
2. Eval set विस्तार गर्नुहोस्। तपाईंले regress हुने चिन्ता गरेको areas लाई stress गर्ने specific test cases थप्नुहोस्।
3. Isolation मा test गर्नुहोस्। नयाँ मोडेल लाई eval set विरुद्ध चलाउनुहोस्। हरेक dimension score गर्नुहोस्।
4. A/B test पछाडि deploy गर्नुहोस्। प्रारम्भिक रूपमा 5%।
5. Production metrics तुलना गर्नुहोस्। Real-user thumbs, latency, cost।
6. Ramp up गर्नुहोस्। यदि metrics स्वस्थ देखिन्छन् भने एक हप्ता भर 25% → 50% → 100%।
7. पुरानो code path हटाउनुहोस्। एकपटक तपाईं सुनिश्चित छ कि नयाँ संस्करण पूर्ण deployed र stable छ।
8. Change log entry लेख्नुहोस्। भविष्यको तपाईंको लागि migration record गर्नुहोस्।

पूरै playbook: राम्ररी-managed migration को लागि 2-4 हप्ता calendar time। Rushed migrations जहाँ regressions आउँछन्।

Trust बजेट

हरेक migration ले user trust को थोरै मात्रा जल्दछ — केही queries ले अलिकति फरक जवाफहरू पाउनेछन्, केही regress गर्नेछन्। यसको लागि बजेट राख्नुहोस्।

यदि तपाईंको उत्पादको tone अनुमति दिन्छ भने प्रयोगकर्ताहरूलाई अर्थपूर्ण मोडेल migrations घोषणा गर्नुहोस्: “सोमबारदेखि, हामीले नयाँ मोडेलमा upgrade गर्यौं। तपाईंले thoughts अलिकति फरक जवाफहरू देख्न सक्नुहुन्छ जब हामी व्यवहार tune गर्दछौं। यदि कुनै degrade गर्दछ भने हामीलाई थाहा दिनुहोस्।” प्रयोगकर्ताहरू जसले परिवर्तन बुझ्दछन् साना variations स्वीकार गर्दछन्। नबुझ्नेहरूले यसलाई bug मान्दछन्।

One-off external event

Regular drift बाहेक, कहिलेकाहीँ एक ठूलो घटना हुन्छ: एक दिन सम्मको provider outage, तेजी API परिवर्तन प्रेरित गर्ने legal issue, forced model migration आवश्यक पर्ने security incident।

यीको लागि:

• Fallback provider राख्नुहोस्। तपाईंले विरलै प्रयोग गरे पनि, Claude र OpenAI दुबै integrated भएको मतलब तपाईंले एक घण्टामा switch गर्न सक्नुहुन्छ जब एउटाको खराब दिन हुन्छ।
• Public status page राख्नुहोस्। प्रयोगकर्ताहरूले honesty appreciate गर्दछन्। status.nepse-mitra.np “Provider outage को कारण हाल degraded; अपेक्षित समाधान 4 घण्टामा” silence भन्दा राम्रो हुन्छ।
• यदि तपाईंको उत्पाद बाहिरी services मा निर्भर छ भने “Nepal-safe” fallback राख्नुहोस्। यदि Nepal बाट Anthropic वा OpenAI पुग्न सकिँदैन (VPN block, provider outage, submarine cable cut) भने, तपाईंको service ले के गर्दछ? एक static “हामी अस्थायी रूपमा unavailable छौं” page पनि मृत URL भन्दा राम्रो हुन्छ।

Chapter 5 समाप्त

तपाईंसँग अब सुरक्षित रूपमा AI प्रणाली परिवर्तन गर्ने discipline छ। प्रत्येक axis version गर्नुहोस्। प्रत्येक परिवर्तन test गर्नुहोस्। बिस्तारै roll out गर्नुहोस्। बाहिरी drift को लागि हेर्नुहोस्। जब तपाईंले must गर्दा deliberately migrate गर्नुहोस्। प्रत्येक axis को लागि Rollback plans।

यीमध्ये कुनै पनि glamorous छैन। यीमध्ये सबै AI प्रणालीलाई तीन वर्ष टिक्ने प्रणाली र महिना छ पछि चुपचाप rot हुने AI प्रणालीबाट अलग गर्दछ।

अब के आउँछ

Chapter 6 Course 05 को अन्तिम chapter हो। यो operations engineering बाट Nepal मा AI उत्पाद चलाउने specific realities तिर shift हुन्छ: trust र privacy अपेक्षाहरू, legal र regulatory landscape (2026 मा अवस्थित छ), र practitioner को playbook जुन सबै कुरा जोड्दछ र पाठ्यक्रम बन्द गर्दछ।