RAG nedir, nasıl çalışır? Embedding'den vector search'e

RAG (Retrieval-Augmented Generation), bir dil modelinin cevap üretmeden önce ilgili belgeleri arayıp bulduğu, bu belgeleri prompt'a ekleyip modelin yalnızca eğitim verisine değil taze ve doğrulanabilir kaynaklara dayanarak cevap vermesini sağlayan bir tekniktir. RAG nedir nasıl çalışır sorusunun kısa cevabı budur: embedding ile anlamsal arama, chunking ile belge bölme ve prompt'a bağlam ekleme üçlüsü. Bu yazıda bu üç adımı gerçek kod örnekleriyle, sıfırdan kuracağın minimal bir sistem üzerinden anlatıyorum.

💡 Pro Tip: RAG kurarken önce chunk boyutunu, sonra modeli seç — yanlış sırayla ilerlersen embedding modelini değiştirdiğinde tüm vektör store'u yeniden hesaplaman gerekir.

İçindekiler

• RAG'i tek cümlede anlamak
• Embedding nedir, vektör neyi temsil eder
• text-embedding-3 modelleri ve boyut
• Chunking: belgeyi parçalara ayırmak
• Contextual Retrieval ile bağlam kaybını önlemek
• Vector store ve benzerlik araması
• Hybrid search: dense + sparse
• Retrieval sonucunu prompt'a yerleştirmek
• Minimal uçtan uca örnek
• Sık yapılan 5 hata
• RAG sistemini nasıl değerlendirirsin
• Değerlendirme setini canlı tut
• SSS
• RAG nedir ve nasıl çalışır?
• Embedding ile klasik anahtar kelime araması arasındaki fark nedir?
• Vector search sonuçları neden alakasız gelir?
• Küçük bir projede RAG kurmanın en basit yolu nedir?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

RAG'i tek cümlede anlamak

Pinecone'un tanımıyla RAG "modelin çıktısının doğruluğunu, ilgisini ve kullanışlılığını artırmak için yetkili, dış veri kullanan bir tekniktir". Bunun pratik anlamı şu: bir dil modeline doğrudan soru sormak yerine, önce soruyla ilgili belgeleri bir veri kaynağından çekiyorsun, sonra bu belgeleri modelin promptuna ekliyorsun ve model cevabını bu bağlama dayandırıyor.

RAG dört bileşenden oluşur: ingestion (verinin sisteme alınması), retrieval (sorguya uygun belgelerin bulunması), augmentation (bulunan belgelerin promptla birleştirilmesi) ve generation (modelin nihai cevabı üretmesi). Bu bileşenlerin hepsi olmadan sistem RAG sayılmaz — yalnızca arama yapıp sonuçları listelemek retrieval'dır, RAG değil.

RAG olmadan modeller neden yanılır? Çünkü eğitim verisinde olmayan ya da güncel olmayan bir konuda soru sorulduğunda model, Pinecone'un deyimiyle "kendinden emin ama yanlış ve alakasız çıktı" üretir, buna halüsinasyon denir. RAG, modele "bil bakalım" yerine "şu belgeye bakarak cevapla" demenin yoludur.

Bu dört bileşeni ayrı ayrı düşünmek işine yarar, çünkü her biri farklı bir yerde bozulabilir. Ingestion aşaması bozulursa (belgeyi hiç sisteme almadıysan ya da yanlış formatta aldıysan) retrieval'ın bulacağı hiçbir şey yoktur. Retrieval bozulursa (yanlış chunk'lar bulunursa) augmentation da doğru bilgiyle beslenmez. Augmentation bozulursa (bulunan chunk'lar doğru olsa bile prompt'a yanlış yerleştirilirse) model onları görmezden gelebilir. Generation bozulursa (model context'i yok sayarsa) tüm zincir boşa gider. Bir RAG sistemini debug ederken bu sırayı takip etmek — önce ingestion'ı, sonra retrieval'ı, sonra augmentation'ı, en son generation'ı kontrol etmek — nerede koptuğunu bulmayı hızlandırır; ben genelde bu sırayı izlemeyi tercih ederim çünkü zincirin başındaki bir hata, sonraki her adımı da bozar.

Embedding nedir, vektör neyi temsil eder

Embedding, bir metnin anlamsal içeriğini sayısal bir vektöre (ondalıklı sayı listesine) dönüştürülmüş halidir. OpenAI'nin embeddings kılavuzunun deyişiyle iki vektör arasındaki mesafe, bu iki metnin ne kadar ilişkili olduğunu ölçer. Yani "kedi" ve "kedi yavrusu" kelimelerinin vektörleri birbirine yakın, "kedi" ve "traktör" vektörleri ise uzak düşer — bu da klasik anahtar kelime aramasının kaçırdığı eş anlamlılığı ve bağlamı yakalamanı sağlar.

text-embedding-3 modelleri ve boyut

OpenAI, Ocak 2024'te "text-embedding-3-small" ve "text-embedding-3-large" adlı iki yeni embedding modelini duyurdu. Bu modeller, Aralık 2022'de çıkan önceki nesil "text-embedding-ada-002" modeline göre belirgin bir yükseltme sundu; OpenAI ada-002'yi emekliye ayırmadı, yeni modelleri önermekle birlikte önceki nesli kullanmaya devam etmeyi serbest bıraktı. OpenAI'nin kendi ölçümlerine göre MIRACL çok-dilli arama ortalaması ada-002'de 31.4 iken, text-embedding-3-small'da 44.0'a, text-embedding-3-large'da 54.9'a çıktı; İngilizce ağırlıklı MTEB ortalaması ise 61.0'dan 62.3'e ve 64.6'ya yükseldi.

OpenAI dokümantasyonuna göre varsayılan vektör uzunluğu text-embedding-3-small için 1536, text-embedding-3-large için 3072'dir. API'deki dimensions parametresiyle bu boyutu kısaltabilirsin: text-embedding-3-large'ın vektörü 256 boyuta kadar kısaltılsa bile, 1536 boyutlu ada-002'den daha iyi performans gösteriyor. Bu, depolama maliyetini düşürmek istediğinde işine yarar — daha kısa vektör, daha az disk ve daha hızlı benzerlik hesaplaması demektir.

Aşağıdaki tablo embedding modellerini boyut ve MTEB skoruna göre özetliyor (OpenAI resmi duyurusu ve platform dokümanları):

Chunking: belgeyi parçalara ayırmak

Chunking, büyük bir metni "chunk" adı verilen daha küçük parçalara bölme işlemidir. Neden bölersin? Çünkü embedding modelleri sınırlı bir bağlam penceresine sahiptir ve tüm bir belgeyi tek vektöre sıkıştırmak, o belgenin hangi bölümünün soruyla ilgili olduğunu kaybettirir.

Chunk boyutu bir ödünleşimdir: Pinecone'un chunking kılavuzuna göre "chunk'lar çok küçük ya da çok büyükse, bu durum hatalı arama sonuçlarına veya kaçırılmış fırsatlara yol açabilir". Çok küçük chunk'lar bağlamdan kopar, çok büyük chunk'lar ise alakasız bilgiyi de sürükleyerek arama hassasiyetini düşürür.

Kelime bazlı, örtüşmeli (overlap) basit bir chunking fonksiyonu şöyle görünür:

1def chunk_text(text, chunk_size=500, overlap=50):
2    words = text.split()
3    chunks = []
4    start = 0
5    while start < len(words):
6        end = start + chunk_size
7        chunks.append(" ".join(words[start:end]))
8        start = end - overlap
9    return chunks

Buradaki overlap (örtüşme) parametresi, ardışık chunk'lar arasında ortak kelime bırakarak bir cümlenin ortadan bölünüp anlamını yitirmesini azaltır — chunk boyutu ve overlap değerlerini kendi belge tipine göre küçük bir test setinde denemen gerekir.

Contextual Retrieval ile bağlam kaybını önlemek

Anthropic'in 19 Eylül 2024 tarihli mühendislik yazısı, klasik chunking'in yaygın bir sorununu somutlaştırıyor: bir chunk tek başına "Şirketin geliri bir önceki çeyreğe göre %3 büyüdü" gibi bir cümle içerdiğinde, hangi şirketten ve hangi çeyrekten bahsedildiği belirsizleşir. Buna çözüm olarak "Contextual Embeddings" yöntemini öneriyorlar: her chunk'tan önce, o chunk'a özel açıklayıcı bir bağlam ekleniyor; bu bağlam genellikle "50-100 token" uzunluğunda.

Anthropic'in ölçümlerine göre yalnızca Contextual Embeddings kullanmak, ilk 20 chunk'ta arama başarısızlık oranını %35 azaltıyor (yüzde 5,7'den yüzde 3,7'ye). Contextual Embeddings'i BM25 ile birleştirdiğinde bu azalma %49'a (5,7'den 2,9'a), yeniden sıralama (reranking) eklediğinde ise %67'ye çıkıyor. Prompt caching sayesinde bu bağlamı üretmenin tek seferlik maliyeti, milyon doküman token'ı başına 1,02 dolar.

Vector store ve benzerlik araması

Chunk'ları embedding'e çevirdikten sonra bunları bir vector database'de saklarsın. Sorgu geldiğinde, sorgunun embedding'i ile veritabanındaki her chunk'ın embedding'i arasında cosine similarity hesaplanır ve en yüksek skoru alan belgeler döndürülür. RAG akışında bu adım, Pinecone'un tarifiyle "vektör veritabanından semantik arama kullanarak kullanıcının sorgusunun gerçek anlamını bulan" veri çekme adımıdır.

Hybrid search: dense + sparse

Yalnızca embedding tabanlı (dense) arama her zaman yeterli değildir. Pinecone'un önerisi, "yoğun vektörlerle semantik arama ile seyrek vektörlerle sözcüksel aramayı birleştiren hibrit arama kullanarak" arama sonuçlarını iyileştirmektir. Sözcüksel tarafta en yaygın kullanılan algoritma BM25'tir (Best Matching 25) — Anthropic'in tanımıyla "sözcük veya öbeklerin tam eşleşmelerini bulmak için sözcüksel eşleştirme kullanan bir sıralama fonksiyonu".

Son adım olarak sonuçlar genellikle bir reranking modeliyle Pinecone'un deyimiyle "birleşik bir alaka skoruna göre yeniden sıralanır" — bu, ilk aşamada hızlı ama kaba bir aramayla toplanan adayları, daha pahalı ama daha isabetli bir modelle elemek anlamına gelir.

Küçük bir projede (birkaç yüz-bin chunk'a kadar) vector database'i doğrudan yönetilen bir servis olarak kullanmak, kendi ANN (approximate nearest neighbor) indeksini kurmaktan çok daha az bakım gerektirir. Ben yeni bir projeye başlarken önce yönetilen bir vector store ile hızlıca çalışan bir prototip kurmayı, ölçek büyüdükçe (indeksleme maliyeti, sorgu gecikmesi gözle görülür şekilde artınca) kendi altyapını değerlendirmeyi tercih ederim — bu sıralama, erken optimizasyona zaman harcamak yerine önce "çalışıyor mu" sorusuna cevap vermeni sağlar.

Retrieval sonucunu prompt'a yerleştirmek

Bulunan chunk'ları modele nasıl vereceğin, cevabın kalitesini doğrudan belirler. Pinecone'un önerdiği augmented prompt şablonu şu şekilde:

1QUESTION:
2<kullanıcının sorusu>
3CONTEXT:
4<bulunan chunk'lar>
5Using the CONTEXT provided, answer the QUESTION. Keep your answer grounded in the facts of the CONTEXT. If the CONTEXT doesn't contain the answer to the QUESTION, say you don't know.

Buradaki kritik nokta son iki cümle: modele hem cevabını CONTEXT'teki gerçeklere dayandırmasını hem de CONTEXT cevabı içermiyorsa bilmediğini söylemesini açıkça istiyorsun. Bu talimat olmadan model, bulduğun chunk'ları görmezden gelip yine kendi eğitim verisinden halüsinasyon üretebilir.

Anthropic'in tarif ettiği geleneksel hibrit akış altı adımdan oluşur: metni chunk'lara bölmek, TF-IDF kodlamaları ve semantik embedding'ler oluşturmak, BM25 ile sözcüksel eşleşmeleri bulmak, embedding'lerle semantik benzer chunk'ları bulmak, bu sonuçları birleştirip tekrarları elemek ve son olarak en üst K chunk'ı promptuna eklemek. Bu altı adım, yukarıda anlattığımız chunking → embed → retrieve → augment akışının üretim ortamındaki daha ayrıntılı halidir.

Minimal uçtan uca örnek

Aşağıda OpenAI'nin embeddings kılavuzundaki yaklaşıma dayanan minimal bir örnek var: metni embed'liyor, kullanıcı sorgusuyla cosine similarity hesaplıyor ve en yakın chunk'ı buluyoruz.

1from openai import OpenAI
2 
3client = OpenAI()
4 
5def get_embedding(text, model="text-embedding-3-small"):
6    text = text.replace("\n", " ")
7    response = client.embeddings.create(input=[text], model=model)
8    return response.data[0].embedding

Bu fonksiyon, OpenAI'nin embeddings API'sini sarmalıyor; model parametresi olarak text-embedding-3-small ya da text-embedding-3-large verebilirsin.

1import numpy as np
2 
3def cosine_similarity(a, b):
4    a, b = np.array(a), np.array(b)
5    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
6 
7chunks = [
8    "RAG, modelin cevabını dış kaynaklara dayandırır.",
9    "Chunking, büyük metni küçük parçalara böler.",
10    "Cosine similarity iki vektör arasındaki açıyı ölçer.",
11]
12chunk_embeddings = [get_embedding(c) for c in chunks]
13 
14query = "RAG nedir?"
15query_embedding = get_embedding(query)
16 
17scores = [cosine_similarity(query_embedding, ce) for ce in chunk_embeddings]
18best_index = int(np.argmax(scores))
19print(chunks[best_index])

Bu iskelet üç satırlık bir vector store'dur — production'da bunun yerine Pinecone, Qdrant ya da pgvector gibi bir vector database kullanırsın çünkü binlerce chunk için Python listesinde döngü kurmak yavaştır, ama mantık birebir aynı kalır: embed et, benzerlik hesapla, en yüksek skoru döndür.

Yukarıdaki chunk_text fonksiyonuyla bu iskeleti birleştirmek, uçtan uca akışı tamamlar: önce belgeyi chunk'lara böl, her chunk'ı embed et, sorgu geldiğinde aynı modelle sorguyu da embed et ve en yakın chunk'ı bul.

1document = "... (uzun belge metni) ..."
2doc_chunks = chunk_text(document, chunk_size=200, overlap=20)
3doc_embeddings = [get_embedding(c) for c in doc_chunks]
4 
5def retrieve(query, top_k=3):
6    q_emb = get_embedding(query)
7    scored = [(cosine_similarity(q_emb, e), c) for e, c in zip(doc_embeddings, doc_chunks)]
8    scored.sort(key=lambda x: x[0], reverse=True)
9    return [chunk for _, chunk in scored[:top_k]]

retrieve fonksiyonu en yüksek skorlu ilk top_k chunk'ı döndürüyor; bu chunk'ları, yukarıdaki "QUESTION / CONTEXT" şablonuna yerleştirip modele göndermen, minimal bir RAG döngüsünü tamamlar. Tek embedding çağrısı yerine embeddings.create fonksiyonuna bir liste vererek chunk'ları toplu (batch) göndermek, çok sayıda chunk'ın olduğu belgelerde istek sayısını azaltmanın pratik bir yoludur; ben ingestion aşamasında chunk'ları tek tek değil, gruplar halinde embed etmeyi tercih ederim.

Sık yapılan 5 hata

• Yanlış chunk boyutu seçmek: çok küçük chunk bağlamı parçalar, çok büyük chunk alakasız içerik taşır ve arama hassasiyetini düşürür.
• Chunk'ı bağlamsız bırakmak: chunk içinde "şirket" ya da "bu çeyrek" gibi referanslar hangi varlığa işaret ettiği belirsizse, retrieval yanlış chunk'ı bulmasa bile model yanlış yorumlar.
• Yalnızca dense aramaya güvenmek: embedding arama parafrazı yakalar ama tam eşleşen terimi (ürün kodu, hata mesajı) kaçırabilir; hibrit aramayı atlamak bu tür sorguları kaybettirir.
• RAG'siz halüsinasyon riskini hafife almak: dış kaynak eklemeden soru sormak, modelin "kendinden emin ama yanlış" cevap üretme riskini yükseltir.
• Prompt'a grounding talimatı koymamak: modele "cevabını yalnızca CONTEXT'e dayandır" demeden context eklemek, modelin yine de kendi bilgisine dönmesine izin verir.

Bu beş hatanın ortak noktası şu: hepsi de sistem "çalışıyor gibi görünürken" sessizce yanlış cevap üretmene yol açar. Bir RAG sistemi hiç cevap vermediğinde hatayı bulmak kolaydır; ama yanlış ya da eksik bağlamla "makul" bir cevap ürettiğinde, o hatayı fark etmek için gerçek kullanıcı sorularıyla düzenli olarak manuel test yapman gerekir — otomatik testler chunk'ların doğru bulunduğunu doğrulayabilir ama cevabın doğru CONTEXT'e mi yoksa modelin kendi bilgisine mi dayandığını her zaman ayırt edemez.

RAG sistemini nasıl değerlendirirsin

Bir RAG sistemini kurmak kolay, çalıştığını kanıtlamak zordur. Pinecone bu soruyu doğrudan soruyor: RAG'e gerçekten ihtiyacın var mı ve çalıştığını nereden bileceksin? Cevap "ground truth" değerlendirmesinde: herhangi bir uygulamayı düzgün biçimde yayına almak için ne zaman çalıştığını bilmen gerekir, AI uygulamaları da farklı değil — bu yüzden "bir dizi sorgu ve bu sorguların beklenen cevaplarını belirlemek, uygulamanın çalışıp çalışmadığını bilmek açısından kritiktir".

Pratikte bu, kod yazmaya başlamadan önce gerçek kullanıcı sorularını ve her birinin beklenen cevabını (ya da cevabın hangi belgede geçtiğini) bir dosyaya yazmak demektir. Bu küçük set, sonraki her kararın — chunk boyutu, overlap, embedding modeli, top_k değeri — ölçülebilir hale gelmesini sağlar. Set olmadan yaptığın her ayar bir tahmindir.

Değerlendirme setini canlı tut

Pinecone'un vurguladığı ikinci nokta bu setin bakımı: değerlendirme setini sürdürmek, zaman içinde nerede iyileştirme yapılacağını ve yapılan iyileştirmelerin işe yarayıp yaramadığını bilmek için de kritik. Yani set tek seferlik bir dosya değil; kullanıcılardan gelen her yeni soru tipi buraya eklenir.

Ölçümü iki katmana ayırmak işini kolaylaştırır. Retrieval katmanında sorduğun soru şu: beklenen cevabı içeren chunk, dönen ilk K sonucun içinde mi? Generation katmanında ise soru şu: model bu chunk'ı gerçekten kullandı mı, yoksa kendi bilgisine mi döndü? Birinci katman otomatik ölçülebilir, ikincisi okuyup kontrol etmeni gerektirir. Ben genelde önce retrieval katmanını sabitlemeyi, ancak ondan sonra prompt üzerinde oynamayı tercih ederim — çünkü yanlış chunk geldiğinde en iyi prompt bile doğru cevabı üretemez.

Bir not daha: Pinecone'un hatırlattığı gibi RAG yalnızca bir optimizasyon; sorgu yeniden yazımı (query rewriting), chunk genişletme ve bilgi grafikleri gibi başkaları da var. Elinde iyi bir temel ölçüm varsa, hangisinin senin verinde işe yaradığını görebilirsin; yoksa hepsi eşit derecede makul görünür.

SSS

RAG nedir ve nasıl çalışır?

RAG, bir dil modelinin cevap üretmeden önce ilgili belgeleri harici bir kaynaktan bulup bunları prompt'a eklediği bir tekniktir. Dört adımda çalışır: verinin sisteme alınması (ingestion), sorguya uygun belgelerin bulunması (retrieval), bu belgelerin promptla birleştirilmesi (augmentation) ve modelin cevap üretmesi (generation).

Embedding ile klasik anahtar kelime araması arasındaki fark nedir?

Klasik anahtar kelime araması yalnızca tam eşleşen kelimeleri bulur. Embedding tabanlı arama ise metnin anlamsal içeriğini vektöre çevirir ve anlamca yakın metinleri bulur, çünkü iki vektör arasındaki mesafe ilişkililiği ölçer. Bu yüzden "araba" araması yapıldığında "otomobil" geçen bir belge de bulunabilir.

Vector search sonuçları neden alakasız gelir?

En yaygın nedenlerden biri yalnızca dense (embedding tabanlı) arama kullanmaktır — bu yöntem parafrazı yakalar ama tam eşleşmesi gereken kelimeleri veya tanımlayıcıları kaçırabilir; hibrit arama (dense + sparse) bu boşluğu kapatır. Bir diğer neden ise yanlış chunk boyutudur: çok büyük ya da çok küçük chunk'lar arama hassasiyetini düşürür.

Küçük bir projede RAG kurmanın en basit yolu nedir?

Belgelerini chunk'lara böl, her chunk'ı bir embedding modeliyle (örneğin text-embedding-3-small) vektöre çevir, bunları basit bir listede veya küçük bir vector database'de sakla, sorgu geldiğinde cosine similarity ile en yakın chunk'ları bul ve bunları grounding talimatı içeren bir prompt şablonuyla modele ver.

Güncelleme (Eylül 2026)

Bu makale ilk olarak 12 Kasım 2024 tarihindeki API ve modellerle yazıldı. O tarihten bu yana RAG'in temel mekaniği (chunk → embed → retrieve → prompt) değişmedi, ama üç eksende olgunlaştı.

Standardizasyon tarafında, Anthropic 25 Kasım 2024'te Model Context Protocol'ü (MCP) duyurdu — LLM'lerin veri kaynaklarına bağlanmasını standart hale getiren açık bir protokol; bu, retrieval'ı özel entegrasyonlardan çok adımlı, tool-calling ile iç içe geçen bir yapıya taşıyan en büyük altyapı değişikliği oldu. OpenAI da 11 Mart 2025'te Responses API ile birlikte yerleşik bir file_search aracı sundu; retrieval yeteneği artık ayrı bir vector store kurmadan "hosted" bir araç olarak kullanılabiliyor.

Doğrulanabilirlik tarafında Anthropic, 23 Ocak 2025'te API'de kullanıma açılan (Bedrock'ta 30 Haziran 2025'te genişleyen) Citations API'yi tanıttı; bu API kaynak belgelerdeki tam pasajlara otomatik atıf ekliyor. Pratik anlamı şu: yukarıda anlattığımız "QUESTION / CONTEXT" prompt şablonunu elle yazıp modelden grounding talimatına uymasını ummak yerine, hangi cevabın hangi pasajdan geldiğini API seviyesinde takip edebiliyorsun — bu da "Sık yapılan 5 hata" bölümünde bahsettiğimiz, cevabın gerçekten CONTEXT'e mi dayandığını doğrulama sorununu kısmen otomatikleştiriyor.

Retrieval kalitesi tarafında yeni nesil embedding modelleri çıktı: Cohere, 15 Nisan 2025'te metin ve görseli tek embedding uzayında birleştiren Embed 4'ü; Google ise Mart 2025'te deneysel, 14 Temmuz 2025'te genel kullanıma açılan gemini-embedding-001 modelini yayınladı — bu model Mart'taki deneysel çıkışından beri MTEB çok-dilli lider tablosunda üst sıralarda yer alıyor. Hibrit (dense+sparse) arama ise bu dönemde yaygın bir varsayılan haline geldi: dense retrieval parafrazı yakalar ama tam eşleşen kelime veya tanımlayıcıyı kaçırabilir, sparse arama bu boşluğu kapatıyor.

Sonuç

RAG'in temeli üç adımdan ibaret: metni chunk'lara böl, her chunk'ı embedding modeliyle vektöre çevir, sorgu geldiğinde benzerlik araması yap ve bulduğun chunk'ları grounding talimatıyla birlikte modele ver. Bu mekanik zamanla değişmedi; değişen, bu adımların etrafındaki araçlar — yukarıdaki Güncelleme bölümünde anlattığım MCP gibi standart protokoller ve hibrit arama desteği sunan vektör veritabanları.

Küçük bir projede RAG kurmaya başlıyorsan, önce chunk boyutunu ve embedding modelini küçük bir test setiyle doğrula, sonra agentic, çok adımlı retrieval akışlarına geç. Prompt şablonunda grounding talimatını atlamamak, muhtemelen tek başına en çok halüsinasyonu önleyecek adım — bu konuyu prompt şablonlarına dair arşiv yazımızda daha ayrıntılı işledik. Retrieval sonuçlarını production'a almadan önce gerçekten doğrulama alışkanlığını erken kur; retrieval'ın agent framework'lere nasıl bağlandığını merak ediyorsan bu yazıya bakabilirsin.

Kaynaklar

• Retrieval-Augmented Generation (RAG) — Pinecone — RAG tanımı, dört bileşeni ve augmented prompt şablonu.
• Chunking Strategies — Pinecone — chunk boyutu ödünleşimi ve chunking tanımı.
• Embeddings — OpenAI Platform Docs — embedding tanımı, boyut ve cosine similarity kullanımı.
• New embedding models and API updates — OpenAI — text-embedding-3 duyurusu ve MTEB/MIRACL skorları.
• Introducing Contextual Retrieval — Anthropic — Contextual Embeddings, BM25 birleşimi ve performans kazanımları.
• Model Context Protocol — Anthropic — MCP duyurusu, 25 Kasım 2024.
• API release notes — Anthropic — Citations yeteneğinin API'de yayınlandığı tarih (23 Ocak 2025).
• Gemini Embedding available in the Gemini API — Google Developers Blog — gemini-embedding-001 GA duyurusu, 14 Temmuz 2025.
• Changelog — OpenAI Developers — Responses API ve yerleşik file search aracının yayın tarihi (11 Mart 2025).
• Introducing Embed 4 — Cohere — çok-modlu Embed 4 duyurusu, 15 Nisan 2025.
• Introducing Citations on the Anthropic API — Anthropic — Citations API duyurusu ve 30 Haziran 2025 Amazon Bedrock güncellemesi.