Üretim Seviyesinde RAG: Neden Vektör Arama Yeterli Olmuyor?

Ürün dokümantasyonunuza yönelik RAG tabanlı bir asistanın ilk versiyonunu canlıya aldığınızda, test ortamında performansı mükemmel görünür. Geliştiriciler soruları sorduğunda, sistem doğru yanıtlar verir, halüsinasyon yapmaz ve hatta cevapları üç paragrafta sunar. Ancak yayınlandıktan sadece iki gün sonra, kıdemli bir geliştirici Slack üzerinden sizi uyarır: "Arkadaş, AI bot PX-9000-v2 konfigürasyon hatalarını bulamıyor."

Loglara baktığınızda, kullanıcının aradığı tam hata kodunu sorguladığını görürsünüz. Vektör arama sistemi, semantik anlam için optimize edilmiş olmasına rağmen, "hata" kavramına çok yakın olmaması nedeniyle PX-9000-v2’nin teknik açıklamasına yalnızca 50. sırada ulaşabilmiştir. Üretim ortamında, bu tür hassas sorguların çalışması için semantik benzerlik tek başına yeterli değildir; hibrit arama gereklidir.

Bilgi Erişiminin İki Yüzü

Gerçek dünya uygulamalarında, bilgi erişiminin iki temel yaklaşımı vardır: semantik niyet ve kelime hassasiyeti. Bu yaklaşımlar birbirini tamamladığında, sistemler kullanıcıların aradığı spesifik bilgileri bulabilir.

Vektör Arama (Semantik)

Vektör arama, metinleri yoğun sayısal vektörlere (embedding’ler) dönüştürerek çalışır. Bu sistem, "keşif uçağı" gibi bir sorguyu "SR-71 Blackbird" gibi alakalı terimlerle eşleştirebilir. Doğal dil işlemede oldukça güçlüdür, ancak teknik terimler, hata kodları veya versiyon numaraları gibi spesifik sorgularda zayıf kalır. Örneğin, "PX-9000-v2" arandığında, sistem benzer ancak tam olarak aynı olmayan terimleri de yakalayabilir. Bu da istenen sonuca ulaşmayı zorlaştırır.

Anahtar Kelime Arama (Kelime Hassasiyeti)

Geleneksel tam metin arama sistemleri, kelime düzeyinde hassasiyeti hedefler. Kullanıcı "PX-9000-v2" yazdığında, sistemden tam olarak bu dizeyi bulmasını bekler. Vektör embedding’leri, geniş semantik ilişkiler üzerinde eğitildiği için versiyon numaraları veya teknik tanımlamalar gibi spesifik terimlerde yetersiz kalabilir. Anahtar kelime arama ise bu hassasiyeti sağlar ve teknik dokümantasyonlardaki uzun kuyruklu terimleri doğru şekilde eşleştirir.

Hibrit arama, bu iki sistemin güçlü yönlerini birleştirerek, hem semantik hem de kelime hassasiyetini aynı anda sunar.

Sonuçların Birleştirilmesi: Ters Sıralı Füzyon (RRF)

Hibrit arama uygulamalarında karşılaşılan en büyük zorluklardan biri, farklı puanlama sistemlerinin birleştirilmesidir. Vektör arama, genellikle 0 ile 1 arasında değişen bir mesafe puanı verirken, anahtar kelime arama herhangi bir pozitif sayı üretebilir. Bu puanları doğrudan toplamak mantıklı değildir.

Bu sorunu çözmek için Ters Sıralı Füzyon (RRF) algoritması kullanılır. RRF, ham puanları dikkate almaz ve yalnızca sıralamalara odaklanır. Örneğin, bir belge vektör aramada 1. sırada, anahtar kelime aramada ise 5. sırada yer alıyorsa, RRF bu sıralamaları kullanarak yeni bir puan hesaplar. Formül oldukça basittir:

score = Σ 1 / (k + rank(c, r))

Burada:

• c, bir belgeyi temsil eder.
• r, sıralamaların bulunduğu kümeyi (vektör arama ve anahtar kelime arama sonuçları) temsil eder.
• k, genellikle 60 olarak ayarlanan bir sabittir ve tek bir en yüksek sıradaki sonucun diğerlerini tamamen domine etmesini engeller.

k=60’un Önemi

Peki neden k=60? Bu sabit, orijinal araştırmada çeşitli veri kümeleri üzerinde test edilmiş ve en istikrarlı sonuçları verdiği görülmüştür. Matematiksel olarak, k bir "sönümleyici" görevi görür. Eğer k 1 olsaydı, 1. sıradaki bir belge (1/2 = 0,5) ile 2. sıradaki bir belge (1/3 ≈ 0,33) arasındaki fark çok büyük olurdu (0,17). Bu da, yalnızca vektör aramada 1. sırada yer alan bir belgenin, hem vektör hem de anahtar kelime aramada 2. sırada yer alan bir belgeyi kolayca yenmesine yol açardı.

Ancak k=60 ile 1. sıradaki bir belge (1/61 ≈ 0,01639) ile 2. sıradaki bir belge (1/62 ≈ 0,01613) arasındaki fark minimize edilir (0,00026). Bu da, algoritmanın farklı sıralama sistemlerinde genel performansı yüksek olan belgeleri öne çıkarmasını sağlar. Böylece, hem semantik hem de kelime hassasiyetini dengeli bir şekilde birleştiren sonuçlar elde edilir.

Uygulamaya Geçmek: Hibrit Arama Kurulumu

Hibrit arama uygulamak genellikle iki ayrı veritabanını yönetmeyi gerektirir: anahtar kelime arama için Elasticsearch veya Solr gibi bir sistem ve semantik arama için Pinecone veya Weaviate gibi bir vektör veritabanı. Bu sistemler daha sonra özel bir orkestrasyon katmanıyla birleştirilir. Bu katman, sonuçları toplar, RRF algoritmasını uygular ve nihai sıralanmış listeyi kullanıcıya sunar.

Bazı ilişkisel veritabanları (örneğin, MariaDB) hem tam metin hem de vektör aramayı destekler. Bu tür bir veritabanında hibrit arama, tek bir SQL sorgusu ile gerçekleştirilebilir. Örnek bir uygulama aşağıda gösterilmiştir:

CREATE OR REPLACE TABLE phrases (
    content VARCHAR(200) UNIQUE,
    embedding VECTOR(1536),
    FULLTEXT KEY (content)
);

INSERT INTO phrases (content) VALUES 
    ("Sabahları güçlü bir kahve severim."),
    ("Bir tebrik kartında 'sabah canlandırıcı' ifadesi neon harflerle yazılmıştı."),
    ("Her sabah cappuccino ile güne başlarım."),
    ("Zaman darlığında küçük bir kafein şokuna ihtiyacım olur.");

-- Her içerik için vektör embedding’leri hesaplayın
ALTER TABLE phrases MODIFY COLUMN embedding VECTOR(1536) NOT NULL;
ALTER TABLE phrases ADD VECTOR INDEX (embedding);

SET @search_term = "sabah canlandırıcı";
SET @search_term_vector = VEC_FromText("... arama vektörü burada ...");
SET @k = 60;

-- Hibrit arama (pencere fonksiyonları)
SELECT content,
       1 / (@k + RANK() OVER (
           ORDER BY VEC_DISTANCE_COSINE(embedding, @search_term_vector)
       )) AS hybrid_score
FROM phrases
ORDER BY hybrid_score DESC;

Bu örnekte, hem semantik hem de anahtar kelime temelli arama sonuçları birleştirilerek kullanıcılara daha doğru ve kapsamlı yanıtlar sunulabilir. Üretim ortamında RAG sistemleri kurarken, hibrit arama çözümleri kullanarak hem genel hem de spesifik sorgulara yanıt verebilmek kritik önem taşır.

RAG sistemlerinin geleceği, hibrit arama teknolojilerinin gelişimine bağlı olacaktır. Teknik dokümantasyonlardan müşteri sorgularına kadar geniş bir yelpazede kullanılan bu sistemler, kullanıcı deneyimini köklü bir şekilde iyileştirecek potansiyele sahiptir. Geliştiriciler ve veri mühendisleri, bu yaklaşımı benimseyerek RAG tabanlı uygulamaların hem doğruluğunu hem de kullanıcı memnuniyetini artırabilir.