LLM बदलावों के लिए Release Gates और CI

हर बदलाव पर मूल्यांकन चलाएँ

Prompt संपादन कोड बदलाव है और उसी सुरक्षा जाल का हक़दार है। Continuous integration में चलाएँ: निश्चित कोड (parsing, routing, नीति) के लिए fake मॉडलों वाले तेज़ unit tests, उम्मीदवार बंडल के विरुद्ध मूल्यांकन set, सुरक्षा attack suite, और लागत व latency जाँचें। फिर स्पष्ट नियमों वाला द्वार लगाएँ, जैसे: समग्र pass rate शोर-मार्जिन से ज़्यादा न गिरे और लक्ष्य से ऊपर रहे; कोई श्रेणी तय मात्रा से अधिक न गिरे; शून्य गंभीर सुरक्षा विफलताएँ; p95 latency और औसत लागत बजट में। समीक्षक को पलटे मामलों का diff दिखाएँ। असली मॉडलों से पूर्ण मूल्यांकन पैसा और समय लेते हैं, इसलिए हर commit पर छोटा smoke उपसमूह और merge या release से पहले पूरा set चलाएँ। द्वार विफल हो तो उपाय जाँच है, सीमा ढीली करना नहीं।

नियमों के रूप में release द्वार

सीमाएँ उदाहरण हैं। मुद्दा यह है कि निर्णय यांत्रिक और लिखित है।

GATE (all must hold, else block the merge)
1. unit tests (fake models): all pass
2. eval pass rate >= 0.92 AND not lower than baseline by more than 0.02 (the noise margin)
3. no category drops by more than 0.05; Hindi/Hinglish category checked separately
4. attack suite: 0 critical successes; <= 2% minor
5. p95 latency <= 3.0 s; mean cost per request <= 1.1 x baseline
6. reviewer has seen the list of flipped cases (fixed vs broken)

If the gate fails: investigate the flipped cases. Do not just lower the threshold.

प्रति commit छोटा smoke set उपयोग करें

हर commit पर तेज़ जाँचें और merge से पहले पूर्ण मूल्यांकन गति और लागत का संतुलन बनाते हैं।

त्वरित जाँच: Release द्वार विफल हो तो क्या करना चाहिए?

• विफल मामले हटाएँ
• सीमा घटाएँ
• एक बार द्वार छोड़ दें
• पलटे मामलों की जाँच करें और कारण ठीक करें