Mimari ve çalışma modeli
LLM değerlendirmesi tek bir ortalama puan değildir. Görev başarısı, doğruluk, kaynak kullanımı, güvenlik, üslup, gecikme ve maliyet ayrı ölçülür. Veri seti kullanım senaryosu, risk katmanı, dil, uzunluk ve zor örnekleri temsil eder; üretim olayları sürekli regresyon setine dönüşür.
Deterministik denetimler şema, alıntı, yasak terim ve araç parametresi gibi kuralları ölçer. İnsan değerlendirmesi belirsiz kalite ve iş uygunluğunu kalibre eder. Model-as-judge ölçek sağlar fakat hakem modeli, rubrik ve örnek sırası yanlılık yaratabilir; küçük bir insan etiketli kontrol setiyle uyumu izlenir.
Sürüm karşılaştırması eşleştirilmiş örneklerle yapılır. Yalnız yeni modelin genel ortalaması değil, eskiye göre kaybedilen örnekler ve yüksek risk dilimleri incelenir. İstatistiksel belirsizlik ve tekrar varyansı raporlanır; kabul kapısı kalite artarken güvenlik veya p95 gecikmenin bozulmasına izin vermez.
- 1Sürüm ve risk tabakalı veri seti
- 2Deterministik, insan ve model hakemleri
- 3Eşleştirilmiş regresyon analizi
- 4Canary üretim ve geri besleme
Tasarım parametreleri
- Altın set yapısı
- Her kayıt için girdi, beklenen davranış, kaynak, risk etiketi ve rubrik sürümü saklayın.
- Eşleştirilmiş karşılaştırma
- Aynı girdileri aday ve mevcut sürümde çalıştırıp win/loss/tie ile kritik regresyonları ölçün.
- Hakem kalibrasyonu
- İnsan etiketli örneklerde judge uyumu, sınıf bazlı hata ve kararsızlık oranını izleyin.
- Kabul bütçesi
- Kalite, güvenlik, p95 TTFT, token maliyeti ve hata oranına ayrı eşik koyun.
Hesap ve uygulama örneği
600 örnekte aday 330 kez kazanıyor, 210 eşit ve 60 kaybediyorsa eşitler dışındaki kazanma oranı %84,6'dır. Ancak 40 bordro sorusunun 6'sında mevcut sürümden kötü ise kritik dilim regresyonu %15'tir ve genel sonuç başarılı görünse bile dağıtım durdurulur.
Judge ile insan arasındaki Cohen kappa 0,42 ise hakem kararı tek başına kapı olmamalıdır. Rubrik örnekleri netleştirilir, çift kör insan örneklemesi artırılır ve judge sürümü eval manifestinde sabitlenir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
llm-eval run --candidate release-42 --baseline release-41 --dataset support-golden-v7
llm-eval gate --min-win-rate 0.60 --max-critical-regression 0 --max-ttft-p95-ms 900Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Offline puan yüksek, kullanıcı memnuniyeti düşük | Eval seti gerçek niyeti veya zorluğu temsil etmiyor. | Üretimden tabakalı örnek alıp eksik niyetleri ve dilimleri karşılaştırın. |
| Judge sürekli aday modeli seçiyor | Pozisyon, uzunluk veya model ailesi yanlılığı vardır. | Cevap sırasını rastgeleleştirip insan etiketli kalibrasyon setinde analiz edin. |
| Sonuçlar çalıştırmalar arasında oynuyor | Sampling ayarı, model aliası veya dış kaynak değişiyor. | Model sürümü, temperature/seed, retrieval snapshot ve araç mock'larını sabitleyin. |
Kabul ve doğrulama kontrolleri
- Veri setini kullanım amacı ve risk dilimleriyle sürümleyin.
- Deterministik kontrolleri model hakeminden önce çalıştırın.
- Judge rubriğini insan etiketli kontrol setiyle kalibre edin.
- Adayı mevcut sürümle eşleştirilmiş örneklerde karşılaştırın.
- Kalite yanında güvenlik, gecikme ve maliyet eşiklerini zorunlu kılın.
- Canary sonuçlarını olay ve kullanıcı geri bildirimiyle regresyon setine ekleyin.
İlgili kavramlar
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.