#Üretimde RAG Pipeline Kurmak: Pratik Dersler

RAG pipeline, doğru kurulduğunda LLM uygulamalarını daha güncel, daha izlenebilir ve daha kontrol edilebilir hale getirir. Yanlış kurulduğunda ise sadece ek bir karmaşıklık katmanı olur. Üretimde farkı yaratan şey, demo başarısından çok geri getirme kalitesi, gecikme bütçesi, değerlendirme disiplini ve operasyonel gözlemlenebilirliktir.

Bu yazıda, AI mühendisleri için üretim odaklı bir RAG pipeline tasarlarken karşılaştığım temel kararları ve pratik dersleri özetliyorum.

#RAG pipeline neyi çözer, neyi çözmez?

RAG, modeli yeniden eğitmeden dış bilgiyi cevap üretim sürecine ekler. Bu, özellikle değişen dokümantasyon, ürün bilgisi, iç bilgi tabanları ve destek senaryolarında işe yarar.

Ancak RAG şunların yerine geçmez:

• kötü tanımlanmış bilgi mimarisini
• zayıf veri kalite süreçlerini
• yanlış ürün kapsamını
• temel model limitlerini tamamen

Başka bir deyişle, RAG bir otomatik doğruluk makinesi değildir. İyi bir bilgi erişim sistemi ve iyi bir değerlendirme çerçevesi gerektirir.

#Tipik üretim akışı

Basit bir üretim RAG pipeline genelde şu aşamalardan oluşur:

1. Ingestion: Dokümanları, logları veya veri kaynaklarını toplama
2. Chunking: İçeriği arama için anlamlı parçalara ayırma
3. Embedding: Parçaları vektör temsillerine dönüştürme
4. Indexing: Vektör ve metadata indeksini oluşturma
5. Retrieval: Sorgu için en alakalı parçaları getirme
6. Reranking: İlk sonuçları daha iyi bir sıralayıcı ile yeniden düzenleme
7. Prompt assembly: Bağlamı güvenli ve sınırlı biçimde prompt’a ekleme
8. Generation: LLM ile yanıt üretme
9. Post-processing: Kaynak gösterme, filtreleme, politika kontrolleri
10. Observability: İz, metrik ve geri bildirim toplama

Buradaki en yaygın hata, bütün odağı generation aşamasına vermektir. Oysa üretimde performansı çoğu zaman retrieval belirler.

#Chunking kararları model kalitesini doğrudan etkiler

Chunking ilk bakışta mekanik görünür, ama üretimde kritik bir tasarım kararıdır. Fazla küçük chunk’lar bağlamı parçalar; fazla büyük chunk’lar ise retrieval hassasiyetini düşürür.

Pratikte şu kurallar yardımcı olur:

• Başlık ve alt başlık yapısını koru
• Semantik bütünlüğü bozma
• Tablo, kod ve liste gibi özel formatları ayrı ele al
• Chunk boyutunu veri tipine göre ayarla
• Overlap kullan ama gereksiz tekrar üretme

Bir dokümanı sayfa bazlı bölmek yerine, anlamlı alt bölümlere ayırmak çoğu senaryoda daha iyi sonuç verir.

#Retrieval kalitesi için embedding tek başına yetmez

Embedding modeli önemlidir, ama iyi retrieval için tek başına yeterli değildir. Üretimde genelde şu bileşenler birlikte düşünülür:

• dense retrieval
• lexical retrieval
• hybrid search
• metadata filtreleri
• reranking

Özellikle kurumsal veri setlerinde metadata filtreleri çok değerlidir. Örneğin tarih, dil, ürün sürümü, erişim seviyesi ve kaynak türü gibi alanlar retrieval alanını daraltır.

Bir diğer önemli nokta da query rewriting. Kullanıcı sorgusu kısa, eksik veya konuşma dilinde olabilir. Sorguyu yeniden yazmak, retrieval kalitesini ciddi biçimde artırabilir.

#Reranking çoğu zaman düşük maliyetli yüksek etki sağlar

İlk retrieval sonuçları genelde yeterince iyi ama sıralaması zayıftır. Reranker kullanmak, özellikle top-k sonuçların doğruluğunu artırır.

Bunu bir lüks değil, üretim optimizasyonu olarak görmek gerekir. Çünkü:

• daha iyi top-k bağlamı
• daha az gürültü
• daha düşük hallucination riski
• daha tutarlı cevaplar

Reranking katmanı maliyet ve gecikme ekler, ama çoğu uygulamada bu maliyet karşılığını verir.

#Prompt tasarımı sadece talimat yazmak değildir

RAG prompt’u, modelin bağlamı nasıl kullanacağını belirler. İyi bir prompt şu özellikleri taşır:

• bağlamı açık sınırlar içinde sunar
• kaynak dışı bilgi üretimini caydırır
• cevap formatını net tanımlar
• eksik bilgi durumunda davranışı belirtir

Örneğin modelin, bağlamda yoksa bunu açıkça söylemesini istemek önemlidir. Aksi durumda model boşlukları doldurabilir.

Ayrıca prompt içine çok fazla doküman koymak genelde iyi fikir değildir. Daha çok bağlam, daha iyi sonuç anlamına gelmez. Gereksiz bağlam dikkat dağıtır ve token maliyetini artırır.

#Değerlendirme olmadan üretime çıkmak risklidir

RAG sistemlerinde klasik offline değerlendirme ile gerçek kullanım davranışı arasında fark olabilir. Bu yüzden hem retrieval hem generation için ayrı değerlendirme yapmak gerekir.

Ölçülebilecek bazı başlıklar:

• retrieval hit rate
• context precision
• context recall
• answer faithfulness
• answer relevance
• latency
• token usage
• fallback rate

Altın etiketli veri azsa, insan değerlendirmesi ve örnek bazlı inceleme çok değerlidir. Üstelik aynı sorgu setini düzenli olarak yeniden çalıştırmak regresyon yakalamada yardımcı olur.

#Gözlemlenebilirlik üretimde fark yaratır

Sadece final cevabı loglamak yeterli değildir. RAG pipeline’da şu sinyalleri izlemek gerekir:

• kullanıcı sorgusu
• normalize edilmiş sorgu
• retrieved chunk’lar
• rerank skorları
• prompt uzunluğu
• model cevabı
• kaynak referansları
• hata ve timeout kayıtları

Bu veriler olmadan sorun nerede oluştuğunu anlamak zordur. Retrieval mı bozuldu, chunking mi kötüleşti, yoksa model mi tutarsız davrandı, bunu izler olmadan ayırt etmek güçtür.

#Gecikme bütçesi erken tasarlanmalı

Üretimde RAG pipeline’ın en sık gözden kaçan taraflarından biri latency’dir. Retrieval, reranking ve generation toplamı kullanıcı deneyimini doğrudan etkiler.

Erken aşamada şu sorular sorulmalı:

• Hedef yanıt süresi nedir?
• Retrieval kaç milisaniye sürmeli?
• Reranker senkron mu asenkron mu çalışacak?
• Cache hangi katmanlarda kullanılacak?
• Kısa sorgular için daha hızlı bir fallback var mı?

Bazı sistemlerde çok aşamalı pipeline yerine basit ve hızlı bir çözüm daha iyi sonuç verir. Teknik olarak daha zengin olan mimari, ürün olarak daha iyi olmak zorunda değildir.

#Güvenlik ve veri sızıntısı ciddiye alınmalı

RAG, hassas veriyi modele taşımayı kolaylaştırabilir. Bu yüzden erişim kontrolü retrieval katmanında uygulanmalıdır; sadece prompt tarafında değil.

Dikkat edilmesi gerekenler:

• yetkisiz doküman erişimi
• prompt injection
• kaynak içeriğinde zararlı talimatlar
• PII ve gizli veri sızıntısı
• tenant izolasyonu

Özellikle çok kiracılı sistemlerde, retrieval sonuçları kullanıcı yetkileriyle sıkı biçimde filtrelenmelidir.

#Basitlik çoğu zaman daha iyi başlangıçtır

Üretim için iyi bir başlangıç çoğu zaman şu formüldür:

• iyi tanımlanmış veri kapsamı
• sade chunking stratejisi
• hybrid retrieval
• hafif reranking
• net prompt şablonu
• sağlam değerlendirme seti
• detaylı logging ve tracing

Her soruna ayrı bir model eklemek yerine, mevcut hattın kalitesini ölçmek ve iyileştirmek daha sürdürülebilir olur.

#Sonuç

RAG pipeline kurmak, yalnızca vektör veritabanı bağlamak değildir. Üretimde başarılı bir sistem; veri kalitesi, retrieval tasarımı, prompt kontrolü, güvenlik, değerlendirme ve operasyonel görünürlük arasında iyi bir denge gerektirir.

En önemli pratik ders şu: önce retrieval’ın gerçekten ne kadar iyi çalıştığını kanıtla, sonra generation’ı optimize et. Çünkü çoğu RAG problemi modelden değil, bağlamın yanlış seçilmesinden kaynaklanır.

Eğer istersen bir sonraki yazıda bunu daha da ileri taşıyıp örnek bir production RAG mimarisi, teknoloji seçimi ve değerlendirme checklist’i paylaşabilirim.