Göndermeyi planladığınız işlerde AI modellerini benchmark edin; başkasının görevi için oluşturulmuş bir leaderboard üzerinde değil. Herkese açık bir benchmark güçlü bir aday belirleyebilir. Ancak bu modelin iş akışınızı güvenilir biçimde tamamlayıp tamamlamayacağını söyleyemez.
Hedef kitle: Orta seviye — gerçek bir uygulama için model seçen geliştiriciler, ürün ekipleri ve teknik satın alma uzmanları.
AI modellerini gerçek işler için benchmark etmek üzere her adaya aynı temsili görevleri verin, ifadeler yerine ortaya çıkan durumu değerlendirin, her görevi tekrarlayın, gecikme ve maliyeti kaydedin ve kabul edemeyeceğiniz hatalar etrafında bir rollout gate belirleyin. Kazanan model, bu kapıları tutarlı biçimde geçen en ucuz seçenektir. En yüksek ortalama skora sahip model olması şart değildir.
Bir AI model benchmark'ı neyi yanıtlamalıdır?
Kullanışlı bir benchmark tek bir operasyonel soruyu yanıtlamalıdır:
Bu cümle altı ayrıntıyı açıkça ortaya çıkarır:
Herkese açık benchmark'lar genellikle bu değişkenlerin farklı bir kombinasyonunu sabitler. Model card'ları ve release note'lar yine de yardımcı olur: aday listesini daraltır ve desteklenen modality'leri, context limitlerini, fiyatlandırmayı ve bilinen safety davranışlarını ortaya çıkarır. Temmuz 2026 sürümleri bu ayrımı gösteriyor. OpenAI, GPT-5.6 için geniş capability ve safety sonuçları yayımlarken Google, Gemini 3.6 Flash için önceki Flash modeline kıyasla daha düşük token kullanımı ve fiyatı belgeledi. Bunlar prompt'unuzun, tool'larınızın, verilerinizin veya error budget'ınızın ölçümleri değil, yararlı öncül bilgilerdir. (OpenAI, Google)
NVIDIA NIM free AI API case study→, bir translation workflow'unun model seçimini ölçülebilir throughput ve consistency'ye nasıl dönüştürebileceğini gösterir. Coding adayları için odaklanmış free AI coding agents comparison→ ile başlayın. Ardından kararı kendi test set'inize taşıyın.
Tek bir ortalama skor production riskini neden gizler?
Son dönemdeki üç benchmark aynı sorunu farklı alanlardan ortaya koyuyor.
Partial credit uçtan uca başarısızlığı gizleyebilir
APEX-Accounting, spreadsheet'ler, PDF'ler ve diğer dosyaları kullanarak on sentetik şirket genelinde 160 accounting görevinde modelleri değerlendirir. Görevleri ve başarı kriterlerini accounting uzmanları yazdı. Araştırmacılar dokuz frontier modelini görev başına sekiz kez çalıştırarak 11.520 trajectory üretti.
En güçlü model, makalenin partial-credit metriği olan Mean Criteria@3'te %56,4'e ulaştı. Ancak hiçbir model, bir görevin sekiz denemesinin tamamının başarılı olup olmadığını soran Pass^8 metriğinde %2,6'yı aşamadı. Sekiz denemeden en az birinin başarılı olup olmadığını soran en iyi Pass@8 sonucu %21,5'ti. 160 görevin 93'ü, test edilen hiçbir model tarafından hiçbir çalıştırmada kusursuz biçimde tamamlanmadı. (APEX-Accounting)
Yazarlar, kontrollü sentetik bir ortamda close-cycle accounting görevlerini ölçtü. Tax, audit, consolidation, multi-entity veya multi-currency işleri ya da external reporting kapsam dışındaydı. Görev seti ayrıca üç frontier modeli kullanılarak zorluk açısından filtrelendi; bu durum skorları düşürebilir veya bazı model ailelerini avantajlı kılabilir. Pratik sonuç “AI accounting yapamaz” ifadesinden daha dardır: Bir model birçok bireysel kontrolü karşılayabilir, ancak unattended, multi-step bir workflow için fazla tutarsız kalabilir.
Geçerli bir çıktı yine de kullanıcının kısıtını kaçırabilir
TREK, 212.530 kayıt içeren sentetik bir knowledge base'e karşı 800 görevde travel-planning agent'larını test eder. Evaluator, planı başka bir language model'dan değerlendirmesini istemek yerine kuralları ve final state'i deterministik biçimde kontrol eder.
Test edilen en güçlü agent, uygulanabilir görevlerin %46,2'sini kusursuz biçimde tamamladı. %94,9 oranında hallucination-free ve %86,3 oranında executable olmasına rağmen tüm kullanıcı kısıtlarını yalnızca %50,7 oranında karşıladı. Sistem makul ve bookable planlar üretebilirken örtük bir tercihi veya adımlar arası gereksinimi kaçırabiliyordu. (TREK)
TREK sentetik bir travel world kullanır, canlı fiyatları ve availability'yi dışarıda bırakır ve agent başına tek bir run raporlar. Reasoning karşılaştırması, eşleştirilmiş kontrollü bir ablation yerine tek çiftli, sürümler arası bir gözlemdir. Yine de kalıcı bir evaluation kuralını gösterir: final state'i ve bağlayıcı her kısıtı kontrol edin. Fluency, task completion değildir.
Benchmark'ın kendisi bozuk olabilir
OpenAI'nin SWE-Bench Pro'nun 731 görevlik public split'i üzerinde yaptığı audit, yanlış güvenin ikinci bir kaynağını ortaya çıkardı: hatalı evaluation data. Otomatik bir pipeline görevlerin %27,4'ünü bozuk olarak işaretlerken, beş mühendisin yürüttüğü annotation süreci %34,1'ini işaretledi. Sorunlar arasında yetersiz tanımlanmış prompt'lar, aşırı katı testler ve eksik çözümlerin geçmesine izin veren testler vardı. OpenAI, benchmark'ın yaklaşık %30'unun bozuk olduğunu tahmin etti ve daha önce onu kullanma yönündeki tavsiyesini geri çekti. (OpenAI benchmark audit)
Zor bir test, yalnızca bilinen iyi bir reference result testi geçtiğinde ve yanlış bir result doğru nedenle başarısız olduğunda kullanışlıdır.
AI modelleri yedi adımda nasıl benchmark edilir?
1. Testten önce kararı tanımlayın
Production kararını tek satırda yazın:
Sayıları ürününüze göre değiştirin. Yapıyı koruyun. Karar kuralı olmayan bir benchmark, sonuçlar geldikten sonra cherry-picking yapılmasına davetiye çıkarır.
Hard gate'leri optimization metric'lerinden ayırın:
Bir model, ortalama skoru daha yüksek olsa bile hard gate'i ihlal ediyorsa kaybeder.
2. Görevleri demo'dan değil işten oluşturun
Kullanmanıza izin verildiğinde gerçek, kimlikten arındırılmış örneklerle başlayın. Nadir hataları kapsamak için synthetic case'ler ekleyin, ancak synthetic prompt'ların kullanıcıların oluşturduğu dağılımın yerini almasına izin vermeyin.
Pratik bir ilk suite 30 ila 50 görev içerebilir:
Bu yüzdeler başlangıç şablonudur, statistical standard değildir. High-impact sistemler daha geniş coverage ve domain review gerektirir. Prompt tuning'in benchmark'a sessizce overfit olmasını önlemek için ayrı bir holdout set tutun.
Her görevi language, input type, risk, difficulty ve expected behavior'a göre etiketleyin. Aggregate skorlar iyileşirken önemli bir slice kötüleşebilir.
3. Gözlemlenebilir sonuçları belirtin
Mümkün olduğunda artifact'i veya system state'i değerlendirin:
Anthropic'in evaluation guidance'ı da transcript ile outcome arasındaki aynı ayrıma dikkat çeker: Bir agent bir flight'ın rezerve edildiğini söyleyebilir, ancak ilgili kontrol reservation'ın database'de mevcut olup olmadığıdır. Mümkün olduğunda deterministic grader'ları, gerektiğinde model-based grader'ları ve calibration için human review'ı önerir. (Anthropic)
Partial credit'i bir failure'ı teşhis etmek için kullanın, deployment'ı onaylamak için değil. Task-perfect rate, tüm işin ne sıklıkla tamamlandığını söyler. Criteria coverage ise hangi gereksinimin genellikle bozulduğunu gösterir.
4. Test koşullarını sabitleyin
Her run için eksiksiz configuration'ı kaydedin:
Soru özellikle “hangi complete system'i deploy etmeliyiz?” değilse, bir modeli tuned prompt ile diğerini generic prompt ile karşılaştırmayın. Model benchmark'ı ve system benchmark'ı farklı soruları yanıtlar.
Provider API'leri değişir. Örneğin Google'ın current model guide'ı, Gemini 3.6 Flash'ın deprecated sampling parameters'ı yok saydığını ve gelecekteki generation'larda bunları reddedeceğini söylüyor. Reproducible bir kayıt, sessiz bir configuration değişikliğinin model drift'i gibi görünmesini önler. (Google model guide)
5. Eşleştirilmiş, tekrarlanan denemeler çalıştırın
Her adayı aynı task ID'leri üzerinde çalıştırın. Paired comparison, test zorluğundaki farklılıklardan kaynaklanan gürültüyü azaltır.
Tek bir run bir anekdotu ölçer. Repeated run'lar variance'ı ortaya çıkarır:
Görev başına üç tekrar, instability hakkında düşük maliyetli bir ilk görünüm sağlar. Beş ila sekiz tekrar, high-variance veya high-risk workflow'lar için daha net bir tablo sunar. Bunlar evrensel sample-size kuralları değil, pratik başlangıç noktalarıdır. Aday skorları birbirine yakın olduğunda veya deployment sonucu büyük olduğunda tekrarları artırın.
*Her adayı aynı görevlerden ve tekrarlanan denemelerden geçirin. Guarded rollout öncesinde sonuçları, consistency'yi, latency'yi ve cost'u karşılaştırın.*
6. Yalnızca toplamları değil hataları da inceleyin
Her failed trial için şunları saklayın:
Yararlı failure label'ları arasında missing constraint, wrong tool, invalid argument, retrieval miss, fabricated fact, premature completion, unsafe action, timeout ve grader defect bulunur.
Pass'lerin bir örneğini de okuyun. Gevşek bir grader, daha sonra başarısız olacak bir shortcut'ı ödüllendirebilir. Katı bir grader, geçerli bir alternatifi reddedebilir. Hatalar adil görünmüyorsa modelleri karşılaştırmadan önce görevi düzeltin.
Dar kapsamlı bir evaluation da burada yardımcı olabilir. Retrieval zayıf aşamaysa RAG evaluation workflow→ ile ayrı test edin. Bir confidence signal escalation'ı kontrol ediyorsa, LLM confidence score→ değerini truth olarak görmek yerine labeled outcome'lara göre calibrate edin.
7. Bir rollout gate uygulayın
Modeli ancak önceden yazılmış kuralı geçtikten sonra seçin. Ardından seçilen configuration üzerinden trafiğin küçük ve geri alınabilir bir bölümünü gönderin.
Production'da aynı outcome metric'lerini izleyin. Yeni gözlemlenen hataları regression suite'e ekleyin. Zorlu kalması gereken capability test'lerini, sistemin zaten desteklediği davranışlar için %100'e yakın kalması gereken regression test'lerinden ayrı tutun.
Yerel bir benchmark belirsizliği azaltır. Distribution shift'i, provider değişikliklerini, yeni kullanıcı davranışlarını veya evaluator hatalarını ortadan kaldırmaz.
Gerçek işi yansıtan bir scorecard
| Metric | Calculation | Why it matters |
|---|---|---|
| --- | --- | --- |
| Task-perfect rate | Every required check passed olan tasks / all tasks | Uçtan uca tamamlanmayı ölçer |
| Criteria coverage | Passed checks / all checks | Partial failure'ların yerini belirler |
| First-attempt success | Trial one'da geçen tasks / all tasks | Retry olmadan kullanıcı deneyimini yakalar |
| Pass@k | k trial içinde en az bir success bulunan tasks / all tasks | Alternatiflere izin verilen search veya generation için uygundur |
| Pass^k | Tüm k trial'ın başarılı olduğu tasks / all tasks | Consistency risk'ini ortaya çıkarır |
| Cost per successful task | Total model ve tool cost / completed tasks | Ucuz ancak failure-prone bir modelin verimli görünmesini önler |
| p50 and p95 latency | Median ve tail completion time | Hem normal hızı hem de yavaş kullanıcı deneyimini gösterir |
| Hard-gate violations | Safety veya policy rule başına count | Kabul edilemez davranışı engeller |
Her metric'i çok erken tek bir weighted number içinde birleştirmeyin. Tek bir skor, safety failure'ını daha düşük cost veya daha iyi style arkasında gizleyebilir.
Reproducible bir başlangıç formatı
Task'ları versioned JSONL file içinde saklayın. Private veya personal data'yı repository dışında tutun.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
Grader, persuasive wording aramak yerine result'ı incelemelidir:
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Task'a güvenmeden önce bir reference solution ve kasıtlı olarak yanlış bir solution'ı grader'dan geçirin. Reference geçmelidir. Wrong result, beklenen nedenle başarısız olmalıdır.
Ne zaman LLM judge kullanmalısınız?
State, schema, calculations, citations, required fields ve prohibited actions için deterministic check'ler kullanın. Bunlar ucuz, reproducible ve debug edilmesi kolaydır.
Quality exact check'lere indirgenemediğinde rubric-based human veya LLM grader kullanın: tone, completeness, argument quality veya bir summary'nin önemli nüansı koruyup korumadığı. Rubric'i specific tutun. Kabul edilebilir alternatiflere ve disqualifying error'lara örnekler ekleyin.
Bir LLM judge'ı scale'de kullanmadan önce expert label'lara göre calibrate edin. APEX-Accounting bunu açıkça yaptı: Judge'ları 1.687 human label'a karşı kontrol edildi ve bu çalışmada F1 score'u 0,970'e ulaştı. Bu, judge'ı makalenin kriterleri ve verileri için doğrular; aynı judge'ı evrensel olarak güvenilir kılmaz. (APEX-Accounting)
Canonical benchmark pahalı olduğunda adaptive sampling evaluation cost'unu azaltabilir. BayesAME, historical reference-model performance kullanarak item'ları seçer ve çeşitli academic benchmark'larda birkaç baseline'a kıyasla daha iyi accuracy-cost trade-off'ları raporlar. Mevcut yöntemi scalar score'ları ve yararlı historical item signal'larını varsayar. Küçük, bespoke bir suite için full run karşılanabilir durumdaysa her task'ı çalıştırmak yine daha basit ve audit edilmesi daha kolaydır. (BayesAME)
Open-source tool'lar, product requirements'ınızı tanımlamadan harness sağlayabilir. Inspect AI, task execution, scoring, logs ve retry'ları destekler. LM Evaluation Harness, geniş bir academic task ve model backend koleksiyonu sunar. Uygun olduklarında kullanın. Versioned bir JSONL file ile product-specific grader'lar, ilk yararlı benchmark için çoğu zaman yeterlidir.
Yaygın benchmarking hataları
Yalnızca happy path'i test etmek
Bir model action almayı öğrenebilir, ancak ne zaman durması gerektiğini asla öğrenmeyebilir. Action alması gereken ve clarify, abstain veya refuse etmesi gereken eşleştirilmiş case'ler ekleyin.
Explanation'ı outcome yerine değerlendirmek
Kendinden emin prose, hiç gerçekleşmemiş bir action'ı anlatabilir. Database'i, file'ı, API response'u veya test result'ı inceleyin.
Birkaç değişkeni aynı anda değiştirmek
Modeli, prompt'u, retrieval system'ini ve tool'ları birlikte değiştirirseniz complete system'leri karşılaştırabilirsiniz, ancak farkı modele atfedemezsiniz.
Test set'i üzerinde tuning yapmak
Iterate ederken failed example'ları development set'e taşıyın. Rollout öncesinde değişikliği dokunulmamış holdout task'lar üzerinde doğrulayın.
Failure'ın oluşturduğu cost'u görmezden gelmek
Token başına fiyat; retry'ları, human review'ı, tool call'larını veya kötü bir action'dan kurtulma maliyetini içermez. Başarılı task başına cost'u ölçün.
Yeni bir benchmark'ı kalıcı truth olarak görmek
Task contamination, saturation, broken grader'lar ve capability shift'leri signal'ı yok edebilir. Benchmark version'ını kaydedin ve failure'larının hâlâ adil görünüp görünmediğini yeniden değerlendirin.
Claim kontrolleri
| Important claim | Evidence | Boundary or uncertainty |
|---|---|---|
| --- | --- | --- |
| Partial-credit skorları zayıf uçtan uca consistency ile birlikte görülebilir | APEX-Accounting: en iyi model için %56,4 Mean Criteria@3; hiçbir model %2,6 Pass^8'i aşmadı | Sentetik close-cycle accounting task'ları; difficult-task filtering skorları etkileyebilir |
| Geçerli görünen planlar binding constraint'leri kaçırabilir | TREK: en güçlü agent, daha yüksek executability ve hallucination-free oranlarına rağmen %46,2 task-perfect ve %50,7 satisfaction | Sentetik travel world; agent başına tek trial |
| Benchmark kusurları capability estimate'lerini önemli ölçüde bozabilir | OpenAI audit'i, SWE-Bench Pro'nun public task'larının %27,4'ünü automated review ve %34,1'ini human review ile broken olarak işaretledi | Tek bir coding benchmark ve tek bir audit methodology |
| Mevcut olduğunda deterministic outcome check'leri tercih edilmelidir | Anthropic'in evaluation guidance'ı ve deterministic TREK evaluator'ı | Subjective quality yine calibrated human veya model judgment gerektirir |
| Adaptive item selection, large-benchmark cost'unu azaltabilir | BayesAME, çeşitli academic benchmark'larda daha güçlü estimation-cost trade-off raporlar | Historical reference signal'larına ve scalar score'lara bağlıdır |
Sık sorulan sorular
Bir AI modelini benchmark etmek için kaç örneğe ihtiyacınız var?
İyi seçilmiş 30 ila 50 görev, belirgin farkları ve failure mode'ları ortaya çıkarabilir. Bu bir pilot çalışmadır, kanıt değildir. Kararlar pahalı olduğunda, slice'lar çeşitli olduğunda veya aday skorları birbirine yakın olduğunda suite'i genişletin. Uncertainty'yi raporlayın ve bir holdout set tutun.
pass@k ile pass^k arasındaki fark nedir?
Pass@k, k denemeden en az birinin başarılı olup olmadığını sorar. Birden fazla denemenin kabul edilebilir olduğu workflow'lara uygundur. Pass^k, tüm k denemelerin başarılı olup olmadığını sorar. Consistency'nin önemli olduğu customer-facing veya side-effecting workflow'lara uygundur.
Bir LLM'i başka bir LLM'i grade etmek için kullanmalı mısınız?
Yalnızca deterministic check'ler quality criterion'ı ifade edemediğinde. Specific bir rubric yazın, judge'ı expert label'larla karşılaştırın, anlaşmazlıkları inceleyin ve deterministic hard gate'leri judge'ın dışında tutun.
Kazanan modeli cost mu yoksa quality mi belirlemeli?
Önce quality ve safety gate'lerini uygulayın. Geçen modeller arasında başarılı task başına cost'u ve tail latency'yi karşılaştırın. Düşük token fiyatı retry veya recovery work'ünü telafi etmez.
Karar kuralı
Göndereceğiniz workflow'u benchmark edin. Önem verdiğiniz state'i grade edin. Variance'ı ortaya çıkarmaya yetecek kadar task'ı tekrarlayın. Failure'ları inceleyin. Ardından her hard gate'i ve gerekli reliability threshold'u geçen en düşük maliyetli modeli seçin.
Leaderboard'lar neyi test edeceğinize karar vermenize yardımcı olur. Production trafiğini neyin hak ettiğine task suite'iniz karar verir.