LLM टेस्टिंग क्या है?
LLM टेस्टिंग यह प्रमाण जुटाना है कि large language model पर बना सिस्टम वही करता है जो उसे करना चाहिए, prompt, मॉडल या डेटा बदलने पर भी करता रहता है, और दुरुपयोग पर सुरक्षित रूप से फ़ेल होता है। क्योंकि output हर रन में बदलते हैं, यह schema के विरुद्ध validate होने वाले structured output, property checks, pass-rate threshold वाले बार-बार रन और rubric-आधारित रिव्यू पर निर्भर है, जिसे हर prompt या मॉडल बदलाव पर regression evaluation के रूप में दोबारा चलाया जाता है।
गाइड पढ़ें: LLM टेस्टिंग: LLM एप्लिकेशन कैसे टेस्ट करें
एजेंट टूल-कॉल इवैल्युएटर कैसे इस्तेमाल करें
- टेस्ट केस जिन कॉल की अपेक्षा करता है उन्हें JSON array में लिखें: [{ "name": "search_flights", "args": { "from": "RUH" } }]। वैकल्पिक कॉल पर "optional": true लगाएँ।
- एजेंट का trace पेस्ट करें: API response, message list, या आपके फ़्रेमवर्क से एक्सपोर्ट की गई कॉल की सूची।
- क्रम का नियम और आर्ग्युमेंट की तुलना चुनें, और वे टूल लिखें जिन्हें एजेंट को कभी कॉल नहीं करना चाहिए।
- इवैल्युएट करें दबाएँ और फ़ैसला, स्कोर और अपेक्षित कॉल की तालिका पढ़ें।
- आर्ग्युमेंट में अंतर और अनपेक्षित कॉल खोलकर देखें कि एजेंट ने क्या ग़लत किया, फिर उस केस को अपने evaluation set में जोड़ें।
एजेंट टूल-कॉल इवैल्युएटर की खूबियाँ
- OpenAI Chat Completions (tool_calls), OpenAI Responses (function_call), Messages API के tool_use blocks, Gemini (functionCall) या कॉल की सादी सूची से trace पढ़ता है
- अपेक्षित कॉल को strict, क्रम में (बीच में दूसरी कॉल आ सकती हैं) या किसी भी क्रम में मिलाता है
- आर्ग्युमेंट की तुलना subset, exact, सिर्फ़ keys या बिल्कुल नहीं — पूरे टेस्ट के लिए या हर अपेक्षित कॉल के लिए — numeric tolerance और वैकल्पिक case-insensitive मिलान के साथ
- टूल चयन की precision और recall, F1 और आर्ग्युमेंट की सटीकता रिपोर्ट करता है
- छूटी, अतिरिक्त, वर्जित और एक जैसी दोहराई गई कॉल पर निशान लगाता है, और कॉल की अधिकतम संख्या भी जाँचता है
- कारणों के साथ pass/fail फ़ैसला, हर path का आर्ग्युमेंट diff और डाउनलोड होने वाली JSON रिपोर्ट देता है
एजेंट टूल-कॉल इवैल्युएटर का उदाहरण
दो यात्रियों के लिए दो बार बुकिंग करने वाला booking एजेंट
इनपुट:
अपेक्षित: search_flights (RUH → DXB, 2026-11-05), वैकल्पिक get_fare_rules, book_flight (passengers: 1), send_confirmation (सिर्फ़ keys) · Trace: OpenAI tool_calls, जिसमें search_flights और दो बार book_flight (passengers: 2)आउटपुट:
फ़ैसला: FAIL — एक ज़रूरी टूल कॉल नहीं हुआ (send_confirmation), एक टूल ग़लत आर्ग्युमेंट के साथ कॉल हुआ ($.passengers अपेक्षित 1, वास्तविक 2), एजेंट ने ऐसी कॉल कीं जिनकी टेस्ट को अपेक्षा नहीं थी (दूसरी book_flight) · एक जैसी दोहराई गई कॉल: book_flight × 2 · Precision 67% · Recall 67% · आर्ग्युमेंट की सटीकता 50%एजेंट टूल-कॉल इवैल्युएटर कब इस्तेमाल करें
- Prompt, मॉडल या tool schema बदलने के बाद एजेंट की regression टेस्टिंग
- यह जाँचना कि एजेंट अपेक्षित confirmation वाले कदम के बिना कभी कोई destructive टूल (refund, deletion) कॉल नहीं करता
- ग़लत action वाले production trace को दोहराए जा सकने वाले टेस्ट केस में बदलना
- एक ही टास्क पर दो मॉडलों की तुलना उनके अपनाए रास्ते से करना, सिर्फ़ जवाब से नहीं
एजेंट टूल-कॉल इवैल्युएटर के बारे में अक्सर पूछे जाने वाले सवाल
सिर्फ़ आख़िरी जवाब के बजाय टूल कॉल को क्यों evaluate करें?
एजेंट ग़लत रास्ते से भी सही लगने वाले जवाब तक पहुँच सकता है — ग़लत API कॉल करना, दो बार बुक करना, कोई जाँच छोड़ देना या ऐसा action लेना जो उसे कभी नहीं लेना चाहिए। ये defects सिर्फ़ trace में दिखते हैं, इसलिए एजेंट के टेस्ट को जवाब के साथ-साथ कॉल को भी assert करना चाहिए।
कौन-से trace फ़ॉर्मेट सपोर्ट होते हैं?
OpenAI Chat Completions के tool_calls (आर्ग्युमेंट JSON string के रूप में), OpenAI Responses के function_call आइटम, Messages API के tool_use blocks, Gemini के functionCall parts, और name व arguments वाले objects की कोई भी सादी सूची। Message lists और पूरे API responses में कॉल क्रम से खोजी जाती हैं।
आर्ग्युमेंट की तुलना कैसे होती है?
डिफ़ॉल्ट रूप से अपेक्षित keys बराबर values के साथ मौजूद होनी चाहिए और अतिरिक्त keys चलती हैं (subset)। आप पूरी बराबरी माँग सकते हैं, सिर्फ़ यह जाँच सकते हैं कि keys मौजूद हैं, या आर्ग्युमेंट अनदेखा कर सकते हैं — पूरे टेस्ट के लिए या हर कॉल के लिए — numeric tolerance और वैकल्पिक case-insensitive strings के साथ।
यहाँ precision और recall का क्या मतलब है?
Precision एजेंट की उन कॉल का हिस्सा है जो किसी अपेक्षित कॉल से मेल खाईं; recall ज़रूरी अपेक्षित कॉल में से उन कॉल का हिस्सा है जो एजेंट ने कीं। आर्ग्युमेंट की सटीकता मेल खाई कॉल में से उन कॉल का हिस्सा है जिनके आर्ग्युमेंट सही थे।
क्या यह टूल किसी AI मॉडल को कॉल करता है?
नहीं। यह deterministic तुलना है जो आपके ब्राउज़र में चलती है। आप जो पेस्ट करते हैं वह न Mutqan को भेजा जाता है, न किसी मॉडल प्रोवाइडर को।
तकनीकी नोट्स
"क्रम में" मोड में हर अपेक्षित कॉल को उसी नाम वाली अगली पहली कॉल से मिलाया जाता है, और जिसके आर्ग्युमेंट मेल खाते हों उसे प्राथमिकता मिलती है; "किसी भी क्रम में" मोड में पूरा trace खोजा जाता है; "strict" मोड में स्थान n पर अपेक्षित कॉल n ही होनी चाहिए। OpenAI के आर्ग्युमेंट JSON string के रूप में आते हैं और तुलना से पहले decode किए जाते हैं।
Precision = मेल खाई कॉल ÷ की गई कॉल, recall = की गई ज़रूरी अपेक्षित कॉल ÷ ज़रूरी अपेक्षित कॉल, और आर्ग्युमेंट की सटीकता = सही आर्ग्युमेंट वाली कॉल ÷ मेल खाई कॉल। वैकल्पिक अपेक्षित कॉल मौजूद होने पर गिनी जाती हैं और कभी छूटी हुई नहीं मानी जातीं।
सीमाएँ और कार्यप्रणाली
इवैल्युएटर कॉल की तुलना करता है; यह नहीं आँकता कि आख़िरी जवाब सही है या अच्छी तरह लिखा गया है — इसके साथ जवाब की जाँच भी जोड़ें।
यह आपके पेस्ट किए trace की कॉल पढ़ता है। जो कॉल आपके फ़्रेमवर्क ने रिकॉर्ड नहीं कीं, या जो sub-agents ने किसी दूसरे trace में कीं, वे नहीं दिखतीं।
आर्ग्युमेंट values की तुलना शब्दशः होती है (tolerance और case विकल्पों के साथ); अर्थ में बराबर पर अलग तरह से लिखी values, जैसे दो date फ़ॉर्मेट, अलग मानी जाती हैं।
संदर्भ
- AI Risk Management Framework (AI RMF 1.0)पूरे जीवनचक्र में AI जोखिम प्रबंधन के लिए NIST का स्वैच्छिक फ़्रेमवर्क, Govern, Map, Measure और Manage फ़ंक्शन में व्यवस्थित।
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)AI RMF का generative-AI प्रोफ़ाइल: generative मॉडल के विशेष जोखिम, जैसे confabulation और सूचना की अखंडता, और उन्हें संभालने के सुझाए क़दम।
- ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsAI-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।