içindekiler
- RAG nedir, açılımı ne anlama gelir?
- RAG nasıl çalışır?
- RAG ile fine-tuning (ince ayar) arasındaki fark nedir?
- RAG için vektör veritabanı şart mı?
- RAG hangi işlerde şirkete değer katar?
- RAG, chatbot ve yapay zekâ ajanından nasıl ayrılır?
- Bir RAG sistemi için neler gerekir?
- RAG için belgeler nasıl hazırlanmalı?
- RAG asistanında her kullanıcı yalnızca yetkili olduğu belgeyi görebilir mi?
- RAG'de kaynak gösterme nedir, neden gerekir?
- RAG'in isabetini hangi soru setiyle ölçeceksiniz?
- Belgeler değişince RAG dizini nasıl güncellenecek?
- RAG nerede yanlış gider?
- RAG halüsinasyonu tamamen önler mi?
- RAG kurarken KVKK açısından veriler nerede durur?
- Basit bir arama ya da SSS sayfası ne zaman RAG'den daha iyidir?
- RAG projesinin maliyetini ve süresini ne belirler?
- Bir RAG projesine nasıl başlanır?
- RAG projesi için yazılım firmasına hangi soruları sormalısınız?
- RAG projelerinde sık yapılan hatalar nelerdir?
- RAG ne zaman kurulmamalı, UlvionTech ile ne zaman çalışmamalısınız?
RAG (retrieval-augmented generation, Türkçesiyle getirme destekli üretim), bir yapay zekâ dil modelinin soruyu cevaplamadan önce şirketinizin belgelerinde arama yapıp ilgili parçaları bulması ve cevabını bu parçalara dayandırmasıdır. Model yeniden eğitilmez: prosedürler, sözleşmeler ya da ürün dokümanları her soruda modele bağlam olarak verilir ve cevap, dayandığı kaynakla birlikte döner.
Bir yöneticiye RAG'i anlatacak olsam önce şunu söylerdim: bu işin zor kısmı model değil, belgelerdir. Belgeler dağınıksa, aynı prosedürün üç sürümü yan yana duruyorsa ya da gizli bir klasör herkese açıksa, en yetenekli dil modeli bile yanlış ya da yetkisiz bir cevabı ikna edici bir dille verebilir. Bu yüzden bir RAG projesine "hangi modeli kullanalım?" sorusuyla değil, "hangi belgeler, kimin için ve ne kadar güncel?" sorusuyla başlardım.
RAG nedir, açılımı ne anlama gelir?
RAG, İngilizce retrieval-augmented generation ifadesinin kısaltmasıdır ve bir dil modelinin dışarıdaki bir bilgi kaynağından getirdiği metinlerle cevap üretmesini anlatır. Terim, Patrick Lewis ve arkadaşlarının NeurIPS 2020'de yayımlanan Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (yeni sekmede açılır) makalesinden gelir. Makale, modelin eğitimle edindiği bilgiyi (parametrik bellek) Wikipedia'dan oluşturulmuş yoğun bir vektör dizinine dayanan ayrı bir bilgi deposuyla (parametrik olmayan bellek) birleştirir. Makaledeki yöntemde getirici ve üretici birlikte ince ayarlanır; şirket kullanımında ise çoğunlukla hazır bir dil modeli yeniden eğitilmeden kullanılır ve bilgi deposu Wikipedia değil, sizin belgelerinizdir.
RAG'in bir yönetici için pratik anlamı şudur: dil modeli genel dil becerisini getirir, şirkete özgü bilgiyi ise her soruda belgelerinizden alır. Model, izin prosedürünüzü ya da bir ürününüzün teknik şartnamesini eğitiminden bilemez; RAG bu bilgiyi soru anında modelin önüne koyar. Lewis ve arkadaşlarının makalesi, büyük dil modellerinde cevabın kaynağını göstermenin ve bilgiyi güncellemenin açık sorunlar olduğunu yazar ve RAG'i bu sorunlara bir yaklaşım olarak önerir. Benim için RAG'in bilgiyi modelin dışında tutmasının önemi şurada: RAG kaynağı gösterilebilir kılar, ama gösterilen kaynağın isabetli ve güncel olmasını sizin belge düzeniniz belirler.
RAG nasıl çalışır?
RAG dört adımda çalışır: belgeler parçalara bölünüp dizinlenir, soru gelince en ilgili parçalar getirilir, bu parçalar soruyla birlikte dil modeline verilir ve model cevabı kaynak göstererek yazar. Dizin bir kez kurulur ve belgeler değiştikçe güncellenir; getirme ve üretim ise her soruda yeniden yapılır. RAG'in adımları sırasıyla şunlardır:
- Hazırlama ve parçalama: Belgeler (PDF, ofis belgeleri, wiki sayfaları, e-postalar) metne çevrilir ve anlamlı parçalara bölünür; her parçaya kaynak belge, tarih ve erişim yetkisi bilgisi eklenir.
- Dizinleme: Her parça, anlamını sayısal olarak temsil eden bir vektöre (embedding) çevrilir ve aranabilir bir dizine yazılır. Böylece "yıllık izin" diye sorulan soru, belgede "senelik izin" yazsa da bulunabilir.
- Getirme: Kullanıcı soru sorduğunda sistem, o kullanıcının görmeye yetkili olduğu parçalar arasından soruya en yakın olanları seçer.
- Üretim: Seçilen parçalar bir talimatla birlikte dil modeline gönderilir; model cevabı bu parçalara dayanarak yazar ve kullandığı belgeleri listeler.
Getirme adımındaki yetki filtresi, sonradan eklenecek bir özellik değil, ilk günden mimarinin parçası olmalıdır. Getirme adımı yetkiyi kontrol etmezse model, kullanıcının hiç açamayacağı bir belgenin içeriğini cevabın içine yazabilir. Üretim adımındaki "yalnızca bu parçalara dayan" talimatı da bir garanti değil, bir yönlendirmedir; model yine de parçalarda olmayan bir bilgi ekleyebilir. RAG cevabının yanında kaynak listesini göstermek, kullanıcıya cevabı belgeyle karşılaştırma imkânı verir.

RAG ile fine-tuning (ince ayar) arasındaki fark nedir?
RAG ile ince ayar arasındaki fark, bilginin nerede durduğudur: RAG'de bilgi modelin dışında, değiştirilebilir bir dizindedir; ince ayarda ise modelin kendisi ek veriyle yeniden eğitilir. Kişisel Verileri Koruma Kurumu'nun (KVKK) Kasım 2025 tarihli üretken yapay zekâ rehberi ince ayarı, bir temel modelin belirli bir görev için gözetimli öğrenme yoluyla daha fazla eğitilmesi olarak tanımlar. Prosedür değişince RAG'de belgeyi ve dizini güncellemek yeter; ince ayar yapılmış bir modelde ise yeniden eğitim gerekir ve modelin bir bilgiyi nereden öğrendiğini göstermek zorlaşır. Şirket bilgisine dayalı soru-cevapta önce RAG'i, üslup ya da çıktı biçimi değişecekse ince ayarı denerdim.
RAG için vektör veritabanı şart mı?
RAG için ayrı bir vektör veritabanı ürünü şart değildir; şart olan, belge parçalarını soruya göre hızlıca bulan ve kullanıcının yetkisine göre süzen bir dizindir. Küçük bir belge setinde bu dizin, mevcut veritabanınıza eklenen bir vektör arama özelliğiyle ya da klasik anahtar kelime aramasını anlam tabanlı aramayla birleştiren bir yapıyla kurulabilir. Belge sayısı, eş zamanlı kullanıcı ve güncelleme sıklığı arttıkça ayrı bir dizin servisi mantıklı hâle gelir. Bu kararın ilk gün değil, pilotta ölçülen yanıt süresine ve isabete bakılarak verilmesi daha sağlıklıdır.
RAG hangi işlerde şirkete değer katar?
RAG, cevabı şirket belgelerinde yazılı olan ve aynı sorunun farklı kişilerce tekrar tekrar sorulduğu işlerde değer katar. Bir çalışan cevabı bulmak için bir meslektaşına soruyor ya da birkaç klasör açıyorsa ve cevap bir belgede yazılıysa, RAG o arama süresini kısaltabilir. Cevap bir kişinin kararına, anlık bir sistem verisine ya da yazıya geçmemiş bir alışkanlığa dayanıyorsa RAG bunu üretemez. RAG'in tipik kullanım alanları şunlardır:
- İç prosedür ve politika soruları: İzin, masraf, satın alma onayı ya da bilgi güvenliği kuralları gibi el kitabında yazan ama kimsenin ezbere bilmediği konular.
- Teknik doküman ve ürün bilgisi: Satış ve destek ekiplerinin kurulum kılavuzu, şartname ya da sürüm notlarında cevap araması.
- Sözleşme ve şartname arama: "Bu tedarikçi sözleşmesinde cezai şart ne diyor?" gibi bir sorunun ilgili maddeyi kaynak göstererek bulunması; maddenin yorumu yine hukukçunun işidir.
- Yeni çalışanın alışması: Dağınık eğitim belgelerinin tek bir soru kutusundan aranabilmesi.
- Müşteriye dönük cevap taslağı: Destek ekibinin, ürün belgelerine dayanan bir cevap taslağını göndermeden önce kontrol etmesi.
İlk pilot için en hızlı karşılığı iç prosedür sorularında beklerdim: belgeler tek bir birime aittir, beklenen cevap nettir ve yanlış bir cevabın etkisi sınırlı kalır.
RAG, chatbot ve yapay zekâ ajanından nasıl ayrılır?
RAG bir bilgi getirme yöntemidir; chatbot konuşmanın geçtiği kanal, yapay zekâ ajanı ise sistemlerde işlem yapan yazılımdır. Bir chatbot cevaplarını sabit kurallardan, sık sorulan sorulardan ya da RAG ile belgelerden alabilir; bu ayrımı kanal tarafından WhatsApp chatbot nasıl yapılır yazısında anlattık. Bir yapay zekâ ajanı ise cevap vermekle kalmaz, sistemlerde işlem yapar; RAG bir ajanın bilgi kaynağı olabilir ama tek başına işlem yapmaz. Hangi süreçle başlayacağınızı seçmek için şirketlerde yapay zekâ otomasyonu rehberindeki ölçütleri de kullanabilirsiniz.
Bir RAG sistemi için neler gerekir?
Bir RAG sisteminin güvenilir çalışması için beş şey gerekir: temiz ve güncel belgeler, kullanıcı bazlı erişim yetkisi, cevapta kaynak gösterme, bir değerlendirme soru seti ve belgeler değiştiğinde dizini güncelleyen bir yol. Bu beşinden biri eksik olan bir RAG sistemi demoda iyi görünse de günlük kullanımda güven kaybetme riski taşır.
RAG için belgeler nasıl hazırlanmalı?
RAG için her belgenin bir sahibi, bir geçerlilik tarihi ve tek bir yürürlükteki sürümü olmalıdır; aynı prosedürün üç farklı sürümü klasörde duruyorsa sistem eskisini getirebilir. KVKK rehberi, "doğru ve gerektiğinde güncel olma" ilkesi altında, eğitim verilerinin kaynağının kayıt altına alınmasını ve eksik, hatalı ya da güncelliğini yitirmiş bilgilerin ayıklanmasını örnek uygulamalar olarak sayar. Aynı ilkeyi RAG'e alınan belgelere uygulamak bana yerinde görünüyor. Taranmış PDF'lerin önce metne çevrilmesi gerekir; tablolar ve el yazısı notlar bu adımda bilgi kaybedebilir.
RAG asistanında her kullanıcı yalnızca yetkili olduğu belgeyi görebilir mi?
Evet, yetki ilk günden mimariye kurulursa görebilir; RAG asistanındaki erişim yetkisi, belge sisteminizdeki yetkinin aynısı olmalıdır: insan kaynakları klasörünü açamayan bir çalışan, asistan üzerinden de o klasördeki bir maaş tablosunun içeriğine ulaşamamalıdır. Bunun için her belge parçası dizine yetki bilgisiyle yazılır ve getirme adımı, soruyu soranın kimliğine göre süzülür. Yetkiler kaynak sistemde değiştiğinde dizinin de güncellenmesi gerekir; aksi hâlde rolü değişen ya da işten ayrılan biri eski yetkisiyle cevap almaya devam eder. Belgelerin hepsi herkese açık değilse, tek bir "herkes her şeyi görür" dizini kuran bir mimari kabul edilmemelidir.
RAG'de kaynak gösterme nedir, neden gerekir?
Kaynak gösterme, RAG cevabının hangi belgenin hangi bölümüne dayandığını kullanıcıya bağlantı ya da alıntıyla göstermesidir. Kullanıcı cevabı belgeyle karşılaştırabildiğinde yanlış bir cevap fark edilir; fark edilemeyen yanlış cevap ise sessizce yayılır. ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) Temmuz 2024 tarihli üretken yapay zekâ risk profili (NIST AI 600-1) (yeni sekmede açılır), önerilen eylemler arasında RAG'de kullanılan verinin dayanaklı olduğunun doğrulanmasını sayar. Kaynak göstermeyen bir şirket asistanına, cevabı ne kadar akıcı olursa olsun, karar verdiren bir işte güvenmezdim.
RAG'in isabetini hangi soru setiyle ölçeceksiniz?
RAG için değerlendirme seti, çalışanların sorduğu ya da soracağı sorulardan ve her birinin belgeye dayalı beklenen cevabından oluşan bir listedir; sistemin isabeti bu listeyle ölçülür. Set, sık sorulan sorular kadar cevabı belgelerde olmayan ve sistemin "bilmiyorum" demesi gereken soruları da içermelidir. NIST AI 600-1, RAG uygulandıktan sonra model risklerinin yeniden değerlendirilmesini önerir. Ben bir adım ileri gider, aynı seti her belge güncellemesinden, model değişikliğinden ve ayar değişikliğinden sonra yeniden çalıştırırdım. Setin beklenen cevaplarını yazılım ekibi değil, belgeyi bilen birim yazmalıdır.
Belgeler değişince RAG dizini nasıl güncellenecek?
RAG'de güncelleme yolu, bir belge eklendiğinde, değiştiğinde ya da kaldırıldığında dizinin ne zaman ve nasıl yenileneceğini tanımlar. Bunun iki yaygın biçimi vardır: belge sisteminden gelen bir değişiklik bildirimiyle anında güncelleme ya da belirli aralıklarla yapılan toplu tarama. Silme ayrıca önemlidir; yürürlükten kalkmış bir yönetmelik dizinde kalırsa asistan onu kaynak göstermeye devam eder. Bir pilotta bile "bu belgeyi değiştirirsem asistan yeni hâlini ne zaman görür?" sorusunun yazılı bir cevabı olmalıdır.

RAG nerede yanlış gider?
RAG'in tipik olarak yanlış gittiği beş nokta şunlardır: yanlış belgeyi getirmek, eski bir sürümü kaynak göstermek, kullanıcının yetkisi olmayan bir belgeyi cevaba taşımak, belgede olmayan bir bilgiyi kendinden emin bir dille eklemek ve kapsam dışındaki bir soruyu tahminle cevaplamak. Bu hataların kaynağı çoğu zaman model değil, getirme adımı ve belge düzenidir. RAG hatalarının belirtileri, muhtemel nedenleri ve önlemleri şöyle özetlenebilir:
| Belirti | Muhtemel neden | Önlem | |
|---|---|---|---|
| Yanlış kaynak | Cevap akıcı ama ilgisiz bir belgeye dayanıyor. | Parçalar çok büyük ya da çok küçük; başlık ve bağlam kaybolmuş. | Parçalama ayarını değerlendirme setiyle test edin; kaynağı gösterin. |
| Eski belge | Cevap yürürlükten kalkmış bir prosedürü anlatıyor. | Aynı belgenin birden çok sürümü dizinde duruyor. | Tek yürürlükteki sürüm, geçerlilik tarihi ve silme adımı. |
| Yetkisiz belge sızıntısı | Cevapta kullanıcının açamadığı bir belgenin içeriği var. | Getirme adımı yetkiye göre süzmüyor. | Parça düzeyinde yetki etiketi, kaynak sistemle eşitleme, erişim kaydı. |
| Kendinden emin yanlış cevap | Cevap ikna edici ama belgede böyle bir bilgi yok. | Model, getirilen parçaların dışına çıkıyor. | Kaynağa dayanma talimatı, kaynak gösterme, düzenli örnek denetimi. |
| Kapsam dışı soru | Belgelerde olmayan bir soruya tahminî cevap geliyor. | Sistem "bilmiyorum" diyecek şekilde kurulmamış. | Benzerlik eşiğinin altında cevap vermeme, insana yönlendirme. |
RAG hatalarına karşı alınan önlemlerin hiçbiri tek başına yeterli değildir. NIST AI 600-1, kendinden emin bir dille sunulan hatalı ya da uydurma içeriğe "confabulation" der. Ben bu hatayı en yanıltıcısı sayardım, çünkü dili isabetli cevaplardan farksızdır. Bir pilotta en az üç davranışı birlikte görmek isterdim: kaynak gösterme, yetkiye göre süzme ve cevabı belgede olmayan sorulara "bilmiyorum" deme.
RAG halüsinasyonu tamamen önler mi?
Hayır, RAG halüsinasyonu tamamen önlemez; cevabı belgelere dayandırmayı amaçlar ve kaynak göstererek cevabı kontrol edilebilir kılar. KVKK rehberi halüsinasyonu, gerçek görünümlü ama gerçekte yanlış çıktılar olarak tanımlar ve eğitim verilerinin doğruluğunun bu riski tamamen ortadan kaldıramasa da olasılığını azaltabileceğini belirtir. Aynı mantığın RAG'de modele verilen belgeler için de geçerli olduğunu düşünüyorum. KVKK rehberi ayrıca kişisel veri içeren çıktıların düzenli izlenmesini ve gerektiğinde insan gözetimini önerir; RAG bu gözetimi gereksiz kılmaz, yalnızca kolaylaştırabilir.
RAG kurarken KVKK açısından veriler nerede durur?
Bir RAG sisteminde kişisel veri dört yerde durabilir: kaynak belgelerde, belge parçalarından oluşan dizinde, soruların ve cevapların tutulduğu kayıtlarda ve her soruda bağlamın gönderildiği dil modeli servisinde. Bu dört yerin her biri için verinin hangi ülkede, kimin sunucusunda ve ne kadar süre tutulduğu yazılı olmalıdır. Bir RAG mimarisini, bu dört yeri gösteren bir sayfalık veri akış çizimini görmeden onaylamazdım; KVKK sorularının cevabı o çizimden çıkar.
Kişisel Verileri Koruma Kurumu'nun 24 Kasım 2025'te yayımladığı Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (yeni sekmede açılır), Ekim 2026 itibarıyla üretken yapay zekâ ve kişisel veri konusunda başvurulacak resmî kaynaklardan biridir. Rehberin RAG projeleri için öne çıkan noktaları şunlardır:
- Veri sorumlusu ve veri işleyen: Rehbere göre bu rolleri sözleşmedeki ifadeler değil, veri işleme üzerindeki fiilî kontrol ve karar yetkisi belirler. Belgelerinizin hangi amaçla işleneceğine siz karar veriyorsanız, sistemi kuran yazılım firmasının ve model servisinin konumunu hukukçunuzla birlikte belirleyin.
- Yurt dışına aktarım: Türkiye'deki bir veri sorumlusu, yurt dışında yerleşik bir hizmet sağlayıcının yapay zekâ sistemini kullanıyor ve kişisel veri yurt dışına gidiyorsa bu bir yurt dışına aktarımdır. Aktarım 6698 sayılı Kanun'un 9'uncu maddesine ve 10 Temmuz 2024'te Resmî Gazete'de yayımlanan Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmelik'e uygun olmalıdır.
- Doğruluk ve izleme: Kişisel veri içeren çıktıların düzenli izlenmesi ve gerektiğinde insan gözetimiyle desteklenmesi önerilir.
- Güvenlik ve kayıt: Rehber, yetkisiz erişime karşı çok faktörlü kimlik doğrulama gibi yöntemleri ve veri işleme faaliyetlerine ilişkin işlem kayıtlarıyla sistem günlüklerinin tutulmasını sayar.
Ben olsam ilk sürümde kişisel veri içeren belgeleri dizine almaz, pilotu prosedür ve ürün belgeleriyle başlatırdım; kişisel veri gerekiyorsa veri akışı ve aktarım dayanağı önceden yazılmalıdır. Model servisinin girdileri saklayıp saklamadığı, saklıyorsa ne kadar süre ve hangi ülkede tuttuğu, sözleşmede ve servis belgelerinde açıkça okunmalıdır.
Web sitesi ve uygulama tarafındaki KVKK kontrollerini web sitesi KVKK uyumu yazısında ayrıca ele aldık. RAG ve KVKK hakkındaki bu bilgiler hukuki görüş değildir; kendi durumunuz için bir KVKK avukatına danışın.
Basit bir arama ya da SSS sayfası ne zaman RAG'den daha iyidir?
Sorular az, cevaplar kısa ve sabitse, iyi düzenlenmiş bir sık sorulan sorular (SSS) sayfası ya da belge sistemindeki klasik arama, RAG'den daha ucuz ve daha öngörülebilir bir çözümdür. RAG'in farkı, sorunun belgedeki kelimelerle sorulmadığı, cevabın birkaç belgeye dağıldığı ve belge sayısının bir kişinin hatırlayabileceğinden fazla olduğu durumlarda ortaya çıkar. Bir RAG projesine başlamadan önce, en sık sorulan soruların ne kadarının bir SSS sayfasıyla çözüldüğüne bakmanızı öneririm. SSS sayfası, klasik arama, hazır asistan ve özel RAG seçeneklerini aynı ölçütlerle yan yana koymak kararı kolaylaştırır:
| Ne zaman uygun | Zayıf kaldığı yer | Veri ve maliyet | |
|---|---|---|---|
| Özel yazılmış RAG | Belge çok, sorular serbest dilde, yetki kuralları şirkete özgü, cevap kendi sistemlerinizle birleşmeli. | İlk sürüm daha uzun sürer; belge düzeni ve değerlendirme seti emek ister; şirket içinde bir sahibi olmalı. | Veri yeri ve model servisi sizin seçiminiz; kullanıcı başına lisans ücreti yok, model kullanım ücreti soru hacmine bağlı; kod, sunucu ve alan adı sizin adınıza. |
| Hazır yapay zekâ asistanı (abonelikli) | Belgeler tek bir depoda, yetkiler standart, amaç hızlı bir deneme. | Yetki ve kaynak gösterme ürünün ayarlarıyla sınırlı; kendi sistemlerinize bağlantı ürünün desteklediği kadar. | Veri çoğunlukla sağlayıcının altyapısında durur; kullanıcı başına lisanslanan ürünlerde ücret kullanıcı sayısıyla artar. |
| Klasik arama | Kullanıcı aradığı belgenin adını ya da içindeki kelimeleri biliyor. | Eş anlamlı ifadeleri ve birkaç belgeye dağılmış cevabı bulamaz. | Belge sisteminizde çoğunlukla zaten vardır; ek maliyeti düşüktür. |
| SSS sayfası | Soru sayısı az, cevaplar kısa ve nadiren değişiyor. | Listede olmayan soruya cevap vermez; güncel tutulmazsa eskir. | Yazılım maliyeti düşük; bakımı insan emeğidir. |
SSS sayfası, klasik arama, hazır asistan ve özel RAG arasında seçim yapmak için şu kuralları kullanabilirsiniz:
- SSS sayfası seçin, eğer sorular sınırlıysa ve cevaplar her çalışan için aynıysa.
- Klasik aramayı iyileştirin, eğer asıl sorun belgelerin içeriği değil, dağınık adlandırılmış olmalarıysa.
- Hazır bir asistanla deneyin, eğer belgeler zaten tek bir depodaysa, yetkiler basitse ve amaç fikri hızlıca sınamaksa.
- Özel bir RAG sistemi yazdırın, eğer yetki kurallarınız şirketinize özgüyse, verinin nerede durduğu sizin için bir şartsa, cevaplar ERP, CRM ya da kendi veritabanınızla birleşmeliyse ve kullanıcı sayısı büyüdükçe artan bir abonelik ücreti istemiyorsanız.
Yetki kuralları şirkete özgü ve verinin nerede durduğu bir şart olduğunda, özel yazılmış bir RAG sisteminin avantajları belirgindir: yetki kurallarını bir ürünün ayarlarına göre değil şirketinizin kurallarına göre yazarsınız ve verinin hangi ülkede, kimin sunucusunda duracağını siz seçersiniz. Sistem kendi markanız ve alan adınız altında çalışır; ihtiyaç değiştiğinde bir ürün yol haritasını beklemezsiniz. Yapay zekâ destekli geliştirme araçlarının ilk sürümü yazmanın maliyetini düşürebildiğini de düşünüyorum. Özel yazılımın bedeli de vardır: ilk sürüm hazır bir ürünü açmaktan daha uzun sürer ve sistemi şirket içinde sahiplenen biri gerekir.
Yetki kuralları karmaşık bir şirkette özel yazılmış bir RAG sistemini tercih ederdim; genel karşılaştırma için özel yazılım mı hazır yazılım mı rehberine bakabilirsiniz.
RAG projesinin maliyetini ve süresini ne belirler?
Bir RAG projesinin maliyetini ve süresini en çok belgelerin durumu, yetki modelinin karmaşıklığı ve bağlanacak sistem sayısı belirler; model seçimi bu listenin yalnızca bir kalemidir. Rakamı belgeleri ve soruları görmeden söylemek mümkün değildir, ama bir RAG teklifini büyüten ya da küçülten kalemler bellidir:
- Belge biçimi ve temizliği: Düzgün metin belgeleri hızlı işlenir; taranmış PDF'ler, tablo ağırlıklı dosyalar ve aynı belgenin çok sayıda sürümü süreyi uzatır.
- Yetki modeli: Herkesin aynı belgeleri gördüğü bir set basittir; birim, rol ya da proje bazlı yetki ve kaynak sistemle eşitleme işi büyütür.
- Entegrasyon: Cevabın ERP, CRM ya da bir veritabanındaki canlı veriyle birleşmesi her bağlantı için ayrı iş demektir; API nedir yazısındaki entegrasyon kalemleri burada da geçerlidir.
- Değerlendirme seti: Beklenen cevapları belgeyi bilen birimin yazması ekip zamanı ister, ama sonradan yapılan her değişikliği ölçülebilir kılar.
- Kullanım ücreti: Dil modeli servisini API üzerinden kullanıyorsanız ücret, işlenen metin miktarına bağlıdır; soru sayısı ve her soruda gönderilen bağlam büyüdükçe aylık gider artar.
- Veri yeri şartı: Verinin Türkiye'de ya da kendi sunucunuzda kalması gerekiyorsa model ve dizin seçenekleri daralır, barındırma maliyeti değişir.
Ben bir RAG teklifinde belge biçimi, yetki modeli, entegrasyon, değerlendirme seti, kullanım ücreti ve veri yeri kalemlerinin her birinin varsayımını ayrı bir satırda arardım. "Belgeler temiz kabul edilmiştir" gibi bir cümle, projenin en riskli kısmını müşteriye bırakır. Teklifleri kalem kalem karşılaştırmak için yazılım yaptırma maliyeti yazısındaki yöntem RAG projelerine de uyar.
Bir RAG projesine nasıl başlanır?
Bir RAG projesi en sağlıklı biçimde tek bir birimin tek bir belge setiyle ve o birimin sorduğu sorularla başlar; şirketin tüm belgelerini ilk günden dizine almak, hataların kaynağını görünmez kılar. Önerdiğim başlangıç sırası şöyledir:
- Bir soru alanı seçin: Örneğin insan kaynakları prosedürleri ya da bir ürün ailesinin teknik dokümanları.
- Belgeleri sahiplendirin: Her belge için sahip, geçerlilik tarihi ve tek yürürlükteki sürüm belirleyin; eski sürümleri setten çıkarın.
- Değerlendirme setini yazın: Birimin sorduğu soruları ve beklenen cevapları, cevabı belgede olmayan sorularla birlikte listeleyin.
- Dar bir pilot kurun: Yetkiye göre süzme, kaynak gösterme ve "bilmiyorum" davranışı ilk sürümde olsun; kullanıcı sayısı küçük kalsın.
- Ölçün ve karar verin: Değerlendirme setindeki isabeti, kullanıcıların cevabı kaynağa bakarak düzelttiği durumları ve arama süresindeki değişimi pilot öncesiyle karşılaştırın; genişletme kararını bu sonuçlarla verin.
UlvionTech'te bir iş kodlamadan önce yazılı kapsamla başlar ve sabit fiyat o kapsamdan sonra verilir. Kod deposu, bulut hesapları ve alan adları ilk günden müşterinin adına açılır; yayın sonrası destek süresi yazılı olarak belirlenir. Yapay zekâ otomasyonu hizmetimiz, şirket belgeleriyle çalışan bilgi asistanlarını bu çerçevede kapsar.
RAG projesi için yazılım firmasına hangi soruları sormalısınız?
Bir RAG teklifinde yetki, kaynak gösterme, ölçüm, güncelleme, veri yeri ve sahiplik konuları açıkça sorulmalıdır. Yazılım firmasından şu soruların yazılı cevabını isteyin:
- Erişim yetkisi hangi adımda ve hangi kaynak sisteme göre kontrol ediliyor?
- Cevaplar kaynak belgeyi ve ilgili bölümü gösteriyor mu?
- Değerlendirme setini kim hazırlıyor, isabet nasıl ölçülüyor ve sonuçlar bize raporlanıyor mu?
- Bir belge değiştiğinde ya da silindiğinde asistan bunu ne zaman görüyor?
- Belgeler, dizin, soru kayıtları ve model servisi hangi ülkede, kimin sunucusunda duruyor?
- Model servisi girdilerimizi saklıyor mu, kendi modelini eğitmekte kullanıyor mu?
- Model servisini değiştirmek istersek ne kadar iş çıkar?
- Kod deposu, dizin ve hesaplar kimin adına açılıyor?
RAG projelerinde sık yapılan hatalar nelerdir?
RAG projelerinde sık yapılan beş hata, model seçiminden çok hazırlıkla ilgilidir: tüm belgeleri bir kerede dizine almak, yetkiyi sonraya bırakmak, demoyu ölçüm sanmak, belge sahibi atamamak ve "bilmiyorum" diyemeyen bir sistem kurmak. Her birinin sonucu şöyledir:
- Tüm belgeleri bir kerede dizine almak: Hangi belgenin yanlış cevaba yol açtığı anlaşılmaz hâle gelir.
- Yetkiyi sonraya bırakmak: Sonradan eklenen yetki süzmesi, mimarinin baştan değişmesini gerektirebilir.
- Demoyu ölçüm sanmak: Birkaç iyi cevap, değerlendirme setinin yerini tutmaz.
- Belge sahibi atamamak: Güncellenmeyen belge, asistanın da eskimesi demektir.
- "Bilmiyorum" diyemeyen bir sistem kurmak: Kapsam dışı sorulara tahminle verilen cevap, kullanıcı güvenini hızla aşındırır.
RAG ne zaman kurulmamalı, UlvionTech ile ne zaman çalışmamalısınız?
RAG; sorular az ve sabitse, belgelerin sahibi yoksa ya da cevap bir belgede değil bir kişinin kararındaysa kurulmamalıdır. Bu durumlarda para ve zaman, belgeleri düzenlemeye ya da bir SSS sayfasına daha iyi harcanır. Şu durumlarda UlvionTech ile bir RAG projesi başlatmamanızı öneririm:
- Sorularınız bir SSS sayfasına sığıyorsa: Az sayıda sabit soru için yazılmış bir asistan, bakım isteyen gereksiz bir sistemdir.
- Belgelerin sahibi yoksa: Kimsenin güncellemediği belgelerle kurulan asistan, eski bilgiyi daha hızlı dağıtır; önce belge düzenini kurun.
- Şirket içinde bu işi yapabilecek bir yazılım ekibiniz varsa: Ekibiniz belge sistemlerinizi ve yetki yapınızı bizden iyi tanır; gerekirse yalnızca mimari ya da değerlendirme konusunda destek almanız yeterli olabilir.
- Amaç bir kişinin kendi notlarında arama yapmasıysa: Bireysel kullanım için hazır bir program yeterlidir; özel yazılımın maliyeti burada karşılığını vermez.
- Asıl ihtiyaç hukuki ya da tıbbi yorumsa: RAG ilgili maddeyi bulabilir, ama yorumu bir uzmanın işidir.
Belgelerinizin bir RAG asistanına hazır olup olmadığını, hangi soru alanıyla başlamanın mantıklı olduğunu ve verinin nerede durması gerektiğini birlikte değerlendirmek isterseniz, belge türlerinizi ve en sık sorulan birkaç soruyu iletişim sayfasından bize yazabilirsiniz.
Etiketler
- rag nedir
- retrieval augmented generation
- rag nasıl çalışır
- rag ve fine-tuning farkı
- kurumsal bilgi asistanı
- rag halüsinasyon
- yapay zekâ ve KVKK





