RAG Neden Çöküyor? Üretimde Retrieval Hataları ve Adaptif Yönlendirme (2026)

TL;DR — Üretimde RAG (retrieval-augmented generation) sistemleri çoğunlukla modelin "aptallığından" değil, yanlış belgeyi getirmekten çöküyor. 2026 saha analizleri, RAG hatalarının yaklaşık %73'ünün retrieval (getirim) aşamasından kaynaklandığını gösteriyor; üretim değil. Bu yazıda hibrit aramayı, yeniden sıralamayı (reranking), sorgu karmaşıklığına göre adaptif yönlendirmeyi ve agentic RAG'e geçişi sahadan örneklerle anlatıyorum. Amaç net: demo'da parlayan RAG'i üretimde de ayakta tutmak.

RAG projelerinde en sık duyduğum cümle şu: "Model çok iyi ama cevaplar bir türlü tutmuyor." Oysa çoğu zaman sorun modelde değil. Model, kendisine verilen bağlamı (context) sadakatle işliyor; ama o bağlam yanlışsa, model de güvenle yanlış cevap üretiyor. Buna sahada "çöp gir, çöp çık" diyoruz. 2026'da olgunlaşan bir farkındalık var: RAG bir "model problemi" değil, bir "bilgi getirimi problemi". Bir sistem çöktüğünde bakılacak ilk yer, modelin ürettiği metin değil; modele hangi belgelerin verildiğidir.

Bu neden bu kadar önemli? Çünkü ekipler enerjilerini yanlış yere harcıyor. Cevaplar kötü gelince herkes "daha büyük model" ya da "daha iyi prompt" arıyor. Halbuki retrieval katmanı bozuksa, dünyanın en güçlü modeli bile yanlış belgeyle doğru cevap üretemez. RAG'i iyileştirmenin yolu, önce getirimi ölçmekten, sonra getirimi düzeltmekten geçiyor.

"

Sahadan kural: RAG bir cevabı yanlış verdiğinde, önce "hangi belgeler geldi?" diye sorun. Onda birinizde sorun modelde değil, gelen belgelerdedir.

Getirimin neden bozulduğunu beş başlıkta topluyorum. Birincisi kötü chunking (parçalama). Belgeleri anlamsız yerlerden, örneğin cümle ortasından böldüğünüzde, embedding vektörü de yarım bir anlamı temsil eder ve arama isabet etmez. İkincisi embedding-sorgu uyumsuzluğu: kullanıcının sorusu ile belgenin dili farklı olduğunda (kısa soru, uzun teknik belge) semantik yakınlık düşer. Üçüncüsü tek yönlü arama: sadece semantik (vektör) araması yapıp anahtar kelime aramasını ihmal etmek, özel isim, ürün kodu, sayı gibi tam eşleşme gerektiren sorgularda başarısız olur. Dördüncüsü sıralama körlüğü: doğru belge ilk 50'de gelir ama ilk 5'e giremez, çünkü yeniden sıralama yoktur. Beşincisi bağlam taşması: çok fazla belge modele tıkıştırılır, önemli bilgi gürültüde kaybolur.

Bu beş kök nedenin ortak özelliği: hepsi getirim katmanında ve hepsi ölçülebilir. RAG'i düzeltmek istiyorsanız, önce bu beş boyutta nerede durduğunuzu ölçmeniz gerekiyor.

2026'da üretime dayanıklı RAG'in temel taşı hibrit arama. Yani hem yoğun (dense/semantik) hem seyrek (sparse/anahtar kelime, örneğin BM25) aramayı birlikte kullanmak. Neden? Çünkü ikisi farklı hatalar yapıyor. Semantik arama "kavramsal olarak benzer" belgeleri bulur ama "İ-450 model numarası" gibi tam eşleşmeleri kaçırabilir. Anahtar kelime araması tam eşleşmeyi yakalar ama eş anlamlıları, dolaylı ifadeleri ıskalar. İkisini birleştirdiğinizde, birinin körlüğünü diğeri kapatıyor.

Pratikte hibrit arama şöyle kurgulanıyor: sorgu hem vektör indeksine hem anahtar kelime indeksine gidiyor, iki ayrı sonuç listesi geliyor, sonra bu listeler bir skor birleştirme yöntemiyle (örneğin karşılıklı sıralama füzyonu, RRF) tek listeye harmanlanıyor. Türkçe gibi morfolojik olarak zengin dillerde bu özellikle kritik; çünkü kelime çekimleri anahtar kelime aramasını zorlarken, semantik arama anlamı yakalar. Türkçe RAG kuranların hibrit aramayı atlaması, en sık gördüğüm hatalardan biri.

Hibrit arama size geniş bir aday havuzu verir; diyelim ilk 50 belge. Ama modele 50 belge veremezsiniz; hem bağlam penceresi hem maliyet buna izin vermez. İşte burada yeniden sıralama (reranking) devreye giriyor. Bir reranker modeli, sorgu ile her aday belgeyi ikili olarak değerlendirip gerçek alaka düzeyine göre yeniden sıralıyor. Tipik bir üretim hattı şöyle işliyor: hibrit aramayla ilk 50'yi getir, reranker ile ilk 5'e indir, o 5 belgeyi modele ver. Bu desen, RAGAS gibi metriklerde cevap kalitesini tutarlı biçimde %15-30 artırıyor.

Reranking'in güzelliği, ucuz getirim ile pahalı hassasiyeti ayırmasında. Vektör araması ucuz ve hızlıdır ama kaba; reranker pahalı ama hassas. İkisini ardışık kullanınca, geniş havuzu ucuza tarayıp sadece en umut verici birkaç adayı pahalı modelle inceliyorsunuz. Bu, hem kaliteyi hem maliyeti aynı anda optimize eden nadir tekniklerden biri.

Aşama	Yöntem	Amaç	Maliyet
1. Geniş getirim	Hibrit (vektör + BM25)	Yüksek kapsama	Düşük
2. Yeniden sıralama	Cross-encoder reranker	Yüksek isabet	Orta
3. Üretim	LLM + ilk 5 belge	Doğru cevap	Yüksek

2026'nın en olgun fikirlerinden biri şu: her sorguyu aynı ağır hattan geçirmeyin. Basit bir "çalışma saatleriniz nedir?" sorusuyla, "geçen çeyrekteki üç bölgenin satış trendlerini karşılaştır" sorusu aynı boru hattını hak etmiyor. En iyi üretim sistemleri, sorgu karmaşıklığını sorgu karmaşıklığıyla eşleştiriyor: basit sorular için hafif bir hat (belki tek bir vektör araması), karmaşık sorular için tam agentic ya da grafik tabanlı cephanelik.

Bu adaptif yönlendirme, hem maliyeti hem gecikmeyi ciddi biçimde düşürüyor. Çünkü çağrıların çoğu aslında basit; onları pahalı çok adımlı bir sürece sokmak israf. Bir yönlendirici (router), gelen sorguyu sınıflandırıp uygun hatta gönderiyor. Kurumsal bir asistanı düşünün: gelen soruların belki %70'i basit bilgi getirimi, %20'si orta karmaşıklıkta, %10'u gerçek muhakeme istiyor. Adaptif yönlendirme, o %70'i ucuza çözüp kaynağı asıl zor %10'a ayırıyor.

RAG'in 2025-2026'daki en büyük paradigma kayması agentic RAG. Klasik RAG'de akış sabit: getir, birleştir, üret. Agentic RAG'de ise ajan getirim sürecinin kendisine karar veriyor. Hangi aracı kullanacak (anahtar kelime araması, semantik arama, API çağrısı, veritabanı sorgusu)? Ne zaman getirecek? Gelen sonuçlar yeterli mi, yoksa yeniden mi aramalı? Bu, statik ve kural güdümlü bir hattan, muhakeme güdümlü dinamik bir mimariye geçiş demek.

Somut bir örnekle açayım. Kullanıcı "X ürününün garanti süresi ne ve bu süre AB'de farklı mı?" diye soruyor. Klasik RAG tek bir arama yapıp en yakın belgeleri getirir; belki garanti süresini bulur ama AB farkını kaçırır. Agentic RAG ise soruyu ikiye böler: önce garanti süresini arar, sonra "AB'de farklı mı" alt sorusu için ayrı bir arama yapar, iki sonucu birleştirir ve yeterli olup olmadığını değerlendirir. Yetersizse tekrar arar. Bu "muhakeme ederek getirme" yaklaşımı, çok parçalı ve koşullu soruları çözmede klasik RAG'i açık ara geçiyor.

Ama bir uyarı: agentic RAG bedava değil. Her ek muhakeme adımı, ek LLM çağrısı, ek gecikme, ek maliyet demek. Bu yüzden agentic RAG'i her soruya değil, gerçekten hak eden karmaşık sorulara saklamak gerekiyor. Adaptif yönlendirme ile agentic RAG'in birlikte çalışması tam da bu yüzden anlamlı: basit sorular hafif hattan, karmaşık sorular agentic hattan geçiyor.

Bazı sorular tek bir belgede cevaplanmaz; birden fazla belgedeki bilgiyi birbirine bağlamayı gerektirir. "A şirketinin CEO'su hangi üniversiteden mezun ve o üniversite hangi şehirde?" gibi çok atlamalı (multi-hop) sorular klasik vektör aramasını zorlar. İşte burada bilgiyi bir grafik olarak temsil eden yaklaşımlar (GraphRAG) devreye giriyor: varlıklar (entities) düğüm, ilişkiler kenar olarak modelleniyor ve getirim bu grafik üzerinde geziniyor. GraphRAG kurmak pahalı ve karmaşık; bu yüzden onu her yere değil, gerçekten ilişkisel muhakeme gerektiren alanlara (uyum, hukuk, karmaşık ürün kataloğu) saklamak akıllıca.

RAG'i düzeltmenin en çok atlanan adımı: ölçüm. Sahada gördüğüm en büyük eksiklik, ekiplerin bir değerlendirme setleri olmaması. Elimde bir soru-doğru cevap seti olmadan, yaptığım her değişikliğin işe yarayıp yaramadığını nasıl bilebilirim? RAG değerlendirmesinde iki boyutu ayrı ayrı ölçmek gerekiyor: getirim kalitesi (doğru belge geldi mi? — recall, precision, MRR) ve üretim kalitesi (cevap doğru ve dayanaklı mı? — sadakat/faithfulness, alaka). Bu ikisini ayırmak, sorunun retrieval'da mı generation'da mı olduğunu anında gösterir.

Ben her RAG projesine, en az 50-100 örnekten oluşan bir "altın set" (golden set) ile başlamayı öneriyorum. Bu set, gerçek kullanıcı sorularından türetilmiş, doğru cevabı ve doğru kaynak belgesi bilinen örnekler içerir. Her değişiklikten sonra bu set üzerinde ölçüm alırsınız. Reranker eklediniz mi? Getirim recall'u ne oldu? Chunk boyutunu değiştirdiniz mi? Sadakat skoru arttı mı? Bu disiplin olmadan, RAG optimizasyonu bir tahmin oyununa döner ve ekip aynı yerde döner durur.

Türkçe RAG kurarken iki ek zorluk var. Birincisi dil: Türkçe morfolojik olarak zengin olduğu için, hem embedding modelinin Türkçeyi iyi temsil etmesi hem de anahtar kelime aramasının çekim eklerini tolere etmesi gerekiyor. Türkçe destekli iyi bir embedding modeli seçmek ve hibrit aramada Türkçe için uygun bir tokenizasyon kullanmak, isabet oranını gözle görülür artırıyor. İkincisi mahremiyet: RAG hattınız kurumsal belgelere eriştiği için, hangi kullanıcının hangi belgeye erişebileceğini getirim aşamasında zorlamanız (erişim kontrollü retrieval) KVKK açısından şart. Bir kullanıcının, yetkisi olmayan bir belgenin içeriğini modelin cevabı üzerinden görmesi ciddi bir veri sızıntısıdır. Erişim kontrolünü modelin insafına bırakmayın; getirim katmanında filtreleyin.

Sahada bir RAG sistemini üretime almadan önce şu listeyi geçiriyorum:

1. Chunking anlamlı sınırlardan mı yapılıyor (paragraf, başlık), yoksa kör mü kesiliyor?
2. Hibrit arama (semantik + anahtar kelime) devrede mi?
3. Reranking var mı; ilk 50'den ilk 5'e iniyor muyuz?
4. Sorgu karmaşıklığına göre adaptif yönlendirme kuruldu mu?
5. Erişim kontrollü getirim ile KVKK/veri güvenliği sağlanıyor mu?
6. Bir altın değerlendirme seti ve düzenli ölçüm var mı?
7. Getirim ve üretim kalitesi ayrı ayrı izleniyor mu?
8. Cevaplar kaynak gösteriyor mu (kullanıcı doğrulayabiliyor mu)?

Bu sekiz maddeyi geçen bir RAG, demo'dan üretime sağlıkla terfi eder. Geçmeyen ise, ilk gerçek kullanıcı yükünde çatlamaya başlar.

Elinizde çöken bir RAG varsa, önerim şu sırayı izlemek: önce ölçün (altın set kurun, getirim recall'unu görün), sonra hibrit aramayı ekleyin, sonra reranking koyun, sonra adaptif yönlendirmeye geçin, en son gerçekten gerekiyorsa agentic ve grafik tabanlı yaklaşımlara uzanın. Bu sıralamanın mantığı, en yüksek getirili ve en ucuz iyileştirmeleri başa almak. Çoğu ekip, henüz hibrit arama ve reranking bile kurmamışken agentic RAG'e atlıyor ve karmaşıklıkta boğuluyor. Oysa temel getirim katmanını sağlamlaştırmak, çoğu RAG probleminin %80'ini az emekle çözüyor. Karmaşıklığı, ancak basit çözümler tükendiğinde ekleyin; çünkü üretimde ayakta kalan sistem, en akıllı olan değil, en az kırılan olandır.

Yukarıda beş kök nedeni sıraladım ama birini özellikle açmak istiyorum, çünkü en çok göz ardı edilen ama en yüksek getirili müdahale burada: chunking, yani belgeleri parçalara ayırma stratejisi. Çoğu ekip, belgeleri sabit karakter sayısına göre (örneğin her 500 karakterde bir) kör bir şekilde bölüyor. Bu yaklaşım cümleleri, tabloları, hatta kelimeleri ortadan kesiyor. Sonuç: her parçanın embedding'i yarım bir anlamı temsil ediyor ve arama isabet etmiyor.

Daha iyi bir yaklaşım, belgenin doğal yapısına saygı gösteren "anlamsal chunking". Başlıkları, paragrafları, liste öğelerini, tablo satırlarını sınır olarak kullanmak. Bir teknik dokümanı bölerken, her bölümü kendi başlığıyla birlikte tutmak, hem embedding kalitesini hem de modele verilen bağlamın anlaşılırlığını artırıyor. Ayrıca "üst üste binen pencereler" (overlapping windows) tekniği faydalı: ardışık parçalar arasında belirli bir örtüşme bırakmak, sınırda kalan bilgiyi kaybetmemeyi sağlıyor.

Bir de metadata zenginleştirmesi var. Her chunk'a hangi belgeden, hangi bölümden, hangi tarihten geldiğini etiketlemek, hem getirimde filtreleme yapmanızı sağlıyor hem de modele verdiğiniz bağlamı izlenebilir kılıyor. "Bu bilgi hangi belgenin kaçıncı sayfasından geldi?" sorusuna cevap verebilmek, hem hata ayıklama hem de kullanıcıya kaynak gösterme açısından altın değerinde. Chunking'i düzeltmek, çoğu zaman kod olarak küçük bir değişiklik ama sonuçta getirim isabetini dramatik biçimde yükseltiyor. Bir müşterimde, sadece kör chunking'den başlık-duyarlı chunking'e geçerek getirim recall'unu %58'den %81'e çıkarmıştık; tek satır model değişikliği yapmadan.

2026'da sık duyduğum bir iddia: "Modellerin bağlam penceresi çok büyüdü, artık RAG'e gerek yok, tüm belgeyi modele verelim." Bu kısmen doğru ama tehlikeli bir aşırı genelleme. Evet, bilgi tabanınız görece küçükse (kabaca 200 bin token altı) ve sık değişmiyorsa, tüm bağlamı modele verip prompt önbelleğinden (prompt caching) faydalanmak bazen RAG altyapısı kurmaktan daha hızlı ve ucuz olabilir. Ama kurumsal gerçeklikte bilgi tabanları milyonlarca belgeden oluşuyor ve sürekli güncelleniyor. Böyle bir hacmi her sorguda modele tıkıştırmak ne mümkün ne de ekonomik.

Ayrıca "her şeyi ver" yaklaşımının gizli bir maliyeti var: "kayıp orta" (lost in the middle) etkisi. Modeller, çok uzun bağlamlarda ortadaki bilgiyi baş ve sondaki bilgiye göre daha zayıf kullanıyor. Yani modele 100 belge verseniz bile, aradığınız bilgi ortalardaysa model onu ıskalayabilir. Bu yüzden "az ama doğru belge" vermek, "çok ama gürültülü belge" vermekten neredeyse her zaman daha iyi. RAG'in özü tam da bu: modele ihtiyacı olan az sayıda doğru belgeyi seçip vermek. Bağlam penceresi büyüdükçe RAG ölmüyor; sadece "kaç belge getireyim" ayarı değişiyor.

Üretimdeki bir RAG sistemini kör uçuşla yönetemezsiniz. Her sorgu için şunları loglamak gerekiyor: hangi sorgu geldi, hangi belgeler getirildi, reranker skorları neydi, hangi belgeler modele verildi, model ne cevap üretti, kullanıcı memnun kaldı mı (varsa geri bildirim). Bu izler olmadan, bir kullanıcı "cevap yanlış" dediğinde nerede hata olduğunu asla bulamazsınız. Getirim mi yanlıştı, reranking mi kötü sıraladı, model mi doğru belgeden yanlış çıkarım yaptı?

İyi bir gözlemlenebilirlik kurulumu, bu soruların cevabını saniyeler içinde veriyor. Ben müşterilere her RAG sorgusunun bir "iz" (trace) üretmesini ve bu izlerin bir panoda incelenebilir olmasını öneriyorum. Böylece haftalık olarak "en çok başarısız olan sorgu türleri" analizini yapıp, sistemi gerçek kullanım verisiyle iyileştirebiliyorsunuz. RAG statik bir ürün değil; canlı bir organizma gibi, kullanım verisiyle sürekli besleniyor ve olgunlaşıyor.

RAG'in en büyük vaadi, modeli gerçek belgelere dayandırarak halüsinasyonu azaltmaktır. Ama bu vaat otomatik değil. Model, kendisine verilen belgeleri görmezden gelip kendi "bildiğini" uydurabilir. Bunu engellemenin yolu, hem prompt tasarımı hem de doğrulama. Prompt'ta modele açıkça "yalnızca verilen belgelere dayan, belgede yoksa 'bilmiyorum' de" talimatı vermek ilk adım. İkinci adım, üretilen cevabın gerçekten kaynak belgelerle desteklenip desteklenmediğini ölçen bir sadakat (faithfulness) kontrolü. İleri sistemler, cevabın her iddiasını bir kaynak cümleye bağlayıp, bağlanamayan iddiaları işaretliyor.

Kullanıcıya kaynak göstermek de dayanaklılığı artırıyor. Cevabın altında "bu bilgi şu belgeden geldi" diye kaynak sunduğunuzda, kullanıcı hem güven duyuyor hem de gerektiğinde doğrulayabiliyor. Kurumsal ortamda, özellikle hukuk, finans, sağlık gibi hata toleransı düşük alanlarda, kaynaksız bir RAG cevabı kabul edilebilir değil. Kaynak gösterimi bir lüks değil, bir üretim gerekliliği.

Her RAG kararının bir maliyet ve gecikme boyutu var. Reranker eklemek kaliteyi artırır ama gecikmeyi büyütür. Agentic RAG doğruluğu artırır ama çağrı sayısını katlar. Bu yüzden her müdahaleyi "ne kazandırıyor, ne kaybettiriyor" diye tartmak gerekiyor. Basit bir SSS botunda 2 saniyelik ek gecikme kabul edilemezken, karmaşık bir analitik asistanda 10 saniye bekleme tolere edilebilir. Sistem tasarımı, kullanıcı beklentisiyle teknik seçimleri buluşturma sanatı. Adaptif yönlendirmenin bu kadar değerli olmasının sebebi tam da bu: farklı sorulara farklı maliyet-gecikme profilleri sunarak, tek bir katı hattın dayattığı ödünleşmeden kurtarıyor.

Sonuçta üretime dayanıklı RAG, tek bir sihirli teknikten değil, doğru sırayla kurulmuş bir katmanlar bütününden doğuyor: sağlam chunking, hibrit arama, akıllı reranking, adaptif yönlendirme, erişim kontrolü, sürekli ölçüm ve gözlemlenebilirlik. Bu katmanları tek tek, ölçerek ve gerçek kullanım verisiyle besleyerek kurduğunuzda, demo'da parlayan RAG üretimde de ayakta kalıyor. En sık gördüğüm başarı örüntüsü basit: temelleri sağlam atan, karmaşıklığı ancak gerektiğinde ekleyen ve her adımı ölçen ekipler kazanıyor. RAG bir yarış değil, bir mühendislik disiplini; ve bu disiplini kuran ekip, kullanıcısının güvenini de kazanıyor.

Sahada tekrar tekrar gördüğüm hataları ve çözümlerini kısaca derleyeyim, çünkü bunları önceden bilmek aylarca zaman kazandırıyor.

Hata: Tek bir embedding modeline körü körüne güvenmek. Her embedding modeli her alanda iyi değildir. Hukuki metinlerde iyi olan bir model, tıbbi terminolojide zayıf kalabilir. Panzehir: kendi alanınızın örnekleriyle birkaç embedding modelini altın setiniz üzerinde kıyaslayın ve verinin karar vermesine izin verin.

Hata: Getirilen belge sayısını (top-k) sabit tutmak. Bazı sorular tek belgeyle cevaplanır, bazıları beş belge ister. Sabit bir top-k, ya gereksiz gürültü ekler ya da eksik bilgi bırakır. Panzehir: adaptif top-k, yani sorgu tipine göre getirilecek belge sayısını değiştirmek.

Hata: Güncelliği yok saymak. Bilgi tabanınız değişiyorsa, eski belgeler yanlış cevaplara yol açar. Panzehir: her chunk'a tarih metadata'sı ekleyip, getirimde güncellik ağırlığı uygulamak ve süresi geçmiş belgeleri elemek.

Hata: Değerlendirmeyi bir kez yapıp bırakmak. RAG, kullanıcı davranışı ve bilgi tabanı değiştikçe bozulur. Panzehir: değerlendirmeyi CI/CD hattına gömüp her değişiklikte otomatik çalıştırmak; tıpkı yazılım testleri gibi.

Hata: Kullanıcı geri bildirimini toplamamak. En değerli iyileştirme sinyali, gerçek kullanıcıların "bu cevap işe yaradı/yaramadı" geri bildirimi. Panzehir: her cevaba basit bir başparmak yukarı/aşağı koyup, olumsuz geri bildirimleri haftalık analiz etmek.

RAG sistemlerinin olgunluğunu dört seviyede düşünmek işe yarıyor. Seviye 1 — Naif RAG: tek vektör araması, sabit chunking, reranking yok. Demo için yeterli, üretim için kırılgan. Seviye 2 — Sağlam RAG: hibrit arama, anlamsal chunking, reranking, temel değerlendirme. Çoğu kurumsal senaryo için yeterli. Seviye 3 — Adaptif RAG: sorgu yönlendirme, adaptif top-k, gözlemlenebilirlik, erişim kontrolü, sürekli ölçüm. Yüksek hacimli üretim için ideal. Seviye 4 — Agentic/Grafik RAG: muhakeme güdümlü getirim, çok atlamalı sorular, grafik temsili. Yalnızca gerçekten karmaşık alan bilgisi gerektiğinde.

Bu modelin faydası, ekibe "şu an neredeyiz ve bir sonraki adım ne" sorusuna net cevap vermesi. Çoğu ekip Seviye 4'ün cazibesine kapılıp Seviye 2'yi atlıyor ve temeli sağlam olmayan bir gökdelen inşa etmeye çalışıyor. Oysa gerçek dünyada değer, çoğunlukla Seviye 2 ve 3'te üretiliyor. Seviye 4'e ancak iş gerçekten oraya ihtiyaç duyduğunda geçin; erken geçiş, karmaşıklık borcundan başka bir şey getirmez.

Nereden başlayacağınızı bilmiyorsanız, bugün tek bir şey yapın: 30 gerçek kullanıcı sorusu toplayıp her biri için doğru cevabı ve doğru kaynak belgesini yazın. Bu küçük altın set, RAG yolculuğunuzun pusulası olacak. Onunla mevcut sisteminizi ölçtüğünüzde, nerede kırıldığını hemen göreceksiniz; ve iyileştirmelerinizi tahminle değil, veriyle yönlendireceksiniz. RAG'i üretimde ayakta tutmanın sırrı karmaşık teknikler değil, ölçülebilir bir disiplin ve doğru sırayla atılan sağlam adımlardır.

Geçtiğimiz aylarda bir ekiple çalışırken tipik bir sahne yaşadık. Yönetime yaptıkları RAG demosu kusursuzdu; hazırladıkları on soruya sistem mükemmel cevap veriyordu. Ama pilot canlıya çıkınca memnuniyet çakıldı. Sebep basitti: demo soruları, ekip tarafından bilgi tabanındaki belgelere birebir uyacak şekilde seçilmişti. Gerçek kullanıcılar ise soruları kendi kelimeleriyle, eksik, dolaylı ve bazen yazım hatalı soruyordu. Semantik arama bu "gerçek dünya" sorgularında zorlandı; hibrit arama ve reranking olmadığı için doğru belge ilk beşe giremedi.

Çözüm, bu yazıda anlattığım katmanları sırayla eklemek oldu. Önce hibrit aramayı devreye aldık; özel isim ve ürün kodu içeren sorgular anında düzeldi. Sonra reranker ekledik; doğru belge tutarlı biçimde ilk beşe girmeye başladı. Ardından bir altın set kurup ölçmeye başladık; artık her değişikliğin etkisini görebiliyorduk. Son olarak adaptif yönlendirme ile basit soruları hafif hatta yönlendirip maliyeti düşürdük. Üç haftalık bu çalışmanın sonunda memnuniyet, pilot başındaki seviyenin çok üstüne çıktı. Hiçbir aşamada modeli değiştirmedik; sadece getirim katmanını mühendisçe kurduk.

Bu hikayenin dersi şu: RAG'de başarı, en gösterişli demoyu yapmakta değil, gerçek kullanıcıların dağınık sorularına dayanıklı bir getirim hattı kurmakta. Demo, kontrollü bir laboratuvar; üretim ise vahşi doğa. İkisi arasındaki köprü, bu yazıda anlattığım disiplin: ölç, katmanları sırayla ekle, gerçek veriyle besle. Bu köprüyü kuran ekipler, yapay zekayı bir gösteriden bir değere dönüştürüyor. Ve unutmayın: kullanıcı, arkadaki mimarinin ne kadar akıllı olduğuyla ilgilenmez; sadece sorduğu sorunun doğru cevaplanıp cevaplanmadığına bakar. RAG mühendisliğinin tüm amacı, o tek anı güvenilir kılmaktır.

Kısacası: getirim katmanını sağlamlaştırmadan model veya prompt peşinde koşmak, çatısı sağlam olmayan eve mobilya taşımaya benzer. Önce temeli kurun, ölçün, sonra süsleyin.