Yapay zekâ özelliklerini değerlendirmek: sürümden önce ölçülebilir kalite

Yapay zekâ destekli bir özelliği geliştirmek çoğu zaman etkileyici birkaç örnekle başlar. Yeni prompt bir demoda daha iyi özet çıkarır, başka bir model daha akıcı yanıt verir veya retrieval ayarı daha fazla kaynak getirir. Fakat bu gözlemler tek başına üretim kararı için yeterli değildir. Bir örnekte daha iyi çalışan değişiklik, başka bir kullanıcı sorgusunda doğruluğu, maliyeti, gecikmeyi ya da güvenlik sınırını kötüleştirebilir.

Bu yüzden yapay zekâ özelliğini yalnızca model çağrısı olarak değil, ölçülebilir bir ürün davranışı olarak ele almak gerekir. Değerlendirme hattının amacı “model iyi mi?” sorusuna genel bir yanıt vermek değildir. Daha yararlı soru şudur: Bu sürüm, kullanıcıların önemli görevlerinde önceki sürümden daha güvenilir mi ve başarısız olduğunda kabul edilebilir biçimde mi davranıyor?

Önce ürün kararını yazın

Değerlendirme seti toplamadan önce özelliğin neyi başarması gerektiği netleştirilmelidir. “Yardımcı yanıt üretmek” çok geniştir. Bunun yerine somut bir görev tanımlayın: toplantı transkriptinden aksiyon maddelerini çıkarmak, uzun bir belgeyi belirli başlıklarda özetlemek, müşteri talebini doğru kategoriye yönlendirmek ya da kaynaklı bir araştırma sorusuna yanıt vermek.

Her görev için başarı ve başarısızlık ölçütleri farklıdır. Aksiyon maddesi çıkaran özellikte yanlış sahip atamak, bir maddenin eksik kalmasından daha maliyetli olabilir. Belge özetinde kaynakta olmayan ayrıntı eklemek, daha kısa bir özetten daha kötü bir sonuçtur. Sınıflandırmada belirsiz girdiyi yanlış sınıfa zorlamak yerine “inceleme gerekli” sonucunu vermek daha doğru olabilir.

Bu kararlar, metrik seçiminden önce gelir. Bir sayısal skor yalnızca ürün riskini temsil edebildiği ölçüde faydalıdır.

Küçük ama temsil gücü olan bir set hazırlayın

İlk değerlendirme setinin binlerce örneğe ihtiyacı yoktur. Yirmi ila elli iyi seçilmiş örnek, rastgele yüzlerce örnekten daha faydalı olabilir. Setin günlük kullanıcı davranışını ve riskli kenar durumları birlikte içermesi gerekir:

• sık gelen, normal girdiler,
• kısa, uzun ve kötü biçimlenmiş girdiler,
• belirsiz ya da birden fazla yoruma açık istekler,
• eksik bağlam veya hiçbir doğru yanıt olmayan durumlar,
• hassas içerik, yetki sınırı veya reddedilmesi gereken talepler,
• daha önce kullanıcı desteğine veya hataya yol açmış örnekler.

Her örneğin mümkünse beklenen sonucu, kabul edilebilir varyasyonları ve değerlendirme notu bulunmalıdır. Serbest metin görevlerinde tek bir “altın yanıt” her zaman doğru yaklaşım değildir. Bunun yerine gerekli olgular, yasaklanmış iddialar, beklenen ton veya kaynak zorunluluğu gibi kontrol listeleri tanımlanabilir.

Seti sürüm kontrolünde tutmak önemlidir. Böylece hangi örneğin ne zaman eklendiği, hangi üretim hatasının yeni test oluşturduğu ve sonuçların hangi veri üzerinde karşılaştırıldığı görünür olur.

Çıktıyı birden fazla boyutta inceleyin

Tek bir puan, yapay zekâ davranışının tamamını açıklamaz. Değerlendirme en az şu boyutları ayırmalıdır:

• Görev başarısı: Yanıt istenen işi gerçekten tamamlıyor mu?
• Doğruluk ve dayanak: Söylenenler girişe veya sağlanan kaynağa uyuyor mu?
• Biçim: İstenen JSON, tablo, alan yapısı veya dil kuralı korunuyor mu?
• Güvenlik: Özellik yetki, gizlilik ve içerik sınırlarına uyuyor mu?
• Kullanılabilirlik: Yanıt anlaşılır, uygun uzunlukta ve eyleme geçirilebilir mi?
• Maliyet ve gecikme: Sonuç kabul edilebilir sürede ve bütçede mi oluşuyor?

Örneğin model yanıtı dilbilgisel olarak mükemmel olabilir ama istenen şemaya uymuyorsa otomasyon akışını bozabilir. Ya da kaynaklı bir yanıt biçimsel olarak iyi görünüp hiç dayanak göstermiyorsa kullanıcı açısından güvenilir değildir. Puanları ayrı görmek, hangi iyileştirmenin hangi bedelle geldiğini anlamayı sağlar.

Otomatik kontrol ile insan incelemesini birleştirin

Bazı ölçütler kodla güvenilir biçimde denetlenebilir. JSON şeması geçerli mi, zorunlu alan var mı, kaynak kimliği döndü mü, yanıt izin verilen uzunlukta mı, kişisel veri deseni var mı? Bu kontroller hızlıdır ve her sürümde çalışmalıdır.

Ancak doğruluk, fayda ve ton gibi nitelikler çoğu zaman insan değerlendirmesi gerektirir. İnsan incelemesini rastgele örneklerle sınırlamak yerine, riskli ve skor değişimi yüksek örneklere odaklamak verimlidir. İnceleyenler için açık bir rubrik gerekir; aksi halde “bence daha iyi” yorumu sürümler arasında karşılaştırılamaz.

Başka bir modelle puanlama yapmak yardımcı bir sinyal olabilir, fakat nihai gerçek olarak görülmemelidir. Puanlayıcı model de hatalı, önyargılı veya biçime fazla duyarlı olabilir. İnsan doğrulaması ve belirli hatalara yönelik kural kontrolleri bu riski dengeler.

Sürümün tüm girdilerini kaydedin

Sonuç değiştiğinde yalnızca model adını bilmek yetmez. Değerlendirme kaydı; model ve sağlayıcı sürümü, prompt sürümü, sistem talimatı, araç tanımları, retrieval ayarları, sıcaklık benzeri parametreler ve değerlendirme seti sürümünü içermelidir.

Bu bilgi, “neden dün geçen test bugün başarısız?” sorusunu araştırmayı mümkün kılar. Aynı zamanda geri dönüş kararını kolaylaştırır. Yeni prompt üretimde sorun çıkarırsa, yalnızca kodu değil; bilinen iyi davranış üreten tam yapılandırmayı geri almak gerekir.

İstemciden gelen gerçek kullanıcı içeriğini saklamak gerekiyorsa gizlilik politikası, maskeleme ve saklama süresi değerlendirme tasarımının parçası olmalıdır. Kalite ölçmek için gereğinden fazla kişisel veri toplamak doğru bir takas değildir.

Eşik yerine değişim ve hata bütçesi izleyin

Bir sürümün ortalama puanının yüksek olması, üretime hazır olduğu anlamına gelmez. Kritik bir hata kategorisinde küçük bir kötüleşme kabul edilemez olabilir. Bu nedenle genel puanın yanında “kaynağa dayanmayan iddia”, “geçersiz yapılandırılmış çıktı” veya “reddedilmesi gereken talebe yanıt verme” gibi kırmızı çizgiler tanımlanmalıdır.

Karar genellikle iki sürüm arasındaki farkla verilir. Yeni sürüm hangi örneklerde iyileşti, hangilerinde geriledi, maliyet ve gecikme ne kadar değişti? Bu karşılaştırma, model değişiminin yalnızca etkileyici örneklerini değil, kayıplarını da görünür kılar.

Üretimde aşamalı açılış, değerlendirme setinin yerini tutmaz; onu tamamlar. Küçük bir kullanıcı grubunda izlenen hata oranı, geri bildirim ve güvenlik olayı gerçek davranış hakkında ek kanıt sağlar. Açılış için geri alma koşulları önceden belirlenmelidir.

İyi bir değerlendirme hattı büyük bir platformla başlamak zorunda değildir. Versiyonlanmış küçük bir örnek seti, otomatik birkaç kontrol, net bir insan rubriği ve sürümler arası karşılaştırma bile prompt denemelerini tekrarlanabilir mühendislik kararlarına dönüştürür. Yapay zekâ özelliği ancak bu şekilde “etkileyici demo” olmaktan çıkar ve güvenle geliştirilebilen bir ürün yeteneğine dönüşür.