TL;DR: Türkçe RAG'de embedding modeli genel benchmark sıralamasına bakılarak değil, kendi dokümanlarınızdan ve gerçek kullanıcı sorgularınızdan oluşan küçük bir değerlendirme setiyle seçilir. Karar kriterleri dil kapsamı, boyut, maliyet ve gecikmedir; asıl gizli maliyet ise modeli sonradan değiştirmenin tüm vektör verisini yeniden üretmeyi gerektirmesidir.
Retrieval-Augmented Generation (RAG) sistemlerinde cevabın kalitesini büyük ölçüde üretim modeli değil, getirilen pasajların kalitesi belirler. Pasajları getiren bileşen embedding modelidir ve Türkçe gibi eklemeli bir dilde bu seçim, İngilizce örneklerde gördüğünüz kadar kolay değildir.
Embedding modeli RAG'de ne işe yarar?
Embedding modeli, bir metni sabit boyutlu bir sayı vektörüne dönüştüren ve anlamca yakın metinleri vektör uzayında birbirine yaklaştıran modeldir. RAG'de hem doküman parçaları hem de kullanıcı sorgusu aynı modelle vektörleştirilir; en yakın parçalar üretim modeline bağlam olarak verilir. Model yanlış parçayı getirirse, üretim modeli ne kadar güçlü olursa olsun cevap yanlış kalır.
Türkçe için neden ayrı bir değerlendirme gerekir?
Türkçe, bir kelimenin onlarca ek alabildiği eklemeli bir dildir. "Sözleşmelerimizdeki", "sözleşmeye" ve "sözleşmeden" aynı kavramı taşır ama yüzey biçimleri farklıdır. Çoğunlukla İngilizce veriyle eğitilmiş bir modelde bu biçimler gereğinden uzak vektörlere düşebilir. Genel çok dilli benchmark skorları bu davranışı ölçmez; çünkü sizin alan terminolojinizi, kısaltmalarınızı ve yazım alışkanlıklarınızı içermez.
Model nasıl karşılaştırılır?
Karşılaştırma, aday modelleri aynı veri üzerinde aynı metrikle ölçmektir. Pratik akış şöyledir:
- Değerlendirme seti hazırlayın. Gerçek dokümanlarınızdan 50-100 soru seçin; her soru için cevabı içeren doğru pasajı elle işaretleyin.
- Aynı parçalama ile indeksleyin. Parça boyutu ve örtüşme tüm adaylarda aynı olmalı; aksi halde modeli değil parçalamayı ölçersiniz.
- Metrikleri hesaplayın. İlk 5 sonuçta doğru pasajın bulunma oranı (recall@5) ve doğru pasajın ortalama sırası (MRR) yeterlidir.
- Hata örneklerini okuyun. Skor tablosu "neden" sorusunu cevaplamaz; yanlış getirilen on sorguya bakmak, ek kökü sorunu mu yoksa alan terimi sorunu mu olduğunu gösterir.
Aşağıdaki tablo, skorun yanında hangi kriterlere bakılacağını özetler:
| Kriter | Neden önemli | Nasıl ölçülür |
|---|---|---|
| Türkçe geri getirme kalitesi | Asıl hedef metrik | Kendi setinizde recall@5 ve MRR |
| Vektör boyutu | Depolama ve arama maliyetini belirler | Doküman sayısı × boyut × 4 bayt |
| Maksimum girdi uzunluğu | Parça boyutunu sınırlar | Model dokümantasyonu |
| Gecikme ve fiyat | Sorgu başına maliyet ve kullanıcı deneyimi | Gerçek yük altında ölçüm |
| Barındırma biçimi | Veri yerleşimi ve KVKK etkisi | Sağlayıcı sözleşmesi ve bölge |
Modeli sonradan değiştirmek neden pahalıdır?
Embedding modeli değişimi, vektör indeksinin tamamını yeniden üretmeyi gerektirir. Farklı modellerin vektörleri aynı uzayda değildir; eski vektörlerle yeni sorgu vektörünü karşılaştırmak anlamsız sonuç verir. Boyut da değişiyorsa indeks şeması da değişir. Bu yüzden model seçimini "sonra değiştiririz" varsayımıyla yapmak yanıltıcıdır; seçimi ölçerek yapın, indeks kayıtlarına hangi modelle üretildiğini yazın ve geçişi iki aşamalı planlayın: yeni indeksi yanında üretin, doğrulayın, ardından trafiği çevirin.
Üretimde hangi uygulamalar korur?
- Embedding model adını yapılandırmada tek yerde tutun ve her vektör kaydına model etiketini yazın.
- Değerlendirme setini kod deposunda saklayın; her model veya parçalama değişikliğinde aynı testi yeniden çalıştırın.
- Aramayı tek başına vektöre bırakmayın; ürün kodu, kısaltma ve özel isim gibi tam eşleşme gereken sorgular için anahtar kelime aramasıyla birleştirin.
Exponential Yazılım olarak üretimdeki AI bileşenlerini uçtan uca, ölçülebilir ve uzun vadeli sürdürülebilir olacak şekilde kurgularız. Embedding seçiminde de ilke aynıdır: önce kendi verinizle ölçün, sonra karar verin.