RAG Nedir? Şirket Dokümanlarından Kaynaklı Cevap Veren Yapay Zekâ

RAG (getirme destekli üretim) nedir, nasıl çalışır? Fine-tuning ile farkı, cevap kalitesini belirleyen etkenler, sık hatalar ve kurumsal kurulum adımları.

Yazar: CX Teknoloji Uzman Ekibi

RAG (Retrieval-Augmented Generation, getirme destekli üretim), bir dil modelinin soruyu cevaplamadan önce şirket dokümanları gibi bir bilgi kaynağında arama yapıp ilgili parçaları bulduğu ve cevabını yalnız bu parçalara dayandırarak kaynak gösterdiği bir yöntemdir. Model yeniden eğitilmez; bilgi güncellendiğinde arama dizini güncellenir ve cevaplar da güncel kalır.

Büyük dil modelleri (LLM) genel bilgiyle eğitilmiştir; şirketinizin kalite el kitabını, bakım talimatlarını ya da geçen yılki tedarikçi sözleşmesini bilmez. Bu belgeleri bilmediği bir soruyla karşılaştığında da çoğu zaman susmaz, akla yatkın ama yanlış bir cevap üretir. RAG bu iki sorunu birlikte ele alır: modele cevap vermeden önce ilgili belgeyi okutur ve cevabın hangi belgeden geldiğini gösterir. Şirket içi kurumsal yapay zekâ asistanlarının büyük çoğunluğu bu yöntemle çalışır. Bu yazı RAG'in nasıl çalıştığını, kalitesini neyin belirlediğini ve hangi durumlarda yanlış araç olduğunu yönetici ve BT sorumlusu gözüyle anlatıyor. Bu tür bir sistemi kendi belgeleriniz için değerlendirmek isterseniz danışmanlık sayfamızda çalışma modelimizi bulabilirsiniz.

RAG adım adım nasıl çalışır?

Bir RAG sistemi iki ayrı süreçten oluşur. Birincisi belgelerin hazırlanmasıdır ve arka planda, belgeler değiştikçe çalışır. İkincisi her soru sorulduğunda çalışan cevap üretme sürecidir.

1. Belge toplama: Dosya sunucusu, doküman yönetim sistemi, intranet ya da ERP'deki ekler gibi kaynaklardan belgeler alınır; her belgenin sürümü ve erişim yetkileri de birlikte kaydedilir.
2. Metne çevirme: PDF, Word, Excel ve taranmış belgeler okunabilir metne dönüştürülür. Taranmış belgeler için OCR, tablolar için yapıyı koruyan ayrıştırma gerekir.
3. Parçalama: Uzun belgeler başlık ve bölüm yapısı korunarak anlamlı parçalara bölünür. Her parça, ait olduğu belge ve bölüm bilgisini taşır.
4. Vektörleştirme ve dizinleme: Her parça, anlamını sayısal olarak temsil eden bir vektöre (embedding) çevrilir ve aranabilir bir dizine konur. Aynı parçalar genellikle anahtar kelime dizinine de eklenir.
5. Arama: Kullanıcı soru sorduğunda soru da vektöre çevrilir; anlamca en yakın parçalar ve anahtar kelimeyle eşleşen parçalar bulunur. Kullanıcının erişim yetkisi olmayan parçalar bu adımda elenir.
6. Yeniden sıralama: Bulunan aday parçalar, soruyla ilgisine göre ikinci bir modelle yeniden sıralanır ve en ilgili birkaç tanesi seçilir.
7. Cevap üretme: Dil modeline soru ve seçilen parçalar verilir; modelden yalnız bu parçalara dayanarak cevap vermesi, kaynağını belirtmesi ve parçalarda bilgi yoksa bunu söylemesi istenir.

Bu akıştaki her adım cevap kalitesini etkiler. Pratikte sorunların çoğu, dil modelinin kendisinden değil, ikinci ile beşinci adımlar arasından çıkar: belge düzgün okunmamıştır, parça bir tablonun yarısını kesmiştir ya da arama doğru parçayı getirmemiştir.

RAG, fine-tuning ve sistem talimatı arasındaki fark nedir?

Şirkete özel bilgiyi bir dil modeline kazandırmanın üç yolu sık karıştırılır. Aşağıdaki tablo bunların hangi ihtiyaca cevap verdiğini özetler.

Kurumsal belge sorularının büyük kısmı için başlangıç noktası RAG'dir. Fine-tuning, RAG ile çözülemeyen belirli bir davranış sorunu olduğunda (örneğin şirkete özgü kısaltmaların sürekli yanlış yorumlanması) değerlendirilir ve çoğu zaman RAG ile birlikte kullanılır.

Cevap kalitesini belirleyen etkenler

Aynı dil modeliyle kurulan iki RAG sistemi çok farklı kalitede cevap verebilir. Farkı yaratan etkenler şunlardır:

• Belge kalitesi ve sürüm disiplini: Geçersiz revizyonlar dizinde kaldıkça asistan eski bilgiyle cevap verir. Hangi belgenin geçerli olduğu kaynak sistemde net değilse RAG bunu düzeltemez.
• Metne çevirme kalitesi: Tablo ağırlıklı teknik dokümanlarda satır ve sütun ilişkisi kaybolursa, tolerans ya da ölçü sorularında yanlış değer okunur.
• Parçalama stratejisi: Çok küçük parçalar bağlamı kaybeder, çok büyük parçalar ilgisiz bilgiyi de modele taşır. Bölüm başlıklarını parçaya eklemek çoğu belge türünde fark yaratır.
• Hibrit arama: Yalnız anlam tabanlı arama, parça numarası, hata kodu ya da standart numarası gibi tam eşleşme gerektiren sorgularda zayıf kalabilir. Anahtar kelime aramasıyla birlikte kullanmak bu açığı kapatır.
• Meta veri ile filtreleme: Belge türü, tesis, ürün ailesi, tarih gibi etiketler aramayı daraltır. “Gebze tesisindeki geçerli talimat” sorusu ancak bu etiketler varsa doğru cevaplanır.
• Türkçe dil desteği: Kullanılan vektör modelinin ve dil modelinin Türkçe teknik metinlerde nasıl davrandığı, şirketin kendi belgeleriyle test edilmelidir.

RAG sistemlerinde sık görülen hatalar

Pilotlarda tekrar tekrar karşılaştığımız hatalar birkaç başlıkta toplanır. İlki, bütün belgeleri tek seferde dizine almaktır. Kalite sorunu çıktığında hangi belge grubundan kaynaklandığı anlaşılmaz. İkincisi yetki ayrımını sonraya bırakmaktır: pilot herkesin her şeyi görebildiği bir ortamda yapılır, geniş kullanıma açılırken personel ya da maaş belgelerinin dizinde olduğu fark edilir. Üçüncüsü değerlendirmeyi demo sorularıyla yapmaktır. Ekibin önceden denediği sorularda sistem iyi çalışır; gerçek kullanıcıların sorduğu, belirsiz ya da yazım hatalı sorularda zayıflar.

Dördüncü hata, RAG'den belgelerde olmayan bir işi beklemektir. “Geçen ay hangi hatta en çok fire verdik” sorusunun cevabı bir belgede değil, MES ya da ERP verisindedir. Bu tür sayısal sorular için doğru yol veri ambarı ve yönetim panosudur; bir dil modeli bu veriye ancak kontrollü bir sorgu arayüzüyle bağlanabilir. Sayısal verinin nerede ve nasıl tutulacağı konusunu veri ambarı mı veri gölü mü yazısında ele aldık.

Bir RAG sisteminin kalitesi nasıl ölçülür?

Ölçüm, gerçek kullanım senaryolarından derlenen bir test setiyle yapılır. Bölüm uzmanları her soru için doğru cevabı ve cevabın bulunduğu belgeyi işaretler. Setin içinde belgede cevabı olmayan sorular da bulunmalıdır; sistemin bunlarda bilgi uydurmayıp bulamadığını söylemesi gerekir. Sonuçlar iki ayrı katmanda incelenir: arama doğru belgeyi getirdi mi ve model getirilen belgeye sadık bir cevap üretti mi. Bu ayrım, sorunun aramada mı yoksa üretimde mi olduğunu gösterir ve düzeltmeyi doğru yere yönlendirir.

Test seti bir kez hazırlanıp bırakılmaz. Yeni belge eklendiğinde, parçalama değiştiğinde ya da model güncellendiğinde set yeniden çalıştırılır. Bu, görüntü işleme modellerinde uyguladığımız sürekli izleme mantığının aynısıdır; model yaşam döngüsünün genel çerçevesi için MLOps yazısına bakabilirsiniz.

Veriler nerede işlenmeli?

RAG sisteminde belgeler hem dizinleme hem de cevap üretme sırasında işlenir. Dil modeli bulut hizmeti olarak kullanılıyorsa, her soruda ilgili belge parçaları o hizmete gönderilir. Teknik çizim, reçete ya da müşteri sözleşmesi gibi şirket dışına çıkmaması gereken belgeler için dizin ve dil modelinin şirket içinde çalıştırılması gerekir. Bu seçeneğin donanım ve işletme gereksinimlerini on-premise yapay zekâ yazısında anlattık. Dizine kişisel veri içeren belgeler alınacaksa, işleme amacı ve aktarım koşulları hukuk biriminizle birlikte değerlendirilmelidir; bu genel bilgidir, hukuki danışmanlık yerine geçmez.

Bir RAG projesinin maliyetini ne belirler?

Yöneticiler genellikle maliyeti dil modelinin kullanım ücreti üzerinden düşünür. Pratikte bütçeyi daha çok şu kalemler belirler:

• Belge hazırlığı: Sürüm temizliği, taranmış belgelerin metne çevrilmesi ve tabloların doğru ayrıştırılması. Belgeler ne kadar dağınıksa bu kalem o kadar büyür.
• Kaynak sistem bağlantıları: Dosya sunucusu, doküman yönetim sistemi ya da ERP eklerinden düzenli ve yetkiyle birlikte veri çekmek için geliştirilecek bağlayıcılar.
• Altyapı: Bulut hizmetinde soru başına kullanım ücreti; şirket içi kurulumda GPU sunucusu, depolama ve bunların bakımı.
• Test ve iyileştirme: Test setinin hazırlanması için bölüm uzmanlarının ayıracağı zaman ve düzenli değerlendirme çalışması.
• İşletme: Yeni belge kümelerinin eklenmesi, model güncellemeleri ve kullanıcı desteği.

Bu kalemlerin ilk ikisi şirketten şirkete en çok değişen kısımdır ve ancak keşif aşamasında belgeler ve sistemler incelendikten sonra gerçekçi biçimde tahmin edilebilir.

Şirketinizde RAG'e nereden başlamalı?

En sağlıklı başlangıç, belge kümesi sınırlı ve sahibi belli bir alandır: bakım talimatları, kalite prosedürleri ya da İK politikaları gibi. Bu alan için gerçek kullanıcılardan soru toplanır, belgeler temizlenir, test seti hazırlanır ve küçük bir grupla pilot yapılır. Başarı ölçütü pilottan önce yazılır; örneğin test setindeki sorularda doğru kaynağın bulunması ve cevapsız soruların doğru tanınması. CX Teknoloji olarak bu süreçte keşiften devire kadar aynı ekiple çalışıyoruz; mevcut belge altyapınızın RAG için ne kadar hazır olduğunu görmek isterseniz ücretsiz dijital olgunluk ön değerlendirmesi ile başlayabilirsiniz.

Sık sorulan sorular

RAG ne demektir?

RAG, Retrieval-Augmented Generation'ın kısaltmasıdır ve Türkçede getirme destekli üretim olarak karşılanır. Dil modeli cevap vermeden önce bir bilgi kaynağında arama yapar ve cevabını bulduğu belge parçalarına dayandırır. Bu sayede cevaplar güncel olur ve kaynağı gösterilebilir.

RAG için dil modelini yeniden eğitmek gerekir mi?

Hayır, RAG'de model yeniden eğitilmez. Şirket belgeleri aranabilir bir dizine konur ve her soruda ilgili parçalar modele verilir. Belgeler değiştiğinde yalnız dizin güncellenir.

RAG yanlış cevap vermeyi tamamen engeller mi?

Hayır, ama cevabı belgeye bağladığı için hatayı görünür ve kontrol edilebilir kılar. Arama yanlış parçayı getirirse ya da belge eskiyse cevap da yanlış olabilir. Kaynak gösterme sayesinde kullanıcı cevabı belgeye bakarak doğrulayabilir.

RAG Türkçe belgelerle çalışır mı?

Evet, çok dilli vektör modelleri ve dil modelleriyle Türkçe belgeler üzerinde çalışır. Ancak Türkçe teknik terimler, kısaltmalar ve tablolu belgelerde davranış modele göre değişir. Bu yüzden seçim, şirketin kendi belgelerinden hazırlanan bir test setiyle yapılmalıdır.

RAG ile ERP verisine soru sorulabilir mi?

Doğrudan değil; RAG belgelerdeki metin için tasarlanmıştır. Stok, üretim adedi ya da ciro gibi sayısal sorular için veri ambarı, yönetim panosu ya da kontrollü bir sorgu arayüzü gerekir. Bir asistan bu iki yöntemi birlikte kullanacak şekilde tasarlanabilir.