Semantik arama nedir, anahtar kelime aramasından farkı ne

Semantik arama, sorguyu ve belgeleri anlam vektörlerine çevirip birbirine yakınlıklarına göre eşleştirir; anahtar kelime araması (BM25) ise kelimelerin geçme sıklığına ve nadirliğine bakar. Fark şurada görünür: “araç kiralama” sorgusunda BM25, “oto kiralama” başlıklı belgeyi bulamaz — semantik arama bulur. Ama “TX-4410-B” parça kodunu tam isabetle BM25 bulur, semantik arama kaçırır. Bu yüzden ikisi rakip değil: Elasticsearch’te RRF ile birleştirilen hibrit arama, karışık sorgu yükünde çoğu zaman daha dengeli sonuç verir — ama ölçmeden emin olunmaz.

Anahtar kelime araması ne yapar

Elasticsearch’ün varsayılan skorlaması BM25’tir. Üç şeye bakar: terim belgede kaç kez geçiyor, terim koleksiyonun genelinde ne kadar nadir, belge ne kadar uzun. Varsayılan parametreler `k1 = 1.2` ve `b = 0.75`’tir; ilki terim tekrarının doyum noktasını, ikincisi uzunluk normalizasyonunun sertliğini ayarlar.

BM25 hızlıdır, ucuzdur, açıklanabilir ve hafife alınmayacak kadar iyi bir temel çizgidir. Zayıflığı tek bir yerde toplanır: eşleşme kelimenin kendisi üzerinden kurulur. Sorgudaki terim belgede geçmiyorsa o belgenin skoru yoktur. Eşanlamlılar, yeniden ifade edilmiş sorular, kullanıcının kurum jargonunu bilmemesi — hepsi buraya çarpar.

Semantik arama ne yapar

Semantik aramada bir dil modeli metni sabit boyutlu bir sayı dizisine, yani embedding’e çevirir. Anlamca yakın metinler bu uzayda birbirine yakın düşer. Sorgu da aynı modelden geçirilir; arama artık kelime eşleştirmek değil, en yakın komşuyu bulmaktır. Benzerlik genelde kosinüs ile ölçülür, milyonlarca vektörde makul sürede sonuç almak için de HNSW gibi yaklaşık komşu indeksleri kullanılır — “yaklaşık” kelimesi burada gerçek: hız için bir miktar isabetten feragat edilir.

Semantik aramanın kendi zayıflığı da nettir. Nadir özel isimler, ürün kodları, mevzuat madde numaraları, hata kodları, tam alıntı aramaları: bunlarda vektör benzerliği “yakın ama yanlış” cevap üretmeye çok müsaittir. Bir de indeksleme maliyeti vardır; her belge için model çalıştırmak, uzun metinleri parçalara bölmek ve vektörleri saklamak gerekir.

Karşılaştırma tablosu

	Anahtar kelime (BM25)	Semantik (vektör)
Eşleşme temeli	Terimin kendisi	Anlam yakınlığı
Eşanlamlı / farklı ifade	Bulamaz	Bulur
Ürün kodu, madde no, tam alıntı	Güçlü	Zayıf, kayar
Yazım hatasına dayanıklılık	Düşük (fuzzy ile kısmen)	Orta
İndeksleme maliyeti	Düşük	Yüksek (model + vektör depolama)
Sorgu gecikmesi	Çok düşük	Düşük–orta (ANN indeksi ile)
Neden bu sonuç geldi	Açıklanabilir	Yorumlaması zor
Yeni alana taşınırken	Çalışır	Model alanı tanımıyorsa düşer
Dil desteği	Analiz zincirine bağlı	Modelin dil kapsamına bağlı

Tablo tek başına şunu söylüyor: sütunların zayıflıkları birbiriyle örtüşmüyor. Biri nerede düşüyorsa diğeri orada ayakta. Hibrit aramanın tüm gerekçesi budur.

Hibrit arama ve RRF

Hibrit aramada iki sorgu paralel çalışır ve sonuç listeleri birleştirilir. Sorun şu: BM25 skoru ile kosinüs benzerliği aynı ölçekte değildir, doğrudan toplanamaz. Reciprocal Rank Fusion (RRF) bu sorunu skorları tümden yok sayarak çözer — sadece sıralamaya bakar:

skor(d) = Σ  1 / (k + sıra(d, sorgu))

Her liste için belgenin kaçıncı sırada olduğuna bakılır, tersi alınır, toplanır. Elasticsearch’te `rank_constant` varsayılanı 60’tır. Yöntem 2009’da Cormack, Clarke ve Buettcher tarafından yayımlandı ve popülerliğini bir şeye borçlu: ayarlanacak neredeyse hiçbir şeyi yok.

Elasticsearch 8.14+ retriever sözdiziminde kurulum şöyledir:

{
  "retriever": {
    "rrf": {
      "retrievers": [
        { "standard": { "query": { "match": { "icerik": "araç kiralama" } } } },
        { "knn": { "field": "icerik_vektor", "query_vector": [/* ... */],
                   "k": 50, "num_candidates": 100 } }
      ],
      "rank_window_size": 50,
      "rank_constant": 60
    }
  }
}

Daha eski 8.x kurulumlarında RRF, `rank` bloğu üzerinden yapılandırılır.

Vektör tarafını elle kurmak istemiyorsanız `semantic_text` alan tipi mapping’i, chunking’i ve indeksleme anındaki embedding üretimini üstlenir.

Türkçede durum: ekler ve morfoloji

Türkçe sondan eklemeli bir dildir. “Ev” kökünden “evlerimizden”, “evlerindekiler” gibi çok sayıda yüzey biçimi üretilir. BM25 için her yüzey biçimi ayrı bir terimdir; kullanıcı “kiralama” yazıp belgede “kiralamalarımızda” geçiyorsa, kök ayrıştırılmadan eşleşme olmaz.

Burada dürüst olmak gerekir: bu, tek başına semantik aramaya geçmek için yeterli bir gerekçe değil. Elasticsearch’ün `turkish` analizörü bu işin önemli bir kısmını zaten yapar. Zinciri şudur: `apostrophe` → `turkish_lowercase` → `turkish_stop` → `turkish_keywords` → `turkish_stemmer`. İki parçası özellikle değerli: `apostrophe` filtresi “Ankara’dan” içindeki kesmeden sonrasını atar; `lowercase` filtresi `language: turkish` ile kurulduğunda noktalı/noktasız I ayrımını doğru ele alır. Büyük “I”, jenerik küçültmede “i” olur, Türkçe küçültmede “ı”. Yani “IŞIK” jenerik zincirde “işik” olarak indekslenir; kullanıcı “ışık” yazdığında o belgeye hiç ulaşamaz.

Semantik aramanın Türkçedeki gerçek katkısı ek çekiminde değil, kelime seçiminde ortaya çıkar. Stemmer “fatura” ile “irsaliye”yi, “iş kazası” ile “ramak kala olayı”nı, “izin” ile “mazeret”i birbirine bağlayamaz. Vektör bunları yakın düşürebilir. Ayrıca Snowball tabanlı Türkçe stemmer kural temellidir; bileşik ve düzensiz biçimlerde hem fazla kısaltma hem eksik kısaltma yapar. Semantik katman bu hataları örter ama silmez.

İkinci ve daha önemli uyarı: semantik arama, ancak modelin Türkçeyi gerçekten görmüş olması durumunda işe yarar. Elastic’in ELSER modeli İngilizce için önerilir; Türkçe içerikte doğru tercih E5 gibi çok dilli bir model ya da Türkçe kapsamı doğrulanmış başka bir embedding modelidir. Model seçimi burada, kurulumun geri kalanının tamamından daha belirleyicidir.

Nereden başlanır

Önce ölçün. 30–50 gerçek sorgu ve beklenen doğru sonuçtan oluşan küçük bir değerlendirme seti çıkarın. Bu set olmadan hangi yöntemin daha iyi olduğunu kimse bilemez.
BM25’i düzgün kurun. `turkish` analizörü, kurum sözlüğü için eşanlamlı listesi, alan bazlı ağırlıklar. Temel çizgiyi ölçün.
Türkçe kapasitesi doğrulanmış bir embedding modeli seçin, ölçek ve veri egemenliği gereksinimlerinize göre yerel çalıştırın.
Vektör tarafını ekleyin, ayrı ölçün.
RRF ile birleştirin, aynı sette tekrar ölçün. Kazancı görürsünüz — ya da göremezsiniz, ki bu da bilgidir.

Albatros olarak nasıl yardımcı oluruz

Ölçekli bir örnek: uçtan uca geliştirdiğimiz LEGAPALAS, 11 milyondan fazla mahkeme kararı ve mevzuat metnini vektörleştirip anlam tabanlı aramaya açıyor — kullanıcı doğal dille soruyor, sonuçlar anahtar kelime örtüşmesine değil hukuki bağlama göre geliyor.

Semantik arama hizmetimizde bu zinciri kurumun kendi verisi üzerinde kuruyoruz: Elasticsearch analiz zinciri, model seçimi, hibrit sıralama ve önce değerlendirme seti. Modeli müşterinin kendi sunucusunda çalıştırmak istediğinizde kurulum baştan buna göre tasarlanıyor. Arama kalitenizi konuşmak isterseniz bize yazın ya da [email protected] adresine bir satır bırakın.