RAG sistemi kurmadan önce kurumsal veriler nasıl hazırlanmalı?

RAG, yani retrieval-augmented generation, kurumun belgelerini bir dil modeline kalıcı olarak ezberletmek yerine soruya uygun kaynakları bulup yanıt üretiminden hemen önce bağlama getiren bir mimaridir. Bu yaklaşım güncel bilgi, kaynak gösterme ve erişim filtresi için güçlüdür; fakat arama katmanına atılan her dosya otomatik olarak kaliteli kurumsal bilgiye dönüşmez. Eski bir prosedür, imzasız taslak veya yanlış erişim etiketi modelin cevabını doğrudan bozar.

Bir RAG projesinin en zor kısmı çoğu zaman model değil veri hazırlığıdır. RAG sistemleri ve LLMOps & AI platform mühendisliği çalışmaları; belge envanteri, sahiplik, sürüm, parçalama, metadata, erişim, değerlendirme ve operasyon katmanlarını birlikte tasarlar. alfi Engines search ve docs yetenekleri, alfi Platform pipeline ve gateway katmanıyla ürün akışına bağlanabilir.

RAG sistemi nasıl çalışır?

Kullanıcı sorusu önce temizlenir, niyeti ve erişim bağlamı belirlenir. Arama katmanı anahtar kelime, semantik embedding veya hibrit yöntemle aday parçaları bulur; filtreler yalnızca kullanıcının görmeye yetkili olduğu kayıtları bırakır. Yeniden sıralama, en uygun kanıtları öne taşır. Dil modeli bu kaynakları kullanarak yanıt üretir; sistem kaynak, alıntı ve belirsizlik bilgisini geri döndürür.

Bu zincirde her adım ayrı hata üretebilir. Soru yanlış anlaşılabilir, embedding terimi kaçırabilir, arama eski sürümü seçebilir, metadata yanlış tenant taşıyabilir veya model kaynak dışı bir cümle ekleyebilir. Bu nedenle “RAG çalışıyor” demek yerine alım, arama, erişim, üretim ve sunum katmanları ayrı ölçülmelidir.

Veri envanteri: hangi bilgi gerçekten kullanılıyor?

İlk çalışma belgenin bulunduğu yerleri haritalar: dosya paylaşımı, SharePoint benzeri depolar, ERP, CRM, wiki, e-posta, sözleşme sistemi, çağrı notları ve veritabanı. Her kaynak için belge türü, sahip ekip, güncelleme sıklığı, erişim modeli, dil, hacim, hassasiyet ve kullanım senaryosu yazılır. “Kurumsal drive” tek kaynak değildir; içinde geçici taslak ve kişisel notlar olabilir.

Envanter bir liste olarak kalmamalı, veri sözleşmesine dönüşmelidir. Hangi belge yayımlanabilir, hangisi taslaktır, hangisi müşteri özelidir, hangisi yalnız hukuk ekibine aittir? Belge sahibi güncelleme ve geri çekmeden sorumludur. Sahipsiz belge, RAG'in cevap havuzunda görünmez bir risk olarak kalır.

Kullanım senaryosu ve sorgu sözlüğü

RAG'i “kurumun tüm bilgisini sohbet ettirmek” gibi geniş tanımlamak değerlendirmeyi imkânsız kılar. İlk senaryo çalışan prosedürleri, satın alma sözleşmelerini, teknik bakım talimatlarını veya müşteri politikalarını hedefleyebilir. Kullanıcı kimdir, hangi soruyu sorar, hangi cevap kararı etkiler ve kaynak nasıl gösterilmelidir? Bu sorular arama mimarisini belirler.

Sorgu sözlüğü gerçek kelimeleri, kısaltmaları, eş anlamlıları, ürün kodlarını ve yanlış yazımları içerir. Çalışanın “izin prosedürü”, “yıllık izin”, “izin onayı” ve “PTO” ifadeleri aynı belge ailesine gidebilir. Altın sorgu kümesi, yalnız kolay soruları değil eksik, çelişkili, kötü niyetli ve erişim dışı soruları da içermelidir.

Temizleme: mükerrer, eski ve düşük değerli bilgi

İki farklı klasörde aynı PDF bulunması yalnız depolama sorunu değildir; arama sonucunda aynı kanıtın ağırlığı artabilir. Hash, belge kimliği, başlık, sürüm ve içerik benzerliğiyle mükerrerler belirlenir. Arşiv, taslak, imzasız ve geçerliliği bitmiş belgeler canlı bilgi kümesinden ayrılır; tamamen silinmeleri gerekmeyebilir.

Temizleme içerik düzenleme değildir. Hukuki veya denetim gereği belge değişmez kalabilir; RAG indeksi yalnız güncel ve yetkili görünümü kullanır. Eski sürümün neden elendiği, hangi yeni sürümle değiştiği ve geri dönüş yolu kayıt altındadır. Veri odası mantığıyla belgelerin bağlamı ve erişimi birlikte yönetilir.

OCR ve Document AI ile veri çıkarımı

Tarama PDF'ler, görüntüler ve e-posta ekleri OCR veya Document AI ile metne dönüştürülür. Çıktı başlık, sayfa, tablo, liste, dipnot ve kaynak koordinatını korumalıdır. Düz metin, sözleşmedeki madde hiyerarşisini veya fiyat tablosundaki sütun ilişkisini kaybedebilir; bu yüzden yapısal temsil yanında insan doğrulaması gerekir.

Bir belgenin tümünü metne çevirmek onu otomatik olarak güvenilir yapmaz. OCR güveni düşük kelimeler, özel isimler, ürün kodları ve tutarlar işaretlenir. Doküman anlama hizmeti, RAG'e giden içerikte alan çıkarımı ve kanıt koordinatını koruyarak aramanın yalnız “metin bulma” olmaktan çıkmasını sağlar.

Bölümleme ve chunking stratejisi

Chunking, belgeyi arama ve üretim için anlamlı parçalara ayırma işlemidir. Sabit karakter sayısı hızlı bir başlangıç olabilir ancak başlık ve maddeyi bölebilir. Yapısal parçalama; bölüm başlığı, alt başlık, paragraf, madde ve tablo bütünlüğünü korur. Her parçada belge başlığı, bölüm yolu, sayfa, sürüm ve sahip bilgisi bulunmalıdır.

Çok küçük parçalar sorguya hassas cevap verir fakat bağlamı kaybeder; çok büyük parçalar arama isabetini ve model maliyetini düşürür. Overlap, tekrar eden bağlamı artırır ancak aynı cümlenin sonuçlarda gereksiz çoğalmasına yol açabilir. Parça boyutu “en iyi sayı” olarak değil sorgu kümesinde kaynak isabeti, alıntı doğruluğu ve cevap bütçesiyle test edilir.

Metadata ve veri sözleşmesi

Her parça metadata olmadan yalnız anonim bir metindir. Minimum alanlar belge kimliği, parça kimliği, başlık yolu, kaynak URL veya yol, sayfa, yayın tarihi, yürürlük tarihi, güncelleme, sahip ekip, dil, gizlilik, tenant ve erişim rolleridir. Ürün, müşteri, proje, süreç ve bölge gibi domain alanları senaryoya göre eklenir.

Metadata'nın kaynağı ve değişiklik sahibi belirlenmelidir. Kullanıcının serbest yazdığı “gizli” etiketi politika yerine geçmez; kaynak sistemdeki erişim grubu ve belge sahibi doğrulanır. Metadata şeması sürümlenir, eski indekslerle uyumluluk korunur. Boş veya tutarsız metadata oranı kalite dashboard'unda görünmelidir.

Embedding ve hibrit arama

Embedding metin anlamını vektör uzayında temsil eder; benzer soruların benzer parçaları bulmasına yardım eder. Ancak özel isim, ürün kodu, tarih ve tam sözleşme numarası için anahtar kelime araması daha güvenilir olabilir. Hibrit arama iki yaklaşımı birleştirir, yeniden sıralama ise adayları sorgunun amacı ve metadata'sına göre düzenler.

Embedding modeli seçerken Türkçe, alan terimleri, maliyet, gecikme, veri işleme koşulu ve yeniden indeksleme yükü değerlendirilir. Model değiştiğinde eski ve yeni vektörler sessizce karıştırılmamalı; sürüm, indeks zamanı ve kalite karşılaştırması tutulmalıdır. Arama cache'i tenant veya rol sınırını aşmayacak şekilde anahtarlanır.

Erişim kontrolü, tenant ve etik duvar

RAG'in en kritik güvenlik kuralı, arama sonucunun yetki filtresinden önce üretilmemesidir. Kullanıcı rolü, departmanı, müşteri, proje ve tenant bağlamı sorguyla birlikte politika motoruna gider; yalnız izin verilen parçalarda arama yapılır. Sonuçları aldıktan sonra gizlemek, modelin yetkisiz bilgiyi çoktan görmüş olabileceği için yeterli değildir.

Hukuk, yatırım, insan kaynakları veya müşteri dosyalarında bilgi duvarı gerekir. Aynı kullanıcının farklı proje veya müşteri bağlamlarını karıştırmaması sağlanır. Çok müşterili sistemde multi-tenant izolasyonu vektör koleksiyonu, metadata, cache, log ve değerlendirme verisinde ayrı ayrı test edilmelidir.

Güncellik, sürüm ve geri çekme

RAG cevabında güncel politika seçilmiyorsa arama iyi çalışmıyor demektir. Belgenin yürürlük tarihi, iptal tarihi, sürüm numarası ve yerine geçtiği belge bilgisi sorgu filtresine dahil edilir. Aynı madde farklı günlerde değiştiyse kullanıcıya geçerli sürüm ve yürürlük bağlamı gösterilir; eski sürüm yalnız tarihli araştırmada açılır.

Belge geri çekildiğinde indeks, cache, özet ve türetilmiş embedding de güncellenir. Silme işlemi yalnız dosya depoda yapılırsa eski parça cevapta kalabilir. Geri çekme olayı kim, ne zaman, hangi nedenle yaptı bilgisiyle kaydedilir. Yeniden indeksleme başarısız olursa sistem eski veriyi sessizce kullanmak yerine operasyon ekibine alarm üretmelidir.

Cevap üretimi, alıntı ve belirsizlik

Model yalnız getirilen kaynaklarla cevap verme politikasına uymalıdır. Her önemli iddia için atıf, kaynak bağlantısı, başlık ve sayfa gösterilebilir. Kaynaklar çelişiyorsa tek bir kesin cümle yerine fark ve sürüm açıklanmalıdır. Sorunun cevabı veri kümesinde yoksa “bulamadım” demek, halüsinasyon riskini azaltır.

Alıntı kalitesi ayrı test edilir. Model kaynakta olmayan bir cümleyi kaynakla ilişkilendiriyor mu, sayfa ve bölüm doğru mu, özet belgenin anlamını değiştiriyor mu? Kaynak kartı kullanıcıyı orijinal belgeye götürmeli ve erişim hakkını yeniden kontrol etmelidir. GEO açısından cevap-önce özeti faydalıdır; ancak kısa cevap derin kaynak ve kanıt yapısının yerine geçmez.

Değerlendirme kümesi ve RAG metrikleri

Altın kümede soru, beklenen kaynak, kabul edilebilir alıntı, cevap özeti, erişim seviyesi ve cevap verememe durumu bulunur. Retrieval hit rate, MRR veya nDCG aramanın doğru parçayı getirip getirmediğini; faithfulness ve citation accuracy cevabın kaynağa bağlı kalıp kalmadığını gösterir. Uzman değerlendirmesi, otomatik metrikleri tamamlar.

Adversarial testler erişim dışı soruyu, yanlış sürümü istemeyi, prompt enjeksiyonunu, benzer isimli müşteri verisini ve kaynak bulunmayan iddiayı dener. Her indeks veya model sürümünde test tekrarlanır. Başarı eşiği senaryoya göre belirlenir; müşteri sözleşmesi veya kişisel veri bağlamında erişim ihlali sıfır toleranslı olabilir.

Güvenlik ve KVKK

RAG kaynağına giren belge, embedding, cache ve log kişisel veya ticari veri taşıyabilir. Veri minimizasyonu gereği soruyu cevaplamak için gerekmeyen alanlar maskelenir veya indekslenmez. Embedding'in geri döndürülemeyeceği varsayımıyla hareket edilmez; erişim, saklama ve silme politikası türetilmiş veriyi de kapsar.

Model sağlayıcısı, veri bölgesi, alt işleyen, eğitim kullanımı, anahtar yönetimi ve destek erişimi incelenir. Hassas bilgi için on-premise KVKK uyumlu AI yaklaşımı veya özel ağ seçilebilir. DPO ve bilgi güvenliği ekipleri indeks tasarımına sonradan onay veren değil, ilk kapsamın parçası olmalıdır.

Veri kalite döngüsü ve işletim

Canlıda “cevap beğenilmedi” geri bildirimi doğrudan belgeyi veya modeli değiştirmemelidir. Geri bildirim önce hata sınıfına ayrılır: kaynak yok, yanlış kaynak, eski sürüm, yetki, parçalama, model sentezi veya kullanıcı beklentisi. Sonra veri sahibi ve teknik sahip aynı vakayı inceleyip düzeltme planı açar.

RAG işletim panosu indeks tazeliği, boş metadata, arama hit oranı, cevap verememe, kaynak dışı iddia, erişim reddi, maliyet ve gecikmeyi izler. alfi Insight kalite, alfi Guard erişim ve audit, alfi Platform pipeline ve ops sinyallerini ortak görünümde toplayabilir.

Pilot yol haritası

İlk pilot tek departman, sınırlı kaynak kümesi ve net sorgu sözlüğüyle başlar. Belge envanteri ve erişim temizlenir, 100–300 gerçek soru hazırlanır, baseline anahtar kelime aramasıyla karşılaştırma yapılır. Ardından yapısal parsing, embedding ve cevap üretimi eklenir. İnsan uzman kaynak ve cevabı puanlar; erişim testi ayrıca koşulur.

Pilot başarılıysa kaynak alanı genişletilir, farklı roller eklenir ve eski sürüm senaryoları çalıştırılır. “Tüm şirketi indeksleme” kararı ancak tazelik, sahiplik, silme ve değerlendirme işletimi kanıtlandıktan sonra alınır. Yeni bilgi kaynağının onboarding süreci, RAG projesinin teknik kadar önemli bir parçasıdır.

Satın alma kontrol listesi

RAG çözümünü değerlendirirken şunları yazılı ve canlı testlerle doğrulayın:

• Belge sahibi, yürürlük, sürüm ve geri çekme akışı var mı?
• OCR, tablo, başlık ve kaynak koordinatı korunuyor mu?
• Chunking stratejisi sorgu kümesiyle ölçülüyor mu?
• Embedding ve hibrit arama, Türkçe alan terimleriyle test edildi mi?
• Tenant, rol, proje ve etik duvar filtresi aramadan önce çalışıyor mu?
• Cevap kaynak, sayfa, bölüm ve alıntıyla geri dönebiliyor mu?
• Kaynak yoksa sistem açıkça cevap veremiyor mu?
• Prompt enjeksiyonu, eski sürüm ve erişim sızması testleri var mı?
• İndeks tazeliği, kalite, maliyet ve geri bildirim işletiliyor mu?
• Yeni model veya veri sürümünde otomatik değerlendirme çalışıyor mu?

RAG projesi, kurumsal belleği modele emanet etmek değil; hangi bilginin doğru, kimin erişimine açık, ne zaman geçerli ve hangi kanıtla cevaplanabilir olduğunu sistemleştirmektir. Veri hazırlığı bu omurgayı kurmadan yapılan en etkileyici demo bile üretimde güvenilir bir bilgi yardımcısına dönüşmez.

Kaynak sistemlerin değişim yakalama stratejisi

RAG indeksini her gece tüm belgeleri baştan okuyarak güncellemek basit görünür ama maliyetli ve gecikmelidir. Kaynak sistem destekliyorsa değişiklik günlüğü, webhook, sürüm olayı veya dosya hash'i kullanılır. Belge değiştiğinde yalnız etkilenen parçalar yeniden işlenir; metadata ve erişim politikası da aynı olayla güncellenir. Başarısız işleme kaybolmamalı, yeniden deneme kuyruğunda görünmelidir.

Değişim yakalama ile silme birbirinden ayrılır. Belge güncellendiğinde eski parçalar yeni sürümle ilişkilendirilir; belge geri çekildiğinde eski parçalar aramadan çıkarılır. Kaynak sistemin tarihi güvenilir değilse RAG kendi zamanını uydurmak yerine belirsizliği işaretler. Tazelik metriği, son kaynak güncellemesi ile indekslenme zamanı arasındaki farktır.

Tablo, grafik ve görsel bağlamı koruma

Politika belgeleri ve raporlar yalnız metinden oluşmaz. Tablo, dipnot, grafik açıklaması, imza, ek ve şekil referansı kaybolduğunda RAG yanlış bağlam getirir. Tablo hücreleri satır ve sütun başlığıyla birlikte temsil edilir; grafik için kaynak veri veya açıklama saklanır. Görseldeki metin OCR'dan geçse bile görselin hangi bölümle ilişkili olduğu korunur.

Kullanıcı “2025 bütçesinde X kalemi neydi?” diye sorduğunda sayı ve birim birlikte gelmelidir. Aynı rakamın farklı tablo veya para birimine ait olabileceği belirtilir. Model tabloyu serbestçe özetlemek yerine kanonik alan veya hücre alıntısı kullanabilir. RAG değerlendirme kümesine tablo ve görsel soru türleri ayrıca eklenmelidir.

Soru yeniden yazma ve arama stratejisi

Kullanıcının “bunu geçen yılkiyle karşılaştır” sorusu tek başına anlamlı değildir; önceki konuşma, belge türü ve zaman filtresi gerekir. Soru yeniden yazma önceki bağlamı sorgu terimlerine dönüştürür, fakat yetki sınırını değiştiremez. Kullanıcının erişemediği müşteri adı yeniden yazılmış sorguya gizlice eklenmemelidir.

Arama planı sorgu niyetine göre değişebilir: kesin belge numarası için filtre, politika sorusu için hibrit arama, karşılaştırma için iki sürüm seti, liste için yapılandırılmış alan sorgusu. Tüm soruları tek embedding ile çözmek arama maliyetini ve hata oranını artırır. alfi Engines search ve alfi Platform pipeline katmanları bu planı ölçülebilir hale getirebilir.

Reranking ve bağlam bütçesi

İlk arama çok sayıda aday üretebilir; yeniden sıralama sorgunun amacına, başlık, tarih, kaynak güveni ve rol filtresine göre en yararlı parçaları seçer. Aynı belgenin art arda beş parçası bağlamı dolduruyorsa farklı ama tamamlayıcı kaynaklara yer bırakılabilir. Bağlam bütçesi sınırlı olduğundan her parçanın bilgi değeri ve kanıt gereği ölçülür.

Model uzun metinde her şeyi eşit dikkatle okuyamaz. Kaynakları özetlemek kanıtı kaybettirebileceği için kritik alanlarda orijinal alıntı tutulur. Reranker sürümü değiştiğinde kaynak isabeti ve cevap maliyeti yeniden ölçülür. Kullanıcıya getirilmeyen adayların neden elendiği teknik logda tutulabilir, ancak hassas içerik gereksiz yere loglanmaz.

Erişim politikası ve görev bağlamı

Kullanıcının rolü tek başına belge erişimini açıklamaz; görev, müşteri, proje, bölge ve etik duvar gibi bağlamlar da gerekir. Aynı çalışan satış hesabında gördüğü bilgiyi hukuk projesinde göremeyebilir. RAG sorgusu bu bağlamı kimlik ve politika servisinden alır, kullanıcı metnindeki “her şeyi göster” isteğine güvenmez.

Erişim politikası değiştiğinde mevcut embedding ve cache geçersiz hale gelebilir. Cache anahtarı kullanıcı/rol/tenant ve politika sürümünü taşır. Erişim kaldırma sonrası eski cevabın tarayıcıda veya sohbet geçmişinde görünmesi de düşünülür. alfi Guard access, govern ve audit yetenekleri kaynak, sorgu ve cevap düzeyinde kontrol sağlayabilir.

Bilgi yönetişimi ve belge sahipleri

RAG'in bilgi yönetişimi veri ekibine devredilemez. Her içerik ailesi için iş sahibi, gözden geçirme sıklığı, yayın onayı, geri çekme ve itiraz mekanizması belirlenir. “İK politikası” sahibi olmayan bir klasörde duruyorsa RAG hangi metnin geçerli olduğunu bilemez. İçerik sahibi ayrıca çalışanların hangi soruları sorduğunu ve hangi bilginin eksik kaldığını görmelidir.

Belge yayın süreci ile indeks yayın süreci ilişkilendirilir. İnsan onayı tamamlanmadan politika arama indeksine alınmayabilir. Taslak içerik test tenant'ında kullanılabilir, canlı kullanıcıya kapalı kalır. Eski sürüm neden saklandı, hangi belgeyle değişti, kim onayladı bilgisi denetim ve çalışan güveni için gereklidir.

Değerlendirmede insan uzman rolü

Otomatik metrikler kaynak isabetini ve alıntıyı ölçebilir, fakat cevabın iş bağlamında yeterli olup olmadığını uzman değerlendirir. Uzman puanlama kılavuzu; doğru, kısmen doğru, eksik, yanlış kaynak, erişim ihlali, gereksiz kesinlik ve cevap vermeme sınıflarını ayırır. İki uzmanın anlaşmazlığı sistemin açıklama veya kaynak sunumunda sorun olduğunu gösterebilir.

Değerlendirme verisi kişisel ve ticari bilgiyi içerebilir. Anonimleştirme, rol bazlı erişim, saklama ve eğitim kullanım kuralı uygulanır. Uzmanın verdiği düşük puan doğrudan model prompt'una yazılmaz; hata sınıfına, kaynak düzeltmesine veya ürün tasarımına yönlenir. Böylece RAG kalite döngüsü kontrollü kalır.

Üretken cevap yerine yapılandırılmış çıktı

Bazı sorgular için serbest paragraf yerine liste, tablo, tarih karşılaştırması veya kaynak kartı daha güvenlidir. RAG katmanı cevap tipini soruya göre seçebilir: politika sorusuna kısa cevap ve alıntı, karşılaştırmaya sürüm tablosu, süreç sorusuna adım listesi, veri yoksa açık bekleme durumu. Yapılandırılmış çıktı insanın doğrulamasını hızlandırır.

Modelin ürettiği sayısal toplam veya tarih, kaynak alanla karşılaştırılabilir. Çelişki varsa sistem kaynakları yan yana gösterir, modelin ortalamasını almaz. İş akışı başlatılacaksa cevap nesnesi gereken alanları taşımalı; serbest metin içinden değer ayıklamak ikinci bir hata katmanı yaratır. alfi Automate onay ve görev akışı bu çıktıyı kontrollü tüketebilir.

Çoklu tenant ve müşteri projeleri

Hizmet sağlayıcı veya grup şirketi yapısında aynı model ve indeks altyapısı kullanılabilir; ancak veri koleksiyonu ve politika sınırı tenant'a göre ayrıdır. Müşteri A'nın sözleşmesi benzer sorguda Müşteri B'ye görünmemelidir. Test verisi, log, cache ve değerlendirme kümesi de tenant bilgisi taşır. “Aynı vektör alanında filtreleriz” yaklaşımı ayrıca sızma testi olmadan yeterli değildir.

Müşteri çıkışında belge, embedding, özet, cache ve görevler için silme veya taşıma planı bulunur. Yedeklerde ve felaket kurtarma kopyalarında saklama süresi ayrıca kontrol edilir. Multi-tenant izolasyonu yalnız uygulama katmanında değil depolama, ağ ve yönetici erişiminde de doğrulanır.

RAG işletim sözleşmesi

Canlı RAG için tazelik hedefi, arama gecikmesi, cevap kaynak oranı, erişim ihlali toleransı, maliyet bütçesi ve olay yanıt süresi yazılı hale gelir. Kimin indeks tazeliğini izlediği, kimin belge sahiplerini uyardığı ve kimin modeli güncellediği belirsiz kalmamalıdır. LLMOps süreçleri teknik sürüm ile iş yönetişimini aynı takvimde tutar.

İşletim panosu boş kaynak cevaplarını, eski sürüm kullanımını, kullanıcı geri bildirimini, erişim reddini, maliyet ve gecikmeyi gösterir. Kritik kalite düşüşünde sistem daha temkinli cevap moduna geçebilir veya insan aramasına yönlendirebilir. RAG'in olgunluğu, her soruya cevap vermesinde değil, cevap veremediğinde güveni korumasındadır.

Soru türlerine göre kabul kriteri

Bilgi sorusu, karşılaştırma, prosedür, sayısal arama ve karar desteği aynı başarı eşiğine sahip değildir. Bilgi sorusunda kaynak ve kısa cevap; karşılaştırmada doğru sürüm ve fark tablosu; prosedürde adım sırası ve sorumlu; sayısal soruda alan, birim ve tarih; karar desteğinde kanıt ve insan onayı test edilir. Bu kabul kriterleri yazılmadan tek bir genel doğruluk yüzdesi yanıltıcıdır.

Değerlendirme kümesi gerçek kullanıcı dilinden oluşur. Kısaltma, yazım hatası, eksik bağlam ve doğal takip soruları eklenir. Kullanıcının ikinci sorusu ilk kaynak bağlamına erişebilir fakat yetkiyi genişletemez. Cevap verememe ve açıklama isteme de doğru sonuç olarak işaretlenir; RAG her soruyu akıcı paragrafla cevaplamak zorunda değildir.

Belge geri bildirimi ve kaynak kalitesi

Kullanıcı bir cevabı beğenmediğinde sorun kaynakta mı, aramada mı, model sentezinde mi ayırt edilmelidir. Kaynağın sahibi, güncellik, çelişki ve eksik kapsam ayrı geri bildirim alanlarıdır. Kaynak belgenin düzeltilmesiyle arama parçasının yeniden üretilmesi aynı değişiklik olayı içinde takip edilir.

Kaynak kalite skoru; sahip, yürürlük, son gözden geçirme, erişim etiketi ve kullanıcı geri dönüşünü birleştirebilir. Düşük skorlu belge arama sonucunda gösterilebilir ancak cevap üretimine sınırlı girebilir. Bu yaklaşım içerik üretimini teknik indeks ekibine bırakmak yerine bilgi sahiplerini sorumlu yapar.

Model sağlayıcıdan bağımsızlık

RAG tasarımı tek bir dil modelinin formatına bağımlı kalmamalıdır. Embedding, reranker, üretim modeli, OCR ve güvenlik filtresi sürümlenebilir bileşenler olarak ayrılır. Model değiştiğinde aynı altın küme ve erişim testleri çalıştırılır; alıntı, maliyet, gecikme ve cevap verememe karşılaştırılır.

İstem, kaynak şeması ve araç çıktısı taşınabilir tutulursa kurum sağlayıcı değişikliğinde tüm veri hazırlığını tekrarlamaz. LLMOps kayıtları model, prompt, indeks, değerlendirme ve maliyet ilişkisini korur. Tedarik sözleşmesinde veri çıkışı, model eğitimi kullanımı ve silme kanıtı yazılı olur.

Son kullanıcı deneyimi

Kullanıcı kaynakları yalnız teknik ID olarak değil başlık, bölüm, tarih ve erişilebilir bağlantıyla görmelidir. Cevap kısa ise “devamını aç” seçeneği, uzun ise özet ve kritik alıntı ayrı sunulur. Kaynak bulunmadığında sistem nedenini açıklar ve doğru bilgi sahibine yönlendirir. Kullanıcı geri bildirimi tek tıklamayla alınır, hassas soru metni gereksiz kopyalanmaz.

Arama geçmişi ve sohbet hafızası kurum politikasına tabidir. Kullanıcı bir konuşmayı silerse cache, özet ve embedding etkisi değerlendirilir. Farklı tenant veya proje bağlamı aynı arayüzde görünüyorsa aktif bağlam ekranda belirgin olmalıdır. İyi RAG deneyimi modelin ne kadar konuştuğuyla değil, kullanıcının aradığı kanıta ne kadar hızlı ve güvenli ulaştığıyla ölçülür.

Veri hazırlama ekibinin çalışma sözleşmesi

RAG veri hazırlığı yalnız arama mühendislerinin sorumluluğuna bırakılmamalıdır. Bilgi sahibi, belgeyi hangi iş kararında kullandığını ve güncelliğin ne anlama geldiğini açıklar; güvenlik ekibi erişim ve saklama politikasını belirler; hukuk ekibi lisans, kişisel veri ve üçüncü taraf içeriklerini inceler; ürün ekibi kullanıcının cevap beklediği dili ve başarısızlık davranışını tanımlar. Her veri kümesi için bir sahip, bir yedek sahip ve bir hizmet seviyesi yazılı hale getirilir.

Kaynak alımında “okunabiliyor” ile “cevaplanabilir” aynı değildir. Bir politika PDF'i metne dönüştürülebilir fakat bölüm başlıkları, istisnalar ve yürürlük tarihi kaybolmuşsa model doğru parçayı bulamaz. Hazırlık hattı sayfa yönünü düzeltir, tabloları semantik olarak işaretler, dipnotu ana metinden ayırır, ekleri ilişkilendirir ve kaynak konumunu korur. Her chunk için belge kimliği, sürüm, erişim etiketi, bölüm, dil, geçerlilik tarihi ve hassasiyet seviyesi bulunur.

Altın değerlendirme kümesi gerçek kullanıcı sorularından oluşturulur fakat kişisel veriler temizlenir. Her soru için beklenen kaynak, kabul edilebilir cevap, cevap verilmemesi gereken durum ve gerekçe yazılır. Retrieval başarısı, kaynak doğruluğu, alıntı kapsamı, cevap faydası, gecikme ve maliyet ayrı puanlanır. Model cevap vermediğinde doğru biçimde “bilmiyorum” demesi, yanlış bir cevaptan daha yüksek puan alabilir. RAG sistemleri bu değerlendirmeyi indeks değişikliğine ve model sürümüne bağlayacak şekilde işletilebilir.

İçerik tazeliği için otomatik denetimler kurulur. Süresi dolan belge sorgu dışına alınır, yeni sürüm geldiğinde eski embedding etkisizleştirilir ve erişim değişikliği indeks yenileme kuyruğu açar. Yenileme tamamlanmadan kullanıcıya eski ve yeni sürümün karışık sunulması engellenir. Böylece RAG projesi yalnız “vektör veritabanı kurma” işi olmaktan çıkar; kurum bilgisinin sahiplik, kanıt, erişim ve güncellik disiplinleriyle yönetildiği canlı bir bilgi ürününe dönüşür.