मूल्यांकन

docs.scrimba.com

आप एक प्रॉम्प्ट बदलते हैं, इसे एक बार आजमाते हैं, उत्तर बेहतर लगता है, और आप शिप करते हैं, फिर एक हफ्ते बाद उपयोगकर्ता उन मामलों को हिट करते हैं जिन्हें यह चुप करके बदतर बना देता है। एक मूल्यांकन (मूल्यांकन के लिए संक्षिप्त) समाधान है: यह परीक्षण करने का एक दोहराया जा सकने वाला तरीका है कि आपकी AI सुविधा काम करती है या नहीं, यह इनपुट का एक सेट है जो यह दिखाता है कि एक अच्छा आउटपुट कैसा दिखता है, और हर बार एक ही तरीके से स्कोर किया जाता है ताकि आप बता सकें कि क्या कोई परिवर्तन वास्तव में मदद करता है। एक मॉडल एक संभाव्य ब्लैक बॉक्स है जो एक ही सवाल का हर रन में अलग तरीके से जवाब देता है, इसलिए मापना ही एकमात्र तरीका है जानने का, और यह अनुशासन एक डेमो को एक उत्पाद से अलग करता है।

आंखों से देखना क्यों विफल होता है

अपने AI के उत्तरों को हाथ से जांचना पहली बार ठीक लगता है। आप एक प्रॉम्प्ट चलाते हैं, जवाब पढ़ते हैं, और यह अच्छा लगता है, तो आप आगे बढ़ते हैं। समस्या यह है कि तीन चीजें चुप करके आपके खिलाफ काम करती हैं, और आपने सभी से पहले ही मिल चुके हैं।

ये तीन हैं:

• आउटपुट भिन्न होता है। एक ही प्रॉम्प्ट हर रन में विभिन्न उत्तर दे सकता है, इसलिए एक अच्छा परिणाम यह वादा नहीं करता कि अगला भी अच्छा होगा।
• परिवर्तन प्रतिगमन का कारण बनते हैं। एक प्रॉम्प्ट संपादन जो एक मामले को ठीक करता है, अक्सर दूसरे को तोड़ देता है जिस पर आप नहीं देख रहे थे।
• यह स्केल नहीं करता है। आप पांच उत्तर पढ़ सकते हैं। आप हर बार जब आप एक लाइन बदलते हैं तो पांच सौ नहीं पढ़ सकते।

इसका मतलब यह नहीं है कि आपने कुछ गलत किया है। इसका मतलब है कि आंखों से देखना इस आकार के काम के लिए गलत उपकरण है, और इसे करने का एक शांत तरीका है।

Junoआंखों से देखना क्यों विफल होता है हाथ से उत्तर पढ़ना तीन कारणों से टूट जाता है, ये सभी इस बात से जुड़े हैं कि मॉडल कैसे काम करता है: आउटपुट रन दर रन भिन्न होता है, संपादन चुप करके उन मामलों को तोड़ते हैं जिन पर आप नहीं देख रहे थे, और एक बार सैकड़ों उत्तर हो जाने पर आप हाथ से नहीं रख सकते। यह अनुशासन समस्या नहीं है, यह काम के आकार के लिए गलत उपकरण है। अच्छी खबर यह है कि समाधान दोस्ताना है, और यह आ रहा है।

एक जवाब आंखों से देखना आपको लगभग कुछ नहीं बताता है, और कारण यह है कि मॉडल कैसे काम करता है। क्योंकि आउटपुट गैर-निर्धारक है (एक ही प्रॉम्प्ट हर रन में विभिन्न उत्तर दे सकता है), एक एकल जवाब एक का नमूना है। यह आपको पास दर नहीं बता सकता है, जो मामलों का हिस्सा है जो सही आते हैं, क्योंकि आपको एक ही मामलों पर कई रन की आवश्यकता है यह अनुमान लगाने के लिए कि यह वास्तव में कितनी बार काम करता है।

प्रतिगमन एक संबंधित कारण के लिए छिपे होते हैं। एक मामले को हाथ से ठीक करें और आपके पास दूसरों का कोई रिकॉर्ड नहीं है, तो अगला संपादन कुछ ऐसा तोड़ सकता है जिस पर आप नहीं देख रहे थे। इसे देखने का एकमात्र तरीका मामलों का एक निर्धारित सेट है जिसे हर बार एक ही तरीके से स्कोर किया जाता है, इसलिए गिरावट एक आश्चर्य के बजाय एक संख्या के रूप में दिखता है।

संख्या के ऊपर एक मानवीय समस्या है। मैनुअल समीक्षा लोगों के बीच और मनोदशा के बीच भटकती है: एक ही उत्तर सोमवार को ठीक पढ़ता है और शुक्रवार को कमजोर। इसलिए यह कदम "यह अच्छा लगता है" को मामलों के एक निर्धारित सेट पर एक मापा पास दर में परिवर्तित करना है। एक भावना को एक ही मामलों पर एक संख्या में बदलें।

Junoआंखों से देखना क्यों विफल होता है एक जवाब एक का नमूना है, इसलिए यह आपको बताता है कि मॉडल एक बार काम करता है, न कि यह कितनी बार काम करता है। एक वास्तविक पास दर देखने के लिए आप कई मामलों को चलाते हैं; प्रतिगमन को पकड़ने के लिए आप मामलों के उस सेट को ठीक करते हैं और हर बार इसे एक ही तरीके से स्कोर करते हैं। मैनुअल समीक्षा समीक्षक के साथ भी बहती है, इसलिए काम "अच्छा लगता है" को एक मापा संख्या से बदलना है।

स्पॉट-जांच विफल नहीं होती क्योंकि आप लापरवाह हैं। यह विफल होता है क्योंकि इसमें चयन पूर्वाग्रह बनाया गया है: आप उन मामलों को देखते हैं जिनके काम करने की उम्मीद करते हैं, इसलिए व्यवहार जिसे आप कभी नहीं देखते हैं वह है जो उपयोगकर्ताओं के सामने वापस आता है। मीट्रिक जिसे आप ट्रैक नहीं करते हैं वह बिल्कुल वह है जो चलता है।

एक बेसलाइन स्कोर के बिना, हर गुणवत्ता परिवर्तन एक कहानी है जिसे आप अपने आप को बताते हैं। आप एक शिफ्ट को एक विशिष्ट संपादन के लिए जिम्मेदार नहीं ठहरा सकते, और आप परिवर्तनों के एक सेट को द्विभाजित नहीं कर सकते यह खोजने के लिए कि कौन सा पास दर को गिराता है (आपके मामलों का हिस्सा जो सही आते हैं), क्योंकि आपने पहले कभी मापा नहीं है। "यह बेहतर लगता है" बना रहता है क्योंकि कुछ भी इसका विरोध नहीं करता।

भावनाएं-आधारित पुनरावृत्ति भी ओवरफिट करती है। आप एक ही मुट्ठी भर उदाहरणों को दोबारा टाइप करते रहते हैं, जब तक ये सही न दिखें तब तक समायोजित करते हैं, और चुप करके अपने प्रॉम्प्ट को उस छोटे निजी सेट में प्रशिक्षित करते हैं जबकि वास्तविक ट्रैफिक कहीं और भटक जाता है। मैनुअल समीक्षा उस वितरण में बदलाव नहीं देख सकती, क्योंकि नए इनपुट वे हैं जिन्हें आप टाइप नहीं कर रहे हैं। एक संस्करणित मूल्यांकन सेट और एक ट्रैक किया गया स्कोर यह कहने का एकमात्र तरीका है कि एक परिवर्तन मदद करता है न कि बेहतर महसूस होता है, और यह पुनरावृत्ति और अनुमान के बीच का अंतर है।

Junoआंखों से देखना क्यों विफल होता है मैंने भावनाओं पर शिप किया है और फिर देखा है कि एक रास्ता जिसे मैंने कभी स्पॉट-जांच नहीं किया त्रुटि लॉग को रोशन करता है, यह अपना काम करते समय चयन पूर्वाग्रह है। कोई बेसलाइन मतलब नहीं जिम्मेदारी और द्विभाजन नहीं: आप साबित नहीं कर सकते कि कौन सा संपादन संख्या को स्थानांतरित करता है यदि आपके पास कभी संख्या नहीं थी। एक संस्करणित सेट और एक ट्रैक किया गया स्कोर रखें, या आप पांच उदाहरणों पर ओवरफिट कर रहे हैं जिन्हें आप बार-बार टाइप करते हैं जबकि वास्तविक ट्रैफिक एक जगह की ओर बढ़ता है जहां आप नहीं देख सकते।

एक मूल्यांकन सेट बनाएं

एक मूल्यांकन सेट परीक्षण मामलों की एक सूची है। प्रत्येक मामले में एक इनपुट है और इसके लिए एक अच्छा आउटपुट कैसा दिखता है। छोटे से शुरू करें। दस से बीस मामले जो आपकी सामान्य परिस्थितियों को कवर करते हैं और कुछ मुश्किल किनारे के मामले किसी से कहीं अधिक उपयोगी हैं, और आप जंगली में नई विफलताओं को खोजने के समय सेट को बढ़ा सकते हैं।

eval_set = [
    {"input": "खाना ठंडा और देरी से आया।", "expected": "NEGATIVE"},
    {"input": "मेरी जिंदगी का सबसे अच्छा भोजन!", "expected": "POSITIVE"},
    {"input": "यह ठीक था, कुछ विशेष नहीं।", "expected": "NEUTRAL"},
    # ...जैसे-जैसे आप उन्हें खोजते हैं, वास्तविक मामले और किनारे के मामले जोड़ें
]

जब कोई उपयोगकर्ता एक बुरा उत्तर की रिपोर्ट करता है, तो इसे सेट में जोड़ें जो आउटपुट देना चाहिए था। आपका मूल्यांकन सेट फिर हर गलती की एक बढ़ती हुई स्मृति बन जाता है जिसे आप फिर कभी नहीं करना चाहते, उसी तरह से एक बग जिसे आप ठीक करते हैं एक परीक्षण बन जाता है जिसे आप रखते हैं।

Junoएक मूल्यांकन सेट बनाएं एक मूल्यांकन सेट परीक्षण मामलों की एक सूची है: एक इनपुट, और एक अच्छा उत्तर कैसा दिखता है। दस से बीस के साथ शुरू करें जो आपकी रोज़मर्रा की परिस्थितियों और कुछ मुश्किल लोगों को कवर करते हैं। हर बार जब कोई उपयोगकर्ता एक बुरा उत्तर को हिट करता है, इसे उस उत्तर के साथ जोड़ें जो देना चाहिए था, और आपका सेट चुप करके हर गलती को याद रखता है जिसे आप दोहराना नहीं चाहते।

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

तीन चीजों को कवर करने का लक्ष्य रखें: सामान्य पथ जो आपके उपयोगकर्ता वास्तव में हिट करते हैं, निर्णय सीमाएं जहां दो लेबल करीब बैठते हैं (अस्पष्ट मामले सही लाइन पर), और ज्ञात विफलता मोड जिन्हें आप पहले से ही गलत देख चुके हैं। चेरी-उठाई गई दोस्ताना इनपुट आपके स्कोर को अच्छा दिखाती है और आपको कुछ नहीं बताती, इसलिए सेट को वास्तविक ट्रैफिक का प्रतिनिधि रखें।

हर बग जो एक उपयोगकर्ता रिपोर्ट करता है सेट में एक स्थायी मामला बन जाता है। यह इसे एक प्रतिगमन सूट में बदल देता है: एक निर्धारित बग तय रहता है क्योंकि मामला जिसे इसे उजागर किया वह हर बार चलता है। जब आपके अपेक्षित आउटपुट संरचित हों मुक्त पाठ के बजाय, जैसे एक लेबल या JSON फील्ड, आप सटीक-मैच तुलना के साथ ग्रेड कर सकते हैं, जो स्वच्छ और स्पष्ट है, संरचित आउटपुट देखें।

एक अलग आयोजित-बाहर स्लाइस रखें जिस पर आप कभी ट्यून नहीं करते हैं। यदि आप प्रॉम्प्ट को समायोजित करते हैं जब तक आप सटीक मामलों को पास नहीं करते हैं जिन पर आप नजर रख रहे हैं, तो आप उत्तरों पर अपने आप को ग्रेड कर रहे हैं जिसका आपने पहले ही अध्ययन किया है, और स्कोर कुछ भी नहीं का मतलब बंद हो जाता है।

Junoएक मूल्यांकन सेट बनाएं कवरेज कच्चे आकार को हराता है: सामान्य पथ, लेबल के बीच अस्पष्ट सीमाएं, और विफलताएं जिन्हें आप पहले से ही देख चुके हैं। हर रिपोर्ट किए गए बग को एक स्थायी मामले में बदलें ताकि सेट एक प्रतिगमन सूट की तरह काम करे। एक आयोजित-बाहर स्लाइस रखें जिस पर आप कभी ट्यून नहीं करते हैं, या आप उन उत्तरों पर अपने आप को ग्रेड कर रहे हैं जिसका आपने अध्ययन किया।

मूल्यांकन सेट को एक संपत्ति के रूप में मानें जिसे आप प्रॉम्प्ट के बगल में संस्करण करते हैं, क्योंकि दोनों एक साथ चलते हैं और एक प्रॉम्प्ट परिवर्तन चुप करके बदल सकता है कि अच्छे उत्तर के रूप में क्या गिना जाता है। सेट की लेबल गुणवत्ता आपके मीट्रिक पर छत है: एक गलत "अपेक्षित" मान आपके स्कोर को सीमित करता है और चुप करके आपको गलत सबक सिखाता है, इसलिए सावधानी से लेबल क्यूरेट करना केस एकत्रित करने जितना महत्वपूर्ण है।

परीक्षण लीकेज से बचें। यदि आप सटीक सेट को पास करने तक ट्यून करते हैं जिसे आप रिपोर्ट करते हैं, तो संख्या थिएटर है। एक स्लाइस को तब तक रखें जब तक आप पुनरावृत्ति करते समय नहीं देखते, और इसे समय के साथ घुमाएं ताकि यह धीरे-धीरे अपनी ट्यूनिंग लूप में न लीक हो जाए।

वर्ग संतुलन देखें। एक सेट जो नब्बे प्रतिशत स्पष्ट-कट सकारात्मक है, जबकि दस प्रतिशत पर हर विफलता को छिपाते समय एक खुशहाल संख्या की रिपोर्ट करेगा जो वास्तव में महत्वपूर्ण है, इसलिए नमूने ताकि मुश्किल और दुर्लभ मामले वास्तविक वजन ले जाएं। उत्पादन लॉग से कल्पना के बजाय मामले खींचें, क्योंकि वास्तविक ट्रैफिक वाक्यांशों को सतह पर लाता है जिन्हें आप अपने डेस्क पर कभी नहीं देते।

स्वीकार करें कि सेट सड़ता है। जैसे-जैसे उत्पाद बदलता है, पुराने मामले यह प्रतिबिंबित करना बंद कर देते हैं कि उपयोगकर्ता भेजते हैं और नई विफलता के तरीके दिखाई देते हैं जिन्हें सेट ने कभी नहीं देखा है। इसे क्यूरेट करना चल रहा काम है, एक-बार का निर्माण नहीं।

Junoएक मूल्यांकन सेट बनाएं सेट एक संपत्ति है जिसे आप प्रॉम्प्ट के बगल में संस्करण करते हैं, और इसकी लेबल गुणवत्ता आपके मीट्रिक की कठिन छत है, एक बुरा अपेक्षित मान पूरे स्कोर को सीमित करता है। एक स्लाइस को रखें और घुमाएं, या आपकी रिपोर्ट की गई संख्या थिएटर है। वर्ग संतुलन देखें, लॉग से वास्तविक मामले नमूना करें, और मान लें कि सेट सड़ता है जैसे-जैसे उत्पाद चलता है, इसलिए इसे क्यूरेट करना कभी वास्तव में समाप्त नहीं होता।

कैसे ग्रेड करें

विभिन्न कार्यों को विभिन्न ग्रेडिंग की आवश्यकता है, इसलिए पहला कदम जांच को आपके द्वारा अपेक्षित उत्तर के प्रकार से मेल खाना है।

• सटीक मैच काम करता है जब एक सही उत्तर हो: एक वर्गीकरण लेबल, एक निकाली गई फील्ड, एक हां या नहीं। आप आउटपुट को अपेक्षित मान के साथ सीधे तुलना करते हैं।
• मानदंड-आधारित ग्रेडिंग काम करता है जब एक एकल सही उत्तर न हो, जैसे एक सारांश या एक जवाब। आप जांचते हैं कि क्या आउटपुट शर्तें पूरी करता है: क्या सारांश मुख्य तथ्य का उल्लेख करता है? क्या यह 50 शब्दों से कम है? क्या टोन विनम्र है?
• LLM-as-judge आपके मानदंड के खिलाफ आउटपुट को स्कोर करने के लिए एक दूसरी मॉडल कॉल का उपयोग करता है। यह एक सरल जांच नहीं को पकड़ सकते हैं फजी गुणवत्ता सवालों के लिए स्केल करता है, लेकिन न्यायाधीश स्वयं एक मॉडल है, इसलिए यह गलत हो सकता है, और आप कभी-कभी इसे मानवीय निर्णय के खिलाफ सेनिटी-चेक करते हैं।

# मूल्यांकन सेट पर सटीक-मैच ग्रेडिंग
def run_evals(eval_set, classify):
    passed = 0
    for test in eval_set:
        output = classify(test["input"])
        if output == test["expected"]:
            passed += 1
        else:
            print(f'FAIL: "{test["input"]}" -> got {output}, wanted {test["expected"]}')
    print(f"{passed}/{len(eval_set)} passed")

सटीक मैच शुरू करने के लिए सबसे दोस्ताना जगह है, और यह पिछले अध्यायों से वर्गीकरण और निष्कर्षण कार्य को पूरी तरह से फिट करता है। LLM-as-judge विचार काम करता है क्योंकि यह स्पॉट करना कि क्या एक उत्तर एक मानदंड को पूरा करता है, अक्सर उत्तर का उत्पादन करने से आसान भविष्य कहनेवाला है, उसी तरह से एक निबंध की समीक्षा करना इसे लिखने से आसान है। लेकिन न्यायाधीश एक ही खामियों के साथ दूसरा भविष्य कहनेवाला है, इसलिए इसके स्कोर को एक उपयोगी अनुमान के रूप में मानें, इसे एक स्पष्ट रूब्रिक दें, और हर बार इसके ग्रेड के खिलाफ अपने आप को एक नमूने पर जांचें।

Junoकैसे ग्रेड करें जांच चुनें जो उत्तर पर फिट बैठे: सटीक मैच जब एक सही उत्तर हो, मानदंड जब कई अच्छे हों, और फजी गुणवत्ता के लिए दूसरा मॉडल न्यायाधीश के रूप में। सटीक मैच सबसे कोमल शुरुआत है, और यह वर्गीकरण और निष्कर्षण के साथ करीब से पंक्तिबद्ध करता है जिसे आपने पहले से ही अभ्यास किया है। लेकिन न्यायाधीश भी एक मॉडल है, इसलिए हर बार इसके ग्रेड को अपने आप को देखें।

ग्रेडर को कार्य से मेल खाएं, फिर सबसे सस्ते को पहुंचें जो अभी भी उस पर कब्जा करता है जिसकी आप परवाह करते हैं। एक ग्रेडर कोड या मॉडल कॉल है जो तय करता है कि क्या आउटपुट पास हुआ, और गलत पसंद या तो वास्तविक विफलताओं को मिस करता है या उत्तरों को झंडी लगाता है जो ठीक थे।

सटीक मैच लेबल और निकाली गई फील्ड के लिए है: आप आउटपुट को अपेक्षित मान के साथ तुलना करते हैं और परिणाम निर्धारक है, इसलिए आप इस पर भरोसा कर सकते हैं। यह संरचित आउटपुट के साथ स्वाभाविक रूप से जोड़ी जाती है, क्योंकि एक मॉडल एक निर्धारित स्कीमा लौटाता है जो आपको मुक्त-रूप गद्य के बजाय तुलना करने के लिए कुछ स्वच्छ देता है।

प्रोग्रामेटिक मानदंड सस्ते बीच की जमीन को कवर करते हैं: लंबाई जांचें, एक आवश्यक स्ट्रिंग की पुष्टि करें, पुष्टि करें कि JSON पार्स करता है, एक regex चलाएं। ये मिलीसेकंड में कोई मॉडल कॉल के साथ चलते हैं, इसलिए कुछ भी अर्ध-संरचित के लिए उन्हें एक न्यायाधीश पर खर्च करने से पहले उपयोग करें।

LLM-as-judge खुले-समाप्त गुणवत्ता के लिए है, जहां एक सारांश या जवाब के कई अच्छे रूप हैं और कोई सटीक लक्ष्य नहीं। इसे एक लिखित रूब्रिक की आवश्यकता है ताकि न्यायाधीश एक सुसंगत मानक लागू करे, साथ ही एक अंशांकन जांच जहां आप एक नमूने पर अपने लेबल के खिलाफ इसके ग्रेड की तुलना करें। याद रखें कि एक ग्रेडर कोड है जिस पर आप भी भरोसा करते हैं: एक फ्लैकी ग्रेडर आपको एक आत्मविश्वास से गलत स्कोर देता है।

Junoकैसे ग्रेड करें सबसे सस्ता ग्रेडर का उपयोग करें जो अभी भी पकड़ता है जो महत्वपूर्ण है: लेबल और फील्ड के लिए सटीक मैच, लंबाई या मान्य JSON या एक आवश्यक स्ट्रिंग के लिए प्रोग्रामेटिक जांच, और एक मॉडल न्यायाधीश केवल खुले-समाप्त गुणवत्ता के लिए। सटीक मैच संरचित आउटपुट के साथ अच्छी तरह से जोड़ी जाती है क्योंकि एक निर्धारित स्कीमा आपको तुलना करने के लिए कुछ स्वच्छ देता है। जो भी आप चुनते हैं, ग्रेडर कोड है जिस पर आप भी भरोसा करते हैं, इसलिए एक फ्लैकी एक आत्मविश्वास से गलत स्कोर देता है।

LLM-as-judge वह ग्रेडर है जो सबसे दिलचस्प तरीकों से टूटता है, इसलिए इसके पूर्वाग्रहों के लिए योजना बनाएं इससे पहले कि आप इस पर झुकें। एक न्यायाधीश लंबे उत्तरों का पक्ष लेता है, जब एक जोड़ी की तुलना करते समय पहला विकल्प लेता है, और पाठ को पुरस्कृत करता है जो अपनी शैली की तरह पढ़ता है, और इसके पूर्ण स्कोर खराब-कैलिब्रेटेड हैं, इसलिए एक रन से एक 8 अगले रन से 8 नहीं है।

न्यायाधीश को एक मॉडल के रूप में मानें जिसे आप अपने आप में मूल्यांकन कर रहे हैं। न्यायाधीश मॉडल को पिन और संस्करण करें, क्योंकि यह तब बहता है जब यह अपडेट होता है और आपके स्कोर इसके साथ चलते हैं। इसे एक कसी हुई रूब्रिक को कुछ एंकर उदाहरणों के साथ दें, फिर एक लेबल किए गए नमूने पर न्यायाधीश-बनाम-मानव समझौते को मापें ताकि आप जानते हैं कि इस पर कितना भरोसा करना है।

जहां आप कर सकते हैं, एक पंक्तिबद्ध तुलना के लिए पूछें ("क्या A या B बेहतर है?") एक निरपेक्ष 1-से-10 स्कोर के बजाय; सापेक्ष निर्णय आमतौर पर एक मॉडल को एक कैलिब्रेटेड संख्या को हिट करने के लिए पूछने से अधिक विश्वसनीय होते हैं। न्यायाधीश को पिन करें, रूब्रिक को कस लें, इसे मनुष्यों के खिलाफ जांचें।

परिपत्रता और बिल को ध्यान में रखें। एक ही मॉडल परिवार इसके अपने आउटपुट को ग्रेड करना अपनी अंधी जगहों को साझा करता है, इसलिए एक खामी जो जनरेटर ने की थी एक खामी है जिसे न्यायाधीश संभवतः मिस करेगा, और हर मामले को पैमाने पर ग्रेड करना पहले के शीर्ष पर एक दूसरी मॉडल बिल है।

Junoकैसे ग्रेड करें न्यायाधीश के पास विचार हैं जिन्हें आपने नहीं पूछा था: यह लंबे उत्तर पसंद करता है, पहला विकल्प है, और गद्य जो खुद की तरह लगता है, और इसके पूर्ण स्कोर रन के बीच भटकते हैं। इसे पिन और संस्करण करें, इसे एंकर के साथ एक कसी हुई रूब्रिक दें, और ट्रैक करें कि यह एक मानव से कितनी बार सहमत होता है, क्योंकि आप अभी न्यायाधीश को ग्रेड कर रहे हैं। एक अकेले 1-से-10 पर पंक्तिबद्ध तुलना की ओर झुकें, और यह जागरूक रहें कि एक मॉडल अपने परिवार के आउटपुट को ग्रेड करना अपनी अंधी जगहों को साझा करता है और बिल को दोगुना करता है।

हर परिवर्तन पर चलाएं

एक मूल्यांकन सेट केवल उपयोगी है यदि आप वास्तव में इसे चलाते हैं। अपने प्रॉम्प्ट को कोड की तरह मानें: इससे पहले कि आप एक प्रॉम्प्ट, एक मॉडल, या आपकी पुनर्प्राप्ति में परिवर्तन को शिप करें, मूल्यांकन चलाएं और स्कोर की तुलना पहले से करें। यदि संख्या नीचे चली गई, तो आपने एक प्रतिगमन का कारण बना दिया, भले ही आपकी एक हाथ-परीक्षा ठीक दिखने के लिए हुई हो।

यह वह है जो प्रॉम्प्ट इंजीनियरिंग को अनुमान से कुछ में बदल देता है जिस पर आप आत्मविश्वास के साथ पुनरावृत्ति कर सकते हैं। कुछ बदलें, इसे मापें, जो उच्च स्कोर करता है उसे रखें, और जो कम स्कोर करता है उसे त्यागें। यह वही लूप है जो सामान्य सॉफ्टवेयर को विश्वसनीय बनाता है, अब AI सुविधा के फजी हिस्सों पर लागू किया गया है।

यदि स्कोर गिरता है, तो आपने एक प्रतिगमन का कारण बना दिया। एक भाग्यशाली हाथ-परीक्षा सेट को ओवररूल नहीं करता है, इसलिए हर बार संख्या को टाईब्रेकर होने दें।

Junoहर परिवर्तन पर चलाएं एक मूल्यांकन सेट केवल मदद करता है यदि आप इसे चलाते हैं, इसलिए इसे आदत बनाएं: किसी भी परिवर्तन से पहले जहाज, मूल्यांकन चलाएं और स्कोर की तुलना पिछली बार से करें। यदि यह नीचे चला गया, तो यह एक प्रतिगमन है जिसे ठीक करना है, लहराने के लिए एक विप्लव नहीं। परिवर्तन, माप, जो उच्च स्कोर करता है उसे रखें, और आप अनुमान के बजाय पुनरावृत्ति कर रहे हैं।

मूल्यांकन रन को अपने विकास लूप में तार दें ताकि यह परिवर्तनों को गेट करे जिस तरह एक परीक्षण सूट एक विलय को गेट करता है। एक प्रॉम्प्ट, एक मॉडल, या आपकी पुनर्प्राप्ति में परिवर्तन (जो कदम है जो समर्थन दस्तावेजों में खींचता है) तब तक शिप नहीं होता है जब तक आपने सेट को चलाया है और स्कोर की तुलना पिछली रन से की है। संख्या, न कि आपकी आंत एक हाथ-परीक्षा के बाद, तय करता है कि क्या परिवर्तन एक सुधार है।

एक समय में एक चर बदलें। यदि आप प्रॉम्प्ट को संपादित करते हैं और एक ही पास में मॉडल को स्वैप करते हैं, तो स्कोर में एक कदम के दो संभावित कारण हैं और आप इसे या तो के लिए जिम्मेदार नहीं ठहरा सकते। परिवर्तन को अलग करें, सेट चलाएं, परिणाम पढ़ें, फिर अगले को चलें।

प्रति-मामले के अंतर को पढ़ें, केवल कुल स्कोर नहीं (एकल संख्या हर मामले में औसत)। एक स्थिर कुल एक मामले को ठीक किया गया छिपा सकता है और एक समय पर टूट गया, जो शून्य को पूरा करता है जबकि आपका व्यवहार चुप करके बदल गया। यह देखना कि कौन से मामलों को बदल दिया आपका परिवर्तन वास्तव में क्या किया है।

समय के साथ स्कोर ट्रैक करें ताकि सुधार दृश्यमान हो और प्रतिगमन बाहर खड़े हों। एक लॉग किए गए इतिहास "यह बेहतर लगता है" को एक लाइन में बदल देता है जिसे आप इंगित कर सकते हैं, और यह एक अचानक गिरावट को तेजी से ट्रेस करता है जो इसका कारण बना।

Junoहर परिवर्तन पर चलाएं परीक्षणों पर विलय करने के तरीके से स्कोर पर चेंज गेट करें: कोई रन नहीं, कोई जहाज नहीं। एक चर प्रति पास बदलें ताकि स्कोर का कदम एक कारण हो, और प्रति-मामले के अंतर को पढ़ें, क्योंकि एक फ्लैट कुल एक ठीक किया हुआ और एक टूटा हुआ छिपा सकता है। समय के साथ स्कोर लॉग करें ताकि जीत दृश्यमान हों और प्रतिगमन बाहर खड़े हों।

इसे एक वास्तविक गेट बनाएं, एक अनुष्ठान नहीं। CI में एक स्कोर थ्रेसहोल्ड डालें ताकि एक परिवर्तन जो बार के नीचे गिरता है किसी को याद रखने पर भरोसा करने के बजाय बिल्ड विफल हो। और हर मॉडल-संस्करण बंप पर सेट को फिर से चलाएं, क्योंकि एक ही प्रॉम्प्ट नए वजन पर अलग तरीके से उतरता है; मॉडल संस्करण को पिन करें जिस पर आपने परीक्षण किया और नए को अपनाने से पहले फिर से मूल्यांकन करें।

दो जाल पकड़ें दिमाग में। सबसे पहले, मूल्यांकन सेट (अपेक्षित परिणामों के साथ परीक्षण मामलों का आपका निर्धारित संग्रह) एक प्रॉक्सी है, जमीनी सत्य नहीं, इसलिए इसके खिलाफ कड़ी ट्यूनिंग ओवरफिट करती है: आप स्कोर चढ़ते हैं जबकि वास्तविक व्यवहार ठहर जाता है। सेट को विस्तारित और घुमाते रहें ताकि आप टेस्ट को याद नहीं कर रहे हैं बल्कि कार्य को माप रहे हैं।

दूसरा, ऑफलाइन मूल्यांकन पूरी तस्वीर नहीं है। उन्हें ऑनलाइन सिग्नल के साथ जोड़ी, नमूना किए गए उत्पादन ट्रैफिक, उपयोगकर्ता प्रतिक्रिया, शिकायत की दरें, और वास्तविक विफलताओं को नए मामलों के रूप में सेट में वापस खिलाएं।

क्योंकि आउटपुट गैर-निर्धारक है, एक ही इनपुट रन में अलग तरीके से स्कोर कर सकता है। प्रत्येक मामले के लिए पर्याप्त नमूने चलाएं और एक सहिष्णुता के विरुद्ध एकल-रन शोर का पीछा करने के बजाय न्यायाधीश करें; एक-बिंदु wobble रन के बीच माप सांस है, प्रतिगमन नहीं। बार को एक स्तर पर सेट करें जो उस विचरण को जीवित करता है, या आप अपना सप्ताह भूतों की जांच करने में खर्च करेंगे। मैंने बिल्कुल वह, एक से अधिक बार किया है।

Junoहर परिवर्तन पर चलाएं CI में एक थ्रेसहोल्ड डालें ताकि एक बुरा परिवर्तन बिल्ड विफल हो, और हर मॉडल-संस्करण बंप पर फिर से मूल्यांकन करें क्योंकि नए वजन एक ही प्रॉम्प्ट को अलग तरीके से पढ़ते हैं। सेट एक प्रॉक्सी है, इसलिए इसे घुमाते रहें और इसे ऑनलाइन सिग्नल के साथ जोड़ी, या आप अपनी स्वयं की परीक्षा के लिए ओवरफिट करेंगे। और क्योंकि आउटपुट गैर-निर्धारक है, सहिष्णुता के विरुद्ध एकल-रन शोर का पीछा करने के बजाय न्यायाधीश करें, जो हां, मैंने किया है।

व्यावहारिक रूप में

पिछले अनुभाग से run_evals फंक्शन एक पूर्ण, यदि छोटा, eval harness है। आप इसे अपने क्लासिफायर और अपने eval सेट पर इंगित करते हैं, और यह आपको बताता है कि कितने मामले पास करते हैं और आपको बिल्कुल दिखाता है कि कौन विफल होते हैं:

run_evals(eval_set, classify_review)
# FAIL: "यह ठीक था, कुछ विशेष नहीं।" -> got POSITIVE, wanted NEUTRAL
# 2/3 passed

यह एक विफल लाइन दर्जन सफल हाथ-परीक्षण से अधिक लायक है, क्योंकि यह एक वास्तविक कमजोरी पर इंगित करती है जिसे आप अब ठीक कर सकते हैं और फिर से माप सकते हैं। अंतिम अध्याय, सुरक्षा और सीमाएं, उन जोखिमों को कवर करता है जिन्हें आप इसे असली उपयोगकर्ताओं के सामने रखने से पहले डिजाइन करते हैं।

Junoव्यावहारिक रूप मेंrun_evals जैसा एक छोटा harness पहले से ही अपनी रखरखाव को अर्जित करता है: यह आपको एक स्कोर और सटीक मामलों को देता है जो टूटे। एक को ठीक करें, इसे फिर से चलाएं, संख्या को चलते हुए देखें। अगला, सुरक्षा और सीमाएं असली उपयोगकर्ता आने से पहले क्या बचाव करना है इसे कवर करती हैं।

एक छोटा eval harness, कोड का बिट जो अपने eval सेट में हर मामले को चलाता है और आउटपुट को स्कोर करता है जो आप अपेक्षा करते थे, वह लूप है जो "ठीक लगता है" को एक संख्या में बदल देता है जिसे आप स्थानांतरित कर सकते हैं। आप सेट चलाते हैं, आप एक स्कोर प्लस विफलताओं की एक सूची पाते हैं, आप सबसे सस्ती असली विफलता को ठीक करते हैं, आप इसे फिर से चलाते हैं।

प्रत्येक विफल मामला काम की एक इकाई है जो पूरा होने की स्पष्ट परिभाषा है: मामला गुजरता है। यह "प्रॉम्प्ट को बेहतर बनाएं" की तुलना में एक तीव्र लक्ष्य है, क्योंकि आप ठीक से देख सकते हैं जब आप इसे हिट करते हैं और ठीक से जब आप प्रतिगमन करते हैं।

इससे पहले कि यह असली उपयोगकर्ताओं को देखता है, अगला अध्याय, सुरक्षा और सीमाएं, उन जोखिमों को कवर करता है जिन्हें आप समय से पहले डिजाइन करते हैं।

Junoव्यावहारिक रूप में Harness vibes को एक संख्या में बदल देता है जिसे आप स्थानांतरित कर सकते हैं: सेट चलाएं, स्कोर और विफलताओं को पढ़ें, सबसे सस्ती असली को ठीक करें, फिर से चलाएं। प्रत्येक विफलता एक कार्य है जो एक स्पष्ट परिभाषा के साथ किया जाता है, जो "इसे बेहतर बनाएं" की तुलना में एक तीव्र लक्ष्य है। फिर असली उपयोगकर्ता इसे देखते हैं इससे पहले सुरक्षा और सीमाएं।

उत्पादन में यह छोटा harness स्क्रिप्ट होने का कार्य बंद कर देता है जिसे आप हाथ से चलाते हैं और यह प्रणाली का हिस्सा बन जाता है। यह एक CI गेट में बढ़ता है, एक जांच जो एक रिलीज को तब तक अवरुद्ध करता है जब तक स्कोर एक लाइन के नीचे न गिर जाए जिसे आप सेट करते हैं, और एक डैशबोर्ड जिसे आप एक एकल रन कभी नहीं दिखाता है धीरे-धीरे बहाव को पकड़ने के लिए रिलीज के पार देखते हैं।

ऑफलाइन मूल्यांकन, निर्धारित सेट जिसे आप शिप करने से पहले स्कोर करते हैं, और ऑनलाइन निगरानी, सिग्नल जिन्हें आप बाद में असली ट्रैफिक से एकत्रित करते हैं, एक दूसरे को खिलाते हैं: उत्पादन विफलताएं नए ऑफलाइन मामले बन जाती हैं, और ऑफलाइन सेट आपको बताता है कि क्या आपकी मरम्मत की गई। टीमें जो यहां जीतती हैं वे होशियार प्रॉम्प्ट वाली नहीं हैं। वे जो मापते हैं जबकि बाकी सब नजर रखते हैं।

यह अनुशासन है। अगला अध्याय, सुरक्षा और सीमाएं, उन जोखिमों को कवर करता है जिन्हें आप डिजाइन करते हैं इससे पहले कि किसी को असली उपयोगकर्ताओं तक पहुंचें।

Junoव्यावहारिक रूप में परिपक्व करें और स्क्रिप्ट एक CI गेट प्लस एक डैशबोर्ड में बदल जाता है, ऑफलाइन मूल्यांकन और ऑनलाइन निगरानी एक दूसरे को खिलाते हैं। मैंने "मुझे अच्छा लगता है" पर शिप किया है और बाद में इसके लिए भुगतान किया है, इसलिए मुझे ले लो: टीमें जो जीतते हैं वे मापते हैं जबकि बाकी सब नजर रखते हैं। असली उपयोगकर्ता आने से पहले सुरक्षा और सीमाएं पढ़ें।