दस्तावेज़, भूमिकाएँ और टीम अभ्यास

लिखें कि system क्या है और क्या नहीं

LLM सुविधाएँ अपने लेखकों से लंबी जीती हैं, इसलिए उन्हें दस्तावेज़ित करें। छोटा system card (या मॉडल/सुविधा card) बताता है: उद्देश्य और इच्छित users, किसके लिए उपयोग नहीं होना चाहिए, उपयोग किया डेटा, मॉडल व prompt संस्करण, मूल्यांकन कैसे हुआ (sets, metrics, परिणाम, ज्ञात कमज़ोरियाँ), सुरक्षा नियंत्रण, मानव निरीक्षण, monitoring और किससे संपर्क करें। महत्वपूर्ण चुनावों और उनके कारणों का निर्णय log रखें (मॉडल चयन, सीमाएँ, समझौते)। भूमिकाएँ तय करें: prompts और releases का स्वामी कौन, सुरक्षा समीक्षा कौन करता है, user रिपोर्ट का triage कौन, on-call कौन, मूल्यांकन set में बदलाव कौन अनुमोदित करता है। घटनाओं के बाद दोषारोपण-रहित समीक्षाएँ करें, नमूना बातचीतों की नियमित गुणवत्ता समीक्षाएँ रखें, और निष्कर्ष टीमों में साझा करें। Developers और support स्टाफ़ को LLMs की सीमाओं पर प्रशिक्षित करें ताकि वे users के साथ सटीक अपेक्षाएँ रख सकें। अच्छा दस्तावेज़ onboarding और audits भी तेज़ करता है।

एक-पन्ने के system card की रूपरेखा

अपनी सुविधा के लिए भरें और कोड के बग़ल में रखें।

Name / owner / contact:
Purpose and intended users:
Out of scope (do NOT use for):
Model, prompt and retrieval versions (release ID):
Data used (sources, personal data, retention):
Evaluation: sets, metrics, latest results, known weaknesses, languages covered
Safety controls: output handling, tool policy, approvals, rate/spend caps, red-team status
Human oversight and escalation path:
Monitoring: dashboards, alerts, feedback loop, review cadence
Change history / decision log:

System card को कोड के बग़ल में रखें

कोड के साथ रहने वाला दस्तावेज़ अद्यतन रहने की अधिक संभावना रखता है।

त्वरित जाँच: System card में "दायरे से बाहर" उपयोग क्यों शामिल करें?

• कोई कारण नहीं
• दस्तावेज़ छोटा करने के लिए
• क्योंकि क़ानून उपयोग सूचीबद्ध करना मना करता है
• ताकि सुविधा का उन स्थितियों में दुरुपयोग रोका जा सके जिनके लिए वह परखी या डिज़ाइन नहीं हुई