Evaluations | The .NET Blog

Model router evals वह कदम है जिसे बहुत सारी टीमें छोड़ देती हैं

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें।

Automatic model routing बहुत अच्छा लगता है, लेकिन तभी तक, जब तक आपको यह साबित करना न पड़े कि यह आपकी workload के लिए सही विकल्प है।

इसीलिए नया model router evaluation repo उपयोगी है।

यह teams को उन सवालों के जवाब देने का अधिक ठोस तरीका देता है जो वास्तव में मायने रखते हैं:

क्या routing quality को बरकरार रखता है?
क्या यह cost को बेहतर बनाता है?
latency पर इसका क्या असर पड़ता है?
अगर मैं model subset को सीमित कर दूँ तो क्या बदलता है?

source article सही सवाल पूछता है

मुझे original post की एक बात बहुत पसंद आई: वह model router को अपने-आप अच्छा मानकर नहीं चलता।

इसके बजाय, वह असहज लेकिन सही सवाल पूछता है:

“मेरे prompts पर, model router द्वारा auto-selected model, उस single model के बराबर या उससे बेहतर है जिसे मैं otherwise चुनता?”
“क्या मैं वाकई end to end पैसे बचा रहा हूँ, या सिर्फ़ खर्च को एक जगह से दूसरी जगह शिफ्ट कर रहा हूँ?”

यही बिल्कुल सही रवैया है।

क्योंकि automatic routing आकर्षक है, लेकिन वह अभी भी एक system decision है। और system decisions को measured होना चाहिए, admired नहीं।

यह repo पहली नज़र से ज़्यादा क्यों महत्वपूर्ण है

एक स्तर पर, यह सिर्फ़ एक evaluation repo है।

दूसरे स्तर पर, यह maturity का संकेत है।

यह कहता है: अगर आप automatic routing अपनाना चाहते हैं, तो यहाँ test करने का एक अधिक disciplined तरीका है:

quality
cost
latency
subset trade-offs
model distribution behavior

यह routing को एक अच्छी branding वाली black box की तरह मानने से बहुत बेहतर है।

मेरी राय

यह उन tools का अच्छा उदाहरण है जिनकी AI platforms को और ज़्यादा ज़रूरत है: और ज़्यादा magic नहीं, बल्कि magic पर trust करने से पहले उसे validate करने के और तरीके।

यही तरीका teams को untested assumptions पर expensive confidence बनाने से बचाता है।

मूल लेख: How to run evals for the model router

AI विकास की सबसे मुश्किल बात अब पहुँच नहीं रही। सही मॉडल को अच्छे से चलाना है

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें.

हम उस चरण से आगे निकल चुके हैं जहाँ केवल एक शक्तिशाली model तक पहुँच होना पर्याप्त था।

यही बात इस नई Foundry guide to managing models, cost and quality में सही पकड़ी गई है।

असल चुनौती अब operational है:

हर workload के लिए सही model चुनना
उसे अपने data के खिलाफ validate करना
latency और spend को manage करना
upgrades और regression risk को govern करना

यही वह चीज़ है जिसमें गंभीर teams को अच्छा होना है।

स्रोत लेख समस्या को सही तरह परिभाषित करता है

मूल लेख की एक पंक्ति यह बदलाव बहुत अच्छी तरह पकड़ती है:

“आज AI systems बनाने का सबसे कठिन हिस्सा अब सक्षम model तक पहुँच नहीं है। यह जानना है कि एक वास्तविक application के पूरे lifecycle में सही model को कैसे चुनना, validate करना, optimize करना और operate करना है।”

यह बिल्कुल सही diagnosis है।

बहुत-सी टीमों को अब भी लगता है कि model selection ही मुख्य निर्णय है।

ऐसा नहीं है।

Model operation बड़ी समस्या है:

किस workload को कौन सा model मिलता है?
quality कैसे verify होती है?
स्वीकार्य cost shape क्या है?
जब नया model आता है या पुराना drift करता है तो क्या होता है?
real workflows तोड़े बिना change कैसे test करें?

अब यही असली engineering work है।

यह Foundry piece क्यों उपयोगी है

मुझे यह लेख इसलिए पसंद है क्योंकि यह AI systems के बारे में उसी तरह बात करता है जैसे अनुभवी platform engineers को सोचना पड़ता है।

ना कि “सबसे smart model चुनो और आगे बढ़ो”।

बल्कि ऐसे systems के रूप में जो trade-offs के नीचे रहते हैं:

capability
latency
cost
safety
governance
upgrade pressure

यह benchmark-driven optimism से कहीं अधिक उपयोगी है।

सबसे महत्वपूर्ण बदलाव criteria-first सोच है

मूल लेख model catalog खोलने से पहले success criteria define करने की सलाह देता है।

मुझे लगता है यह उन सबसे महत्वपूर्ण आदतों में से एक है जो teams अपना सकती हैं।

अगर आप पहले catalog खोलते हैं, तो आप reputation पर टिक जाते हैं।

अगर आप पहले criteria define करते हैं, तो आप workload reality पर टिकते हैं।

यह एक healthier process है।

क्योंकि जो model benchmark जीतता है, वही ज़रूरी नहीं कि जीतता हो:

आपके prompts पर
आपके latency budget पर
आपके cost guardrails के भीतर
आपकी governance requirements में

यही distinction mature AI engineering की शुरुआत है।

Multi-model कहानी एक वास्तविक advantage बन रही है

एक और चीज़ जो मुझे पसंद है, वह है model-agnostic framing।

लेख Foundry को single-model destination की तरह नहीं, बल्कि एक operating surface की तरह प्रस्तुत करता है:

Microsoft models
partner models
open-source models
post-trained variants
routing और optimization strategies

यह इसलिए मायने रखता है क्योंकि model flexibility अब luxury नहीं है। यह risk management का हिस्सा है।

यदि quality बदलती है, prices हिलते हैं, या quota सीमित हो जाती है, तो teams को options चाहिए।

Cost control secondary concern नहीं है

लेख यह भी सही कहता है कि cost एक architectural concern है।

यह “बाद में optimize करेंगे” वाली समस्या नहीं है।

अगर आप हर task को default रूप से सबसे heavy model पर भेजते हैं, तो यह demo में शानदार काम कर सकता है और production economics में ढह सकता है।

इसलिए मुझे लगता है कि sections on:

routing
batching
caching
provisioned throughput
quota management

कई लोगों की अपेक्षा से अधिक महत्वपूर्ण हैं।

जो teams cost discipline को system design का हिस्सा मानती हैं, वे उन teams से कहीं बेहतर उम्र पाएँगी जो इसे बाद की सफाई का काम मानती हैं।

मेरी राय

यह एक उपयोगी Foundry piece है क्योंकि यह AI systems के बारे में उसी तरह बात करता है जैसे अनुभवी engineers को वास्तव में उन्हें run करना पड़ता है।

ना कि demos की तरह। ना कि one-off prototypes की तरह। और ना ही leaderboard tourism की तरह।

बल्कि workloads, constraints, trade-offs, और निरंतर बदलाव के operating systems की तरह।

हमें बातचीत को इसी स्तर की ओर ले जाते रहना होगा।

और अगर आप production AI systems बना रहे हैं, तो यही mindset है जिसे teams को जल्दी internalize करना चाहिए।

मूल लेख: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

Foundry की observability-to-ROI कहानी वही है जिसकी गंभीर agent platforms को ज़रूरत है

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें.

अगर AI agents को production में रहना है, तो observability सिर्फ logs और traces पर खत्म नहीं हो सकती।

इसीलिए Foundry की नई observability-to-ROI कहानी महत्वपूर्ण लगती है।

असल संदेश “हमने और dashboards जोड़ दिए” नहीं है।

असल संदेश यह है कि गंभीर agent platforms को एक निरंतर operating loop चाहिए:

क्या हुआ, उसे trace करो
देखें कि वह अच्छा था या नहीं
जिस हिस्से में काम चाहिए, उसे optimize करो
नतीजे को business value से जोड़ो

यह सामान्य platform hand-waving से कहीं मजबूत कहानी है।

स्रोत article की key sentence सब कुछ कह देती है

मूल post की शुरुआत एक पंक्ति से होती है जिस पर मुझे लगता है कि agent बनाने वाली हर टीम को ध्यान देना चाहिए:

“AI agent deploy करना आसान हिस्सा है. उसे production में accurate, safe, और accountable बनाए रखना वह जगह है जहाँ teams अटकती हैं.”

यह बिल्कुल सही है।

हम उस चरण से आगे बढ़ चुके हैं जहाँ मुख्य सवाल था, “क्या मैं agent से कोई cool काम करवा सकता हूँ?”

अब कठिन और अधिक मूल्यवान सवाल यह है:

जब वह real users, real tools, और real costs के साथ interact करना शुरू करे, तब क्या मैं उसे operate कर सकता हूँ?

यही वह दिशा है जिसमें Foundry conversation को आगे बढ़ाना चाहती है।

यह किसी और agent demo से ज्यादा महत्वपूर्ण क्यों है

बहुत-सी AI agent announcements अभी भी creation पर केंद्रित रहती हैं: agent बनाओ, tools जोड़ो, tasks route करो, interface ship करो।

यह सब ठीक है।

लेकिन operational सवाल वही जगह हैं जहाँ ज्यादातर serious systems या तो sustainable बनती हैं या expensive experiments:

production में agent वास्तव में क्या कर रहा है?
क्या उसने सही काम किया?
क्या वह समय के साथ खराब हो रहा है?
क्या वह उससे बनाए गए value के मुकाबले बहुत महँगा है?
कौन से configuration changes ने quality सच में बेहतर की?

इसीलिए मुझे लगता है कि Foundry announcement एक typical feature roundup से ज्यादा महत्वपूर्ण है. यह सिर्फ agent creation story नहीं, बल्कि एक Agent DevOps loop define करने की कोशिश कर रही है.

चार-part loop यहाँ असली product है

Article platform को essentially चार capabilities के इर्द-गिर्द organize करता है:

Trace
Evaluate
Monitor
Optimize

यही सही shape है.

मैं तो यह भी कहूँगा कि जो भी platform agent production workloads में seriously लिया जाना चाहता है, उसे अंततः इन चारों की जरूरत होगी.

सिर्फ tracing काफी नहीं है.

सिर्फ evaluation काफी नहीं है.

Evidence के बिना optimization सिर्फ अंदाज़ा है.

और telemetry के बिना ROI की बात अक्सर theater होती है.

Interoperability वाला angle खास तौर पर smart है

Announcement के सबसे मजबूत decisions में से एक यह है कि Foundry यह मानकर नहीं चलती कि हर agent एक ही framework में बनेगा.

Source post साफ़ तौर पर बताता है कि tracing और evals इन तक extend होते हैं:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
OpenTelemetry के जरिए custom frameworks

यह महत्वपूर्ण है.

क्योंकि platform lock-in किसी भी उपयोगी operations story को कम attractive बनाने के सबसे तेज़ तरीकों में से एक है.

अगर teams अपने framework choices बनाए रख सकें और फिर भी production-grade telemetry और evaluation surfaces हासिल कर सकें, तो friction काफी कम हो जाता है.

Rubric evaluation शायद उम्मीद से ज्यादा महत्वपूर्ण हो जाए

Rubric evaluator वाला हिस्सा भी उल्लेखनीय है.

मुझे लगता है यह पूरे post में सबसे practical additions में से एक है.

क्यों? क्योंकि “अच्छा” context पर निर्भर करता है.

Article कहता है कि rubric evaluation “agent के intended behavior से context-aware evaluation criteria” बनाती है. यही दिशा इन systems को चाहिए.

Generic quality scoring उपयोगी है.

लेकिन अंत में teams को agents को अपने standards पर score करना होगा:

tone
task completion
policy adherence
latency expectations
cost boundaries
domain-specific business rules

यही वह जगह है जहाँ evaluation अकादमिक रूप से interesting होने से निकलकर operationally meaningful बनता है.

ROI सबसे uncomfortable हिस्सा है, और इसी लिए वह important है

मुझे announcement का ROI हिस्सा भी इसलिए महत्वपूर्ण लगता है क्योंकि वह असहज है.

Source सीधे सवाल पूछता है:

“क्या यह agent उसकी लागत के लायक है?”

AI conversations में इस सवाल से अक्सर बचा जाता है.

लेकिन यही सही सवाल है.

अगर platform सच में cost, task completion, time saved, और production traces को एक जगह जोड़ सके, तो engineering और leadership के लिए एक बहुत बेहतर shared language बनता है.

और honestly, उस shared language की बहुत जरूरत है.

मेरा take

यह batch की बेहतर platform-level announcements में से एक है क्योंकि यह agents को operate करने पर केंद्रित है, सिर्फ बनाने पर नहीं.

और असली कठिन काम यहीं से शुरू होता है.

अगले कुछ सालों में सबसे मजबूत AI platforms वही नहीं होंगे जिनके पास ज्यादा models या ज्यादा demos तक पहुंच होगी. वे वही होंगे जो teams को behavior trace करने, outcomes evaluate करने, safely optimize करने, और evidence के साथ cost justify करने में मदद करेंगे.

Foundry की यह कहानी ठीक उसी दिशा में बढ़ने की कोशिश कर रही है.

इसीलिए इसे गंभीरता से लेना चाहिए.

Original post: Build 2026: From observability to ROI for AI agents on any framework