RAG Mimarisi Kurumsal Bilgiyi Nasıl Dönüştürür — ve Nerede Biter?

Piyasada RAG mimarisi çoğu zaman tek bir vaatli cümleyle satılıyor: ‘modele kendi belgelerinizi öğretin, halüsinasyonlar biter.’ Bu cümle hem doğru hem yanıltıcı — ve bu gerilimi anlamadan RAG projesine bütçe ayıran her şirket, aynı hayal kırıklığıyla karşılaşıyor. Konya’da makine imalatı yapan, 295 çalışanlı bir üretici geçen yıl RAG tabanlı bir teknik destek asistanı kurdu. Altı ay sonra sistemin kullanım oranı beklenenin çok altındaydı. Teknik altyapı sağlamdı. Sorun başka bir yerdeydi.RAG’ın açılımı ‘Retrieval-Augmented Generation’ — erişim destekli üretim. Sistem iki parçadan oluşuyor: bir arama katmanı (retrieval) ve bir üretim katmanı (generation). Kullanıcı soru sorduğunda model, önce kurumun kendi belgelerini — teknik kılavuzlar, bakım prosedürleri, geçmiş proje notları, tedarikçi anlaşmazlık kayıtları — tarayarak ilgili pasajları bulur; ardından bu pasajları bağlam olarak kullanarak yanıt üretir. Bu yaklaşım iki somut sorunu çözüyor: modelin eğitim kesim tarihinden sonraki bilgiye erişmesi ve kuruma özgü gizli bilgiyi genel modelin içine gömmek yerine kontrollü biçimde sunması. İkincisi özellikle kritik — zira genel LLM’ye özel belge eğitimi hem maliyetli hem KVKK açısından riskli.Konya’daki makine üreticisine dönersek: şirketin teknik belge arşivi 11 yıllık PDF yığınından oluşuyordu. Taranmış el kitapları, birbirini çelen revizyon notları, farklı mühendisler tarafından farklı formatlarda oluşturulmuş bakım kılavuzları. RAG sistemi bu belgeleri vektör veritabanına dönüştürdü ve sorgulamaya açtı. Ne var ki retrieval katmanı alakasız pasajları sık sık üst sıraya taşıyordu çünkü belgeler arasında tutarsız terminoloji vardı: aynı parça üç farklı isimle anılıyordu. Sistem teknik olarak çalışıyordu — ama çıktıların %63’ü teknik servis ekibinin doğrulama yapmadan kullanamayacağı yanıtlar içeriyordu. Mühendisler sistemi terk etti. Arıza değil; veri kalitesi sorunu.Bu örnek RAG mimarisinin en sık yanlış anlaşılan boyutunu gösteriyor: değer, modelde değil, belge katmanının nasıl yapılandırıldığında yatıyor. Retrieval kalitesi doğrudan chunk stratejisine, belge temizliğine ve metadata zenginliğine bağlı. Pratik adımlar şunlar: ilk olarak belge envanteri yapın — hangi belgeler güncel, hangisi eskimiş, hangi terminoloji standardı benimseniyor? İkinci adım, chunk boyutunu içerik türüne göre ayarlayın; prosedürel metinler için daha küçük (256-512 token), bağlamsal belgeler için daha büyük parçalar genellikle daha iyi retrieval skoru veriyor. Üçüncü adım, her chunk’a sektöre özgü metadata etiketleyin: ‘makine tipi’, ‘revizyon tarihi’, ‘uygulanan standart’ gibi alanlar. Bu etiketler, hybrid search — hem anlamsal hem anahtar kelime bazlı — stratejisinde filtreleme gücü sağlar. Dördüncü adım, retrieval çıktısını ölçün: her sorgu için ilk üç pasajın ilgili olup olmadığını bir değerlendirme veri setiyle düzenli test edin. Bu adım atlanırsa sistem çürüyor ama kimse fark etmiyor.Tedarik zinciri bağlamında RAG’ın en somut değer ürettiği alan, tedarikçi yönetimi bilgisidir. Türkiye’deki üretim şirketlerinin büyük çoğunluğu tedarikçi iletişim geçmişini e-posta arşivlerinde, kalite raporlarını ayrı bir klasörde, sözleşme şartlarını farklı bir sistemde tutuyor. Bir satın alma uzmanı gecikmeli teslimat için tedarikçiye başvurduğunda, geçmişi aramak için üç farklı kaynağa bakması gerekiyor. RAG bu dağınıklığı çözebilir — ama yalnızca belgeler sisteme düzgün beslenmişse. Örnek bir yapıda: tedarikçi başına ayrı bir koleksiyon, her koleksiyonda sözleşme, kalite kayıtları ve iletişim özetleri ayrı chunk grupları olarak tanımlı. Bu yapı kurulduğunda ‘Bu tedarikçi geçen yıl kaç kez gecikti, gecikme nedenleri nelerdi?’ sorusu saniyeler içinde yanıt alıyor — ve yanıt, modelin yarattığı değil, şirketin kendi verisinden derlenen bir özet oluyor. Ölçüm basit: kullanıcıların yanıtı doğrulamak için başka bir kaynağa gidip gitmediğini takip edin. Gitmiyorlarsa retrieval işe yarıyor demektir.Şimdi dürüst bir çekince: RAG her kurumsal bilgi sorununu çözmez. Bunu açıkça söylemek gerekiyor, çünkü vendor sunumlarında bu sınır nadiren görünür. Yapılandırılmamış, birbiriyle çelişen ve güncellenmemiş belge tabanında RAG yalnızca pahalı bir arama motoruna dönüşür — üstelik yanıtı mantıklı bir cümleyle sunan, bu yüzden yanlışı daha inandırıcı hissettiren bir motor. EU AI Act’ın 2025’teki yürürlük süreciyle birlikte, yüksek riskli iş akışlarında AI çıktısının insan denetimiyle kontrol edilmesi zorunluluğu pratikte daha fazla önem kazandı. Üretim ortamında bir bakım talimatı yanlışsa makine durabilir; bir tedarikçi termin tarihi hatalıysa hat bekleyebilir. Bu nedenle RAG çıktılarını ham yanıt olarak değil, ‘araştırma taslağı’ olarak konumlandıran şirketler, kullanıcı güvenini daha sağlıklı kuruyorlar. Ayrıca veri egemenliği sorusu: Türkiye’deki şirketlerin büyük bölümü belge verisini offshore bulut ortamına göndermek istemiyor. Bu noktada on-premise veya Türkiye veri merkezi seçeneklerinin maliyet farkı ciddi — ve 2025 itibarıyla bu farkı karşılayabilecek yerel model seçenekleri büyüyor, ama henüz her ölçek için uygun değil.RAG’ın gerçek testi şu soruyu yanıtlamaktır: bu sistemin olmadığı haftayla olduğu haftayı karşılaştırabilir misiniz? Eğer farkı ölçemiyorsanız — kaç sorgu yanıtlandı, kaçı eskalasyon gerektirdi, ortalama yanıt doğruluğu ne oldu — sisteminiz üretimde değil, gösterimde yaşıyor demektir. Konya’daki makine üreticisi ikinci çeyrekte belge standardizasyonu projesine başladı; tek terminoloji sözlüğü oluşturdu, eski PDF’leri yeniden işledi ve her belgeye zorunlu metadata alanı tanımladı. Altı ay sonra aynı RAG altyapısıyla retrieval isabeti %72’ye çıktı ve teknik servis ekibi sistemi günlük iş akışına entegre etti. Mimari değişmemişti. Veri değişmişti.