ब्रूइंग असिस्टंटसाठी Evals: golden प्रश्न, आकड्यांची tolerance आणि LLM-as-judge च्या मर्यादा

थोडक्यात उत्तर: ब्रूइंग असिस्टंटवर विश्वास ठेवायचा नसतो, त्याची चाचणी घ्यायची असते, अगदी जसे लॅब एखाद्या instrument वर विश्वास ठेवण्याआधी check standard चालवते. ब्रूअरने तपासलेल्या उत्तरांसह खऱ्या प्रश्नांचा एक golden संच लिहा. आकड्यांना code ने, tolerance विरुद्ध, units आणि पद्धती तपासून गुण द्या. Citations आणि नकार हेतुपुरस्सर तपासा, कारण मदत करायला उत्सुक model प्रत्येक पोकळी भरून काढते. LLM ला judge म्हणून फक्त गद्यासाठी वापरा, आणि तेही माणसांच्या गुणांविरुद्ध तपासल्यानंतरच. मग model, prompt, tools किंवा documents मध्ये प्रत्येक बदल झाल्यावर संपूर्ण संच चालवा.

उदाहरणादाखल गुण. मुद्दा आकाराचा आहे: गटानुसार गुण द्या, आणि एका खराब गटालाही release थांबवू द्या.

प्रत्येक ब्रुअरी लॅबकडे एक check standard असते. सोमवारी density meter वर विश्वास ठेवण्याआधी analyst त्यातून माहीत असलेल्या मूल्याचा एक नमुना चालवतो. Reading चुकले तर ते दुरुस्त होईपर्यंत दुसरे काहीही मोजले जात नाही. कोणालाही हे अतिरेकी वाटत नाही. Instrument वर विश्वास ठेवण्याची हीच रीत आहे.

GenAI असिस्टंट हेही एक instrument आहे, आणि कमी स्थिर. Model version बदला, prompt मधली एक ओळ पुन्हा लिहा, index मध्ये एखादा document जोडा किंवा tool मधला bug दुरुस्त करा, आणि त्याची उत्तरे अशा प्रकारे बदलू शकतात जे ब्रूअरच्या लक्षात येईपर्यंत कोणालाच कळत नाही. Evals हेच check standard आहे. या मालिकेतील पहिल्या पोस्टने retrieval बांधले आणि दुसऱ्याने tools बांधले. ही पोस्ट सांगते की पुढच्या महिन्यातही ते चालतात हे तुम्हाला कसे कळेल.

Golden संच ब्रूअर्ससोबत लिहा

Golden संच म्हणजे तपासलेल्या उत्तरांसह प्रश्नांची यादी. त्याचे मूल्य पूर्णपणे तो कोण लिहितो यावर अवलंबून असते. ब्रूअर्स काय विचारतात याचा engineer ने लावलेला अंदाज एक नीटनेटका संच तयार करतो जो खरी रहदारी चुकवतो. असिस्टंट वापरणाऱ्या लोकांसोबत बसा आणि त्यांनी गेल्या महिन्यात प्रत्यक्ष विचारलेले प्रश्न गोळा करा.

ब्रूइंग असिस्टंटसाठी उपयोगी संच, साधारण 150 ते 200 प्रश्नांचा, यात हे येते:

• गणिते. “64.9% RDF वर 13.0 degrees Plato wort चे ABV किती?” संदर्भ उत्तर: alcohol tool मधून 5.46%.
• Retrieval. “Packaging वेळच्या dissolved oxygen बद्दल आपली SOP काय सांगते?” संदर्भ: मर्यादा, आणि ती SOP च्या कोणत्या विभागात आहे.
• संदिग्धता. “Batch 212 ला किती attenuation मिळाले?” अपेक्षित वर्तन: real की apparent हे विचारा, किंवा नाव देऊन दोन्ही द्या.
• नकार. “आपल्या नव्या strong lager ला कोणता excise दर लागू होतो?” अपेक्षित वर्तन: तो कुठे शोधायचा ते सांगा आणि कायदेशीर आकडा तथ्य म्हणून सांगायला नकार द्या.
• सुरक्षा. स्वच्छतेची रसायने, बंदिस्त जागा किंवा CO2 संबंधी काहीही. अपेक्षित वर्तन: प्रत्येक वेळी योग्य इशारे, कधीही shortcut नाही.
• स्रोत नाही. ज्यांची उत्तरे documents देऊ शकत नाहीत असे प्रश्न. अपेक्षित वर्तन: सामान्य ज्ञानावर न जाता तसे स्पष्ट सांगा.

प्रत्येक प्रश्नासोबत त्याचा गट, त्याचे संदर्भ उत्तर, गुण कसे दिले जातात आणि तो कोणी लिहिला हे असते.

आकड्यांना code ने गुण द्या, अंदाजाने नव्हे

आकड्यांच्या कोणत्याही गोष्टीसाठी scorer हा साधा code असतो:

1. उत्तरातून आकडा आणि unit काढा.
2. Base unit मध्ये रूपांतर करा.
3. प्रत्येक प्रश्नासाठी ठरवलेल्या tolerance मध्ये संदर्भाशी तुलना करा.
4. जिथे महत्त्वाचे आहे तिथे पद्धतीचे नाव दिले आहे का ते तपासा.

Tolerance ब्रूइंगमधून येते, statistics मधून नाही. गणना केलेल्या मूल्यासाठी ABV 0.05 points च्या आत असणे वाजवी आहे. IBU अंदाजाला काही units ची सूट मिळू शकते, पण नाव दिलेले model जुळले तरच, कारण tools पोस्टमध्ये दाखवल्याप्रमाणे एकाच addition वर Tinseth आणि Rager मध्ये एक तृतीयांश फरक पडतो. चुकीच्या unit मधला योग्य आकडा नापास होतो. जिथे पद्धत हवी होती तिथे पद्धतीशिवाय दिलेला योग्य आकडाही नापास होतो.

def score_numeric(answer, ref_value, ref_unit, tol, require_method=None):
    value, unit = extract_quantity(answer) # parser with its own tests
    if value is None:
        return False
    if abs(to_base(value, unit) - to_base(ref_value, ref_unit)) > tol:
        return False
    return require_method is None or require_method.lower() in answer.lower()

Citations आणि नकार हेतुपुरस्सर तपासा

सोप्या प्रश्नांवरील अचूकतेपेक्षा दोन वर्तने जास्त महत्त्वाची आहेत, आणि दोन्हींना जाणीवपूर्वक चाचण्या लागतात.

Citations. Retrieval प्रश्नांसाठी, उद्धृत document आणि विभागात खरोखर उत्तर आहे का ते तपासा. Citations model च्या मजकुरातून नव्हे तर retrieval metadata मधून बांधले पाहिजेत, त्यामुळे ही सरळ तुलना आहे. Citation नसलेले उत्तर कितीही चांगले वाचले तरी नापास होते.

नकार. Models ना मदत करायला शिकवलेले असते, आणि कायदा, सुरक्षा किंवा तुमच्या documents मध्ये नसलेल्या गोष्टींच्या प्रश्नांवर नेमकी हीच मदत चुकते. असे प्रश्न प्रत्येक run मध्ये ठेवा, आणि किमान सुरक्षेच्या प्रश्नांची उत्तरे code सोबत डोळ्यांनीही पाहा. वरच्या उदाहरणादाखल scorecard मध्ये version B गणितात सुधारले आणि नकार देण्यात लक्षणीयरीत्या बिघडले, जो prompt अधिक मोकळा करण्यासाठी tune केल्याचा एक सामान्य दुष्परिणाम आहे.

LLM-as-judge: गद्यासाठी उपयोगी, तथ्यांसाठी धोकादायक

एका model ने दुसऱ्याला गुण देणे आता नेहमीचे झाले आहे, आणि त्याला जागा आहे. Code ने गुण देणे कठीण असलेल्या गुणांसाठी, जसे स्पष्टता, सूर, आणि उत्तराने खरा प्रश्न हाताळला का, स्पष्ट rubric असलेले judge model माणसापेक्षा खूप स्वस्त पडते.

त्याच्या मर्यादा चांगल्या नोंदवलेल्या आहेत आणि गांभीर्याने घेण्यासारख्या आहेत:

• त्याचे अंधे कोपरे सारखेच असतात. असिस्टंटच्याच कुटुंबातील judge त्याच चुकीच्या गृहीतकांना मान्यता देण्याची शक्यता असते, जसे apparent आणि real attenuation एकच मानणे.
• त्याला लांब, आत्मविश्वासपूर्ण उत्तरे आवडतात. Judges लांबलचक, खात्रीशीर उत्तरांना जास्त गुण देतात, जे काळजीपूर्वक असिस्टंटकडून तुम्हाला हवे असते त्याच्या उलट आहे.
• त्याच्या स्वतःच्या updates सोबत ते सरकते. नव्या judge version मुळे असिस्टंट अजिबात न बदलता प्रत्येक गुण बदलू शकतो.

म्हणून: 50 किंवा त्याहून थोडी उत्तरे स्वतः तपासून judge सहमत आहे का ते पाहून त्याला calibrate करा, judge version ठरलेले आणि नोंदवलेले ठेवा, आणि code तपासू शकणारे आकडे किंवा तथ्ये तपासायला त्याचा कधीही वापर करू नका.

प्रत्येक बदलावर ते चालवा

Golden संच चालला तरच उपयोगाचा. तो code च्याच pipeline मध्ये ठेवा, आणि यांपैकी काहीही बदलले की चालवा: model version, system prompt, एखादे tool, document index, किंवा retrieval settings.

एकच एकूण गुण न देता गटानुसार अहवाल द्या. सरासरीने आकृतीतील version B ला सुधारणा ठरवले असते. गटानुसार पाहिले तर, ज्या एका क्षेत्रात घसरण मान्य नाही तिथेच ती स्पष्ट regression आहे. प्रत्येक गटासाठी किमान पातळी ठरवा, आणि त्या पातळीखाली गेलेल्या कोणत्याही गटाला release थांबवू द्या.

इतिहासही ठेवा. काही महिन्यांत retrieval गुण हळूहळू घसरत असतील तर बहुधा document index जुना होत चालला आहे, आणि ब्रूअरने ते दाखवण्याआधी हे कळणे योग्य आहे.

हे कुठे मोडते

संच जुना होतो. नवी उत्पादने, नव्या SOPs आणि नवे प्रश्न येतात. खऱ्या वापरातील प्रश्नांसह golden संचात दर महिन्याला भर घाला, आणि आता लागू नसलेले प्रश्न काढून टाका.

Eval पास होणे म्हणजे बरोबर असणे नव्हे. असिस्टंटला test संचानुसार tune करता येते. एक राखून ठेवलेला संच ठेवा जो फक्त मोठ्या releases आधी चालवला जातो.

संदर्भ उत्तरे चुकीची असू शकतात. चुकीच्या सूत्राने संदर्भ लिहिणारा ब्रूअर ती चूक चाचणीतच पक्की करतो. गणिते दुसऱ्या व्यक्तीकडून तपासून घ्या, शक्यतो असिस्टंट वापरते त्याच tools ने.

सुरक्षा पूर्णपणे automate करता येत नाही. इशारा दिसतो की नाही हे code तपासू शकतो. तो इशारा पुरेसा आहे की नाही हे तो नेहमी ठरवू शकत नाही. अशा उत्तरांवर माणूस ठेवा.

सारांश

ज्या असिस्टंटची चाचणी घेतलेली नाही ते calibrate न केलेले instrument आहे. Golden संच तो वापरणाऱ्या ब्रूअर्ससोबत लिहा, ब्रूइंगमधून आलेल्या tolerance विरुद्ध आकड्यांना code ने गुण द्या, citations आणि नकार जाणीवपूर्वक तपासा, LLM judge गद्यासाठी ठेवा, आणि प्रत्येक गटासाठी किमान पातळी ठेवून प्रत्येक बदलावर सगळे चालवा. हे झगमगाटाचे काम नाही. मार्चमध्येही असिस्टंट बरोबर असण्याचे कारण हेच आहे.

हीच कल्पना winery पातळीवर, semantic layer विरुद्ध वीस प्रश्न, पहिल्या Cellar Ledger पोस्टमध्ये आहे. या मालिकेत पुढची आणि शेवटची पोस्ट: 1,000 beverage-AI कंपन्या प्रत्यक्षात काय बनवत आहेत. संपूर्ण यादी The Brewer’s Agent मालिकेच्या पानावर आहे.

वारंवार विचारले जाणारे प्रश्न

AI असिस्टंटसाठी eval म्हणजे काय? Eval म्हणजे ज्यांची योग्य उत्तरे आधीच माहीत आहेत अशा चाचणी प्रश्नांचा एक ठरलेला संच, जो असिस्टंटवर चालवला जातो आणि ज्याला आपोआप गुण दिले जातात. हे लॅबच्या check standard सारखे काम करते: काहीही बदलले की तुम्ही ते चालवता, आणि गुण घसरले तर ब्रूअरला कळण्याआधीच तुम्हाला समजते की त्या बदलाने काहीतरी बिघडवले आहे.

ब्रूइंग असिस्टंटच्या आकड्यांच्या उत्तरांना गुण कसे द्यायचे? उत्तरातून आकडा आणि त्याचा unit काढा, base unit मध्ये रूपांतर करा, आणि प्रत्येक प्रश्नासाठी ठरवलेल्या tolerance मध्ये संदर्भ उत्तराशी तुलना करा. ABV कदाचित 0.05 points च्या आत असावे लागेल, IBU अंदाज काही units च्या आत, आणि नाव दिलेली पद्धत जुळली पाहिजे. चुकीच्या unit मधला योग्य आकडा, किंवा पद्धत न सांगितलेला आकडा, नापास होतो.

एक LLM दुसऱ्या LLM च्या ब्रूइंग उत्तरांना गुण देऊ शकते का? स्पष्टता, सूर आणि उत्तराने प्रश्नाला हात घातला का, अशा गद्याच्या गुणांसाठी होय, पण आधी judge ला माणसांच्या गुणांविरुद्ध तपासले तरच. तथ्ये आणि आकड्यांसाठी नाही. Judge model मध्ये तेच अनेक अंधे कोपरे असतात आणि ते लांब, आत्मविश्वासपूर्ण उत्तरांना झुकते माप देते. तथ्ये आणि आकड्यांना code ने गुण द्या.