RAG Mimarisi: Üretim Ortamı için Pratik Rehber

Büyük dil modelleri (LLM) genel bilgide güçlüdür ama şirketinizin ürün kataloğunu, iç prosedürlerini ya da geçen ay güncellenen sözleşme şartlarını bilmez. Bilmediği bir soruda da çoğu zaman "bilmiyorum" demek yerine makul görünen bir cevap üretir. Retrieval-Augmented Generation (RAG), modele soruyu sormadan önce ilgili belgeleri kendi kaynaklarınızdan bulup bağlam olarak vermeye dayanan bir mimaridir. Doğru kurulduğunda cevapları güncel ve kaynağa dayalı hâle getirir, uydurma cevap riskini azaltır; ancak ortadan kaldırmaz. Bu yazıda bir RAG sisteminin bileşenlerini ve üretim ortamında her birinde verilmesi gereken kararları ele alıyoruz.

Mimarinin İki Yarısı

Bir RAG sistemi iki ayrı akıştan oluşur:

• Hazırlık (ingestion): Belgelerin okunması, temizlenmesi, parçalara bölünmesi, her parçanın embedding'inin hesaplanması ve bir indekse yazılması. Belgeler değiştikçe tekrar çalışır.
• Sorgu (retrieval + generation): Kullanıcının sorusuyla ilgili parçaların bulunması, sıralanması ve modele bağlam olarak verilerek cevabın üretilmesi.

Cevap kalitesinin büyük kısmı modelden önce, yani doğru parçaların bulunup bulunmadığında belirlenir. Model, kendisine verilmeyen bilgiyi kullanamaz.

Belgeleri Hazırlamak ve Parçalamak

PDF, Word ve web sayfalarından çıkarılan metin çoğu zaman sayfa numaraları, üst bilgiler ve bozuk tablolarla doludur. Parçalamadan önce bu gürültüyü temizlemek, sonraki her adımı iyileştirir.

Parça (chunk) boyutu için evrensel bir doğru değer yoktur. Çok küçük parçalar anlamı böler; "bu ürünün iade süresi" cümlesi bir parçada, ürünün adı başka bir parçada kalabilir. Çok büyük parçalar ise ilgisiz metni de bağlama taşır ve embedding'in anlamını bulanıklaştırır. Pratik bir başlangıç:

• Yapıya göre bölün. Sabit karakter sayısı yerine başlık, paragraf ve madde sınırlarını kullanın.
• Küçük bir örtüşme bırakın. Komşu parçaların birkaç cümle paylaşması, sınırda kalan bilgiyi korur.
• Bağlamı parçaya ekleyin. Her parçanın başına belge adını ve bölüm başlığını eklemek, tek başına okunduğunda da anlaşılır olmasını sağlar.
• Metadata saklayın. Kaynak belge, bölüm, tarih, dil ve erişim yetkisi bilgisi; filtreleme ve kaynak gösterme için gereklidir.

Hangi boyutun sizin belgelerinizde iyi çalıştığını, aşağıda anlatılan değerlendirme setiyle birkaç farklı ayarı karşılaştırarak bulun.

Embedding Modeli Seçimi

Embedding modeli, metni anlamını temsil eden bir sayı vektörüne dönüştürür. Seçimde dikkat edilecek noktalar:

• Dil desteği: Belgeleriniz Türkçeyse, modelin Türkçe metinlerde iyi sonuç verdiğini kendi örneklerinizle doğrulayın. Çok dilli modeller genellikle daha güvenli bir başlangıçtır.
• Tutarlılık: Belgeler ve sorgular aynı modelle vektörleştirilmelidir. Model değiştiğinde bütün indeksin yeniden hesaplanması gerekir; bu yüzden her kayıtla birlikte modelin adını ve sürümünü saklayın.
• Boyut ve maliyet: Daha yüksek boyutlu vektörler daha fazla depolama ve bellek ister. Belge sayısı arttıkça bu fark hissedilir hâle gelir.
• Veri gizliliği: Harici bir API kullanılıyorsa belgelerin o servise gönderildiğini unutmayın; hassas veriler için yerel çalışan modeller değerlendirilebilir.

Vektör Deposu: Çoğu Zaman PostgreSQL Yeterli

Ayrı bir vektör veritabanı her zaman gerekli değildir. Uygulamanız zaten PostgreSQL kullanıyorsa pgvector eklentisi vektörleri ilişkisel verilerin yanında saklamayı, aynı sorguda yetki ve metadata filtresi uygulamayı ve mevcut yedekleme düzeninizi korumayı sağlar.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE belge_parcalari (
  id          bigserial PRIMARY KEY,
  belge_id    bigint NOT NULL,
  kiraci_id   bigint NOT NULL,
  icerik      text NOT NULL,
  model       text NOT NULL,
  embedding   vector(1024) NOT NULL,
  icerik_tsv  tsvector
    GENERATED ALWAYS AS (to_tsvector('turkish', icerik)) STORED
);

CREATE INDEX ON belge_parcalari USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON belge_parcalari USING gin (icerik_tsv);

Vektör boyutu (örnekteki 1024) seçtiğiniz modelin çıktı boyutuyla aynı olmalıdır. HNSW indeksi yaklaşık en yakın komşu araması yapar: Çok hızlıdır ama sonuçlar kesin değil, yaklaşıktır. <=> operatörü kosinüs mesafesini verir:

SELECT id, icerik
FROM belge_parcalari
WHERE kiraci_id = $2
ORDER BY embedding <=> $1
LIMIT 20;

Filtre ile yaklaşık arama birlikte kullanıldığında, indeksin bulduğu adayların bir kısmı filtreye takılacağı için beklenenden az sonuç dönebilir. pgvector'ın güncel sürümlerindeki iteratif indeks taraması bu durumu hafifletir; çok seçici filtrelerde kiracıya göre bölümleme (partitioning) de seçenekler arasındadır. Çok büyük ölçeklerde ya da yoğun vektör iş yüklerinde özel vektör veritabanları değerlendirilebilir, ancak bu karar ölçüme dayanmalıdır.

Arama Kalitesi: Hibrit Arama ve Yeniden Sıralama

Hibrit arama

Vektör araması anlam benzerliğinde güçlüdür ama ürün kodu, sipariş numarası ya da özel bir terim gibi birebir eşleşme gereken sorgularda zayıf kalabilir. Tam metin araması ise tam tersi bir profile sahiptir. İkisini birlikte çalıştırıp sonuç listelerini birleştirmek (örneğin Reciprocal Rank Fusion yöntemiyle, her listedeki sıraya göre puan vererek) iki yaklaşımın güçlü yanlarını bir araya getirir. Yukarıdaki tablodaki icerik_tsv sütunu bu amaçla eklenmiştir.

Yeniden sıralama (re-ranking)

İlk aşamada hızlı yöntemlerle geniş bir aday listesi (örneğin 20–50 parça) toplanır; ardından bir cross-encoder modeli soru ile her parçayı birlikte değerlendirerek daha isabetli bir sıralama üretir. Cross-encoder'lar daha yavaş olduğu için yalnız bu küçük aday kümesine uygulanır. Modele de en üstteki birkaç parça gönderilir.

Cevap Üretimi ve Güvenlik

• Modele sınır çizin. Sistem talimatında yalnız verilen bağlama dayanmasını, bağlamda cevap yoksa bunu açıkça söylemesini isteyin.
• Kaynak gösterin. Cevapla birlikte kullanılan parçaların belge adını ve bölümünü döndürmek, kullanıcının cevabı doğrulamasını sağlar ve güveni artırır.
• Yetkiyi aramada uygulayın. Kullanıcının erişemeyeceği belgeler, istem (prompt) içinde "bunu gösterme" denerek değil, sorgu aşamasında filtrelenerek dışarıda bırakılmalıdır. Modele verilen her bilginin cevapta görünebileceğini varsayın.
• Belgelerdeki talimatlara karşı dikkatli olun. İndekslenen bir belge, modeli yönlendirmeye çalışan metin (prompt injection) içerebilir. Bağlamı veri olarak işaretleyin ve modelin araç çağırma yetkilerini kısıtlı tutun.

Değerlendirme: Ölçmeden İyileştiremezsiniz

RAG sistemlerinde bir değişikliğin işe yarayıp yaramadığını birkaç soruyu elle deneyerek anlamak yanıltıcıdır. Bunun yerine gerçek kullanıcı sorularından ve beklenen kaynak belgelerden oluşan bir değerlendirme seti hazırlayın ve her değişikliği bu sete karşı ölçün:

• Arama metrikleri: Doğru parça ilk k sonuç içinde mi (recall@k), kaçıncı sırada geliyor (MRR)?
• Cevap metrikleri: Cevap verilen bağlama sadık mı, soruyu gerçekten yanıtlıyor mu? Bu ölçümler için insan değerlendirmesi ya da dikkatle kurgulanmış LLM tabanlı değerlendiriciler kullanılabilir; Ragas gibi açık kaynak araçlar bu süreci kolaylaştırır.
• Üretim geri bildirimi: Kullanıcıların "faydalı değil" işaretlediği cevapları ve kaynak bulunamayan soruları kaydedip değerlendirme setine ekleyin.

Sonuç

İyi bir RAG sistemi tek bir akıllı bileşenden değil, birbirine bağlı sıradan kararların özenle verilmesinden doğar: temiz belgeler, anlamlı parçalar, tutarlı embedding'ler, hibrit arama, yeniden sıralama, yetkiye duyarlı sorgular ve sürekli ölçüm. İşe küçük bir belge kümesi ve bir değerlendirme setiyle başlamak, hangi adımın sizin verinizde gerçekten fark yarattığını görmenin en güvenilir yoludur.