Arama katmanını yenileyen ekiplerden sık duyduğumuz bir cümle var: "Vektör aramaya geçtik, bazı sorgular çok daha iyi çalışıyor ama bazıları tamamen bozuldu."
Bu, beklenen bir sonuç. Vektör arama anlam benzerliğini yakalamakta iyidir ve tam terim eşleşmesinde zayıftır. Kullanıcı "iade süresi ne kadar" diye sorduğunda mükemmel çalışır. "TX-4410-B" diye aradığında ise bu kodu benzer görünen başka kodlarla karıştırır.
Kurumsal arama sorgularının önemli bir kısmı ikinci türdendir: ürün kodu, fatura numarası, sipariş numarası, mevzuat madde numarası, hata kodu. Bu sorguları kaybeden bir arama katmanı, ne kadar iyi anlam yakalarsa yakalasın kullanıcı için gerilemedir.
İki yöntem birbirinin alternatifi değil
Klasik metin araması, kelime frekansı ve doküman uzunluğunu hesaba katan BM25 gibi sıralama fonksiyonlarıyla çalışır. Bu yaklaşım, aranan terimin dokümanda geçip geçmediğini doğrudan ölçer ve nadir terimlerde çok güçlüdür (Robertson ve Zaragoza, 2009).
Vektör arama ise metni bir anlam uzayına yerleştirir ve sorgu ile dokümanların bu uzaydaki yakınlığına bakar. Kelime örtüşmesi olmadan da eşleşme kurabilir; "fatura kesilmedi" ile "faturam gelmedi" arasındaki bağı yakalar.
Doğru mimari, ikisinden birini seçmek değil, ikisini birlikte çalıştırmak. Uygulamada gördüğümüz tablo şu: hibrit yapı, hemen her kurumsal veri setinde tek başına metin aramasından da tek başına vektör aramasından da daha iyi sonuç veriyor.
İki listeyi birleştirmenin doğru yolu
Burada sık yapılan hata, iki yöntemin skorlarını ortalamaya çalışmak. Bu çalışmıyor, çünkü skor ölçekleri birbiriyle uyumsuz. BM25 skorları üst sınırı olmayan pozitif sayılardır; kosinüs benzerliği ise dar bir aralıkta gezer. İkisini toplamak, farkında olmadan bir yöntemi diğerine ezdirmek anlamına gelir.
Yaygın kabul gören çözüm, skorları değil sıraları birleştirmek. Reciprocal Rank Fusion, her dokümanı bulunduğu listelerdeki sırasına göre puanlar ve toplar. Yöntem Cormack, Clarke ve Buettcher'in 2009 SIGIR bildirisinde tanımlandı; formüldeki sabit için orijinal çalışmadaki 60 değeri pratikte hâlâ makul bir başlangıç noktası.
Sıra tabanlı birleştirmenin avantajı, hiçbir normalizasyon gerektirmemesi ve yeni bir arama kaynağı eklendiğinde (örneğin başlık araması veya eşanlamlı genişletmesi) aynı formülün çalışmaya devam etmesi.
Türkçe içerikte ayrıca ilgilenilmesi gerekenler
Arama katmanının dilden bağımsız kurulabileceği varsayımı, Türkçe içerikte hızla duvara toslar. Birkaç somut başlık var.
Sondan eklemeli yapı. "Fatura", "faturam", "faturamı", "faturalarımın", "faturalandırma" kelime tabanlı bir indekste beş ayrı terimdir. Kullanıcı "faturamı göremiyorum" diye aradığında, içinde "fatura görüntüleme" geçen doküman eşleşmeyebilir. Bu yüzden metin arama tarafında Türkçe için gövdeleme veya alt-kelime analizi zinciri kurulması gerekir. Bu ayar yapılmadan kurulan indekslerde, hibrit mimarinin metin bacağı beklenenin çok altında çalışır.
Türkçe karakterler ve büyük-küçük harf dönüşümü. Kullanıcılar aramada Türkçe karakter kullanmayabilir: "cozum", "sifre", "gonderi". İndeksleme sırasında hem özgün hem sadeleştirilmiş biçimi tutmak bu farkı kapatır.
Buna bağlı, yazılım tarafında klasikleşmiş bir hata var: küçük harfe çevirme işleminin dil ayarından bağımsız yapılması. Türkçe dil ayarında büyük "I" harfinin küçüğü "ı", büyük "İ" harfinin küçüğü "i" olur. Dil ayarı hesaba katılmadan yapılan dönüşümler "İSTANBUL" ile "istanbul" arasındaki eşleşmeyi bozabilir. Arama davranışında açıklanamayan tutarsızlıklar gördüğünüzde bakılacak ilk yerlerden biri burasıdır.
Kuruma özgü kısaltmalar. Her kurumun kendi jargonu var ve bu jargon genel modellerde karşılığı olmayan bir alan. Eşanlamlı sözlüğü, arama kalitesini artırmanın en ucuz yoludur. Elli satırlık bir eşanlamlı listesi, çoğu kurulumda model değişikliğinden daha fazla fark yaratır.
Yetki filtresi sorgudan önce çalışmalı
Kurumsal aramada her kullanıcı her dokümanı görmemeli. Bu filtrenin nerede uygulandığı bir performans meselesi değil, güvenlik meselesidir.
Sonuçları toplayıp sonra ayıklayan mimariler iki nedenle sorunludur. Birincisi, kullanıcının erişemeyeceği doküman zaten işlenmiş ve özetlenmiş olur. İkincisi, ayıklama sonrası liste beklenenden kısa kalır ve alaka sıralaması bozulur.
Doğru yaklaşım, kullanıcının erişebildiği doküman kümesini sorgu çalıştırılmadan önce daraltmak. Vektör indekslerinde filtreli arama performansı tasarım gerektirir; erişim gruplarının indekse öznitelik olarak yazılması ve filtrenin arama motoruna devredilmesi gerekir.
Ölçmeden iyileştirilemez
Arama iyileştirmelerinin çoğu hissiyata dayalı ilerliyor: bir mühendis birkaç sorgu deniyor, sonuç daha iyi görünüyor, değişiklik yayınlanıyor. Bu yöntemle bazı sorgular iyileşirken diğerlerinin bozulduğu fark edilmiyor.
Değerlendirme seti kurmak zannedildiği kadar zahmetli değil. Pratik yol şu:
- Arama loglarından en sık kullanılan 150-200 sorguyu çıkarın
- Her sorgu için doğru sonucun ne olması gerektiğini insan eliyle işaretleyin
- Bu seti her değişiklikte çalıştırın ve iki metrik raporlayın: doğru sonucun ilk k içinde olma oranı ve sıralama kalitesi (nDCG gibi)
Tıklama verisi de kullanılabilir ama tek başına yeterli değildir, çünkü kullanıcılar üstteki sonuca daha çok tıklar. Sıralamayı tıklamayla optimize etmek, mevcut sıralamayı doğrulamaktan öteye gitmeyebilir.
Gömme modeli seçerken kamuya açık kıyaslamalara bakmak mantıklı bir başlangıç noktası; MTEB gibi çok görevli değerlendirme setleri modeller arası genel bir fikir verir (Muennighoff ve ark., 2022). Ancak kendi verinizdeki sonuç sıralaması genel kıyaslamayla aynı olmayabilir; nihai kararı kendi setinizle verin.
Yeniden sıralama, en yüksek getirili tek adım olabilir
Hibrit aramanın çıkardığı ilk elli sonucu, sorgu ile doküman metnini birlikte değerlendiren bir model ile yeniden sıralamak (reranking) genellikle belirgin bir kalite artışı sağlar. Maliyeti gecikmedir: elli dokümanı yeniden puanlamak arama süresine ek yük bindirir.
Pratik denge şöyle kuruluyor: kullanıcının doğrudan beklediği aramada ilk yirmi sonuç yeniden sıralanır; bir asistanın arka planda yaptığı aramalarda daha geniş bir küme değerlendirilir çünkü kullanıcı zaten cevabı bekliyordur.
Cevap üretmek arama sonuçlarının yerini almaz
Arama sonucunun üstünde kısa bir cevap göstermek faydalı. Ancak sonuç listesini tamamen cevapla değiştirmek, kullanıcıyı doğrulama imkanından mahrum bırakıyor.
İşleyen düzen: kısa cevap, cevabın dayandığı kaynaklar ve altında normal sonuç listesi. Kullanıcı hızlı cevabı okur, ikna olmazsa kaynağa gider. Bu yapı aynı zamanda hatalı cevapların fark edilmesini ve raporlanmasını kolaylaştırır.
İzlenecek metrikler
- Sıfır sonuç dönen sorguların oranı ve bu sorguların listesi
- İlk sonuca tıklama oranı
- Arama sonrası destek talebi açma oranı
- Sorgu başına ortalama arama sayısı (kullanıcı aynı şeyi kaç kez yeniden yazıyor)
- Yeniden sıralama açık ve kapalıyken kalite farkı
Sıfır sonuç listesi, içerik ekibi için en somut iş listesidir. Kullanıcıların arayıp bulamadığı konular, çoğu zaman eksik dokümanı işaret eder.
Kontrol listesi
- Metin ve vektör arama birlikte mi çalışıyor
- Birleştirme skor tabanlı mı sıra tabanlı mı yapılıyor
- Türkçe için gövdeleme veya alt-kelime analizi kurulu mu
- Karakter sadeleştirme ve dile duyarlı harf dönüşümü yapılıyor mu
- Eşanlamlı ve kurum jargonu sözlüğü var mı
- Yetki filtresi sorgudan önce mi uygulanıyor
- Değerlendirme seti kurulu mu, her değişiklikte çalıştırılıyor mu
- Sıfır sonuç sorguları düzenli inceleniyor mu
Anlam bazlı arama servisinin API üzerinden nasıl bağlandığını Smartsearch Servisleri sayfasında, bilgi tabanına bağlı cevap üretimini ise kurumsal chatbot yazımızda bulabilirsiniz.
Kaynaklar
- Robertson, S., Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval. staff.city.ac.uk
- Cormack, G. V., Clarke, C. L. A., Buettcher, S. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. SIGIR '09. dl.acm.org
- Muennighoff, N. ve ark. (2022). MTEB: Massive Text Embedding Benchmark. arxiv.org