Arama API'lerini kendi sorgularınızla değerlendirmenin tam yöntemi

Her arama sağlayıcısı size kazandığı bir grafik gösterebilir. O grafiklerin hiçbiri sizin sorgularınızı, sizin ajanınızı ya da sizin iyi sonuç tanımınızı kullanmadı. Arama bir yapay zekâ uygulamasını besliyorsa, üretimde nasıl davranacağını öngören tek değerlendirme, sisteminizin gerçekten sorduğu sorular üzerine kurulandır. Bu rehber yöntemin tamamını anlatıyor: sonuçların ne işe yaradığına karar vermek, bir altın set (gold set) kurmak, ilgililiği ve kanıt desteğini ayrı ayrı puanlamak, paydası bilinmeyen geri çağırmayla başa çıkmak ve her şeyi gelecek çeyrekte yeniden çalıştırılabilecek kadar tekrarlanabilir kılmak. Sonda, bir öğleden sonrada çalıştırabileceğiniz kısaltılmış bir sürüm de var.

Sonuçların ne işe yaradığına karar verin

Sonuçları gözden geçiren bir insan çok şeye tahammül eder: istenmeyen içeriği atlar, iki sekme açar ve yanıtı kendisi çıkarır. Sonuçları okuyan bir model bunu daha az yapar. Önüne geleni kabullenme eğilimindedir, çoğu zaman yalnızca özet parçaları görür ve ihtiyaç duyduğu sayfanın eksik olduğunu size söyleyemez. Bu yüzden sonuçları sisteminizde gördükleri işe göre değerlendirin ve bu işi tek bir cümleyle yazın:

Her kullanıcı sorusu için üst sıradaki sonuçlar, kabul edilebilir bir kaynaktan, tek başına doğru yanıtı vermeye yetecek en az bir pasaj içermelidir.

Bu cümle ölçütlerin çoğunu zaten içinde taşır: doğru malzeme bulundu mu, yanıtı gerçekten destekliyor mu, kaynak kabul edilebilir mi ve modelin okuyabileceği bir biçimde geldi mi? Cümle size iki düzeyde değerlendirme yapmanız gerektiğini de söyler. Erişim değerlendirmesi sonuç listesini doğrudan puanlar. Uçtan uca değerlendirme ise her arama seçeneği takılıyken ajanınızın ürettiği nihai yanıtı puanlar. İkisine de ihtiyacınız var, çünkü daha iyi bir sonuç listesi her zaman daha iyi bir yanıt üretmez.

Gerçek sorgulardan bir altın set kurun

Sisteminize gerçekten sorulanlardan başlayın: üretim kayıtları, ajan izleri, destek talepleri, ekibinizin test sırasında yazdığı sorular. Değerlendiricinin kendi yazdığı yapay sorgular gerçek olanlardan daha temiz ve daha kolay olma eğilimindedir; bu da her sağlayıcıyı olduğundan iyi gösterir.

Sorguları türlerine ayırın, çünkü sağlayıcılar türe göre farklılaşır ve ortalama bunu gizler:

Her sorgu için doğru bir yanıtın neye benzediğini ve bir kaynağı neyin kabul edilebilir kıldığını, herhangi bir sağlayıcının sonuçlarına bakmadan önce kaydedin. Değerlendirme ölçütlerini sonuçları gördükten sonra yazmak, onları sessizce ilk gördüğünüz sağlayıcıya göre ayarlar.

{
  "id": "q-0412",
  "query": "ticari kira sözleşmesini sona erdirmek için asgari bildirim süresi ...",
  "type": "long_tail",
  "answer_must_contain": ["bildirim süresi", "yasal dayanak"],
  "acceptable_sources": "resmî mevzuat sitesi ya da mahkeme; hukuk bürosu özetleri ikincildir",
  "time_sensitive": false,
  "expires": null,
  "notes": "iki farklı yanıt dolaşıyor; yürürlükteki kanun belirleyicidir"
}

Seti toplam sayıya göre değil, tür başına boyutlandırın. Tür başına makul sayıda, özenle değerlendirilmiş sorgu, özensizce değerlendirilmiş büyük bir yığından daha çok şey söyler. Seti zamanla, incelediğiniz her üretim hatasını ekleyerek büyütün.

İlgililiği ve desteği ayrı puanlayın

Konu ilgililiği, bir sonucun soruyla ilgili olup olmadığını sorar. Destek ise sonucun, doğru bir yanıtı gerekçelendiren belirli pasajı içerip içermediğini sorar. Yapay zekâ kullanımı için önemli olan destektir ve ikisi arasındaki fark, pek çok arama değerlendirmesinin yanlış gittiği yerdir: olguyu hiç söylemeyen ama konuyla ilgili sayfalarla dolu bir sonuç listesi ilgililikte iyi puan alır, yine de ajanınızı tahmin yürütmek zorunda bırakır.

Her sonuç için basit, kademeli bir ölçek:

• 3, destekliyor: kabul edilebilir bir kaynaktan, soruyu yanıtlayan bir pasaj içeriyor.
• 2, ilgili: konuyla ilgili ve bağlam olarak yararlı, ama yanıtı kesinleştirmiyor.
• 1, kenarda: konudan yalnızca geçerken söz ediyor.
• 0, ilgisiz ya da yanlış: konu dışı, güncelliğini yitirmiş ya da yanlış bir yanıt veriyor.

Kaynağın kabul edilebilirliğini ve güncelliğini puana katmak yerine ayrı işaretler olarak kaydedin; böylece sonradan destekleyen tek sonucun ne sıklıkla bir derleyici siteden geldiği gibi sorular sorabilirsiniz. Tekrarları da not edin: aynı basın bülteninin beş kopyası beş değil, tek bir sonuçtur.

En azından bir örneklem üzerinde, yazılı yönergelerle çalışan iki insan değerlendirici kullanın ve anlaşmazlıkları tartışarak çözün; anlaşmazlıklar genellikle belirsiz bir yönergeyi ortaya çıkarır. Bu işi ölçeklemek için bir model de değerlendirici olarak kullanılabilir, ama yalnızca aynı öğeler üzerinde etiketlerini insan etiketleriyle karşılaştırıp tutarlı bulduktan sonra; sonrasında da örnek kontrollere devam edin. Değerlendirme sırasında hangi sonucun hangi sağlayıcıdan geldiğini gizleyin.

Kesinlik, geri çağırma ve bilinmeyen payda

Kesinlik (precision) kolaydır: ilk k sonuçtan kaçı destekleyici ya da ilgili? k değerini ajanınızın gerçekten okuduğu sonuç sayısına göre seçin; ajan beş sonuç okurken ilk yirmiyi puanlamak, sisteminizin hiç görmediği bir şeyi ölçmek demektir.

Geri çağırma (recall) zordur, çünkü açık webde kaç destekleyici sayfa bulunduğunu kimse bilmez. TREC gibi bilgi erişimi araştırmalarından ödünç alınan standart çözüm havuzlamadır: her adayın ilk k sonucunu alın, bir insanın elle arayarak bulduklarını ekleyin, havuzun tamamını değerlendirin ve içindeki destekleyici sonuçları bilinen küme sayın. Geri çağırma bu durumda webe göre değil, havuza göre ölçülür. Bundan iki sonuç çıkar. Başka hiçbir adayın bulmadığı iyi sayfaları bulan bir sağlayıcı, o sayfalar değerlendirilip havuza eklenene kadar olduğundan kötü görünür; bu yüzden her yeni aday eklediğinizde yeni sonuçları da değerlendirin. Ayrıca farklı havuzlardan elde edilen geri çağırma değerleri birbiriyle karşılaştırılamaz.

Ajanlar için daha yararlı geri çağırma sorusu çoğu zaman belge başına değil, sorgu başınadır: ilk k sonuç en az bir destekleyici sonuç içeriyor mu? Bir ajanın genellikle bütün pasajlara değil, iyi bir pasaja ihtiyacı vardır. nDCG gibi sıralama ölçütleri ise sıranın önemli olduğu durumlarda, örneğin ajan yalnızca ilk birkaç sonucu okuyorsa, anlam kazanır.

Yanıtsız sorguları ayrı puanlayın. Burada doğru davranış az sonuç ya da hiç ikna edici olmayan sonuç döndürmektir; her zaman kendinden emin görünen bir sayfa döndüren sağlayıcı, yanıtı olan sorgularda cömert, bunlarda ise tehlikeli görünecektir. Hatalar ve zaman aşımları da kendi sütununu hak eder. Başarısız olan bir istek, hiçbir şey bulamayan bir istekle aynı şey değildir; hataları boş sonuç saymak güvenilirlik sorunlarını gizler.

Değerlendirmeyi tekrarlanabilir kılın

Arama sonuçları zamanla kayar. Dizinler güncellenir, sıralama değişir, bazı sağlayıcılar aynı çağrıya farklı sonuçlar döndürebilir. Yeniden çalıştıramadığınız bir değerlendirme bir anekdottur. Sizinkini tekrarlanabilir kılmak için:

• Her çağrının ham yanıtını, zaman damgası ve kullanılan parametrelerin tam haliyle saklayın.
• Her sorguyu farklı günlerde birden fazla kez çalıştırın ve ortalamanın yanında dağılımı da raporlayın.
• Altın seti ve değerlendirme yönergelerini sürümleyin; ikisinden birindeki değişiklik yeni bir seri başlatır.
• Zamana duyarlı sorguları her çalıştırmada yeniden değerlendirin; yanıtının süresi dolmuş sorguları emekliye ayırın.
• Her aday için aynı zaman aşımı, sonuç sayısı ve içerik ayarlarıyla tek bir test düzeneği kullanın.
• Maliyeti ve gecikmeyi bir sağlayıcı sayfasından kopyalamak yerine, kendi ortamınızda ölçülmüş ayrı sütunlar olarak tutun.

Ardından uçtan uca karşılaştırmayı yapın: aynı ajan, aynı istem ve aynı model, değişen tek şey arama altyapısı; puanlama da yanıtın doğruluğuna ve gösterilen her kaynağın bağlı olduğu iddiayı gerçekten destekleyip desteklemediğine göre. Yanıt yanlışsa nedenini belirleyin: erişim mi kaçırdı, sıralama doğru sayfayı aşağıya mı itti, içerik çıkarma mı başarısız oldu, yoksa model iyi bir kaynağı yanlış mı okudu? Yalnızca ilk ikisi arama sağlayıcısının hatasıdır. Bu, yalnızca yanıtı değil işi değerlendirme fikrinin aramaya uygulanmış halidir; atıf tarafında neye bakılacağını ise sağlam atıflar yazısı anlatıyor.

Aynı yöntem özel belgeler üzerindeki aramaya da uygulanır. GoCux bir web arama API'si değildir; Bilgi arama soruları tek bir projenin belgeleri içinde yanıtlar ve pasajları atıflarıyla birlikte döndürür. Orada boş bir sonuç meşru bir yanıttır ve “kullanılamıyor” durumu “hiçbir şey bulunamadı” durumundan farklı raporlanır; yukarıdaki yanıtsız sorgu ve hata sütunları tam da bu ayrımı sınamak için vardır. Dokümantasyondaki arama değerlendirme rehberi bu yöntemi proje bilgisine uyguluyor.

Öğleden sonra sürümü ve doğrulanacaklar

Tam bir program yerine bu hafta ilk bir yanıta ihtiyacınız varsa, kısaltılmış bir sürüm bile bir sağlayıcı grafiğinden iyidir:

1. Kayıtlarınızdan, yukarıdaki türlerin en az dördünü kapsayan ve birkaç yanıtsız soru da içeren birkaç düzine gerçek sorgu çekin.
2. Hiçbir şey çalıştırmadan önce her biri için kabul edilebilir yanıtı ve kaynağı yazın.
3. Her adayı aynı ayarlarla çalıştırın ve ham yanıtları saklayın.
4. Üst sıradaki sonuçları, sağlayıcı adlarını gizleyerek 0 ile 3 arası ölçekte değerlendirin; eski ve ikincil kaynakları işaretleyin.
5. Tür başına raporlayın: en az bir destekleyici sonuç içeren sorguların payı, yanıtsız sorgulardaki davranış ve hatalar.
6. Aynı seti birkaç gün sonra yeniden çalıştırın ve vardığınız sonucun geçerliliğini koruyup korumadığına bakın.

Herhangi bir sonuca göre harekete geçmeden önce şunları kontrol edin: sorgular gerçek miydi, değerlendirme kör müydü, k ajanınızın okuduğu sayıyla eşleşiyor mu, hatalar hata olarak mı sayıldı ve sonuç ikinci çalıştırmada da geçerli miydi? Elinizde kendi rakamlarınız olduğunda sağlayıcılar arasında seçim yapmak için web arama API'si seçme ve geri çağırma ve doğruluğu değerlendirme yazılarına bakın.