LLM Kalitesini Yanlış Ölçmeyi Bırakın: Python’da IV Kullanın

LLM Kalitesini Yanlış Ölçmeyi Bırakın: Python’da IV Kullanın

Şu senaryoyu çok sık görüyorum. Bir ekip çok modelli bir LLM gateway kuruyor. Soruları maliyete, gecikmeye ve “karmaşıklık” sezgilerine göre GPT-4, Claude veya Llama’ya yönlendiriyorlar. Sonra da hangi modelin gerçekten daha iyi olduğunu anlamaya çalışıyorlar. En bariz şeyi yapıyorlar: her yanıtı logluyorlar, bir kalite puanı ölçüyorlar (kullanıcı oyu, tutarlılık veya hata oranı gibi) ve bu puanı kullanılan modele göre regresyona sokuyorlar. Kolay, değil mi?

Yanlış.

Bu şekilde hesapladığınız her metrik tamamen kurgu. Neden mi? Çünkü router’ınız rastgele değil. Kolay istekleri ucuz modellere, zor olanları pahalı modellere göndermekle meşgul. Llama’nın ortalama kalite puanı düşük çıktığında bunun sebebi Llama’nın daha aptal olması değil — router’ınızın ona sadece çetrefilli uç durumları göndermesi. İstatistikçiler buna **içsellik (endogeneity)** diyor ve 2025’te bir LLM pipeline’ı yönetiyorsanız, bu muhtemelen farkında bile olmadığınız en kötü gizli yanlılık.

Bugün size ekonometriden gelip ML ürün deneylerine sessizce giren bir çözümü göstereceğim: **Araç Değişkenleri (Instrumental Variables - IV)**. Ve bunu kendi routing loglarınızla yapmanız için gerçek Python kodunu vereceğim.

Standart Regresyon Neden LLM Routing Verisinde Çalışmaz?

Önce temel sorunu netleştirelim. Model A ile Model B’yi kullanmanın yanıt kalitesi üzerindeki nedensel etkisini bilmek istiyorum. Standart yol bir regresyon yapmak:

`quality_score ~ model_used + query_complexity + ...`

Sorun şu: gözlemlenmeyen karıştırıcı değişkenler var. Router’ınız karar verirken bir sürü özellik kullanıyor — bilgi alanı, müşteri duygusu, beklenen yanıt uzunluğu, hatta loglamayı unuttuğunuz A/B test bayrağı gibi şeyler. Bunların bazılarını ölçmek zor veya loglardan geri getirmek imkânsız. O yüzden birkaç kontrol değişkeni ekleyip umuyorsunuz. Ama umut bir strateji değil.

Router zor soruları Claude’a, kolayları GPT’ye gönderiyorsa, `model_used` katsayınız hem *zorluk* etkisini hem de *model* etkisini birlikte toplar. Sonunda hayalet bir optimizasyon yaparsınız.

Bunu gerçek üretim sistemlerinde sürekli görüyorum. “Müşteri desteği için en iyi LLM hangisi?” diye arıyorsunuz ve onlarca blog yazısı çıkıyor; hiçbiri kendi router’ının sonuçları karıştırdığından bahsetmiyor. Bu beni deli ediyor.

IV yaklaşımı bunu, **model seçimini değiştiren ama kaliteyi bağımsız olarak etkilemeyen** bir şey bularak çözer. O şey araç değişkenidir.

Sezgi: Trafik Polisi Analojisi

Diyelim ki belirli bir motor tipine sahip arabaların ortalama olarak daha hızlı olup olmadığını bilmek istiyorsunuz. Sorun şu: o motoru alan sürücüler aynı zamanda daha agresif kullanıyor. Gözlemlediğiniz hız, motor etkisi ile sürücü etkisinin karışımı.

Şimdi bir kavşakta kırmızı ışık var. Kırmızı ışık bazı sürücüleri rastgele durdurur ve bu da yeşil yandığında hangi arabanın önce gideceğini değiştirir. Kırmızı ışık *arabaların sırasını etkiler* ama tek başına hiçbir arabayı yavaşlatmaz veya hızlandırmaz. İşte o kırmızı ışık bir araç değişkenidir.

LLM routing’de bir araç değişken, router’ınız için bir “kırmızı ışık” gibidir — sorguları normalde gideceği modelden farklı bir modele zorlayan, ama yanıtın kalitesini kendisi değiştirmeyen keyfi bir dış şok.

Gerçek Dünyadan Örnekler

Örnek 1: Altyapı kesintileri doğal deney olarak

İki model endpoint’iniz var, diyelim GPT-4 ve Claude. Bir gün Claude’un sağlayıcısında kısmi bir kesinti oluyor. Router’ınız Claude’a gidecek sorguları otomatik olarak GPT-4’e düşürüyor. Kesintinin sorgu zorluğuyla bir ilgisi yok — herkesi rastgele vuruyor. Kesinti mükemmel bir araç değişkendir.

Bunu aslında bir müşteri destek botu olan bir danışanım için uyguladım. Her hafta birkaç dakikalığına model endpoint gecikme spike’ları yaşıyorlardı. “Gecikme spike’ı aktif” değişkenini “kullanılan model” için araç değişken olarak kullandık. IV tahmini, iş mantıklarının (zor sorguları pahalı modele gönderen) pahalı modelin kalitesini %18 oranında abarttığını gösterdi. Bu bir gürültü değil.

Örnek 2: Tam uyum olmayan A/B testi

Bir test duyuruyorsunuz: yeni kaydolanlar Model A’yı, mevcut kullanıcılar Model B’yi alacak. Ama önbellekleme ve replikasyon gecikmeleri yüzünden bazı mevcut kullanıcılar da Model A’yı aldı. Kayıt tipini basitçe karşılaştıramazsınız çünkü “kayıt tipi” tam olarak deterministik değil. Ancak, *atanan* tedaviniz (niyet) var — gerçek tedavi için araç değişken olarak atamayı kullanın. Atama kalite açısından rastgele ise, IV etkiyi temiz bir şekilde bulur. Bunu bir tıbbi chatbot değerlendirmesiyle akademik bir ortamda kullandım ve şaşırtıcı bir sonuç ortaya çıktı: Herkesin sevdiği Model B, routing yanlılığı giderildiğinde aslında daha kötüydü.

Örnek 3: Günün saati araç değişken olabilir mi?

Bazı router’larda yoğun yük kuralları vardır. Yüksek trafik saatlerinde para kazanmak için daha ucuz ve hızlı modele yönlendirirler. Ama günün saati, uygulamayı kimin kullandığıyla da ilişkilidir. Bu geçerli bir araç değişken mi? Bu daha zor — zamanın kaliteyi doğrudan etkilemediğinden emin olmalısınız. İş saatlerinde kullanılan B2B bir araçta yüksek yük aynı zamanda daha fazla karmaşıklık anlamına gelebilir. Yani belki değil. Mesele şu: dışlama kısıtını (exclusion restriction) dikkatlice düşünmeniz gerekiyor, körlemesine kodlayıp geçmeyin.

Python’da IV Yapmak (Ekonometri Doktorası Gerekmez)

Kod sandığınızdan daha basit. `linearmodels` kütüphanesini kullanacağım çünkü temiz özetler ve sağlam teşhisler veriyor.

Kurulum:

```bash
pip install linearmodels
```

Veya resmi depoya bakın: <https://github.com/bashtage/linearmodels>

Sentetik veriyle temel kalıp şöyle:

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

df şu sütunlara sahip olsun:
quality : sürekli sonuç (yüksek iyi)
model_b : 1 pahalı model, 0 ucuz model
incident : 1 rastgele kesinti/fallback var, 0 yok

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

Gizli fark (complexity) hem model seçimini hem kaliteyi etkiliyor
-- yanlılığa neden olan şey bu

Sihri görmek için simüle edelim
np.random.seed(42)
n = 5000
complexity = np.random.normal(size=n)
incident = np.random.binomial(1, 0.1, n) # rastgele kesinti

Router model_b'yi complexity ve araç değişkeni kullanarak seçiyor
Daha karmaşık -> pahalı modeli kullanma olasılığı daha yüksek
model_b = (0.5*complexity + 1.5*incident + np.random.normal(size=n)) > 0

model_b'nin gerçek nedensel etkisi 2.0
Ama complexity kaliteyi doğrudan düşürüyor
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 (yanlı)
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]) # Ağır şekilde yanlı çıkmalı

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

Göreceksiniz ki OLS katsayısı complexity tarafından aşağı çekilirken, IV tahmini gerçek 2.0’ı yakalıyor. Bütün hile bu.

Teşhisler: Relevance Testini Atlamayın

Bir araç değişkeni atıp dua edemezsiniz. İki şeyi kontrol etmeniz gerek.

**1. Relevance: Araç değişkeniniz gerçekten model seçimiyle ilişkili mi?**

İlk aşama F-istatistiğine bakın. `linearmodels.IV2SLS` içinde `.first_stage` özelliği bunu verir. Genel bir kural: F-istatistiği 10’un üzerindeyse araç değişkeniniz zayıf değildir. 10’un altındaysa daha iyi bir araç değişken bulmanız gerekir.

```python
iv.first_stage # tabloları inceleyin
```

F değeri çok küçükse araç değişkeniniz işe yaramaz. Yazı tura atmanızdan farkı olmaz.

**2. Dışsallık / Dışlama kısıtı: Araç değişken kaliteyi sadece model üzerinden mi etkiliyor?**

Bunu istatistiksel olarak kanıtlayamazsınız. Bir alan argümanına ihtiyacınız var. Kendinize sorun: Bu kesinti, zaman dilimi veya rastgele bayrak, kullanıcı deneyimini doğrudan etkiler miydi? Cevap evetse IV geçersizdir. Çoğu insan tam da burada yanıyor.

Örneğin, “gecikme spike’ı” araç değişken olarak kulağa hoş gelebilir, ama spike genel sisteminizin daha yavaş yanıt vermesine neden oluyorsa, kullanıcılar hangi model ilgilenirse ilgilensin sinirlenip yanıtı düşük puanlayabilir. Bu doğrudan bir etkidir ve dışlama kısıtını ihlal eder.

Bu yüzden hep derim: IV’nin en zor kısmı kod yazmak değil, kendinizi (ve ürün müdürünüzü) araç değişkeninizin gerçekten rastgele olduğuna ikna etmektir.

İleri Senaryolar

İkili ve sürekli tedavi

Yukarıdaki örnek ikili: Model B vs. değil. Peki üç modeliniz varsa? Yine IV yapabilirsiniz ama birden fazla araç değişkene ihtiyacınız olacak. Örneğin, her biri farklı bir model çiftini farklı şekilde etkileyen iki kesintiniz var. Bu işler çetrefilleşmeye başlıyor. Dürüst tavsiyem: ikili karşılaştırmalarla başlayın. GPT vs. Claude’u bir araç değişkenle, Claude vs. Llama’yı başka bir araç değişkenle karşılaştırın, vb.

IV size ortalama tedavi etkisini verir mi?

Hayır. IV, **Yerel Ortalama Tedavi Etkisini (LATE)** tahmin eder — yani araç değişken tarafından hareket ettirilen “uyumlular” (compliers) için etki. Bizim örneğimizde bu, yalnızca kesinti olduğu için yönlendirilen sorgulardır. Eğer yönlendirilen sorgular tuhaf bir alt küme ise (örneğin yedek modelin kalitesi ana modella yaklaşık aynı olan sorgular), IV genellenebilir olmayabilir. Bu, dashboard’unuza koymanız gereken kritik bir uyarıdır.

Ancak çoğu LLM routing bağlamında, uyumlular tam da model kalitesinden emin olmadığınız sorgulardır. Router karmaşık sorguları ana modele, basit olanları yedeğe gönderir. Kesinti, karmaşık sorguları daha ucuz modele zorlar; böylece en çok önemsediğiniz zor durumları öğrenmiş olursunuz — bu aslında harika.

IV Ne Zaman Kullanılmaz?

İnsanlara 5 dakika sonra durmalarını söylediğim zamanlar var. Büyük bir örneklem gerekir. IV verimsizdir. Elinizde yalnızca 500 yönlendirilmiş sorgu varsa standart hatalarınız devasa olur. Minimum binler, ideal olarak on binlerce.

Ayrıca, router’ınız deterministikse ve asla kesinti veya dış şok almıyorsa, araç değişkeniniz yok demektir. O zaman tek gerçek çözüm uygun bir randomize deney yapmaktır: trafiğin küçük bir kısmı için router’ı rastgele bypass edin ve modelleri doğrudan karşılaştırın. Bu altın standarttır. Yapabildiğinizde onu yapın. IV, randomize edemediğiniz zamanlar içindir.

Ekibiniz İçin Pratik Adımlar

1. **Araç değişken denetimi**: 30 dakika ayırın, router’ınızın sorgu içeriğiyle ilgisi olmayan nedenlerle normal davranışından saptığı her anı listeleyin. Gecikme, kesinti, kota limitleri, ağ zaman aşımları, sürüm dağıtımları. Bunlar aday araç değişkenleriniz.

2. **Loglamadığınız her şeyi loglayın**: Bir modelin neden seçildiğini kaydediyor muydunuz? Değilse, routing nedenini loglamaya başlayın. O neden daha sonra sizin IV’niz olabilir.

3. **Mevcut mimarinize aşırı bağlanmayın**: LLM sağlayıcı alanı haftalık değişiyor. Bugün işe yarayan araç değişkenler (belirli bir bölgedeki belirli bir kesinti gibi) yarın kaybolabilir. Yeni doğal deneylere açık olun.

4. **Bir dashboard yapın**: IV tahminlerini güven aralıklarıyla birlikte zaman içinde gösterin. Stabiliteyi izleyin. IV tahmininiz çok dalgalanıyorsa ya araç değişken başarısızdır ya da gerçek kalite değişmiştir (sağlayıcılar modelleri güncellediğinde olur).

Son Düşünce

2026’ya kadar her ciddi LLM routing platformunun deney altyapısına IV’yi entegre edeceğine eminim. Alternatif — gözlemsel veri üzerinde saf regresyon yürütmek — kendinize yalan söylemektir. Hangi modelleri tutacağınıza ve ne kadar ödeyeceğinize dair milyon dolarlık kararlar alıyorsunuz ve sistematik olarak yanlı olan bir yöntem kullanıyorsunuz.

Altyapınızda zaten var olan doğal rastlantısallığı kullanın. Bedava nedensel çıkarım, gözünüzün önünde saklanıyor.

---

SSS

1. Her yeni model eklediğimde yeni bir araç değişkene mi ihtiyacım var?

Hayır. Ama bir model eklediğinizde araç değişken stratejinizi yeniden düşünmeniz gerekir. Eski araç değişkenler diğer modeller arasındaki routing’i hâlâ etkiliyor olabilir, bu yüzden genellikle ikili karşılaştırmalarda onları yeniden kullanabilirsiniz. Router’ınız sorguları aynı anda tüm modeller arasında triyaj yapıyorsa farklı bir yaklaşım gerekebilir (ayrık seçim IV’ü gibi). Çoğu insan için ikili karşılaştırmalar yeterlidir.

2. Ya araç değişkenim zayıfsa (F < 10)? Yine de IV kullanmalı mıyım?

Hayır. Zayıf bir araç değişken, bazen OLS kadar kötü, yanlı tahminler üretir. Bunun yerine daha güçlü bir tane bulmaya çalışın. Ya da resmi bir randomize deney yapmayı düşünün. IV’nin amacı doğal şoklardan öğrenmektir; şoklarınız çok nadir veya çok zayıfsa, elinizde hiç yok demektir.

3. IV “insan tercihi” veya “güvenlik” gibi sonuçları ölçmek için kullanılabilir mi?

Kesinlikle. Sonuç değişkeniniz sürekli (veya bazı uyarılarla ikili) olduğu sürece IV’nin umurunda değil. Güvenlikte, araç değişkenin sonucu doğrudan etkilemediğine ekstra dikkat etmelisiniz. Örneğin, bir kesinti sistemin daha az korumalı bir güvenlik filtresine düşmesine neden oluyorsa, IV geçersizdir çünkü kesinti güvenlik politikasını kendisi değiştirir.

4. IV, rastgele A/B testi yapmaktan daha mı iyi?

Randomize kontrollü deneyler (RCT) hâlâ altın standarttır. Daha güçlü iç geçerliliğe sahiptirler ve araç değişken aramanıza gerek yoktur. IV, RCT yapamadığınızda *daha değerlidir* — örneğin ürün yönetimi rastgele kullanıcıları daha kötü bir modele göndermek istemiyorsa. IV, daha az iş riskiyle tarafsız sonuçlar elde etmek için doğal varyasyonu kullanır. Yapabildiğinizde RCT, yapmak zorunda kaldığınızda IV kullanın.

---

*Ekonometri ustalarından IV hakkında daha fazla bilgi edinmek ister misiniz? `linearmodels` dokümantasyonuna <https://github.com/bashtage/linearmodels> ve dokümanlarda referans verilen klasik Wooldridge ekonometri ders kitabına göz atın.*