कंपनी LLM से चलने वाला summary फीचर जोड़ना चाहती है। यह ship करने लायक अच्छा है या नहीं, आप कैसे evaluate करेंगे?

कुछ भी generate करने से पहले तय करें कि इस काम के लिए अच्छा का मतलब क्या है, फिर असली inputs का एक तय evaluation set बनाएं जिसके outputs rubric से scored हों। अपने आप चलने वाली जांचें (source के मुकाबले factual consistency, format की वैधता, refusal और latency दरें) को नमूने पर इंसानी review के साथ मिलाएं। किसी flag के पीछे ship करें, downstream यूजर बर्ताव मापें, और eval set को model version बदलने के लिए regression suite की तरह बनाए रखें।

यहां जाल यह है कि पहले दस outputs हमेशा शानदार लगते हैं और सब ship करना चाहते हैं। तो कुछ भी generate करने से पहले मैं लिख लेता हूं कि अच्छा का मतलब क्या है: source दस्तावेज के प्रति ईमानदार, मुख्य बिंदुओं को समेटने वाला, सही लंबाई का, बिना गढ़े हुए तथ्यों के। फिर मैं कुछ सौ असली inputs निकालता हूं, सुंदर वाले नहीं बल्कि मुश्किल मामलों की तरफ झुके हुए, और उसे evaluation set के तौर पर जमा देता हूं। अपने आप चलने वाली तरफ मैं source के मुकाबले factual consistency, format की वैधता और refusal rate जांचता हूं, और rubric scores के लिए model as judge इस्तेमाल करता हूं, पर तभी जब उसे किसी हिस्से पर इंसानी grades से calibrate कर लूं, क्योंकि बिना जमीन वाला judge ज्यादातर अपने ही साथ सहमत रहता है। हर चक्र में एक नमूने को इंसान फिर भी grade करता है। फिर मैं इसे किसी flag के पीछे traffic के एक हिस्से पर ship करता हूं और देखता हूं कि यूजर असल में करते क्या हैं: क्या वे summary को edit करते हैं, क्या वे फिर भी पूरा दस्तावेज खोलते हैं। वही downstream बर्ताव असली metric है। और मैं eval set को regression suite की तरह रखता हूं, क्योंकि जब provider आपके नीचे model अपडेट करता है तो बर्ताव खिसक जाता है, और यह आप support tickets से नहीं, अपने ही tests से जानना चाहेंगे।