Ne yalan söyleyeyim, Bir ara masaüstümdeki klasörlere bakıp kendi kendime şunu düşündüğümü hatırlıyorum: “Ben bu notları niye bir daha bulamıyorum?” 2024’ün Mart ayında, İstanbul’da kahve soğurken açtığım bir araştırma dosyasında aynı sorun yine karşıma çıktı. PDF’ler ayrı yerde, ekran görüntüleri başka klasörde, birkaç hayati cümle ise Notion’un derinliklerinde bir yerlerde kaybolmuştu — hani o “şimdi buldum” dediğin an bir daha gelmiyor ya, aynen öyle. İşte tam da o noktada yerel RAG fikri bayağı anlamlı hale geldi benim için.
İşin özeti şu: kendi verinizi kendi makinenizde tutarak soru sorabiliyorsunuz. Model internete kaçmıyor. API anahtarı peşinde koşmuyorsunuz. Veri de dışarı sızmıyor. Kulağa biraz “fazla iyi” gibi geliyor olabilir, biliyorum — ama açık konuşayım, doğru kurulduğunda gerçekten iş görüyor.
Neden Yerel RAG Bu Kadar İlgi Çekiyor?
RAG dediğimiz şey aslında yapay zekâya hafıza takmak gibi. Modeli tek başına bırakmıyorsunuz; ona sizin belgelerinizi gösteriyorsunuz, kendi arşivinizi önüne seriyorsunuz. Böylece “geçen hafta okuduğum makalede ne vardı?” diye sorduğunuzda sallama cevap vermek yerine ilgili parçaları çekip kullanıyor (ciddiyim)
Benzer bir sistemi 2023 sonunda küçük bir içerik arşivi için denemiştim. O zaman bulut tabanlı servisler cazip gelmişti ama maliyet meselesi ve gizlilik kaygısı can sıkıyordu. Bilhassa hukuk dokümanları ya da sağlık notları söz konusuysa, veriyi dışarı taşımak insanın içini rahat ettirmiyor… hani kağıt üstünde güzel görünür, “güvenli” der geçersiniz, ama içinizde bir tereddüt kalıyor işte. Kalıyor.
Yerel yaklaşımın en dayanıklı yani tam da burada çıkıyor: kontrol sizde kalıyor. Bir de şu var — kişisel bilgi yönetimi dediğiniz şey bazen “büyük veri” değil, tam tersine küçük ama çok değerli kırıntılar demek. Bir cümlelik toplantı notu bile iki ay sonra altın değerine dönüşebiliyor. Gerçekten.
Boru Hattı Nasıl Çalışıyor?
Bakın şimdi, temel akış dört beş adımdan oluşuyor ve göz korkutacak kadar karmaşık değil. Önce metni parçalara bölüyorsunuz — buna chunking deniyor. Sonra her parçayı embedding ile sayısal temsile çeviriyorsunuz. Ardından bu vektörleri ChromaDB gibi yerel bir veritabanına koyuyorsunuz. Sırası önemli, atlamayın.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Sorgu geldiğinde sistem benzer parçaları çekiyor ve LLM’e veriyor. Model de elindeki bağlama göre cevap üretiyor. Yani modelin belleksiz davranmasını engelliyorsunuz; ona kısa süreli bir çalışma masası açıyorsunuz diyelim. Güzel bir metafor bu aslında. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Araya gireyim: Editör masasındayken bu tip mimarileri seviyorum çünkü test etmesi keyifli oluyor. Geçen ay Kadıköy’de çalışırken basit bir PDF koleksiyonuyla deneme yaptım; düzgün chunk boyutu seçmeyince cevaplar da dağıldı gitti. Hani ne farkı var diyorsunuz, değil mi? Küçücük detaylar pek çok deneyimi etkiliyor — bunu yaşayarak öğrendim.
| Aşama | Ne Yapıyor? | Dikkat Noktası |
|---|---|---|
| Chunking | Metni parçalara ayırıyor | Çok büyük olursa kaçırır, çok küçük olursa bağlam bozulur |
| Embedding | Parçayı sayısal vektöre çeviriyor | Kullandığınız model kalitesi önemli |
| Saklama | Vektörleri yerelde tutuyor | Pencere kapalıyken bile veri sizde kalıyor |
| Sorgu + Üretim | Anlamlı parçaları çekip yanıt yazıyor | Cevapların kaynaklanması şart |
Neden Chunk Boyutu Önemli?
Eğer metni fazla iri dilimlerseniz sistem ilgili kısmı kaçırabiliyor. Fazla küçültürseniz bu kez anlam kopuyor (ben de ilk duyduğumda şaşırmıştım). Paragrafın yarısını alıp diğer yarısını bırakınca ortaya — ki bu tartışılır — kuru bir tost çıkmış gibi oluyor — içi yok, bağlamı yok. Ben genelde orta karar yaklaşımı seviyorum: 500 civarı karakter ya da token bazlı dengeli segmentler fena değil, en azından başlangıç için. Daha fazla bilgi için Claude Code Eklenti Ekosistemi: 12.000+ Plugin Rehberi yazımıza bakabilirsiniz.
Neden Yerel Veritabanı Kullanılır?
Bir şey dikkatimi çekti: Burası biraz sıkıcı görünebilir ama kritik nokta tam burası işte. ChromaDB ya da benzeri yerel çözümler hem hızlı hem de veri mahremiyeti açısından rahatlatıcı. Kurumsal tarafta bunu özellikle seviyorum çünkü güvenlik ekibiyle uzun e-posta trafiğine girmiyorsunuz. Herkes mutlu oluyor diyemem — ama en azından tartışma azalıyor. Küçük kazanım sayılır. CSS Animasyonlarında Fazla Mesai: FSCSS ile Rahatlayın yazımızda bu konuya da değinmiştik.
Kod Tarafında Neler Oluyor?
Aşağıdaki yapı tipik bir kurulumun iskeleti gibi düşünülebilir:
import ollama
import chromadb
client = chromadb.PersistentClient(path="./knowledge_db")
collection = client.get_or_create_collection(
name="documents",
metadata={"hnsw:space": "cosine"}
)
def chunk_text(text, chunk_size=500, overlap=50):
chunks = []
start = 0
while start < len(text):
end = start + chunk_size
chunks.append(text[start:end])
start += chunk_size — overlap
return chunks
def embed_and_store(doc_id, text):
for i, chunk in enumerate(chunk_text(text)):
response = ollama.embed(model="gemma3", input=chunk)
collection.add(
ids=[f"{doc_id}_chunk_{i}"],
embeddings=[response["embeddings"][0]],
documents=[chunk],
metadatas=[{"source": doc_id, "chunk_index": i}]
)Daha fazla bilgi için Claude Code’u Kandırmadan GPT-5 Codex’e Yönlendirmek yazımıza bakabilirsiniz.
Kod kısa görünüyor diye kandırmasın sizi. Asıl mesele çevresindeki kararlar oluyor — hangi modeli seçeceksiniz, kaç token’lık pencere kullanacaksınız, doküman güncellenince eski vektörleri nasıl temizleyeceksiniz? Bunlar çözülmeden sistem “demo güzel ama prod’da tökezler” seviyesinde kalır. Maalesef.
Aslında, Lafı gevelemeden söyleyeyim: local-first AI tarafının en hoş yani maliyet sürprizi yaşamamak. API faturası yoksa rahat nefes alırsınız — ama bunun bedeli de var. Donanım yükü size biner. Performans tamamen makinenize bağlı olur. Değiş tokuş bu.
Yerel RAG sistemi kurarken ilk hedefiniz “en akıllı model” değil, “en güvenilir akış” olsun. Çünkü iyi tasarlanmamış boru hattı üstüne dünyanın en parlak modeli bile konunca mucize yaratmıyor!
Küçük Takımlar İçin mi Daha Mantıklı?
Evet. Çoğu zaman öyle görünüyor. Küçük startup’larda bütçe baskısı olduğu için ücretsiz ya da düşük maliyetli lokal araçlar çok cazip duruyor — mesela üç kişilik bir ekipte kimse sürekli API kotasını takip etmek istemez, herkes işini yapsın ister. Makul beklenti bu.
- Küçük ekipte avantajlar: — ciddi fark yaratıyor
- – Düşük maliyet baskısı azalır.
- – Veri gizliliği daha kolay korunur.
- – Deneme-yanılma süreci hızlı akar.
Ama dürüst olayım; eksileri de var — Tek makinede çalışan düzen büyüdükçe yetmeyebilir. İndekslerin senkronizasyonu, belge sürümleme, kullanıcı yetkilendirme derken iş enterprise tarafına doğru kaymaya başlıyor. Orada işler biraz daha sertleşiyor doğrusu. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Kurumlarda Ne Değişiyor?
Büyük yapılarda konu sadece teknik olmuyor; yönetişim de devreye giriyor. Kim hangi dokümana erişecek? Hangi belgeler indekslenecek? Silinen kayıtlar gerçekten silindi mi? Bu sorular yüzünden proje uzayabiliyor, hatta bazen hayal kırıklığına dönüyor.
Bunu geçen yıl Şişli’de bir danışmanlık görüşmesinde net gördüm. Ekip yerel çözümü çok istemişti ama güvenlik politikaları yüzünden bazı klasörlerin sisteme hiç alınmaması gerekiyordu. İşin aslı şu ki, yerellik tek başına yeterli değil; süreç disiplini olmadan sadece güzel fikir olarak kalabiliyor. Güzel ama işlevsiz.
Nerede Parlıyor, Nerede Tökezliyor?
Bence en güçlü kullanım alanları kişisel arşivler, araştırma notları, okuma listeleri ve proje dökümanları. Mesela PDF içinde gömülü bilgi ararken fark yaratıyor. Bir şeyi beş dakika içinde buluyorsanız o sistem zaten işe yarıyordur — başka ölçüt aramayın.
Şöyle ki, Zayıf taraflara gelirsek: veri kalitesi kötüyse sonuç da kötü olur. Çöp girerse çöp çıkar, bu klişe ama burada acı şekilde doğru. Bir dosyada başlık yoksa veya taramalar berbatsa retrieval katmanı ne kadar iyi olursa olsun mucize beklemeyin. Beklemeyin gerçekten.
Hmm, bunu nasıl anlatsamdı…
Sık Yapılan Hatalar ve Pratik İpuçları
- Dökümanı doğrudan devasa blok halinde indexlemek yerine parçalara bölün.
- Aynı içeriğin kopyalarını temizleyin; aksi halde model aynı şeyi üç kez görür.
- Sorgu tarafında top-k değerini körlemesine yükseltmeyin; gürültü artabilir.
- Cevaplara mutlaka kaynak parçasını ekleyin; kullanıcı güveni buradan geliyor.
Tuning İşine Nasıl Yaklaşmalı?
Ben genelde önce basit tutup sonra iyileştirmeyi seviyorum. İlk versiyonda mükemmeliyetçilik gereksiz yere fren yapar — önce çalışsın, sonra güzelleştirirsiniz. Bu yaklaşımı geçen yaz Ankara’da yürüttüğüm küçük otomasyon projesinde kullandım; hız kazandırdı, açık konuşayım.
Eğer tek kullanıcıysanız local Ollama + ChromaDB ikilisi fazlasıyla yeterli olabilir. Ama on kişi — kendi adıma konuşayım — aynı anda sorgu atacaksa bellek tüketimi, disk I/O ve indeks güncelleme gecikmeleri hemen görünür hale gelir. Yani ihtiyaç büyüdükçe mimariyi yeniden düşünmek şart — ertelemek işe yaramıyor — valla güzel iş çıkarmışlar —
Sıkça Sorulan Sorular
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
