Genel amaçlı bir dil modeli şirketinizin güncel sözleşmelerini, iç prosedürlerini veya ürün kılavuzlarını kendiliğinden bilmez. Retrieval-Augmented Generation (RAG), kullanıcı sorusuna yanıt vermeden önce izinli kurumsal kaynaklardan ilgili bölümleri bulur ve modele bağlam olarak verir.
Bu yaklaşım yanıtı kurum bilgisine dayandırabilir; fakat RAG bir “doğruluk düğmesi” değildir. Yanlış kaynak, eski belge, bozuk ayrıştırma, zayıf retrieval veya yanlış citation varsa model yine güvenilir görünmeyen bir cevap üretebilir.
Kurumsal RAG'in hedefi yalnız daha fazla cevap vermek değil; cevap verilemediğinde bunu dürüstçe söylemek ve verilen her önemli iddiayı yetkili, güncel bir kaynağa bağlamaktır.
RAG neden gerekli?
Bir modele şirket belgelerini öğretmek için her değişiklikte yeniden eğitim yapmak pahalı, yavaş ve denetlenmesi zor olabilir. RAG, bilgi ile model davranışını ayırır:
- Belge güncellendiğinde indeks güncellenir; model yeniden eğitilmez.
- Kullanıcı yalnız yetkili olduğu kaynaklarda arama yapar.
- Yanıtta kullanılan kaynak ve revision gösterilebilir.
- Farklı model sağlayıcıları aynı kontrollü bilgi katmanını kullanabilir.
- Yanlış cevabın ingestion, retrieval veya generation aşamasından kaynaklandığı ayrıştırılabilir.
Uçtan uca RAG zinciri
Kaynak sistem
→ Connector / yükleme
→ Ayrıştırma
→ Chunk
→ Embedding
→ Vektör + metadata indeksi
→ Yetkili retrieval
→ Context oluşturma
→ Model yanıtı
→ Citation ve kalite kontrolü
Zincirin bir halkası bozulduğunda sonucun tamamı etkilenir. Dosyanın arayüzde görünmesi, ayrıştırıldığı veya aranabilir olduğu anlamına gelmez.
1. Kaynak kalitesi
RAG'in ulaşabileceği en yüksek kalite, kaynak setinin kalitesiyle sınırlıdır. İndekslemeden önce her kaynak için şu metadata'yı tutun:
| Alan | Neden gerekli? |
|---|---|
| Kaynak sahibi | İçerikten sorumlu kişi/birim |
| Yürürlük durumu | Taslak, aktif, arşiv |
| Revision / tarih | Güncel sürümü ayırmak |
| Veri sınıfı | Erişim ve model egress kararı |
| Organizasyon/departman/Space | Tenant ve iş bağlamı |
| Kaynak URL/ID | Citation ve silme |
| Saklama/silme kuralı | Yaşam döngüsü |
Taslak ve yürürlükteki politikanın aynı ağırlıkta indekslenmesi, modelin eski kuralı seçmesine yol açabilir. Çelişkili kaynakları sessizce birleştirmek yerine yürürlük önceliğini açıkça tanımlayın.
2. Ayrıştırma
PDF, DOCX, sunum, tablo, wiki ve e-posta aynı yapıda değildir. İyi parser yalnız düz metin çıkarmaz; başlık, sayfa, tablo ve bölüm bağlamını mümkün olduğunca korur.
Sık ayrıştırma sorunları
- Taranmış PDF'de OCR uygulanmaması
- Tablo başlıklarının satırlardan kopması
- Header/footer metninin her chunk'ta tekrarlanması
- E-posta zincirinde aynı quoted text'in çoğalması
- Şifreli veya bozuk dosyanın başarı sayılması
- Sayfa ve kaynak konumunun kaybolması
OCR güven skoru düşükse içerik kesin politika kaynağı gibi kullanılmamalıdır. Başarısız dosya karantinaya alınmalı ve veri sahibine görünür bir neden sunmalıdır.
3. Chunk tasarımı
Model tüm belgeyi her soruda görmez; retrieval'ın seçebileceği parçalara ihtiyaç vardır.
| Strateji | Uygun içerik | Risk |
|---|---|---|
| Sabit uzunluk | Homojen düz metin | Bölüm anlamını kesebilir |
| Başlık/bölüm | Politika ve kılavuz | Çok uzun bölümler |
| Semantik | Konu geçişleri | Daha yüksek işlem maliyeti |
| Parent-child | Ayrıntı + üst bağlam | İndeks ve retrieval karmaşıklığı |
| Satır grubu | Tablo | Başlık/kolon bağlamı kaybı |
Chunk; metinle birlikte source ID, revision, başlık, sayfa/konum ve ACL metadata'sını taşımalıdır. “En iyi chunk boyutu” evrensel değildir; gerçek soru setiyle ölçülür.
4. Embedding ve vektör indeksi
Embedding, metni anlamsal yakınlık için sayısal temsile dönüştürür. Knowentra dağıtım tercihine göre Chroma, Qdrant, Milvus veya PGVector gibi farklı vektör depolarıyla çalışabilir. Önemli olan ürün adı değil şu kontrollerdir:
- Embedding modeli ve revision'ı sabit mi?
- Sorgu ve belgeler aynı embedding uzayında mı?
- Distance metric doğru mu?
- Tenant ve Space filtresi sorgu sırasında uygulanıyor mu?
- Silinen kaynağın bütün chunk'ları bulunabiliyor mu?
- İndeks yedeklenebiliyor veya ölçülen RTO içinde yeniden üretilebiliyor mu?
Embedding modeli değiştiğinde yeni ve eski vektörleri aynı koleksiyonda karıştırmayın. Yeni index revision oluşturun, değerlendirin ve alias'ı atomik olarak değiştirin.
5. Yetkili retrieval
Kurumsal RAG'in en kritik farkı erişim kontrolüdür:
Etkili kaynak kapsamı =
kullanıcının organizasyonu
∩ departman/Space üyeliği
∩ bilgi tabanı erişimi
∩ belge/ACL filtresi
∩ agent sürümüne atanmış kaynaklar
Bir vektörün sorguyla yakın olması, kullanıcının o belgeyi okuyabileceği anlamına gelmez. Filtre yalnız sonuç gösterildikten sonra uygulanırsa yasak içeriğin skor, metadata veya model context'i üzerinden sızma riski oluşur.
Agent'a bilgi tabanı bağlamak kullanıcıya yeni belge yetkisi vermemelidir. Retrieval, gerçek kullanıcı kimliği ve Space kapsamıyla sunucuda yeniden yetkilendirilmelidir.
6. Sorgu ve retrieval
Kullanıcının kısa sorusu kurumsal terminolojiyle eşleşmeyebilir. Query rewrite veya hybrid search yardımcı olabilir:
- Dense/vector search: Anlamsal benzerlik
- Keyword/BM25: Kod, numara, kesin terim
- Metadata filter: Departman, tarih, tür, durum
- Reranking: İlk adayları daha güçlü modelle sıralama
Hybrid retrieval, “KVKK Madde 12” gibi kesin ifadeyi keyword ile; “veri güvenliği yükümlülükleri” gibi anlamı vector search ile bulabilir.
Top-k tek başına ayar değildir
Çok az sonuç ilgili kaynağı kaçırır; çok fazla sonuç context'i gürültüyle doldurur. Şunları birlikte değerlendirin:
- Recall@k
- Precision@k
- Reranker başarısı
- Context token bütçesi
- Benzer/duplicate chunk sayısı
- Minimum güven eşiği
Skor eşiğinin altında sonuç varsa modelin genel bilgisini kurum kuralı gibi sunmak yerine “onaylı kaynak bulunamadı” davranışı tercih edilmelidir.
7. Context oluşturma
Retrieval sonucunu ham biçimde prompt'a yığmak yerine:
- Yetkiyi tekrar doğrulayın.
- Duplicate ve düşük değerli chunk'ları çıkarın.
- Kaynak kimliği ve revision'ı koruyun.
- Her chunk'ı güvenilmeyen kaynak içeriği olarak sınırlandırın.
- Token bütçesini kaynaklar arasında dengeli dağıtın.
- Kullanıcı sorusuyla birlikte açık cevap sözleşmesi verin.
Belge içinde “önceki talimatları yok say” yazması kaynak bilgisidir, sistem talimatı değildir. RAG pipeline'ı indirect prompt injection'a karşı bunu ayırmalıdır.
8. Yanıt ve citation
Citation yalnız belge adını göstermek değildir. Önemli iddia ile onu destekleyen kaynak bölümü arasında doğrulanabilir bağ kurmalıdır.
İyi bir cevap:
- Kısa sonucu önce verir.
- Kaynak destekli iddiaları citation ile eşler.
- Belge revision/tarih bilgisini gerektiğinde gösterir.
- Çelişkili kaynakları belirtir.
- Kaynak yoksa bunu açıklar.
- Yetkisiz veya scope dışı soruda içerik sızdırmaz.
Citation doğruluğunu kullanıcı tıklamasıyla sınırlamayın; değerlendirme setinde “iddia bu chunk tarafından gerçekten destekleniyor mu?” sorusunu ölçün.
RAG halüsinasyonu bitirir mi?
Hayır. RAG riski azaltabilir ve cevabı denetlenebilir hâle getirir; fakat:
- Model context'i yanlış yorumlayabilir.
- Retrieval ilgisiz chunk seçebilir.
- Kaynak yanlış veya eski olabilir.
- Model kaynakta olmayan detayı tamamlayabilir.
- Citation doğru belgeye ama yanlış iddiaya bağlanabilir.
Bu yüzden güvenilirlik formülü şöyledir:
Kaynak kalitesi
× erişim doğruluğu
× retrieval kalitesi
× generation disiplini
× citation doğruluğu
× sürekli değerlendirme
Halkalardan biri sıfıra yaklaştığında model kalitesi tek başına sistemi kurtaramaz.
Değerlendirme seti
| Test grubu | Beklenen |
|---|---|
| Açık cevabı olan soru | Doğru cevap + doğru citation |
| Birden çok kaynak | Uygun kaynakları birleştirme |
| Çelişen revision | Güncel olanı ayırma |
| Kaynakta olmayan soru | Cevaptan kaçınma/yönlendirme |
| Yetkisiz belge | İçerik veya metadata göstermeme |
| Dolaylı prompt injection | Sistem sınırını koruma |
| Tablo sorusu | Kolon bağlamıyla doğru değer |
| Çok dilli soru | Doğru kaynağı dil bağımsız bulma |
Ölçümler
- Retrieval recall ve precision
- Citation precision
- Faithfulness / groundedness
- Answer relevance
- Abstention doğruluğu
- Tenant/ACL ihlali
- P50/P95 latency
- Kaynak ve index freshness
Değerlendirme sonuçlarını model, agent, parser, chunk, embedding ve index revision'ıyla birlikte saklayın.
Üretim gözlemlenebilirliği
Bir RAG isteğinde şu zincir izlenebilmelidir:
query_id
→ kullanıcı ve Space kapsamı
→ uygulanan filtreler
→ dönen source/chunk/revision'lar ve skorlar
→ seçilen context boyutu
→ model/agent revision
→ citation eşleşmesi
→ kullanıcı geri bildirimi
Ham belge veya prompt'u trace attribute'una koymayın. Hassas içeriği yeniden kopyalamadan kimlik ve revision üzerinden teşhis yapın.
Sık görülen arızalar
| Belirti | İlk bakılacak yer |
|---|---|
| Dosya var, cevap yok | Parse → embedding → index durumu |
| Yönetici görüyor, üye görmüyor | Space/ACL filtresi |
| Eski bilgi geliyor | Connector checkpoint ve source/index revision |
| Yanlış citation | Chunk metadata ve citation mapping |
| Çok genel cevap | Retrieval sonucu/context'e aktarım |
| Çok yavaş | Retrieval, reranker, model ve context süreleri |
| Başka departman bilgisi | Acil erişim olayı; filtre ve grant |
Tüm indeksi yeniden oluşturmadan önce tek source ID'yi zincir boyunca izole edin.
Maliyet ve kapasite
RAG maliyeti yalnız model token'ı değildir:
- Connector API ve veri transferi
- Parsing/OCR
- Embedding üretimi
- Vektör depolama ve sorgu
- Reranking
- Context token'ı
- Reindex ve yedekleme
Değişmeyen belgeyi content hash/revision ile tanıyıp tekrar embedding yapmayın. Büyük full reindex'i üretim model kapasitesi ve connector rate-limit'iyle aynı anda çalıştırmayın.
Knowentra'da güven zinciri
Knowentra, RAG'i tek başına bir arama özelliği olarak değil yönetişim zinciri içinde ele alır:
- Connector veya yükleme ile kaynak provenance'ı
- Organizasyon, departman ve Space kapsamı
- Agent sürümüne kontrollü bilgi atama
- Dağıtıma uygun vektör deposu
- Harici model öncesi LLM Secure Gateway politikası
- Kaynaklandırılmış chat deneyimi
- Audit ve gözlemlenebilirlik
Bu bileşenlerin bulunması doğru yapılandırıldıkları anlamına gelmez. Üretim kabulü, negatif yetki ve kaynak doğruluğu testleriyle yapılmalıdır.
Uygulama kontrol listesi
- Kullanım amacı ve kaynak sahibi belli.
- Taslak, aktif ve arşiv içerik ayrılmış.
- Source ID, revision, tarih ve veri sınıfı korunuyor.
- Parser gerçek dosya türleriyle test edildi.
- Chunk stratejisi belge yapısına uygun.
- Embedding ve index revision sabitlenmiş.
- Kullanıcı/Space/ACL filtresi retrieval sırasında uygulanıyor.
- Query rewrite ve hybrid search değerlendirme setiyle ölçülmüş.
- Düşük güven durumunda kaynak yokluğu açıklanıyor.
- Citation iddiayı gerçekten destekliyor.
- Prompt injection içeren kaynaklar sistem talimatı olamıyor.
- Yetkisiz ve kaynakta olmayan sorular negatif testte geçiyor.
- Freshness, latency ve kalite metrikleri izleniyor.
- Silme ve yeniden indeksleme runbook'u hazır.
Sonuç
Kurumsal RAG'in değeri modele daha fazla metin vermek değildir. Doğru kaynağı, doğru kullanıcı için, doğru zamanda bulup yanıtın hangi kanıta dayandığını gösterebilmektir. Bu da ingestion'dan citations'a kadar bütün zincirin ölçülmesini ve yönetilmesini gerektirir.
İlk bilgi alanını kurmak için Belge Yükleme, teknik yaşam döngüsü için RAG Sistemi, connector operasyonları için Connector Yönetimi ve Senkronizasyon rehberlerine bakabilirsiniz.