तुम्ही एक अंतर्गत साधन (internal tool) तयार केले आहे, ज्याद्वारे एक टीम मॉडेलच्या API ला कॉल न करताच LLM-चालित फीचरवर २८ युनिट टेस्ट्स (unit tests) रन करू शकते. तुम्ही मॉडेलला एका 'fakeable interface' मध्ये गुंडाळून आणि डिटरमिनिस्टिक (deterministic), ह्युरिस्टिक (heuristic) आणि LLM-आधारित मूल्यमापनाच्या तीन थरांचा वापर करून हे साध्य केले आहे.

जेव्हा LLM मजकूर (prose) तयार करते, तेव्हा स्टँडर्ड अ‍ॅसर्शन्स (assertions) निकामी ठरतात. एकाच प्रॉम्प्टमुळे प्रत्येक वेळी वेगळे वाक्य मिळू शकते, त्यामुळे assertEqual(output, expected) मॉडेलने योग्य वर्तन केले असूनही त्रुटी (failure) दर्शवते. बहुतेक इंजिनिअरिंग गट एकतर पडताळणीशिवाय फीचर रिलीज करतात किंवा मॉडेललाच टेस्ट करण्याचा प्रयत्न करतात, जणू काही ते एखादे स्थिर लायब्ररी (static library) आहे.

ही समस्या का महत्त्वाची आहे

LLMs आता ग्राहकांशी संबंधित वर्कफ्लोमध्ये (workflows) आहेत—उदा. ईमेल आउटरीच, सपोर्ट रिप्लाय, कंटेंट जनरेशन. एक चुकीची माहिती (hallucinated fact) किंवा लीक झालेली ओळख (identifier) ब्रँडची प्रतिष्ठा खराब करू शकते, खाजगी डेटा उघड करू शकते किंवा कंप्लायन्सचे उल्लंघन (compliance violations) करू शकते. विश्वसनीय टेस्ट स्ट्रॅटेजीशिवाय, टीम्स फ्लॅकी फेल्युअरचा (flaky failures) पाठलाग करण्यात वेळ वाया घालवतात किंवा प्रोडक्शनमध्ये समस्या निर्माण करणारे बग्स रिलीज करतात.

दृष्टिकोन: मॉडेलची जबाबदारी मर्यादित करा

पहिले पाऊल म्हणजे LLM नेमके काय करते यावर मर्यादा आणणे. लेखकाच्या सिस्टममध्ये मॉडेल फक्त आउटरीच मेसेजचा मसुदा (draft) तयार करते. सर्व राउटिंग लॉजिक, स्टेट मॅनेजमेंट आणि सेफ्टी चेक्स सामान्य कोडमध्ये राहतात. मॉडेलला एका विशिष्ट, सुस्पष्ट आउटपुटपुरते मर्यादित ठेवल्यामुळे, आजूबाजूची सिस्टम डिटरमिनिस्टिक आणि टेस्ट करण्यायोग्य राहते.

हे शक्य करण्यासाठी, LLM एका 'provider interface' च्या मागे असते, ज्यामुळे टेस्टमध्ये 'fake version' वापरता येते. प्रोडक्शनमध्ये इम्प्लिमेंटेशन बाह्य API ला कॉल करते; टेस्ट सुईटमध्ये एक हलका (lightweight) 'fake' एक तयार प्रतिसाद (canned response) देतो. उर्वरित कोड फक्त इंटरफेससोबत संवाद साधत असल्याने, संपूर्ण वर्कफ्लो युनिट टेस्ट्सद्वारे तपासता येतो ज्यामध्ये नेटवर्कचा वापर होत नाही. परिणामी एक प्रेडिक्टेबल (predictable) कोअर तयार होतो ज्याची २८ टेस्ट्सद्वारे पडताळणी केली जाते.

एक प्रामाणिक इव्हॅल्युएशन हार्नेस (evaluation harness)

व्याप्ती मर्यादित असूनही, मॉडेलचे आउटपुट नॉन-डिटरमिनिस्टिक (nondeterministic) राहते. म्हणून लेखकाने तीन-स्तरीय इव्हॅल्युएशन हार्नेस तयार केला, ज्यातील प्रत्येक स्तर जोखमीच्या वेगवेगळ्या प्रकारांना हाताळतो.

  • स्तर १ – डिटरमिनिस्टिक चेक्स (Deterministic checks) साधे रेग्युलर-एक्सप्रेशन (regular-expression) नियम चुकीचा बिल्डिंग आयडी किंवा प्रतिबंधित टोकन्स यांसारख्या ठोस चुका पकडतात. हे चेक्स जलद असतात आणि पास/फेल (pass/fail) निकाल देतात.

  • स्तर २ – ह्युरिस्टिक चेक्स (Heuristic checks) स्क्रिप्ट्स चुकीचे नंबर किंवा तारखा शोधतात, ज्यामुळे स्पष्टपणे चुकीची माहिती (factual fabrications) पकडली जाते. ज्या दाव्यांमध्ये संख्यात्मक संकेत नसतात, ते हे चेक्स पकडू शकत नाहीत, आणि लेखक ही मर्यादा स्पष्टपणे मान्य करतात.

  • स्तर ३ – LLM जज (LLM judge) एक दुय्यम मॉडेल टोन आणि व्यावसायिकता (professionalism) तपासते. ही पायरी दुसऱ्या संभाव्य (probabilistic) सिस्टमवर अवलंबून असल्याने, ती केवळ अशा व्यक्तिनिष्ठ (subjective) पैलूंसाठी वापरली जाते जिथे डिटरमिनिस्टिक नियम लावणे अशक्य आहे.

या हार्नेसची गुरुकिल्ली इव्हॅल्युएशनसाठी वापरलेला डेटासेट आहे. लेखकाने ज्ञात फेल्युअर पॅटर्न—विशिष्ट सापळे आणि डोमेन नॉलेज—एनकोड केले आहेत, जेणेकरून हार्नेस नेमक्या त्याच चुका तपासतो ज्या प्रत्यक्षात दिसून आल्या आहेत. हे कोणतेही जादुई "catch-all" साधन नसून एक लक्ष्यित सेफ्टी नेट (safety net) आहे.

टीम्ससाठी याचा अर्थ काय?

  • LLM चे काम मर्यादित ठेवा. जबाबदाऱ्या कमी असल्यास आयसोलेशन आणि टेस्टिंग करणे सोपे होते.
  • राउटिंग, स्टेट आणि सेफ्टी कोडमध्ये ठेवा. पारंपारिक लॉजिक डिटरमिनिस्टिक आणि पूर्णपणे टेस्ट करण्यायोग्य राहते.
  • मॉडेलला 'fakeable interface' द्वारे उपलब्ध करून द्या. युनिट टेस्ट्स बाह्य कॉल्सशिवाय चालतात, ज्यामुळे टेस्ट सुईट जलद आणि विश्वसनीय राहते.
  • इव्हॅल्युएशन्सचे स्तर करा. डिटरमिनिस्टिक नियमांपासून सुरुवात करा, ज्ञात हॅलुसिनेशनसाठी ह्युरिस्टिक्स जोडा आणि व्यक्तिनिष्ठ गुणवत्ता तपासणीसाठी LLM जजेस राखून ठेवा.
  • मर्यादा स्पष्ट करा. कोणताही स्तर परिपूर्णतेची खात्री देत नाही; हार्नेस फक्त तुम्ही प्रोग्राम केलेले घटकच शोधू शकतो.

प्रतिवाद: तुम्ही तरीही मॉडेलला स्वतः युनिट-टेस्ट करू शकत नाही

मॉडेल हे एक 'मूव्हिंग टार्गेट' (moving target) आहे हे लेखक मान्य करतात. अगदी LLM जज लेयरमध्येही तेच नॉन-डिटरमिनिझम असते ज्याचे ते मूल्यांकन करण्याचा प्रयत्न करत आहे. परिणामी, रिलीजपूर्वी प्रत्येक हॅलुसिनेशन किंवा पॉलिसी उल्लंघन पकडले जाईल याची सिस्टम कधीही खात्री देऊ शकत नाही. हा दृष्टिकोन जोखीम कमी करतो, ती पूर्णपणे काढून टाकत नाही, आणि नवीन फेल्युअर मोड्स समोर येत असताना इव्हॅल्युएशन डेटा अद्ययावत ठेवण्याच्या टीमच्या क्षमतेवर तो अवलंबून असतो.

निष्कर्ष (Takeaway)

तुम्ही LLM च्या नेमक्या आउटपुटची खात्री देणारी क्लासिक युनिट टेस्ट लिहू शकत नाही, परंतु तुम्ही अशी सिस्टम तयार करू शकता जिथे मॉडेलचा प्रभाव मर्यादित असेल, त्याचा इंटरफेस बदलता येईल आणि त्याच्या आउटपुटची विविध स्तरांवर पारदर्शकपणे तपासणी केली जाईल. ही युती एका अस्थिर (flaky) घटकाला मोठ्या, टेस्ट करण्यायोग्य ॲप्लिकेशनचा एक प्रेडिक्टेबल भाग बनवते.