Bu, RAG mi İnce Ayar mı Sorusundan Farklı Bir Soru

Sürekli birbirine karıştırılan ve yanlışını cevaplamak aylar kaybettiren iki ayrı mimari soru var. Birincisi bilginin nerede duracağıdır: eğitimle model ağırlıklarına işlenmiş mi olsun, yoksa modelin dışında bir indekste mi tutulsun. Bu, eğitim mi retrieval mı sorusudur ve onu RAG mi ince ayar mı yazısında ayrıca ele aldık; hâlâ canlı bir sorudur ve cevabı çok da değişmedi. İkinci soru daha yenidir ve bu yazının konusu odur: bilgi zaten modelin dışında duruyorsa, modele promptun içinde mi ulaşsın, yoksa bir retrieval adımıyla mı? Bu iki soruyu birbirinden ayırmadan işe başlayan projeler, çoğu zaman doğru cevabı yanlış probleme veren bir mimariyle sonuçlanır.

Üç yıl önce bu ikinci soru pratikte var değildi, çünkü bağlam pencereleri cevabı zorunlu kılacak kadar küçüktü. Bir korpusu prompta yapıştıramazdınız, dolayısıyla retrieval kurardınız ve tek tartışma parça boyutları üzerineydi. O günden bu yana pencereler iki ila üç büyüklük mertebesi büyüdü ve uzun bağlamda hatırlama başarısı da belirgin biçimde iyileşti. Bu da ilk kez gerçekten seçim yapabileceğiniz anlamına geliyor. Eskiden bir hat kurmayı zorunlu kılan pek çok belge artık tek bir isteğe rahatça sığıyor ve üstüne yer bile kalıyor. Yani soru artık teknik bir zorunluluk olmaktan çıkıp bilinçli bir mühendislik tercihine dönüştü ve tercihin bedeli de artık sizin üzerinizde.

Birçok kişinin buradan çıkardığı sonuç retrieval'ın miadını doldurduğuydu. Doldurmadı ve gerekçelerin model yeteneğiyle neredeyse hiç ilgisi yok. Gerekçeler; bir kere değil her istekte ölçeklenen maliyetle, bir promptun ifade edemeyeceği erişim kontrolüyle, bir denetçinin isteyeceği kaynak gösterimiyle ve hiçbir pencerenin alamayacağı büyüklükteki korpuslarla ilgili. Aşağıdaki karşılaştırma bir mühendisin yapması gerektiği biçimde kurulmuştur: ne değişti, ne değişmedi, her yaklaşım gerçekten nerede kazanır ve üretim sistemlerinin zaten er geç vardığı hibrit yapı nedir. Aşağıda bir mimari tarafı savunmak yerine karar değişkenlerini tek tek ele alıyoruz; amaç bir yaklaşımı kazandırmak değil, hangi koşulda hangisinin kazandığını sayılarla göstermektir.

Uzun Bağlamda (long context) Gerçekten Ne Değişti

Gerçekten değişen iki şey var. Bağlam pencereleri büyüklük mertebeleriyle ölçülecek kadar genişledi ve bu, geniş bir belge sınıfını imkânsızdan sıradana taşıdı. Bir de uzun bağlamda hatırlama iyileşti: bugünün modelleri, uzun bir girdinin derinlerindeki bilgiyi önceki kuşaklardan belirgin biçimde daha iyi kullanıyor. Büyük bir belgeyi yapıştırıp soru sormaktan ibaret o naif testin eskiden başarısız olurken bugün genellikle çalışmasının nedeni budur. Uzun bağlama dair zihinsel modeliniz eski bir model kuşağından kalmışsa güncelliğini yitirmiştir; yaklaşımı elemeden önce kendi testinizi yeniden koşturun. Bu testi kendi belgelerinizle ve kendi soru dağılımınızla yapmak, herhangi bir kıyaslama tablosuna bakmaktan çok daha bilgilendiricidir.

Hiç değişmeyen iki şey var ve ikisi de yetenekle değil ekonomiyle ilgili. Birincisi, maliyet gönderdiğiniz şeyle ölçeklenir. Promptunuzdaki her token, her istekte, süresiz olarak ödediğiniz bir tokendır. Bir retrieval indeksi veri yükleme sırasında bir kez ödenir ve sonra ucuza sorgulanır; uzun bağlam promptu ise biri her soru sorduğunda yeniden ödenir. İkincisi, gecikme de girdi uzunluğuyla ölçeklenir. Prefill gerçek bir iştir ve ilk token süresi girdi boyutuyla birlikte büyür; aynı sorunun küçük bir promptta anında, çok büyük bir promptta ise gözle görülür biçimde yavaş hissettirmesinin sebebi budur. Bu iki kalem, hangi mimariyi seçerseniz seçin her faturada karşınıza çıkar.

Dolayısıyla dürüst özet şu: uzun bağlam bir yetenek kısıtını kaldırdı ve operasyonel kısıtları tam olarak bulduğu yerde bıraktı. Bu gerçekten önemli bir değişim, çünkü retrieval'ın artık modelin metni kaldıramayacağı gerekçesiyle savunulması gerekmiyor. Onun yerine maliyet, izinler, tazelik ve denetlenebilirlik üzerinden savunulması gerekiyor; bu da çok daha somut ve bir finans ya da uyum paydaşıyla yürütmesi çok daha kolay bir konuşmadır. Bu dört değişken yerine mimari modasına bakarak karar vermek, ekiplerin ya ihtiyaç duymadıkları bir hat kurmasıyla ya da modellemedikleri bir faturayla karşılaşmasıyla sonuçlanır. Karar bir moda meselesi değil, dört değişkenli bir hesap işidir ve hesabı yapmak birkaç saat sürer.

Bağlam Çürümesi (context rot) ve Konum Etkileri

Uygulamacıların context rot dediği, Türkçede bağlam çürümesi diye karşılayabileceğimiz, iyi belgelenmiş bir davranış var: bağlam miktarı büyüdükçe modelin bağlamı etkili kullanımı, pencere o uzunluğu nominal olarak desteklese bile geriler. Bu, modelin bir bilgiyi bulamaması demek değildir. Daha ince ve üretimde daha yıkıcıdır: cevaplar muğlaklaşır, daha çok çekince koyar, koşulları düşürür ve farklı belgelerden gelen ayrıntıları birbirine karıştırır. Sistem hata bildirmez. Biraz daha kötü bir cevap bildirir ki bu tam olarak yüzeysel testten sağ çıkan ve aylar sonra kullanıcı şikâyeti olarak geri dönen başarısızlık biçimidir. Bu yüzden uzun bağlam testlerini yüzeysel örneklerle değil, gerçek soru dağılımıyla yapmak gerekir.

Konum etkileri bunu katmerlendirir. Uzun bir girdinin başına ve sonuna yerleştirilen bilgi, ortada duran bilgiye kıyasla daha güvenilir biçimde dikkate alınır. Pratikte bu, bir şeyi dahil edip etmediğiniz kadar nereye koyduğunuzun da önemli olduğu anlamına gelir ki bu, büyük pencerenin prompt yapısını düşünmeyi bırakmak demek olduğunu sanan herkes için rahatsız edici bir özelliktir. İki yüz sayfalık bir yığının ortasına gömülmüş kritik bir sözleşme maddesinin cevabı belirleme ihtimali, aynı maddenin getirilip kısa bir promptun tepesine konmasına kıyasla belirgin biçimde düşüktür. Pencerenin büyümesi, promptun neresine ne koyduğunuzu düşünme yükümlülüğünü ortadan kaldırmadı; yalnızca o yükümlülüğü daha az görünür hâle getirdi.

Bir de dikkat dağıtıcılar var. Soruyla konu bakımından benzeşen ama alakasız içerik arka planda zararsızca durmaz; cevabı aktif olarak kendine çeker. Daha fazla bağlam tekdüze biçimde daha iyi değildir ve bu, tüm karşılaştırmadaki en sezgi karşıtı gerçektir. Operasyonel sinyali, aramayı bildiğinizde tanımak kolaydır: belge ekledikçe cevaplar keskinleşeceğine muğlaklaşır. Sığan bir pencerenin içinde bile seçmek yığmaya üstündür; disiplinli bağlam mühendisliğinin pencereler büyüdüğünde önemini yitirmemesinin nedeni de budur. Aksine, çalışan bir sistemle yalnızca ayakta duran bir sistemi ayıran şey hâline geldi. Pratikte bu, gönderdiğiniz parça sayısını artırmadan önce isabeti ölçmeniz gerektiği anlamına gelir; aksi hâlde daha fazla bağlam eklerken kaliteyi düşürdüğünüzü fark etmezsiniz.

Dürüst Maliyet Karşılaştırması

İki yaklaşımı hiçbirine sadakat duymadan yan yana koyun. Retrieval'ın peşin bir maliyeti vardır: korpusun embedding'ini çıkarmak, vektörleri saklamak, altyapıyı çalıştırmak ve belgeler değiştikçe eklenen artımlı maliyet. Ardından sorgu başına küçük bir marjinal maliyeti vardır; tipik olarak bir embedding çağrısı ve bir arama, birlikte 20 ila 150 milisaniye aralığında koşar ve token cinsinden yuvarlama hatası kadar tutar. Uzun bağlamın ise hiç peşin maliyeti yoktur, ki bu gerçekten cazip, ama sorgu başına marjinal maliyeti korpusun tamamını her seferinde ve her kullanıcı için göndermeye eşittir. İki tarafın maliyet yapısı temelden farklıdır: biri sermaye harcamasına, diğeri işletme giderine benzer.

Kesişim aritmetiği basittir. Bir korpusu indekslemek tek seferlik bir tutar, göndermek ise istek başına bir tutar ediyorsa, iki yaklaşım birincinin ikinciye bölümüne eşit sayıda istekten sonra başa baş gelir. İndeksleme tek seferlik ve gelecekteki tüm sorgulara yayılan bir maliyetken gönderme sorgu ve kullanıcı başına ödendiği için, bu başa baş sayısı kayda değer herhangi bir korpus için küçüktür. Modellediğimiz sistemlerde onlarla düşük yüzler arasında bir yere düşüyor. Bir avuç kişiden fazlasının kullanacağı her iş yükü bu eşiği ilk hafta içinde geçer. Bu hesabı bir tabloya dökmek yarım saat sürer ve mimari kararı tartışma olmaktan çıkarıp ölçüme bağlar.

İnsanların kaçırdığı çarpan eşzamanlılıktır. Uzun bağlam promptuna aynı soruyu soran on kullanıcı, aynı tokenları on kez öder. Bir indeksi sorgulayan on kullanıcı, bir kez yapılmış bir işin üzerine on ucuz arama öder. Bunu günde bin kişinin kullandığı bir destek aracıyla çarpın; fark bir optimizasyon olmaktan çıkar, ürünün ekonomisinin tamamı hâline gelir. İş akışı başına maliyet modeli kuruyorsanız bu, tam da model yönlendirme ve maliyet kontrolü konusunda karşınıza çıkan türden bir karardır ve mimari seçilmeden önce modellenmelidir, sonradan keşfedilmemelidir. Eşzamanlılık çarpanını modeline koymayan her maliyet tahmini, ürün büyüdükçe hızla anlamsızlaşır ve bunu genellikle ilk fark eden ekip değil finans olur.

Uzun Bağlamın Gerçekten Kazandığı Yerler

En net kazanç tek ve sınırlı bir belgedir. Bir sözleşme, bir mevzuat bildirimi, bir toplantı dökümü, bir teknik şartname, bir kod tabanı modülü. Bütün metin sığıyorsa ve soru o metin hakkındaysa, retrieval hattı kurmak mimari tiyatrodan ibarettir. Parçalama, embedding ve değerlendirmeye üç hafta harcayıp belgeyi doğrudan yapıştırmaktan daha kötü bir şey üretirsiniz; çünkü retrieval, modelin bütün olarak okuyabileceği bir belgeyi zorunlu olarak parçalar. Bu konudaki duruşumuz açık: tek bir PDF hakkında soru cevaplamak için RAG kurmayın. Aynı belgeyi ikinci kez sorgulamayacaksanız kurduğunuz hattın amortismanı hiçbir zaman gerçekleşmez; harcanan üç hafta doğrudan zarar yazılır.

İkinci kazanç, yeniden kullanımı olmayan tek seferlik analizdir. Tek bir satın alma hedefinde durum tespiti, tek bir dava dosyası üzerine hukuki görüş, tek bir yılın kayıtlarının denetimi. Belirleyici özellik, korpusun birkaç kez sorgulanıp bir daha hiç kullanılmayacak olmasıdır; bu da sizi başa baş hesabının yanlış tarafına düşürür. Üçüncüsü prototiplemedir ve en sık önerdiğimiz kullanım budur. Herhangi bir hat kurmadan önce, bir örneklem üzerinde uzun bağlamla çalışarak görevin mümkün olduğunu kanıtlayın. Model, belgeler doğrudan eline verildiğinde görevi yapamıyorsa retrieval onu kurtarmayacaktır. Prototip aşamasında uzun bağlam, altyapı kurmadan önce riski en ucuz biçimde eleyen araçtır.

Dördüncü kazanç bir ölçek değil bir kategoridir: bütünsel yapı gerektiren sorular. Bu belgenin tamamını özetle. Bu maddeler arasındaki tüm tutarsızlıkları bul. Bu argümanın nasıl geliştiğini izle. Bir şablona kıyasla neyin eksik olduğunu belirle. Retrieval bu soruları yapısı gereği parçalar, çünkü en iyi sonuçları bütünü içerecek bir sorgu yoktur. Metnin tamamını okuyan bir modelin, hiçbir retrieval yapılandırmasının yeniden üretemeyeceği bir avantajı vardır ve bunu giderek büyüyen bir top-k ile taklit etmeye çalışmak, hâlâ kısmi cevap veren yavaş ve pahalı bir sisteme çıkan çok bilinen bir yoldur. Bu tür sorularda doğru hamle top-k değerini büyütmek değil, belgeyi bütün olarak göndermektir.

Retrieval'ın Kazandığı Yerler

İlk ve en yaygın neden basitçe büyüklüktür. Kurumsal korpuslar bağlam penceresi problemi değildir. Yürüttüğümüz pilotlar tipik olarak 50.000 ila 200.000 belgeyle başlar ve ardından gelen üretim sistemleri daha da büyüktür, büyümeye devam eder ve var olacak hiçbir pencereye sığmayacaktır. Korpus pencereyi aştığı anda soru mimari tercih olmaktan çıkıp aritmetiğe dönüşür. Bu listedeki bundan sonraki her madde, korpus sığsa bile retrieval'ın neden kazandığını anlatıyor ki asıl ilginç durum da odur. Pratikte kurumsal bir korpus yalnızca büyük değil, sürekli büyüyen bir hedeftir; bugün sığan bir koleksiyon on sekiz ay sonra sığmayabilir ve mimariyi o noktada değiştirmek en pahalı senaryodur.

Bu nedenlerin en güçlüsü erişim kontrolüdür. Bir promptun izin modeli yoktur. Aynı korpus üzerinde on kullanıcının on farklı yetkisi varsa bunu bir promptta ifade edemezsiniz; her yetki kümesi için ayrı bir prompt gerekir ki bu, fazladan adımlarla ve daha kötü ergonomiyle yapılmış retrieval demektir. Retrieval, belge düzeyindeki izinleri sorgu anında uygulanan bir filtreye taşır ve güvenlik incelemesinden sağ çıkan tek tasarım budur. Tazelik ikinci nedendir: bir belge değiştiğinde indeks artımlı güncellenir, uzun bağlam promptu ise baştan kurulur ve günlük değişen bir korpusta bu fark operasyonel maliyetin tamamıdır. Bu iki neden tek başına kurumsal vakaların çoğunu belirlemeye yeter.

Sonra kaynak gösterimi ve denetlenebilirlik gelir. Retrieval size köken bilgisini neredeyse bedavaya verir: bu cevap şu belgenin şu sürümünün şu parçasından geldi, en son şu tarihte değişti. Uzun bağlam ise bir kaynaktan söz eden bir cevap verir ki bu aynı şey değildir ve programatik olarak doğrulanamaz. Düzenlemeye tabi Türkiye kurulumlarında bunun somut karşılığı vardır; 6698 sayılı Kanun'un 12. maddesi veri sorumlusuna veri güvenliği yükümlülüğü yükler ve ciddi her denetim hangi kaydın hangi kararı beslediğini sorar. Bu cevabın yaşadığı yer vektör veritabanıdır ve yukarıda anlatılan hacimdeki maliyet de bunun üstüne gelen dördüncü nedendir.

Neredeyse Herkesin Yakınsadığı Hibrit Yapı

Pencere genişlemesinden sonra kurulan üretim sistemleri seçim yapmıyor. Retrieval yapıyor ve sonra gönderdikleri konusunda cömert davranıyorlar. Üç yüz tokenlık üç parça döndürme disiplini, bağlam kıt ve pahalı olduğu için vardı; o kıtlık ortadan kalktı ve bugün işe yarayan yapılandırmalar tamamen farklı görünüyor. Büyüyen pencereler retrieval'ı gereksiz kılmadı. Retrieval'ı daha iyi hâle getirdiler, çünkü tam da isabetin en çok önem taşıdığı anda onu cimri olmaya zorlayan kısıtı ortadan kaldırdılar. Kısacası asıl soru hangisini seçeceğiniz değil, retrieval'ın modele ne kadar cömert bir bağlam vermesi gerektiğidir; ve bu sorunun cevabı önyargıyla değil ölçümle bulunur.

Sık kurduğumuz bir yapılandırma şöyle görünüyor. Sözcük tabanlı ve vektör tabanlı eşleşmeyi birleştiren hibrit arama, kabaca ilk elli adaydan oluşan bir küme döndürür. Bir yeniden sıralayıcı bunu soruyu gerçekten cevaplayan on ila yirmi adaya indirir; bu adım modele ve yığın boyutuna göre kabaca 100 ila 400 milisaniye ekler. Hayatta kalan her parça sonra bir kırıntı olarak değil, ait olduğu üst bölüme genişletilerek gönderilir; böylece model öksüz paragraflar yerine birkaç bin tokenlık tutarlı pasajlar alır. Bu hattın ayrıntıları hibrit arama ve yeniden sıralama yazısında; genişletme stratejisi ise büyük ölçüde ölçekte belge parçalama tercihlerinize bağlıdır.

Altta yatan tasarım ilkesini açıkça söylemekte fayda var: isabet için retrieval, dayanıklılık için bağlam kullanın. Neyin ilgili olduğuna retrieval karar verir ve bu işi, yüz bin tokenlık gürültü içinde modelin dikkat mekanizmasının yaptığından çok daha iyi yapar. Bağlam uzunluğu ise size kusurlu retrieval'a tolerans satın alır; üç yerine yirmi aday göndermek, vasat bir sıralamanın bile cevabı modelin bulacağı bir yerde barındırması demektir. İki mekanizma birbirinin başarısızlık biçimlerini kapatır ve bu şeklin, zıt noktalardan yola çıkan ekiplerce birbirinden bağımsız olarak sürekli yeniden keşfedilmesinin nedeni budur. Bu yüzden hibrit yapı bir uzlaşma değil, iki mekanizmanın birbirini tamamlaması olarak okunmalıdır.

Önbellekleme Aritmetiği Değiştirir

Karşılaştırmayı gerçekten uzun bağlam lehine kaydıran tek gelişme prompt önbelleklemedir ve bunu dar ve belirli bir durumda yapar. Sağlayıcılar sabit bir öneki önbelleğe alır ve o öneki paylaşan sonraki isteklerde önbellekli girdi tokenları için belirgin biçimde daha az ücret alır. Aynı büyük belge önbellek ömrü içinde tekrar tekrar sorgulanıyorsa tam bedeli bir kez, sonrasında ise bir kesrini ödersiniz; bu da istek başına maliyeti oturum başına maliyete yakın bir şeye dönüştürür. Bu gerçek ve kayda değer bir farktır ve önbellekleme yokken yazılmış her karşılaştırma artık yanlıştır. Yine de bu avantajın tam olarak nerede geçerli olduğunu net çizmek gerekir.

Sınırlar da etki kadar önemlidir. Önbellek ömürleri kısadır, tipik olarak saatlerle değil dakikalarla ölçülür; dolayısıyla önbellekleme tek bir çalışma oturumu içinde muazzam fayda sağlar, güne yayılmış bir kullanıcı kitlesinde ise hiçbir şey yapmaz. Otuz dakikalık bir oturumda tek bir büyük sözleşme üzerinde çalışan bir avukat, önbellekli uzun bağlam için neredeyse ideal örnektir. Aynı bilgi tabanı hakkında on bin farklı kullanıcıya cevap veren bir destek asistanı ise bunun tam tersidir: her istek soğuk başlangıçtır ve korpusun tamamını her seferinde ödersiniz. Kullanım deseninizi bilmeden önbelleğe dayalı bir maliyet tahmini yapmak, tahmini daha kurulurken yanlış kurmaktır.

Bir de çoğu kurumsal kurulumda önbeleklemeyi sessizce devre dışı bırakan bir kısıt var ve buna dayalı bir plan kurmadan önce anlamakta fayda var. Önbelleğe alınan önek token token aynı olmak zorundadır. Her kullanıcının yetkisine göre filtrelenmiş bir korpus promptu, tanımı gereği kullanıcılar arasında aynı değildir; yani belge düzeyinde erişim kontrolüne sahip olduğunuz anda paylaşılan önbelleği kaybetmişsinizdir. Kullanıcı başına önbellekleyebilirsiniz ama o zaman kişi başına bir korpus önbelleklemiş olursunuz ve ekonomi çöker. Çok kiracılı sistemler aynı duvara aynı nedenle toslar ve bu, hiçbir prompt mühendisliğiyle aşılabilecek bir kısıt değildir. Bu kısıt bir mimari tercih değil, matematiksel bir zorunluluktur.

Graf ve Yapılandırılmış Retrieval, ve Bir Karar Ağacı

Ne vektör aramanın ne de uzun bağlamın iyi hallettiği bir soru sınıfı var ve adını koymakta fayda var, çünkü ekipler buna aylar kaybediyor. Vektör arama, bu soruya anlamsal olarak neyin benzediğini cevaplar. Kaç tane olduğunu, iki sürüm arasında hangilerinin değiştiğini, sahiplik zincirinin ne olduğunu ya da şu madde tipini içeren tüm sözleşmelerin listesini cevaplayamaz. Bunlar toplama, gezinme ve filtreleme problemleridir ve benzerlik yanlış araçtır. Uzun bağlam da kurtarmaz: bir şeyi saymak için beş yüz sözleşme okuyan bir model yanlış sayar, hem de kendinden emin biçimde, ve hangi yöne yanıldığını bilemezsiniz.

Cevaplar yapısaldır. Veri yükleme sırasında çıkarılan alanlar üzerindeki metaveri filtreleri ve sıradan SQL; sayma, filtreleme ve tarih aralıklarını düzgün halleder ve ilk başvuracağınız araç bunlar olmalıdır. Varlıklar ve ilişkiler üzerinde çalışan, GraphRAG'in yaygınlaştırdığı tarzda graf retrieval ise sahiplik zincirleri, atıf ağları ve bağımlılık yolları gibi gezinme sorularını halleder. Bu tavsiyenin gösterişsiz hâli şudur: iyi bir retrieval sistemi genellikle az miktarda sıkıcı yapılandırılmış veri mühendisliği içerir ve bunu atlamak, bu kadar çok pilotun düzgün kurulmuş soruları harika cevaplayıp içinde sayı geçen ilk soruda dağılmasının nedenidir. Bu katmanı eklemek genellikle birkaç günlük iştir ve karşılığında tüm bir soru sınıfını açar.

Karar ağacını düz metinle verelim. Korpus büyüklüğüyle başlayın: pencereye sığmıyorsa retrieval yapıyorsunuz demektir ve ağacın geri kalanı nasıl yapacağınızla ilgilidir. Sığıyorsa sorgu hacmini sorun: tek seferlik ya da bir avuç sorgu uzun bağlamı, çok sayıda kullanıcının tekrar tekrar sorgulaması indeksi öne çıkarır ve kesişim noktası düşüktür. Sonra erişim kontrolünü sorun: belge bazında herhangi bir izin gereksinimi retrieval'ı zorunlu kılar, çünkü bir prompt bunu ifade edemez. Sonra denetimi sorun: hangi kaynağın hangi iddiayı ürettiğini birinin bilmesi gerekecekse retrieval bunu yapısal olarak verir, uzun bağlam vermez. Bu dört soruyu sırayla cevaplamak çoğu projede yarım günde biter.

İki dal daha ağacı tamamlar. Hangi tür sorunun baskın olduğunu sorun. Yerel bilgi arama retrieval'ın kendi sahasıdır. Bütünsel yapı, belge geneli özetleme ve tutarlılık denetimi uzun bağlamı öne çıkarır. Toplama ve gezinme ise hangisini seçmiş olursanız olun yapılandırılmış ya da graf retrieval gerektirir. Son olarak tazeliği sorun: korpus günlük değişiyorsa artımlı güncellenen bir indeks, promptu baştan kurmaktan operasyonel olarak daha ucuzdur. Gerçek sistemlerin çoğu farklı dallarda farklı cevaplar verir; hibrit yapının var olma nedeni ve başlıktaki soruya dürüst cevabın neredeyse her zaman ikisi birden olmasının nedeni tam olarak budur. Karar ağacının çıktısı tek bir mimari değil, soru tipine göre kurulmuş bir yönlendirme tablosudur.

Hiçbir Yaklaşımın Kapatmadığı Doğrulama Açığı ve Bizim Kararımız

Hiçbir yaklaşım hiçbir şeyi doğrulamaz. Mimari tartışmalarında kaybolan kısım budur ve bir sistemin müşterinin önüne konulup konulamayacağını belirleyen de budur. Uzun bağlamlı bir model bir belgeyi doğru okuyup yine de belgenin desteklemediği bir iddia üretebilir. Bir retrieval sistemi yanlış parçaya dayanıp onu kaynak gösterebilir ki bu tartışmalı biçimde daha kötüdür, çünkü bir atıf kanıt gibi görünür ve kaynaksız bir iddiadan daha az sorgulanır. İki yaklaşım arasında hata oranı değişir; hatanın varlığı değişmez ve her iki durumda da aynı halüsinasyon problemidir. Doğrulama açığını kapatmadan hiçbir mimari tercih tek başına güven vermez ve bu açık her iki yaklaşımda da aynı biçimde ölçülmelidir.

Açığı kapatan şey mimari değil ölçümdür. Cevapları bilinen sabit bir değerlendirme seti ve bunun her değişiklikte koşturulması. Çıktıdaki her iddianın getirilen metin parçası tarafından gerçekten desteklenip desteklenmediğini, yalnızca ona komşu olup olmadığını soran bir dayanaklılık kontrolü. Atıf verilen pasajın iddiayı gerçekten içerdiğini doğrulayan bir atıf denetimi. Hukuki ya da mali sonucu olan her çıktıda insan gözetimi. Bunlar RAG değerlendirme metrikleri yazısında daha ayrıntılı ele alınıyor ve metnin retrieval'la mı yoksa prompta yapıştırılarak mı geldiğinden bağımsız olarak birebir aynı şekilde geçerlidir. Bu kontrolleri kurmak, mimariyi değiştirmekten hem daha ucuzdur hem de daha çok etki eder.

Bizim izlediğimiz sıra bilinçli olarak romantizmden uzaktır. Önce uzun bağlamla prototip yaparız, çünkü bir öğleden sonra sürer ve o aşamada önemli olan tek soruyu, yani görevin hiç mümkün olup olmadığını cevaplar. Gerçekçi bir örneklem üzerinde kaliteyi, sorgu başına maliyeti ve gecikmeyi ölçeriz. Sonra sayılar öyle diyorsa retrieval kurarız; pratikte bu, korpus sığmadığında, belge bazında izin gerektiğinde, kaynak gösterimi zorunlu olduğunda ya da sorgu hacmi başa baş noktasını geçtiğinde demektir. 50.000 ila 200.000 belgelik bir korpusta ilk pilotun ölçülebilir bir temel çizgiye ulaşması tipik olarak 6 ila 10 hafta sürer. Ölçüm olmadan verilen mimari kararlar sonradan çok pahalıya geri alınır.

Bu ayrım kendi ürünlerimizde de görünür. caseon.ai ve DiligenceAI'da tek bir sözleşmeyi baştan sona incelemek uzun bağlam işidir, çünkü sorular belgenin bütünü hakkındadır ve belgeyi parçalamak tam da önemli olan çapraz atıfları kaybettirir. Bir içtihat gövdesinde ya da yüzlerce sözleşmelik bir portföyde arama yapmak ise retrieval işidir; çünkü sığmaz, çünkü erişim kullanıcıya göre değişir ve çünkü her cevabın kaynağını göstermesi gerekir. Aynı ürün ikisini birden yapar, sorunun biçimine göre yönlendirerek. Benzer bir işi kapsamlandırıyorsanız, RAG ve anlamsal arama çalışmalarımız genellikle önceden verilmiş bir mimari kararla değil tam olarak bu ölçümle başlar.