Büyük Dil Modelleri güçlüdür — ama hallüsinasyon yaparlar. Eğitim verilerinden emin görünen ama güncel olmayan, eksik veya tamamen yanlış yanıtlar üretirler. Retrieval-Augmented Generation (RAG), modeli tek bir token üretmeden önce gerçek, doğrulanabilir veriye dayandırarak bu sorunu çözer.
Bu rehberde, sıfırdan üretim ortamına hazır bir RAG sistemi kuracağız: veri hazırlığı, embedding, retrieval, üretim ve bir demoyu güvenilir bir üretim sisteminden ayıran optimizasyonlar.
RAG Nedir?
RAG, bir retriever (arama bileşeni) ile bir generator (LLM) birleştiren hibrit bir yapay zeka mimarisidir. Model yalnızca parametrik hafızasına güvenmek yerine, önce harici bir bilgi tabanından ilgili belgeleri getirir, sonra bu bağlamı kullanarak yanıtını üretir.
Örnek: Bir müşteri destek botu _"API anahtarımı nasıl sıfırlarım?"_ sorusunu alır. Tahmin etmek yerine:
1. Sorguyu vektöre dönüştürür 2. Şirketin dokümantasyon veritabanında arama yapar 3. En alakalı 3 paragrafı getirir 4. Bunları bağlam olarak LLM'e gönderir 5. LLM, gerçek dokümantasyona dayanan bir yanıt üretir
Sonuç: doğru, güncel ve doğrulanabilir yanıtlar.
Temel Bileşenler
| Bileşen | Görev | Araçlar | |---|---|---| | Veri Pipeline | Doküman okuma, temizleme, chunk'lama | LangChain, LlamaIndex | | Embedding Modeli | Metni vektör temsiline dönüştürme | OpenAI Ada v2, Sentence-BERT | | Vektör Veritabanı | Embedding'leri indeksleme ve arama | FAISS, Pinecone, Weaviate, Chroma | | Retriever | En alakalı chunk'ları bulma | BM25, dense search, hibrit | | LLM Generator | Getirilen bağlamdan yanıt üretme | GPT-4, Llama 3, Claude | | Re-ranker | Sonuçları alakalılığa göre yeniden sıralama | Cohere Rerank, BGE Reranker |
Veri Hazırlığı ve Chunking
Ham verilerinizin kalitesi, tüm RAG sisteminizin tavanını belirler. Çöp girerse çöp çıkar — bu, retrieval için eğitimden bile daha geçerlidir.
Adım 1: Verinizi Temizleyin
- De-duplikasyon — Tekrar eden paragrafları kaldırın. Aksi hâlde model aynı bilgiyi birden fazla "bağımsız" kaynak olarak görür ve potansiyel olarak yanlış veriye olan güveni şişirir.
- Normalizasyon — Unicode hataları, tutarsız büyük/küçük harf, encoding sorunları ve gereksiz biçimlendirme kalıntılarını düzeltin.
- Metadata çıkarımı — Doküman başlıkları, bölüm başlıkları, tarihler ve kaynak URL'lerini koruyun. Bu metadata, filtreleme ve kaynak gösterme için çok değerli hale gelir.
- Çok aşamalı retrieval — İlk geçiş: ucuz, geniş filtre (BM25 ile 1000 doküman → en iyi 100). İkinci geçiş: pahalı, hassas re-ranker (en iyi 100 → en iyi 5).
- Asenkron pipeline — Retrieval ve LLM ısınmasını paralel başlatın.
- Önceden hesaplanmış embedding'ler — Sık sorulan sorgular için embedding'leri önbelleğe alın.
- Güven puanlaması — Retrieval benzerlik puanlarını ölçün. En iyi eşleşme bir eşiğin altındaysa (ör. kosinüs benzerliği < 0.7), üretilmiş yanıt yerine "Yeterli bilgim yok" döndürün.
- Kaynak atıfı — Yanıtla birlikte her zaman kaynak dokümanları döndürün. Kullanıcıların doğrulamasını sağlayın.
- Dayanak doğrulama — Üretilen yanıtın gerçekten getirilen bağlam tarafından desteklendiğini doğrulamak için ikinci bir LLM çağrısı kullanın.
- İndeks parçalama — Büyük doküman koleksiyonları için vektör indeksinizi birden fazla düğüme bölün.
- Katmanlı depolama — Sık erişilen embedding'leri bellekte tutun, eskileri diske arşivleyin.
- Artımlı indeksleme — Yeni doküman eklediğinizde her şeyi yeniden embed etmeyin; mevcut indekse ekleyin.
Adım 2: Chunking Stratejisi
Chunking, dokümanları vektör veritabanınızdaki bireysel kayıtlara dönüşecek parçalara bölme şeklinizdir. Bu tek karar, retrieval kalitesi üzerinde orantısız bir etkiye sahiptir.
| Strateji | Chunk Boyutu | Artıları | Eksileri | |---|---|---|---| | Sabit boyut | 256–512 token | Basit, öngörülebilir | Cümle ortasında keser | | Cümle bazlı | Değişken | Sınırlara saygı duyar | Eşitsiz boyutlar | | Semantik | Değişken | İlgili içeriği gruplar | Daha karmaşık | | Recursive | Örtüşmeli 512 token | İyi denge | Ayar gerektirir |
Temel kural: 512 token ve 50 token örtüşme ile recursive chunking ile başlayın. Test seti üzerinde retrieval recall ölçün, sonra ayarlayın.
Büyük chunk'lar daha fazla bağlam yakalar ama gürültü getirir. Küçük chunk'lar hassastır ama çevreleyen anlamı kaybedebilir. Örtüşme, chunk'lar arasındaki boşluğa bilgi düşmemesini sağlar.
Retrieval: RAG'ın Kalbi
Retriever en kritik bileşendir. Doğru belgeleri bulamazsa, en iyi LLM bile yanlış bir yanıt üretir — sadece daha akıcı bir şekilde.
Sparse Arama (BM25)
BM25, anahtar kelime tabanlı aramadır. Hızlı, yorumlanabilir ve tam eşleşmelerde üstündür. Kullanıcı "PostgreSQL connection pooling" araması yaptığında, BM25 bu tam terimleri içeren dokümanları güvenilir şekilde bulur.
Dense Arama (Embedding)
Dense retrieval, semantik anlamı yakalamak için sinir ağı embedding'lerini kullanır. _"Veritabanı bağlantılarını verimli şekilde nasıl yönetirim"_ sorgusu, bu tam kelimeler olmasa bile connection pooling hakkındaki dokümanlarla eşleşir.
Hibrit Arama (Her İkisinin En İyisi)
2025 itibarıyla, hibrit retrieval en yüksek recall değerlerini verir:
1. BM25 ve dense aramayı paralel çalıştırın 2. Sonuçları Reciprocal Rank Fusion (RRF) kullanarak birleştirin 3. Birleştirilmiş sonuçları son sıralama için re-ranker'dan geçirin
Bu yaklaşım hem tam anahtar kelime eşleşmelerini hem semantik benzerlikleri yakalar.
from langchain.retrievers import EnsembleRetriever from langchain.retrievers import BM25Retriever from langchain.vectorstores import FAISS# Sparse retriever bm25 = BM25Retriever.from_documents(docs, k=10)
# Dense retriever vectorstore = FAISS.from_documents(docs, embeddings) dense = vectorstore.as_retriever(search_kwargs={"k": 10})
# Hibrit: 50/50 ağırlık hybrid = EnsembleRetriever( retrievers=[bm25, dense], weights=[0.5, 0.5] )
Multi-Vector Retrieval
Gelişmiş bir teknik: chunk başına birden fazla embedding vektörü saklayın. Örneğin, hem chunk içeriğini hem de oluşturulmuş bir özeti embed edin. Farklı sorgu türleri aynı içeriğin farklı temsilleriyle eşleşir ve çeşitli soru stillerinde recall'ı artırır.
Basit Bir RAG Pipeline'ı Oluşturma
LangChain ve FAISS kullanan eksiksiz, minimal bir RAG pipeline'ı:
from langchain.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS from langchain.chains import RetrievalQA from langchain.llms import OpenAI# 1. Dokümanları yükle loader = DirectoryLoader("./docs", glob="*/.md") documents = loader.load()
# 2. Dokümanları parçala splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=50, separators=["\n\n", "\n", ". ", " "] ) chunks = splitter.split_documents(documents)
# 3. Vektör deposu oluştur embeddings = OpenAIEmbeddings() vectorstore = FAISS.from_documents(chunks, embeddings)
# 4. Retriever kur retriever = vectorstore.as_retriever( search_type="similarity", search_kwargs={"k": 4} )
# 5. RAG chain oluştur qa_chain = RetrievalQA.from_chain_type( llm=OpenAI(temperature=0), chain_type="stuff", retriever=retriever, return_source_documents=True )
# 6. Sorgu result = qa_chain.invoke("KV Cache nedir?") print(result["result"]) for doc in result["source_documents"]: print(f" Kaynak: {doc.metadata['source']}")
Üretim Ortamı Dikkat Noktaları
Bir RAG demosu bir gün sürer. Bir üretim RAG sistemi haftalar alır. İşte onları ayıran şeyler.
Gecikme vs. Doğruluk
Eklediğiniz her katman (retrieval → re-ranking → üretim) gecikme ekler. Bunu şöyle dengeleyin:
Hallüsinasyonu Azaltma
Retrieval ile bile hallüsinasyon ortadan kalkmaz — azalır. Daha da azaltmak için:
İzleme
Üretim ortamında şunları takip edin:
| Metrik | Ne Söyler | |---|---| | Retrieval recall | İlgili dokümanlar bulunuyor mu? | | Yanıt sadakati | Yanıt kaynaklara dayalı mı? | | Gecikme (P50/P99) | Sistem yeterince hızlı mı? | | Kullanıcı geri bildirimi | Yanıtlara beğen/beğenme |
Ölçeklendirme
2025 Yenilikleri
HetaRAG
Vektör veritabanı, bilgi grafiği, tam metin indeksi ve ilişkisel veritabanını tek bir retrieval katmanında birleştirir. Yalnızca vektör benzerliğine güvenmek yerine, ilişkileri takip edebilir ve yapılandırılmış filtreler uygulayabilir — salt vektör aramasının sınırlarını aşar.
Federated RAG
Sağlık ve finans gibi hassas alanlar için: ham veriyi paylaşmadan dağıtık veri kaynakları üzerinde RAG çalıştırın. Her veri sahibi yerel retrieval yapar; yalnızca getirilen chunk'lar (veya özetleri) generator'a gönderilir. Ölçekte gizlilik koruyan RAG.
Adaptive Retrieval
Sorgu karmaşıklığına göre retrieval derinliğini dinamik olarak ayarlar. Basit olgusal sorular hızlı, sığ arama alır. Karmaşık analitik sorular re-ranking ve çok adımlı muhakeme ile daha derin retrieval tetikler. Bu hem gecikmeyi hem maliyeti optimize eder.
Sonuç
RAG, LLM'leri üretim ortamında güvenilir kılmanın en pratik yoludur. Mimari kavramsal olarak basittir — getir, sonra üret — ama mühendislik detayları muazzam önem taşır. Temellerle başlayın: temiz veri, iyi chunking, hibrit retrieval. Sonra gerçek metriklere göre iterasyon yapın.
Kaynaklar
1. Pinecone — Retrieval-Augmented Generation (RAG) 2. DEV Community — Best Practices for Building Robust RAG Systems (2025) 3. Chitika — RAG Definitive Guide 2025 4. Aggil.fr — RAG in 2025: Best Practices 5. IEEE — Best Practices for Constructing Knowledge Graphs in RAG Systems (2025) 6. arXiv 2501.07391 — Enhancing RAG: A Study of Best Practices (Jan 2025) 7. arXiv 2508.06401 — Systematic Literature Review of RAG (2025) 8. arXiv 2505.18906 — HetaRAG: Heterogeneous Data Stores for Hybrid Deep Retrieval (2025) 9. arXiv 2505.18906 — Federated RAG: Systematic Mapping Study (May 2025)
Yorumlar (