# Kurumsal Yapay Zekâda RAG Ne Zaman Gerekir? > RAG hangi bilgi problemini çözer? Doğrudan belge, veritabanı, API, kurumsal arama ve yetkilendirilmiş bilgi erişimi arasından doğru yolu nasıl seçersiniz? > 💡 **Özet: Ana Çıkarımlar** > - **Her bilgi sorusu RAG gerektirmez.** Az sayıda ve sabit kaynak doğrudan modele verilebilir. Güncel işlem verisi ise API veya veritabanından okunmalıdır. > - **RAG, büyük bir belge kümesinde doğru bölümü bulma problemine yarar.** Kaynağın nerede olduğu zaten biliniyorsa ek bir arama katmanı gereksiz kalabilir. > - **Belgeyi bulmak, kullanıcıya gösterme yetkisi vermez.** Erişim izinleri belge modele ulaşmadan uygulanmalı. Arama kalitesi, güncellik ve maliyet de gerçek sorularla ölçülmelidir. Bir müşteri destek sisteminin şu üç soruyu yanıtlaması gerektiğini düşünün: 1. Bu cihazın yıllık bakımında hangi filtre kullanılmalı? 2. Siparişim şu anda nerede? 3. Sözleşmemde bu ürün için özel bir indirim var mı? Üçü de ilk bakışta bilgi sorusu. Fakat sistemin ihtiyaç duyduğu bilgiye aynı yoldan ulaşılamaz. İlk sorunun cevabı bakım kılavuzunun tek bir sayfasında olabilir. Belgeyi soruyla birlikte modele vermek yeterlidir. İkinci sorunun cevabı sürekli değişir; sipariş sisteminden veya ilgili API'den okunmalıdır. Üçüncü soruda ise hem sözleşme belgesini hem güncel müşteri kaydını kullanmak gerekebilir. Üstelik sistem bu bilgileri yalnızca görmeye yetkili kişiye göstermelidir. Bu üç soruyu da “belgeleri bir arama sistemine atalım, RAG yapalım” diyerek çözmeye çalışmak mümkündür. Fakat doğru mimari bu olmayabilir. ## RAG hangi problemi çözer? RAG (*retrieval-augmented generation*), modelin cevap vermeden önce ilgili kaynakları arayıp gerekli bölümleri bulması ve bunları cevabın bağlamına eklemesidir. Buradaki bağlam, modelin cevap üretirken önünde bulunan bilgi demektir. Kullanıcının sorusu, verilen talimatlar, bulunan belgeler, önceki mesajlar ve araçlardan dönen sonuçlar bu bağlamın parçası olabilir. Kaynak sayısı azsa arama katmanına ihtiyaç olmayabilir. Anthropic, [kendi Contextual Retrieval rehberinde](https://www.anthropic.com/engineering/contextual-retrieval){.dofollow target="_blank" rel="noopener"}, bilgi kümesi modelin bağlamına sığacak kadar küçük olduğunda tamamını doğrudan vermenin en sade çözüm olabileceğini söylüyor. Verdiği 200 bin token örneği evrensel bir sınır değil; model, maliyet, gecikme ve hata riski bu kararı değiştirir. Kaynak sayısı büyüdüğünde veya hangi bölümün gerekli olduğu önceden bilinmediğinde arama anlam kazanır. RAG bu durumda binlerce sayfanın tamamını modele göndermek yerine soruyla en ilgili bölümleri seçebilir. Yani RAG'ın çözdüğü temel problem şudur: **Modelin ihtiyacı olan bilgi büyük bir kaynak kümesinin neresinde?** Bu önemli bir problemdir. Fakat kurumsal bağlamın tamamı değildir. ## Güncel işlem verisi belge değildir Müşteri “Siparişim nerede?” diye sorduğunda cevap dün hazırlanan bir dokümanda bulunmaz. Siparişin son durumu, kargo hareketi ve teslimat tahmini operasyonel sistemlerde yaşar. Bu bilgileri düzenli aralıklarla belgeye dönüştürüp bir arama indeksine kopyalamak mümkün olabilir. Ancak o kopya daha oluşturulduğu anda eskimeye başlar. Sistem doğru belgeyi bulsa bile güncel olmayan bir cevap verebilir. Bu tür bir soruda daha güvenilir yol, sipariş numarasını doğrulayıp yetkili bir API veya veritabanı sorgusuyla mevcut durumu okumaktır. Dil modeli bulunan sonucu müşterinin anlayacağı bir cevap haline getirebilir. Bilginin kaynağı yine sipariş sistemidir. Kurumsal bir sistem bu nedenle yalnızca “hangi belgeyi bulmalıyım?” diye sormaz. Önce bilginin asıl kaynağını belirler: - Az sayıda ve sabit kaynak için doğrudan bağlam, - Çok sayıda metin belgesi için kurumsal arama veya RAG, - Güncel kayıtlar için SQL sorgusu ya da API, - Açık ve değişmez kararlar için yazılım kuralı. Model bunların birkaçını aynı cevapta kullanabilir. Hepsini aynı depoya kopyalamak zorunda değildir. ## İlgili belgeyi bulmak, o belgeyi görmeye yetkili olmak değildir Şirket içi aramada en alakalı sonuç, kullanıcının görmemesi gereken bir ücret tablosu, çalışan kaydı veya müşteri sözleşmesi olabilir. RAG sisteminin belgeyi doğru bulması bu erişimi meşru hale getirmez. Kimlik doğrulama, kullanıcı ve grup yetkileri, müşteri sınırları ve belge izinleri ayrıca uygulanmalıdır. AWS, Bedrock Knowledge Base içindeki belge izin filtrelerinin [tek başına bir yetkilendirme sınırı olmadığını](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-ds-custom-acl.html){.dofollow target="_blank" rel="noopener"} açıkça belirtiyor. Servis, uygulamanın gönderdiği kullanıcı bilgisinin gerçek olup olmadığını doğrulayamıyor. Kullanıcıyı doğrulama sorumluluğu uygulamada kalıyor. Azure AI Search ise belge izinlerini arama indeksinde tutup sorgu sırasında kullanıcı kimliğiyle eşleştirebiliyor. Ancak [kaynak sistemde değişen bir iznin arama sonucuna yansıması](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview){.dofollow target="_blank" rel="noopener"}, izin bilgisinin indekse yeniden aktarılmasına bağlı. Başka bir deyişle doğru yetki modeli kadar bu modelin ne kadar güncel olduğu da önemlidir. Buradaki sınır net: > Arama sistemi bir belgeyi bulur. Yetkilendirme, o belgenin bu kullanıcı için bulunabilir olup olmadığına karar verir. Yetkisiz bir belge önce modele verilip cevap üretildikten sonra filtrelenmemelidir. Belge daha aday sonuçlar arasına girmeden elenmelidir. ## Daha fazla bağlam her zaman daha iyi cevap üretmez Modelin bağlam penceresi büyüdükçe bütün belgeleri tek seferde vermek cazip hale geliyor. Bazı küçük ve sabit bilgi kümelerinde bu gerçekten daha sade ve daha iyi bir çözüm olabilir. Fakat bağlam kapasitesi ile bağlam kalitesi aynı şey değildir. İlgisiz metin arttığında modelin doğru bilgiyi ayırt etmesi zorlaşabilir. [RAG ile uzun bağlamı karşılaştıran bir araştırmada](https://aclanthology.org/2024.emnlp-industry.66/){.dofollow target="_blank" rel="noopener"}, yeterli kaynak ayrıldığında uzun bağlam kullanılan yöntemler birçok testte daha iyi sonuç vermiş; RAG ise belirgin bir maliyet avantajı sağlamış. Sonuç, “RAG bitti” veya “uzun bağlam işe yaramaz” değil. İki yaklaşımın başarısı soruya, kaynağa, modele ve maliyet sınırına göre değişiyor. Aynı belgenin parçalara nasıl ayrıldığı, kelime ve anlam aramasının birlikte kullanılıp kullanılmadığı ve ilk sonuçların yeniden sıralanması da kaliteyi etkiler. Microsoft'un [RAG bilgi erişimi rehberi](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-information-retrieval){.dofollow target="_blank" rel="noopener"}, yeniden sıralamanın daha alakalı sonuçlar sağlayabildiğini fakat her sorguya ek gecikme getirdiğini vurguluyor. Bu nedenle kelime araması, anlam benzerliğine göre arama veya sonuçları ikinci kez sıralayan ek bir model, birer olgunluk seviyesi değildir. Her biri belirli bir arama hatasını çözmek için eklenen yöntemdir. Basit arama çalışıyorsa daha karmaşık olanı kullanmak sistemi daha kurumsal yapmaz. ## RAG kurmadan önce verilecek karar Bir şirketin önce “RAG yapalım mı?” diye sorması gerekmiyor. Daha faydalı soru şu: **Bu iş için gerekli doğru ve yetkili bilgi, ihtiyaç anında sisteme hangi yoldan ulaşmalı?** Bilgi küçük ve sabitse doğrudan vermek yeterli olabilir. Çok sayıda metin belgesi arasında aranacaksa RAG veya kurumsal arama anlamlı olabilir. Güncel işlem durumu gerekiyorsa kaynak sisteme sorgu yapılmalıdır. Kullanıcının görebileceği bilgi değişiyorsa izinler arama yapılmadan önce uygulanmalıdır. RAG bu seçeneklerden biridir. Doğru yerde güçlüdür; her veri probleminin ortak adı haline geldiğinde ise asıl kaynağı, yetkiyi ve güncelliği gizlemeye başlar. [Fine-tuning, doğrudan bağlam ve RAG arasındaki sınırı önceki yazıda bilgi, kural ve öğrenilecek örüntü üzerinden ele aldım](/tr/kuruma-ozel-yapay-zeka-icin-fine-tuning-sart-mi). Model, bilgi, yetki ve ölçümle ilgili diğer kararları [yapay zekâ sistemi tasarlama rehberinde](/tr/sirketiniz-icin-yapay-zeka-sistemi-nasil-tasarlanir) bir arada görebilirsiniz. --- Language: Turkish License: CC BY 4.0 License URL: https://creativecommons.org/licenses/by/4.0/ Scope: Evren Bal-authored text, unless this article expressly states otherwise. Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights. Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes. Source: https://evrenbal.com/tr/kurumsal-yapay-zekada-rag-ne-zaman-gerekir