Üretimde RAG: Gerçek Müşteriler Soru Sormaya Başlayınca Ne Kırılır?

Çalışan bir RAG (Retrieval-Augmented Generation) demosunu bir öğleden sonrada kurabilirsiniz. Birkaç belgeyi gömün, bir vektör deposuna atın, kosinüs benzerliğine göre en iyi beş parçayı getirin, prompt'a yapıştırın. Sorulara cevap veriyor. Ekran kaydında sihir gibi görünüyor.

Sonra onu gerçek müşterilerin önüne koyuyorsunuz ve uçurum açılıyor.

Biri desteklediğiniz üçüncü dilde soru soruyor. Biri, kendi sitenizde iki farklı ve birbiriyle çelişen sürümü bulunan bir politikayı soruyor. Biri, içeriğinizin gerçekten kapsamadığı bir şeyi soruyor ve sistem yine de cevap veriyor: akıcı, kendinden emin ve yanlış. Yeniden tarama sürerken yirmi kişi aynı anda yazıyor. Taranarak (yazılarak değil) oluşturulmuş bir PDF, çevresindeki tüm cevapları sessizce zehirleyen bir getirim gürültüsüne dönüşüyor.

Bunların hiçbiri demoda görünmez; çünkü demoda temiz belgeler, tek bir dil, tek bir kullanıcı ve cevabını zaten bildiğiniz sorular vardır. RAG'in pahalı olan her yanı, bu iki durum arasındaki mesafede yaşar.

Bu rehber tam olarak o mesafeyi anlatıyor. RAG'in ne olduğunu bildiğinizi varsayıyor — bilmiyorsanız önce RAG chatbot nedir ve nasıl çalışır yazımızla başlayın, sonra buraya dönün. Devamı bir üst katman: bir getirim sisteminin gerçek kullanıcılarla temasında ayakta kalıp kalmayacağını belirleyen mühendislik.

Bağlam pencereleri her büyüdüğünde birileri RAG'in modasının geçtiğini ilan ediyor. Bu olmadı; nedenleri de geçici değil, yapısal.

Kullanılabilir bağlam, ilan edilen bağlamdan küçüktür. 200.000 token kabul eden bir model, bu 200.000 tokenin tamamında eşit kalitede akıl yürütmez. Etki iyi belgelenmiş durumda: Liu ve arkadaşlarının 2023 tarihli "Lost in the Middle" çalışması, uzun girdilerin ortasına gömülen bilgide doğruluğun düştüğünü gösterdi ve o günden bu yana çıkan her uzun bağlamlı model kuşağı benzer bir uyarıyla geldi. Kalite, sert sınıra varmadan önce bozulur. Üstelik orta ölçekli bir şirketin gerçek bilgi tabanı 200 sayfa değil, on binlerce sayfadır.

İnce ayar davranışı değiştirir, bilgiyi değil. Bu, alandaki en pahalı yanlış inanç. İnce ayar; bir modele biçim, üslup veya akıl yürütme kalıbı öğretmek için mükemmeldir. Olgu öğretmek için ise zayıf ve güvenilmez bir yoldur; olgular değiştiğinde de hızla bozulur — ki fiyatlarda, politikalarda ve stokta her hafta değişir.

Maliyet yanlış yöne ölçeklenir. Tüm külliyatı her isteğe doldurmak, her soruda tüm külliyatın parasını ödemek demektir. Getirim ise yalnızca ilgili birkaç bin tokenin parasını ödemektir. Gerçek mesaj hacminde bu fark, kârın tamamıdır.

Denetlenebilirlik bir özellik değil, zorunluluktur. Finansta, sağlıkta ve hukukta kaynağı izlenemeyen bir cevap kullanılamaz. Getirim bu izi bedavaya üretir; çünkü sistem her pasajın hangi belgeden geldiğini zaten bilir.

Dolayısıyla asıl soru artık "getirim yapılmalı mı" değil. Asıl soru, bu kadar çok getirim sisteminin bu işte neden kötü olduğu.

Kötü cevapların en yaygın nedeni model, gömme (embedding) veya vektör veritabanı değildir. İçerik yığınının kendisidir.

Bir müşterinin bilgi tabanında, belgelerin kabaca yarısının diğer yarısının neredeyse birebir kopyası olduğunu gördük: aynı politika, küçük biçim farklarıyla bir pazarlama sitesinde, bir yardım merkezinde ve arşivlenmiş bir PDF'te yeniden yayımlanmıştı. Getirim, görevini yaparak beş parça döndürüyordu — ama beşi de aynı paragrafın kopyasıydı. Model, beş farklı bakış açısı yerine tek bir dar kanıt dilimi görüyordu ve top-k bütçesi tekrara harcanıyordu. Bunu düzeltmek gösterişsiz, elle yapılan veri hattı işiydi. Yine de o ay yaptığımız tüm getirim ayarlarından daha çok cevap kalitesi kazandırdı.

Sürekli tekrar eden suçlular:

• Taranmış PDF'ler ve OCR hasarı. İnsan gözüne düzgün görünen metin yapısal olarak paramparça olabilir: sütun sırası karışır, tablolar kelime çorbasına dönüşür. Parçalanmış metnin gömmeleri öngörülemez biçimde getirilir.
• Şablon metinler ve çerez bantları. Bir siteyi naif biçimde tarayın; her sayfa aynı çerez bildirimini, menüyü ve alt bilgiyi taşır. Böylece her parça büyük ve birebir aynı bir önek paylaşır, alakasız sayfalar arasındaki anlamsal benzerlik yükselir. Bu yüzden tarayıcımız, hiçbir şey dizine eklenmeden önce çerez bantlarını ve sayfa çerçevesini ayıklar.
• Giriş duvarları ve içi boş sayfalar. Bir oturum açma sayfasında da metin vardır, dolayısıyla naif bir hat onu da yutar. Hiçbir şey katmaz, her şeyi seyreltir.
• Kimsenin fark etmediği çelişkiler. İki sayfa farklı iade süresi yazar. Getirim ikisini de bulur. Model birini seçer. Hangisini seçerse seçsin, birine yanlış bilgi verilecektir.

Pratik kural: kalite kapısı dizine eklemeden önce, kod tabanınızda tek bir yerde durmalı ve içerik ekleyebilen her yol bu kapıdan geçmelidir. İçe alma kuralları üç ayrı yerde yaşadığında zamanla birbirinden ayrışır; kurulum akışınız ile yeniden taramanız arasındaki kalite farkı da kimsenin yeniden üretemediği bir muammaya dönüşür. Bunun uygulamalı hali için temiz bir chatbot bilgi tabanı kurma rehberimize bakın.

Tek bir yoğun (dense) vektör araması, getirimin ilk taslağıdır. Üretimdeki getirim; dört-beş ayrı aşamadan oluşan bir hattır ve her aşama, diğerlerinin gideremediği bir arıza türünü giderir.

Sorgu genişletme. Gerçek kullanıcı sorguları kısadır, yazım hatalıdır ve şirket içi kısaltmalarla doludur. Sorguyu gömmeden önce eş anlamlılarla ve açılmış kısaltmalarla genişletmek, geri çağırmayı ölçülebilir biçimde artırır — özellikle gerçek sohbet trafiğine hâkim olan iki-üç kelimelik sorularda.

Hibrit arama: yoğun + seyrek. Yoğun gömmeler anlamı yakalar ama tam eşleşmeleri kaçırır: stok kodları, hata kodları, model numaraları, soyadları. Anahtar kelime araması (bizde Postgres tsvector üzerinde BM25) bunları tam isabetle bulur, buna karşılık başka sözcüklerle ifade edilmiş soruları kaçırır. İkisini birden çalıştırıp sonuçları Reciprocal Rank Fusion (RRF) ile birleştirmek bir iyileştirme değil, üretimin varsayılanıdır.

Hak ettiğinden daha az konuşulan bir ayrıntı: anahtar kelime araması dile bağlıdır. Postgres, metnin İngilizce olduğunu söylerseniz "prices" kelimesini "price" köküne indirir. Türkçe, Almanca, İspanyolca, Fransızca, İtalyanca ve Portekizce'nin her biri kendi yapılandırmasını ister; yerleşik kök bulucusu olmayan diller — Japonca, Korece, Çince — ise kazara değil, bilinçli bir geri düşüş stratejisi ister. Her sorguyu İngilizce gibi köklendiren çok dilli bir RAG sistemi, diğer tüm dillerde sessizce geri çağırma kaybeder. Birden fazla pazara hizmet ediyorsanız bu bölümün yanında çok dilli chatbot rehberimizi de okuyun.

Yeniden sıralama (rerank). Birleştirme size yirmi-otuz makul aday verir. Bir cross-encoder yeniden sıralayıcı her adayı asıl sorguya karşı puanlar ve gerçekten doğru olan pasajı 15. sıradan ilk 3'e taşımayı alışkanlık hâline getirir. Sisteminiz "sürekli neredeyse doğru olan bir sayfayı gösteriyorsa", ilk bakılacak yer eksik yeniden sıralama aşamasıdır.

Önbellek, ama dikkatli. Aynı sorular hattın tamamını yeniden çalıştırmamalı. Ancak önbelleğe getirim sonucunu alın (sorgu + top-k anahtarıyla), üretilen cevabı değil — yoksa altındaki belge güncellendikten sonra bayat bir yanıt servis edersiniz.

Ciddi her RAG sistemi, üretimden önce getirimini puanlar ve bu puanı modele "bu bağlama ne kadar güven" talimatı vermek için kullanır: doğrudan cevapla, çekinceyle cevapla ya da cevaplama ve insana aktar. Bu, elimizdeki en önemli halüsinasyon savunmasıdır.

Aynı zamanda yanlış ayarlanmış olma ihtimali en yüksek parametredir; çünkü varsayılanlar genelde ölçülmez, uydurulur.

İşte ders çıkarmaya değer bir hata — bize ait. "Yüksek güven" eşiğimiz 0,82 kosinüs benzerliğine ayarlıydı; kulağa gayet titiz geliyor. Sonra bunu canlı trafiğe karşı ölçtük ve gerçek yanıtların %2'sinden azının bu eşiği geçtiğini gördük. Yoğun anlamsal eşleşmeler, getirilen pasaj apaçık ve tam isabetli olduğunda bile nadiren 0,80 civarını aşar. Yani model neredeyse her soruda "bu bağlam yalnızca kısmi" bilgisini alıyordu ve çekiniyordu: doğru cevaplar, gereksiz bir belirsizliğe sarılıyordu. Getirim gayet iyiydi. Bozuk olan cetveldi.

Çözüm her şeyi gevşetmek değildi. Belirsiz banttaki gerçek konuşmalardan bir örneklem çekip okuduk: 0,64-0,68 aralığında cevaplar somut ve doğruydu; tam plan limitlerini ve tam politika kurallarını alıntılıyordu. Ancak gerçek boşluklar — desteklemediğimiz bir entegrasyona dair sorular — aynı aralıkta puanlanıyor ve doğru biçimde çekinceli davranıyordu. Bu yüzden yüksek eşiği gerçek eşleşmelerin ulaşabileceği bir seviyeye çektik, belirsiz orta bandı "kısmi" olarak bıraktık ve en alttaki "uydurma" korumasını olduğu yerde tuttuk.

Devredilebilir dersler: eşikleri sezgiye göre değil, kendi dağılımınıza göre kalibre edin; ayar yaptığınız bantta gerçek konuşmaları okuyun, çünkü toplu puanlar iyi bir cevap ile yüksek puan almış bir ıskayı birbirinden gizler; ve her eşiği bir ortam değişkeni yapın ki hatalı bir kalibrasyon, deploy gerektiren bir kriz değil, bir dakikalık geri alma olsun.

Parçalama (chunking) bir biçimlendirme kararı gibi görünür. Oysa bir getirim kararıdır ve "dokümanlarımızda kesinlikle var olan bir şeyi bot bulamıyor" şikâyetlerinin şaşırtıcı bir kısmı buradan doğar.

Örneğin her 500 tokende bir sabit uzunlukta bölmek; bir tabloyu ikiye keser, bir başlığı tanıttığı paragraftan koparır ve numaralı bir prosedürü iki parçaya bölerek hiçbirini tek başına kullanılamaz hâle getirir. Yapı farkında bölme — önce başlıklara ve paragraf sınırlarına saygı gösterip sonra hedef boyuta doğru birleştirmek, uzun bölümleri de cümle sınırlarından kesmek — bir günlük iştir ve kendini anında amorti eder. Kendi hattımız parça başına yaklaşık 800 token ve 200 token örtüşme hedefler; düz metin ağırlıklı kurumsal içerik için makul bir başlangıç noktasıdır.

Daha ince sorun şu: bir parça yalıtıldığı anda, onu anlamlı kılan bağlamı kaybeder. "Standart teslimat 3-5 iş günü sürer" cümlesi, parçada kimin teslimatı, hangi bölge ve hangi ürün hattı yazmıyorsa işe yaramaz bir getirim hedefidir. Tek başına getirildiğinde model onu bambaşka bir soruya uygulayabilir.

Çözüm, her parçayı gömmeden önce kendi künyesiyle zenginleştirmektir: belge başlığı, bölüm başlığı, kaynak. Böylece gömülen metin, insan okurun sayfanın tamamından edineceği bağlamı da taşır. Anthropic bunun bir sürümünü "contextual retrieval" adıyla yaygınlaştırdı ve getirim hatalarında ciddi bir düşüş bildirdi. Değerli olması için bir LLM geçişi de gerekmez: belgenin kendi üst verisinden kurulan deterministik bir önek, faydanın büyük kısmını sıfır marjinal maliyetle yakalar — üretimde çalıştırdığımız da budur.

Deneyimden bir uyarı: parçalama veya bağlamlandırma stratejinizi değiştirirseniz bir göç (migration) işini de üstlenmiş olursunuz. Mevcut her parça eski şemayla gömülmüştür. Belge bazında, hedefli bir yeniden dizinleme planlayın — canlı bir külliyatı asla körlemesine toptan yeniden gömmeyin.

Ekipler getirim kalitesini tartışır. Sistemleri asıl düşüren ise dayanıklılıktır.

İçe alma; uzun süren, çok aşamalı ve kısmen dışa bağımlı bir süreçtir: getir, çıkar, parçala, göm (hız sınırına takılabilen ücretli bir API çağrısı), yaz, tamamlandı olarak işaretle. Ağ sınırının ötesinde dakikalarca çalışan her şey kesintiye uğrar ve bu kesintiler nadir değildir.

En öğretici arızamız sessizdi. Bir kullanıcı site taraması başlattı, sonra sayfadan ayrıldı. İsteğini yürüten sunucusuz fonksiyon iş ortasında öldürüldü — parçalar ve gömmeler yazıldıktan sonra, ama belge "işlendi" olarak işaretlenmeden önce. İstisna yok. İzlemede hata yok. Yalnızca tamamen dizine eklenmiş olduğu hâlde kalıcı olarak "indeksleniyor" görünen bir belge ve bir rozetin değişmesi için aynı siteyi 19 saat içinde dört kez yeniden tarayıp sonunda giden bir kullanıcı.

Bu arıza sınıfı, çalmaya değer üç değişmez öğretti:

• Yazma sırasını, kullanıcıya görünen gerçek önce yazılacak şekilde kurun. İçerik kalıcı olarak yazıldıktan hemen sonra "işlendi" bayrağını çevirin; istatistikleri, önbellek geçersizleştirmeyi ve diğer defter tutma işlerini sonraya bırakın — her biri süreli ve en iyi çaba. Gerçek iş ile onu kaydeden bayrak arasına asla isteğe bağlı bir adım koymayın.
• Her iş işleyicisini idempotent yapın, sonra cömertçe yeniden kuyruğa alın. Bir işçi iş ortasında ölürse, bir sonraki tarama işin tamamını güvenle yeniden çalıştırabilmelidir. "Önce sil, sonra ekle" tarzı işleyiciler yeniden denemeyi bedava kılar.
• Kendi kendini onaran bir süpürge ekleyin. Yarım kalmış durumda takılı belgeleri arayıp yeniden kuyruğa alan periyodik bir iş, kalıcı ve kullanıcıya görünen bir arızayı birkaç dakikalık gecikmeye dönüştürür. Bir RAG hattında getirisi en yüksek dayanıklılık işi budur ve neredeyse hiç kimse canı yanmadan önce bunu inşa etmez.

Eşzamanlı yük altında sıkıcı altyapıyı da ekleyin: ateşle-unut vaatler yerine gerçek bir kuyruk, gömme çağrılarının bağlantıları açık tuttuğunu hesaba katan bağlantı havuzu limitleri ve bir müşterinin 900 sayfalık taramasının diğer herkesin canlı sohbetini aç bırakmasını önleyen kiracı bazlı yalıtım.

RAG kalitesi göz kararı ölçülemez. Her ekip ölçebileceğine inanır ve her ekip yanılır; çünkü kötü bir RAG sisteminin arıza biçimi akıcı, makul ve düzgün biçimlendirilmiş ama yanlış olan bir cevaptır. Tıpkı iyi bir cevap gibi okunur.

Asgari uygulanabilir değerlendirme kurulumu, korkulduğu kadar büyük değildir:

Altın küme. Doğru cevabı bilinen, uydurma değil gerçek destek geçmişinizden alınmış 30-100 soru. Getirimde, parçalamada, prompt'larda veya model sürümünde her değişiklikten sonra yeniden çalıştırın. Bu bir regresyon testidir ve sesli biçimde başarısız olmalıdır.

Getirim puanı ile cevap puanını ayırın. Kalite düştüğünde, doğru pasajın hiç getirilmediğini mi yoksa getirilip göz ardı mı edildiğini bilmeniz gerekir. Bunların çözümleri tamamen farklıdır ve tek bir uçtan uca puan ikisini ayırt edemez.

Güven dağılımını zaman içinde izleyin. Getirim puanlarının histogramındaki kayma erken bir uyarıdır — genellikle biri toplu hâlde düşük kaliteli içerik eklemiştir ya da trafik, külliyatınızın kapsamadığı konulara kaymıştır.

"Bilmiyorum" cevabını en değerli telemetriniz sayın. Her düşük güvenli cevap ve her insana aktarma, etiketlenmiş bir içerik boşluğudur. Asistanları aylar içinde gözle görülür biçimde iyileşen ekipler, neredeyse istisnasız, bu listeyi haftalık okuyup eksik sayfayı yazan ekiplerdir. Chatbot analitiği rehberimiz izlemeye değer metrikleri anlatıyor.

Bir de saptırma oranını dürüstçe ölçün. Bir konuşma, müşteri yazmayı bıraktı diye çözülmüş olmaz; bir saat sonra size e-posta atmadıysa çözülmüştür. Platformunuz bu iki olayı birbirine bağlayamıyorsa, sizi pohpohlayan bir sayıyı optimize ediyorsunuz demektir.

Mimarisi birebir aynı iki RAG sistemi, aynı sektörde biri başarılı biri başarısız olabilir. Fark genellikle hattın içinde değildir.

Alanın dili gerçek bir iştir. Sağlıktaki kısaltmalar, finansal ürün adları, hukuki atıf biçimleri ve stok kodu gelenekleri, genel amaçlı getirimi kendine özgü biçimlerde kırar. Bir finans müşterisi "3 yıllık" diye sorar ve belirli bir ürünü kasteder; genel bir gömme ise zamanı düşünür. Bunun çaresi daha büyük bir model değil; eş anlamlı sözlükleri, üst veri filtreleri ve insan kadar makine için de yazılmış içeriktir.

Kapsam disiplini, yetenekten önemlidir. Bir asistana duyulan güveni yok etmenin en hızlı yolu, gerçekten bilmediği konularda cevap vermesine izin vermektir. Açık bir sınır — bu asistan ürünlerimiz, politikalarımız ve dokümantasyonumuz hakkında cevap verir, gerisini insana aktarır — utandırıcı cevapları herhangi bir getirim iyileştirmesinden daha fazla azaltır. Gerçek asistanların genel geçer ve faydasız bir alana savrulduğunu gördükten sonra bizim de devreye aldığımız çözüm buydu.

Benimseme bir yayın koşuludur. Destek ekibine haber verilmemiş bir asistanın altını yine destek ekibi oyar. İçerik boşluklarının sahibi olan, aktarmaları okuyan ve asistanın ne vaat edebileceğine karar veren biri olmalıdır.

Kurumsal güvenin bir kontrol listesi vardır. Getirimin kimin sorduğuna saygı göstermesi için rol tabanlı erişim, hangi kaynağın hangi cevabı ürettiğini gösteren denetim izleri, net veri yerleşimi, saklama kontrolleri ve müşteri konuşmalarının halka açık modelleri eğitmek için kullanılmadığına dair tartışmasız bir beyan. Bunlar güvenlik incelemesinden sonra eklenen özellikler değildir; incelemenin geçilip geçilmemesinin sebebidir. Chatbot güvenliği ve gizliliği rehberimiz bir tedarikçide neyin doğrulanacağını tek tek anlatıyor.

Bunu şirket içinde inşa ediyorsanız, dürüst kapsam "bir vektör veritabanı ve bir prompt" değildir. Bir içerik kalite kapısı, çok aşamalı bir getirim hattı, kalibre edilmiş güven eşikleri, idempotent işleyicileri ve kendi kendini onaran süpürgesi olan bir iş kuyruğu, bir değerlendirme koşumu ve bir analitik döngüsü — artı hepsinin sürekli operasyon yükü. Getirim kalitesi ürününüzün kendisiyse bunu yapmaya değer. Getirim yalnızca müşteri sorularını cevaplamanın aracıysa, küçük bir ekibin bir yılını buna harcamak kötü bir tercihtir.

Satın alıyorsanız, bu yazıdaki kontrol listesi sizin durum tespiti listeniz olur. Tedarikçiye sorun: Hibrit getirim mi kullanıyorsunuz, yalnızca yoğun mu? Yeniden sıralama aşaması var mı? "Bilmiyorum" eşiği nasıl belirleniyor ve ben değiştirebiliyor muyum? İçe alma yarıda kesilirse belgeye ne olur? Belirli bir cevabı hangi kaynağın ürettiğini görebilir miyim? Benim dilimde anahtar kelime aramasına ne oluyor? Asistan geçen hafta hangi soruları cevaplayamadı? Bunları cevaplayamayan bir tedarikçi bir demo inşa etmiştir.

Chatloom tam olarak bu katmanın sahibi olmak için var. Yazı boyunca anlatılan hat — bağlamsal zenginleştirmeli, yapı farkında parçalama; sorgu genişletme; dil farkında köklendirmeyle yoğun + seyrek hibrit getirim; RRF birleştirme; cross-encoder yeniden sıralama; gerçek bir "bilmiyorum" içeren kalibre edilmiş güven; kendi kendini onaran süpürgesiyle idempotent içe alma işleri ve hangi soruların cevapsız kaldığını tam olarak gösteren bir panel — platformdaki her asistanın arkasında, on dilde ve sizin tarafınızda bir ML ekibi olmadan çalışan şeydir.

Bugün kendi içeriğinizde deneyin. Ücretsiz hesap oluşturun, site adresinizi yapıştırın ve tüm döngünün — tarama, kalite kapısı, parçalama, gömme, hibrit getirim — bu yazıyı okuduğunuz süreye yakın bir sürede işlediğini görün. Müşterilerinizin gerçekten sorduğu beş soruyu sorun. Cevaplar içeriğinize dayanıyorsa ve bilmediğini itiraf ediyorsa, değerlendirmenizi yapmış olursunuz. Ücretsiz planda kart gerekmez.

Önce ayrıntı mı istiyorsunuz? RAG motorumuzun nasıl çalıştığına bakın ya da uygulamalı kardeş yazımızı okuyun: asistanı kendi verinizle eğitmek.