Prompts, मॉडल और Settings versioned artefacts के रूप में

व्यवहार = prompt + मॉडल + settings + डेटा

LLM सुविधा का व्यवहार एक बंडल से तय होता है: prompt templates, मॉडल का नाम और संस्करण, sampling settings (temperature, max tokens), tool परिभाषाएँ, retrieval configuration (chunking, embedding model, k) और कोई fine-tuned adapters। कोई भी हिस्सा बदलें तो व्यवहार बदलता है। इसलिए बंडल को versioned artefact मानें: prompts को version control में files के रूप में रखें (बिखरी strings नहीं), बदलावों की pull requests में समीक्षा करें, हर release को version ID दें, और वह ID हर अनुरोध के साथ logs में दर्ज करें। जहाँ provider तिथि वाले identifiers दे वहाँ मॉडल संस्करण pin करें, क्योंकि चुपचाप provider अद्यतन परिणाम बदल सकते हैं; deprecations की योजना बदलने से पहले प्रतिस्थापन के विरुद्ध अपना मूल्यांकन set दोबारा चलाकर बनाएँ। "पिछले मंगलवार इस उत्तर को किस prompt और मॉडल ने बनाया?" का उत्तर दे पाना debugging, audits और rollbacks की नींव है।

Version करें, द्वार लगाएँ, बाँधें

Prompts, मॉडल और settings को release द्वारों वाले versioned artefacts मानें, और आउटपुट बाँधें ताकि कोड उन पर भरोसा कर सके।

Release manifest

एक file जो व्यवहार तय करने वाली हर चीज़ pin करती है। उदाहरण; नाम placeholders हैं।

{
  "release": "support-assistant-2026.10.2",
  "prompt": { "file": "prompts/support_v14.md", "sha256": "<hash of the file>" },
  "model": { "provider": "<provider>", "name": "<dated-model-id>", "temperature": 0.2, "max_tokens": 500 },
  "retrieval": { "embedding_model": "<embedding-id>", "chunk_tokens": 300, "top_k": 5, "reranker": "<reranker-id>" },
  "tools": ["get_order", "propose_refund"],
  "eval": { "set": "evals/support_v7.jsonl", "pass_rate": 0.93, "date": "2026-10-01" }
}

तिथि वाले मॉडल identifiers pin करें

जहाँ उपलब्ध हो, चलते alias की जगह निश्चित मॉडल संस्करण का नाम बताने वाला identifier उपयोग करें।

त्वरित जाँच: हर अनुरोध के साथ release version ID क्यों दर्ज करें?

• ताकि आप किसी भी उत्तर को ठीक prompt, मॉडल और settings तक खोज सकें
• अनुरोध बड़े करने के लिए
• क्योंकि APIs को यह चाहिए
• इसका कोई उपयोग नहीं