RAG nedir? Belgelerinizden kaynak göstererek yanıt veren yapay zekâ

RAG (retrieval-augmented generation, erişimle desteklenmiş metin üretimi), bir dil modelinin soruyu yanıtlamadan önce sizin belgelerinizde arama yaptığı, bulduğu ilgili bölümleri bağlamına aldığı ve yanıtını bu bölümlere dayandırdığı yöntemdir. Model yeniden eğitilmez; belgeler değiştiğinde arama indeksini güncellemek yeterlidir. İyi kurulmuş bir RAG sistemi yanıtla birlikte dayandığı belge bölümünü de gösterir, böylece çalışan bilgiyi özgün belgeyle karşılaştırabilir.

RAG ne işe yarar?

Dil modelleri eğitildikleri veriyi bilir; kurumunuzun bakım kılavuzlarını, prosedürlerini veya ürün kataloglarını bilmez. Bu belgelere dair bir soruya doğrudan yanıt vermeye çalışan bir model, akıcı ama yanlış bir metin üretebilir (halüsinasyon). RAG, modeli yanıt vermeden önce doğru belge parçasına götürür.

RAG’in kurumlara sağladığı başlıca faydalar:

• Belgeye dayalı yanıt: Model kendi hafızasından değil, bulunan parçalardan yanıt verir.
• Kaynak gösterme: Yanıtın hangi belgenin hangi bölümünden geldiği görülür.
• Güncellik: Yeni bir revizyon indekse eklendiğinde yanıtlar da güncellenir; model eğitimi gerekmez.
• Erişim kontrolü: Arama, kullanıcının görme yetkisi olan belgelerle sınırlanabilir.

Yöntemin adı, Lewis ve arkadaşlarının 2020 tarihli makalesinden gelir.

RAG nasıl çalışır?

Bir RAG sistemi iki aşamadan oluşur: belgelerin bir kez hazırlandığı indeksleme aşaması ve her soruda tekrarlanan sorgu aşaması.

İndeksleme

1. Dönüştürme: PDF, DOCX ve benzeri dosyalar metne, tercihen başlıkların ve tabloların korunduğu Markdown’a çevrilir.
2. Parçalama (chunking): Metin, tek bir konuyu anlatan ve modelin bağlamına rahatça sığan parçalara bölünür. Her parçayla birlikte belge adı, sayfa ve bölüm bilgisi saklanır.
3. Embedding: Her parça bir embedding modeliyle, anlamını temsil eden bir sayı dizisine (vektöre) dönüştürülür.
4. İndeks: Vektörler bir vektör veritabanına veya arama indeksine yazılır. Kelime tabanlı arama da kullanılacaksa ayrıca bir kelime indeksi oluşturulur.

Sorgu

5. Sorunun vektörü: Kullanıcının sorusu, parçalarda kullanılan embedding modeliyle vektöre çevrilir. İndeksleme ve sorgu farklı modellerle yapılırsa arama başarısız olur veya kötü sonuç verir.
6. Arama: Soruya en yakın birkaç parça bulunur. İsteğe bağlı bir yeniden sıralama (reranking) adımı bu parçaları yeniden puanlayabilir.
7. Bağlam: Bulunan parçalar soruyla birlikte modele verilir. Prompt, modelden yalnızca bu parçalara dayanmasını ve bilgi yetersizse bunu söylemesini ister.
8. Yanıt ve kaynak: Yanıt, dayandığı parçaların belge adı, sayfa ve bölüm bilgisiyle birlikte gösterilir.

Örneğin teknik servis çalışanı "P-200 pompasında salmastra contası ne zaman değiştirilir?" diye sorar. Sistem 212 sayfalık bakım kılavuzunda § 6.2’yi bulur ve yanıtı ("her 4.000 çalışma saatinde") bu bölümün referansıyla gösterir. (Örnek belge, Doküman Asistanı sayfası için yazılmıştır.)

Arama: anlamsal, kelime tabanlı ve hibrit

RAG’in kalitesini en çok arama adımı belirler; model, kendisine verilmeyen bir parçadan yanıt üretemez.

Anlamsal aramada soru ile bulunan kayıt arasında ortak kelime olması gerekmez. letsearch sayfasındaki örnekte "Ürün çok gürültülü çalışıyor" sorusu, "Fan sesi artarsa yatakları yağlayın." kaydını bulur. Türkçede kelime tabanlı arama ek bir zorlukla karşılaşır: "pompa", "pompanın" ve "pompaya" farklı kelimeler olarak sayılır. Bu yüzden Türkçe kelime aramasında kök bulma veya morfolojik analiz genellikle sonucu iyileştirir. Ayrıntılar için Türkçe doğal dil işleme rehberine bakabilirsiniz.

Ne zaman RAG, ne zaman başka bir yöntem?

RAG şu durumlarda uygundur: bilgi belgelerde duruyor, belgeler sık güncelleniyor, yanıtın kaynağının gösterilmesi gerekiyor ve farklı kullanıcılar farklı belgelere erişiyor.

Başka bir yöntem gerekebilir:

• Modelin alan dilini veya yanıt biçimini öğrenmesi gerekiyorsa fine-tuning düşünülmeli. İkisi rakip değildir: ALTAI blogunda ele aldığımız bir akademik çalışmada, birçoğu sentetik üretilmiş soru-cevaplarla eğitilen LoRA adaptörlerini erişimle birlikte kullanan kurulum, yalnız RAG’den daha iyi sonuç verdi. Ayrıntılar Fine-tuning mi RAG mi? rehberinde.
• Belgeler az ve kısaysa hepsini modelin bağlam penceresine koymak yeterli olabilir.
• Soru bir tablo veya veritabanı üzerinde hesaplama gerektiriyorsa sorgu çalıştıran bir yapay zekâ ajanı daha uygundur.

Adım adım RAG sistemi kurmak

1. Belgeleri ve yetkileri seçin. Hangi belge koleksiyonları kullanılacak, kim hangisini görebilecek? Yürürlükten kalkmış revizyonları baştan ayırın.
2. Belgeleri Markdown’a dönüştürün. Başlıkların, listelerin ve tabloların korunması parçalamayı ve kaynak göstermeyi kolaylaştırır. Taranmış PDF’ler için OCR gerekir.
3. Parçalama kuralını belirleyin. Başlık ve bölüm sınırlarına göre bölmek, sabit uzunlukta kesmekten genellikle daha anlamlı parçalar verir. Çok küçük parça bağlamı kaybeder, çok büyük parça gereksiz metin taşır. Sayfa ve bölüm bilgisini parçayla birlikte saklayın.
4. Embedding modelini kendi sorularınızla seçin. Genel benchmark sonuçları sizin belgelerinizdeki sonucu göstermez. Türkçe seçenekler için Türkçe embedding modelleri rehberine bakın.
5. Aramayı kurun. Anlamsal, kelime tabanlı veya hibrit aramayı ve modele kaç parça verileceğini (top-k) test ederek belirleyin.
6. Prompt’u yazın. Model yalnızca verilen parçalara dayanmalı, bilgi yoksa bunu söylemeli ve kaynağı belirtmeli.
7. Değerlendirme seti hazırlayın. Çalışanların gerçek sorularını ve her yanıtın bulunduğu belge ve bölümü listeleyin. Doğru parçanın ilk sonuçlarda bulunma oranını (Recall@10 gibi) ve yanıtın kaynakla desteklenip desteklenmediğini ayrı ölçün. Sentetik sorular seti genişletir ama gerçek soruların yerini tutmaz.
8. Güncellemeyi planlayın. Belgeler değiştiğinde ilgili parçaların yeniden indekslenmesi gerekir.

Dikkat edilmesi gerekenler

• Dönüştürme kalitesi her şeyi etkiler. Tablosu bozulmuş, sütunları karışmış bir PDF metni doğru aranamaz. Dönüştürülen metni indekslemeden önce örnekler üzerinden gözle kontrol edin.
• Erişim kontrolü aramada uygulanmalı. Kullanıcının yetkisi olmayan bir parça modele hiç verilmemeli; yanıt aşamasında filtrelemek geç kalır.
• Kaynak göstermek doğruluk garantisi değildir. Bulunan parça eski bir revizyondan olabilir veya soruyla yalnızca kısmen ilgili olabilir. Kaynak, çalışanın kontrol edebilmesi içindir.
• RAG halüsinasyonu azaltır, sıfırlamaz. Model, parçada olmayan bir ayrıntıyı yine de ekleyebilir; değerlendirme setinde bunu ayrıca ölçün.
• Kişisel veriler ve dış servisler. Belgeler kişisel veri içerebilir. Dönüştürme veya yanıt üretimi için dış bir servis kullanılıyorsa hangi verinin kurum dışına çıktığını bilin; model çağrılarına kural koymak için bir AI gateway kullanılabilir. Hukuki çerçeve için KVKK ve yapay zekâ rehberine bakın. Bu metin hukuki danışmanlık değildir; kendi durumunuz için bir hukukçuya danışın.

ALTAI’de nasıl yapıyoruz

Doküman Asistanı, çalışanların kılavuz, prosedür ve ürün belgelerinde arama yapabileceği, ALTAI’nin geliştirdiği bir belge asistanı. Seçtiğiniz PDF ve DOCX belgelerini işleyip arama için indeksliyor, Türkçe sorular ve kurum terimleriyle test ediyoruz. Her yanıt, dayandığı belge bölümünü gösterir. Belge izinlerini kurumun kimlik sistemiyle birlikte tasarlıyor; uygulamayı kurum içinde, VPC’de veya seçilen bulut ortamında kurabiliyoruz. Gerektiğinde Yada ile model erişim kuralları, isanagent ile araç kullanan görevler ekliyoruz.

Bu yapının arkasında açık kaynak araçlarımız var:

• llm-food PDF, DOC/DOCX, RTF, PPTX ve HTML içeriğini Markdown’a dönüştürür; API, Python istemcisi veya komut satırıyla çalışır. Seçilen PDF yöntemi Google Cloud ve Gemini kullanabilir: taranmış PDF’ler Gemini’ye gider, yerel bir sunucu her yolu yerel yapmaz.
• letsearch metinleri embedding modeliyle vektörlere dönüştürüp indeksler ve bir arama servisi olarak sunar. JSONL, Parquet ve Hugging Face veri setlerini okur; Rust ve ONNX ile çalışır, Apache-2.0 lisanslıdır. Proje erken aşamadadır: PDF içe aktarma, MCP ve artımlı indeksleme yol haritasındadır, bugünkü özellik değildir.
• Akana 2,5 MB’lık yerleşik bir Türkçe embedding modeli ve ALTAI’nin geliştirdiği hibrit arama yöntemini içerir: 1-bit vektörler morfolojik BM25 ile birleşir. Projenin kendi testlerine göre bu yöntem Türkçe RAG testlerinde yalnız CPU ile %96,7–100 Recall@10’a ulaşır.
• Türkçe embedding modelleri BGE-M3 Distill 4L (1024 boyut) ve Model2Vec TurboQuant 2-bit’tir (256 boyut). Bu modelleri diğer seçeneklerle birlikte kurumunuzun verisinde test edip arama doğruluğu, bellek kullanımı ve çalışma süresine göre seçiyoruz.

Test sorularını çalışanların günlük sorularından seçiyoruz. Ölçtüklerimiz: yanıtın kaynak belgelerle desteklenmesi, doğru belgenin ve bölümün bulunması, çalışanın arama ve düzeltme için harcadığı süre. Belge asistanınızı konuşmak için bize yazın.

Sık sorulan sorular

RAG ile fine-tuning arasındaki fark nedir?

RAG, modeli değiştirmeden her soruda ilgili belge parçalarını bulup modele verir. Fine-tuning ise modeli kendi örneklerinizle yeniden eğiterek alan dilini ve yanıt biçimini öğretir. Güncel ve kaynağı gösterilmesi gereken bilgi için RAG, davranış ve biçim için fine-tuning daha uygundur; ikisi birlikte de kullanılabilir.

RAG halüsinasyonu tamamen önler mi?

Hayır. RAG modeli doğru parçaya götürerek uydurma riskini azaltır, fakat model parçada olmayan bir ayrıntı ekleyebilir veya yanlış parçaya dayanabilir. Bu yüzden yanıtla birlikte kaynağı göstermek ve sistemi gerçek sorularla düzenli olarak ölçmek gerekir.

Türkçe belgeler için hangi embedding modeli kullanılmalı?

Tek bir doğru model yoktur; seçimi kendi sorularınız ve belgelerinizle ölçerek yapmalısınız. Arama doğruluğunun yanında bellek kullanımı ve hız da önemlidir. ALTAI’nin iki açık Türkçe modeli BGE-M3 Distill 4L (1024 boyut) ve Model2Vec TurboQuant 2-bit’tir (256 boyut); karşılaştırma için Türkçe embedding modelleri rehberine bakın.

Taranmış PDF’ler RAG için kullanılabilir mi?

Kullanılabilir, ancak önce OCR ile metne çevrilmeleri gerekir ve sonuç kalitesi taramanın kalitesine bağlıdır. OCR için hangi servisin kullanıldığını da kontrol edin: llm-food’da taranmış PDF’ler Gemini’ye gönderilir, yani belge kurum dışına çıkar.

Hibrit arama nedir, neden gerekir?

Hibrit arama, kelime tabanlı arama (örneğin BM25) ile anlamsal aramanın sonuçlarını birleştirir. Kelime araması ürün kodu ve madde numarası gibi birebir terimlerde, anlamsal arama farklı kelimelerle sorulan sorularda güçlüdür. Kurumsal belgelerde iki tür soru da sorulduğu için hibrit arama genellikle daha dengeli sonuç verir.

RAG için vektör veritabanı şart mı?

Şart değildir. Küçük koleksiyonlarda bellekte tutulan bir indeks veya letsearch gibi kendi indeksini arama servisi olarak sunan bir araç yeterli olabilir. Koleksiyon büyüdükçe, sık güncelleme ve filtreleme gerektiğinde Qdrant veya PostgreSQL için pgvector gibi açık kaynak vektör veritabanları kullanılır.