जब कोई बेंचमार्क न हो, तब AI एजेंट्स का परीक्षण कैसे करें — नाथानीएल वील, एयर कनाडा
원제 · How to Test AI Agents When No Benchmark Exists — Nathanael Weill, Air Canada
핵심 요약
डोमेन-विशिष्ट AI एजेंटों के मूल्यांकन के लिए सार्वजनिक बेंचमार्क के अभाव में, सही उत्तर से प्रश्न उत्पन्न करके और मानवीय राय के बजाय कोड-आधारित स्वचालित जाँच का उपयोग करके परीक्षण आवृत्ति को सप्ताह में एक से बढ़ाकर प्रति दिन दर्जनों किया जाता है।
하이라이트
सार्वजनिक बेंचमार्क और डोमेन विशेषज्ञों तक सीमित पहुंच होने पर, एजेंटों का मूल्यांकन करने के लिए प्रश्न-उत्पत्ति और कोड-आधारित जाँच का उपयोग किया जाता है।
दूरसंचार Q&A सिस्टम प्रोजेक्ट में विशेषज्ञों के साथ साप्ताहिक बैठकों के कारण मूल्यांकन सप्ताह में केवल एक बार होता था, जिसे स्वचालित परीक्षणों के माध्यम से प्रति दिन दर्जनों तक बढ़ाया गया।
एयर कनाडा के आपूर्तिकर्ता अनुबंध विश्लेषण प्रोजेक्ट में, मूल हस्ताक्षरित अनुबंध से एक खंड को हटाकर यह परीक्षण किया जाता है कि एजेंट अनुपस्थित खंड को पहचान पाता है या नहीं।
न्यायाधीश के रूप में LLM (LLM-as-judge) का उपयोग करने से अत्यधिक शोर उत्पन्न होता है, इसलिए सटीक मिलान और कोड-आधारित सत्यापन अधिक प्रभावी होते हैं।
परीक्षणों को उत्पन्न करने का मुख्य उद्देश्य एजेंट में सुधार करना और बेहतर प्रॉम्प्ट तैयार करना है, न कि उत्पाद को शिप करने का अंतिम गो-नो-गो निर्णय लेना।
타임라인
एजेंट मूल्यांकन में डोमेन विशेषज्ञों की कमी की चुनौती
विशिष्ट व्यावसायिक क्षेत्रों जैसे संचालन, कॉर्पोरेट और वाणिज्यिक के लिए एजेंट बनाते समय सार्वजनिक बेंचमार्क उपलब्ध नहीं होते हैं। डेटा वैज्ञानिकों और AI इंजीनियरों के पास डोमेन की गहराई न होने और विशेषज्ञों की व्यस्तता के कारण पारंपरिक मूल्यांकन लगभग असंभव हो जाता है। शुरुआती दूरसंचार प्रोजेक्ट में, टीम सप्ताह में केवल एक बार विशेषज्ञों के साथ बड़ी स्क्रीन पर पांच अलग-अलग चैटबॉट की समीक्षा करती थी, जिससे प्रगति की गति सीमित हो जाती थी।
- एयर कनाडा में विभिन्न व्यावसायिक खंडों के लिए AI समाधान प्रदान करते समय सार्वजनिक बेंचमार्क का अभाव होता है।
- डोमेन विशेषज्ञ अपने कार्यों में अत्यधिक व्यस्त होते हैं, जिसके कारण AI एजेंटों के मूल्यांकन के लिए उनकी तक पहुंच सीमित होती है।
- दूरसंचार Q&A सिस्टम प्रोजेक्ट में विशेषज्ञों के साथ सप्ताह में एक बार होने वाली बैठकों के कारण विकास चक्र अत्यधिक धीमा था।
समस्या को उलटना और स्वचालित मूल्यांकन को लागू करना
पारंपरिक मानवीय मूल्यांकन के विपरीत, समस्या को उल्टा करके स्वचालित परीक्षण प्रणाली बनाई जाती है। सिस्टम एक दस्तावेज़ के पृष्ठ से प्रश्न उत्पन्न करता है और एजेंट द्वारा खोजे गए उत्तर की तुलना स्वचालित कोड के माध्यम से करता है। इस स्वचालन से मूल्यांकन की गति प्रतिदिन दर्जनों परीक्षणों तक पहुँच जाती है, जिससे जटिलता को कम करने और सही एम्बेडिंग तथा चंकिंग पर ध्यान केंद्रित करने में मदद मिलती है।
- एक पृष्ठ से शुरुआत करके LLM से प्रश्न उत्पन्न कराया जाता है और एजेंट के उत्तर की तुलना कोड द्वारा की जाती है।
- मूल्यांकन की आवृत्ति सप्ताह में एक बार से बढ़कर प्रतिदिन दर्जनों परीक्षणों तक पहुँच जाती है।
- परीक्षण सेट की उपलब्धता के कारण दूरसंचार प्रोजेक्ट में समाधान ने सफलतापूर्वक मूल्य प्रदान किया।
आपूर्तिकर्ता अनुबंध विश्लेषण के लिए पाँच परीक्षण तकनीकें
अनुबंध विश्लेषण जैसे जटिल कार्यों के लिए, टीम पाँच अलग-अलग परीक्षण तकनीकें उपयोग करती है। पहली तकनीक पिछले अनुबंधों के अंतर की तुलना करना है, जो संस्करणों की कमी के कारण हमेशा काम नहीं करती। दूसरी और पाँचवी तकनीक में नियमों (जैसे 1 मिलियन डॉलर की सीमा) और रिक्त स्थानों वाले टेम्पलेट्स का उपयोग करके कई परीक्षण केस उत्पन्न किए जाते हैं। सबसे प्रभावी तकनीक में एक वैध अनुबंध से एक मुख्य खंड को हटा दिया जाता है, और एजेंट को यह पहचानना होता है कि वहाँ कुछ गायब है।
- एयर कनाडा में आपूर्तिकर्ता अनुबंधों की जाँच और अनुपालन विश्लेषण के लिए कोई मौजूदा सार्वजनिक बेंचमार्क नहीं है।
- विशिष्ट नियमों और सीमा सीमाओं के आधार पर अनुबंध उत्पन्न करके 275 परीक्षण केस तैयार किए जाते हैं।
- हस्ताक्षरित अनुबंध से एक खंड को हटाकर एजेंट की अनुपस्थिति का पता लगाने की क्षमता का परीक्षण किया जाता है, जो सबसे शक्तिशाली दृष्टिकोण है।
LLM-as-Judge से परहेज और एजेंट विकास का दृष्टिकोण
न्यायाधीश के रूप में LLM का उपयोग करने में आने वाली कठिनाइयों के कारण, टीम यथासंभव कोड-आधारित सत्यापन और सटीक मिलानों पर निर्भर करती है। विशेषज्ञ प्रतिक्रिया का उपयोग कोड को सीधे बदलने के बजाय अधिक सटीक परीक्षण सेट और बेहतर प्रॉम्प्ट तैयार करने के लिए किया जाता है। अंततः, स्वचालित परीक्षण उत्पाद को तुरंत शिप करने का एक निश्चित पैमाना नहीं है, बल्कि यह विकास प्रक्रिया को गति देने और एजेंट की सटीकता को लगातार सुधारने का एक साधन है।
- न्यायाधीश के रूप में LLM का उपयोग करने से अत्यधिक शोर उत्पन्न होता है, इसलिए सटीक मिलान और कोड-आधारित जाँच को प्राथमिकता दी जाती है।
- विशेषज्ञों की प्रतिक्रिया का उपयोग एजेंट को सीधे ठीक करने के लिए नहीं, बल्कि बेहतर परीक्षण और प्रॉम्प्ट उत्पन्न करने के लिए किया जाता है।
- परीक्षणों को उत्पन्न करना उत्पाद को शिप करने का अंतिम निर्णय नहीं है, बल्कि यह डेवलपर्स की सहायता करने का एक टूल है।
설명
Nathanael Weill leads a team building AI agents at Air Canada, where tasks are so specific there's no public benchmark and domain experts have little time to grade results. His fix is to write the answer first: start from a known answer, generate the input from it, and check whether the agent finds its way back. He shows how that took a past RAG project from one expert-graded test a week to dozens of automated tests a day, then applies it to a supplier-contract review agent with five ways to build a test set: past decisions, planted rule violations, removed clauses, changes that shouldn't matter, and contract templates with filled-in blanks. He also explains why he avoids LLM judges whenever code can check the answer. Chapters: - 00:00 Intro - 00:47 No benchmark, no experts - 01:41 A lesson from a telecom RAG project - 04:43 Weekly expert reviews were too slow - 05:38 Flip it: write the answer first - 06:33 From one test a week to dozens a day - 07:30 Supplier contract review - 10:08 How the contract agent works - 10:39 Five ways to build a test set - 12:31 Planting rule violations - 13:39 Removing clauses - 14:42 Changes that shouldn't matter - 15:38 Templates with blanks - 16:39 Avoid LLM judges when code can check - 18:07 Use expert feedback to build better tests Nathanael Weill, Air Canada: https://www.aircanada.com Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!