RAG
Retrieval-Augmented Generation
Sorgu → belge arama → LLM bağlamı → yanıt üretme zinciri.
Bir kullanıcı soru sorduğunda önce ilgili belgeler bulunur (retrieval — arama), bu belgeler LLM'e bağlam olarak iliştirilir (augmentation — zenginleştirme), sonra LLM cevabı üretir (generation). Modeli yeniden eğitmeden ona güncel ya da özel bilgi eklemenin en yaygın yolu.
Tipik akış: 1. Belgeler küçük parçalara (chunk) bölünür ve her parça embedding'e (anlam-vektörü) çevrilir. 2. Bu vektörler vektör veritabanına yüklenir. 3. Bir soru gelince sorunun da embedding'i hesaplanır. 4. Vektör veritabanı soruya en yakın K parçayı (genelde 5-20) döner. 5. Bu parçalar prompt'a eklenip LLM'e gönderilir. 6. LLM cevabı bu bağlamdan üretir — tahmin değil, belgeye dayalı.
Yaygın varyantlar: hibrit arama (vektör + anahtar kelime), yeniden sıralama (reranking — cross-encoder ile sonuçların sıralamasını rafine et), graf tabanlı RAG, ajan tabanlı RAG (LLM kendi sorgularını kendi yazar).
Sınav öncesi bütün kitapları ezberlemek yerine, sınav sırasında ilgili sayfaları açık tutmak gibi. RAG modele bir tür "kopya kağıdı" verir — cevap modelin hafızasından değil, gerçek belgelerden çıkar. Açık kitap sınavı düşün.
Bir SaaS ürününün dokümantasyonu sürekli güncelleniyor. Kullanıcı "API rate limit nedir?" diye soruyor. Doğrudan ChatGPT'ye sorulsa eski bir değer söyleyebilir veya tamamen uydurabilir (halüsinasyon).
RAG'li çözüm: 1. 200 sayfalık doküman parçalara bölünmüş, hepsi Pinecone'da hazır. 2. Sorunun embedding'i alınır; en yakın 5 parça döner. Örn: "Rate limit — Free: 100 istek/dk, Pro: 1000 istek/dk…" 3. Bu parçalar Claude'a sistem bağlamı olarak verilir. 4. Claude bağlamı okuyup belge-temelli, spesifik bir cevap üretir.
Sonuç: her zaman güncel, kaynak gösterilebilir, halüsinasyon riski çok düşük cevap. Doküman değişince sadece etkilenen parçaları yeniden embed etmek yeter.
from openai import OpenAI
import numpy as np
client = OpenAI()
# 1. KURULUM — belgeleri bir kez embed et
docs = [
"Free plan: 100 req/dk rate limit.",
"Pro plan: 1000 req/dk + öncelikli destek.",
"Aşılırsa 429 dönülür, 60 sn sonra reset.",
]
def embed(t): return np.array(
client.embeddings.create(model="text-embedding-3-small", input=t).data[0].embedding
)
doc_vecs = [embed(d) for d in docs]
# 2. SORGU — en yakın 2 belgeyi bul
query = "API rate limit nasıl çalışıyor?"
q_vec = embed(query)
sims = [float(np.dot(q_vec, v) / (np.linalg.norm(q_vec) * np.linalg.norm(v))) for v in doc_vecs]
top = sorted(zip(sims, docs), reverse=True)[:2]
context = "\n".join(d for _, d in top)
# 3. ÜRETİM — bağlamı LLM'e ver
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Sadece verilen bağlamdan cevap ver."},
{"role": "user", "content": f"Bağlam:\n{context}\n\nSoru: {query}"},
],
)
print(resp.choices[0].message.content)- Özel/dahili bilgi (şirket dokümantasyonu, müşteri verileri)
- Sürekli güncellenen bilgi (haberler, fiyatlar, stok)
- Halüsinasyon riskinin yüksek olduğu alanlar (yasal, tıbbi, finansal)
- Geniş bilgi tabanı üzerinde sorgu modu (>10K döküman)
- Denetim ya da kaynak gösterimi gerekiyorsa — RAG kaynağa referans verebilir
- Genel bilgi soruları (LLM zaten biliyor)
- Az doküman varsa (<50) — hepsini doğrudan bağlama koy
- Tek seferlik yaratıcı içerik (şiir, blog) — RAG fayda sağlamaz
- Yapısal sorgular (klasik veritabanı sorgusu daha doğrudan)
Arama kalitesi her şeydir
Modeli güçlendirmeye çalışmadan önce arama (retrieval) katmanını düzelt. Yanlış parçalar gelirse en iyi LLM bile saçma cevap üretir. Recall@5 (ilk 5 sonuçta doğru parça oranı) ölçümü şart.
Parçalar bağlamsız
Ham parçalar genelde 'bunun yerine' ya da 'önceki bölümde' gibi referanslar içerir. Doküman başlığını ve başlık hiyerarşisini parça meta verisine ekle.
RAG'i tek başına bırakmak
RAG + yeniden sıralama + hibrit arama + sorgu genişletme = bütün çözüm. Sadece basit vektör araması ile başlarsan canlıda %60 doğrulukta takılırsın.