LLM क्वालिटी गलत तरीके से मापना बंद करें: Python में IVs का इस्तेमाल करें

LLM क्वालिटी गलत तरीके से मापना बंद करें: Python में IVs का इस्तेमाल करें

मैं एक ऐसा scenario बहुत बार देखता हूँ। Team एक multi-model LLM gateway बनाती है। वे queries को GPT-4, Claude, या Llama के पास भेजते हैं — cost, latency, और "complexity" heuristics के आधार पर। फिर वे यह पता लगाने की कोशिश करते हैं कि असल में कौन सा मॉडल सबसे अच्छा perform कर रहा है। वे obvious काम करते हैं: हर response को log करते हैं, quality score measure करते हैं (जैसे user rating, agreement, या error rate), और फिर उस score को model पर regress करते हैं। आसान है, है ना?

गलत है।

इस तरह से जो भी metric आप निकालेंगे, वह बिल्कुल fiction है। क्यों? क्योंकि आपका router random नहीं है। वह आसान requests को सस्ते models के पास भेज रहा है और मुश्किल requests को महँगे models के पास। तो जब आप देखते हैं कि Llama का average quality score कम है, तो इसका मतलब यह नहीं कि Llama कम समझदार है — असल वजह यह है कि आपका router उसे सिर्फ वही gnarly edge cases भेजता है। Statisticians इसी को **endogeneity** कहते हैं। और अगर आप 2025 में LLM pipeline manage कर रहे हैं, तो यह सबसे बुरा hidden bias है जिसके बारे में आपको पता भी नहीं है।

आज मैं आपको econometrics से निकला एक ऐसा समाधान दिखाऊँगा जो अब धीरे-धीरे ML product experimentation में घुस रहा है: **Instrumental Variables (IV)**। साथ में मैं आपको असली Python code भी दूँगा जो आप अपने routing logs पर इस्तेमाल कर सकते हैं।

Standard Regression LLM Routing Data पर क्यों Fail होती है

पहले fundamental problem को सीधे समझ लेते हैं। मैं जानना चाहता हूँ कि Model A को इस्तेमाल करने का response quality पर क्या causal effect है, बनाम Model B। Standard तरीका है regression चलाना:

`quality_score ~ model_used + query_complexity + ...`

समस्या यह है कि कुछ unobserved confounders होते हैं। आपका router अपना decision लेने के लिए बहुत सारी features use करता है — knowledge domain, customer sentiment, expected answer length, यहाँ तक कि वो A/B test flag भी जिसे आप log करना भूल गए। इनमें से कुछ चीज़ों को measure करना बहुत मुश्किल है। कुछ तो logs से दोबारा बनाना नामुमकिन है। So आप कुछ control variables डाल देते हैं और उम्मीद करते हैं। But उम्मीद कोई strategy नहीं है।

अगर router मुश्किल सवाल Claude को भेजता है और आसान सवाल GPT को, तो `model_used` पर आपका coefficient सिर्फ model का असर नहीं दिखाता। उसमें *difficulty* का असर भी घुला हुआ होता है। और आप एक phantom को optimize करने लगते हैं।

मैं यह असली production systems में हर वक्त देखता हूँ। आप search करते हैं "which LLM is best for customer support?" और दर्जनों blog posts मिल जाते हैं। उनमें कहीं यह mention नहीं होता कि उनके अपने router ने results को confound किया था। यह मुझे बहुत चिढ़ाता है।

IV approach इस समस्या को ठीक करता है। यह कोई ऐसी चीज़ ढूँढता है जो **model selection को बदलती है लेकिन quality को independently प्रभावित नहीं करती**। यही चीज़ instrumental variable कहलाती है।

Intuition: Traffic Cop वाला Analogy

सोचिए, आप जानना चाहते हैं कि क्या एक certain engine type वाली गाड़ियाँ औसतन तेज़ चलती हैं। Problem यह है कि जो drivers वो engine खरीदते हैं, वे और ज़्यादा aggressive drive करते हैं। आपकी observed speed में engine का असर भी मिला हुआ है और driver का असर भी।

अब मान लीजिए कि एक intersection पर red light लग जाती है। Red light randomly कुछ drivers को रोक देती है। इससे बदल जाता है कि green होने पर कौन सी गाड़ी पहले जाएगी। Red light *गाड़ियों के क्रम को प्रभावित करती है*, लेकिन किसी भी गाड़ी को अपने आप में धीमा या तेज़ नहीं बनाती। यही red light आपका instrument है।

LLM routing में, instrument आपके router के लिए एक "red light" जैसा है। यानी कोई arbitrary external shock जो queries को आम तौर से हटकर किसी दूसरे model में भेज दे, लेकिन response की quality को खुद न बदले।

Real Examples — असली दुनिया से

Example 1: Infrastructure outages — natural experiments की तरह

मान लीजिए आप दो model endpoints host करते हैं — GPT-4 और Claude। एक दिन Claude के provider में partial outage आ जाती है। आपका router automatically उन queries को GPT-4 पर fall back कर देता है जो Claude के पास जानी थीं। Outage का query difficulty से कोई लेना-देना नहीं — यह सबको equally hit करती है। यह outage एक perfect instrument है।

मैंने असल में यह एक client के लिए implement किया था जिसके पास customer-support bot था। हर हफ्ते उनके model endpoints में कुछ मिनटों के latency spikes आते थे। हमने "latency spike active" को "model used" के instrument के रूप में use किया। IV estimate ने दिखाया कि उनकी business logic — जो tough queries को महँगे model को भेजती थी — उस महँगे model की quality को 18% तक overestimate कर रही थी। यह कोई noise नहीं है।

Example 2: A/B test जिसमें perfect compliance नहीं थी

आप एक test announce करते हैं: नए signups को Model A मिलेगा, पुराने users को Model B। लेकिन caching और replication delays की वजह से कुछ पुराने users को भी Model A मिल गया। आप सीधे signup types की तुलना नहीं कर सकते, क्योंकि "signup type" perfectly deterministic नहीं है। हालाँकि आपके पास *assigned* treatment है — यानी intent। Assignment को actual treatment के instrument की तरह use करिए। अगर assignment quality के मामले में random है, तो IV सही effect निकाल देगा। मैंने यह एक academic setting में medical chatbot evaluation पर किया था। Result surprising था: Model B, जिसे सब प्यार करते थे, असल में routing bias हटाने के बाद worse निकला।

Example 3: Time-of-day एक instrument की तरह

कुछ routers में peak-load rules होते हैं। High traffic के समय वे पैसे बचाने के लिए सस्ते और तेज़ model की तरफ भेज देते हैं। लेकिन time-of-day का correlation इस बात से भी है कि app कौन use कर रहा है। क्या यह valid instrument है? यह थोड़ा tricky है। आपको यह सुनिश्चित करना होगा कि time directly quality को प्रभावित नहीं करता। B2B tool में जो business hours में use होता है, वहाँ high load का मतलब ज़्यादा complexity भी हो सकता है। So maybe not. Point यह है — exclusion restriction के बारे में ध्यान से सोचिए, बस blindly code मत कर दीजिए।

Python में IV करना (बिना PhD in Econometrics)

Code आपके ख्याल से कहीं आसान है। मैं `linearmodels` library use करूँगा, क्योंकि यह साफ summaries और robust diagnostics देती है।

Install करें:

```bash
pip install linearmodels
```

या official repo देखें: <https://github.com/bashtage/linearmodels>

Synthetic data के साथ basic pattern यह रहा:

```python
import pandas as pd
import numpy as np
from linearmodels.iv import IV2SLS

Assume df has columns:
quality : continuous outcome (higher is better)
model_b : 1 if high-cost model, 0 if low-cost model
incident : 1 if there was a random outage/fallback, 0 otherwise

df = pd.read_csv('router_logs.csv')

Latent diff (complexity) that affects both model selection and quality
-- this is what causes the bias

Let's simulate to see the magic
np.random.seed(42)
n = 5000
complexity = np.random.normal(size=n)
incident = np.random.binomial(1, 0.1, n) # random outage

Router selects model_b using complexity and instrument
More complex -> more likely to use expensive model
model_b = (0.5*complexity + 1.5*incident + np.random.normal(size=n)) > 0

True causal effect of model_b is 2.0
But complexity also lowers quality directly
quality = 5 + 2.0*model_b - 1.0*complexity + np.random.normal(size=n)

df = pd.DataFrame({'quality': quality, 'model_b': model_b, 'incident': incident})

Naive OLS (biased)
import statsmodels.api as sm
X = sm.add_constant(df[['model_b']])
ols = sm.OLS(df['quality'], X).fit()
print("Naive OLS:", ols.params[1]) # Should be heavily biased

IV regression
df['const'] = 1
iv = IV2SLS(df['quality'], df[['const', 'model_b']], None, df[['incident']]).fit()
print("IV estimate:", iv.params['model_b'])
```

आप देखेंगे कि OLS coefficient complexity की वजह से नीचे खिंच जाता है। वहीं IV estimate सही 2.0 पर निशाना लगाता है। यही पूरा trick है।

Diagnostics: Relevance Test को Skip न करें

आप सिर्फ एक instrument डालकर prayer नहीं कर सकते। दो चीज़ें check करनी पड़ती हैं।

**1. Relevance: क्या आपका instrument वाकई model choice के साथ correlated है?**

First-stage F-statistic देखिए। `linearmodels.IV2SLS` में `.first_stage` property से यह मिल जाता है। आम rule of thumb: F-statistic 10 से ऊपर हो तो instrument weak नहीं है। अगर 10 से नीचे है, तो कोई बेहतर instrument ढूँढिए।

```python
iv.first_stage # inspect tables
```

अगर F बहुत छोटा है, तो आपका instrument बेकार है। फिर तो सिक्का उछालना भी बराबर है।

**2. Exogeneity / Exclusion restriction: क्या instrument का असर quality पर सिर्फ model के रास्ते होता है?**

यह चीज़ आप statistical तरीके से साबित नहीं कर सकते। आपको domain argument देना होगा। खुद से पूछिए: क्या यह incident, time period, या random flag user experience पर कोई direct असर डाल सकता है? अगर हाँ, तो आपका IV invalid है। यहीं पर ज़्यादातर लोग जल जाते हैं।

उदाहरण के लिए, "latency spike" को instrument बनाना अच्छा लग सकता है। लेकिन अगर spike की वजह से आपका पूरा system धीमा respond करे, तो users frustrate होकर answer को कम rating दे सकते हैं — चाहे कोई भी model handle करे। यह direct effect है, जो exclusion को तोड़ देता है।

इसलिए मैं हमेशा कहता हूँ: IV का सबसे मुश्किल हिस्सा coding नहीं है। असली मुश्किल खुद को (और अपने PM को) यह विश्वास दिलाना है कि आपका instrument truly random है।

Advanced Scenarios

Binary treatment और continuous treatment

ऊपर वाला example binary था: Model B vs. not Model B। लेकिन अगर तीन models हैं? तो आप IV कर सकते हैं, लेकिन आपको multiple instruments चाहिए होंगे। मसलन, आपके पास दो incidents हैं और हर एक अलग-अलग pairs of models को अलग तरह से प्रभावित करता है। यह थोड़ा उलझ जाता है। मेरी सच्ची सलाह: pairwise comparisons से शुरू करिए। एक instrument से GPT vs. Claude compare करिए। फिर दूसरे से Claude vs. Llama। ऐसे ही आगे बढ़िए।

क्या IV average treatment effect देता है?

नहीं। IV **Local Average Treatment Effect (LATE)** estimate करता है — यानी उन "compliers" पर असर जिन्हें instrument ने move किया। हमारे case में, ये वो queries हैं जो सिर्फ इसलिए reroute हुईं क्योंकि incident आ गया था। अगर rerouted queries अजीब subset हैं (जैसे जहाँ fallback model की quality primary के बराबर है), तो IV generalize नहीं कर पाएगा। यह critical caveat है जो आपको अपने dashboard में लगाना चाहिए।

लेकिन ज़्यादातर LLM routing contexts में, compliers वही queries हैं जिनमें आपको model quality को लेकर uncertainty है। Router complex queries को primary model के पास भेजता है और simple queries को fallback पर। Incident complex queries को सस्ते model में धकेल देता है। तो आप उन्हीं मुश्किल cases के बारे में सीख रहे हैं जिनकी आपको सबसे ज़्यादा परवाह है। यह सच में बहुत अच्छी बात है।

IV का इस्तेमाल कब न करें

कई बार मैं लोगों को 5 मिनट में रुक जाने को कहता हूँ। आपको बड़ा sample चाहिए। IV inefficient है। अगर आपके पास सिर्फ 500 routed queries हैं, तो आपके standard errors बहुत बड़े होंगे। Thousands minimum है, ideally tens of thousands.

और अगर आपका router deterministic है और उसे कभी incidents या external shocks नहीं मिलते, तो आपके पास instrument ही नहीं है। ऐसे में असली समाधान सिर्फ एक है — proper randomized experiment। Traffic के एक छोटे हिस्से के लिए router को randomly bypass करिए और models को सीधे compare करिए। यही golden standard है। जब possible हो तो यही करिए। IV उस समय के लिए है जब आप randomize *नहीं* कर सकते।

अपनी Team के लिए Practical Steps

1. **Instrument audit**: 30 मिनट निकालिए। List बनाइए — हर वो मौका जब आपका router अपने usual behavior से भटका हो, और वजह query content से unrelated हो। Latency, outages, quota limits, network timeouts, version deployments। यही आपके candidate instruments हैं।

2. **जो आपने log नहीं किया उसे log करिए**: क्या आपने record किया कि model क्यों चुना गया? अगर नहीं, तो routing reason को log करना शुरू करिए। वही reason बाद में आपका IV बन सकता है।

3. **अपने current architecture पर overfit मत होइए**: LLM provider space हफ्ते-दर-हफ्ते बदलता है। जो instruments आज काम करते हैं (जैसे किसी specific region का कोई खास outage) वे कल गायब हो सकते हैं। नए natural experiments के लिए आँखें खुली रखिए।

4. **Dashboard बनाइए**: IV estimates को confidence intervals के साथ समय के हिसाब से plot करिए। Stability देखिए। अगर आपका IV estimate बहुत उछलता है, तो या तो instrument fail हो रहा है या true quality बदल गई है। ऐसा तब होता है जब providers अपने models update करते हैं।

आखिरी बात

मुझे पूरा यकीन है कि 2026 तक हर गंभीर LLM routing platform के experimentation stack में IV built-in होगा। इसका विकल्प — observational data पर naive regressions चलाना — खुद से झूठ बोलने जैसा है। आप लाखों डॉलर के फैसले ले रहे हैं कि कौन से models रखने हैं और कितना pay करना है। और आप ऐसा method use कर रहे हैं जो systematically biased है।

Use करिए उस natural randomness को जो आपके infrastructure में पहले से मौजूद है। यह free causal inference है, hiding in plain sight.

---

FAQ

1. क्या हर नए model के लिए नया instrument चाहिए?

नहीं। लेकिन जब आप नया model जोड़ते हैं, तो अपनी instrument strategy पर दोबारा सोचने की ज़रूरत होती है। Пुराने instruments अब भी दूसरे models के बीच routing को प्रभावित कर सकते हैं, इसलिए pairwise comparisons के लिए आप अक्सर उन्हें दोबारा use कर सकते हैं। अगर आपका router सभी models के बीच एक साथ queries को triage करता है, तो अलग approach चाहिए — जैसे discrete choice IV। ज़्यादातर लोगों के लिए pairwise काफी है।

2. अगर मेरा instrument weak है (F < 10), तो क्या मैं फिर भी IV use करूँ?

नहीं। Weak instrument biased estimates देगा, कई बार उतना ही बुरा जितना OLS। इसके बजाय कोई मज़बूत instrument ढूँढिए। या formal randomized experiment चलाइए। IV का मकसद natural shocks से सीखना है। अगर आपके shocks बहुत rare या बहुत weak हैं, तो आपके पास कुछ नहीं है।

3. क्या IV का use "human preference" या "safety" outcomes measure करने के लिए हो सकता है?

बिल्कुल। IV को आपके outcome variable से कोई फर्क नहीं पड़ता, जब तक वह continuous है (या binary हो तो कुछ caveats के साथ)। Safety के मामले में आपको extra careful रहना होगा कि instrument outcome को directly प्रभावित न करे। मिसाल के लिए, अगर किसी incident की वजह से system किसी कम सुरक्षित safety filter पर fall back कर जाए, तो IV invalid है। क्योंकि incident ने खुद safety policy बदल दी।

4. क्या IV random A/B testing से बेहतर है?

Randomized control trials (RCTs) अब भी gold standard हैं। उनकी internal validity मज़बूत होती है और आपको instruments ढूँढने की ज़रूरत नहीं पड़ती। IV का *असली मूल्य* तब है जब आप RCT नहीं कर सकते — मसलन, product leadership random users को worse model पर भेजना नहीं चाहती। IV natural variation का फायदा उठाकर unbiased results देता है, वो भी कम business risk के साथ। जब हो सके RCT use करिए, जब मजबूरी हो IV।

---

*Econometrics के masters से IV के बारे में और सीखना चाहते हैं? `linearmodels` documentation देखिए <https://github.com/bashtage/linearmodels> और docs में referenced classic Wooldridge econometrics textbook पढ़िए।*