आपने एक ऐसा इंटरनल टूल बनाया है जो एक टीम को LLM-संचालित फीचर पर 28 यूनिट टेस्ट चलाने की अनुमति देता है, वह भी मॉडल के API को कॉल किए बिना। आपने इसे मॉडल को एक फेकेबल इंटरफ़ेस (fakeable interface) में लपेटकर और तीन स्तरों—डिटरमिनिस्टिक (deterministic), ह्यूरिस्टिक (heuristic) और LLM-आधारित मूल्यांकन—को जोड़कर किया है।

जैसे ही कोई LLM टेक्स्ट जेनरेट करता है, स्टैंडर्ड एसेर्शन (standard assertions) काम करना बंद कर देते हैं। एक ही प्रॉम्प्ट हर बार एक अलग वाक्य दे सकता है, इसलिए assertEqual(output, expected) तब भी विफलता (failure) दिखाता है जब मॉडल सही ढंग से व्यवहार कर रहा हो। अधिकांश इंजीनियरिंग ग्रुप्स या तो बिना किसी वेरिफिकेशन के फीचर शिप कर देते हैं या फिर मॉडल को ही टेस्ट करने की कोशिश करते हैं, जैसे कि एक लगातार बदलते लक्ष्य को कोई स्टैटिक लाइब्रेरी (static library) मान लिया गया हो।

यह समस्या क्यों महत्वपूर्ण है

LLMs अब कस्टमर-फेसिंग वर्कफ़्लो का हिस्सा हैं—जैसे ईमेल आउटरीच, सपोर्ट रिप्लाई और कंटेंट जनरेशन। एक भी गलत तथ्य (hallucinated fact) या लीक हुआ आइडेंटिफायर ब्रांड की प्रतिष्ठा को नुकसान पहुँचा सकता है, निजी डेटा को उजागर कर सकता है, या अनुपालन उल्लंघन (compliance violations) का कारण बन सकता है। एक विश्वसनीय टेस्ट रणनीति के बिना, टीमें फ्लैकी फेलियर (flaky failures) के पीछे समय बर्बाद करती हैं या ऐसे बग्स शिप कर देती हैं जो केवल प्रोडक्शन में सामने आते हैं।

दृष्टिकोण: मॉडल की जिम्मेदारी कम करें

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

इसे संभव बनाने के लिए, LLM एक प्रोवाइडर इंटरफ़ेस (provider interface) के पीछे रहता है, जिससे टेस्ट में एक फेक वर्जन का उपयोग किया जा सकता है। प्रोडक्शन में, इम्प्लीमेंटेशन बाहरी API को कॉल करता है; टेस्ट सुइट में, एक हल्का फेक वर्जन एक कैंड रिस्पॉन्स (canned response) लौटाता है। चूंकि बाकी कोड केवल इंटरफ़ेस के साथ इंटरैक्ट करता है, इसलिए पूरे वर्कफ़्लो को उन यूनिट टेस्ट द्वारा चलाया जा सकता है जो कभी नेटवर्क को टच नहीं करते। इसका परिणाम एक प्रेडिक्टेबल कोर है जिसे 28 टेस्ट सत्यापित करते हैं।

एक ईमानदार मूल्यांकन हार्नेस (evaluation harness)

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

  • लेयर 1 – डिटरमिनिस्टिक चेक साधारण रेगुलर-एक्सप्रेशन नियम गलत बिल्डिंग ID या प्रतिबंधित टोकन जैसी ठोस गलतियों को पकड़ लेते हैं। ये चेक तेज़ होते हैं और बाइनरी पास/फेल परिणाम देते हैं।

  • लेयर 2 – ह्यूरिस्टिक चेक स्क्रिप्ट्स गलत नंबरों या तारीखों (hallucinated numbers or dates) की तलाश करते हैं, जिससे स्पष्ट तथ्यात्मक बनावट को पकड़ा जा सके। वे उन गलत दावों को नहीं पकड़ पाते जिनमें संख्यात्मक संकेत नहीं होते, और लेखक खुले तौर पर इस सीमा को स्वीकार करते हैं।

  • लेयर 3 – LLM जज एक सेकेंडरी मॉडल टोन और प्रोफेशनलिज्म को रेट करता है। चूंकि यह चरण एक अन्य प्रोबेबिलिस्टिक सिस्टम (probabilistic system) पर निर्भर करता है, इसलिए इसका उपयोग केवल उन व्यक्तिपरक (subjective) पहलुओं के लिए किया जाता है जहाँ डिटरमिनिस्टिक नियम असंभव होंगे।

हार्नेस की कुंजी मूल्यांकन के लिए उपयोग किया जाने वाला डेटासेट है। लेखक ने ज्ञात विफलता पैटर्न—विशिष्ट जाल और डोमेन ज्ञान—को एनकोड किया है, ताकि हार्नेस ठीक उन्हीं गलतियों का परीक्षण करे जो व्यवहार में सामने आई हैं। यह कोई जादुई "सब कुछ पकड़ने वाला" टूल नहीं है, बल्कि एक लक्षित सुरक्षा जाल (safety net) है।

टीमों के लिए इसका क्या अर्थ है

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

काउंटर-पॉइंट: आप अभी भी मॉडल को खुद यूनिट-टेस्ट नहीं कर सकते

लेखक स्वीकार करते हैं कि मॉडल एक बदलता हुआ लक्ष्य (moving target) है। यहाँ तक कि LLM जज लेयर भी उसी नॉन-डिटरमिनिस्टिज्म को विरासत में लेती है जिसका वह आकलन करने की कोशिश करती है। परिणामस्वरूप, सिस्टम कभी यह गारंटी नहीं दे सकता कि रिलीज़ से पहले हर हैलुसिनेशन या पॉलिसी उल्लंघन को पकड़ लिया जाएगा। यह दृष्टिकोण जोखिम को कम करता है, खत्म नहीं करता, और यह नई विफलता के तरीकों के आने पर मूल्यांकन डेटा को अपडेट रखने की टीम की क्षमता पर निर्भर करता है।

निष्कर्ष (Takeaway)

आप ऐसा क्लासिक यूनिट टेस्ट नहीं लिख सकते जो LLM के सटीक आउटपुट का दावा करे, लेकिन आप एक ऐसा सिस्टम बना सकते हैं जहाँ मॉडल का प्रभाव सीमित हो, उसका इंटरफ़ेस प्रतिस्थापनीय (replaceable) हो, और उसका आउटपुट लेयर्ड, पारदर्शी जांच के माध्यम से स्क्रीन किया गया हो। यह संयोजन एक अस्थिर घटक को एक बड़े, टेस्ट करने योग्य एप्लिकेशन के प्रेडिक्टेबल हिस्से में बदल देता है।