ग्राउंड अप से Python में एक कस्टम LLM मूल्यांकन हार्नेस बनाएँ

मेटा विवरणः सीखें कि Python में चार मॉड्यूल के साथ एक कस्टम LLM मूल्यांकन हार्नेस कैसे बनाया जाए: गोल्डन dataset , असिंक्रोनस रनर, जज लेयर और क्रैश-सेफ लॉगर।

टैगः LLM मूल्यांकन, Python , LiteLLM, Pydantic, AI परीक्षण

विशेष रुप से प्रदर्शित छवि: (अंग्रेज़ी में) ">"</string> चार जुड़े Python मॉड्यूल, एक परीक्षण हार्नेस और मॉडल आउटपुट का अमूर्त मैत्रीपूर्ण चित्रण, कोई लोग, लोगो या पाठ नहीं।

डेवलपर्स और उत्पाद टीमों के लिए जो अपनी आवश्यकताओं के खिलाफ large language models का परीक्षण करते हैं, Python में एक कस्टम LLM मूल्यांकन हार्नेस संकेत भेजने, प्रतिक्रिया रिकॉर्ड करने और उन्हें जज करने के लिए एक दोहराए जाने योग्य वर्कफ़्लो बनाता है। गाइड आपको अपने मॉडल को कैसे परीक्षण और स्कोर किया जाता है इस पर पूर्ण नियंत्रण देने के लिए चार मॉड्यूलर घटकों का उपयोग करके Python , में खरोंच से निर्माण करता हैः गोल्डन dataset , एक अनुमान धावक, न्यायाधीश परत और लॉगर।

सार्वजनिक बेंचमार्क क्यों पर्याप्त नहीं हैं

MMLU और GSM8K व्यापक मॉडल क्षमता दिखा सकते हैं, लेकिन वे उत्पाद-विशिष्ट प्रश्नों का उत्तर नहीं देते। क्या customer support एजेंट आपकी अस्वीकृति नीति का पालन करेगा? क्या एक retrieval-augmented generation पाइपलाइन आपके डोमेन के लिए सही संदर्भ प्राप्त करेगी? उन लोगों को जवाब देने के लिए, आपको अपनी खुद की पाइप लाइन की आवश्यकता है।

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

पूर्व शर्तें और निर्भरताएँ

Python 3.10 या बाद में आवश्यक है, मुख्य रूप से क्योंकि मूल asyncio समर्थन प्रत्येक API कॉल के लिए क्रमशः प्रतीक्षा करने के बजाय मूल्यांकन को ओवरलैप करता है। पैकेज सूची जानबूझकर छोटी है।

LiteLLM OpenAI , Anthropic , Google और अन्य मॉडल बैकएंड के लिए एक कॉलिंग पैटर्न प्रदान करता है। परीक्षण के तहत मॉडल को बदलना रनर पुनर्लेखन की बजाय एक स्ट्रिंग संपादन बन जाता है। Pydantic जज लेयर को टाइप किए गए फ़ील्ड वापस करने के लिए मजबूर करता है, मुक्त पाठ नहीं। मानक लाइब्रेरी बाकी का प्रबंधन करती है, समवर्तीता के लिए asyncio और लॉगिंग के लिए JSON के साथ।

दोहन बनाने के लिए चरण-दर-चरण मार्गदर्शिका

1. वास्तविक उपयोगकर्ता इनपुट से एक गोल्डन dataset का निर्माण करें। एक गोल्डेन dataset परीक्षण मामलों की एक संरचित सूची है जो प्रत्येक इनपुट प्रॉम्प्ट को अपेक्षित परिणाम के साथ जोड़ती है। हर अन्य घटक इस पर निर्भर करता है। वास्तविक उपयोगकर्ता लॉग या ज्ञात विफलता मोड से खींचे गए 20 से 50 मामलों से शुरू करें। डेस्क-निर्मित उदाहरण अक्सर खुश पथ पर बैठते हैं, जबकि वास्तविक इनपुट गड़बड़ होते हैं, और उस गंदगी को पकड़ने के लिए हार्नेस मौजूद होता है। प्रत्येक मामले में क्रॉस-रन ट्रैकिंग के लिए एक अद्वितीय आईडी की आवश्यकता होती है, मॉडल को भेजा गया इनपुट, और स्कोरर के लिए जांच करने के लिए expected_concept. संक्षिप्त, अस्पष्ट expected_ Concept मान अविश्वसनीय स्कोर को रोकते हैं। श्रेणी टैग, कठिनाई स्तर या मेटा डेटा जोड़कर इसे अपना बनाएं जहां एक मामला उत्पन्न हुआ था। संरचना एक प्रारंभिक बिंदु है, छत नहीं।

1. Inference runner लिखें. यह रनर मामलों पर लूप करता है, मॉडल को बुलाता है और कच्ची प्रतिक्रिया देता है. चूंकि LiteLLM नीचे बैठता है, आप एक तर्क संपादित करके GPT-4o , Claude 3.5 Sonnet या स्थानीय रूप से होस्ट किए गए मॉडल को लक्षित कर सकते हैं। उत्पादन मूल्यांकन चलाने के लिए न्यूनतम विश्वसनीयता सेटिंग्स के रूप में num_retries=3 और timeout=30 का उपयोग करें। पूर्ण- dataset समवर्तीकरण के लिए, c in cases के लिए await asyncio.gather(*[run_casec, model) का प्रयोग करें]). इससे सभी मामले समानांतर में शुरू होते हैं और बड़े datasets पर वॉल-क्लॉक समय कम हो जाता है। रनर से बाहर स्कोरिंग रखें: इसे केवल कच्चे आउटपुट लौटना चाहिए। बाद में इस अलगाव की बात आती है।

1. एक न्यायाधीश परत के साथ आउटपुट को स्कोर करें। न्यायाधीश प्रत्येक धावक परिणाम प्राप्त करता है और एक प्रश्न का उत्तर देता हैः पास या असफल। परीक्षण के आधार पर न्यायाधीश चुनें। जब आपको किसी विशिष्ट स्ट्रिंग, प्रारूप या पैटर्न की आवश्यकता होती है तो एक निर्धारात्मक न्यायाधीश तेज़, सस्ता और सुसंगत होता है। LLM -जैसा-एक न्यायाधीश अधिक लागत और धीमा चलता है, लेकिन यह सटीक पाठ के बजाय अर्थ का मूल्यांकन कर सकता है। "इस ऑपरेशन से आपके डेटा को स्थायी रूप से हटा दिया जाएगा" जैसी प्रतिक्रिया को अस्वीकार शब्द के बिना भी इनकार करने की परीक्षा उत्तीर्ण करनी चाहिए। Pydantic न्यायाधीश को वैध पारित बूलियन वापस करने की आवश्यकता है, गद्य नहीं। उस गार्ड के बिना, "मुझे लगता है कि यह पारित हो गया" जैसे जवाब पार्सिंग को तोड़ सकते हैं। ये जज जानबूझकर नंगे हड्डियां हैं। ग्रेडिंग रूब्रिक को समायोजित करके, आंशिक स्कोरिंग जोड़कर, या विभिन्न श्रेणियों को अलग-अलग न्यायाधीशों को भेजकर उन्हें दर्जीत करें; जो परियोजना के लिए विशेष उपयोगिता बनाती है।

1. परिणामों को डिस्क पर लॉग करें. प्रत्येक स्कोर किए गए परिणाम को तुरंत एक .jsonl फ़ाइल में लिखें। अनुलग्नक-केवल पंक्ति-सीमित JSON एक सामान्य मूल्यांकन लॉग प्रारूप है क्योंकि यह दुर्घटनाओं से बचता हैः यदि धावक dataset समाप्त होने से पहले रुक जाता है, तो पिछले परिणाम बने रहते हैं। score के बगल में raw_output रखें। बाद में, न्यायाधीश की रूब्रिक में सुधार करने के बाद, आप एक और अनुमान चलाने के बिना उसी आउटपुट को फिर से स्कोरिंग कर सकते हैं। API के खिलाफ 500 मामले वाले dataset , जो समय और लागत की बर्बादी से बचाता है।

टीमों के लिए क्या बदलता है

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

डिज़ाइन को फिर से लिखने के बिना बढ़ाया जा सकता है. लॉग रिकॉर्ड्स में विलंबता और token लागत फ़ील्ड जोड़ें. हार्नेस को निरंतर एकीकरण और सतत वितरण पाइपलाइन से कनेक्ट करें ताकि प्रत्येक मॉडल अद्यतन पर प्रतिगमन सतह हो। एक डैशबोर्ड में समग्र .jsonl लॉग इन करें। रूब्रिक-आधारित ग्रेडर के साथ सरल न्यायाधीश की जगह लें।

स्रोत algorithm टेस्ट हार्नेस, PyCaret मॉडल पाइपलाइनों पर संबंधित कवरेज की ओर भी इशारा करता है, LLM मूल्यांकन फ्रेमवर्क की तुलना, LLM मूल्यांकन मैट्रिक्स और कस्टम टूल कॉल के लिए fine-tuning Llama 3 ।

आम गलतियाँ

• MMLU और GSM8K व्यापक क्षमता दिखा सकते हैं, लेकिन वे आपको यह नहीं बताएंगे कि क्या एक विशिष्ट अस्वीकृति नीति, डोमेन संदर्भ या उत्पाद संकेत काम करता है।
• आविष्कार किए गए परीक्षण मामलों का उपयोग करना। वास्तविक उपयोगकर्ता लॉग या ज्ञात विफलता मोड के साथ शुरू करें; सिंथेटिक खुश-पथ उदाहरण उन गन्दा इनपुट को छिपाते हैं जो प्रतिगमन का कारण बनते हैं।
• अस्पष्ट expected_concept मान. यदि अपेक्षित परिणाम संदिग्ध है, तो स्कोर अविश्वसनीय हो जाते हैं।
• निष्कर्ष और स्कोरिंग का मिश्रण करना यदि कच्चे आउटपुट लॉग नहीं किए जाते हैं, तो बाद में रूबरी परिवर्तन एक अन्य महंगे API रन को मजबूर करता है।
• न्यायाधीश तापमान को अनसेट छोड़ना. LLM न्यायाधीश डिफ़ॉल्ट रूप से गैर-निर्णयवादी हैं। भिन्नता को कम करने के लिए न्यायाधीश मॉडल कॉल पर तापमान = 0 सेट करें।
• कोई समवर्ती सीमा नहीं है. LiteLLM का num_retries क्षणिक विफलताओं को संभालता है, लेकिन निरंतर दर की सीमाओं के लिए एक साथ अनुरोधों को सीमित करने के लिए asyncio.gather और asynzio.Semaphore ((10) को लपेटने की आवश्यकता होती है।
• प्रत्येक मामले को LLM न्यायाधीश के पास रूट करना. पहले निर्धारक स्कोरिंग चलाएं और केवल अधिक महंगी जज को असफलताएँ रुट करें। अधिकांश सीधे मामलों को API कॉल के बिना हल किया जाता है, और आप वास्तव में अस्पष्ट आउटपुट के लिए महंगा ग्रेडिंग बचाते हैं।
• श्रेणियों के लिए न्यायाधीशों को अनुकूलित नहीं करना। नंगे हड्डियां पास / फेल जज एक नींव हैं, लेकिन वास्तविक परियोजनाओं में अक्सर अलग-अलग शीर्षक, आंशिक स्कोरिंग या श्रेणी-विशिष्ट रूटिंग की आवश्यकता होती है।