Uyarlanabilir RAG (Adaptive RAG)

Ne öğreneceksin

On dört bölümdür retrieval pipeline’ları kurduk ve sonra kapıdan giren her soru için onları aynı şekilde çalıştırdık. Bu bölüm, incelenmeden kalan son şeyi düzeltiyor: tek bir pipeline’ın her query’ye hizmet etmesi gerektiği varsayımını. Küçücük bir karmaşıklık sınıflandırıcısı (complexity classifier) kuracağız: gelen bir query’ye bakıp gerçekten ne kadar mekanizmayı hak ettiğine karar veren bir fonksiyon; sonra da her query’yi üç yoldan birine gönderen bir yönlendirici (router): hiç retrieval yok, tek bir retrieve-then-generate ya da çok adımlı bir decompose-retrieve-synthesize. Bu, Adaptive RAG; ve işin keyif veren tarafı, yeni bir pipeline icat etmiyor olmamız. 6’dan 10’a kadar olan bölümlerde zaten kurduğumuz pipeline’ların önüne bir orkestra şefi koyuyor ve seçimi ona bırakıyoruz. Yol boyunca bu fikri, yüzeysel olarak benzediği iki şeyden ayırmaya özen göstereceğim: 8. bölümdeki query dönüştürme ve 10. bölümdeki kaynak yönlendirme. Aynı hamle değiller ve onları birbirine karıştırmak, insanların Adaptive RAG’i yanlış anlamasının en yaygın yolu.

Ön koşullar

Bu bölüm serinin tüm ikinci yarısına yaslanıyor; dolayısıyla önceki parçaların kafanda olduğunu gerçekten varsaydığım tek yer burası. İlk RAG’ini Kur (6. bölüm) lazım, çünkü tek adımlı rota tam olarak o retrieve-augment-generate döngüsü. Query ayrıştırma (query decomposition) için Retrieval’ı Akıllandırmak (8. bölüm) lazım; çok adımlı rota onu yeniden kullanıyor ve query dönüştürmeyle karşıtlığı da böylece temiz çizebileceğiz. Ve İleri RAG Mimarileri (10. bölüm) lazım, çünkü çok adımlı rota oradaki decompose-and-synthesize kalıbı; ayrıca 10. bölümün bilgi kaynağına göre yönlendirme fikri, zorluğa göre yönlendirmeyle karıştırmamaya dikkat etmemiz gereken şey. Bu bölümde yeni matematik yok. Mimari ve muhakeme var, bir de bir oturuşta okuyabileceğin küçük bir miktar deterministik Python.

Tek pipeline her query’ye uymaz

İşte 6. bölümden beri sessizce içinde olduğumuz durum. Bir pipeline kurduk, retriever’ını ayarladık, re-ranking, ayrıştırma ve dayanaklandırma ekledik ve sonra onu her query’ye birebir aynı şekilde doğrulttuk. Kullanıcı “hi there” yazıyor ve sistem görev bilinciyle onu embed ediyor, vector store’da arıyor, en yakın üç politika chunk’ını çekiyor, onları bir prompt’a tıkıyor ve bir dil modelinden cevap istiyor. Model, hakkını yemeyelim, ilgisiz chunk’ları görmezden gelip merhaba diyor. Ama hiçbirine ihtiyacı olmayan bir selamlaşma üretmek için bir embedding’e, bir vektör aramasına ve şişirilmiş bir prompt’a para ödedik.

Şimdi tersine çevir. Kullanıcı “compare the refund window and the warranty period, and explain the difference” diye soruyor. Tek bir retrieval, o koca cümleye en yakın chunk’ları kapıyor; bu refund chunk’ı olabilir, warranty chunk’ı olabilir ya da şanssız bir karışım, ama ikisi birden nadiren temizce gelir; ve modelden iki şeyi karşılaştırması isteniyor, oysa elinde güvenilir biçimde yalnızca birinin kanıtı var. Kolay query fazla hizmet aldı. Zor query eksik hizmet aldı. Aynı sabit pipeline ikisini de yaptı, çünkü sabit bir pipeline’ın onları birbirinden ayırt etmesinin hiçbir yolu yok.

Çözüm, önce query’ye bakıp ne kadar emeği hak ettiğine karar vermek. Retrieval’dan önce verilen bu karar, Adaptive RAG’in tüm fikri: gelen her query’yi karmaşıklığına göre sınıflandıran ve hepsi için tek pipeline çalıştırmak yerine onu uyan pipeline’a yönlendiren bir sistem. İsim, Adaptive-RAG makalesinden geliyor (Jeong ve arkadaşları, NAACL 2024, arXiv 2403.14403); makale bunu tam olarak, tek stratejiye bağlanmak yerine query başına bir retrieval stratejisi seçmek olarak çerçeveledi.

Üç rota

Herhangi bir şeyi sınıflandırmadan önce üç varış noktasını adlandıralım, çünkü sınıflandırıcı ancak neler arasında seçim yaptığını bildiğinde anlam kazanır. Üçü de daha önce gördüğün pipeline’lar.

İlk rota retrieval yok (no retrieval). Bazı query’lerin index’e hiç ihtiyacı yoktur. “Hi there” ve “thanks” saf sohbet tutkalı. Cevabını modelin kendi ön eğitiminden zaten taşıdığı bir soru, mesela yaygın bir kelimenin tanımı, senin belgelerine de ihtiyaç duymaz. Bunlar için doğru hamle, retrieval’ı tamamen atlayıp doğrudan cevap vermek. Bu, mümkün olan en ucuz yol: tek model çağrısı, ya da bizim çevrimdışı kurulumumuzda şablonlu bir yanıt; sıfır embedding, sıfır arama. Kritik nokta şu: bu rota 6. bölümün aramasını hiç kullanmıyor. Bütün mesele, ona ihtiyacımız olmadığını fark etmiş olmamız.

İkinci rota tek adımlı (single-step) ve bu, 6. bölüm pipeline’ının değişmemiş hali: query’yi embed et, en iyi bir iki chunk’ı getir, dayanaklı bir prompt kur, üret. İşin yük beygiri bu. Bir bilgi tabanına sorulan olgusal soruların çoğu tek adımlı query’lerdir. “What is our refund window?” tam olarak tek bir ilgili chunk’a karşı tam olarak tek bir arama ister, sonra da ona dayanan bir cevap. Trafiğin çoğunlukla böyle sorulardan oluşuyorsa, çoğunun tek adımlıya düşmesi gerekir ve bunda hiçbir sorun yok.

Üçüncü rota çok adımlı (multi-step) ve bu, 10. bölümdeki decompose-retrieve-synthesize kalıbı. Senden iki şeyi karşılaştırmanı isteyen ya da birkaç soruyu tek cümleye sığdıran bir query tek retrieval’la cevaplanamaz, çünkü hiçbir tek chunk bir karşılaştırmanın iki yarısını birden tutmaz. O yüzden onu ayrıştırırız (decompose): tek zor query’yi birkaç daha basit alt query’ye böl, her biri için bağımsız retrieval yap, sonra toplanan kanıtı tek bir cevapta sentezle. “Compare the refund window and the warranty period” iki retrieval’a dönüşür; biri refund chunk’ını bulur, biri warranty chunk’ını; ancak ondan sonra cevap veririz. Çok adımlı rota en pahalısıdır (birkaç retrieval, daha çok token) ve onu “hi there” üzerinde çalıştırmak istemememizin sebebi tam olarak bu.

Menünün tamamı bu: none, single, multi. En ucuzdan en pahalıya; en kolaydan en zora eşlenmiş. Sınıflandırıcının tek işi, her query’yi doğru rafa koymak.

Karmaşıklık sınıflandırıcısı

Sınıflandırıcı beklediğinden daha küçük, hem de bilerek. Eşlik eden kodda onu, küçük harfe çevrilmiş query üzerinde bir avuç deterministik kural olarak yazdım. Bu, çalıştırılabilir artefakttaki (adaptive_rag.py) fonksiyonun birebir hali ve yönlendirme mantığının değişmekte serbest olmayan tek parçası, çünkü bu bölümdeki yönlendirme kararları doğrudan ondan çıkıyor:

def classify_complexity(query: str) -> str:
    q = query.lower().strip()
    if re.search(r"\b(hi|hello|thanks|who are you)\b", q) or len(q.split()) <= 2:
        return "none"
    multi_signals = ("compare", "versus", " vs ", "difference between",
                     " and then", "across", "each of", "both", "trade-off")
    if any(s in q for s in multi_signals) or q.count("?") > 1:
        return "multi"
    return "single"

Bunu, sırayla sorulan üç soru olarak oku. Birincisi: bu havadan sudan sohbet mi, ya da önemsiz derecede kısa mı? Bir selamlaşma anahtar kelimesi, ya da iki kelime veya daha azı, none’a yönlenir. İkincisi: karşılaştırma veya çokluk sinyali taşıyor mu? “compare”, “versus”, “difference between”, “across”, “both” gibi kelimeler ya da tek mesajda birden fazla soru işareti, hepsi query’nin aslında tek palto giymiş birkaç soru olduğuna işaret eder; o yüzden multi’ye yönlenir. İki kontrolden de sağ çıkan her şey düz bir olgusal aramadır ve single’a yönlenir.

Bu sinyaller bilerek kaba. Uzunluk, karşılaştırma kelimeleri, “and then”, “both” veya “each of” gibi bir avuç görev-bağlacı ifadesi ve soru işareti sayısı; bir kuralın mikrosaniyeler içinde okuyabileceği ucuz, okunaklı özelliklerdir ve seni epey ileri götürürler. Sınırın kesin yerine dikkat et: sınıflandırıcı o belirli ifadelere kilitlenir, çıplak bir “and”e değil; tek başına bir “and” yalnızca cümlecikleri birleştirir ve kendi başına multi rotasını tetiklemez (daha sonra, zaten multi’ye yönlenmiş bir query’yi bölmek için ayrıştırmanın içinde kullanılır). Üretim ortamında bu kural bloğunu küçük, eğitilmiş bir sınıflandırıcıyla değiştirirdin: çok sayıda etiketli query görmüş ve sınırı bir anahtar kelime listesinin çizebileceğinden çok daha sağlam öğrenmiş hafif bir model. Eşlik eden kod yalnızca kural bloğunu içeriyor — çevrimdışı koruması sınıflandırıcıyı değil, embedding backend’ini değiştiriyor — böylece yönlendirme kararları her yerde birebir aynı ve ders her yerde çalışıyor. Mekanizma iki durumda da aynı: query metninden rota etiketine giden hızlı, ucuz bir fonksiyon. Oyuncakla üretim arasında değişen tek şey, o fonksiyonun çizgileri ne kadar isabetli çizdiği.

Sınıflandırıcıyı ve üç rotayı, bir query seçtiğinde izlediği yolun aydınlandığı tek bir bağlantılı makine olarak görmek işe yarar. Aşağıdaki widget tam olarak bunu yapmanı sağlıyor.

Open figure ↗

Zaten kurduğumuz pipeline’lar arasında yönlendirme

Bu, tüm serinin meyvesi; o yüzden açıkça söylemeye değer. Adaptive RAG yeni bir retrieval tekniği getirmiyor. 6’dan 10’a kadar olan bölümleri kurmakla geçirdiğin pipeline’ların önünde duran orkestra şefi bu ve enstrümanı da sınıflandırıcı. None rotası, 6. bölüm aramasının bazen gereksiz olduğunun fark edilmesi. Single rotası, 6. bölüm aramasının ta kendisi. Multi rotası, 10. bölümün decompose-and-synthesize kalıbı. Adaptive RAG, bunlardan hangisinin çağrılacağına karar veren katman. Bir kez böyle gördüğünde, önceki her bölüm şefin uzanabileceği bir araç olarak yerine oturuyor.

Eşlik eden kodda, adaptive_rag.py içindeki route fonksiyonu tam olarak o dağıtıcı. Önce classify_complexity’yi çağırıyor, sonra dallanıyor: bir none query’si retrieval olmadan doğrudan şablonlu bir yanıt alıyor, bir single query’si retrieve-then-generate’ten geçiyor ve bir multi query’si, her biri için retrieval yapılıp sonra sentezlenen alt query’lere ayrıştırılıyor. Artefakttaki altı demo query’si her sınıfa ikişer bölünüyor ve davranışı somutlaştırıyorlar. “Hi there” ve “thanks” none’a yönleniyor ve index’e hiç dokunmuyor. “What is our refund window?” ve “How do I fix the E-4042 error?” single’a yönleniyor ve her biri kendi tek ilgili chunk’ını getiriyor: sırasıyla refund-policy chunk’ı ve E-4042 hata kodu chunk’ı; önceki bölümlerdeki aynı destek bilgi tabanını yeniden kullanarak. “Compare the refund window and the warranty period, and explain the difference” ile “What is the difference between the refund window and the warranty period?” multi’ye yönleniyor, bir refund alt query’si ve bir warranty alt query’sine ayrışıyor, her chunk’ı ayrı ayrı getiriyor ve sentezliyor. Yönlendirme kararları deterministik ve gerçek model yolunu da çalıştırsan çevrimdışı geri düşüşü de, birebir aynı. Yollar arasında değişen şey alttaki benzerlik skorları; bu yüzden ayrıştırılmış bir alt query’nin hangi chunk’a indiği farklılaşabilir — çevrimdışı hashing geri düşüşü, “warranty” gibi yakın-eşanlamlılar konusunda gerçek bir encoder’dan daha kaba.

Şimdi karşıtlıklar, çünkü Adaptive RAG’in komşularıyla karıştırıldığı yer burası.

Bu, 8. bölüm değil (query’yi dönüştürmek)

8. bölüm query dönüştürmeyi öğretti: bir query’yi daha iyi retrieval yapsın diye yeniden yazmak. “The E-4042 thing”i “E-4042 payment-declined error”a genişletmek ya da çok parçalı bir soruyu aynı retriever’a beslemek için alt sorulara bölmek. Query dönüştürme neyle aradığını değiştirir. Adaptive RAG, arama yapılıp yapılmayacağını ve ne kadar yapılacağını değiştirir. Bir dönüşüm her zaman retrieval yapacağını varsayar ve o retrieval’ın daha isabetli oturmasına çalışır. Yönlendirici ise ondan önce gelen soruyu sorar: bir kez mi, birkaç kez mi, yoksa hiç mi retrieval yapmalıyız? Güzelce birleşirler. Hatta çok adımlı rota, iç mekanizması olarak 8. bölümün ayrıştırmasını kullanır. Ama yönlendirme kararı dönüşümün bir seviye üstünde oturur ve yeni fikir o seviyedir.

Bu, 10. bölüm değil (kaynağa göre yönlendirme)

10. bölümün query yönlendirmesi, bir query’nin hangi index’e gideceğine karar verir: İK sorusunu İK deposuna, kod sorusunu kod deposuna, haber sorusunu web aramasına gönder. Bu, bilgi kaynağına göre, yani cevabın nerede yaşadığına göre yönlendirmedir. Adaptive RAG ise karmaşıklığa göre yönlendirir: cevabın nerede yaşadığından bağımsız olarak, query’nin cevaplanmasının ne kadar zor olduğuna göre. Basit bir İK sorusu da basit bir kod sorusu da tek adımlı query’lerdir, farklı depolara gitseler bile; çok sekmeli bir karşılaştırma, kanıtı ister tek depoda otursun ister üçünde, çok adımlı bir query’dir. Kaynak yönlendirme ile karmaşıklık yönlendirme birbirine diktir ve olgun bir sistem ikisini de yapar: önce query’nin ne kadar mekanizmaya ihtiyacı olduğuna karar verir, sonra retrieval yapan rotaların içinde hangi kaynaklara vurulacağına. İkisini karıştırmak, insanları bir kaynak yönlendiricisi kurup ona uyarlanabilir demeye götürür; oysa herhangi bir query’nin tetiklediği retrieval miktarında aslında hiçbir şey değişmemiştir.

Ne kazandırır ve dürüst uyarılar

Yönlendirmenin faydası yapısal ve figürde görmesi kolay: kolay bir query’nin hiç ihtiyaç duymadığı mekanizmaya para ödemeyi bırakırsın ve ağır mekanizmayı, ona gerçekten ihtiyaç duyan zor query için hazırda tutarsın.

Bu faydaya iliştirilmiş sayılar göreceksin ve onlara dikkatli yaklaşmak istiyorum. Üretimdeki yönlendirme kurulumlarına dair bazı 2026 tedarikçi yazıları, bir karmaşıklık yönlendiricisi eklemekten kabaca yüzde 35 daha düşük gecikme ve yüzde 28 daha düşük maliyet raporluyor, bazen yanında küçük bir doğruluk artışıyla. Bu rakamları gösterge niteliğinde, ölçülmüş garanti değil diye ele al. Adaptive-RAG makalesinden gelmiyorlar; makale manşetlik bir gecikme yüzdesi değil, etkinlik ve adım sayısı tarzında bir verimlilik raporluyor; ve burada senin için ölçtüğüm bir şey de değiller. Kendi sayıların tamamen trafik karışımına bağlı: çoğunlukla selamlaşma ve kolay bilgi yönlendiriyorsan çok tasarruf edersin; çoğunlukla gerçekten zor karşılaştırmalar yönlendiriyorsan sınıflandırıcı çoğunlukla sadece bir adım ekler. Dürüst çerçeve şu: kazanç sabit bir yüzde değil, yapısal. Kolay bir query’nin hiç ihtiyaç duymadığı mekanizmaya harcamayı bırakıyorsun; bunun sana ne kadar kazandıracağını ise ancak kendi trafiğin söyleyebilir.

En çok önemsenmesi gereken uyarı, sınıflandırıcının kendisinin yeni bir başarısızlık yüzeyi olması. Sabit bir pipeline en azından öngörülebilir biçimde başarısız olur: hep aynı şekilde fazla ya da eksik hizmet verir. Bir yönlendirici yanlış yönlendirebilir. Tehlikeli yön, eksik sınıflandırma: sınıflandırıcının single diye okuduğu, gerçekten zor, çok parçalı bir query, birkaç retrieval gerekirken bir tane alır, eksik retrieval yapar ve bir karşılaştırmayı kanıtın yarısından cevaplar. Bu başarısızlık sessizdir, çünkü sistem kendinden emin biçimde akıcı bir cevap döndürür; cevabın bir tarafı eksiktir, o kadar. Ters yöndeki hata, yani kolay bir query’yi çok adımlı yola göndermek, yalnızca emek israf eder ve çok daha bağışlayıcıdır. O yüzden bir yönlendiriciyi ayarlarken asimetriyi bilerek ayarla: fazla hizmet almış kolay bir query sana paraya mal olur, ama eksik hizmet almış zor bir query yanlış cevaba mal olur. Yönlendiriciyi ancak bu ödünleşimi ölçebildiğinde ekle; bu da tam olarak 11. bölümün konusu olan disiplin.

💡 Deneyimden. Böyle bir yönlendiriciyi ilk kez canlıya aldığımda klasik hatayı yaptım: onu ucuz rotalar konusunda agresif olacak şekilde ayarladım, çünkü yöneticimin baktığı şey maliyet panosuydu ve daha fazla trafiği retrieval’sız ve tek adımlı yollara göndermek o sayıyı çok güzel düşürüyordu. İki hafta boyunca bir zafer gibi göründü. Sonra bir destek ekibi lideri bana bir transkript iletti; müşteri “what is the difference between your refund window and your warranty, and which one covers water damage?” gibi bir şey sormuştu ve bot yalnızca iade penceresi hakkında, akıcı ve kendinden emin biçimde cevap vermiş, garantiden hiç bahsetmemişti. Agresif eşiklerim onu tek adımlı bir query olarak okumuş ve tek arama vermişti. Getirdiği chunk gerçekti ve doğruydu, yani loglarda hiçbir şey bozuk görünmüyordu ve cevap gerçek bir belgeye dayanıyordu. Sadece sorunun yarısını cevaplıyordu. Çözüm daha akıllı bir model değildi. Eşiği, karşılaştırma sinyali ya da ikinci bir soru işareti taşıyan her query multi rotasına düşecek şekilde kaydırmak ve artık bazen pahalı yolu, ona kesinlikle ihtiyacı olmayan bir query üzerinde çalıştıracağımı kabullenmekti. Biraz maliyeti geri verdim, karşılığında sessizce yarısı cevaplanmış sorulardan çok daha azını aldım ve bu her seferinde doğru takastı. Ders aklımda kaldı: “daha ucuza” doğru bir yanlış yönlendirme maliyet grafiğinde görünmezdir ve başarısız olduğu o tek kullanıcı için fazlasıyla görünürdür.

Kendin dene

Yönlendirici, tek bir dosyayı düzenleyerek her kararı hissedebileceğin kadar küçük. adaptive_rag.py dosyasını al (yalnızca numpy; alışıldık çevrimdışı korumanın arkasında isteğe bağlı bir sentence-transformers yolu var) ve çalıştır. Altı demo query’sinin, düzyazının anlattığı gibi her sınıfa ikişer bölündüğünü göreceksin: selamlaşmalar none rotasını alıp index’e sıfır kez dokunuyor, refund ve E-4042 soruları birer retrieval’la single alıyor ve iki karşılaştırma query’si multi alıp ikişer alt query’ye açılıyor. Sonra şu üç alıştırmayı sırayla dene.

Önce asimetriyi izle. İkinci multi demosunu al, “What is the difference between the refund window and the warranty period?”, ve tek soru işaretini sil, bir bildirim cümlesi gibi okunsun: “What is the difference between the refund window and the warranty period”. “difference between” ifadesi hâlâ bir multi sinyali, dolayısıyla multi’de kalıyor. Şimdi bir de o ifadeyi sınıflandırıcının kilitlenmediği bir şeye çevir; mesela “compare” kelimesi olmadan “how the refund window compares to the warranty period” (“the refund window relative to the warranty period” diye yaz). Birden hiçbir şey bir multi sinyalini tetiklemiyor, soru işareti sayısı sıfır ve query single’a düşüyor. Çalıştır: bir retrieval alırsın, cevap yalnızca refund chunk’ına dayanır ve warranty tarafı sessizce eksiktir. Bu, “Deneyimden” notundaki yarım cevap başarısızlık modunun üç satırda yeniden üretilmiş hali. Çıktıda hiçbir şeyin bozuk görünmediğine dikkat et: getirdiği chunk gerçek ve doğru, cevap akıcı ve onu ancak iki taraf olduğunu bilen bir insan yakalayabilir.

İkincisi, bir eşiği bilerek yanlış ayarla. Sınıflandırıcıda kaydırılacak sayısal bir eşik yok ama ahlaki eşdeğeri var: multi_signals demeti ve q.count("?") > 1 testi. Yönlendiriciyi, bir maliyet panosunun seni ayartacağı şekilde ucuz rota konusunda agresif yap: o testi q.count("?") > 2 olarak değiştir (böylece iki soru işareti artık yükseltmiyor) ve "difference between"i multi_signals’tan çıkar. Demoları yeniden çalıştır. İkinci karşılaştırma query’si artık single’a yönlenip eksik retrieval yapıyor; figürdeki query başına maliyet çizgisi ise çok güzel düşüyor. Bu, denemenin uyardığı takasın ta kendisi: zor query’lerin sessizce kendi yarılarını cevaplamasını sağlayarak daha düşük bir maliyet sayısı satın aldın. Sonra ikisini de geri koy ve altı rotanın da düzyazıyla eşleşmeye döndüğünü doğrula (betiğin son satırı all six routes match the prose: True yazdırır).

Üçüncüsü, dördüncü bir rota ekle. Gerçek sistemlerin çoğu zaman üç rotalı menünün kapsamadığı bir rotaya ihtiyacı olur: cevabı bilgi tabanında hiç olmayan ve web araması gerektiren bir query; 10. bölümün kaynak yönlendirme dediği yükseltme. classify_complexity’ye bir web dalı ekle (örneğin query bir rakipten, bir fiyattan ya da “latest”/“today”den bahsettiğinde web’e yönlendir; bunların hiçbirini statik politika chunk’ların cevaplayamaz) ve route içine, yerel retrieve yerine taslak bir web_search(query) çağıran eşleşen bir kol ekle. Mesele aramanın kendisi değil (onu mock’lu bırakabilirsin), şekil: karmaşıklık yönlendirme ile kaynak yönlendirme artık yan yana duruyor ve birinin ne kadar retrieval, diğerinin nereden diye sorduğu birbirine dik kararlar olduğunu kendi gözünle görebiliyorsun.

⚠️ Sık yapılan hatalar

• Maliyet grafiğine göre ayarlamak. Ucuz rotaları agresifçe genişletmek (none ve single’a daha çok trafik) maliyet panosunu düşürür ve zafer gibi görünür, ama “daha ucuza” doğru her yanlış yönlendirme, çok az kanıtla cevaplanmış zor bir query’dir. Bu başarısızlık maliyet metriklerinde görünmez ve yalnızca başarısız olduğu kullanıcıya görünür. Asimetriye göre ayarla: fazla hizmet almış kolay bir query paraya, eksik hizmet almış zor bir query yanlış cevaba mal olur.
• Tek başına bir “and”i multi sinyali saymak. Çıplak bir “and”, görevleri paketlemekten çok daha sık cümlecikleri birleştirir (“refunds and exchanges are handled by support” tek aramadır). Multi rotasını her “and”e kilitlemek pahalı yolu sele boğar. Buradaki sınıflandırıcı belirli görev-bağlacı ifadelerine kilitlenir (“and then”, “both”, “each of”), tek başına “and”e değil; “and” daha sonra, zaten multi’ye yönlenmiş bir query’yi bölmek için ayrıştırmanın içinde kullanılır.
• Yönlendiriciyi bir query dönüşümüyle karıştırmak (8. bölüm). Bir dönüşüm neyle aradığını değiştirir ve her zaman retrieval yapacağını varsayar. Yönlendirici, retrieval yapılıp yapılmayacağına ve ne kadar yapılacağına karar verir. “Uyarlanabilir” katmanın yalnızca query’leri yeniden yazıyor ve yine her seferinde bir retrieval çalıştırıyorsa, bir yönlendirici değil bir dönüşüm kurdun.
• Karmaşıklık yönlendirmeyi kaynak yönlendirmeyle karıştırmak (10. bölüm). Bir query’nin hangi index’e vuracağını seçmek (İK deposu mu, kod deposu mu, web mi), ne kadar retrieval gerektiğini seçmeye diktir. Bir kaynak yönlendiricisi kurup ona uyarlanabilir demek, her query’nin her zamanki kadar retrieval tetiklemesini değiştirmez.
• Yönlendiriciyi ölçemeden canlıya almak. Sabit bir pipeline öngörülebilir biçimde başarısız olur; bir yönlendirici, tehlikeli yönde sessizce başarısız olan yeni bir başarısızlık yüzeyi getirir. Onu ancak zor query’lerde eksik hizmet oranını ölçebildiğinde ekle; bu da 11. bölümün disiplini.

Özet çıkarımlar

• Adaptive RAG, her query’yi karmaşıklığına göre sınıflandırır ve her şey için tek sabit pipeline çalıştırmak yerine onu uyan pipeline’a yönlendirir. Tek pipeline’ın kolay query’lere fazla, zor query’lere eksik hizmet vermesi sorununun cevabıdır.
• Üç rota vardır: none (havadan sudan sohbet ya da modelin zaten bildiği bir olgu; index’i tamamen atla), single (6. bölümün retrieve-then-generate’i) ve multi (karşılaştırmalar ve çok parçalı sorular için 10. bölümün decompose-retrieve-synthesize’ı).
• Karmaşıklık sınıflandırıcısı, query metninden rota etiketine giden küçük, hızlı bir fonksiyondur; burada ucuz sinyaller üzerinde deterministik kurallardan kurulmuştur (uzunluk, karşılaştırma kelimeleri, “and then” veya “both” gibi birkaç görev-bağlacı ifadesi, soru işareti sayısı) ve üretimde küçük, eğitilmiş bir sınıflandırıcıyla değiştirilir. Mekanizma aynıdır; yalnızca sınırın isabeti değişir.
• Adaptive RAG, yeni bir retrieval tekniği değil, 6-10. bölümlerin üzerindeki orkestra şefidir. Onu 8. bölümle (neyle aradığını dönüştürür) ya da 10. bölümün kaynak yönlendirmesiyle (hangi index’te aranacağını seçer) karıştırma. Karmaşıklık yönlendirme, ondan önce gelen soruyu sorar: retrieval yapılacak mı ve ne kadar.
• Fayda yapısaldır: kolay bir query’nin hiç ihtiyaç duymadığı mekanizmaya ödemeyi bırak, ağır mekanizmayı ona ihtiyaç duyan zor query için sakla. Kabaca yüzde 35 daha düşük gecikme ve yüzde 28 daha düşük maliyet gibi tedarikçi rakamları gösterge niteliğindedir, ölçülmüş değildir; gerçek tasarrufun trafik karışımına bağlıdır.
• Sınıflandırıcı yeni bir başarısızlık yüzeyidir ve tehlikeli yön eksik sınıflandırmadır: tek adımlıya yönlenen zor bir query eksik retrieval yapar ve sorunun yarısını sessizce cevaplar. O asimetriye göre ayarla ve yönlendiriciyi ancak ödünleşimi ölçebildiğinde ekle.

Referanslar

• Soyeong Jeong, Jinheon Baek, Sukmin Cho, Sung Ju Hwang ve Jong C. Park. “Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity.” NAACL 2024. arXiv:2403.14403. Tüm bölümün üzerine kurulduğu makale bu. Retrieval’ı query başına bir seçim olarak çerçeveliyor ve her sorunun karmaşıklığını tahmin etmesi için küçük bir sınıflandırıcı eğitiyor, sonra üç stratejiden birine gönderiyor: retrieval yok, tek retrieval ya da yinelemeli çok adımlı retrieval. Manşet sonucu bir gecikme yüzdesi değil, bir denge: açık alan soru-cevap benchmark’ları genelinde uyarlanabilir sistem, query başına doğru miktarda retrieval harcayarak taban çizgilerine göre “genel verimliliği ve doğruluğu artırıyor”. Doğruluğu, tek adımlı ile yinelemeli çok adımlı stratejilerin arasına düşüyor ve ortalamada saf çok adımlı yaklaşımdan daha az retrieval adımı kullanıyor (örneğin HotpotQA’da raporlanan koşu, yinelemeli taban çizgisinin kabaca 2.1 adımına karşı kabaca ortalama 1.6 adım). Makalenin gerçekten iddia ettiği şey, sabit bir maliyet tasarrufu sayısı değil, bu adım sayısı tarzındaki verimlilik; bu bölümdeki rakamların ölçülmüş garanti değil, gösterge niteliğinde tedarikçi raporları diye işaretlenmesinin sebebi de bu.

Sözlük

• Adaptive RAG (uyarlanabilir RAG): gelen her query’yi karmaşıklığına göre sınıflandıran ve her query için tek sabit pipeline çalıştırmak yerine onu uyan retrieval stratejisine yönlendiren bir RAG sistemi.
• Karmaşıklık sınıflandırıcısı (complexity classifier): bir query’yi, uzunluk, karşılaştırma kelimeleri, “and then” / “both” / “each of” gibi belirli görev-bağlacı ifadeleri ve soru işareti sayısı gibi ucuz sinyallerden bir rota etiketine (none, single veya multi) eşleyen küçük, hızlı bir fonksiyon (çıplak bir “and” tek başına multi’yi tetiklemez); burada bir kural bloğu, üretimde küçük eğitilmiş bir model.
• Yönlendirici (router): karmaşıklık sınıflandırıcısını çağıran ve sonra eşleşen pipeline’ı (doğrudan bir cevap, tek bir retrieve-then-generate ya da çok adımlı bir decompose-retrieve-synthesize) çalıştıran dağıtıcı.
• Retrieval’sız rota (no-retrieval route): havadan sudan sohbet ya da modelin zaten bildiği bir olgu için, index’e dokunmadan doğrudan cevaplanan yol; en ucuz rota.
• Tek adımlı rota (single-step route): 6. bölümün retrieve-augment-generate döngüsü; tek retrieval’ın cevaplayabileceği düz olgusal aramalar için kullanılır.
• Çok adımlı rota (multi-step route): 10. bölümün decompose-retrieve-synthesize kalıbı; hiçbir tek retrieval’ın cevaplayamayacağı karşılaştırmalar ve çok parçalı sorular için kullanılır.
• Karmaşıklık yönlendirme (complexity routing): bir query’yi, cevaplamanın ne kadar zor olduğuna (ne kadar retrieval gerektirdiğine) göre yönlendirmek; query’nin hangi index’e veya depoya gönderileceğini seçen kaynak yönlendirmeden farklıdır.
• Yanlış yönlendirme (misroute): bir query’yi yanlış yola gönderen sınıflandırıcı hatası; eksik sınıflandırma (tek adımlıya gönderilen zor bir query) pahalı yöndür, çünkü eksik retrieval yapar ve doğru görünürken sorunun bir kısmını cevaplar.

---

Frontier Track burada kapanıyor. Bu üç isteğe bağlı bölümde çekirdek seriyi token seviyesinde eşleştirme, bağlama duyarlı chunking ve şimdi de query başına yönlendirmeyle genişlettik; hepsi elle kuruldu ve hepsi zaten bildiklerinin üzerine oturuyor. Seri 16. bölüm, RAG vs Long Context’te devam ediyor; retrieval’ın en gürültücü rakibiyle, milyon token’lık context penceresiyle karşılaştığı yerde. Yani bu, ikinci bir veda değil, hafif bir uğurlama: artık enstrümanların yanında orkestra şefin de var. Git onu gerçek bir corpus’a doğrult, 11. bölümün öğrettiği gibi ölç ve bir şey inşa et.