RAG Nedir, Nasıl Kurulur? Türkçe Veriyle Adım Adım RAG Kurulumu ve Maliyet Hesabı

RAG (Retrieval-Augmented Generation / erişimle güçlendirilmiş üretim), dil modelinin yanıtını kendi belgelerinizden çekilen parçalarla besleyen mimaridir. Kurulum üç katmandır: belgeleri parçalayıp vektöre çeviren embedding katmanı, benzerlik aramasını yapan vektör veritabanı ve yanıtı üreten LLM. İlk ikisini açık kaynak araçlarla kurar, üretim katmanını Onysoft AI Gateway'in OpenAI uyumlu ucuna bağlarsınız.

Türkçe kaynaklarda "RAG nedir" sorusunun cevabı genellikle kavram düzeyinde kalıyor: şema çiziliyor, bileşenler sayılıyor, ama iki kritik soru açıkta bırakılıyor. Birincisi mimari dürüstlük: hangi katman hangi araçla kurulmalı, LLM sağlayıcınızdan ne beklemeli ne beklememelisiniz? İkincisi para: bağlama koyduğunuz her token faturaya yazılır — peki kaç token koymalısınız?

Bu rehber ikisini de açık açık cevaplıyor: katman katman kurulum planı, Türkçe veriye özgü embedding ve chunk incelikleri, canlı katalog fiyatlarıyla hesaplanmış 4K vs 32K bağlam maliyet karşılaştırması, çalışan üretim kodu ve üretim trafiğinden gerçek gecikme ölçümleri.

RAG Nedir? Erişimle Güçlendirilmiş Üretim Nasıl Çalışır?

RAG, dil modelinin yanıt üretmeden önce sizin bilgi kaynaklarınızda arama yapılmasını ve yanıtın bulunan parçalara dayandırılmasını sağlayan mimaridir. Model böylece yalnızca eğitim verisindeki genel bilgiyle değil, sorunun sorulduğu andaki güncel ve size özel bilgiyle konuşur: halüsinasyon azalır, her yanıt kaynak gösterebilir hale gelir.

Sistem üç aşamada çalışır:

• 1. İndeksleme (bir kez, sonra güncellendikçe): PDF, yardım makalesi, sözleşme, ürün dokümanı gibi kaynaklar okunur; anlam bütünlüğünü koruyan parçalara (chunk) bölünür; her parça bir embedding modeliyle sayısal vektöre çevrilip vektör veritabanına yazılır.
• 2. Erişim (her soruda): Kullanıcının sorusu aynı embedding modeliyle vektöre çevrilir, veritabanında en benzer parçalar (top-k) bulunur.
• 3. Üretim (her soruda): Bulunan parçalar + soru, bir talimatla birlikte LLM'e gönderilir; model yanıtı yalnızca bu bağlamdan üretir.

İnce ayardan (fine-tuning) temel farkı güncellenebilirliktir: bilgi değiştiğinde modeli yeniden eğitmezsiniz, yalnızca indeksi güncellersiniz. Şirket içi bilgi asistanı, doküman soru-cevabı ve destek botu gibi "bilgisi sık değişen" senaryolarda bu yüzden varsayılan mimari RAG'dir.

RAG Mimarisi: Üç Katmanı Neden Ayrı Kurmalısınız?

Sağlıklı bir RAG kurulumunda embedding, vektör veritabanı ve üretim katmanı üç ayrı bileşendir — tek sağlayıcıya yapışık bir blok değil. Burada açık olalım: Onysoft AI Gateway bir /v1/embeddings ucu sunmaz. Embedding katmanını açık kaynak yerel bir modelle veya harici bir embedding servisiyle kurarsınız; Onysoft'un üstlendiği katman üretimdir — OpenAI uyumlu chat/completions ucu üzerinden.

Bu ayrım bir eksikliği idare etme taktiği değil, zaten doğru mühendislik pratiğidir; sebebi iki katmanın yaşam döngüsünün taban tabana zıt olmasıdır:

• Embedding modeli sabit kalmalıdır. Vektör veritabanınızdaki her kayıt o modelin ürettiği uzayda yaşar; modeli değiştirmek tüm külliyatı yeniden indekslemek demektir. Bu kararı bilinçli, planlı ve seyrek vermek istersiniz.
• Üretim modeli serbestçe değişebilmelidir. Daha iyi veya daha ucuz bir model çıktığında geçiş, indeksinize dokunmadan tek satırlık bir model alanı değişikliği olmalıdır. Üretim katmanını bir gateway'e bağlamanın değeri tam burasıdır: katalogdaki 739+ model arasında geçiş, yeniden indeksleme maliyeti sıfırken yapılır.

Vektör veritabanı tarafında yaygın seçenekler: halihazırda PostgreSQL kullanıyorsanız pgvector eklentisi çoğu ekip için ilk durak; adanmış çözüm isteyenler için Qdrant, Milvus, Weaviate; prototip ve küçük külliyatlar için sunucusuz çalışan FAISS. Milyon parça altındaki külliyatlarda bu seçim, embedding kalitesi kadar sonucu etkilemez — basit olanla başlayın.

Türkçe Veride RAG İncelikleri: Embedding Seçimi ve Chunk Stratejisi

Türkçe RAG'de kaliteyi belirleyen ilk karar embedding modeli, ikincisi chunk stratejisidir — üretim modeli ancak bu ikisinin bulduğu bağlam kadar iyi yanıt verebilir. Türkçe eklemeli bir dildir: "arabalarımızdakiler" gibi tek bir kelime, İngilizcede beş kelimelik bir öbeğin bilgisini taşır. Kelime eşleşmesine dayalı klasik arama bu yüzden Türkçede zayıf kalır; anlam vektörüyle arama (dense retrieval) büyük avantaj sağlar — ama yalnızca embedding modeli Türkçeyi eğitiminde ciddi oranda görmüşse.

Model seçerken üç somut kritere bakın: çok dilli eğitim verisinde Türkçenin varlığı ve modelin Türkçe içeren bir retrieval kıyaslamasındaki sonucu; vektör boyutu (boyut büyüdükçe depolama ve arama maliyeti büyür); lisans ve barındırma şekli (yerel açık kaynak model veri egemenliği sağlar, harici servis operasyon yükünü alır). En önemlisi: seçimi genel tablolara değil, kendi verinize dayandırın. Külliyatınızdan 50-100 gerçek soru ve "doğru parça" eşlemesinden oluşan bir altın set hazırlayın; aday modelleri bu sette ölçün. Yarım günlük bu yatırım, üretimde haftalarca sürecek "neden alakasız parça geliyor" tartışmasını kapatır.

Chunk tarafında yaygın ve makul başlangıç: 300-800 token aralığında, paragraf veya cümle sınırından bölünmüş, yüzde 10-15 örtüşmeli (overlap) parçalar; her parçaya belge adı ve bölüm başlığını metadata olarak ekleyin. İki Türkçeye özgü tuzağa da dikkat: büyük-küçük harf dönüşümünde İ/ı ayrımı standart lowercase fonksiyonlarında bozulur (İSTANBUL → istanbul yerine i̇stanbul benzeri hatalar) — normalizasyonu Türkçe yereline (locale) duyarlı yapın; OCR'dan gelen metinlerde ğ/g, ş/s bozulmaları embedding kalitesini sessizce düşürür — indekslemeden önce temizleyin.

Bağlama Kaç Token Koymalı? 4K vs 32K Bağlam Maliyet Hesabı

Pratik formül şudur: bağlam bütçesi ≈ top_k × ortalama chunk boyutu — ve bu sayı, RAG'de sorgu başına maliyetin ana belirleyicisidir; çünkü bağlama koyduğunuz her parça, her soruda girdi tokenı olarak faturalandırılır. Örneğin top_k=5 × 800 token ≈ 4.000 tokenlık bir bağlam çoğu doküman soru-cevap senaryosu için sağlam bir başlangıçtır; top_k=40 ile 32.000 tokena çıkmak ise "ne bulduysan koy" yaklaşımıdır.

Farkı canlı satış fiyatlarıyla hesaplayalım. Senaryo: sistem talimatı 300 + soru 100 + bağlam (4.000 veya 32.000) girdi tokenı; 500 çıktı tokenı; günde 1.000 sorgu (ayda 30.000). Üretim katmanı fiyatları:

Model	Girdi ($/1M)	Çıktı ($/1M)	Girdi (TL/1M)	Çıktı (TL/1M)
anthropic/claude-opus-5	$7.50	$37.50	356,66 TL	1.783,31 TL
anthropic/claude-sonnet-5	$3.00	$15.00	142,67 TL	713,33 TL
openai/gpt-5.6-terra	$1.50	$9.00	71,33 TL	428,00 TL
openai/gpt-5.6-luna	$0.15	$0.90	7,13 TL	42,80 TL
google/gemini-3.6-flash	$2.25	$11.25	107,00 TL	534,99 TL
deepseek/deepseek-v4-flash	$0.21	$0.42	9,99 TL	19,97 TL

Aynı senaryonun sorgu ve ay bazında karşılığı:

Kurgu	Girdi tokenı	Sorgu başı (USD)	Sorgu başı (TL)	Aylık, 30.000 sorgu (TL)
Sonnet 5 + 4K bağlam	4.400	$0.0207	0,98 TL	≈ 29.532 TL
Sonnet 5 + 32K bağlam	32.400	$0.1047	4,98 TL	≈ 149.370 TL
Luna + 4K bağlam	4.400	$0.0011	0,05 TL	≈ 1.584 TL
Luna + 32K bağlam	32.400	$0.0053	0,25 TL	≈ 7.576 TL

Ölçüm: 5 Ağustos 2026 — api.onysoft.com canlı katalog. TL karşılıkları 5 Ağustos 2026 TCMB kuru (1 USD = 47,555 TL) ile hesaplanmıştır.

Sonuç çıplak: bağlamı 4K'dan 32K'ya çıkarmak, aynı modelde sorgu maliyetini yaklaşık 5 kat artırıyor — Sonnet 5 ile aylık fark 119.000 TL'yi aşıyor. Üstelik geniş bağlam kaliteyi otomatik yükseltmez; uzun bağlamın ortasında kalan bilginin gözden kaçabildiği bilinen bir model davranışıdır. Doğru sıralama şudur: önce erişim kalitesini (embedding + chunk) iyileştirip dar bağlamla yüksek isabet almak, bağlamı ancak ölçülmüş bir ihtiyaçla genişletmek. Kendi trafik profilinizle hesabı maliyet hesaplayıcıda kurabilirsiniz.

Onysoft'ta Nasıl Çalışıyor: Üretim Katmanı Kod Örneği

Üretim katmanı, OpenAI şemasını birebir izleyen tek uca bağlanır: https://api.onysoft.com/v1. Panelden sk-ony- önekli anahtarınızı alır, resmî openai Python paketini olduğu gibi kullanırsınız — erişim katmanından gelen parçalar bağlama yerleştirilir, model yalnızca bu bağlamdan yanıtlar:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.onysoft.com/v1",
    api_key="sk-ony-ANAHTARINIZ",
)

# Erişim katmanı: soru vektörüyle vektör DB'den en alakalı parçalar
# (embedding: yerel açık kaynak model veya harici servis; arama: pgvector/Qdrant vb.)
parcalar = vektor_db.ara(soru_vektoru, top_k=5)  # 5 x ~800 ≈ 4.000 token bağlam
baglam = "\n\n---\n\n".join(f"[{i+1}] {p.metin}" for i, p in enumerate(parcalar))

response = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",  # katalogdaki herhangi bir model
    max_tokens=600,
    messages=[
        {"role": "system", "content": "Yalnızca verilen bağlamdaki bilgiyle yanıt ver. "
            "Bağlamda yoksa uydurma, \"bu bilgi kaynaklarda yok\" de. "
            "Kullandığın parçanın numarasını köşeli parantezle belirt."},
        {"role": "user", "content": f"Bağlam:\n{baglam}\n\nSoru: {soru}"},
    ],
)
print(response.choices[0].message.content)

Yanıtın ham JSON'unda, o sorgunun gerçek maliyeti cost alanıyla hazır gelir — RAG'de sorgu başı maliyet takibi için ayrı bir ölçüm altyapısı kurmanız gerekmez:

{
  "model": "anthropic/claude-sonnet-5",
  "usage": {
    "prompt_tokens": 4412,
    "completion_tokens": 486,
    "total_tokens": 4898
  },
  "cost": 0.0205
}

Sohbet arayüzü kuruyorsanız aynı uçta streaming (SSE) desteklenir: stream=True ile ilk token geldiği anda ekrana basmaya başlarsınız — RAG'in algılanan hızını en çok artıran tek ayardır. Şema ayrıntıları API dokümantasyonunda; mevcut bir OpenAI entegrasyonundan taşınıyorsanız SDK geçiş rehberi adım adım anlatıyor.

Üretime Alırken: Gecikme Bütçesi, Maliyet Tavanı ve Anahtar Ayrımı

RAG'i üretime alırken üç şeyi baştan planlayın: gecikme bütçesi, maliyet tavanı ve anahtar ayrımı. Gecikmede tablo nettir: vektör araması milisaniye sınıfında biter, toplam süreyi üretim katmanı belirler. Kendi üretim trafiğimizden ölçüm: son 14 günde gateway üzerinden geçen 6.959 başarılı istekte uçtan uca ortalama yanıt süresi 3,8 saniye, en hızlısı 0,3 saniye. Ortalamayı yukarı çeken uzun üretimli amiral istekleridir; hafif modeller ve streaming ile RAG deneyimi saniye altına iner.

Maliyet tarafında en riskli RAG hatası, kontrolsüz döngüdür: hatalı bir retry veya agent döngüsü, 32K bağlamlı istekleri dakikada onlarca kez atmaya başlarsa fatura hızla büyür. Onysoft'ta bu senaryonun tavanı yapısaldır: her istekten önce gateway tahmini maliyeti hesaplar, 1,2 katsayılı tamponla bakiyenizle karşılaştırır; bakiye yetmiyorsa istek sağlayıcıya hiç iletilmeden HTTP 402 ile döner. Ön ödemeli bakiyeyle birleşince harcamanın mutlak tavanı, yüklediğiniz tutardır — mekanizmanın tamamı maliyet kontrolü rehberinde.

Anahtar ayrımı da aynı disiplinin parçası: RAG servisine kendi sk-ony- anahtarını verin ve anahtar bazlı token limiti tanımlayın — indeksleme sırasındaki yoğun deneme trafiği veya sızan bir anahtar, üretim bütçesini süpüremez. cost alanını sorgu kimliğiyle birlikte logladığınızda "soru başına kaç TL yakıyoruz" sorusu tahmin olmaktan çıkar; bağlam bütçesi kararlarını da bu veriyle güncellersiniz. Başlamak için ücretsiz hesap açıp Playground'da kendi bağlam + soru kalıbınızı birkaç modelle yan yana deneyin; genel çerçeve için Yapay Zeka API rehberi iyi bir sonraki durak.

Son güncelleme: 5 Ağustos 2026 · Veriler: api.onysoft.com canlı katalog