Prompts, models, र data — परिवर्तनका तीन अक्ष

तीन axes

हरेक LLM प्रणालीसँग तीनवटा स्वतन्त्र चीजहरू छन् जुन परिवर्तन हुन सक्दछन्:

• Prompt। System prompt, few-shot उदाहरणहरू, retrieval-context format, output format।
• Model। Provider, model name, model version, parameters (temperature, max_tokens)।
• Data। तपाईंको RAG index मा documents, embeddings, chunk size, retrieval strategy।

कुनै एक axis मा परिवर्तनले व्यवहारमा असर गर्न सक्दछ। एक भन्दा बढी axis मा एकैचोटि परिवर्तनले कुन परिवर्तनले देखिने प्रभाव कारण दियो जान्न गाह्रो बनाउँछ। साना बानीहरूले यसलाई सम्हाल्न योग्य राख्दछन्।

किन यो matter गर्दछ

Real टिमहरूको real कथा: मंगलबार, कसैले system prompt कस्यो। उही दिन, कसैले नयाँ chunker सँग RAG corpus re-index गर्यो। बुधबार, thumbs-down rate बढ्यो। टिमले prompt वा chunker दोषी थियो कि थिएन एक हप्ता तर्क गर्यो। कुनै पनि cleanly reversible थिएन, किनकि “परिवर्तन” दुई परिवर्तनहरू सँगै tangled थियो।

Versioning र disciplined rollout ले axes अलग गर्दछ। एक पटकमा एउटा चीज परिवर्तन गर्नुहोस्। कुन परिवर्तनले कुन प्रभाव कारण दियो थाहा पाउनुहोस्। Confidence सँग roll back गर्नुहोस्।

Prompt version गर्नुहोस्

Prompts कोडमा हुनुपर्दछ, Google doc मा होइन:

# prompts.py
PROMPT_V1 = """You are a helpful assistant for Nepal's passport office FAQs.
Answer questions using only the documents provided..."""

PROMPT_V2 = """You are niyam, a helpful assistant for Nepal's passport office.
Follow these rules strictly:
1. Answer in the same language as the question.
2. Cite the document name after each fact.
..."""

CURRENT_PROMPT = PROMPT_V2
CURRENT_PROMPT_VERSION = "v2.0"

तपाईंको endpoint मा, prompt version सधैँ log गर्नुहोस्:

response = client.messages.create(
    model=CURRENT_MODEL,
    system=CURRENT_PROMPT,
    ...
)
log_event("model_call",
          request_id=request_id,
          prompt_version=CURRENT_PROMPT_VERSION,
          model=CURRENT_MODEL)

जब तपाईंले नयाँ prompt सँग प्रयोग गर्नुहुन्छ, यसलाई पुरानोसँग PROMPT_V3 को रूपमा थप्नुहोस्; traffic को अंश route गर्न A/B test infrastructure प्रयोग गर्नुहोस्। यदि यो जित्छ भने, यसलाई CURRENT_PROMPT मा promote गर्नुहोस् र V1 delete गर्नुहोस्। यदि यसले हार्छ भने, V3 delete गर्नुहोस्।

Version bump नगरी prompt लाई कहिल्यै place मा edit नगर्नुहोस्। Version tag ले prompt content लाई observed metrics सँग जोड्दछ।

Model version गर्नुहोस्

Model version सबैभन्दा सजिलै बिर्सिने हो। "claude-3-5-sonnet-latest" सुविधाजनक छ — जबसम्म Anthropic ले “latest” कुरालाई point गर्दैछ त्यो update गर्दैन, र तपाईंको service ले चुपचाप व्यवहार परिवर्तन गर्दैन।

नियम: production code मा ठ्याक्कै model version pin गर्नुहोस्।

# Not this:
MODEL = "claude-3-5-sonnet-latest"

# This:
MODEL = "claude-3-5-sonnet-20241022"

Trade-off: Pinned models ले स्वचालित सुधारहरू पाउँदैनन्। त्यो नै point हो। जब Anthropic ले नयाँ संस्करण ship गर्दछ, तपाईं आफ्नो timeline मा आफ्नो eval set विरुद्ध नयाँ संस्करण evaluate गर्नुहुन्छ, र switch गर्नुहुन्छ जब तपाईं निर्णय गर्नुहुन्छ।

OpenAI, Gemini, र हरेक provider को लागि उही तर्क। gpt-4o-2024-11-20, gpt-4o होइन।

Data version गर्नुहोस्

RAG systems परिवर्तन हुन्छन् हरेक पटक underlying documents परिवर्तन हुन्छन् वा index rebuild हुन्छ। Index को हरेक संस्करण प्रणालीको व्यवहारको एक संस्करण हो।

Track गर्नुहोस्:

• Document version। हरेक source कागजातसँग version छ (hr-policy-v3.pdf, वा source repo को git SHA)।
• Chunking strategy। Chunk size, overlap, र boundary नियमहरू version का भाग हुन्।
• Embedding model। प्रयोग गरिएको embedding मोडेल (text-embedding-3-small-v1, वा versioned local मोडेल)।
• Index build timestamp। यो specific index कहिले निर्माण भयो?

Version identifier सँग हरेक index build tag गर्नुहोस्:

INDEX_VERSION = "2026-06-15-hr-v3-embed-3s"

हरेक request मा, कुन index संस्करणले यसलाई सर्भ गर्यो log गर्नुहोस्:

log_event("retrieval",
          request_id=request_id,
          index_version=INDEX_VERSION,
          top_k=3,
          top_score=hits[0]["score"])

जब तपाईंले re-index गर्नुहुन्छ, नयाँ versioned index उत्पादन गर्नुहोस् र यसलाई promote गर्नुभन्दा पहिले नयाँलाई current सँग A/B test गर्नुहोस्।

Change log

हरेक AI प्रणालीको लागि, एउटा change log राख्नुहोस् — एक file (वा dashboard) जुन हरेक axis मा हरेक परिवर्तन record गर्दछ, timestamps सँग:

2026-05-01  10:14  MODEL     Switched sonnet-3-5-20240620 → sonnet-3-5-20241022
2026-05-08  15:32  PROMPT    v1.2 → v1.3 (adjusted refusal wording)
2026-05-15  09:00  DATA      Reindexed HR corpus (v3.1 → v4.0, new chunker)
2026-05-22  14:11  PROMPT    v1.3 → v1.4 (added Nepali script normalisation instruction)
2026-06-01  11:00  MODEL     A/B test: 50% traffic to haiku-4-5 for cost savings

जब metrics move हुन्छन्, change log पहिलो ठाउँ हो जहाँ तपाईंले हेर्नुहुन्छ। “2026-05-16 मा thumbs-down बढ्यो — के परिवर्तन भयो?” → “हामीले 2026-05-15 मा reindex गर्यौं।” → जाँच।

यो log बिना, हरेक regression जाँच archaeology हो। यसको साथ, यो database query हो।

Rollback contract

प्रत्येक axis को लागि, कसरी roll back गर्ने थाहा पाउनुहोस्:

• Prompt rollback। तुच्छ — constant revert गर्नुहोस्, redeploy गर्नुहोस्।
• Model rollback। Pinned संस्करण फिर्ता परिवर्तन गर्नुहोस्, redeploy गर्नुहोस्। दुई मिनेट recovery।
• Data rollback। पछिल्लो index लाई नयाँ को साथसाथै कम्तिमा 7 दिन राख्नुहोस्। यदि नयाँ index ले regressions कारण गर्दछ भने, pointer लाई पुरानोमा फिर्ता swap गर्नुहोस्।

यदि कुनै axis सँग rollback plan छैन भने, तपाईंसँग पूर्ण versioning छैन। अर्को परिवर्तन ship गर्नुभन्दा अघि यसलाई fix गर्नुहोस्।

Dependency graph

केही परिवर्तनहरू axes पार गर्दछन्:

• Embedding model परिवर्तन गर्दा सबै कागजातहरू re-embedding चाहिन्छ (index incompatible हुन्छ)।
• Model provider परिवर्तन गर्दा prompt का भागहरू पुनर्लेख आवश्यक हुन सक्दछ (Anthropic र OpenAI कुरामा फरक प्रतिक्रिया दिन्छन्)।
• Chunk size परिवर्तन गर्दा specific top-K retrieval व्यवहारलाई invalidate गर्दछ।

यी dependencies note गर्नुहोस्। जब cross-axis परिवर्तन unavoidable छ, यसलाई स्पष्ट रूपमा योजना गर्नुहोस्: एउटा deploy जुन coupled axes एकसाथ मात्र परिवर्तन गर्दछ, कुनै पनि अन्य परिवर्तन अघि stabilisation अवधि द्वारा पछ्याइएको।

एक-चीज-एक-पटक बानी

दैनिक कार्यमा concrete नियम:

• कुनै deploy ले स्पष्ट रूपमा आवश्यक नभएसम्म एक भन्दा बढी axis परिवर्तन गर्दैन।
• हरेक परिवर्तन incremented version tag सँग ship हुन्छ।
• हरेक परिवर्तन सम्भव हुँदा A/B tested हुन्छ।
• हरेक परिवर्तन change log मा logged हुन्छ।
• प्रत्येक ship पछि 24-48 घण्टाको लागि Metrics हेरिन्छ।

यीमध्ये हरेकले friction थप्दछ। त्यो friction महिनौं भर बुझ्न योग्य प्रणालीको मूल्य हो। Friction skip गर्नु भनेको कसरी AI systems आफ्नै creators ले debug गर्न नसक्ने रहस्यहरू बन्दछन्।

“राम्रो versioning” कस्तो लाग्दछ

एक well-versioned AI प्रणालीका यी गुणहरू छन्:

• कुनै पनि मितिबाट कुनै पनि जवाफ दिइएमा, तपाईंले ठ्याक्कै भन्न सक्नुहुन्छ कुन prompt, कुन model, कुन index ले यसलाई उत्पादन गर्यो।
• जब metrics move हुन्छन्, तपाईंले कुन परिवर्तन (वा परिवर्तनहरूको कुन combination) ले यसलाई कारण दियो एक घण्टा भित्र जाँच गर्न सक्नुहुन्छ।
• कुनै एकल परिवर्तन rolling back मा दिन होइन, मिनेटहरू लाग्दछन्।
• “प्रणाली आज कस्तो व्यवहार गर्दछ” vs. “यो एक महिना अघि कस्तो व्यवहार गर्थ्यो” तुलना गर्नु queryable प्रश्न हो, कसैले सम्झिनु पर्ने कथा होइन।

यदि तपाईंको प्रणालीमा यी गुणहरू छन् भने, तपाईं सुरक्षित रूपमा iterate गर्न सक्नुहुन्छ। यदि छैन भने, हरेक परिवर्तन बाँकी सबै कुराको अदृश्य state विरुद्ध जुवा हो।

अब के आउँछ

तपाईंलाई थाहा छ तीन axes कसरी version गर्ने। अर्को खण्ड ती axes मा परिवर्तनहरू सुरक्षित रूपमा roll out कसरी गर्ने हो — canary deploys, staged rollouts, र specific patterns जुन खराब परिवर्तनलाई सबै प्रयोगकर्ताहरूमा एकैचोटि पुग्नबाट रोक्दछन्।