पिछले अध्यायों तक हमने टूल रखने वाले, याददाश्त इस्तेमाल करने वाले, और कई एजेंटों में बँटवारा करने वाले एजेंट डिज़ाइन किए। यहाँ कई डेवलपर एक दीवार से टकराते हैं। "बना तो लिया, पर यह सचमुच ठीक से चल रहा है या नहीं, यही समझ नहीं आता" वाली समस्या। एजेंट प्रायिक (probabilistic) रूप से चलता है, इसलिए एक ही निर्देश पर भी हर बार हूबहू एक जैसा नहीं चलता। इसीलिए "मापने की व्यवस्था (मूल्यांकन)" और "दृश्यमान बनाने की व्यवस्था (ऑब्ज़र्वेबिलिटी)", असल इस्तेमाल की जीवनरेखा बनती हैं। इस अध्याय में, गुणवत्ता को आँकड़ों में पकड़ने, नाकामी दोहराने, और सुधार लगातार घुमाते रहने की बुनियाद बनाएँगे।
लक्ष्य है "अटकल नहीं, मापे गए आँकड़ों से एजेंट को बेहतर बनाना"
मूल्यांकन सबसे अहम क्यों है
सामान्य प्रोग्राम में, एक ही इनपुट देने पर एक ही नतीजा लौटता है। पर एजेंट के केंद्र में LLM बैठा है, और उसका आउटपुट प्रायिक है। एक ही निर्देश पर भी, चुना गया टूल, तरीका, और शब्दावली हर बार ज़रा-ज़रा बदलती है। यानी, एक बार अच्छे से चल गया, इसका मतलब यह हरगिज़ नहीं कि अगली बार भी चलेगा।
यहीं एजेंट डेवलपमेंट की ख़ास फिसलन है। डेमो में शानदार चला, पर असली यूज़र ने ज़रा अलग ढंग से माँगा और झट टूट गया — यह कोई अनोखी बात नहीं। वजह सीधी है — "चल गया = सही" ज़रूरी नहीं। शायद इत्तेफ़ाक़ से सही निकल आया हो, और 10 में से 3 बार गलत कर रहा हो। यह जानने के लिए, गिनने के सिवा कोई चारा नहीं।
💡 जो मापा न जा सके, उसे सुधारा नहीं जा सकता। "कुछ बेहतर हुआ-सा लगता है" — यह सुधार नहीं है। प्रॉम्प्ट बदला तो सफलता-दर बढ़ी या घटी? टूल एक जोड़ा तो बेवजह धीमा या महँगा तो नहीं हुआ? आँकड़ों में तुलना कर पाने पर ही तय होता है कि बदलाव आगे का क़दम है या पीछे का। मूल्यांकन "बनाने के बाद का होमवर्क" नहीं, डेवलपमेंट की बुनियाद है।
एक और अहम बात है, मूल्यांकन को टालना नहीं। शुरू से मुकम्मल मूल्यांकन-ढाँचा नहीं चाहिए। पर "पहले बना लो, चल जाए तो मूल्यांकन सोचेंगे" वाले ढंग से बढ़ें, तो आमतौर पर मूल्यांकन कभी बनता ही नहीं। छोटा ही सही, पहला एजेंट बनाते ही तुरंत मापना शुरू कर दें — यह घुमावदार दिखकर भी सबसे नज़दीकी रास्ता है। मूल्यांकन का पूरा खाका AI एजेंट मूल्यांकन की व्यावहारिक गाइड, और मूलतः इसका मतलब क्या है यह एजेंट मूल्यांकन (evals) क्या है से शुरू करें।
क्या मूल्यांकन करें — नतीजा और सफ़र
"मूल्यांकन" सुनते ही, ज़्यादातर लोग बस आख़िरी जवाब सही है या नहीं, यही सोचते हैं। वह बेशक शुरुआत है, पर एजेंट में इतने से काम नहीं चलता। क्योंकि एजेंट में "बीच में क्या किया" बहुत अहम है। सही जवाब तक पहुँच भी जाए, पर बेकार में 10 बार टूल बुलाकर समय और लागत बर्बाद की हो, तो असल काम में नहीं चलेगा। उल्टा, जवाब भले ज़रा चूक गया, पर बीच के निर्णय सही थे — ऐसा भी होता है।
इसलिए, मूल्यांकन के लक्ष्य को 4 पहलुओं में बाँटकर सोचते हैं। इन 4 को दिमाग में रख लें, तो "क्या मापूँ यही समझ नहीं आता" वाली उलझन मिट जाती है।
दिया गया लक्ष्य पूरा हुआ या नहीं। जवाब सटीक है, ज़रूरतें पूरी करता है। सबसे बुनियादी संकेतक।
कौन-सा टूल, किस क्रम में, क्यों बुलाया। प्रक्रिया वाजिब है या नहीं। घुमाव या बेवजह के चरण तो नहीं।
सही टूल, सही आर्ग्युमेंट से बुलाया या नहीं। न होने वाला टूल तो नहीं बुलाया, या नाकामी को अनदेखा तो नहीं किया।
एक बार के क्रियान्वयन में खपा टोकन, शुल्क, और लगा समय। गुणवत्ता के अनुपात में है या नहीं।
📊 "सफ़र" मापना ही एजेंट मूल्यांकन का दिल है। सामान्य AI आउटपुट का मूल्यांकन जहाँ "जवाब मिलाना" है, वहीं एजेंट मूल्यांकन "जवाब + वहाँ तक पहुँचने की प्रक्रिया" देखता है। जिसका सफ़र गंदा है, वह एजेंट शर्तें ज़रा बदलते ही आसानी से बिखर जाता है। उल्टा, जिसका सफ़र सधा हुआ है, वह थोड़ा टलने पर भी ख़ुद को सँभाल लेता है। प्रक्रिया देखने से ही, सुधार का सुराग़ मिलता है।
मूल्यांकन के 5 तरीके
"तो, मापें कैसे" — यहीं असल काम का केंद्र है। मूल्यांकन के तरीकों की कई किस्में हैं, और हर एक के मज़बूत-कमज़ोर पक्ष अलग हैं। किसी एक के भरोसे रहने के बजाय, जो मापना है उसके मुताबिक़ जोड़-मिलाना ही तरीका है। 5 प्रतिनिधि, गुण-दोष समेत देखें।
पहले से तैयार "सही जवाब" और एजेंट के आउटपुट को मिलाकर मेल मापना। वर्गीकरण, निष्कर्षण, गणना जैसे एक-तय-जवाब वाले कामों के लिए उपयुक्त।
गुण: साफ़, स्वचालित करने में आसान, और डगमगाता नहीं।
दोष: "सही जवाब एक तय नहीं" वाले मुक्त-लेखन में इस्तेमाल मुश्किल।
"ज़रूरी शब्द शामिल है", "JSON के रूप में सही फ़ॉर्मैट है", "निषिद्ध शब्द तो नहीं" जैसी तयशुदा शर्तों से यंत्रवत जाँच।
गुण: तेज़, कम-लागत, और फ़ॉर्मैट व सुरक्षा-शर्तों की जाँच में मज़बूत।
दोष: "मतलब सही है या नहीं" जैसी धुँधली गुणवत्ता नहीं माप सकता।
दूसरे LLM को अंकन-मानदंड देकर, आउटपुट का अच्छा-बुरा आँकवाना। सार की गुणवत्ता या जवाब की मददगारी जैसे एक-तय-जवाब न रखने वाले कामों को माप सकता है।
गुण: मुक्त-लेखन या व्यक्तिनिष्ठ गुणवत्ता को, बड़ी मात्रा में स्वचालित आँक सकता है।
दोष: अंकनकर्ता ख़ुद डगमगाता / पक्षपाती होता है। मानदंड लिखित करना और इंसानी नमूना-जाँच ज़रूरी।
प्रतिनिधि टास्क को टेस्ट सेट में समेटकर, हर बदलाव पर एकसाथ चलाना। "कल तक जो पास हो रहा था, वह आज के सुधार से टूट तो नहीं गया" — इसकी हिफ़ाज़त वाली व्यवस्था।
गुण: बदलाव से आई गिरावट (डिग्रेडेशन) को जल्दी पकड़ लेता है।
दोष: टेस्ट सेट तैयार करने और सँभालने में मेहनत लगती है।
रिलीज़ के बाद, असली यूज़र के क्रियान्वयन को लगातार देखना। सफलता-दर, लागत, देरी की चाल, और यूज़र की राय (👍／👎) इकट्ठा कर हक़ीक़ी प्रदर्शन का पीछा करना।
गुण: असली माहौल में ही सामने आने वाली समस्याएँ, या अनचाहे इस्तेमाल पकड़ लेता है।
दोष: उत्तर-वर्ती। समस्या "होने के बाद" ही पता चलती है। पूर्व-मूल्यांकन के साथ इस्तेमाल ज़रूरी।
⚠️ जोड़-मिलाना ही नियम है। फ़ॉर्मैट व सुरक्षा-शर्तें नियम-आधारित से, तय-जवाब वाले सही-जवाब मिलान से, मुक्त-लेखन LLM-as-judge से, हर बदलाव पर रिग्रेशन टेस्ट से, और रिलीज़ के बाद प्रोडक्शन मॉनिटरिंग से। किसी एक तरीके से सब कुछ निपटाने की कोशिश मत करें। सस्ते-तेज़ तरीक़े (①②) से ज़्यादातर छान लें, और महँगे तरीके (③) को सिर्फ़ ज़रूरी हिस्से पर इस्तेमाल करें, तो लागत क़ाबू में रखते हुए सटीकता बचा सकते हैं। ज़्यादा विस्तार के लिए LLM मूल्यांकन क्या है देखें।
मूल्यांकन डेटा (टेस्ट सेट) कैसे बनाएँ
कोई भी तरीका इस्तेमाल करें, उसकी बुनियाद है "क्या मापना है इसकी सामग्री" = मूल्यांकन डेटा (टेस्ट सेट)। यह असल में, "ऐसे इनपुट पर, ऐसा नतीजा चाहिए" वाले प्रतिनिधि टास्क का संग्रह है। यहाँ कमज़ोरी हो, तो कितना ही शानदार मूल्यांकन-तरीका हो, भरोसे लायक़ नहीं। उल्टा, अच्छा टेस्ट सेट भर हो, तो मूल्यांकन का 80% काम सफल-सा समझें।
बनाने का तरीका सरल है, नीचे के क्रम में बढ़ें। मुकम्मलता की जगह, पहले छोटे से शुरू करके बढ़ाना नियम है।
एजेंट से असल में जो माँगा जा सकता है, उसे सामान्य, सीमांत, और आसानी से नाकाम होने वाले उदाहरणों समेत इकट्ठा करें।
हर टास्क का "ऐसा चाहिए" लिखें। सही जवाब हो, पूरी करने योग्य शर्त हो, या अंकन-मानदंड — कोई भी चले।
शुरू में 10~20 ही काफ़ी हैं। गिनती से ज़्यादा, ज़मीनी हक़ीक़त झलकाने वाली "गुणवत्ता" को प्राथमिकता दें।
प्रोडक्शन में मिले नाकामी के उदाहरण टेस्ट सेट में जोड़ते जाएँ। जितना इस्तेमाल, उतना समझदार होने वाली पूँजी बनती है।
✅ "बस 10" को कम मत आँकें। "नमूने इतने कम हैं कि कोई मतलब नहीं" — ऐसा लग सकता है। पर सोच-समझकर चुने 10, बेतरतीब जमा किए 1000 से कहीं ज़्यादा काम के होते हैं। असल में जिनसे परेशानी है ऐसे प्रतिनिधि 10 मामले, पहले मापने लायक़ बना लें। इतने भर से, प्रॉम्प्ट या टूल का बदलाव अच्छी दिशा में है या बुरी, यह वहीं तय कर पाते हैं। टेस्ट सेट एक बार बनाकर ख़त्म नहीं होता, बल्कि हर नाकामी मिलने पर एक-एक जोड़कर बढ़ने वाली, जीवित पूँजी है।
ऑब्ज़र्वेबिलिटी — हरकत को दृश्यमान बनाना
मूल्यांकन अगर "अच्छा-बुरा मापना" है, तो ऑब्ज़र्वेबिलिटी "ऐसा क्यों हुआ इसका पीछा कर पाना" है। मूल्यांकन से "सफलता-दर घटी" पता भी चल जाए, तो उसमें क्या हुआ था यह देख न पाएँ, तो सुधारने का कोई ज़रिया नहीं। एजेंट कई चरण भीतर घुमाता है, इसलिए बाहर से देखने पर "इनपुट डाला, कुछ हुआ, नतीजा आया" वाला ब्लैक बॉक्स बन जाता है। इसे खोलकर भीतर दिखाने लायक़ बनाना ही ऑब्ज़र्वेबिलिटी है।
ऑब्ज़र्वेबिलिटी को थामने वाले घटक, मोटे तौर पर 3 हैं।
एक बार के क्रियान्वयन को शुरू से आख़िर तक पूरा रिकॉर्ड किया हुआ। "इनपुट → सोच → टूल कॉल → नतीजा → अगला निर्णय" की पूरी शृंखला, समय-क्रम में पूरी पीछा की जा सकती है।
हर एक चरण में, कैसा प्रॉम्प्ट भेजा, किन आर्ग्युमेंट से टूल बुलाया, और क्या लौटा। टोकन खपत और लगा समय भी यहीं छोड़ें।
जिस क्रियान्वयन में समस्या हुई, उसे उसी इनपुट-उसी अवस्था में दोबारा पीछा कर पाना। दोहरा पाने पर ही कारण की पहचान और सुधार की जाँच हो पाती है।
इन्हें हाथ से लॉग में लिखते जाना भी संभव है, पर असल काम में ट्रेसिंग टूल इस्तेमाल करना आम है। ट्रेसिंग टूल, एजेंट के हर चरण को अपने आप पकड़कर, समय-क्रम के पेड़ (ट्री) के रूप में देखने-लायक़ दृश्य बना देता है। "किस चरण में समय लगा", "कहाँ टूल कॉल नाकाम हुआ", "किस निर्णय पर गलत दिशा में मुड़ा" — यह एक नज़र में समझ आ जाता है।
📊 ट्रेस "डीबग की आँख" है। ऊपर के उदाहरण में, ④ पर टूल कॉल नाकाम हुआ, और ⑤ पर एजेंट ने ख़ुद को सँभाल लिया। सिर्फ़ नतीजा देखें तो "सफल", पर ट्रेस देखें तो "कॉलम नंबर आसानी से गलत करता है" वाली कमज़ोरी दिख जाती है। यही समझ अगले सुधार से जोड़ती है। ऑब्ज़र्वेबिलिटी की सोच AI ऑब्ज़र्वेबिलिटी क्या है में व्यवस्थित रूप से समझाई गई है।
सुधार का लूप घुमाना
यहाँ तक के औज़ार — मूल्यांकन व टेस्ट सेट, और ऑब्ज़र्वेबिलिटी — अकेले-अकेले भी काम के हैं, पर असली दम तब निकलता है जब इन्हें एक लूप के रूप में घुमाया जाए। एजेंट डेवलपमेंट "एक बार बनाकर मुकम्मल" नहीं, बल्कि मापो, कमज़ोरी ढूँढो, सुधारो, फिर मापो वाले चक्र से धीरे-धीरे बेहतर बनाने वाली मेहनत है।
टेस्ट सेट पर मूल्यांकन चलाकर, सफलता-दर, लागत, देरी को आँकड़ों में निकालो।
नाकाम हुए क्रियान्वयन की ट्रेस पढ़कर, कहाँ और क्यों गलत हुआ यह पता लगाओ।
प्रॉम्प्ट, टूल का विवरण, तरीका, बँटवारा — कारण से जुड़े हिस्से में से एक बदलो।
उसी टेस्ट सेट पर दोबारा मूल्यांकन कर, चाहा गया सुधार आया या नहीं, और कुछ और बिगड़ा तो नहीं, यह जाँचो।
इस लूप में एक अहम तरकीब है। एक बार में बदलो, जितना हो सके एक ही चीज़। प्रॉम्प्ट, टूल और तरीका एक साथ बदल दें, तो सफलता-दर बढ़ भी जाए तो "कौन-सा बदलाव काम आया" यह पता नहीं चलता। एक-एक बदलकर मापने से ही, बदलाव और नतीजे का कारण-संबंध जुड़ता है, और समझ जमा होती जाती है। सादी बात है, पर यही "यूँ ही के सुधार" और "पक्के सुधार" के बीच की रेखा है।
✅ लूप तेज़ और छोटा घुमाएँ। बड़ी मरम्मत एक बार धड़ाम से करने के बजाय, छोटे बदलाव फुर्ती से कई बार घुमाना नतीजतन जल्दी बेहतर बनाता है। टेस्ट सेट 10 हो, तो बदलते ही तुरंत माप सकते हैं। यह "बदलो → तुरंत मापो" वाली लय बन जाए, तो एजेंट डेवलपमेंट अटकल का जुआ नहीं, बल्कि पक्के तौर पर आगे बढ़ने वाला इंजीनियरिंग काम बन जाता है।
- एजेंट प्रायिक है और "चल गया = सही" ज़रूरी नहीं। मापे बिना सुधार नहीं।
- मूल्यांकन के लक्ष्य 4 पहलू — आख़िरी नतीजा, बीच का सफ़र, टूल कॉल, लागत और देरी। ख़ासकर "सफ़र" ही एजेंट मूल्यांकन का दिल।
- तरीके 5 — सही-जवाब मिलान, नियम-आधारित, LLM-as-judge, रिग्रेशन टेस्ट, प्रोडक्शन मॉनिटरिंग को लक्ष्य के मुताबिक़ जोड़-मिलाएँ।
- मूल्यांकन डेटा प्रतिनिधि टास्क थोड़े से। सोच-समझे 10, बेतरतीब 1000 पर भारी। नाकामी जोड़कर बढ़ाएँ।
- ऑब्ज़र्वेबिलिटी है एक्ज़ीक्यूशन ट्रेस, हर चरण का लॉग, नाकामी दोहराना। ट्रेसिंग टूल से हरकत दृश्यमान बनाएँ।
- सुधार है मापो → कमज़ोरी ढूँढो → सुधारो → फिर मापो का लूप। बदलाव एक-एक, छोटा-तेज़ घुमाएँ।
गुणवत्ता माप ली और हरकत दृश्यमान बना ली, तो अगला है "बेकाबू होना, गलत संचालन, दुरुपयोग कैसे रोकें"। पिछले अध्याय 4 "मल्टी-एजेंट डिज़ाइन" में बढ़ाई स्वायत्तता को, सुरक्षित रूप से सँभालने का डिज़ाइन सीखें। अगले अध्याय 6 "गार्डरेल और सुरक्षा" की ओर बढ़ते हैं।