RAG versus lange context: welke moet je nu echt gebruiken?

Zodra een model een miljoen tokens in één prompt kan lezen, is het verleidelijk om retrieval dood te verklaren: geef het gewoon alles. Een zorgvuldige studie laat zien dat het antwoord interessanter is dan dat.

TL;DR

Met voldoende middelen presteert het hele document aan een langecontextmodel voeren doorgaans beter dan retrieval op antwoordkwaliteit.
Retrieval (RAG) is dramatisch goedkoper omdat het veel minder tokens verstuurt.
Een simpele router die makkelijke vragen naar RAG stuurt en moeilijke naar lange context, herwint het grootste deel van de kwaliteit tegen een fractie van de kosten.

Twee manieren om een model context te geven

Er zijn twee brede strategieën om een antwoord in je materiaal te verankeren. Retrieval-augmented generation (RAG) doorzoekt je gegevens, haalt de paar meest relevante fragmenten eruit en zet alleen die in de prompt. Lange context slaat retrieval over en zet het hele document (of vele documenten) rechtstreeks in het venster. Toen vensters voorbij de honderdduizend tokens groeiden, gingen mensen zich afvragen of RAG al die extra complexiteit nog wel waard was.

Wat het onderzoek laat zien

In Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach zetten onderzoekers van Google DeepMind de twee benaderingen rechtstreeks tegenover elkaar op de drie sterkste langecontextmodellen die destijds beschikbaar waren — Gemini-1.5-Pro, GPT-4o en GPT-3.5-Turbo — over een reeks QA-datasets met lange documenten, afkomstig uit gevestigde benchmarks. Voor elke vraag vergeleken ze twee opstellingen: het hele document aan het model voeren (lange context) tegenover de top-k-fragmenten ophalen en alleen die voeren (RAG).

Hun belangrijkste bevinding: wanneer het model sterk is en je het je kunt veroorloven om het alles te voeren, levert lange context gemiddeld consequent betere antwoorden op dan RAG. Retrieval laat soms net het ene fragment vallen dat het antwoord bevatte; het hele document in het venster zetten neemt die faalmodus weg. Maar de twee benaderingen waren ook sterk gecorreleerd — bij de overgrote meerderheid van de vragen gaven ze hetzelfde antwoord, een feit dat de auteurs later zouden benutten.

De adder onder het gras zijn de kosten. Lange context betekent dat je bij elke afzonderlijke query betaalt om tienduizenden of honderdduizenden tokens te verwerken — zelfs als het antwoord in één alinea stond.

RAG daarentegen verstuurt slechts een handjevol opgehaalde passages en is dus veel goedkoper per query. De studie schetst dit als een echte afweging in plaats van een winnaar: lange context koopt kwaliteit, RAG koopt efficiëntie.

De kwalitatieve afweging: lange context leidt op kwaliteit, RAG op kosten, en een router mikt op de linkerbovenhoek. De posities zijn illustratief.

De hybride: routeer, kies niet

Die correlatie is de opening. De auteurs stellen Self-Route voor, een pijplijn in twee stappen die het model per query zelf laat beslissen welke route het neemt:

Eerst RAG, met een nooduitgang. Geef het model de opgehaalde fragmenten en vraag het om óf te antwoorden óf de vraag „onbeantwoordbaar” te verklaren op basis van wat het te zien kreeg — niet gokken.
Escaleer alleen het onbeantwoordbare. Vragen die het model als onbeantwoordbaar markeert, worden opnieuw uitgevoerd met het hele document in het venster; al het andere houdt het goedkope RAG-antwoord.

Omdat RAG en lange context het bij de meeste vragen al eens zijn, bereikt slechts een minderheid ooit de dure route. Het resultaat is een antwoordkwaliteit die dicht bij altijd-lange-context ligt tegen kosten die dicht bij altijd-RAG liggen.

De juiste vraag is zelden „RAG of lange context?” — het is „wat heeft deze specifieke query nodig?”

Wat het voor jou betekent

Voor iedereen die bovenop een LLM bouwt, volgen er twee dingen. Ten eerste maakt een groter contextvenster retrieval niet zinloos — het verandert wanneer je ernaar grijpt. Ten tweede is de slimme standaard niet „gooi altijd alles erin”, maar „houd het materiaal geordend zodat het systeem het juiste stuk kan ophalen, en betaal alleen voor het geheel wanneer een vraag daar echt om vraagt.”

Waar FocusLM in past

FocusLM bewaart je materiaal als een gestructureerd geheugen in plaats van één almaar groeiende prompt. Die structuur is wat de goedkope route mogelijk maakt: de meeste vragen worden beantwoord vanuit de paar relevante, geciteerde bestanden, en de bredere context staat klaar wanneer een vraag daar echt om vraagt — dezelfde routeer-in-plaats-van-kiezen-logica, toegepast op een geheugen dat met je meegroeit.

Sources