RAG Mimarisi: Kendi Belgeleriniz Üzerinde Doğru Cevap Üretmek

RAG mimarisi (bilgiyle desteklenmiş üretim), dil modeline soruyu yalnız başına sormak yerine, önce kendi belgelerinizden ilgili bölümleri bulup modelin önüne koyma yaklaşımıdır. Kurumsal senaryolarda popülerliğinin sebebi basittir: model eğitmeye kıyasla çok daha ucuzdur, bilgi güncellendiğinde yeniden eğitim gerekmez ve en önemlisi, cevabın kaynağını gösterebilirsiniz.

Neden model eğitmek değil?

"Kendi verimizle model eğitelim" cümlesi kulağa doğru gelir ama çoğu şirket için yanlış araçtır. İnce ayar, modele üslup ve biçim öğretmekte iyidir; güncel olgusal bilgi aktarmakta ise zayıf ve pahalıdır. Şirket politikası değiştiğinde modeli yeniden eğitmek gerekir, hangi cevabın hangi belgeden geldiğini gösteremezsiniz ve yanlış bilgi modele gömülür.

RAG'de ise bilgi dışarıda kalır: belge güncellenir, sistem hemen yeni bilgiyle cevap verir. Bu, halüsinasyon riskini de azaltır — konuya bütünsel bakmak için halüsinasyonu azaltma yolları yazımıza bakabilirsiniz.

1. Parçalama: en çok küçümsenen adım

Belgeleri parçalara ayırma biçimi, sistemin tavanını belirler. Sabit karakter sayısıyla kesmek en kolay yöntemdir ve çoğu zaman en kötü sonucu verir: cümleler ortadan bölünür, bir tablo başlığından ayrı düşer, madde listesi anlamını yitirir.

Daha iyi yaklaşım yapıya göre bölmektir: başlıklar, bölümler ve paragraf sınırları esas alınır. Her parçaya ait olduğu başlık zinciri de eklenirse ("Ücret Politikası > Fazla Mesai > Hesaplama"), arama doğruluğu belirgin artar. Parça boyutu için tek doğru yoktur, ancak çok küçük parçalar bağlamı, çok büyük parçalar ise odağı kaybettirir; parçalar arasında küçük bir örtüşme bırakmak sınırda kalan bilgiyi kurtarır.

2. Gömme ve saklama

Parçalar bir gömme (embedding) modeliyle vektöre çevrilir ve bir vektör deposunda saklanır. Burada iki pratik uyarı vardır. Birincisi, sorgu ve belge aynı modelle gömülmelidir; model değiştirilirse tüm koleksiyonun yeniden üretilmesi gerekir. İkincisi, çok dilli içerik varsa modelin o dilleri gerçekten desteklediğinden emin olun — Türkçe içerikte İngilizce odaklı bir modelle alınan sonuçlar belirgin biçimde zayıflar.

Ayrı bir vektör veritabanı şart değildir; birçok ilişkisel veritabanı artık vektör araması destekler ve orta ölçekli koleksiyonlarda bu, mimariyi belirgin biçimde sadeleştirir.

3. Arama: yalnızca vektör yetmez

Vektör araması anlam yakınlığını yakalar ama tam eşleşmelerde zayıftır: bir ürün kodu, bir madde numarası veya özel bir isim aranıyorsa klasik anahtar kelime araması daha iyidir. Sahada en iyi sonucu hibrit arama verir: iki yöntemin sonuçları birleştirilir.

Üstüne bir yeniden sıralama katmanı eklemek, kaliteyi bir kez daha yükseltir: ilk aramadan gelen 20-30 aday, daha maliyetli ama daha isabetli bir modelle sıralanır ve yalnızca en iyi 3-5 tanesi modele verilir. Bağlamı gereksiz parçalarla doldurmak hem maliyeti artırır hem doğruluğu düşürür — ilgisiz metin, modeli yanlış yöne çeker.

4. Üretim: sınırları açıkça çizin

Modelin talimatı net olmalıdır: yalnızca verilen kaynaklara dayanarak cevapla, kaynak yetersizse "bilmiyorum" de ve her iddianın yanına kaynak referansını ekle. Kaynak gösterme yalnızca güven için değil, denetim için de gereklidir — kullanıcı cevabı doğrulayabilmelidir.

Maliyet tarafında bağlam uzunluğu doğrudan faturaya yansır; daha az ama daha alakalı parça göndermek hem daha ucuz hem daha doğrudur. Bu dengeyi kurmak için LLM maliyetini düşürme yolları yazımızdaki teknikler doğrudan uygulanabilir. Entegrasyonun temel kurgusu için ise büyük dil modellerini uygulamaya entegre etmek yazımız başlangıç noktasıdır.

5. Ölçme: "iyi görünüyor" bir ölçüt değildir

RAG sistemlerinin en sık atlanan parçası değerlendirmedir. Minimum kurulum şudur: gerçek kullanıcı sorularından oluşan 50-100 soruluk bir küme hazırlayın, her soru için doğru kaynağı işaretleyin ve iki şeyi ölçün — doğru parça getirildi mi (arama başarısı) ve cevap kaynakla tutarlı mı (üretim başarısı).

Bu ayrım kritiktir çünkü hataların büyük kısmı üretimde değil aramadadır. Model doğru belgeyi hiç görmediyse, en iyi talimat bile işe yaramaz.

Yetkilendirme: en çok atlanan risk

Kurumsal RAG'de en tehlikeli hata, arama katmanının kullanıcının yetkisini yok saymasıdır. İnsan kaynakları belgeleri aynı koleksiyona konduğunda, sıradan bir çalışan maaş bilgisini bir soruyla öğrenebilir. Yetki filtresi arama sorgusunun bir parçası olmalıdır — cevabı sonradan sansürlemek güvenilir bir çözüm değildir. Bu, yetkilendirme modelini baştan doğru kurmak yazımızdaki ilkelerin yapay zekâ katmanına uzanmasıdır. Modeller ve yetenekleri hakkında güncel bilgi için Anthropic araştırma yayınları takip edilebilir.

Sonuç

RAG mimarisi, model eğitmeden kendi bilginizle doğru ve kaynaklı cevaplar üretmenin en pratik yoludur; ancak kalitesi modelde değil, neredeyse tamamen arama katmanında belirlenir. Yapıya duyarlı parçalama, hibrit arama, yeniden sıralama ve yetki filtresi — bu dördü kurulmadan yapılan RAG denemeleri genellikle "bazen çok iyi, bazen tamamen yanlış" bir izlenim bırakır. Bir sonraki adımınız şu olsun: 50 gerçek soruluk bir değerlendirme kümesi hazırlayın ve önce arama başarısını ölçün. Sistemin gerçek zayıf noktasını orada bulacaksınız.