तुमचे Evals देखील अस्थिर आहेत: तुम्ही पुनरुत्पादित (reproduce) करू शकत नाही अशा पास रेटवर विश्वास ठेवणे थांबवा
बहुतेक लोकांना माहित आहे की AI एजंट्स 'नॉन-डिटरमिनिस्टिक' (non-deterministic) असतात. तुम्ही एकच प्रॉम्प्ट पाठवता, पण तुम्हाला वेगवेगळे आउटपुट्स मिळतात.
आम्ही हे स्वीकारले. आम्ही या एजंट्सचे ग्रेडिंग करण्यासाठी LLMs चा वापर न्यायाधीश (judges) म्हणून करण्यास सुरुवात केली.
पण आम्ही एक मोठी चूक केली. आम्ही असे मानले की आमचे न्यायाधीश 'डिटरमिनिस्टिक' (deterministic) आहेत. ते तसे नाहीत.
तुमची इव्हल सूट (eval suite) ही एका यादृच्छिक (random) सिस्टमद्वारे दुसऱ्या यादृच्छिक सिस्टमचे मूल्यमापन करणारी प्रणाली आहे. जर तुमचा ग्रेडर किती प्रमाणात डगमगतो (wobbles) याचे तुम्ही मोजमाप केले नाही, तर तुमच्याकडे 'क्वालिटी गेट' नाही. तुमच्याकडे फक्त एक नाणेफेक आहे.
मी हे एका सपोर्ट एजंटसोबत घडताना पाहिले. डॅशबोर्ड अनेक आठवडे हिरवा (green) दिसत होता. त्यानंतर, ग्राहकांच्या तक्रारी अचानक वाढल्या. मी २०० जुन्या प्रतिसादांवर तेच इव्हल चालवले. त्यातील १४ निकालांनी आपला निर्णय बदलला होता. एजंट बदलला नव्हता. न्यायाधीशांनी आपला निर्णय बदलला होता.
एक अस्थिर (flaky) गेट हे गेट नसण्यापेक्षाही वाईट आहे. ते तुम्हाला खोटा आत्मविश्वास देते.
तुमचे Evals अयशस्वी होण्याची तीन कारणे आहेत:
- द जज मॉडेल (The judge model): प्रत्येक LLM जजमध्ये तफावत (variance) असते. टेम्परेचर ० (temperature 0) वर देखील, प्रदाते (providers) समान निकालाची खात्री देत नाहीत. मॉडेलमधील एखादे छुपे अपडेट तुमचे बेसलाईन रातोरात खराब करू शकते.
- द हार्नेस (The harness): जर तुमच्या रन दरम्यान तुमचा कॉन्टेक्स्ट किंवा टूल आउटपुट्स बदलले, तर जजला वेगळा प्रश्न दिसतो. इनपुट विचलित (drifted) झाले आहे.
- द रुब्रिक (The rubric): "हे चांगले आहे का?" सारखे अस्पष्ट नियम तफावत निर्माण करतात. कडक आणि विशिष्ट नियम ती तफावत कमी करतात.
तुम्ही अस्थिर (flaky) Evals कडे अस्थिर सॉफ्टवेअर टेस्ट्सप्रमाणेच पाहिले पाहिजे. ते रिलीज (ship) करू नका. त्यांना क्वारंटाईन (quarantine) करा. फ्लॅक रेट (flake rate) मोजा.
केवळ एक सिंगल पास रेट रिपोर्ट करणे थांबवा. सुसंगतता (agreement) रिपोर्ट करण्यास सुरुवात करा.
प्रत्येक जज कॉल अनेक वेळा चालवा. जर जज स्वतःशीच सहमत होऊ शकत नसेल, तर तो निकाल कोणताही संकेत (signal) नाही. तो 'अस्थिर' (UNSTABLE) आहे.
तुमच्या CI/CD पाइपलाइनमध्ये 'UNSTABLE' निकाल हा एक महत्त्वाचा (first-class) परिणाम मानला पाहिजे. तो स्पष्टपणे त्रुटी दर्शवणारा (fail loud) असावा.
अस्थिर इव्हल सुधारण्यासाठी तुम्हाला दोन गोष्टींची आवश्यकता आहे:
- एक स्कोअरिंग लेअर (A scoring layer): हे स्थिरता मोजते आणि निकालांचे रूपांतर PASS, FAIL किंवा UNSTABLE मध्ये करते.
- एक ट्रेसिंग लेअर (A tracing layer): तुम्हाला प्रत्येक रनसाठी रॉ बाईट्स (raw bytes), नेमका प्रॉम्प्ट आणि टूल आउटपुट्स पाहता आले पाहिजेत.
ट्रेसिंगशिवाय, तुम्हाला वाटेल की मॉडेल फक्त यादृच्छिक (random) आहे. तुम्ही टेम्परेचर कमी कराल आणि तुम्हाला वाटेल की तुम्ही ते ठीक केले आहे. पण तुम्ही ते ठीक केलेले नाही. तुम्ही फक्त त्या बगला (bug) शांत केले आहे.
खऱ्या गुणवत्तेसाठी या नियमांचे पालन करा:
- केवळ सरासरी (averages) नाही, तर सुसंगतता (agreement) रिपोर्ट करा.
- तुमच्या पाइपलाइनमध्ये UNSTABLE ला 'failing state' बनवा.
- तुमच्या जज मॉडेलचे व्हर्जन फिक्स (pin) करा.
- जेव्हा एखादी तपासणी (check) अयशस्वी होते, तेव्हा ट्रेसेस (traces) वाचा.
ज्या डॅशबोर्डला तुम्ही पुनरुत्पादित (reproduce) करू शकत नाही, तो हिरवा डॅशबोर्ड कोणताही संकेत नाही. ती तुम्ही स्वतःला सांगितलेली एक गोष्ट आहे.
Optional learning community: https://t.me/GyaanSetuAi
