LLM Güven Skoru: Güvenmeden Önce Kalibre Edin

Bir LLM güven skoru ancak neyi tahmin ettiğini tanımladıktan, ölçüm protokolünü sabit tuttuktan ve kendi görevinizden elde edilen etiketli sonuçlarla test ettikten sonra kullanışlıdır. Modelin kendi bildirdiği “%90”, bir token log olasılığı ve on örnekten dokuzunun eşleşmesi, birbirinden farklı üç sinyaldir. Bunların hiçbiri bir yanıtın doğru olduğuna dair evrensel 0.9 olasılığı vermez.

Hedef kitle: Orta seviye — bir LLM’in yanıt vermesine, işi yükseltmesine veya çekimser kalmasına ihtiyaç duyan ürün mühendisleri, veri ekipleri ve teknik liderler.

Ham sayıyı bir karar değil, özellik olarak ele alın. Bunu ayrılmış bir veri kümesi üzerinde kalibre edin, düşük skorlu yanıtları reddettikçe hatanın nasıl değiştiğini inceleyin ve para hareket ettirebilecek, verileri açığa çıkarabilecek veya production durumunu değiştirebilecek her eylemin etrafına deterministik kontroller koyun.

Bir LLM güven skoru neyi ölçer?

Bir LLM güven skoru, bir model çıktısının güvenilirliğini sıralamak veya tahmin etmek amacıyla kullanılan sayısal bir sinyaldir. Anlamı, nasıl üretildiğine bağlıdır.

Bir skorun kalibre edilmiş bir olasılık gibi davranabilmesi için 0.8 atanan çıktıların aynı tür işlerde yaklaşık %80 oranında doğru olması gerekir. Bu ifade dört ayrıntı gerektirir:

Bu ayrıntılardan herhangi birini çıkarırsanız “0.8 güven” belirsiz hale gelir. Bu, modelin ifadeyi olası bulduğu, kendini tutarlı biçimde tekrarladığı, bir sayı yazma talimatını izlediği veya bir yanıtı alternatiflerin üzerinde sıraladığı anlamına gelebilir. Bu özellikler doğrulukla korelasyon gösterebilir. Ancak doğruluğun kendisi değildir.

Kalibrasyon, ayrıştırmadan da farklıdır. Bir skor, doğru yanıtlar genellikle yanlış yanıtların üzerinde sıralandığında iyi ayrıştırma özelliğine sahiptir. Sayısal değerler gözlemlenen frekanslarla eşleştiğinde ise iyi kalibrasyona sahiptir. Bir sistem sıralama için yararlı olabilirken yüzdeleri yanlış olabilir veya doğru ve yanlış yanıtları ayırmada başarısız olurken ortalama olarak makul bir kalibrasyon gösterebilir.

Yaygın olarak güven olarak adlandırılan üç sinyal

Bunlar arasında seçim yapmak bir mühendislik kararıdır. Bunları birleştirmek yardımcı olabilir, ancak bir ensemble’ın da hedef görev üzerinde değerlendirilmesi gerekir.

Sözlü güven, elde edilen bir yanıttır

En kolay yaklaşım şunu sormaktır:

text Return your answer and the probability that it is correct from 0 to 1.

Bu yaklaşım neredeyse her modelle çalışır. Ancak güven değerini üretimin bir parçası haline getirir. Prompt ifadeleri, yanıt ölçeği, sağlanan bağlam ve modelin yanıtı kendisinin üretip üretmediği sonucu değiştirebilir.

2026 tarihli bir çalışma, dört soru-cevap benchmark’ında üç açık 7–8B temel/instruction-tuned model ailesini test etti. Araştırmacılar, hangi yanıtın puanlandığını, token skorunu hangi yanıt token’larının sağladığını ve bu token’lardan önce hangi bağlamın geldiğini değiştirirken sözlü güven prompt’unu sabit tuttu. Koşullandırma bağlamının değiştirilmesi, kalibrasyon tahmincisinin değiştirilmesinden daha fazla sözlü ve token kalibrasyonu karşılaştırmasını etkiledi ve hem ECE hem de Brier skoru karşılaştırmalarında 12 instruction-tuned ayarın 9’unda hangi sinyalin daha iyi göründüğünü değiştirdi. Modeller sağlanan yanıtları puanladığında, makul yanlış yanıtlar doğru sağlanan yanıtlarla neredeyse aynı sözlü güveni aldı. Bu nedenle yazarlar her iki sinyali de belirsizliğin doğrudan okumaları değil, protokole bağlı davranışsal ölçümler olarak tanımlıyor (Kim and Kang, 2026).

Bu sonuç her sözlü skorun işe yaramaz olduğunu kanıtlamaz. “Güveniniz konusunda dürüst olun” gibi bir prompt’un kalibrasyon kümesinin yerini neden alamayacağını gösterir.

Token logprobları sonraki token olasılığını ölçer

Bir log olasılığı, bir token’ın modelin koşullu üretim dağılımı altında ne kadar olası olduğunu kaydeder. OpenAI dokümantasyonu bunu, önceki bağlam verildiğinde belirli bir konumdaki token’ın olasılığı olarak tanımlar; dizi log olasılıkları puanlama veya sıralama için toplanabilir (OpenAI Cookbook). Google’ın GenerateContent yanıtı da seçilen API ve model desteklediğinde ortalama aday log olasılıklarını ve token düzeyinde logprob sonuçlarını sunar (Gemini API reference).

Bu, `approve` ve `reject` gibi kapalı bir seçim için değerlidir. İzin verilen etiketlere atanan olasılık kütlesini toplayabilir ve ardından bu skoru kalibre edebilirsiniz. Uzun, serbest biçimli bir yanıtı yorumlamak çok daha zordur. Tokenization, yanıt uzunluğu, paraphrase kullanımı ve koşullandırma prompt’u dizi olasılığını etkiler.

Akıcı bir yanlış ifade yüksek olasılığa sahip olabilir. Doğru ancak alışılmadık bir isim düşük olasılığa sahip olabilir. Skor “Bu token dizisi burada ne kadar bekleniyordu?” sorusunu yanıtlar. “İddia doğru mu?” sorusunu otomatik olarak yanıtlamaz.

Tekrarlanan örnekleme anlaşmayı ölçer

Modelden birkaç kez örnekleme yapmak black-box bir tutarlılık sinyali sağlar. On yanıtın sekizi aynı yanıtı ifade ediyorsa ampirik anlaşma skoru 0.8’dir. Serbest biçimli yanıtlar genellikle paraphrase’lerin aynı yanıt sayılması için anlamsal kümelendirme gerektirir.

Bu sinyal çoğu zaman tek bir öz-bildirimden daha fazla bilgi taşır, ancak iki maliyeti vardır. İlk olarak, batching, caching veya daha kısa prompt’lar hesabı değiştirmeden önce on üretim, yaklaşık on kat daha fazla çıktı çağrısı gerektirir. İkinci olarak, model aynı yanılgıyı tekrarladığında anlaşma kendinden emin biçimde yanlış olabilir.

Yakın tarihli araştırmalar her iki noktayı da görünür kılıyor. Temmuz 2026 tarihli bir çalışma, kısa olgusal ve multi-hop soru-cevap görevlerinde sözlü güveni, logit tabanlı bir doğrulayıcıyı ve SliCK adlı örnekleme tabanlı bir yöntemi karşılaştırdı. Bu ortamda SliCK, diğer iki yönteme göre daha düşük kalibrasyon hatası ve doğru-yanlış ayrımında daha iyi sıralama elde etti. Yine de değerlendirilen vakaların %31’inde entailment tabanlı bir olasılık tutarlılığı testini ihlal etti. Çalışma, bir LLM judge tarafından yapılan anlamsal kümelendirmeye, kısa yanıt benchmark’larına, bir ana model ile daha küçük çapraz model alt kümelerine ve örnekleme frekansının inancı yansıttığı varsayımına dayanıyordu (Matta, Naphade, and Zou, 2026).

Pratik yorum “örnekleme güven sorununu çözer” ifadesinden daha sınırlıdır. Anlaşma yararlı bir ham sinyaldir. Sonuçlarla karşılaştırılması gereken bir sinyal olmaya devam eder.

*Production eşiği, doğrudan model çıktısından sonra değil, göreve özgü etiketler ve kalibrasyon kontrollerinden sonra belirlenmelidir.*

Makul görünen bir güven sayısı neden yine de yanıltabilir?

Yakın tarihli üç sonuç, ekiplerin bir LLM yanıtının yanındaki yüzdeyi okuma biçimini değiştirmelidir.

Doğruluk ve kalibrasyon birbirinden bağımsız değişebilir

ConfidenceBench, uzamsal akıl yürütme, yüksek hassasiyetli matematik, kelime arama ve bilinemeyen sorular alanlarında 200 özel İngilizce çoktan seçmeli soru üzerinde 15 frontier modelin prompt’lanmış olasılıklarını değerlendirdi. Her model seti üç kez yanıtladı. Benchmark, bildirilen olasılık ile ikili sonuç arasındaki karesel mesafeyi cezalandıran Brier skorunu kullandı.

Modellerin kalibrasyona göre sıralaması, doğruluğa göre sıralamayı basitçe tekrarlamadı. Yazarlar en iyi Brier skorunun 0.103 olduğunu, bazı değerlendirilen sistemlerin ise kalibre edilmiş dört seçenekli rastgelelik baseline’ı olan 0.1875’ten daha kötü skor aldığını bildiriyor. Benchmark kasıtlı olarak küçük, özel, yalnızca İngilizce ve çoktan seçmelidir. Sözlü skorları instruction following ve prompt çerçevelemesini yansıtabilir; bu nedenle sayılar uzun biçimli veya çok turlu çalışmalara genellenmemelidir (ffrench-Constant et al., 2026).

Kalibrasyonu doğrudan ölçün. Bir modelin genel benchmark doğruluğundan kalibrasyon çıkarımı yapmayın.

Ölçüm protokolü sonucu değiştirebilir

Skor belirli bir pipeline’a bağlıdır. Bir ekip prompt’u, model snapshot’ını, yanıt formatını, aday etiketleri, context window’u, temperature’ı veya logprob toplulaştırmasını değiştirirse ölçüm aracını değiştirmiş olur.

Bu seçimleri her değerlendirme sonucuyla birlikte kaydedin. Ham code-agent activity metrics de güvenilirlik hakkında bir şey söylemeden önce sistem ve değerlendirme bağlamına ihtiyaç duyar. Prompt veya model değişirse yeniden kalibrasyon, isteğe bağlı bir temizlik değil, bir release kontrolüdür.

Kalibre edilmiş bir skor yine de bir dilimde başarısız olabilir

Bir ortalama, tek bir dilde, üründe, müşteri segmentinde, belge türünde veya yanıt uzunluğunda yaşanan başarısızlığı gizleyebilir. Yaygın faturalandırma soruları test kümesine hâkim olduğu için bir destek sınıflandırıcısı genel olarak kalibre edilmiş görünebilir; nadir güvenlik taleplerinde ise aşırı güvenli kalabilir.

Bir sonuca destek olacak kadar örnek içeren dilimleri her zaman inceleyin. Örneklerin seyrek olduğu yerlerde belirsizliği raporlayın; gürültülü bir oranı gerçek gibi ele almayın.

Tekrarlanabilir bir LLM güven kalibrasyonu iş akışı

Aşağıdaki iş akışı kasıtlı olarak küçüktür. Daha büyük bir belirsizlik çerçevesini benimsemeden önce çalıştırılabilir.

1. Olayı ve eylemi tanımlayın

Şu şablonu tamamlayan tek bir cümle yazın:

Örnekler:

“Yanıt iyi” gibi olaylardan kaçının. Bunlar tutarlı biçimde etiketlenemez.

Geri döndürülemez etkileri olan eylemlerde güven, yetkilendirmenin yerini almamalıdır. Bir model bir yol seçmeye yardımcı olabilir, ancak AI agent permissions yine de izin verilen kaynakları, argümanları, onay kurallarını ve kayıtları uygulamalıdır.

2. Göreve özgü bir holdout set oluşturun

Prompt’u veya kalibrasyon eşlemesini ayarlamak için kullanılmamış, temsili girdiler toplayın. Şunları dahil edin:

Mümkün olduğunda doğruluğu deterministik bir doğrulayıcıyla etiketleyin. Öznel görevlerde yazılı bir rubrik ve hakemlik kullanın. Bir güven skoru, sonuç etiketlerinden daha savunulabilir olamaz.

Önce belirgin yanlış kalibrasyonu ortaya çıkaracak kadar veriyle başlayın, ardından önemli dilimler ve eşikler çevresinde genişletin. Küçük bir benchmark keşfe yön verebilir, ancak yüksek riskli bir production eşiğini gerekçelendiremez.

3. Protokolü değiştirmeden ham sinyali yakalayın

Şunları saklayın:

Değerlendirmeden önce yuvarlama yapmayın. Yalnızca `0.7`, `0.8` ve `0.9` üreten bir model, hassas bir olasılık ölçümü olarak sunulmamalı; üç kaba bucket olarak değerlendirilmelidir.

4. Brier skorunu ve güvenilirlik tablosunu hesaplayın

İkili doğruluk için Brier skoru şöyledir:

text mean((confidence - outcome)²)

Düşük olması daha iyidir, ancak sayının bir baseline’a ve karşılaştırılabilir bir veri kümesine ihtiyacı vardır. Güvenilirlik tablosu hatayı görmeyi kolaylaştırır: benzer skorları gruplayın, ardından her grubun ortalama skorunu gözlemlenen doğrulukla karşılaştırın.

Bu bağımlılıksız Python script’i bir CSV dosyasından `id,score,correct` okur:

python import csv

with open("predictions.csv", newline="") as source: rows = [ (float(row["score"]), int(row["correct"])) for row in csv.DictReader(source) ]

if not rows: raise SystemExit("predictions.csv has no rows")

brier = sum((score - correct) ** 2 for score, correct in rows) / len(rows) print(f"Brier score: {brier:.4f}")

bin_count = 10 bins = [[] for _ in range(bin_count)]

for score, correct in rows: if not 0 <= score <= 1 or correct not in (0, 1): raise ValueError("score must be 0..1 and correct must be 0 or 1") index = min(int(score * bin_count), bin_count - 1) bins[index].append((score, correct))

print("range,count,mean_score,accuracy,gap") for index, values in enumerate(bins): if not values: continue mean_score = sum(score for score, _ in values) / len(values) accuracy = sum(correct for _, correct in values) / len(values) lower = index / bin_count upper = (index + 1) / bin_count print( f"{lower:.1f}-{upper:.1f},{len(values)}," f"{mean_score:.3f},{accuracy:.3f},{mean_score - accuracy:+.3f}" )

Tablo betimleyicidir. Özellikle küçük kümelerde bucket sınırları ECE tarzı özetleri değiştirebilir. Tek bir grafiği optimize etmek yerine Brier skorunu, güvenilirlik görünümünü ve eylem odaklı bir metriği birlikte tutun.

5. Eşikleri risk ve kapsama göre seçin

0.8 eşiğinin evrensel bir anlamı yoktur. Sistemin yalnızca her aday eşikte veya üzerinde çıktıları kabul etmesi durumunda ne olduğunu değerlendirin:

python print("threshold,coverage,accepted_accuracy") for threshold in (0.5, 0.6, 0.7, 0.8, 0.9): accepted = [ correct for score, correct in rows if score >= threshold ] coverage = len(accepted) / len(rows) accuracy = sum(accepted) / len(accepted) if accepted else float("nan") print(f"{threshold:.1f},{coverage:.3f},{accuracy:.3f}")

Bu, temel bir risk–kapsama görünümü oluşturur. Eşiği yükseltmek kabul edilen vakalar arasındaki hataları azaltabilir, ancak daha fazla işi fallback işlemine gönderir. Eşiği yanlış kabul, yanlış ret, inceleme, gecikme ve kullanıcı zararı maliyetlerinden hareketle seçin.

Ürün üç sonucu desteklediğinde en azından şunları kullanın:

6. Drift’i ve protokol değişikliklerini test edin

Holdout’u şu durumlardan sonra çalıştırın:

Tekrarlanan örnekleme ve daha derin reasoning de compute ekler. Bu ödünleşim değerlendirmeye dahil edilmelidir: daha fazla reasoning token satın almanın her zaman değerli olduğunu varsaymak yerine hata azalmasını gecikme ve token maliyetiyle karşılaştırın.

Hangi güven yöntemini kullanmalısınız?

Open-source kütüphaneler uygulama işini azaltabilir. Örneğin UQLM; black-box tutarlılık, white-box token-probability, judge, ensemble ve long-text scorer’ları sunar. Dokümantasyonu gecikme ve erişim ödünleşimlerini de açıkça belirtir: tutarlılık yöntemleri daha fazla çağrı gerektirirken white-box yöntemleri logproblara ihtiyaç duyar (UQLM documentation). Repository, Temmuz 2026’da v0.6.4 düzeltmeleri de dahil olmak üzere hâlâ release alıyordu; bu, tek başına lifetime star sayısından daha güçlü bir bakım sinyalidir (UQLM v0.6.4).

Bir kütüphane estimator’lar sağlar. Bir eşiği savunulabilir kılan etiketleri, görev tanımını, risk toleransını veya production monitoring’i sağlamaz.

Mevcut araştırmalar neyi ortaya koymuyor?

Alıntılanan çalışmalar, tüm LLM uygulamalarında tek bir yöntemin kazandığını kanıtlamaz.

Araştırma aday sinyalleri belirleyebilir. Eksiksiz sistemi, gerçekten gerçekleştireceği iş üzerinde doğrulayın.

Sık sorulan sorular

LLM güven skorları doğru mudur?

Bazen doğrulukla korelasyon gösterirler, ancak doğruluk modele, göreve, puanlama yöntemine, prompt’a ve değerlendirme dağılımına bağlıdır. Kalibre edilmemiş bir skoru sıralama özelliği olarak ele alın. Olasılık olarak yorumlamadan önce etiketli sonuçlarla test edin.

Token logprobları güvenle aynı şey midir?

Hayır. Bir token logprobu, bağlamı verildiğinde token’ın koşullu olasılığıdır. Özellikle kapalı etiketli görevlerde bir güven tahminini destekleyebilir, ancak serbest biçimli bir yanıtın olgusal olarak doğru olma olasılığı değildir.

Hangi LLM güven eşiğini kullanmalıyım?

Evrensel bir eşik yoktur. Yanlış kabul, manuel inceleme, çekimser kalma ve kaçırılan otomasyon maliyetlerini yansıtan, ayrılmış bir risk–kapsama analizinden hareketle seçim yapın. Model, prompt veya veri dağılımı değişikliklerinden sonra yeniden doğrulayın.

İddia kontrolleri

Kaynaklar