Bir talimatı değiştirdiniz ve çıkan yanıt daha güzel göründü. Peki aynı değişiklik diğer işlerde de yararlı mı? Tek örnek bu soruyu yanıtlamaz. Küçük bir değerlendirme seti, yapay zekâ sisteminin hangi koşullarda iyi çalıştığını ve nerede hata yaptığını daha düzenli görmenizi sağlar.
Gerçek kullanım örnekleri toplayın
Destek mesajı sınıflandıran bir araç düşünün. Yalnızca açıkça yazılmış örnekleri seçerseniz sistem olduğundan başarılı görünebilir. Yazım hatalı, iki konuyu birlikte içeren veya eksik bilgi veren mesajlar da gerçek kullanımın parçasıdır. Kişisel bilgileri koruyarak temsil gücü olan örnekler hazırlayın.
Başlangıçta küçük bir grup yeterli olabilir: kolay, belirsiz ve sınır durumları ayrı tutun. Buradaki sayı evrensel bir kural değildir. Önemli olan aynı örnekleri farklı sürümlerde karşılaştırabilmek ve örneklerin kullanıcınızın işini temsil etmesidir.
Başarıyı gözlenebilir koşullara bağlayın
“Yanıt iyi olsun” ölçülemez kadar geniştir. “Doğru kategori seçilsin, verilmemiş bilgi eklenmesin, gerekli alanlar bulunsun” daha açık koşullardır. Her görev için aynı ölçütler gerekmez; bir özet ile veri çıkarma işi farklı değerlendirilir.
Bir özetleme görevi için şu soruları kullanabilirsiniz:
- Ana kararlar korunmuş mu?
- Kaynakta olmayan sonuç eklenmiş mi?
- İsim ve sayılar doğru mu?
- İstenen uzunluk ve biçim izlenmiş mi?
- Önemli bir belirsizlik kesin hükme dönüşmüş mü?
Bazı koşullar otomatik denetlenebilir, bazıları insan incelemesi gerektirir. İki yöntemin sınırlarını açık tutun.
Değişiklikleri aynı koşullarda karşılaştırın
Bir denemede modeli, talimatı, veri hazırlığını ve çıktı biçimini birlikte değiştirirseniz iyileşmenin nedenini bulmak zorlaşır. Önce mevcut sürümü kaydedin, sonra sınırlı bir değişiklik yapın. Kullanılan model sürümü ve ayarları da kaydın parçası olsun.
Yanıtlar değişken olabileceği için kritik örnekleri gerektiğinde birden fazla çalıştırın. Tek başarısızlığı hemen genel hükme çevirmeyin; tek başarıyı da sistemin hep doğru çalıştığının kanıtı saymayın. Değerlendirme bütçesini görevin riskine ve kullanım hacmine göre ayarlayın.
Hataları yalnızca puanla saklamayın
Toplam başarı oranı, aynı hatanın sürekli tekrarlanmasını gizleyebilir. Yanlış kategori, eksik kaynak, uydurulmuş tarih ve biçim hatası gibi türler belirleyin. Böylece sonraki müdahalenin veri temizliği mi, talimat düzenlemesi mi yoksa farklı araç kullanımı mı olması gerektiği anlaşılır.
Örneğin sistem sürekli güncel olmayan belgeyi kullanıyorsa üslup talimatını geliştirmek çözüm değildir. İlgili kaynağın bulunması ve güncellenmesi gerekir. Hata örneğinin kendisini saklamak, yalnızca “başarısız” etiketi tutmaktan daha öğreticidir.
Canlı kullanım geri bildirimini geri besleyin
Test seti bir kez hazırlanıp unutulacak belge değildir. Gerçek kullanımda ortaya çıkan yeni bir hata türü varsa uygun örneği ekleyin. Ancak yalnızca son hatayı düzeltmeye çalışırken önceki iyi davranışların bozulup bozulmadığını da kontrol edin.
İnsan değerlendiriciler arasında anlaşmazlık varsa ölçütü gözden geçirin. Bazen sorun modelden çok belirsiz beklentidir. Küçük ve açık bir değerlendirme düzeni, büyük fakat kimsenin açıklayamadığı tek bir puandan daha kullanışlı olabilir. Amaç kusursuzluk ilan etmek değil, değişiklikleri kanıta dayalı biçimde seçmektir.
Değerlendirme tablosunda bir satırı birlikte incelemek ölçütleri somutlaştırır. Örneğin yanıt doğru kategoriyi seçmiş ama kaynakta olmayan teslim tarihi eklemişse genel olarak başarılı etiketi vermeyin. Doğruluk ve biçim gibi alanları ayrı işaretleyin. Sonraki sürümde tarih hatası çözülüp kategori seçimi bozulursa toplam puan aynı kalsa bile davranışın değiştiğini görürsünüz. Otomatik puanlayıcı kullanıyorsanız onun kararlarını da insan örneklemiyle karşılaştırın. Bir modelin başka bir modelden aldığı yüksek puan, değerlendirme ölçütünün doğru kurulduğunu kendiliğinden kanıtlamaz; ölçütün kullanıcı amacına uyumu ayrıca gözden geçirilmelidir.
