LLM değerlendirmeleri, gerçekte kullanıma sunduğunuz yolu izlemelidir

Yönlendirme, veri alma, yedekleme, doğrulama ve devretme işlemlerini bir arada değerlendirin; ardından arızaların kaynağını belirlemek için tanılama kontrollerinden yararlanın.

Bir model, bir not defterinde iyi performans gösterirken, ürün yine de yetersiz yanıtlar verebilir. Üretim uygulaması, soruyu yeniden yazabilir, farklı bir sağlayıcı seçebilir, farklı metin parçaları alabilir veya yanıt oluşturulduktan sonra onu reddedebilir.

Ana değerlendirmenin, gerçek bir isteğin kullandığıyla aynı uygulama yolundan girmesini istiyorum. Aksi takdirde, müşterinin tek başına asla karşılaşmayacağı bir bileşeni onaylayabilir.

İki aşamalı değerlendirme uygulayın

Uçtan uca test senaryoları, ürünün doğru şekilde çalışıp çalışmadığını gösterir. Teşhis senaryoları ise ürünün neden doğru çalışmadığını belirlemeye yardımcı olur. Her ikisine de ihtiyacım var.

Bir destek asistanı için uçtan uca süreç, kiracı politikası, model yönlendirme, veri alma, yanıt oluşturma, kanıt doğrulama ve devretme aşamalarını içerebilir. Bu sınırların herhangi birinde meydana gelen bir gerileme, nihai sonuçta görülür olmalıdır.

Teşhis kontrolleri, geri getirilen kaynakları, yeniden yazılan sorguları, çıkarılan iddiaları ve sağlayıcı adaptörünün davranışını ayrı ayrı inceler. Bunlar araştırma amacıyla yararlıdır, ancak ürün düzeyindeki sonucu bir dizi bileşen başarı oranıyla değiştirmezdim.

Çıktıyı okumadan önce beklentilerinizi yazın

Her değerlendirme vakasında müşterinin niyeti, mevcut kanıtlar, izin verilen iddialar, yasaklanmış iddialar ve beklenen eylem belirlenmelidir. Bazı vakalar, açıklayıcı bir soru veya bir insana devredilme ile sonuçlanmalıdır.

Belgelerin içine sıradan sorular, dayanağı olmayan sorular, belirsiz referanslar, güncelliğini yitirmiş içerikler, dil değişiklikleri ve karşıt talimatlar ekliyorum. Dağıtım, canlı trafiğin kusursuz bir kopyasıymış gibi görünmeye çalışmadan ürünün risklerini yansıtmalıdır.

“İadelerle ilgili iyi cevap” gibi bir vaka açıklaması, öznel bir değerlendirme yapılmasına yol açar. “Hangi ürünün sipariş edildiğini sormalı; uygunluk vaadinde bulunmamalı” ifadesi ise değerlendiriciye tutarlı bir şekilde uygulayabileceği bir karar kriteri sunar.

Yararlı olduğu durumlarda otomatik jüri sistemini kullanın

Deterministik kontroller, kesin tanımlayıcılar, izin verilen bağlantılar, yasaklanmış iddialar ve zorunlu yapılandırılmış alanlar açısından yararlıdır. Anlamsal doğruluk ve yanıtın müşteriye yardımcı olup olmadığı açısından insan tarafından yapılan inceleme hâlâ önemini korumaktadır.

Model tabanlı bir değerlendirici, inceleme yükünü azaltabilir; ancak ben, bu modelin verdiği puanı da kalibrasyona ihtiyaç duyan bir başka ölçüt olarak değerlendiriyorum. Sadece ortalama uyum düzeyini ölçmek yerine, ilgili vaka türleri genelinde bu puanı insan tarafından verilen etiketlerle karşılaştırıyor ve uyuşmazlıkları inceliyorum.

Değerlendirme kriterleri, metin mükemmel olsa bile, dayanağı olmayan, kendinden emin bir cevabı olumsuz değerlendirmelidir. Ayrıca, gereksiz reddetmeyi bir sistem hatası olarak kabul etmelidir. Yararlılık içermeyen ihtiyatlılığı ödüllendiren bir jüri üyesi, hiçbir zaman cevap vermeyen bir sistemi seçebilir.

Test setini tekrar tekrar ayarlamaktan koruyun

İş akışını iyileştirmek için kullanılan örnekleri, daha sonra kontrol edilmek üzere ayrılan örneklerden ayırıyorum. Her hata anında ayarlama döngüsünün bir parçası haline gelirse, aynı örnekler üzerindeki performans daha az bilgi verici hale gelir.

Küçük değerlendirme kümeleri yine de değerli olabilir, ancak sonuçları paydaları ve sınırları ile birlikte bildirilmelidir. Birkaç negatif vaka üzerinde elde edilen kusursuz bir sonuç, dayanağı olmayan cevapların elendiğinin kanıtı değildir.

Tekrar tekrar yapılan simülasyonlar, önemli noktalardaki değişkenliği ortaya çıkarabilir. Her deterministik sınırı defalarca yeniden simüle etmeme gerek yok; ancak kararsız üretim davranışları için birden fazla uygun örnek elde etmek gerekir.

Aynı kanıt üzerindeki değişiklikleri karşılaştırın

Bir arama değişikliği söz konusu olduğunda, aynı vakalar ve kaynak anlık görüntüsü üzerinde eski ve önerilen iş akışlarını karşılaştırıyorum. Kod sürümünü, komut satırı sürümünü, model yapılandırmasını ve ilgili metin kümesi sürümünü kaydediyorum.

Değerlendirme tablomda, desteklenen yanıtlar, desteklenmeyen yanıtlar, gereksiz çekimserlikler, başarısız aktarımlar, gecikme süresi ve maliyet ayrı ayrı ele alınmaktadır. Tek bir karma puan, bu boyutlar arasındaki zararlı bir ödünleşimi gizleyebilir.

Yayınlama kararında, dağıtımı engelleyen hataların hangileri olduğu belirtilmelidir. Kiracılar arası bilgi sızıntısı veya yetkisiz eylemler, garip ama doğru bir cümleden ziyade farklı bir denetim aşamasına tabi tutulmalıdır.

Dağıtımdan sonra, incelenen üretim hatalarını yeni vakalara dönüştürür ve gelecekteki değişiklikler için ayrı bir yedek tutarım. Böylece değerlendirme, uygulamanın gerçekte çalıştığı yola dayanan, ürünün yükümlülüklerine ilişkin sürekli güncellenen bir açıklama haline gelir.

25 Eylül 2026 tarihinde güncellenmiştir.