AI बेंचमार्क असली काम का 90% क्यों छोड़ देते हैं

मेरी एक दोस्त एक मझोली logistics कंपनी में operations संभालती है। पिछले बसंत में उसकी टीम ने तीन हफ़्ते लगाकर यह जाँचा कि क्या कोई LLM उनका exception-handling workflow संभाल सकता है। यानी वह उबाऊ काम जिसमें तीन ऐसे systems के बीच invoices मिलाने पड़ते हैं जो आपस में बिल्कुल नहीं बनते। वेंडर की deck में प्रभावशाली आँकड़े भरे थे: MMLU, GSM8K, HumanEval, और कुछ agentic benchmarks। मॉडल ने हर तैयार टेस्ट में शानदार प्रदर्शन किया। फिर उन्होंने उसे असली हफ़्ते के exceptions पर चलाया, और उसने पूरे भरोसे के साथ एक $14,000 के invoice को गलत PO से मिला दिया, क्योंकि एक वेंडर ने अपना नाम अलग तरह से छोटा लिखा था। ऐसा कोई leaderboard नहीं मापता।

यह अंतर अब मापा जा सकता है। सार्वजनिक AI benchmarks को अमेरिकी Department of Labor के O*NET taxonomy से मिलाने वाले एक हालिया अध्ययन में, जिसमें अमेरिकी काम को बनाने वाले कुल 923 पेशे और 18,797 कार्य शामिल हैं, पाया गया कि अमेरिकी कार्यघंटों का 90% ऐसे कार्यों में खर्च होता है जिन्हें benchmarks लगभग या बिल्कुल कवर नहीं करते। 923 में से सिर्फ़ 208 पेशों के पास कम से कम एक ऐसा कार्य है जिसे पाँच या अधिक benchmark prompts सपोर्ट करते हैं। 22 job families में से छह में तो एक भी नहीं है। इससे जो असहज निष्कर्ष निकलता है वह यह नहीं कि AI कमज़ोर है। बात यह है कि AI की क्षमता मापने वाले हमारे औज़ार लगभग पूरी तरह अर्थव्यवस्था के गलत हिस्से की ओर तने हुए हैं।

AI Benchmarks असल में क्या कवर करते हैं

इस mapping की methodology समझना उपयोगी है, क्योंकि यह हेडलाइन से कहीं ज़्यादा सावधान है। शोधकर्ताओं ने 29 उच्च-गुणवत्ता वाले, unsaturated, agentic benchmarks लिए। ये ऐसे टेस्ट हैं जिनमें मॉडल को सवालों के जवाब देने के बजाय सच में काम करना पड़ता है। फिर उन्होंने एक LLM judge का उपयोग किया, जिसे मानव विशेषज्ञों से validate किया गया था, ताकि हर benchmark prompt को उन O*NET कार्यों से टैग किया जा सके जिन्हें वह परखता है। किसी कार्य को “कवर्ड” तभी माना गया जब उससे कम से कम पाँच prompts जुड़ते थे। इसे हर कार्य में लगने वाले समय के अनुमानों से मिलाने पर पूरी अर्थव्यवस्था की एक तस्वीर बनती है कि हमारा evaluation suite वास्तव में क्या देख सकता है।

वह जो देख सकता है वह चौड़ा नहीं, बल्कि संकरा और ऊँचा है। Software engineering और financial analysis benchmarks से भरे पड़े हैं। ट्रक ड्राइविंग, गैस प्लांट का संचालन, food service, और स्वास्थ्य सेवा का ज़्यादातर रोज़ाना का काम लगभग अदृश्य है। और यह असंतुलन सिर्फ़ इस बात का नहीं कि कौन से कार्य तकनीकी रूप से स्वचालित हो सकते हैं। “AI-exposed” टैग वाले कार्यों के benchmark होने की संभावना अनएक्सपोज़्ड कार्यों से लगभग छह गुना है, जो समझ में आता है। लेकिन इस असर को नियंत्रित करने के बाद भी, जिन पेशों की कुल वेतन राशि बड़ी है, उनके कार्य काफ़ी ज़्यादा प्रतिनिधित्व पाते हैं। वकीलों के कार्य भारी मात्रा में कवर हैं। कानूनी सचिव और अदालत के क्लर्क, जिन पर AI का लगभग वैसा ही असर पड़ने वाला है, लगभग दिखते ही नहीं।

इसे फिर से पढ़िए: हम AI को किसी नौकरी के प्रतिष्ठित संस्करण के मुकाबले में परख रहे हैं, और उस संस्करण को नज़रअंदाज़ कर रहे हैं जिसे ज़्यादातर लोग वास्तव में करते हैं। मध्यम आय वाले knowledge work की लंबी दुम, यानी coordinators, clerks, specialists और schedulers, जिनके घंटे मिलकर अर्थव्यवस्था का बड़ा हिस्सा बनते हैं, के पास लगभग कोई measurement infrastructure नहीं है। जब कोई दावा करता है कि AI "knowledge work" के कुछ प्रतिशत को कर सकता है, तो पूछिए कि कौन-सा knowledge work, किस तरह मापा गया, और किस task list के मुकाबले। ईमानदार जवाब आमतौर पर यही होता है: एक पतला, असंतुलित टुकड़ा, जिसे शोध-पत्रों के लिए बने टेस्टों से मापा गया है।

Benchmark Saturation एक evaluation design की विफलता है

मैंने कई साल evaluation pipelines बनाने में बिताए हैं, और सबसे कठिन सबक यह था: benchmark दुनिया का एक मॉडल होता है, और ज़्यादातर benchmarks बहुत खराब मॉडल हैं। वे एक उलझे हुए, संदर्भ-आधारित, बहु-चरणीय मानवीय काम को एक साफ़ prompt में समेट देते हैं जिसका जवाब जाँचा जा सके, क्योंकि उसे ग्रेड करना सस्ता पड़ता है। फिर Goodhart's law अपना काम करता है। जिस पल benchmark मॉडल विकास का लक्ष्य बन जाता है, वह उस क्षमता को मापना बंद कर देता है जिसका वह प्रॉक्सी होने के लिए बना था। Training data टेस्ट के वितरण को सोख लेता है, टीमें leaderboard के हिसाब से ट्यून करती हैं, और स्कोर चढ़ते जाते हैं जबकि असली दुनिया में प्रदर्शन इधर-उधर डोलता रहता है।

Saturation उसका दिखने वाला लक्षण है। जब हर frontier model किसी टेस्ट पर 90% से ऊपर स्कोर करने लगे, तो टेस्ट भेद करना बंद कर देता है। पर गहरी समस्या यह है कि हम इसका जवाब उसी शैली का एक और benchmark बनाकर देते हैं, उन्हीं तरह के कार्यों पर, क्योंकि उन्हें स्वचालित रूप से ग्रेड करना हम जानते हैं। Multiple-choice QA से और कठिन multiple-choice QA पैदा होता है। Coding challenges से और कठिन coding challenges। इस बीच कोई यह benchmark नहीं बनाता कि “देखिए कि इस contract की indemnification clause चुपचाप March के term sheet से उलट है”, क्योंकि ऐसे को ग्रेड करने के लिए वकील, समय और ऐसे निर्णय चाहिए जो स्वचालन का विरोध करते हैं।

इसलिए मैं इस विचार से असहमत हूँ कि benchmark saturation का मतलब है AI ने किसी domain को “हल” कर लिया है। Saturation का मतलब है कि औज़ार अपनी सीमा पर पहुँच गया है, बस। जो थर्मामीटर 40°C पर अटक जाए, वह यह साबित नहीं करता कि कमरा 40 डिग्री का है; वह बस यह साबित करता है कि आपको एक अलग थर्मामीटर चाहिए। अगर आप production के लिए models का मूल्यांकन कर रहे हैं, और खासकर अगर आप LLM-based decision systems बना रहे हैं जहाँ गलतियों की असली कीमत है, तो saturated benchmarks पर leaderboard के अंतर का आपके फ़ैसले में लगभग कोई वज़न नहीं होना चाहिए।

हम ठीक-ठीक जानते हैं कि models उस काम में कितने अच्छे हैं जिसे हमने मापने का फ़ैसला किया है। बाकी नब्बे प्रतिशत के बारे में हम लगभग कुछ नहीं जानते।

AI Evaluation में स्ट्रीटलाइट प्रभाव

एक पुराना चुटकुला है कि एक शराबी अपनी चाबी स्ट्रीटलाइट के नीचे ढूँढ रहा है, इसलिए नहीं कि उसने चाबी वहाँ खोई, बल्कि इसलिए कि रोशनी वहीं है। Benchmark निर्माण भी इसी तर्क पर चलता है, और डेटा बताता है कि यह संयोग नहीं है। Mapping अध्ययन में पाया गया कि किसी पेशे के भीतर कार्य का महत्व कवरेज की भविष्यवाणी करता है: जो O*NET कार्य अपने पेशे के लिए सबसे महत्वपूर्ण माने गए, उनके benchmark होने की संभावना सबसे कम महत्वपूर्ण कार्यों की तुलना में छह से दस गुना है। सतह पर यह समझदारी भरी प्राथमिकता लगती है। व्यवहार में इसका अर्थ है कि हम दिखावटी कार्यों को मापते हैं और जोड़ने वाले ढाँचे को छोड़ देते हैं।

हर नौकरी मुख्यतः उसी जोड़ने वाले ढाँचे से बनी होती है। एक software engineer का benchmark वाला कार्य है “एक फ़ंक्शन लिखो जो ये tests पास करे।” उसके असली दिन में शामिल है किसी साथी का अधूरा migration पढ़ना, यह समझना कि कौन-सा stakeholder असल में किसी फ़ैसले का मालिक है, और यह पहचानना कि ticket गलत समस्या का वर्णन करता है। मैं पहले भी लिख चुका हूँ कि agentic coding tools ठीक इसी बात पर सफल या असफल होते हैं: loop, context और permission boundaries कच्ची generation quality से कहीं ज़्यादा मायने रखते हैं। इनमें से कुछ भी HumanEval-शैली के स्कोर में नहीं दिखता।

कवरेज के आँकड़ों में खुद एक सूक्ष्म परिभाषा की समस्या है। “कवर्ड” का मतलब है कि किसी कार्य से पाँच या अधिक prompts जुड़ते हैं, इसका मतलब यह नहीं कि पाँच prompts उस कार्य को पकड़ लेते हैं। माता-पिता को बच्चों की परवरिश की समस्याओं पर परामर्श देने से जुड़े तेरह prompts उस काम का प्रतिनिधित्व नहीं करते जो एक social worker अपने caseload, अदालत और घर पर होने वाली मुलाकातों में करता है। अगर “अच्छी तरह कवर्ड” की आम आदमी वाली परिभाषा लगाई जाए, तो मापा गया आर्थिक हिस्सा 10% नहीं होगा। वह लगभग शून्य के बराबर होगा। स्ट्रीटलाइट सिर्फ़ संकरी नहीं है; उसकी रोशनी भी पतली है।

Models जनरेट करते हैं, पर कोई judgment को benchmark नहीं करता

यह असमानता मुझे सबसे ज़्यादा परेशान करने वाली लगती है। मौजूद लगभग हर benchmark production को परखता है: कोड लिखो, मेमो का ड्राफ़्ट बनाओ, समस्या हल करो। पर ज़्यादातर असली कार्यों का आर्थिक रूप से निर्णायक आधा हिस्सा detection होता है, यानी गलती पकड़ना, असंगति को चिह्नित करना, और यह जानना कि आत्मविश्वास भरा जवाब गलत है। एक junior accountant की कीमत reconciliation बनाने में नहीं, बल्कि यह पहचानने में होती है कि कोई संख्या गड़बड़ लग रही है। Benchmarks इसे शायद ही कभी परखते हैं, क्योंकि ग्रेड किया जा सकने वाला error-detection टास्क बनाना, ग्रेड किए जा सकने वाले generation टास्क से कहीं कठिन है। आपको यथार्थवादी त्रुटिपूर्ण artifacts चाहिए, विश्वसनीय-पर-गलत सूक्ष्मता चाहिए, और इस पर मानव सहमति चाहिए कि “पकड़ा गया” किसे माना जाए।

यह doorman fallacy का evaluation design पर लागू रूप है। किसी doorman को automatic door से बदल दीजिए, और आप देर से जानेंगे कि doorman किरायेदारों का स्वागत करने, पैकेज लेने और सड़क पर नज़र रखने का काम भी करता था। किसी नौकरी के benchmark वाले हिस्से को स्वचालित कीजिए, और पता चलेगा कि बिना benchmark वाले हिस्से ही इमारत को थामे हुए थे। मेरी logistics दोस्त का मॉडल शानदार reconciliation notes ड्राफ़्ट कर सकता था, जो दिखने वाला काम था, पर चुपचाप मिलान में गड़बड़ करता था, वही judgment जिसके कारण वे notes लिखने लायक बनते थे। Eval suite ने गार्निश को अंक दिए और खाने को नज़रअंदाज़ कर दिया।

जब तक error detection को पहली श्रेणी का benchmark दर्जा नहीं मिलता, demo प्रदर्शन और deployment प्रदर्शन के बीच एक स्थायी अंतर बना रहेगा। यह वही अंतर है जो specification क्या कहती है और implementation क्या करती है के बीच रहता है, और software की तरह यहाँ भी असफलता उसी अंतर में पनपती है। वह मॉडल जो 90th percentile पर जनरेट करता है और 30th percentile पर verify करता है, production में बस टाइपिंग की रफ़्तार वाला 30th percentile कर्मचारी है।

Evals को असली कार्य-वितरण के हिसाब से भारित करना

benchmark-mapping काम का सबसे व्यावहारिक विचार सबसे सरल भी है: अगर benchmarks कुछ कार्यों को ज़रूरत से ज़्यादा दिखाते हैं, तो prompts पर औसत निकालना बंद करें और कार्यों पर औसत निकालें, जिसका भार हर कार्य में लगने वाले असली समय के हिसाब से हो। “financial analyst” टैग वाले हर prompt का सपाट औसत उस कार्य से दबा रहता है जिसके सबसे ज़्यादा benchmark prompts हैं, आमतौर पर वही जिसके लिए dataset बनाना सबसे आसान था। O*NET-भारित औसत हर असली कार्य को बराबर महत्व देता है। फ़र्क नाटकीय हो सकता है।

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

उस snippet में दो बातें ध्यान देने लायक हैं। पहली, भारित स्कोर इसलिए गिरता है क्योंकि मॉडल के सबसे कमज़ोर कार्य prompt pool में कम प्रतिनिधित्व पाते थे, ठीक वही विकृति जो सपाट औसत छिपा देता है। दूसरी, और ज़्यादा महत्वपूर्ण: “advise client” पूरी गणना से गायब हो जाता है क्योंकि उससे कोई prompt नहीं जुड़ता। कोई भी भारांकन योजना चुपचाप शून्य-कवरेज वाले कार्यों को छोड़ देती है, और अर्थव्यवस्था के ज़्यादातर हिस्से में शून्य कवरेज ही आम है। भारांकन भारांकन की समस्या ठीक कर सकता है। वह missing-data की समस्या नहीं सुलझा सकता। इसके लिए नए evals बनाने होंगे, पुरानों का दोबारा औसत निकालने से काम नहीं चलेगा।

AI को अपने असली काम के सामने कैसे परखें

अगर आप models चुन या deploy कर रहे हैं, तो अर्थव्यवस्था-व्यापी कवरेज अंतर का ठोस अर्थ यह है कि सार्वजनिक benchmarks आपके उपयोग के मामले के लिए कमज़ोर पूर्व-अनुमान हैं, जब तक आप उस छोटे, चमकीले कोने में न हों जिसे वे मापते हैं। इसलिए अपना कोना खुद बनाइए। यह सुनने में जितना वीरतापूर्ण लगता है उतना कठिन नहीं है, और यह किसी vendor deck पर भरोसा करने से कहीं बेहतर है।

• कल्पना से नहीं, logs से कार्य चुनें। एक हफ़्ते के असली tickets, emails या exceptions निकालें और आवृत्ति के हिसाब से नमूने लें। आपका eval set आपके workload के histogram जैसा दिखना चाहिए, जिसमें उबाऊ दुम भी शामिल हो। वह उबाऊ दुम ही तो ज़्यादातर काम है।
• समय या लागत से भारित करें, फिर दोनों संख्याएँ रिपोर्ट करें। सपाट औसत और भारित औसत सच्चाई की सीमाएँ तय करते हैं। अगर कोई मॉडल सपाट औसत में जीतता है पर भारित औसत में हारता है, तो वह उन्हीं कार्यों में अच्छा है जिनकी जाँच आसान है, और ठीक यही वह विफलता है जिसे आप छानना चाहते हैं।
• verification कार्य शामिल करें। असली आउटपुट लें, जिनमें ज्ञात-गलत आउटपुट भी हों, और मॉडल को उन गलतियों को पकड़ने पर परखें जो जानबूझकर डाली गई हैं या स्वाभाविक रूप से मौजूद हैं। मेरे अनुभव में detection और generation कौशल का आपस में संबंध बहुत कम होता है, और जो आप असल में खरीद रहे हैं वह detection है।
• एक निजी सेट रखें और उसे ताज़ा करते रहें। जो eval आप महीनों तक दोबारा इस्तेमाल करते हैं, वह किसी training target में बदल जाता है, भले ही अनजाने में, जैसे ही कोई उस पर prompts ट्यून करने लगे। हर तिमाही मामले बदलते रहें।
• जहाँ संभव हो, end-to-end परिणामों पर स्कोर करें। अगर कार्य है “यह invoice मिलाओ”, तो मध्यवर्ती गद्य नहीं, reconciliation को ग्रेड करें। मध्यवर्ती metrics मॉडलों को उसी तरह बढ़ा-चढ़ाकर दिखाते हैं जैसे unit tests उस कोड को बढ़ा-चढ़ाकर दिखाते हैं जिसमें integration coverage नहीं है।

एक अंतिम, शांत प्रभाव का ज़िक्र करना ज़रूरी है, जिसे रोज़ AI coding tools इस्तेमाल करने वाला हर व्यक्ति पहचानेगा: micro-scale Baumol cost disease। जब generation बीस गुना तेज़ हो जाता है, तो आपका दिन generation में नहीं जाता। वह उन हिस्सों में जाता है जो तेज़ नहीं हुए, यानी review, coordination, verification और decision। बिना benchmark वाला शेष हिस्सा AI सुधरने पर सिकुड़ता नहीं; वह खाली हुए समय को भरने के लिए बढ़ जाता है, और यह तय करने में बड़ा हिस्सा बन जाता है कि AI की तैनाती उपयोगी थी या नहीं। स्वचालन योग्य हिस्से को बढ़ती सटीकता से मापना और बाकी को नज़रअंदाज़ करना सिर्फ़ अधूरा नहीं है। यह उल्टा कर देता है कि मायने क्या रखता है।

यह तर्क नहीं कि AI की प्रगति नकली है। क्षमता के लाभ असली हैं, और मैंने अपने प्रोजेक्ट उन पर दाँव पर लगाए हैं। यह तर्क है कि हमारी measurement संस्कृति गलत वितरण की ओर इशारा कर रही है। Benchmarks वहीं बने जहाँ prompts लिखना और ग्रेड करना सस्ता था: code, math, परीक्षा-शैली का ज्ञान। अर्थव्यवस्था ज़्यादातर वैसी नहीं है। जब तक evaluation इसे नहीं पकड़ता, हर बड़े क्षमता-दावे को नक्शे के चमकीले दसवें हिस्से के बारे में बयान समझिए, और अपने खुद के अंधेरे नब्बे प्रतिशत को कवर करने वाले evals बनाइए। जो संगठन यह उबाऊ, गैर-चमकदार measurement काम करेंगे, वे लीडरबोर्ड ताज़ा करने वाले बाकी सबसे बेहतर deployment फ़ैसले लेंगे, और इसमें कोई मुकाबला नहीं होगा।