Semantic Search Nedir? Kelimeyi Değil, Anlamı Aramak

Bir uygulamada arama gerektiğinde benim de ilk aklıma gelen çözüm çoğu zaman oldukça basit oluyor: Kullanıcının girdiği ifadeyi al, ilgili alanlarda ara ve eşleşen kayıtları getir. SQL tarafında yıllardır buna benzer sorgular yazıyoruz:

SELECT *
FROM Articles
WHERE Title LIKE '%redis%'
   OR Content LIKE '%redis%';

Birçok senaryoda bunda yanlış bir şey de yok. Hatta ihtiyaç basitse işi gereksiz yere büyütmek yerine böyle bir çözümü tercih ederim. Problem, insanların bizim veriyi tuttuğumuz ifadelerle arama yapmadığı noktada başlıyor. Elimizde şöyle bir metin olduğunu düşünelim:

Uygulamanın ilk açılış süresi kullanıcıların büyük bölümünde oldukça yüksek.

Arama kutusuna ise şu yazılıyor:

program neden yavaş açılıyor?

İki cümleyi okuduğumuzda aynı problemden bahsettiklerini hemen anlıyoruz. Fakat klasik bir kelime eşleştirmesi açısından ortak nokta oldukça az. Semantic Search tam olarak burada devreye giriyor.

Semantic Search Nedir?

Semantic Search, yani anlamsal arama, metinleri yalnızca içerdikleri sözcüklere göre değil, ifade ettikleri anlama göre karşılaştırmaya çalışır. Başka bir ifadeyle sistem artık sadece:

Bu kelime metnin içinde geçiyor mu?

diye bakmaz. Bunun yerine:

Bu sorgu ile bu içerik aynı konuya mı yakın?

sorusuna cevap arar. Benim bu yaklaşımı anlamamı kolaylaştıran tarafı da burası. Çünkü konu aslında “AI destekli gelişmiş arama” gibi karmaşık bir şeyden önce, arama mantığının değişmesi.

Arka plandaki süreç ise kabaca şöyle çalışır:

Metin
  ↓
Embedding Model
  ↓
Vector
  ↓
Yakın Vectorleri Bul

Bir embedding modeli verdiğimiz metni sayısal bir temsile dönüştürür. Örneğin:

"SQL Server performans problemi"

arka planda buna benzer bir vector haline gelebilir:

[0.021, -0.184, 0.734, 0.091, ...]

Tek tek baktığımızda bu sayıların bizim için çok anlamı yok. Önemli olan, benzer anlam taşıyan metinlerin bu matematiksel uzayda birbirine yakın konumlanması. Sorgu da aynı şekilde vector'e çevrilir. Sonrasında eldeki içerikler arasından buna en yakın olanlar bulunur.

Klasik Aramadan Farkı Ne?

Şöyle yeni bir cümle düşünelim:

JWT token süresi dolduğunda kullanıcı yeniden giriş yapmalıdır.

Birisi sistemde şunu arıyor:

oturum neden kapanıyor?

Birebir metin eşleştirmesi açısından iki ifade pek benzemiyor.

• oturum geçmiyor.
• kapanıyor geçmiyor.

Ama konuyu bilen biri için bağlantı açık: session, token süresi, authentication ve yeniden giriş aynı problem alanının parçaları. Anlamsal yaklaşımın avantajı burada ortaya çıkıyor. Özellikle dokümantasyon, destek sistemleri veya kullanıcıların doğal cümlelerle arama yaptığı yapılarda bunun ciddi fark oluşturduğunu düşünüyorum.

Levenshtein ile Aynı Şey Değil

Burada sık karıştırılan başka bir konu da Levenshtein benzerliği. Örneğin:

Microsoft
Microsfot

Dikkat ederseniz ikinci kelimede yazım hatası var. Levenshtein algoritması bir metni diğerine dönüştürmek için gereken ekleme, silme ve değiştirme işlemlerini hesaplar. Dolayısıyla bu iki kelimenin birbirine yakın olduğunu rahatlıkla tespit edebilir.

Ama şu örneğe bakalım:

araba
otomobil

Anlam olarak neredeyse aynı noktadalar ve karakter olarak ise benzerlik oldukça düşük. Burada Levenshtein çok yardımcı olmaz. Semantic Search ise iki kavramın birbirine yakın olduğunu değerlendirebilir.

Ben bu yöntemleri şöyle ayırmayı daha anlaşılır buluyorum:

Bunları birbirinin yerine geçen teknolojiler olarak görmek pek doğru değil. Aslında her biri farklı bir ihtiyaca cevap veriyor, bu şekilde düşünürsek konu daha rahat anlaşılacaktır.

Peki Nerelerde İşe Yarar?

Bence Semantic Search'ün en güçlü olduğu alanlardan biri, insanların tam olarak hangi terimi kullanması gerektiğini bilmediği sistemler.

Örneğin şirket içi bir dokümantasyon uygulamasında şu sorgu yapılabilir:

prod ortamında bağlantı problemi olduğunda ne yapmalıyım?

İlgili dokümanın başlığı ise şöyle olabilir:

Production Database Connection Troubleshooting

Klasik eşleşmede iki ifade arasında yeterince ortak kelime olmayabilir. Fakat konu olarak baktığımızda son derece yakınlar.

Benzer mantık şu alanlarda da işe yarıyor:

• Şirket içi dokümantasyon
• Bilgi tabanları
• Destek sistemleri
• E-ticaret aramaları
• AI assistant uygulamaları
• RAG sistemleri

Özellikle RAG mimarilerinde bu yaklaşım oldukça önemli. Kullanıcının sorusuna yakın doküman parçaları bulunuyor ve bunlar LLM'e context olarak gönderiliyor. Aslında bugün Semantic Search'ün bu kadar sık konuşulmasının önemli nedenlerinden biri de bu.

Her Yerde Kullanmak Mantıklı mı?

Bence değil. Zaten bir sistemi ihtiyaç olmayan bir yerde kullanmak yarardan çok zarar verecektir. Örneğin kullanıcı şunu arıyorsa:

CVE-2026-12345

ben burada anlam yakınlığıyla uğraşmak istemem. Aynı durum ürün kodu, müşteri numarası, exception adı veya belirli bir teknik anahtar için de geçerli. Böyle durumlarda birebir eşleşme çok daha değerli ve önemlidir. Bu nedenle pratikte en mantıklı çözümlerden biri Hybrid Search oluyor.

Kabaca:

Keyword Search
      +
Semantic Search
      ↓
Sonuçları Birleştir

Örneğin:

ASP.NET Core authentication problemi

gibi bir sorguda ASP.NET Core ifadesini doğrudan eşleştirirken, authentication problemi kısmını anlamsal olarak değerlendirmek mümkün olabiliyor. Açıkçası gerçek sistemlerde bana daha doğal gelen yaklaşım da bu. Çünkü her sorguyu aynı yöntemle çözmeye çalışmak yerine, iki yöntemin güçlü olduğu tarafları birlikte kullanıyoruz.

Sonuç

Semantic Search'ün bence en önemli tarafı kullanılan teknoloji değil, aramaya bakış açısını değiştirmesi. Klasik yöntemde çoğunlukla şu soruyu soruyoruz:

Aranan ifade burada geçiyor mu?

Anlamsal tarafta ise soru değişiyor:

Bu içerik kullanıcının aradığı şeyi anlatıyor mu?

Embedding ve vector search teknolojileri sayesinde bunu uygulamak artık çok daha erişilebilir hale geldi. Yine de Semantic Search'ü her arama probleminin çözümü olarak görmek doğru olmaz. Bazen LIKE, bazen Full-Text Search, bazen Levenshtein, bazen de vector tabanlı arama en doğru çözüm olabilir. Bence asıl mesele, hangi teknolojinin daha yeni olduğundan çok, kullanıcının ne aradığını doğru anlamak. Keyifli kodlamalar 🖖🏼