Kurumsal RAG Rehberi: Şirket verinizle konuşan AI nasıl kurulur?

RAG nedir, neden gerekli?

RAG (Retrieval-Augmented Generation), büyük dil modelinin cevabını üretmeden önce sizin veri kaynaklarınızdan ilgili parçaları bulup modele bağlam olarak vermesi tekniğidir. Modelin "ezberinden" değil, sizin belgelerinizden konuşmasını sağlar.

Kurumsal senaryoda bunun üç somut sonucu var: cevaplar güncel (model eğitim tarihine takılı kalmaz), kaynaklı (her iddianın hangi belgeden geldiği gösterilebilir) ve özel (yalnızca sizin verinize dayanır, rakip herkese açık modelle aynı cevabı alamaz).

Sistemin 4 katmanı

Üretimdeki her RAG sistemi aynı dört katmandan geçer:

1. İçe alma (ingestion): PDF, Word, wiki, CRM kayıtları, e-postalar okunur, temizlenir, parçalanır.
2. İndeksleme: Her parça embedding modeliyle vektöre çevrilir ve vektör veritabanına yazılır.
3. Getirme (retrieval): Kullanıcı sorusu vektörleştirilir, en alakalı parçalar bulunur — çoğu zaman anahtar kelime aramasıyla (hibrit) birleştirilir.
4. Üretim (generation): LLM, bulunan parçaları bağlam alarak cevabı yazar ve kaynak gösterir.

Projelerin çoğu 3. katmanda kazanılır ya da kaybedilir: model ne kadar iyi olursa olsun, yanlış parçaları getirirseniz doğru cevap üretemez. Kabiliyet haritamızdaki veri katmanının bu kadar kalabalık olmasının sebebi bu.

Veri hazırlığı: işin %60'ı

Kırk küsur kurulumdan sonra net söyleyebiliriz: RAG projelerinde zamanın çoğu modelde değil, veride harcanır. Tipik sorunlar ve çözümleri:

• Kopya ve sürüm kirliliği — aynı sözleşmenin 6 versiyonu indekse girerse model çelişkili cevap verir. Tek doğru kaynak (single source of truth) belirleyin, eskileri indeks dışı bırakın.
• Taranmış PDF'ler — metin katmanı olmayan belgeler OCR'dan geçmeden görünmezdir.
• Tablolar — düz metne çevrilen tablo anlamını yitirir; tablo-farkındalıklı ayrıştırıcı şart.
• Erişim yetkileri — İK dokümanını herkese cevaplayan bot, veri sızıntısıdır. İndekse yetki etiketi (ACL) eklenmeli, getirme aşamasında filtrelenmelidir.

Vektör veritabanı seçimi

Popüler seçeneklerin dürüst karşılaştırması:

Kural: altyapınızda ne varsa onunla başlayın. Vektör veritabanı değiştirmek kolaydır; yanlış chunk stratejisiyle indekslenmiş 100 bin dokümanı yeniden işlemek pahalıdır.

Chunk stratejisi

Belgeler modele bütün olarak verilemez; parçalara (chunk) bölünür. Parça boyutu bir denge işidir: çok küçük parçalarda bağlam kopar, çok büyüklerde alaka sinyali sulanır.

# Başlangıç için sağlam varsayılanlar
chunk_size      = 512 token     # bölüm başlıklarına saygılı böl
chunk_overlap   = 64 token      # parçalar arası bağlam köprüsü
strateji        = "semantik"    # sabit boyut değil, anlam sınırından böl
metadata        = belge_adı, bölüm, tarih, erişim_seviyesi

Sözleşme ve mevzuat gibi yapılandırılmış metinlerde madde sınırından bölmek, serbest metinde paragraf/başlık sınırından bölmek isabeti gözle görülür artırır.

Halüsinasyonu önlemek

Üretim sistemlerimizde standart olan dört önlem:

• Kaynak zorunluluğu — model, cevabındaki her iddia için getirilen parçalardan alıntı göstermek zorunda.
• Güven eşiği — getirme skoru eşiğin altındaysa model cevap uydurmak yerine "bu bilgi arşivde yok" der.
• Cevap-kaynak tutarlılık kontrolü — ikinci bir model, üretilen cevabın kaynaklarla çelişip çelişmediğini denetler.
• İnsan eskalasyonu — hukuki/finansal soru sınıfları otomatik olarak insana yönlendirilir.

Başarıyı ölçmek

"Demo'da iyi görünüyor" bir metrik değildir. Yayına almadan önce en az 100 soruluk bir değerlendirme seti kurun ve şu üçünü ölçün: getirme isabeti (doğru belge ilk 5'te mi?), cevap doğruluğu (uzman onayıyla) ve kaynak sadakati (cevap gösterdiği kaynakta gerçekten var mı?). Bu set, her model ya da prompt değişikliğinde regresyon testiniz olur.

Sürecin bizde nasıl işlediğini merak ediyorsanız 4 fazlı metodolojimize göz atın; benzer bir kurulumun ticari tarafı için AI Çözümleri sayfası yol gösterir.

Sık sorulanlar