RAG nedir, kurumsal RAG nasıl kurulur

RAG (Retrieval-Augmented Generation), bir dil modelini kurumun kendi belgelerine bağlayan mimaridir. Soru geldiğinde önce ilgili metin parçaları aranır, bulunanlar modele bağlam olarak verilir, cevap bu kaynaklardan üretilir. Model yeniden eğitilmez; bilgi tabanı modelin dışında, sizin kontrolünüzde kalır. RAG adı ve mimarisi ilk kez Lewis ve arkadaşlarının 2020 tarihli NeurIPS makalesinde tanımlandı. Bugün kurumsal yapay zekada en yaygın desenlerden biri.

Çözdüğü asıl problem

Bir dil modeli, eğitildiği veriyi ağırlıklarının içinde taşır. Bu bilgi dondurulmuştur: sizin dün imzaladığınız sözleşmeyi, geçen ay değişen prosedürünüzü, ERP’nizdeki cari kaydı bilmez. Bilmediğini de her zaman söylemez — makul görünen bir cevap üretir.

Lewis ve arkadaşlarının makalesindeki ayrım burada işe yarıyor: modelin ağırlıklarındaki bilgi parametrik hafıza, dışarıda tutulan aranabilir belge dizini ise parametrik olmayan hafıza. RAG ikisini birleştirir. Dil yeteneği modelden gelir, olgular sizin dizininizden. Belgeyi güncellediğinizde cevap da güncellenir — yeniden eğitim yok.

Mimari: beş halka

1. Parçalama (chunking). Belgeler modele sığacak ve anlam bütünlüğünü koruyacak parçalara bölünür. Anthropic’in mühendislik yazısı, bilgi tabanı parçalarının tipik olarak birkaç yüz token’ı geçmediğini belirtiyor; kesin bir reçete vermiyor ve kendi verinizle denemeyi öneriyor. Bizim pratiğimizde de doğru sınır, karakter sayısı değil belgenin yapısı oluyor: madde, başlık, tablo satırı.

2. Gömme (embedding). Her parça, anlamını temsil eden bir sayı vektörüne çevrilir. Yakın anlamlı metinler vektör uzayında birbirine yakın düşer. Kritik nokta: sorgu ve belgeler aynı vektör uzayında gömülmeli. Pratikte bu çoğu zaman aynı modeli kullanmak demektir — ama modelin beklediği sorgu/pasaj öneklerini de doğru vermek gerekir. E5 ve bge ailesi `query:` ve `passage:` öneklerini ayırır; DPR ise sorgu ve pasaj için ayrı iki encoder çalıştırır. Kural “tek model” değil, “tek uzay”.

3. Vektör deposu. Vektörler aranabilir bir dizine yazılır. PostgreSQL kullanıyorsanız `pgvector` uzantısı çoğu kurum için yeterli — 16.000 boyuta kadar vektör saklıyor, HNSW ve IVFFlat dizinlerini destekliyor (dizinleme sınırı standart vektörlerde 2.000 boyut). Yeni bir veritabanı satın almadan başlayabilirsiniz.

4. Getirme (retrieval). Sorgu gömülür, en yakın parçalar çekilir. Sistemin kaderi burada belirlenir: yanlış parça geldiyse, dünyanın en iyi modeli bile doğru cevabı üretemez.

5. Üretim (generation). Getirilen parçalar prompt’a bağlam olarak konur, model cevabı yalnızca bu bağlamdan üretir ve kaynağı gösterir.

RAG mı, fine-tuning mi, uzun bağlam mı

	RAG	Fine-tuning	Tüm belgeyi prompt’a koymak
Ne için iyi	Değişen olgusal bilgi	Üslup, format, davranış	Küçük, sabit belge kümesi
Güncelleme	Belgeyi değiştir, biter	Yeniden eğitim gerekir	Her istekte yeniden gönder
Kaynak gösterme	Doğal olarak var	Yok	Var ama zayıf
Maliyet eğrisi	Dizin büyüdükçe yatay	Yüksek, tekrarlayan	Belge başına her sorguda ödenir

Bu üçü rakip değil. Fine-tuning modele nasıl konuşacağını, RAG neyi bileceğini öğretir. Çoğu kurumda ihtiyaç olan ikincisidir.

Adım adım kurulum

Soruyla başlayın, belgeyle değil. Kullanıcıların gerçekten sorduğu 30-50 soruyu yazın. Bu liste hem kapsamı hem de test setinizi verir.
Kaynakları ve yetkileri haritalayın. Hangi belge nerede, kim görebilir? Yetki modelini baştan kurun; sonradan eklenen filtre sızdırır.
Değerlendirme setini önce yazın. Soru + beklenen kaynak belge çiftleri. Bu olmadan hiçbir iyileştirmenin işe yarayıp yaramadığını bilemezsiniz.
Boru hattını kurun: ayrıştırma → parçalama → gömme → dizin.
Getirmeyi ölçün, cevabı değil. Doğru belge ilk N sonuç içinde geliyor mu? Anthropic’in yayımladığı ölçümde, her parçaya 50-100 token’lık açıklayıcı bağlam eklemek top-20 getirme hata oranını %5,7’den %3,7’ye düşürüyor; BM25 anahtar kelime aramasıyla birleştirilince %2,9’a, yeniden sıralama (reranking) eklenince %1,9’a iniyor. Yani en büyük kazanç modelde değil, getirme katmanında.
Üretimi sıkın. “Bağlamda yoksa bilmiyorum de” kuralı ve zorunlu kaynak atfı.
Sonra ölçeklendirin. Tek departman, gerçek kullanıcılar, geri bildirim döngüsü.

Kısa konfigürasyon örneği

# rag.yaml — minimal kurumsal profil
ingest:
  parser: unstructured        # pdf/docx/html -> yapılandırılmış metin
  chunk:
    strategy: heading_aware   # başlık sınırlarını koru
    max_tokens: 512
    overlap_tokens: 64
  contextualize: true         # her parçaya kısa belge bağlamı ekle
embedding:
  model: bge-m3               # açık ağırlıklı, çok dilli, kendi sunucumuzda
  dim: 1024
store:
  backend: pgvector
  index: hnsw
  metric: cosine
retrieval:
  hybrid: [dense, bm25]       # anlam + anahtar kelime
  top_k: 20
  rerank:
    enabled: true
    top_n: 5
  filter: acl_from_user_session   # yetki filtresi sorguya gömülü
generation:
  grounding: strict           # bağlam dışına çıkma
  cite_sources: true

-- pgvector: dizin ve yetki filtreli arama
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id          bigserial PRIMARY KEY,
  document_id bigint NOT NULL,
  content     text   NOT NULL,
  dept_id     int    NOT NULL,          -- yetki sınırı
  embedding   vector(1024) NOT NULL
);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

-- <=> kosinüs mesafesi. Yetki filtresi uygulama katmanında değil, sorgunun içinde.
-- DİKKAT: yaklaşık dizinlerde filtre, dizin taramasından SONRA uygulanır.
-- Varsayılan hnsw.ef_search = 40 iken, koşula satırların %10’u uyuyorsa
-- ortalama yalnızca 4 satır kalır -- LIMIT 20 istense bile.
SET hnsw.iterative_scan = relaxed_order;  -- pgvector 0.8.0+; yeterli satır bulunana dek tara
SET hnsw.ef_search = 100;                 -- aday listesini genişlet (varsayılan 40)

SELECT id, document_id, content
FROM chunks
WHERE dept_id = ANY($2)
ORDER BY embedding <=> $1
LIMIT 20;

-- Yetki değeri sayısı azsa partial index daha kesin bir çözüm:
-- CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WHERE dept_id = 7;
-- Çok sayıda değer varsa dept_id’ye göre partitioning tercih edilir.

Bu tuzak, RAG kurulumlarında en sık sessizce bozulan yerdir. Yetki filtresini sorgunun içine koymak doğru karardır — ama yaklaşık dizinin filtreyi taramadan sonra uyguladığını bilmezseniz, dar yetkili bir kullanıcı için retriever 20 parça yerine 3 parça döndürür, kimse hata almaz ve cevap sessizce fakirleşir. Ölçün: getirilen parça sayısını yetki genişliğine göre loglayın.

RAG ne zaman uygun değil

Dürüst olalım — elinde RAG olunca her soru arama sorusu gibi görünür. Değildir.

Hesap ve toplama isteyen sorular. “Geçen çeyrek kaç fatura kestik” bir arama sorusu değil, bir SQL sorusudur. RAG rastgele 20 fatura getirir ve model sayar. Yanlış sayar. Burada modele veritabanı sorgulatmak gerekir — arama değil, araç kullanımı.
Belge kümesi küçük ve sabitse. Otuz sayfalık bir yönetmelik doğrudan prompt’a sığıyorsa, altyapı kurmayın.
Kaynak veri dağınıksa. Çelişen üç prosedür sürümü varsa RAG çelişkiyi çözmez, yükseltir. Önce belge düzeni, sonra RAG.
Üslup problemi varsa. “Modelimiz bizim gibi konuşmuyor” RAG’in işi değil; bu prompt tasarımı veya fine-tuning konusudur.
Sıfır hata toleransı varsa. Getirme hata oranı hiçbir kurulumda sıfır değil. Hukuki veya tıbbi bir karar doğrudan çıktıya bağlanamaz; insan onayı zorunludur.

Veri egemenliği: RAG’in asıl kurumsal sorusu

RAG’i kurmak, en hassas belgelerinizi bir gömme modelinden ve bir dil modelinden geçirmek demektir. Bu servisler dışarıdaysa, sözleşmeleriniz ve personel kayıtlarınız da dışarı çıkar.

Türkiye’de bu bir tercih değil, mevzuat konusu. 6698 sayılı Kanun’un yurt dışına aktarımı düzenleyen 9. maddesi 1 Haziran 2024’te değişti; standart sözleşme yoluyla aktarım yapılacaksa sözleşmenin imzalanmasından itibaren beş iş günü içinde Kuruma bildirim yükümlülüğü var.

Bunun en temiz çözümü mimaridir: gömme modelini ve dil modelini kurumun kendi sunucusunda çalıştırmak. Böylece belge de, sorgu da, cevap da binayı terk etmez — bildirim yükümlülüğü doğuran aktarım hiç gerçekleşmez. Açık ağırlıklı modellerin bugünkü kalitesiyle bu artık bir ödün değil.

Albatros olarak nasıl yardımcı oluruz

Bunu üretimde de çalıştırıyoruz: uçtan uca geliştirdiğimiz LEGAPALAS, 11 milyondan fazla mahkeme kararı ve mevzuat metnine bağlı bir hukuk yapay zekası; her tespiti doğrulanabilir bir karara dayandırıyor — yani bu yazıdaki kurgu, gerçek bir üründe çalışıyor.

RAG kurulumlarını kurumun kendi altyapısında tasarlıyoruz: değerlendirme setiyle başlıyor, getirme katmanını ölçerek iyileştiriyor, yetki modelini sorgunun içine gömüyoruz. Modelleri müşterinin kendi sunucusunda çalıştırdığımız için belgeler dışarı çıkmıyor — yapay zeka hizmetlerimizi inceleyebilirsiniz. Elinizde somut bir soru varsa, bize yazın; önce uygun olup olmadığına birlikte bakalım.