Retrieval-Augmented Generation, bir modelin cevabını dokümanlardan getirilen bağlamla kuran mimaridir. Model her soruda ilgili parçaları bağlam olarak alır; kaynak modelden ayrı durduğu için doküman değişince cevap da değişir.

RAG mı fine-tuning mi?

Fine-tune edilmiş model bilgiyi dondurur: doküman değişince yeniden eğitirsiniz ve bir cevabın hangi dokümandan geldiğini soramazsınız. RAG'i seçtiren ucuzluğu değil, kaynağın modelden ayrı kalması. Fine-tuning ve model uyarlama işini de yapıyorum; ikisi farklı problemlerin cevabı.

RAG'de aramayı nasıl kuruyorsun?

Her parçayı hem vektör indeksine hem tam metin indeksine koyuyor, iki sıralamayı birleştiriyorum. Çünkü bir sabit adı, hata kodu ya da bayrak embedding modelinin temsil edemediği bir şey olabilir ve tam metin tarafı onu yakalıyor. Birleştirmeyi skorla değil sıralamayla yapıyorum; embedding modeli değişince skor ağırlıkları yeniden öğrenilmek zorunda.

Vektör veritabanı olarak ne kullanıyorsun?

Varsayılan tercihim pgvector: vektörleri kullanıcı, doküman ve istek kayıtlarıyla aynı PostgreSQL'de tutuyorum, ikinci bir depo ve koordinasyon katmanı kurmuyorum. Bedeli, her şeyin tek PostgreSQL'e yaslanması ve onun buna göre boyutlandırılması; tek PostgreSQL yetmediğinde, koleksiyon büyüdüğünde Milvus'u, hızlı prototiplerde Chroma'yı kullanıyorum.

Embedding'i nerede üretiyorsun?

Kendi sunucunda çalışan, sürekli sorgulanmak üzere kurulmuş doküman arama araçlarımda varsayılan yol makinenin kendi CPU'su: çalışmak için anahtar isteyen bir araç, "kendi sunucunda çalışır" sözünü baştan bozar. Birkaç ortam değişkeniyle bulut embedding'ine geçilebiliyor ama varsayılan yol makineden çıkmıyor. Bedeli ilk açılışta ödeniyor: model iniyor ve container'ın ayağa kalkması birkaç dakika sürüyor. Sağlayıcıya giden gateway kurulumlarında ise limitler retrieval'dan önce kontrol edilir; kısıtlanan istemci bir embedding çağrısı bile harcamaz.

Retrieval başarısız olursa isteğe ne oluyor?

İsteği düşürmüyorum: yeniden sıralama servisi cevap vermezse, arama arka ucu erişilemezse ya da bağlam getirilemezse olay loglanıyor ve istek bağlamsız devam ediyor. Bedeli açık: yanıtta getirilemeyen bağlamla hiçbir şeyle eşleşmeyen bağlam aynı sıfır isabet olarak görünüyor, fark yalnız logda. 500 dönmek daha dürüst görünür ama pratikte daha kötü: kullanıcı biraz zayıf bir cevap yerine hiç cevap alıyor.

Uzmanlık

RAG mühendisi (Retrieval-Augmented Generation) — 2024'ten beri

RAG'e karar vermek kolay yarı: 2024'ten beri retrieval hatları kuruyorum ve işin geri kalanı anahtarın, model seçiminin ve harcama sınırının nerede duracağı sorularında çıkıyor.

yıl: 2

Birlikte çalışalım

RAG ekosisteminde ben

Tam hikâye: Hakkımda

RAG kararından sonra üç soru kalıyor ve hiçbiri retrieval’ın parçası değil: sağlayıcı anahtarı nerede duracak, hangi uygulama hangi modeli kullanacak, harcama nerede kesilecek. Bunlar dokümanlar ayrıştırılıp parçalanıp embedding’e çevrildikten ve arama çalıştıktan sonra başlıyor; bu soruların nasıl dört tasarım kararına dönüştüğünü blogda yazdım.

RAG’in kendisi benim için bir arama sorusu olmaktan önce bir sınır sorusu: modelin cevabını kendi belleği mi, yoksa bu soru için getirilen doküman mı kuruyor. İkincisini seçtiğimde kaynak modelden ayrı kalıyor; doküman değişince cevap değişiyor, model değişince doküman yerinde duruyor. Yapay zekâ sistemleri sayfası bu kararı daha geniş bir mühendislik çerçevesinde anlatıyor; bu sayfa retrieval hattının kendisi.

Modele bağlam açmanın başka bir yolu da MCP: orada retrieval bir sunucunun arkasında duruyor ve sunucu bir güven sınırı oluyor. Hangi yolu seçeceğim, bağlamın nerede yaşadığına ve kimin erişeceğine bağlı.

RAG Mühendisi nedir?

RAG (Retrieval-Augmented Generation), bir modelin cevabını kendi belleğine değil, sorunun anında dokümanlardan getirilen bağlama dayandıran mimaridir. RAG mühendisi, dokümanların nasıl parçalanıp embedding'e çevrileceğini, aramanın nasıl yapılacağını ve getirilen bağlamın modele nasıl verileceğini tasarlar.

RAG Mühendisi ne iş yapar?

RAG hatlarında dokümanları ayrıştırıp parçalıyor, embedding'e çeviriyor ve vektör aramayı tam metin aramayla birleştiriyorum. Vektörleri PostgreSQL içinde pgvector ile tutuyorum; koleksiyon büyüdüğünde Milvus'u, hızlı bir prototip gerektiğinde Chroma'yı, modeli yerelde çalıştırmam gerektiğinde Ollama'yı kullanıyorum.

Birlikte kullandığım teknolojiler

Retrieval-Augmented Generation

Modelin cevabını dokümanlardan getirilen bağlamla kuran retrieval mimarisi.
Python

Model eğitimi, fine-tuning ve veri hazırlama işlerimin ana dili.
pgvector

Vektör aramasını ayrı bir depoya taşımadan PostgreSQL içinde tutan eklenti.
Milvus

Büyük embedding koleksiyonlarında kullandığım dağıtık vektör veritabanı.
Chroma

Retrieval prototiplerinde hızla kurulan, gömülü çalışabilen vektör veritabanı.
Ollama

Açık ağırlıklı modelleri yerel makinede çalıştıran ve bir API arkasında sunan araç.
PostgreSQL

Kuyruk tablosu ve index davranışını üzerinde ölçtüğüm veritabanı.
Model Context Protocol

Bir modele araç ve bağlam açan protokol; bağlanan her sunucuyu bir güven sınırı olarak ele alıyorum.

Sık sorulanlar

8 soru

RAG ile kaç yıldır çalışıyorsun?

2024'ten bu yana, 2 yıldır.
RAG nedir?

Retrieval-Augmented Generation, bir modelin cevabını dokümanlardan getirilen bağlamla kuran mimaridir. Model her soruda ilgili parçaları bağlam olarak alır; kaynak modelden ayrı durduğu için doküman değişince cevap da değişir.
RAG mühendisi ne iş yapar?

Dokümanları ayrıştırıp parçalar, embedding'e çevirir, aramayı kurar ve getirilen bağlamı modele verir. Bende iş burada bitmiyor: anahtarın, model seçiminin ve harcama sınırının nerede duracağı da aynı işin parçası.
RAG mı fine-tuning mi?

Fine-tune edilmiş model bilgiyi dondurur: doküman değişince yeniden eğitirsiniz ve bir cevabın hangi dokümandan geldiğini soramazsınız. RAG'i seçtiren ucuzluğu değil, kaynağın modelden ayrı kalması. Fine-tuning ve model uyarlama işini de yapıyorum; ikisi farklı problemlerin cevabı.
RAG'de aramayı nasıl kuruyorsun?

Her parçayı hem vektör indeksine hem tam metin indeksine koyuyor, iki sıralamayı birleştiriyorum. Çünkü bir sabit adı, hata kodu ya da bayrak embedding modelinin temsil edemediği bir şey olabilir ve tam metin tarafı onu yakalıyor. Birleştirmeyi skorla değil sıralamayla yapıyorum; embedding modeli değişince skor ağırlıkları yeniden öğrenilmek zorunda.
Vektör veritabanı olarak ne kullanıyorsun?

Varsayılan tercihim pgvector: vektörleri kullanıcı, doküman ve istek kayıtlarıyla aynı PostgreSQL'de tutuyorum, ikinci bir depo ve koordinasyon katmanı kurmuyorum. Bedeli, her şeyin tek PostgreSQL'e yaslanması ve onun buna göre boyutlandırılması; tek PostgreSQL yetmediğinde, koleksiyon büyüdüğünde Milvus'u, hızlı prototiplerde Chroma'yı kullanıyorum.
Embedding'i nerede üretiyorsun?

Kendi sunucunda çalışan, sürekli sorgulanmak üzere kurulmuş doküman arama araçlarımda varsayılan yol makinenin kendi CPU'su: çalışmak için anahtar isteyen bir araç, "kendi sunucunda çalışır" sözünü baştan bozar. Birkaç ortam değişkeniyle bulut embedding'ine geçilebiliyor ama varsayılan yol makineden çıkmıyor. Bedeli ilk açılışta ödeniyor: model iniyor ve container'ın ayağa kalkması birkaç dakika sürüyor. Sağlayıcıya giden gateway kurulumlarında ise limitler retrieval'dan önce kontrol edilir; kısıtlanan istemci bir embedding çağrısı bile harcamaz.
Retrieval başarısız olursa isteğe ne oluyor?

İsteği düşürmüyorum: yeniden sıralama servisi cevap vermezse, arama arka ucu erişilemezse ya da bağlam getirilemezse olay loglanıyor ve istek bağlamsız devam ediyor. Bedeli açık: yanıtta getirilemeyen bağlamla hiçbir şeyle eşleşmeyen bağlam aynı sıfır isabet olarak görünüyor, fark yalnız logda. 500 dönmek daha dürüst görünür ama pratikte daha kötü: kullanıcı biraz zayıf bir cevap yerine hiç cevap alıyor.

Birlikte çalışalım

Bu ekosistemde bir işiniz varsa, ne yaptığınızı anlatın; nasıl kurulacağını konuşalım.

Bana yaz