RAG Nedir? RAG Mimarisi ve Yerel Chatbot Kurulumu 2026

Şirketin 200 sayfalık iç politika PDF’lerini ChatGPT’ye yüklemek istiyorsun, ama hem KVKK riski hem de “verim Amerikan sunucusunda nerede gezecek?” sorusu kapıda. Diğer taraftan Azure OpenAI sözleşmesi de aylık binlerce dolar. Yapay zekayı işinde kullanmak istiyorsun ama veri elinden çıkmasın, fatura da gelmesin.

Bu yazıda, Ollama + LangChain + Chroma üçlüsüyle tek bir satır kapalı veri internete çıkmadan, çalıştırılabilir Python kodu üzerinden uçtan uca yerel bir RAG chatbot kuracaksın. 16 GB RAM’li bir dizüstü bilgisayar yeterli; GPU şart değil.

Yerel RAG hattının kuş bakışı: PDF, ChatGPT’ye değil, kendi bilgisayarındaki vektör DB’sine düşüyor.

RAG Nedir? Tanım ve Açık Kitap Benzetmesi

RAG (Retrieval-Augmented Generation, Türkçesiyle “bilgi getirme destekli üretim”), bir LLM’in cevap üretmeden önce harici bir bilgi kaynağından ilgili parçaları çekip prompt’a eklediği mimaridir. Yani modele yeni şeyler “öğretmiyorsun”; modelin önüne soruyla ilgili kaynak metni koyup “buradan oku, bu çerçevede cevapla” diyorsun.

En açıklayıcı benzetme sınav salonundan: klasik bir LLM, sınava yalnızca ezberiyle giren öğrencidir. Ezberinde olmayan bir soru geldiğinde ya boş bırakır ya da “en makul” sandığı cevabı uydurur. RAG ise açık kitap sınavıdır: öğrenci soruyu görür, kitapta doğru bölümü bulur, o bölüme bakarak cevabı yazar; bulamazsa “kitapta yok” der, uydurmaz.

Kritik bir ayrım: RAG bir model mimarisi değil, bir çalışma zamanı deseni (runtime pattern). Modelin kendisini değiştirmez; modelin nasıl kullanıldığını değiştirir. RAG mimarisi üç bağımsız bileşenden oluşur:

1. Retriever (bulucu): Soruya en alakalı belge parçalarını bulan katman.
2. Bilgi tabanı (knowledge base): Doğrulanmış, güncel belgelerin vektör hâlinde saklandığı depo.
3. Generator (üretici): Bulunan parçalara dayanarak cevabı yazan LLM.

Bu bileşenler birbirinden bağımsız geliştirilip değiştirilebilir; bilgi tabanını güncellemek için modeli yeniden eğitmek gerekmez. RAG’in bütün operasyonel gücü bu ayrıştırmadan gelir.

Peki neden gerekli? Tek başına bir LLM iki büyük sorunu çözemez:

• Bilgi sınırı (knowledge cutoff). Modelin eğitimi belirli bir tarihte donmuştur; bu tarihten sonrasını bilmez. Geçen ay yayınladığın iç politika belgesini bilemez. Şirket-içi belge, ürün katalogu, mevzuat değişikliği, bunların hiçbirini modelin eğitim verisinde aramak mantıklı değil.
• Halüsinasyon. Bilmediğini bilmez. “Madde 6/3’te ne yazıyor?” diye sorduğunda, kaynağı yoksa bile ikna edici bir cevap uydurabilir. Bu, kurumsal bir asistanın ölüm fermanıdır.

“O zaman 200 sayfalık PDF’i prompt’a yapıştırırım, olur biter” diyebilirsin. Üç sebepten ölçeklenmez:

• 200 sayfalık bir belge yaklaşık 150.000 token tutar. Llama 3.1 8B’nin context window’u 128k, çoğu yerel modelde 32k. Yapıştırma fiziksel olarak imkânsız.
• API kullanıyorsan her sorguda tüm belgeyi göndermek = token maliyeti × milyon istek.
• Belge güncellendiğinde, yeni bir yönerge, yeni bir fiyat, her şeyi tekrar prompt’a koymak operasyonel cehennem.

RAG bu üçünü tek hamlede çözer: belgeyi bir kez parçalara böler, parçaları sayısal vektörlere çevirir, vektör veritabanına yazar. Soru geldiğinde sadece soruyla anlamca yakın 3-5 parçayı çeker, onları prompt’a ekler. Yani “her bilen modele” değil, “doğru parçayı bulan retriever’a” yatırım yaparsın.

Beş adımlık RAG hattını kafanda şöyle resmet: Chunk → Embed → Store → Retrieve → Augment + Generate.

PDF → 1000-token chunks → 1024-d bge-m3 vektörü → Chroma → top-4 retrieval → llama3.1 cevap.

RAG vs Fine-tuning vs Sade Prompt: Hangisi Ne Zaman?

Yerel AI üzerine bir karar veriyorsan, sıkça karıştırılan üç yaklaşım var. Her birinin yeri farklı.

• Sade prompt. Tek seferlik bir işin var, bağlam küçük, hızlı bir PoC istiyorsun. Bu durumda yapay zekayı kişiselleştirmek için tek ihtiyacın iyi bir prompt. (Konuya hâkim değilsen önce Prompt Mühendisliği rehberi sana lazım.)
• RAG. Sık güncellenen, büyük, kapalı bir veri var: şirket dokümanı, ürün katalogu, mevzuat, müşteri destek arşivi. Cevap kaynak göstermeli. Asıl yer burası.
• Fine-tuning. Modele bir tarz, format ya da alan dili öğretmek istiyorsun. “Hep şu tonla cevap ver”, “her yanıtı şu JSON şemasında ver”, “hukuk dilini kullan” gibi. Bilgi güncellemek için fine-tuning değil, RAG. Bu cümleyi göğsüne yapıştır.

Karşılaştırmayı bir tabloya çekelim:

Veri sık güncelleniyorsa RAG; tarz/format öğretmek için fine-tuning; tek seferlik ufak iş için sade prompt.

Pratikte karar şöyle düşer: Veri sık değişiyor mu? Evet → RAG. Değişmiyor ama tarzı veya formatı öğretmek mi istiyorsun? Evet → fine-tuning. İkisi de değil, tek seferlik bir iş mi? Sade prompt. RAG ve fine-tuning birbirinin yerine değil, kombinasyonu, büyük projelerde fine-tune’lanmış bir model üzerine RAG koymak normaldir.

En kritik fark: Fine-tuning modele davranış kazandırır, RAG modele bilgi sağlar. Birini diğeriyle değiştirmeye çalışırsan ya cebin ya da güvenilirliğin yanar.

Yerel RAG Stack: Ollama + LangChain + Chroma Neden Bu Üçlü?

Yerel kurulum dediğimizde aslında üç farklı katman lazım: modeli koşturan motor, vektörü saklayan depo, ve hattı birbirine bağlayan tutkal.

Ollama, hem üretim (generation) hem embedding modellerini lokalde çalıştırır. llama3.1:8b cevap üreten LLM olarak, bge-m3 ise metni 1024 boyutlu vektöre çeviren embedding modeli olarak iki ayrı ollama pull ile gelir. İki model de internet olmadan çalışır; tek bir HTTP API ile (localhost:11434) çağrılır. Ollama’nın sıfırdan kurulumu için yerel yapay zeka Ollama kurulum rehberini referans al.

Chroma, embedding vektörlerini saklayan açık kaynak vektör DB’dir. SQLite tabanlı, tek pip install ile çalışır, kurulumu bir dakika tutar. 100.000 chunk’a kadar tek dosya olarak diskine persist eder; bunun üstüne çıkacaksan pgvector veya Qdrant’a geçersin (Bölüm 7).

LangChain, üstteki iki parçayı tek bir pipeline’da birleştirir: PDF okuyucu, chunker, retriever, prompt şablonu, LLM çağrısı, hepsini ayrı ayrı yazmak yerine modüler bileşenler olarak dizmeni sağlar. 2026 itibarıyla langchain-ollama ve langchain-community paketleri bu üçlünün native entegrasyonunu kapatır.

Bu üçlü neden? Üç madde:

• Tamamı açık kaynak. Lisans sürtüşmesi yok, vendor lock-in yok.
• Hiçbiri internet zorunlu kılmaz. İlk model indirme dışında dışarıya tek byte gitmez. KVKK için altın.
• Donanım minimum makul. 16 GB RAM, ~10 GB disk (modeller dahil). GPU şart değil ama CPU’da 8B model token başı ~3-5 saniye; GPU’da bu 200-500 ms’ye düşer.

İstersen Chroma’yı Qdrant’la, Llama’yı Mistral’la, LangChain’i LlamaIndex’le değiştir, mimari aynı kalır. Bu yazı en hızlı çalışan kombinasyonu seçiyor.

Ekosistemin geri kalanına da kısaca değinelim: framework tarafında LangChain’in yanında LlamaIndex (belge yükleme ve veri bağlantısında güçlü), Haystack (kurumsal arama odaklı) ve Microsoft’un Semantic Kernel’i var. Yerel kurulum istemeyen ekipler için Azure AI Search, Amazon Bedrock Knowledge Bases ve Google Vertex AI yönetilen RAG hizmeti sunuyor; bunlar kurulum derdini kaldırır ama veri 3. taraf buluta çıkar, bu yazının derdi tam tersi. Bugün hukuk firmalarının sözleşme analizinde, bankaların uyumluluk kontrollerinde, hastanelerin klinik destek sistemlerinde ve müşteri hizmetleri botlarında dönen mimari, birazdan kuracağının ölçeklenmiş hâli.

Adım Adım Kurulum: Ortam, Modeller, Bağımlılıklar

Önce Python sanal ortamı ve gerekli paketler:

# Sanal ortam oluştur ve aktive et
python -m venv rag-env
source rag-env/bin/activate              # Windows: rag-env\Scripts\activate

# RAG hattının bağımlılıkları
pip install langchain langchain-community langchain-ollama chromadb pypdf

Ardından Ollama modellerini indir. Bunlar tek seferlik; bir kez çekildiğinde diskinde kalıyor:

# Generation modeli (~4.7 GB)
ollama pull llama3.1:8b

# Embedding modeli, Türkçe dahil çoklu dil destekli, 1024 boyut (~1.2 GB)
ollama pull bge-m3

Klasör yapısını şöyle kur:

rag-chatbot/
├── docs/                 # Türkçe PDF'ler buraya
├── chroma_db/            # Vektör DB persist klasörü (otomatik oluşur)
├── ingest.py             # PDF → embedding → Chroma
├── chat.py               # Soru → retrieval → LLM
└── requirements.txt

Son olarak Ollama’nın gerçekten çalıştığından emin ol:

ollama run llama3.1:8b "Merhaba, Türkçe biliyor musun?"

Bir Türkçe selamlama görüyorsan motor ayakta. Şimdi asıl iş başlıyor.

RAG Hattını Kuralım: Türkçe PDF Üzerinde Tam Kod

Bu yazının kalbi. Aşağıdaki kod, docs/ klasörüne attığın herhangi bir Türkçe PDF üzerinde, örnek olarak KVKK metnini ya da şirketinin iç politika belgesini kullan, uçtan uca çalışan bir chatbot kurar. Toplam 150-200 satır Python.

1. Belgeyi Yükle ve Parçala

PDF’i tek parça hâlinde embed edemezsin. Önce 1000 token civarı parçalara (chunk) ayıracaksın. Neden 1000? Çünkü embedding modelleri (bge-m3 dahil) en iyi performansı paragraf büyüklüğünde verir. Çok büyük chunk → ilgisiz cümleler aynı vektöre sıkışır, retrieval kalitesi düşer. Çok küçük chunk → cümleler bölünür, bağlam kaybolur. 200 token’lık overlap, paragraf sınırında kesilen düşünceleri yakalar.

# ingest.py — Part 1: belgeyi yükle ve parçala
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter

# 1. PDF'i yükle (her sayfa = 1 Document)
loader = PyPDFLoader("docs/kvkk-metni.pdf")
pages = loader.load()
print(f"PDF yüklendi: {len(pages)} sayfa")

# 2. Cümle bütünlüğüne saygılı recursive chunker
splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,          # ~750 kelime / 1-2 paragraf
    chunk_overlap=200,        # paragraf sınırını yakala
    separators=["\n\n", "\n", ". ", " ", ""],  # önce paragraf, sonra cümle, sonra kelime
)
chunks = splitter.split_documents(pages)
print(f"Toplam chunk: {len(chunks)}")

RecursiveCharacterTextSplitter, önce paragraf, sonra cümle, son çare olarak kelime sınırından bölmeyi dener. Bu, “Madde 6/3” gibi anlam taşıyan parçaların ortadan yarılmasını ciddi ölçüde azaltır.

2. Embedding ve Chroma’ya Kaydetme

Her chunk’ı bge-m3 ile 1024 boyutlu bir vektöre çevirip Chroma’ya yazıyoruz. İlk çalıştırmada ~30 saniye (PDF boyutuna göre); sonra disk’e persist olduğu için tekrar embed gerekmez.

# ingest.py — Part 2: embed ve store
from langchain_ollama import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

# Ollama'nın embedding modeli — internete çıkmaz
embeddings = OllamaEmbeddings(model="bge-m3")

# Chroma DB'yi oluştur ve persist et
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db",
    collection_name="kurumsal-belgeler",
)
print(f"Vektör DB oluşturuldu: {vectorstore._collection.count()} chunk")

Bu dosyayı bir kez çalıştır (python ingest.py). Sonraki sefer aynı belgeyi tekrar yüklemen gerekmiyor; chat.py tarafı diskten okuyacak.

3. Retrieval, Anlamsal Arama

Şimdi kullanıcı soru sorduğunda DB’den en alakalı parçaları çekmemiz lazım. Arka planda cosine similarity ile sorgunun vektörüne en yakın 4 chunk dönüyor, bu, anlamsal aramanın çalışan hali.

Embedding’in sezgisi şu: metin, anlamı koruyan bir koordinat uzayında bir noktaya dönüşür. “Vergi kanunu” ile “mali mevzuat” birbirine yakın vektörler üretir; “vergi kanunu” ile “pizza tarifi” çok uzak. Basit kelime aramasının yapamadığı da tam bu: “mükellef” kelimesini aramak “vergi ödeyen” ifadesini içeren belgeyi bulamaz, anlamsal arama bulur.

# chat.py — Part 1: retrieval kurulumu
from langchain_community.vectorstores import Chroma
from langchain_ollama import OllamaEmbeddings

embeddings = OllamaEmbeddings(model="bge-m3")

# Aynı DB'yi disk'ten yükle — yeniden embed yok
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings,
    collection_name="kurumsal-belgeler",
)

# top-4 en yakın chunk'ı getiren retriever
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

k=4 neden? Tek chunk yetersiz olabilir; aynı sorunun cevabı iki ayrı sayfada olabilir. Çok fazla chunk (k=10+) bu sefer prompt’u şişirir, modelin dikkati dağılır. Başlangıç için 4 sağlıklı.

4. Prompt Template + LLM

Modelin halüsinasyon yapmasını engelleyen yegâne yer burası. Sistem prompt’unda “Sadece sağlanan bağlamı kullan; bağlamda yoksa ‘belgede bulunamadı’ de” kuralını açıkça veriyoruz. Aksi takdirde model boşluğu eğitim verisiyle doldurmaya çalışır.

# chat.py — Part 2: prompt + LLM
from langchain_core.prompts import ChatPromptTemplate
from langchain_ollama import ChatOllama

prompt = ChatPromptTemplate.from_template("""
Sen kurumsal bir asistansın. SADECE aşağıdaki bağlamı kullanarak cevap ver.
Bağlamda cevap yoksa "Bu konuda belgede bilgi bulunamadı." de — uydurma.
Cevabını Türkçe, kısa ve net ver; gerekiyorsa belgeden alıntı yap.

Bağlam:
{context}

Soru:
{question}

Cevap:
""")

llm = ChatOllama(
    model="llama3.1:8b",
    temperature=0.2,   # faktüel görev — düşük temperature
)

temperature=0.2 bilinçli: yaratıcı yazı değil, kaynak okuyup özetleme yapıyoruz. 0.7-0.9 aralığı (yaratıcılığa uygun) burada modeli “süslemeye” iter, halüsinasyon riski artar.

5. Uçtan Uca: Terminal Chat

Tüm parçaları LangChain’in LCEL syntax’ı ile tek bir zincire bağlıyoruz. Zincirin girdisi soru, çıktısı cevap.

# chat.py — Part 3: zincir + terminal döngüsü
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

def format_context(docs):
    return "\n\n---\n\n".join(d.page_content for d in docs)

rag_chain = (
    {
        "context": retriever | format_context,
        "question": RunnablePassthrough(),
    }
    | prompt
    | llm
    | StrOutputParser()
)

print("RAG chatbot hazır. Çıkmak için 'q' yaz.\n")
while True:
    soru = input("Soru: ").strip()
    if soru.lower() in {"q", "quit", "exit"}:
        break
    cevap = rag_chain.invoke(soru)
    print(f"\nCevap: {cevap}\n")

Şimdi python chat.py çalıştır. Örnek bir oturum (KVKK metni üzerinden):

Soru: Veri sorumlusunun temel yükümlülükleri nelerdir?

Cevap: Belgeye göre veri sorumlusunun temel yükümlülükleri şunlardır:
1) Veri işleme faaliyetlerini Veri Sorumluları Siciline (VERBİS) bildirmek,
2) İlgili kişiyi aydınlatma yükümlülüğünü yerine getirmek,
3) Verinin güvenliğini sağlayacak teknik ve idari tedbirleri almak,
4) İhlal hâlinde Kurul'a en kısa sürede bildirimde bulunmak.
(Madde 12 ve devamı çerçevesinde özetlenmiştir.)

Soru: Şirket içi VPN politikası nedir?

Cevap: Bu konuda belgede bilgi bulunamadı.

İkinci cevaba dikkat: model uydurmadı, susmayı tercih etti. Sistem prompt’undaki tek bir cümle, klasik bir LLM chatbot’la güvenilir bir kurumsal asistan arasındaki farktır. RAG, bir ajanın hafızasıdır, ajan kurmaya geçmek için sıfırdan AI agent yapımı yazısı doğal devam.

Yanlış Cevap Geldi: Re-ranking, Hibrit Arama, Chunk Boyutu

İlk versiyon çalışır. Ama dakika 10’da bir kullanıcı “bu cevap yanlış” der ve onların haklı olduğunu görürsün. Üç klasik başarısızlık + çözümü:

Yanlış chunk geldi (top-k yetersiz)

Top-4 chunk geldi ama 4’ünün hepsi alakasız. Sebep: sorunun fenomenolojisi belgedeki kelimelere uymuyor. Kullanıcı “ücretsiz izin” diyor, belge “izinsiz izin” başlığı altında geçiyor.

İki çözüm:

• Soruyu yeniden formüle et (HyDE). LLM’e “bu soruya verilecek hipotetik bir cevap nasıl olurdu?” diye sor, o hayali cevabı vektörle, sonra ara. Hipotetik cevap belgenin dilini taklit ettiği için isabet artar.
• Re-ranker. Önce top-20 chunk’ı geniş ağ ile çek; sonra bge-reranker-v2-m3 gibi cross-encoder ile bu 20’yi soruya göre yeniden sırala ve top-4’ü al. Maliyet az, kazanç büyük.

Anahtar kelime arama gerekiyor (kanun maddesi, ürün kodu)

Saf anlamsal arama “Madde 6/3”, “TKHK 8/2”, “SKU-78231” gibi keskin tokenları kaçırabilir, çünkü embedding bunları “sayı + harf” olarak homojenleştirir. Çözüm: hibrit arama, semantic + BM25 (klasik kelime eşleme) sonuçlarını birleştir.

from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever

bm25 = BM25Retriever.from_documents(chunks)
bm25.k = 4

ensemble = EnsembleRetriever(
    retrievers=[bm25, retriever],
    weights=[0.4, 0.6],   # %40 keyword, %60 semantic
)

weights yüzdelik dağılımı belgenin doğasına göre kalibre ediliyor: çok sayısal koda dayalı dokümanda BM25 ağırlığını artır, akademik metinde semantic’i.

Chunk boyutu yanlış

Çok küçük chunk (300 token) → bağlam parçalanır, model “yarım cümle” görür. Çok büyük chunk (2000+) → bir parçanın içinde alakasız 3 konu olur, embedding ortalama anlam çıkarmaya çalışırken kaybeder. Pratik kural: 1 chunk = 1-2 paragraf, 500-1000 token, 100-200 overlap. Üretim öncesi 3 farklı chunk_size deneyip aynı soru setiyle karşılaştır, kalite testinin temel adımı.

Production’a Taşıma ve Sonraki Adımlar

Lokalde çalışan PoC ile production-grade RAG arasındaki mesafeyi dört başlık altında özetleyelim.

Vektör DB ölçeği. Chroma, ~100k chunk’a kadar gayet iyi. Üstüne çıkacaksan pgvector (Supabase / RDS / kendi Postgres’in) veya Qdrant (cluster destekli, milyonlarca vektör) tarafına geç. LangChain konfigürasyonunda tek satır değişiklik: Chroma(...) yerine PGVector(...) veya Qdrant(...). Mimari yeniden yazılmıyor.

Citation, kaynak gösterme. Retrieved chunk’ların metadata alanında sayfa numarası ve dosya adı duruyor. Cevabın altına bunları ekle:

docs = retriever.invoke(soru)
cevap = rag_chain.invoke(soru)
kaynaklar = [f"{d.metadata['source']} (s. {d.metadata.get('page', '?')})" for d in docs]
print(f"{cevap}\n\nKaynaklar:\n- " + "\n- ".join(set(kaynaklar)))

Kullanıcı şüphelendiği cevabı belgenin sayfasıyla karşılaştırabilir. Bu, RAG’in fine-tuning’e karşı en büyük operasyonel avantajı: cevabı denetlenebilir yapar.

Geri bildirim döngüsü. Cevabın yanına 👍/👎 düğmeleri koy. 👎 geldiğinde soru + verilen cevap + retrieve edilen chunk’lar üçlüsünü logla. Haftada bir bu logları gözden geçir:

• 👎 nedeni chunk hatası mı? → re-ranker veya chunk_size ayarla.
• Doğru chunk geldi ama cevap kötü mü? → prompt’u sıkılaştır.
• Belge eksik mi? → ingest pipeline’ına yeni kaynak ekle.

Bu döngü olmadan RAG sistemleri yavaşça çürür, kullanıcı kaybettiği zamanı bildirmez, sadece kullanmayı bırakır.

KVKK / şirket gizliliği. Yukarıda kurduğun stack’in tamamı yerel: Ollama localhost’ta, Chroma kendi diskinde, LangChain orchestration sadece bu ikisini bağlayan koddur. Hiçbir veri 3. tarafa çıkmaz. Yargı, sağlık, savunma ve finans sektöründe RAG’in yaygınlaşmasının asıl sebebi de bu, bulutta API çağırmadan AI hizmet sunabilmek.

Kapanış

Üç madde halinde özet:

• RAG, yapay zekayı “her şeyi bilen” bir kahinden, “senin verini referansla okuyup yanıtlayan” bir asistana dönüştürür. Halüsinasyonu düşürür, kaynak gösterir, veriyi 3. tarafa göndermez.
• Ollama + LangChain + Chroma üçlüsüyle bütün hattı tek bilgisayarda, ücretsiz ve KVKK uyumlu kurabilirsin. 200 satır Python yetiyor.
• Production’a giderken pgvector/Qdrant + re-ranker + hibrit arama + citation dörtlüsü zorunlu olur. Başlangıçta değil, önce bir versiyon konuştur, ölç, sonra ölçekle.

Sıradaki adım çok net: kendi PDF’ini docs/ klasörüne at, python ingest.py koştur, python chat.py ile konuş. İlk gerçek soruyu kendi belgene sorduğunda, yapay zekanın senin için ne kadar farklı bir şey haline geldiğini hissedeceksin.

Daha sofistike workflow için ise RAG bir başlangıç; bir sonraki katman, bu hattı bir AI ajanına hafıza olarak verip “sor, ara, oku, eyleme dök” döngüsüne sokmak.

Sonraki adım

Yerel RAG hattını kurduktan sonra ekosistemin geri kalanını şu sırayla öğrenmek pratikte en hızlı yol:

• Vektör Veritabanı Karşılaştırması: Pinecone, Chroma, Weaviate — Chroma’dan Production veritabanına geçişin haritası.
• Function Calling ile LLM’leri Sistemlere Bağlamak — retrieval’i bir tool olarak modele veren tool-use katmanı.
• AI Agent Framework Karşılaştırma: LangGraph, CrewAI, AutoGen — RAG’i bir ajan döngüsüne yerleştirecek orkestrasyon seçimi.