RAG Veri Hazırlığı Nedir?

Kurumsal bir yapay zeka projesinde, yanıtların kaynağa dayanması şart hale geldiğinde, RAG veri hazırlığı kavramı sahneye çıkar. Retrieval-Augmented Generation mimarisinde büyük dil modeli, cevap üretmeden önce bir arama katmanından içerik çeker. Bu arama katmanı sağlıklı çalışmazsa, model hatalı veya uydurma yanıtlar üretir.

Biz Dijital AI olarak, bu süreci sadece teknik bir ETL işi gibi görmüyoruz. Aslında RAG veri hazırlığı, bilgi mimarisi, içerik yönetişimi ve güvenlik politikalarının kesişiminde duran stratejik bir tasarım problemidir. Doğru yapılandırılmış bir bilgi tabanı, kurumsal hafızayı makine tarafından erişilebilir hale getirir. Kötü tasarlanmış bir yapı ise modelin eline yanlış bağlam verir.

Bu bağlamda RAG veri hazırlığı, ham kurumsal dokümanları, arama katmanının verimli ve güvenilir biçimde kullanacağı bir bilgi indeksi haline getirme sürecidir. Yalnızca metin toplamakla kalmayız. Dokümanları parçalara böleriz, zengin metadata alanları tanımlarız, erişim haklarını işleriz ve kalite kontrolleri uygularız. Böylece LLM, soruya uygun parçaları bulup yanıtını bu içeriklere dayandırır.

Bu disiplin, klasik veri ambarı projelerinden birkaç açıdan ayrılır. Öncelikle, sorgu tipi çok serbesttir ve doğal dile dayanır. Ayrıca, RAG tarafında kullandığımız vektör arama, geleneksel SQL indekslerinden farklı davranır. Bu nedenle içerik yapısı, parça büyüklüğü ve metadata seçimi, arama kalitesini doğrudan etkiler.

Pratikte, kurumsal bir RAG projesinde aşağıdaki kaynaklarla sık karşılaşırız:

• Politika dokümanları, prosedürler, sözleşmeler

• Teknik dokümantasyon, API referansları, mimari diyagram açıklamaları

• SSS dokümanları, bilgi bankası makaleleri, iç wiki sayfaları

• Toplantı notları, karar kayıtları, proje raporları

Bu içeriklerin her biri farklı biçimlerde gelir. PDF, Word, HTML, e-posta çıktıları, bazen de ekran görüntülerinden OCR ile çıkmış metinler görürüz. RAG veri hazırlığı yaklaşımı, bu çeşitliliği tek bir ortak işlenmiş forma dönüştürmeyi hedefler. Öte yandan, her kurumsal bağlam için tek bir sihirli şema yoktur. Bu yüzden, hazırlık sürecini deneysel ve yinelemeli bir çalışma olarak ele almak daha doğrudur.

Veri Hazırlığı Süreci

Kurumsal ekipler genellikle “Belgeleri alalım, indekse atalım, gerisi modeli ilgilendirir” diye düşünür. Biz bu bakışı hatalı buluyoruz. Çünkü iyi tanımlanmış bir veri hazırlığı süreci olmadan, en güçlü model bile kurumsal bağlamı yanlış yorumlar. Bu noktada sistematik bir iş akışı kurmak kritik hale gelir.

Tipik bir RAG veri hazırlığı sürecini, uçtan uca bir pipeline gibi tasarlarız. Süreç hem teknik adımları hem de yönetişim kararlarını içerir. Her aşamada ölçülebilir kriterler tanımlarız. Böylece ilerleyen safhalarda hatanın kaynağını daha rahat buluruz.

Deneyimlerimize göre olgun bir süreç en az şu aşamalardan oluşur:

• Kaynak envanteri çıkarma ve kapsam belirleme

• Format normalizasyonu ve metin çıkarma

• Doküman parçalama stratejisinin tanımı ve uygulanması

• Metadata şablonunun tasarımı ve zenginleştirme

• Kalite kontrol, tutarlılık ve boşluk analizi

• İndeksleme, versiyonlama ve izlenebilirlik kurgusu

Diyelim ki bir bankanın iç mevzuat seti üzerinde çalışıyoruz. Önce hangi yönetmeliklerin, talimatların ve süreç dökümanlarının gerçekten soru-cevap senaryolarında kullanıldığını tespit ederiz. Ardından, bu dokümanları ortak bir UTF-8 metin formatına çeviririz. Bu aşamada, karakter bozulmaları ve tablo kayıpları gibi sorunları yakından izleriz.

Sonraki adımda, doküman parçalama ve metadata zenginleştirme devreye girer. Bu iki konuya ayrı alt başlıklarda gireceğiz. Ancak süreç perspektifinden bakınca, parçalama parametrelerini ve metadata alanlarını birlikte tasarlamak gerekir. Çünkü parça boyutu, hangi bağlamsal bilgiyi metadata üzerinden taşıyacağımızı doğrudan etkiler.

Veri hazırlığı sürecinin son bölümünde, indeksleme ve geri alma kalitesini ölçeriz. Örneğin, belirli bir regülasyon maddesini hedefleyen test soruları hazırlarız. Daha sonra, arama katmanının bu maddeleri hangi isabet oranıyla döndürdüğünü inceleriz. Bu tarz test senaryoları, süreci soyut bir “pipeline” olmaktan çıkarır, somut iş çıktısına bağlar.

Doküman Parçalama

Doküman parçalama, RAG mimarisinin en kritik tasarım noktalarından biridir. Tek bir PDF dosyasını, arama katmanının verimli tarayacağı küçük içerik bloklarına böleriz. Parça boyutunu belirlerken, hem semantik bütünlüğü hem de sorgu performansını dikkate alırız.

Çok küçük parçalar, bağlamı kaybettirir. Çok büyük parçalar ise alakasız içeriklerin aynı blokta kalmasına yol açar. Biz genellikle başlık hiyerarşisini, paragraf yapısını ve tablo sınırlarını birlikte kullanırız. Ayrıca, her parçaya benzersiz bir kimlik vererek, orijinal dokümanla izlenebilirliği koruruz.

Metadata Oluşturma

Metadata, her parça için ikinci bir sinir sistemi gibi çalışır. Başlık, bölüm adı, iş birimi, gizlilik seviyesi, versiyon numarası gibi alanlar, arama ve filtreleme kalitesini ciddi biçimde yükseltir. Üstelik erişim kontrolü katmanına da doğrudan sinyal verir.

Kurumsal projelerde, metadata şablonunu yalnızca teknik ekip belirlemez. Hukuk, iç denetim, bilgi güvenliği ve iş birimi temsilcileri de bu tasarıma katılır. Çünkü hangi alanı zorunlu, hangisini isteğe bağlı tuttuğunuz, daha sonra RAG katmanının davranışını etkiler. Tutarlı doldurulan alanlar, benzer içerikleri bir arada tutmamıza yardım eder.

Veri Kalitesi ve Kontrolü

Veri kalitesi, RAG projelerinde genellikle geç fark edilen bir risk kaynağıdır. Metin çıkarma hataları, eksik sayfalar, yinelenen içerikler ve güncel olmayan versiyonlar, arama sonuçlarını bozar. Bu yüzden, hazırlık pipeline’ına otomatik ve manuel kontroller ekleriz.

Bazı ekipler yalnızca teknik doğruluk kontrollerine odaklanır. Biz buna katılmıyoruz. İçerik sahipleriyle birlikte, örnek belgeler üzerinden iş kurallarını da test etmek gerekir. Örneğin, yalnızca onaylı prosedürlerin indekse girdiğinden emin olmak, kalite kontrolünün parçası olmalıdır. Aksi halde model, taslak metinlere dayanarak öneri üretir.

Erişim Kontrolü ve Güvenlik

Birçok kurum, RAG mimarisini konuşurken ilk anda güvenlik risklerini gündeme getirir. Bu refleksi yerinde buluyoruz. Çünkü erişim kontrolü zayıf bir tasarım, hassas verilerin beklenmedik sorularla gün yüzüne çıkmasına yol açabilir. Bu nedenle erişim kontrolü modeli veri hazırlığı aşamasına gömülü olmalıdır.

Geleneksel bilgi sistemlerinde rol tabanlı erişim (RBAC) ve bazen de öznitelik tabanlı erişim (ABAC) kullanırız. RAG tarafında da benzer ilkeleri uygularız, ancak bir farkla. Burada erişim, yalnızca doküman seviyesinde değil, parça seviyesinde de önem kazanır. Çünkü tek bir dosya içinde, hem herkese açık hem de sınırlı bilgi yer alabilir.

Pratikte üç katmanlı bir güvenlik yaklaşımı öneriyoruz:

• Kaynak sistem erişim haklarının korunması ve yansıtılması

• İndeksleme aşamasında gizlilik etiketlerinin metadata’ya işlenmesi

• Sorgu anında, kullanıcı bağlamına göre filtre uygulayan geri alma katmanı

Söz gelimi, bir insan kaynakları yönetmeliğinde, genel prensipler tüm çalışanlar için geçerlidir. Ancak disiplin süreçlerine ait bazı detayları yalnızca İK ekibi görmelidir. Biz Dijital AI projelerinde, bu ayrımı metadata alanlarıyla işaretleriz. “Gizlilik seviyesi”, “hedef rol grubu” gibi alanlar, sorgu anında filtre olarak devreye girer.

Burada sık yapılan bir hatayı da net biçimde söylemek isteriz. Bazı ekipler, “Model zaten yetkisiz bilgiye erişemiyor, çünkü indeks sadece izinli ortamlardan besleniyor” diye düşünür. Bu bakış açısı eksiktir. Çünkü zaman içinde rol değişiklikleri, departman geçişleri ve yeni politikalar ortaya çıkar. İndeks, bu değişiklikleri otomatik takip etmezse, eski haklara göre şekillenmiş bir bilgi alanı kalır.

Güvenlik tarafında denetim izi de kritik rol oynar. Hangi kullanıcının, hangi soruya karşılık, hangi parçaları okuma hakkı olduğunu kayıt altına almak gerekir. Bu sayede, olası bir veri sızıntısı incelemesinde, yalnızca uygulama katmanına değil, RAG altyapısına da bakabiliriz. Bu yaklaşım, bilgi güvenliği ekiplerinin projeye güvenle onay vermesini kolaylaştırır.

Örnek Belge Yaşam Döngüsü

Somut bir senaryo üzerinden ilerlemek, kavramları pekiştirir. Diyelim ki kurumsal bir “Uzaktan Çalışma Politikası” dokümanımız var. Bu belge, hem insan kaynakları hem de bilgi güvenliği açısından önemli hükümler içeriyor. RAG sistemine girmeden önce, belge belirli bir yaşam döngüsünden geçer.

Bu yaşam döngüsünü adım adım ele alalım:

• İlk taslak oluşturma ve ilgili ekiplerce gözden geçirme

• Onay süreci, versiyon numarası atama ve yayınlama

• RAG pipeline’ına alınma, parçalama ve metadata ile zenginleştirme

• İndeksleme, erişim kontrolünün bağlanması ve test sorguları

• Güncelleme, eski versiyonun arşivlenmesi ve yeniden indeksleme

İlk aşamada, belge genellikle Word veya Google Docs formatında doğar. Onay süreci tamamlandığında, resmi bir versiyon numarası alır ve doküman yönetim sistemine yüklenir. Biz bu noktada, yalnızca onaylı versiyonları RAG pipeline’ına dahil ederiz. Taslak statüsündeki belgeler, ayrı bir iş akışında kalır.

Pipeline’a giren belge, önce metin çıkarma aşamasından geçer. Ardından başlık yapısına göre alt bölümlere ayrılır. Diyelim ki, “Çalışma Saatleri”, “Veri Güvenliği”, “Ekipman Kullanımı” gibi başlıklar, ayrı parça kümeleri oluşturur. Her parçaya, “doküman_id”, “versiyon”, “bölüm_adı”, “iş_birimi” gibi alanlar ekleriz.

Burada örnek bir yaşam döngüsü tablosu, kavramları yan yana görmeyi kolaylaştırır.

Bu tabloyu, gerçek sistemlerde genellikle bir konfigürasyon ekranının arka plan modeli olarak düşünürüz. Mesela, yalnızca “İşlenmiş” durumundaki kayıtlar, arama katmanına açık olur. “Arşiv” durumundaki eski versiyonlar ise, yalnızca denetim amaçlı saklanır. Böyle bir yaşam döngüsü kurgusu, RAG veri hazırlığı sürecini kurumsal içerik yönetimiyle uyumlu hale getirir.

Metadata Şablonu ve Kalite Ölçütleri

Metadata şablonu, RAG projesinin iskeletini belirler. Hangi alanları zorunlu, hangilerini isteğe bağlı tuttuğumuz, arama katmanının davranışını büyük ölçüde etkiler. Bu yüzden metadata tasarımını hafife alan ekiplerin, daha sonra geri alma kalitesiyle uğraşmak zorunda kaldığını sıkça görüyoruz. Biz Dijital AI olarak, bu kısmı projenin en fazla zaman ayırdığımız bölümlerinden biri yapıyoruz.

İyi tasarlanmış bir metadata şablonu genellikle şu alan türlerini içerir:

• Tanımlayıcı alanlar: doküman_id, parça_id, başlık, bölüm

• İş bağlamı alanları: iş_birimi, süreç_adı, ürün_hattı

• Yönetişim alanları: versiyon, onay_tarihi, sahip_ekip

• Güvenlik alanları: gizlilik_seviyesi, hedef_rol, ülke_kısıtı

Bu alanların her biri için, sözlükler ve değer kümeleri tanımlarız. Söz gelimi, “gizlilik_seviyesi” alanı yalnızca “Genel”, “İç”, “Gizli” gibi önceden tanımlı değerleri alır. Sonuçta, serbest metin girişlerinden doğan karmaşayı engelleriz. Bunun yanı sıra, otomatik doldurulabilecek alanları pipeline içinde hesaplarız. “Parça uzunluğu”, “sayfa numarası”, “kaynak_sistem” gibi alanlar bu gruba girer.

Kalite ölçütleri tarafında ise, yalnızca teknik doğruluğa odaklanmak yetersiz kalır. Elbette karakter kodlaması, eksik sayfa kontrolü, bozuk PDF tespiti gibi kontrolleri yaparız. Ancak metadata bütünlüğü ve içerik güncelliği gibi ölçütler de en az bunlar kadar önemlidir. Diyelim ki, her parça için zorunlu alanların doluluk oranını izleriz. Üstelik, belirli bir süre güncellenmeyen kritik belgeleri işaretleriz.

Kurumsal ekiplerle çalışırken, genellikle bir “örnek metadata ekranı” tasarlarız. Bu ekran, gerçek sisteme ait bir formun anonimleştirilmiş haline benzer. Ekipler, örnek bir belge üzerinden bu alanları doldurur. Ardından, hangi alanların gerçekten karar süreçlerinde kullanıldığını tartışırız. Kullanılmayan alanları sadeleştirir, eksik görülenleri ekleriz. Bu interaktif çalışma, şablonun masa başında değil, gerçek ihtiyaçlar üzerinden şekillenmesini sağlar.

Son aşamada, kalite ölçütlerini düzenli raporlara dönüştürürüz. Mesela, her hafta “eksik metadata oranı en yüksek ilk 10 belge türü” gibi bir liste üretiriz. Bu listeler, içerik sahiplerine somut aksiyon alanları sunar. Nitekim, RAG veri hazırlığı, tek seferlik bir proje değil, yaşayan bir iyileştirme süreci halini alır.

Sık Sorulan Sorular

RAG veri hazırlığı nedir?

RAG veri hazırlığı, kurumsal belgeleri arama ve üretim katmanının birlikte kullanacağı yapılandırılmış bilgi parçalarına dönüştürme sürecidir. Bu süreçte dokümanları parçalara ayırır, metadata ekler ve kalite kontrolleri uygularız. Amaç, modelin yanıtlarını güvenilir kaynaklara dayandırmaktır.

Veri hazırlığı süreci nasıl işler?

Veri hazırlığı süreci, kaynak envanterinin çıkarılmasıyla başlar ve indekslemeyle tamamlanır. Arada metin çıkarma, doküman parçalama, metadata zenginleştirme ve kalite kontrol adımları yer alır. Her aşamada ölçülebilir kriterler tanımlamak, süreci yönetilebilir kılar.

Hangi veri kalitesi ölçütleri kullanılmalıdır?

Veri kalitesi için teknik doğruluk, bütünlük, tutarlılık ve güncellik ölçütlerini birlikte kullanmak gerekir. Söz gelimi, eksik sayfa oranı, bozuk karakter tespiti ve yinelenen içerik kontrolü önemli metriklerdir. Metadata doluluk oranı ve versiyon uygunluğu da kritik göstergeler arasında yer alır.

Metadata ne işe yarar?

Metadata, her içerik parçasına bağlam ve yönetim bilgisi ekleyerek arama kalitesini ve kontrol edilebilirliği artırır. Başlık, bölüm, iş birimi, gizlilik seviyesi gibi alanlar, hem filtreleme hem de erişim kontrolü için sinyal sağlar. Bunun yanı sıra, izlenebilirlik ve denetim süreçlerini destekler.

Erişim kontrolü neden önemlidir?

Erişim kontrolü, RAG sisteminin hassas bilgileri yalnızca yetkili kullanıcılara göstermesini sağlar. Parça seviyesinde uygulanan gizlilik etiketleri, rol ve öznitelik tabanlı kurallarla birleştiğinde güvenli bir mimari oluşur. Bu yapı, veri sızıntısı riskini azaltır ve denetim gereksinimlerini karşılar.

RAG veri hazırlığı ne zaman yapılmalıdır?

RAG veri hazırlığını, model seçimi ve entegrasyon çalışmalarına paralel, projenin erken safhalarında başlatmak en doğrusudur. Bu sayede, arama katmanını, gerçek kurumsal içerik üzerinden deneysel olarak iyileştirebiliriz. Üstelik, belge yaşam döngüsü ve yönetişim kararlarını da bu aşamada netleştiririz.