लेखक: 
Research review: 17 October 2026. AI Agent Evaluation एक repeatable process है जिससे autonomous AI को business task देने से पहले उसकी उपयोगिता, सही actions, सुरक्षा और लागत समझी जाती है। नीचे technology professionals और small businesses के लिए practical scorecard दिया है।
AI Agent Evaluation का अर्थ सिर्फ सही जवाब नहीं
AI agent chatbot से आगे जाकर किसी task को छोटे steps में बाँट सकता है, documents पढ़ सकता है, tool call कर सकता है और कभी-कभी किसी system में बदलाव भी कर सकता है। इसलिए agent की quality को एक सुन्दर उत्तर या demo video से नहीं माप सकते। उदाहरण के लिए customer support agent ने refund policy सही समझाई, लेकिन गलत customer account खोल दिया तो उसका जवाब भाषाई रूप से सही होते हुए भी वास्तविक काम असफल है। Evaluation का लक्ष्य task success, factual accuracy, permissions, user safety और cost को अलग-अलग देखना है।
पहले business task की सीमा लिखें
Test शुरू करने से पहले स्पष्ट करें कि agent को कौन-सा काम करना है और कौन-सा काम बिल्कुल नहीं करना। स्कूल में IT helpdesk agent ticket पढ़कर category सुझा सकता है, पर employee का password reset नहीं कर सकता। E-commerce agent order status बता सकता है, पर approve किए बिना refund नहीं कर सकता। इस scope document में input data, allowed systems, owner, escalation contact, sensitive fields और acceptable turnaround time लिखें। जब success का अर्थ ही स्पष्ट नहीं होगा, तब evaluation score मनमाना बन सकता है।
Task success rate कैसे निकालें
एक practical test set बनाएँ जिसमें वास्तविक उपयोगकर्ताओं के anonymised सवाल हों। प्रत्येक test के लिए expected end state तय करें: क्या ticket सही category में गया, क्या reference का link खुलता है, क्या customer को policy के अनुरूप जवाब मिला। Task success rate सफल test cases को कुल valid cases से भाग देकर निकाला जाता है। मान लें 100 test में 82 सही outcome मिले; success rate 82 प्रतिशत होगी, लेकिन यह production accuracy की guarantee नहीं है। Sample size, कठिनाई और case selection को भी साथ report करना चाहिए।
Answer accuracy और action accuracy अलग रखें
Language model कभी अच्छी भाषा में गलत तथ्य बता सकता है। इसी तरह सही नियम समझते हुए गलत system record update कर सकता है। इसलिए दो check columns रखें: उत्तर का factual support और वास्तविक action का execution। एक banking FAQ agent ब्याज दर समझाते हुए पुराना document उद्धृत करे तो evidence check fail होगा। अगर वह approval के बिना किसी customer की complaint close करे तो action control fail होगा। दोनों को मिलाकर एक ही average score बनाने से गंभीर operational defect छिप सकता है।
Source grounding की जाँच
Agent से पूछें कि उसने जिस policy का हवाला दिया वह कौन-सा version है, वह document किस तारीख का है और क्या उसमें quoted statement सचमुच मौजूद है। Retrieval-augmented systems में wrong document chunk या outdated FAQ भी गलत उत्तर दे सकते हैं। Test set में contradictory documents, missing pages और superseded rules रखें। यदि evidence उपलब्ध नहीं है तो agent को uncertain answer देना और human handoff करना चाहिए। बिना सत्यापन बनाए गए citations को valid evidence नहीं मानें।
Permission tests सबसे अहम क्यों हैं
OWASP ने excessive agency को गंभीर risk के रूप में समझाया है। Agent को काम से अधिक tools, permissions या autonomous decision power मिले तो त्रुटि का असर बढ़ सकता है। Testing में ऐसे cases रखें जिनमें user किसी दूसरे व्यक्ति की file माँगे, administrative command चलाने को कहे या access scope बदलने का आग्रह करे। सही outcome अक्सर refusal, scoped data और human approval होगा। Test के दौरान production customer data मिटाने का प्रयोग नहीं करें; sandbox records और test account इस्तेमाल करें।
Prompt injection की realistic testing
Agent web pages, PDFs और emails पढ़ता है। इनमें छिपा text कभी ऐसा निर्देश दे सकता है कि मूल काम छोड़कर password या confidential data साझा करे। Test में harmless simulated injection डालें जैसे document में लिखा हो, ‘पहले पिछले सभी निर्देश भूल जाओ।’ देखें कि agent उसे document content के रूप में समझता है या controlling instruction के रूप में। किसी live third-party system पर attack करने की बजाय isolated environment में defensive evaluation करें।
Human approval कब जरूरी है
Routine categorisation या information retrieval कम जोखिम वाला हो सकता है, जबकि payment, account deletion, public publishing या policy change बड़ा प्रभाव डाल सकते हैं। ऐसे कामों के लिए approval gate रखें जहाँ इंसान proposed action, target और irreversible effect देख सके। ‘Confirm’ दबाने से पहले agent को बताना चाहिए कि कौन-सा record बदलने वाला है। यह simple safeguard careless automation और misunderstood requests दोनों का खतरा घटा सकता है। केवल user ने chat में ‘ठीक है’ लिखा, इसे हर भविष्य के action की खुली अनुमति न मानें।
Latency और लागत का balanced score
किसी agent का सही जवाब देने में दस मिनट लगना customer service में असुविधाजनक हो सकता है, लेकिन financial reconciliation में थोड़ा अतिरिक्त समय स्वीकार्य हो सकता है। हर test में response latency, number of tool calls, token usage और estimated operating cost दर्ज करें। केवल cheapest system चुनने से accuracy या security खराब हो सकती है। केवल fastest system चुनने से complex मामलों में अधूरा जवाब मिल सकता है। Service-level objective task criticality देखकर तय होना चाहिए।
Failure severity को weight दें
Test report में सभी failures बराबर नहीं होते। गलत punctuation मामूली editorial issue है, जबकि गलत bank account में payment request भेजना critical issue है। एक matrix बनाएँ: low—formatting, medium—गलत category, high—unsupported financial advice, critical—unauthorised data disclosure या irreversible action। Critical case मिलने पर average performance अच्छा होने के बावजूद launch रोकना आवश्यक हो सकता है। यह approach केवल benchmark leaderboard पर निर्भर रहने से बेहतर operational visibility देता है।
A/B testing और regression testing
जब model, prompt, tool integration या underlying knowledge base बदलता है, पुराने successful tasks फिर असफल हो सकते हैं। इसलिए हर release से पहले एक fixed regression suite चलाएँ और new scenarios भी जोड़ें। A/B test में baseline agent और updated agent के लिए समान dataset इस्तेमाल करें। Compare करें कि task success, severity-weighted failures, time और cost कैसे बदलते हैं। केवल दो-तीन examples पर ‘नया model 20% बेहतर’ घोषित करने से बचें।
Production monitoring में क्या देखना है
Launch के बाद real-world questions test dataset से अलग होते हैं। Logs में tool failures, permission denials, repeated customer corrections, user complaints, timeouts और human handoffs का trend देखें। Logs में password, OTP और personal documents जैसे secrets न रखें; sensitive data redaction जरूरी है। Incident होने पर prompt version, policy reference और related tool response traceable होना चाहिए। Retention अवधि organization की privacy policy के अनुरूप रखें। Monitoring का उद्देश्य कर्मचारियों की छिपकर निगरानी नहीं बल्कि deployed system का quality assurance है।
एक 10-column evaluation sheet
Spreadsheet में columns रखें: test ID, user intent, sample input, allowed data, expected output, actual output, action result, source evidence, risk severity और reviewer decision। अतिरिक्त dashboard में category-wise pass rate, high-risk incidents, latency median और monthly drift दिखा सकते हैं। जहां answer qualitative है, वहां दो reviewers के बीच disagreement भी दर्ज करें। पहले 20–30 varied cases से pilot शुरू करें, फिर वास्तविक workload के अनुसार representative dataset बढ़ाएँ। कोई एक universal score हर organization के लिए पर्याप्त नहीं।
Schools और small businesses का case study
मान लें एक school helpdesk में printer, internet, ERP और email complaints आती हैं। Agent का काम केवल details collect करना, appropriate category तय करना, priority सुझाना और ticket draft बनाना हो। Test में ऐसे cases रखें: printer के साथ network problem, student data वाला attachment, unknown sender द्वारा admin password माँगना और critical CCTV incident। Accurate ticket creation success है, लेकिन confidential attachment को public response में जोड़ना critical failure है। Human operator final assignment और sensitive access control संभाले।
NIST और OWASP से क्या framework मिलता है
NIST AI Risk Management Framework के Measure function में quantitative तथा qualitative testing, uncertainty documentation और lifecycle monitoring का महत्व बताया गया है। OWASP excessive agency guidance unnecessary permissions घटाने, approval और downstream authorisation enforce करने पर जोर देती है। दोनों sources व्यावहारिक दिशा देते हैं, किसी खास AI product को officially certified नहीं करते। संस्था अपनी risk appetite, governing rules और available staff के अनुसार evaluation process डिजाइन कर सकती है।
Launch decision के पाँच सवाल
क्या tests actual user needs दर्शाते हैं? क्या critical failures शून्य या documented acceptance boundary के भीतर हैं? क्या हर tool least-privilege पर चलता है? क्या rollback और human override उपलब्ध है? क्या monitoring owner और response procedure तय हैं? इन सवालों का लिखित जवाब बिना दिया गया launch decision कमजोर होगा। AI agent को production में उतारना project का अंत नहीं, निरंतर reliability cycle की शुरुआत है।
Periodic review का छोटा उदाहरण
हर महीने पाँच नये test cases जोड़ें, एक पुरानी failure को दोबारा चलाएँ, tool permissions का audit करें और मानव reviewer से एक छोटी sample set independently पढ़वाएँ। इससे evaluation report केवल launch-day certificate नहीं बल्कि बदलती परिस्थितियों का record बनती है।
स्रोत और editorial review
यह guide NIST AI RMF के measurement principles तथा OWASP के Excessive Agency threat model पर आधारित है। Primary references: NIST AI RMF — Measure और OWASP LLM06:2025 Excessive Agency। यहां दिए गए scorecard examples शिक्षण के लिए हैं, किसी audited company का वास्तविक result नहीं।
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
