Versioning, Drift और सेवानिवृत्ति

सब कुछ version करें, दोबारा प्रशिक्षण की योजना बनाएँ

हर tuned मॉडल के लिए दर्ज करें: बेस मॉडल और version, dataset version और hash, hyperparameters और seed, code commit, मूल्यांकन परिणाम और तारीख़, ताकि आप दोबारा बना या rollback कर सकें। दोबारा प्रशिक्षण की अपेक्षा रखें: providers बेस मॉडल सेवानिवृत्त करते हैं, आपका डेटा और उपयोगकर्ता drift करते हैं, और नए बेस मॉडल सादे prompt से भी आपके tuned मॉडल को हरा सकते हैं। मूल्यांकन set और pipeline स्वचालित रखें ताकि दोबारा प्रशिक्षण में घंटे लगें, सप्ताह नहीं। लाइव गुणवत्ता, लागत और format वैधता monitor करें, समीक्षा को आउटपुट का नमूना लें, और पिछले version या prompted fallback तक प्रलेखित rollback रखें।

Model card रिकॉर्ड

हर जारी मॉडल के साथ इसे रखें।

model:        tickets-router-v3
base:         <base model id and version>
data:         tickets-2026-09 (sha256 abc123..., 8,000 rows, group split)
method:       LoRA r=8, lr=2e-4, 2 epochs, seed 42
code:         <commit>
eval:         held-out 600 tickets, report with 95% interval
safety:       refusal + regression suite passed on <date>
fallback:     prompted model <id>
owner/review: <name>, re-evaluate every quarter or on base-model retirement

पुनः मूल्यांकन निर्धारित करें

नवीनतम अनट्यून बेस मॉडलों समेत मूल्यांकन का त्रैमासिक पुनः-run कैलेंडर में रखें; कभी-कभी अपना tuned मॉडल हटाना सही निर्णय होता है।

त्वरित जाँच: हर tuned मॉडल के लिए dataset version और बेस मॉडल क्यों दर्ज करें?

• क्योंकि नियामक logging मना करते हैं
• मॉडल छोटा करने के लिए
• ताकि मॉडल दोबारा बनाया, तुलना और rollback किया जा सके
• इसका कोई व्यावहारिक उपयोग नहीं