RAG
Modelin cevap üretmeden önce harici bir bilgi kaynağından ilgili parçaları arayıp bulduğu ve bu parçaları üretim bağlamına dâhil ettiği mimari yaklaşımdır.
Model her şeyi ezberlemek zorunda kalmasın diye ona bir kütüphaneci verilir.
Soru geldiğinde önce kütüphaneci ilgili sayfaları bulur, modele uzatır; model cevabı o sayfalara bakarak yazar. Böylece hem güncel hem kuruma özel bilgi kullanılabilir.
Akış: soru → sorgu dönüşümü → arama (vektör ve/veya anahtar kelime) → yeniden sıralama → seçilen parçaların bağlama eklenmesi → üretim → kaynak gösterme.
Kritik tasarım kararları:
- Parçalama (chunking): çok küçük parça bağlamı kaybettirir, çok büyük parça gürültü getirir.
- Hibrit arama: yalnızca vektör araması, tam eşleşme gereken durumlarda (ürün kodu, mevzuat numarası) zayıftır; anahtar kelime aramasıyla birleştirmek gerekir.
- Yeniden sıralama (reranking): ilk aramanın getirdiği 50 parçayı alaka sırasına sokup en iyi 5'ini almak kaliteyi belirgin artırır.
- Kaynak gösterimi: hangi parçadan hangi cümlenin geldiği izlenebilmelidir.
Ne zaman kullanılmamalı: Bilgi küçük ve durağansa (tek sayfalık fiyat listesi) RAG kurmak gereksiz karmaşıklıktır — dosyayı doğrudan bağlama koymak daha iyidir.
İçerik ekipleri için RAG, "kurumun gerçeğini" modele bağlamanın yoludur. Ancak bu skill'in çalıştığı ölçekte (bir repo, birkaç yüz içerik) doğrudan dosya okuma çoğu zaman RAG'den daha isabetlidir; gereksiz mimari kurmamak da bir karardır.
5.000 ürünlü bir katalogda "hangi ürünler dış mekâna uygundur" sorusuna cevap üretmek RAG işidir. 12 blog yazısı arasında kanibalizasyon aramak RAG işi değildir — hepsini okumak daha doğrudur.
"RAG halüsinasyonu bitirir." Bitirmez. Yanlış parça getirilirse model kendinden emin biçimde yanlış kaynağa dayanarak yanlış cevap verir. RAG riski azaltır, kaldırmaz.