RAG (Retrieval-Augmented Generation, arama destekli üretim), bir dil modelinin soruyu yanıtlamadan önce sizin belgelerinizde arama yapıp bulduğu bölümlere dayanarak yanıt üretmesini sağlayan yöntemdir. Model yeniden eğitilmez. Belge güncellendiğinde yanıt da güncellenir ve her yanıt, dayandığı belgeye bağlanabilir. Prosedür, sözleşme ya da ürün belgelerinden yanıt veren bir asistan kurmak isteyen şirket için başlangıç noktası budur.
Öne çıkanlar
- Yöntem adını, NeurIPS 2020'de kabul edilen "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" makalesinden alır (Lewis vd., arXiv, 22 Mayıs 2020 (yeni sekmede açılır)).
- Bilgi tabanı küçükse RAG şart değildir. Anthropic, 200.000 token'dan (yaklaşık 500 sayfa) küçük bir bilgi tabanının tamamının doğrudan isteme (prompt) eklenebileceğini belirtir (Anthropic, 19 Eylül 2024 (yeni sekmede açılır)).
- Anlam aramasını anahtar kelime aramasıyla birleştirmek fark yaratır. Anthropic'in kendi testlerinde, bağlam eklenmiş gömme vektörleri ile BM25 birlikte kullanıldığında ilk 20 sonuçta bulunamayan ilgili parça oranı %49, yeniden sıralama eklenince %67 azaldı (Anthropic, 19 Eylül 2024 (yeni sekmede açılır)).
- Türkçe belgeler ek iş ister: taranmış PDF'ler, sondan eklemeli yapı, İ/ı harf dönüşümü ve madde-fıkra düzeni.
RAG nasıl çalışır?
RAG iki aşamadan oluşur: belgeler bir kez hazırlanıp dizinlenir, her soruda bu dizinde arama yapılır. Model, yalnızca aramanın getirdiği bölümleri okuyarak yanıt yazar.
Akış beş adımdır:
- Belgeler metne çevrilir. PDF, Word dosyası, e-posta, iç wiki sayfası. Taranmış belgeler önce optik karakter tanımadan (OCR) geçer.
- Metin parçalara bölünür. Uzun belge, anlamı bütün kalan bölümlere (chunk) ayrılır. Her parçaya belge adı, bölüm başlığı ve tarih gibi bilgiler eklenir.
- Parçalar dizinlenir. Her parça bir gömme vektörüne (embedding) çevrilir. Gömme vektörü, metnin anlamını sayılarla temsil eden bir dizidir; anlamca yakın metinlerin vektörleri de birbirine yakın düşer. Vektörler bir vektör veri tabanında (vector database) saklanır. Aynı parçalar anahtar kelime araması için de dizinlenebilir.
- Soru aranır. Kullanıcının sorusu da vektöre çevrilir ve en yakın parçalar bulunur. BM25 gibi bir anahtar kelime algoritması birlikte kullanılırsa madde numarası ya da ürün kodu gibi kesin ifadeler de kaçmaz.
- Yanıt üretilir. Bulunan parçalar soruyla birlikte modele verilir. Model yanıtı bu parçalara dayanarak yazar; sistem buna göre kurulduysa hangi parçayı kullandığını da gösterir.
Yöntemin kökü 2020'ye uzanır. Lewis ve arkadaşları, dil modelinin kendi parametrelerinde taşıdığı bilgiyi Vikipedi'nin vektör dizini gibi dış bir bellekle birleştirmeyi önerdi. Makale, kararların kaynağını göstermeyi ve modelin bilgisini güncellemeyi o dönemin açık sorunları arasında sayıyordu.
RAG, bir yapay zekâ ajanının bilgiye erişme yollarından biridir. Ajanın diğer parçalarını yapay zekâ ajanı nedir? rehberinde anlatıyoruz.
RAG, ince ayar ve uzun bağlam: hangisi ne zaman?
Şirket bilgisini bir dil modeline vermenin üç yolu vardır. RAG belgeleri her soruda arayıp getirir. İnce ayar, modelin kendisini ek eğitimle değiştirir. Uzun bağlam (long context) yaklaşımında ise belgelerin tamamı her seferinde modele verilir.
| RAG | İnce ayar (fine-tuning) | Tüm belgeyi isteme koymak | |
|---|---|---|---|
| Neyi değiştirir? | Modele verilen bilgiyi | Modelin davranışını ve üslubunu | Modele verilen bilgiyi |
| Belge değişince | Yalnızca değişen parça yeniden dizinlenir | Yeniden eğitim gerekir | Bir sonraki soruda yeni belge verilir |
| Kaynak gösterme | Doğal olarak mümkün | Zor | Mümkün, ama metin uzadıkça zorlaşır |
| Uygun olduğu durum | Büyük ve sık değişen belge arşivi | Sabit bir biçim ya da üslup öğretmek | Küçük ve az değişen bilgi tabanı |
| Kullanım maliyetini belirleyen | Her soruda getirilen parça sayısı | Eğitim ve modeli çalıştırma altyapısı | Her soruda okunan metnin tamamı |
Token, modelin metni işlerken kullandığı kelime parçasıdır. Anthropic'in verdiği 200.000 token sınırının sayfa karşılığı dile göre değişebilir; Türkçe belgelerde bu sayıyı kendi metinlerinizle ölçmek gerekir. Token'ın maliyete etkisini LLM API maliyeti yazısında anlatıyoruz.
Kısacası: birkaç düzine sayfalık bir prosedür kitapçığı için arama altyapısı kurmak gereksiz olabilir. Büyük ve sık değişen bir arşivde ise RAG çoğu zaman en gerçekçi yoldur.
Türkçe belgelerde dört özel sorun
Dört sorun, Türkçe belgelerle kurulan bir RAG sisteminin kalitesini doğrudan etkiler. Hepsi model seçiminden önce, belge hazırlığında çözülür.
1. Taranmış PDF ve mühürlü belgeler
Islak imzalı yazı, sözleşme ve tutanaklar taranarak arşivlendiyse bu belgelerde aranabilir metin yoktur; önce OCR gerekir. OCR; tablo, kaşe, imza ve el yazısında zorlanır. Bu yüzden OCR çıktısından örnek sayfalar kontrol edilmeli, hatalı sayfalar dizinlemeden önce işaretlenmelidir.
2. Sondan eklemeli yapı
Türkçede tek bir kök pek çok biçime girer: "sözleşme", "sözleşmenin", "sözleşmelerdeki", "sözleşmesinden". Yalnızca birebir kelime eşleşmesine dayanan arama, bu biçimleri birbirinden ayrı sayar.
Çözüm, anahtar kelime aramasında kök bulma (stemming) kullanmaktır. Örneğin PostgreSQL, Türkçe için Snowball tabanlı bir kök bulma sözlüğüyle (turkish_stem) gelir (PostgreSQL 18 belgeleri, erişim 13 Ekim 2026 (yeni sekmede açılır)). Gömme vektörleri biçim farkına daha dayanıklıdır, ama kesin ifadeleri kaçırabilir. İki aramayı birlikte kullanmak (hibrit arama) bu yüzden Türkçede ayrıca anlamlıdır.
3. İ, I, ı ve i
Türkçede büyük-küçük harf dönüşümü İngilizceden farklıdır. MDN belgelerindeki örnekte "İstanbul", Türkçe dil ayarıyla küçültüldüğünde "istanbul" olur. ABD İngilizcesi ayarıyla ise "i" harfinin üzerine ayrı bir nokta işareti eklenmiş bir biçim çıkar (MDN, erişim 13 Ekim 2026 (yeni sekmede açılır)). Bu biçim, "istanbul" aramasıyla eşleşmeyebilir.
Kural basit: hem belgeleri hem soruları aynı Türkçe kuralla normalleştirin. Dil ayarı verilmeden yapılan her küçük harf dönüşümü, sessiz bir arama hatasına dönüşebilir.
4. Madde, fıkra ve bent düzeni
Mevzuat, sözleşme ve iç yönetmelikler madde düzeninde yazılır. Metni sabit uzunlukta parçalara bölmek, bir maddeyi ortasından keser ve bentleri bağlamından koparır.
Daha iyi yol, metni madde sınırından bölmek ve her parçaya belge adını, madde numarasını ve metnin tarihini eklemektir. Değişen metinlerde bu tarihin neden kritik olduğunu mevzuat yapay zekâ asistanı yazımızda bir kanun örneğiyle gösteriyoruz.
Şirket belgeleriyle RAG kurulumu: adım adım
Teknik kurulum işin yalnızca bir kısmıdır. Belgeyi, yetkiyi ve ölçümü baştan düşünmeyen bir RAG sistemi, kullanıcıların güvenini çabuk kaybeder.
- Belge envanteri çıkarın. Hangi belgeler, hangi biçimde, kimde duruyor? Güncel olmayan ve birbiriyle çelişen sürümleri ayıklayın.
- Yetkiyi belirleyin. Arama, kullanıcının görmeye yetkili olmadığı belgeyi getirmemelidir. Bu kontrol modele verilen talimata değil, arama katmanına konur.
- Parçalama kuralını belgeye göre seçin. Sözleşme ve yönetmelikte madde, kılavuzda başlık, e-postada tek mesaj iyi bir sınırdır.
- Aramayı hibrit kurun. Anlam araması ile Türkçe kök bulmalı anahtar kelime aramasını birlikte kullanın. Gerekirse sonuçları yeniden sıralayın (reranking).
- Gerçek sorulardan değerlendirme seti hazırlayın. Her soru için doğru yanıtı ve hangi belgede olduğunu yazın. Önce aramanın doğru parçayı getirip getirmediğini, sonra yanıt kalitesini ölçün.
- "Bilmiyorum" eşiğini tanımlayın. Arama yeterince ilgili parça bulamazsa asistan tahmin yürütmemeli, kaynağı olmadığını söylemelidir.
- Güncelleme akışını kurun. Değişen belge yeniden dizinlenmeli, eski sürüm aramadan çıkarılmalı ya da tarihle etiketlenmelidir.
- Kayıt tutun. Hangi sorunun hangi parçalarla yanıtlandığı izlenebilir olmalıdır. Hatalı bir yanıtın nedeni ancak böyle bulunur.
Kurulum emeğini en çok belge sayısı ve biçimi, taranmış belgelerin oranı, yetki yapısının karmaşıklığı ve güncelleme sıklığı belirler.
Sık yapılan hatalar
Aşağıdaki hataların hiçbiri modelden kaynaklanmaz. Bu yüzden model değiştirmek onları çözmez.
- Belgeyi sabit uzunlukta bölüp bir maddeyi ya da tabloyu ortasından kesmek.
- Yalnızca anlam aramasına güvenip madde numarası, ürün kodu gibi kesin ifadeleri kaçırmak.
- Türkçe harf dönüşümünü dil ayarı vermeden yapmak.
- Aynı belgenin eski ve yeni sürümünü birlikte dizinde tutmak.
- Kaynak göstermeyen yanıtlara izin vermek.
- Değerlendirme seti olmadan model ya da parçalama kuralı değiştirmek.
- Excel tablosu ya da veri tabanındaki sayısal soruları metin aramasıyla yanıtlamaya çalışmak. Bu tür sorularda modelin bir sorgu aracını çalıştırması daha doğrudur.
Kaynak zorunluluğu ve "bilmiyorum" kuralının ayrıntılarını yapay zekâda halüsinasyon yazısında ele alıyoruz.
Bizim deneyimimiz
Belgelerden yanıt veren bir asistan kurarken modelden önce belgeyle uğraşırız: toplama, ayıklama, bölme ve dizinleme. Vektör arama için çoğu projede PostgreSQL üzerinde çalışan pgvector eklentisi yetiyor. pgvector, Postgres'in tam metin aramasıyla birlikte hibrit arama için kullanılabiliyor (pgvector, erişim 13 Ekim 2026 (yeni sekmede açılır)). Böylece Türkçe kök bulmalı anahtar kelime araması ile anlam araması aynı veri tabanında durabiliyor.
Değerlendirme setini kod yazmadan önce gerçek sorularla kurar, her değişiklikte yeniden çalıştırırız. Uygulamayı tek bir model sağlayıcısına bağlamadan kurduğumuz için, model değişikliği gündeme geldiğinde aynı set iki modeli karşılaştırmaya yarar.
Kendi ürünümüz Kentsel Dönüşüm AI, kentsel dönüşümle ilgili soruları yanıtlıyor. Mevzuat metinleriyle çalışan bir asistanda dikkat ettiğimiz noktaları mevzuat asistanı yazısında topladık. Bu tür bir asistanı kendi belgelerinizle kurmak isterseniz belgelerinizden yanıt veren asistan geliştirme sayfamıza bakabilirsiniz.
Sık sorulan sorular
RAG ile chatbot arasındaki fark nedir?
Chatbot bir arayüzdür; RAG ise o arayüzün arkasında çalışabilen bir yöntemdir. RAG kullanan bir sohbet botu, yanıtını kendi genel bilgisinden değil, belgelerinizden getirdiği bölümlerden üretir. Sohbet botu, asistan ve ajan ayrımını chatbot ile yapay zekâ ajanı farkı yazısında anlatıyoruz.
Vektör veri tabanı şart mı?
Ayrı bir ürün olması şart değil. Küçük ve orta ölçekli arşivlerde PostgreSQL gibi mevcut bir veri tabanına eklenen vektör desteği yeterli olabilir. Çok küçük bir bilgi tabanında ise arama altyapısı hiç gerekmeyebilir.
RAG halüsinasyonu tamamen önler mi?
Hayır, azaltır. Arama yanlış parçayı getirebilir ya da model doğru parçayı yanlış özetleyebilir. Kaynak gösterme, "bilmiyorum" eşiği ve düzenli değerlendirme bu riski sınırlar.
Belgelerimiz yurt dışındaki bir modele gönderilir mi?
Bu, kullandığınız model sağlayıcısına bağlıdır. Arama sonucunda bulunan parçalar her soruda modele gönderilir. Belgelerde kişisel veri varsa ve sağlayıcı yurt dışındaysa, KVKK'nın Kasım 2025 tarihli rehberinin hatırlattığı gibi aktarım 6698 sayılı Kanun'un 9. maddesine uygun olmalıdır (KVKK, Kasım 2025 (yeni sekmede açılır)). Kişisel veriyi dizinlemeden önce ayıklamak ya da modeli yurt içinde çalıştırmak seçenekler arasındadır.
Kaynaklar
- Patrick Lewis vd., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401, 22 Mayıs 2020 (NeurIPS 2020). arxiv.org (yeni sekmede açılır)
- Anthropic, "Introducing Contextual Retrieval", 19 Eylül 2024. anthropic.com (yeni sekmede açılır)
- PostgreSQL Global Development Group, "PostgreSQL 18 Documentation – 12.10. psql Support", erişim 13 Ekim 2026. postgresql.org (yeni sekmede açılır)
- MDN Web Docs, "String.prototype.toLocaleLowerCase()", erişim 13 Ekim 2026. developer.mozilla.org (yeni sekmede açılır)
- pgvector, "Open-source vector similarity search for Postgres", GitHub, erişim 13 Ekim 2026. github.com (yeni sekmede açılır)
- Kişisel Verileri Koruma Kurumu, "Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)", Yayın No 113, Kasım 2025. kvkk.gov.tr (yeni sekmede açılır)
