RAG ile Kurumsal Bilgi Asistanı: Doküman Arşivinizi Konuşturun

Büyük dil modelleri eğitildikleri tarihe kadar gördükleri genel bilgiyi çok iyi özetler, ancak sizin şirketinizin kalite prosedürünü, bir müşteriyle yaptığınız sözleşmenin 7. maddesini ya da geçen ay güncellenen fiyat listesini bilemez. Bu bilgiyi modele doğrudan 'sorarsanız' model ya bilmediğini söyler ya da daha kötüsü, kulağa makul gelen ama yanlış bir cevap uydurur. Kurumsal kullanımda bu 'halüsinasyon' riski, yapay zeka projelerinin önündeki en büyük engeldir.

Retrieval-Augmented Generation (RAG), bu problemi modeli yeniden eğitmeden çözer. Kullanıcı bir soru sorduğunda sistem önce şirketin doküman arşivinde soruyla ilgili pasajları bulur, ardından bu pasajları soruyla birlikte modele verir ve modelden yalnızca bu kaynaklara dayanarak cevap üretmesini ister. Böylece cevap güncel olur, hangi dokümanın hangi sayfasından geldiği gösterilebilir ve doküman değiştiğinde modeli değil sadece arama indeksini güncellemek yeterli olur.

Mersin'deki bir lojistik firmasını düşünelim: gümrük mevzuatı notları, taşıma sözleşmeleri, konşimento örnekleri ve iç prosedürler yüzlerce PDF ve Word dosyasına dağılmış durumda. Yeni başlayan bir operasyon personeli 'Tehlikeli madde içeren konteynerde hangi evraklar gerekiyor?' diye sorduğunda, RAG tabanlı bir asistan ilgili prosedürü bulup kısa bir özet ve kaynak bağlantısı sunabilir. Bu, hem kıdemli personelin zamanını korur hem de bilginin kişilere değil sisteme bağlı kalmasını sağlar.

RAG sisteminin kalitesi, çoğu zaman modelden çok verinin nasıl hazırlandığına bağlıdır. İlk adım dokümanları metne çevirmektir: dijital PDF'lerden metin doğrudan çıkarılabilir, taranmış belgeler için OCR (örneğin Tesseract) ya da düzen analizi yapabilen araçlar (Docling, Unstructured gibi) gerekir. Tablolar, başlıklar ve sayfa numaraları bu aşamada korunmalıdır; aksi halde 'Tablo 3'teki değer nedir?' gibi sorulara doğru cevap vermek imkânsızlaşır.

İkinci adım metni anlamlı parçalara (chunk) bölmektir. Çok küçük parçalar bağlamı kaybeder, çok büyük parçalar ise alakasız bilgiyle modeli boğar ve arama isabetini düşürür. Pratikte 300-800 token arası, başlık sınırlarına saygı duyan ve parçalar arasında küçük bir örtüşme (overlap) bırakan bir strateji iyi bir başlangıç noktasıdır. Her parçaya doküman adı, bölüm başlığı, sayfa numarası, tarih ve erişim yetkisi gibi meta veriler eklenir.

Meta veriler sadece kaynak göstermek için değil, erişim kontrolü için de kritiktir. Muhasebe biriminin bordro dokümanları ile saha ekibinin bakım talimatları aynı indekste bulunabilir, ancak sorgu anında kullanıcının yetkisine göre filtreleme yapılmalıdır. Aksi halde asistan, kullanıcının normalde erişemeyeceği bir bilgiyi 'özetleyerek' sızdırabilir. Bu, KVKK açısından da önemli bir tasarım gereksinimidir.

Her metin parçası bir embedding modeli ile sayısal bir vektöre dönüştürülür. Anlamca birbirine yakın metinler vektör uzayında da birbirine yakın düşer; bu sayede 'fatura itirazı' diye arayan bir kullanıcı, içinde 'faturaya karşı şikâyet süreci' geçen bir paragrafı da bulabilir. Türkçe içerik için çok dilli (multilingual) embedding modelleri tercih edilmeli ve seçim, şirketin kendi dokümanlarından hazırlanmış küçük bir test setiyle doğrulanmalıdır.

Vektörler pgvector eklentili PostgreSQL, Qdrant, Weaviate veya Milvus gibi bir vektör veritabanında saklanır. Halihazırda PostgreSQL kullanan bir KOBİ için pgvector, yeni bir altyapı öğrenmeden başlamanın en pratik yoludur. Doküman sayısı milyonlara çıktığında ya da düşük gecikme kritik olduğunda özel vektör veritabanları ve HNSW gibi yaklaşık en yakın komşu (ANN) indeksleri devreye girer.

Sadece vektör araması her zaman yeterli değildir: ürün kodları, sipariş numaraları, GTİP kodları veya kişi isimleri gibi birebir eşleşme gerektiren sorgularda klasik anahtar kelime araması (BM25) daha başarılıdır. Bu nedenle üretim sistemlerinde genellikle hibrit arama kullanılır: vektör ve anahtar kelime sonuçları birleştirilir, ardından bir yeniden sıralama (reranker) modeli en alakalı 5-10 parçayı seçer. Bu ek adım, cevap kalitesinde çoğu zaman modeli büyütmekten daha büyük bir fark yaratır.

Seçilen parçalar, dikkatle yazılmış bir sistem talimatıyla birlikte modele verilir: 'Yalnızca verilen kaynaklara dayanarak cevap ver; kaynaklarda bilgi yoksa bilmediğini söyle; her iddianın yanına kaynak numarasını yaz.' Bu kısıt, modelin genel bilgisinden uydurma yapmasını büyük ölçüde azaltır ve kullanıcının cevabı tek tıkla doğrulamasını sağlar.

Uzun bağlam pencereleri (128K token ve üzeri) 'bütün dokümanı modele verelim' fikrini cazip kılsa da, bu hem maliyeti hem gecikmeyi artırır; üstelik modellerin çok uzun bağlamların ortasındaki bilgiyi gözden kaçırma eğilimi ('lost in the middle') bilinen bir sorundur. İyi bir arama katmanıyla modele sadece gerekli bilgiyi vermek, hem daha hızlı hem de daha isabetli sonuç verir. Bu konunun teknik arka planını serimizin attention yazısında ele aldık.

Sayısal sorularda ek bir güvenlik katmanı öneriyoruz: stok miktarı, bakiye veya teslim tarihi gibi kritik değerler, metinden değil doğrudan ERP veya veritabanından bir araç çağrısı (tool calling) ile alınmalıdır. Model bu durumda veriyi 'hatırlayan' değil, doğru kaynaktan getirip açıklayan bir arayüz görevi görür.

Bir RAG sistemini canlıya almadan önce ölçmek gerekir. Şirketin gerçek sorularından ve doğru cevaplarından oluşan 50-200 soruluk bir değerlendirme seti hazırlanır; ardından arama isabeti (doğru parça ilk sonuçlarda mı?), cevabın kaynağa sadakati ve cevabın doğruluğu ayrı ayrı ölçülür. Ragas gibi açık kaynak araçlar bu süreci kolaylaştırır. Parçalama stratejisi, embedding modeli veya prompt değiştiğinde aynı set tekrar çalıştırılarak regresyon önlenir.

Canlı ortamda kullanıcı geri bildirimleri (beğen/beğenme), cevapsız kalan sorular ve en çok aranan konular izlenmelidir. Cevapsız kalan sorular genellikle eksik ya da güncel olmayan dokümanlara işaret eder; yani RAG sistemi, şirketin bilgi yönetimi eksiklerini de görünür hale getirir. Doküman güncellendiğinde indeksin otomatik yenilenmesi için bir senkronizasyon hattı (ör. paylaşımlı klasör veya SharePoint izleme) kurulmalıdır.

MeSoft olarak Mersin ve çevresindeki üretim, lojistik, tarım ihracatı ve hizmet şirketleri için RAG tabanlı asistanları tamamen şirket içi sunucularda, verinin dışarı çıkmadığı bir mimariyle kuruyoruz. Küçük bir doküman kümesiyle birkaç haftada sonuç veren bir pilot, yatırım kararından önce değeri somut olarak görmenin en güvenli yoludur. Serinin önceki yazılarında on-prem LLM altyapısını, PDF raporlamayı, inference optimizasyonunu ve attention mekanizmasını ayrıntılı olarak ele aldık.