RAG Nedir? Şirket Belgeleriyle Çalışan Yapay Zeka Nasıl Kurulur?

RAG nedir?

RAG (Retrieval Augmented Generation, yani getirme destekli üretim), bir yapay zeka modelinin cevap yazmadan önce şirketin kendi belgelerinden ilgili parçaları bulup okuduğu yöntemdir. Model ezberine değil, o an önüne konan kaynaklara dayanarak yanıt verir. Böylece cevaplar güncel, şirkete özel ve kaynak gösterilebilir olur.

Bu tanım kısa. Ancak arkasında sade bir fikir var. İyi bir çalışan düşünün: bir soru geldiğinde önce dosyaya bakar, sonra cevabını yazar. RAG, modele aynı alışkanlığı kazandırır.

Ayrıca fikri ilk kez bilimsel olarak tanımlayan çalışma, modelin öğrenilmiş belleğini harici bir bilgi kaynağıyla birleştirmeyi öneriyor. Orijinal makaleyi Lewis ve arkadaşlarının arXiv yazısında okuyabilirsiniz.

Bu yazıda RAG'in nasıl çalıştığını, fine tuning (modeli ek eğitimle özelleştirme) ile farkını, veri hazırlığını, yetkilendirmeyi, değerlendirmeyi ve KVKK açısından dikkat edeceğiniz noktaları sade dille anlatıyoruz. Biz Talha Aslan ve ekibi olarak bu konuya yazılım ve pazarlama tarafından, pratik gözle bakıyoruz.

Büyük dil modeli şirket belgelerini neden bilmez?

Büyük dil modeli, eğitim sırasında gördüğü genel metinlerden öğrenir. Sizin iç yönergeniz, fiyat listeniz ya da sözleşme şablonunuz o metinlerin içinde yoktur. Bu yüzden model, şirketinize özel bir soruya ya "bilmiyorum" der ya da daha kötüsü, kulağa makul gelen bir cevap uydurur.

Bu uydurma davranışına halüsinasyon diyoruz. Modelin amacı akıcı bir metin üretmektir, doğruluğu kontrol etmek değil. Ayrıca modelin bilgisi eğitim anında donar. Dün değişen bir iade politikasını bilemez.

Modelin kendisini ayrıntılı anlatmıyoruz. Temel kavramlar için büyük dil modelleri (LLM) rehberimize göz atabilirsiniz.

Şirket içinde sık gördüğümüz üç sorun şunlardır:

• Bilgi eskir. Fiyat, prosedür ve ürün özellikleri sürekli değişir, model ise eski halini hatırlar.
• Bilgi gizlidir. İç belgeleri herkese açık bir modele yüklemek çoğu zaman uygun değildir.
• Kaynak yoktur. Model cevabın nereden geldiğini gösteremezse, ekip cevaba güvenmez.

RAG bu üç sorunun hepsine aynı hamleyle yaklaşır: bilgiyi modelin içine gömmek yerine, soru geldiğinde modelin önüne koyar.

RAG nedir sorusunun şirketler için cevabı: hangi sorunları çözer?

Şirket gözüyle RAG nedir sorusunun cevabı şudur: belge arşivinizi sorulabilir hale getiren bir katman. Çalışan ya da müşteri doğal dilde soru sorar, sistem ilgili paragrafları bulur ve model bu paragraflardan cevap yazar.

Faydaları dört başlıkta toplayabiliriz:

• Güncellik: Belgeyi güncellediğinizde cevap da güncellenir. Modeli yeniden eğitmeniz gerekmez.
• Şirkete özel bilgi: Prosedürler, ürün kataloğu, teknik şartnameler ve destek geçmişi cevabın hammaddesi olur.
• Kaynak gösterme: Cevabın yanında hangi belgenin hangi bölümünden geldiğini verebilirsiniz. Kullanıcı tıklayıp doğrulayabilir.
• Daha az halüsinasyon: Model, önündeki metne bağlı kalmaya yönlendirilir. Metinde cevap yoksa "bulamadım" demesini isteyebilirsiniz.

Yine de net olalım: RAG halüsinasyonu sıfırlamaz, azaltır. Kötü bulunan bir parça, kötü bir cevaba yol açabilir. Bu yüzden değerlendirme bölümünü atlamamanızı öneririz.

Örneğin tipik kullanım alanları şunlardır: iç bilgi asistanı, müşteri destek botu, satış ekibi için ürün sorgulama, uyum ve politika soruları, teknik dokümantasyon araması.

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

RAG iki aşamadan oluşur. Önce belgeleri hazırlar, yani indekslersiniz. Sonra her soruda arama yapar, ardından cevap üretirsiniz. İndeksleme bir kez kurulur ve belgeler değiştikçe güncellenir. Sorgu aşaması ise her soruda çalışır.

İndeksleme aşaması şöyle ilerler:

1. Belgeleri toplarsınız: PDF, Word, wiki sayfası, e-posta arşivi, ürün kataloğu.
2. Metni temizlersiniz ve anlamlı parçalara (chunk) bölersiniz.
3. Her parçayı bir embedding'e, yani sayısal anlam vektörüne çevirirsiniz.
4. Vektörleri ve parçanın kaynak bilgisini bir vektör veritabanında saklarsınız.

Sorgu aşaması ise şöyledir:

1. Kullanıcı soru sorar.
2. Sistem soruyu da embedding'e çevirir.
3. Veritabanından anlamca en yakın parçaları getirir.
4. Bu parçalar ve soru birlikte modele gönderilir.
5. Model cevabı yazar, kaynakları gösterir.

Bu akış ilk bakışta karmaşık görünür. Ancak her adımın tek bir işi var. Sorun çıktığında hangi adımda koptuğunu bulmak da bu sayede kolaylaşır.

Belgeler neden parçalara bölünür ve parça boyutu nasıl seçilir?

Modelin bir seferde okuyabileceği metin sınırlıdır. Üstelik 200 sayfalık bir kılavuzun tamamını göndermek hem pahalı hem gürültülüdür. Bu yüzden belgeyi küçük parçalara bölersiniz. Soru geldiğinde yalnızca ilgili parçalar modele gider.

Parça boyutu, kalitenin en kritik ayarlarından biridir. Bu yüzden onu tahmin etmek yerine ölçmenizi öneririz. Çok küçük parça bağlamı kaybeder. Çok büyük parça ise içine alakasız bilgi taşır ve aramayı bulanıklaştırır.

Pratik ipuçlarımız:

• Parçaları rastgele karakter sayısına göre değil, başlık ve paragraf sınırına göre kesin.
• Komşu parçalar arasında küçük bir örtüşme bırakın, böylece cümle ortada kesilmez.
• Her parçaya belgenin adını, bölüm başlığını ve tarihini ek bilgi olarak ekleyin.
• Tabloları ve listeleri bütün tutun, çünkü yarım tablo yanlış cevap üretir.

Anthropic'in bağlamsal getirme yazısı tam olarak bu sorunu anlatıyor: "gelir yüzde 3 arttı" diyen bir parça, hangi şirketten söz ettiğini kaybeder. Çözüm olarak parçaların başına kısa bir açıklama eklemeyi öneriyor.

Parça uzunluğunu hızlıca ölçmek için kelime ve karakter sayacımızı kullanabilirsiniz.

Embedding ve vektör veritabanı nedir?

Embedding, bir metnin anlamını sayı dizisine çeviren temsildir. Anlamca yakın iki metin, bu sayı uzayında birbirine yakın durur. "İade süresi" ile "ürünü geri gönderme koşulları" aynı kelimeleri içermez, ama embedding'leri komşudur.

Vektör veritabanı, bu sayı dizilerini saklayan ve soruya en yakın olanları hızla bulan depodur. Örnek olarak pgvector, Qdrant, Chroma, FAISS ve OpenSearch gibi çözümler var. Bunlar yalnızca örnek, tercih sizin altyapınıza ve ekibinize bağlıdır.

Kritik bir kural: indekslerken ve sorgularken aynı embedding modelini kullanmalısınız. Model değiştirirseniz, tüm belgeleri yeniden indekslemeniz gerekir.

Embedding modelinin seçiminde şu soruları sorun:

• Türkçe metinde başarısı nasıl? Çok dilli bir model mi gerekiyor?
• Maliyeti ve hızı bütçenize uyuyor mu?
• Verinizi dışarı gönderiyor mu, yoksa kendi sunucunuzda mı çalışıyor?

Model adları ve sürümleri hızla değişir. Güncel seçenekleri ve fiyatları sağlayıcının resmi sayfasından kontrol edin.

Sadece vektör araması yeterli mi?

Çoğu zaman hayır. Vektör araması anlamı iyi yakalar, ama ürün kodu, hata numarası ya da özel isim gibi birebir eşleşme gerektiren sorgularda zayıf kalabilir. Örneğin "ERR-4032 hatası" diye aranan bir kodu, anlamca benzer ama farklı bir hata sayfası gölgede bırakabilir.

Bu nedenle üretimdeki sistemler genellikle hibrit arama kullanır. Yani hem anlam aramasını hem de klasik anahtar kelime aramasını (BM25 gibi) birleştirir. Böylece iki yöntemin zayıf yanları birbirini tamamlar.

Bir sonraki iyileştirme katmanı yeniden sıralamadır (reranking). Sistem önce biraz geniş bir aday listesi getirir. Ardından ayrı bir model, adayları soruyla ilgisine göre puanlar ve en iyilerini seçer. Böylece gürültü azalır ve modele giden metin kısalır.

Kısacası sıralama şöyle ilerler:

• Aday getirme: anlam ve anahtar kelime aramasını birlikte çalıştırın.
• Filtreleme: tarih, departman ya da belge türü gibi metadata ile daraltın.
• Yeniden sıralama: en ilgili birkaç parçayı seçin.
• Cevap üretme: seçilen parçaları modele verin.

OpenAI'nin retrieval rehberi da anlamsal aramayı, vektör depolarını ve metadata filtrelemeyi benzer bir çerçevede anlatıyor.

Model cevabı nasıl üretir ve kaynağı nasıl gösterir?

Getirilen parçalar, kullanıcının sorusuyla birlikte modelin istemine (prompt) girer. İstem kısa ve net kurallar içerir: "Yalnızca verilen metne dayan. Cevap metinde yoksa bilmediğini söyle. Her iddiaya kaynak numarası ekle."

Bu nedenle bu kurallar RAG kalitesini doğrudan etkiler. İstem mühendisliği konusunda ayrıntı isterseniz Custom GPT rehberimizde talimat yazma mantığını bulabilirsiniz.

Kaynak göstermek için her parçanın yanında belge adı, bölüm ve bağlantı tutmanız gerekir. Model cevap verirken bu bilgileri aynen aktarır. Arayüzde de cevabın altına "Kaynaklar" listesi koyarsınız.

Cevap biçimini de baştan tarif edin. Örneğin kısa bir özet, ardından madde madde adımlar ve en sonda kaynak listesi isteyebilirsiniz. Böylece kullanıcı her seferinde aynı düzende cevap görür ve okuması kolaylaşır.

Bu bölümde iki ayrıntı çok önemli:

• "Bilmiyorum" hakkı: Modele, bulunan parçalar yetersizse cevap vermeme izni verin. Yoksa sorunun cevabını kendi genel bilgisinden uydurur.
• Çelişen kaynaklar: İki belge farklı şey söylüyorsa, tarihi yeni olanı öne alın ya da kullanıcıya çelişkiyi gösterin.

Her istek, getirilen metin kadar token (modelin okuduğu metin birimi) harcar. Maliyet hesabı için token ve API maliyeti yazımıza bakın.

RAG nedir, fine tuning'den farkı ne?

Fine tuning, modelin ağırlıklarını kendi örnek verinizle yeniden ayarlamaktır. RAG ise modeli değiştirmez, ona her soruda doğru belgeyi okutur. İkisi rakip değil, farklı işler için tasarlanmış araçlardır.

Genel bir kural koyalım: bilgi eklemek istiyorsanız RAG, davranış ya da üslup öğretmek istiyorsanız fine tuning daha uygundur. Aşağıdaki tablo farkı özetliyor:

Pratikte birçok ekip RAG ile başlar, çünkü ucuzdur, denemesi kolaydır ve hatayı nerede yaptığınızı görebilirsiniz. Fine tuning ancak RAG'in çözemediği bir davranış sorunu kaldığında devreye girer. İkisini birlikte kullanan sistemler de var.

Kurulumdan önce veri hazırlığı nasıl yapılır?

RAG'in kalitesi, belgelerinizin kalitesini geçemez. Dağınık, eski ve birbiriyle çelişen belgeler, ne kadar iyi model kullanırsanız kullanın kötü cevap üretir. Bu yüzden projenin ilk haftaları çoğunlukla teknik değil, içerik temizliğine gider.

Başlangıç için kontrol listemiz:

1. Kapsamı daraltın. Önce tek bir alan seçin, örneğin müşteri destek bilgileri.
2. Belge sahibini belirleyin. Her belgenin güncelleme sorumlusu olsun.
3. Eski sürümleri ayıklayın. Arşivdeki "kopya", "son", "son2" dosyaları çelişki üretir.
4. Taranmış PDF'leri metne çevirin. Metin çıkarma (OCR) hatalarını örnekleyerek kontrol edin.
5. Tablo, görsel ve ekran görüntülerini nasıl işleyeceğinize karar verin.
6. Her belgeye tarih, departman, dil ve erişim düzeyi gibi metadata ekleyin.

Bu adımlar sıkıcı görünür, ancak sonucu en çok etkileyen kısım budur. Ayrıca belge işleme tarafında ihtiyaç duyarsanız yapay zeka ile belge işleme çözümümüze bakabilirsiniz.

Kim hangi belgeyi görür? Yetkilendirme nasıl kurulur?

Bu, RAG projelerinde en çok gözden kaçan konudur. Çünkü demo sırasında kimse yetkiyi sormaz. Sistem tüm şirket belgelerini tek indekse koyarsa, stajyer de maaş politikasını sorabilir. Yetki kontrolünü cevap üretildikten sonra değil, arama aşamasında uygulamalısınız.

Doğru yaklaşım şöyle çalışır: her parçaya erişim bilgisi (hangi grup, hangi departman) eklersiniz. Kullanıcı soru sorduğunda sistem önce kullanıcının kimliğini ve gruplarını alır. Ardından aramayı yalnızca o kullanıcının görebileceği parçalarla sınırlar.

Dikkat edeceğiniz noktalar:

• Yetkiyi modelden istemeyin. "Gizli belgeleri gösterme" demek güvenlik değildir, çünkü model ikna edilebilir.
• Kaynak sistemdeki yetkileri (paylaşılan sürücü, wiki) indekse yansıtın ve düzenli eşitleyin.
• Bir kullanıcının yetkisi kalktığında, indeksteki erişim bilgisi de güncellensin.
• Erişim denemelerini kayıt altına alın.

Bir de ekip yapısını düşünün. Örneğin satış ekibi fiyat indirim limitlerini görsün, ama maaş bordrolarını görmesin. Bu ayrımı belge düzeyinde tanımlamak, sonradan yama yapmaktan çok daha ucuzdur.

Saldırı tarafını da düşünün. Belgenin içine gizlenmiş talimatlar modeli yanıltabilir. Bu risk için prompt injection rehberimizi okuyun.

RAG sistemi nasıl değerlendirilir?

"Güzel cevap veriyor gibi" bir ölçüt değildir. RAG'i iki parçada ayrı ayrı ölçmeniz gerekir: doğru parçayı buldu mu, ve bulunan parçadan doğru cevap yazdı mı? Hata hangi katmandaysa düzeltmeniz orada başlar.

Bunun için kendi test setinizi hazırlayın. Gerçek kullanıcı sorularından yaklaşık yüz tanesini toplayın. Her biri için doğru cevabı ve cevabın geçtiği belgeyi not edin. Örnek senaryo: "İade süresi kaç gün?" sorusunun doğru parçası iade politikası belgesinin ilgili paragrafıdır.

Üç temel soruya bakın:

• Getirme kalitesi: Doğru parça ilk birkaç sonuç içinde geliyor mu?
• Sadakat: Cevap, yalnızca getirilen metne mi dayanıyor, yoksa model kendi bilgisini mi katıyor?
• Yararlılık: Cevap soruyu gerçekten çözüyor mu, kullanıcı ek soru sormak zorunda kalıyor mu?

Bu yüzden test setini her değişiklikten sonra yeniden çalıştırın. Parça boyutunu, embedding modelini ya da istemi değiştirdiğinizde skorun nasıl oynadığını görürsünüz. Canlıda da kullanıcıya "faydalı oldu mu?" butonu koyun ve olumsuz geri bildirimleri düzenli inceleyin.

RAG nedir diye soran ekipler hangi senaryolarla başlar?

Ekiplerin ilk denediği senaryolar genellikle benzerdir. Hepsinde ortak nokta, cevabın zaten bir belgede yazıyor olmasıdır. Aşağıdakiler örnek senaryodur, gerçek bir müşteri sonucu değildir.

• İç destek asistanı: Yeni başlayan bir çalışan "izin talebini nasıl açarım?" diye sorar. Asistan İK yönergesinden ilgili adımları getirir. Böylece İK ekibi aynı soruyu tekrar tekrar cevaplamaz.
• Satış ekibi için ürün sorgulama: Satışçı müşterinin önünde "bu modelle şu aksesuar uyumlu mu?" diye bakar. Sistem teknik şartnameden cevabı ve sayfa numarasını verir.
• Müşteri destek botu: Müşteri kargo ve iade koşullarını sorar. Bot yalnızca yayındaki politika sayfasına dayanır ve gerekirse konuyu bir insana devreder.
• Teknik dokümantasyon araması: Yazılım ekibi eski bir entegrasyonun nasıl çalıştığını arar. Wiki, kod yorumları ve toplantı notları tek yerden sorgulanır.

Bu senaryoların hepsinde kullanıcı "arama kutusuna doğru kelimeyi yazma" zahmetinden kurtulur. Ayrıca cevabın yanında kaynak gördüğü için güven duyar. Yani RAG nedir sorusuna pratik cevap, "belge arşivinizi konuşan bir yardımcıya çevirmek" olur.

RAG ne zaman gerekmez?

Her yapay zeka işi RAG gerektirmez. Bazen daha basit bir çözüm daha iyi sonuç verir. Aşağıdaki durumlarda RAG'e girişmeden önce bir kez daha düşünün.

Belge seti çok küçükse, yani birkaç sayfaysa, metni doğrudan isteme koymak yeterli olabilir. Böylece arama katmanını kurmak ve bakımını yapmak zorunda kalmazsınız. Ancak belge sayısı büyüdüğünde bu yöntem hem pahalı hem yavaş olur.

Sorunuz sayısal analizse, örneğin satış toplamı ya da stok durumu, doğru araç bir veritabanı sorgusudur. Model bu sorguyu yazıp çalıştırabilir, ama cevap belge aramasından gelmez.

Kural net ve değişmezse, örneğin "şu tutarın üstündeki işlemi onaya gönder", yazılım kuralı yazmak yapay zekadan daha güvenilirdir. Çünkü kural motoru her seferinde aynı sonucu verir.

Son olarak, modelin üslubunu ya da çıktı biçimini değiştirmek istiyorsanız sorun bilgi eksikliği değildir. Bu durumda önce istem tasarımına, gerekirse fine tuning'e bakın.

En sık yapılan RAG hataları nelerdir?

Projelerde tekrar tekrar aynı hatalarla karşılaşıyoruz. Çoğu model seçiminden değil, hazırlık ve ölçüm eksikliğinden doğuyor. İşte en yaygın olanlar:

• Temizlenmemiş arşivi olduğu gibi yüklemek. Eski ve çelişkili belgeler çelişkili cevap demektir.
• Parça boyutunu hiç denememek. Varsayılan ayar sizin belgelerinize uymayabilir.
• Yalnızca vektör aramasına güvenmek. Kod, isim ve numara aramaları kaçar.
• Test seti olmadan canlıya çıkmak. İyileştirme yaptığınızı mı bozduğunuzu mu bilemezsiniz.
• Yetkiyi sona bırakmak. Sonradan eklemek çok zordur, baştan tasarlayın.
• Kaynak göstermemek. Kullanıcı cevabı doğrulayamazsa sisteme güvenmez.
• Güncelleme akışı kurmamak. İndeks bir kez dolar, sonra eskir.
• Her sorunu RAG ile çözmeye çalışmak. Bazı sorular hesaplama ya da veritabanı sorgusu ister.

Son maddeyi biraz açalım. "Geçen ay kaç sipariş aldık?" sorusu bir belge arama sorusu değildir. Bu soru için modelin bir veritabanı sorgusu çalıştırması gerekir. Metin bilgisi için RAG güçlüdür; sayısal analiz için başka araçlar gerekir.

RAG sistemi canlıya çıktıktan sonra nasıl bakım ister?

Bu sistem bir kez kurulup unutulan bir yapı değildir. Belgeler değişir, kullanıcılar yeni sorular sorar, modeller güncellenir. Bu yüzden canlıya çıkış, işin sonu değil başıdır.

Bakım için şu rutinleri öneriyoruz:

• Güncelleme akışı: Kaynak belge değiştiğinde yalnızca ilgili parçaları yeniden indeksleyin. Böylece tüm arşivi baştan işlemek zorunda kalmazsınız.
• Silme akışı: Kaldırılan ya da süresi dolan belgeler indeksten de çıksın. Aksi halde eski bilgi cevaplarda yaşamaya devam eder.
• İzleme: Cevapsız kalan ve olumsuz geri bildirim alan soruları haftalık inceleyin. Çoğu zaman eksik bir belgeyi gösterirler.
• Regresyon testi: Model ya da embedding değiştiğinde test setini yeniden çalıştırın.

Maliyet tarafında üç kaldıraç var. Birincisi, modele giden parça sayısını gereksiz yere artırmamaktır. İkincisi, sık gelen soruların cevabını önbellekte tutmaktır. Üçüncüsü, basit sorularda daha hafif, zor sorularda daha güçlü model kullanmaktır. Güncel fiyatları sağlayıcıların resmi sayfalarından kontrol edin.

KVKK ve GDPR açısından nelere dikkat edilir?

Belgelerinizde kişisel veri varsa (çalışan kayıtları, müşteri yazışmaları, sözleşmeler), RAG kurulumu bir kişisel veri işleme faaliyetidir. Bu durumda KVKK ya da AB'deki GDPR devreye girer. Yazının bu kısmı hukuki danışmanlık değildir; kararlarınız için hukukçunuza danışın.

Başlangıç için sorabileceğiniz sorular:

• İndekse hangi kişisel veriler giriyor? Hepsi gerçekten gerekli mi?
• Veriyi kim işliyor? Model sağlayıcısı, bulut hizmeti ve vektör veritabanı sağlayıcısı veri işleyen olabilir.
• Sağlayıcı gönderdiğiniz veriyi model eğitiminde kullanıyor mu? Sözleşme ve resmi dokümanlardan kontrol edin.
• Veri yurt dışına çıkıyor mu? Çıkıyorsa hukuki dayanağınız ne?
• Silme talebi geldiğinde ilgili kişinin verisini indeksten de silebiliyor musunuz?

Mümkün olan yerde kişisel veriyi indekse almadan önce maskeleyin ya da hiç almayın. Silme ve düzeltme taleplerini karşılamak için her parçanın hangi kaynak belgeden geldiğini tutun.

Resmi çerçeve için KVKK'nın resmi sitesine ve GDPR metnine bakın. Web tarafındaki uyum için KVKK ve GDPR uyumlu web sitesi rehberimiz de yardımcı olur.

Veri yeri: bulut mu, kendi sunucu mu?

RAG'de veri iki yerde durur: belgelerin ve vektörlerin tutulduğu depo, bir de cevabı üreten model. İkisini ayrı ayrı konumlandırabilirsiniz. Karar, verinin hassasiyetine, bütçenize ve ekibinizin işletme gücüne bağlıdır.

Aşağıdaki seçenekler en yaygın senaryolardır:

Hassas veriler için üçüncü seçenek cazip görünür, yani veri dışarı çıkmaz. Kendi sunucunuzda açık modellerle çalışmayı merak ediyorsanız Ollama rehberimize ve yerel LLM kurulumu hizmetimize bakabilirsiniz.

Ancak yerel kurulum otomatik olarak daha güvenli demek değildir. Güncelleme, yedekleme ve erişim kontrolü sizin sorumluluğunuza geçer. Karar vermeden önce riski gerçekçi tartın.

Kurumsal RAG nedir ve hangi araçlarla kurulur?

Kurumsal RAG nedir diye sorarsanız: yukarıdaki parçaların (belge okuyucu, parçalayıcı, embedding, vektör deposu, arama, model, yetki, ölçüm) bir ürün haline getirilmiş şeklidir. Bu parçaları bağlamak için LangChain ve LlamaIndex gibi çerçeveler var, bulut sağlayıcıların hazır yönetilen arama servisleri de var.

Karar verirken iki seçeneği karşılaştırın, çünkü ikisinin de bedeli farklıdır. Hazır servis hızlı başlatır, ama esnekliği ve şeffaflığı sınırlar. Özel geliştirme daha fazla emek ister, ancak yetki, veri yeri ve ölçüm üzerinde tam kontrol verir.

Biz şu yönde öneri veriyoruz: küçük bir pilotla hazır araçları deneyin. Pilot size hangi belgelerin işe yaradığını, hangi soruların kaçtığını gösterir. Sonra ihtiyacınıza göre özel mimariye geçin.

Araç adları ve sürümleri hızla değişir; bu yazıdaki adlar yalnızca örnektir. Hiçbirini "en iyi" olarak önermiyoruz. Güncel özellikleri ve fiyatları ilgili sağlayıcının resmi sayfasından kontrol edin.

RAG projesine hangi sırayla başlamalısınız?

Büyük bir "her şeyi bilen asistan" hedefiyle başlamayın. Küçük, ölçülebilir bir pilot daha hızlı öğretir. Önerdiğimiz sıra şöyle:

1. Tek bir kullanıcı grubu ve tek bir soru türü seçin.
2. O alanın belgelerini temizleyin ve sahiplerini belirleyin.
3. Yüz kadar gerçek soruyla bir test seti hazırlayın.
4. Basit bir RAG kurun: parçalama, embedding, arama, cevap.
5. Test setiyle ölçün; parça boyutu, hibrit arama ve yeniden sıralamayı sırayla deneyin.
6. Yetkilendirmeyi ve kaynak göstermeyi ekleyin.
7. Küçük bir kullanıcı grubuyla canlıya alın, geri bildirim toplayın.
8. Güncelleme ve izleme akışını kurun, sonra kapsamı genişletin.

Her adımda "bunu nasıl ölçeceğim?" sorusunu sorun. Ölçemediğiniz şeyi iyileştiremezsiniz. Ayrıca pilotun başarı ölçütünü baştan yazın; örneğin ekibin ilk cevapta doğru belgeye ulaşma oranı gibi basit bir hedef yeterlidir.

Ayrıca beklentiyi baştan yönetin. Yönetim ve kullanıcılar sistemin her soruyu bilmesini bekleyebilir, oysa RAG yalnızca belgelerinizde olanı bulur. İlk sürüm mükemmel olmayacak. Önemli olan, hatanın nedenini bulabilecek bir yapıyla başlamanız.

Talha Aslan ve ekibi bu işte nasıl destek verir?

Biz Talha Aslan ve ekibi olarak 2012'den beri dijital pazarlama ve yazılım projelerinde sahadayız. Yapay zeka tarafında belge tabanlı asistanları, iş akışı otomasyonlarını ve entegrasyonları kuruyoruz. Burada rakam ya da vaka sözü vermiyoruz; yaklaşımımızı anlatıyoruz.

Önce kapsamı ve veriyi birlikte netleştiriyoruz. Sonra küçük bir pilot kurup test setiyle ölçüyoruz. Yetki, veri yeri ve KVKK sorularını baştan masaya koyuyoruz.

İlgili sayfalarımız:

• Kurumsal bilgi asistanı çözümümüz
• Yapay zeka entegrasyonu
• Yapay zeka danışmanlığı

Not: Bu yazı genel bilgi içindir; hukuki ya da mali danışmanlık değildir. Model ve araç özelliklerinin güncel halini sağlayıcıların resmi sayfalarından doğrulayın.