Wat RAG is, en wanneer u het echt nodig heeft

Iemand heeft u verteld dat u RAG nodig heeft. Een leverancier misschien, een ontwikkelaar, of een slide met een schema erop. Het loont om te weten wat het werkelijk is voordat u er een koopt, want het begrip kost een alinea om uit te leggen en de versie die verkocht wordt, kost maanden onderhoud.

Retrieval-augmented generation houdt dit in: voordat het model antwoordt, doorzoekt uw systeem uw eigen documenten, zoekt de passages die relevant lijken, en plakt die samen met de vraag in de prompt. Het model antwoordt vervolgens uit die tekst en niet uit het geheugen.

Dat is het hele idee. Er wordt niets aan het model toegevoegd, het model leert niets, en volgende week weet het niets over uw organisatie wat uw zoekfunctie er niet bij heeft geleverd. De kwaliteit van een RAG-systeem is de kwaliteit van zijn zoekfunctie, en daarom heeft het meeste werk niets met AI te maken.

De pijplijn, stap voor stap

1. Bepaal wat leidend is. Kies vóór enige techniek welke documenten de bron van waarheid zijn en ruim de rest op. Twee versies van hetzelfde beleid in de index is het gebrek dat de meeste foute antwoorden veroorzaakt, en geen enkele techniek verderop haalt dat eruit.
2. Knip de documenten in passages. Een passage is de eenheid die wordt opgehaald, dus die moet op zichzelf te begrijpen zijn. Houd koppen bij hun tekst, houd tabellen bij hun kolomkoppen, en mik op stukken die iemand als antwoord zou kunnen lezen. Knippen op een vast aantal tekens, de standaard in de meeste handleidingen, is precies hoe een prijstabel losraakt van de regel die zegt waar die prijzen bij horen.
3. Zet de passages om in vectoren en sla ze op. Hier verschijnt de vectordatabase. Draait u al Postgres, dan is de pgvector-extensie meestal genoeg, en is een aparte dienst een extra systeem om te beheren voor voordelen die u op uw schaal misschien nooit merkt.
4. Zoek met beide methoden. Vectorzoeken vindt passages die hetzelfde betekenen in andere woorden. Trefwoordzoeken vindt exacte reeksen: artikelnummers, productcodes, verwijzingen naar een artikel, de naam van een formulier. Zakelijke vragen zitten vol exacte reeksen, dus hybride zoeken wint het voor de meeste verzamelingen van puur vectorzoeken.
5. Herordenen. Haal meer kandidaten op dan u nodig heeft, laat een herordenend model ze rangschikken op hoe goed ze de gestelde vraag beantwoorden, en houd de beste drie of vier over. Deze stap is goedkoop en tilt een middelmatig systeem meestal naar een goed systeem.
6. Genereer met regels. Antwoord alleen uit de aangeleverde passages, verwijs per bewering naar de passage waar die vandaan komt, en zeg het gewoon wanneer het antwoord er niet in staat. Die verwijzing telt zwaarder dan hij oogt: hij laat een lezer controleren, en hij maakt foute antwoorden vindbaar in plaats van onzichtbaar.
7. Evalueer het ophalen los van het antwoord. Dit zijn twee verschillende fouten met twee verschillende oplossingen. Neem vijftig echte vragen, leg vast welke passage gevonden had moeten worden, en meet hoe vaak dat lukte. Komt de juiste passage er nooit uit, dan redt geen enkele promptwijziging het antwoord.
8. Houd de index actueel. Herindexeer zodra documenten wijzigen, en weet hoe lang die vertraging is. Dit is met afstand de meest voorkomende productiefout, en hij komt hieronder terug.

Wanneer RAG niet het juiste antwoord is

Uw verzameling is klein. Past alles wat de assistent nodig heeft ruim in het contextvenster van het model, plak het dan in de prompt en sla de pijplijn helemaal over. Een handboek van dertig pagina's heeft geen vectordatabase nodig, en de versie zonder index kan ook niet verouderen.

De gegevens zijn gestructureerd. "Hoeveel orders hebben we vorige maand verstuurd" is een databasevraag. Uw ordertabel omzetten in vectoren en een zoeksysteem laten tellen, is duur, traag en fout op manieren die lastig op te merken zijn. Staat het antwoord in rijen en kolommen, geef het model dan gereedschap dat een query uitvoert, of schrijf die query zelf.

De feiten veranderen voortdurend. Voorraad, prijzen, levertijden en saldi hoort u op het moment van vragen bij het bronsysteem op te halen. Een index is een kopie, en een kopie van een getal dat per uur verandert, is een risico.

Eén document per keer. Gaat de taak over vragen bij het contract dat een gebruiker zojuist heeft geüpload, dan is dat geen ophalen maar lezen. Stuur het document mee.

De ongemakkelijke versie: een flink deel van de gesprekken over "wij hebben RAG nodig" eindigt bij het opruimen van documenten, een zoekveld en helemaal geen model. Kan uw team de actuele versie van een regeling vandaag niet vinden, dan geeft een taalmodel ze zelfverzekerde antwoorden uit de verkeerde versie.

Het scenario om voor ogen te houden

Alles werkt. Het ophalen vindt een passage, die passage bestaat echt, de verwijzing wijst naar een bestaand intern document, en het antwoord klopt niet, want dat document is in maart vervangen en niemand heeft de oude versie weggehaald uit de map die de indexeerder uitleest.

Deze fout is erger dan een zichtbare misser, om twee redenen. Hij is zelfverzekerd, en hij is in de verkeerde richting controleerbaar: de bronverwijzing laat het antwoord gecontroleerd lijken. Zowel uw medewerkers als uw klanten behandelen het als nagekeken.

De oplossing is weinig spannend en vooral een kwestie van beheer. Eén leidende plek per documentsoort, een zichtbare datum van laatste herziening, een index die herbouwt bij wijziging in plaats van op een maandschema, en een steekproef die juist zoekt naar antwoorden die verwijzen naar documenten die weg hadden moeten zijn. Dat is dezelfde discipline als hallucinaties beheersen in productie: het model is niet het deel dat u beheerst, de invoer en de controles wel.

Wat het kost om het te onderhouden

De bouw duurt enkele weken. De verplichting zit in de index, de evaluatieset en de documenthygiëne eronder, en die houden niet op. Begroot ze als terugkerende posten in plaats van projectkosten, net als in de rest van het driejarige kostenbeeld.

Goed gedaan is dit wat een eigen AI-assistent de moeite waard maakt: antwoorden uit uw eigen materiaal, met een verwijzing naar de alinea waar ze vandaan komen. De overige begrippen behandelen de aangrenzende onderdelen.

Veelgestelde vragen

Is RAG beter dan fine-tuning?

Ze lossen verschillende problemen op. RAG geeft een model toegang tot informatie die het niet had, fine-tuning verandert hoe een model zich gedraagt, zoals toon, opmaak of een nauwe classificatietaak. Is de klacht "het kent onze spullen niet", dan wilt u ophalen. Is het "het weet het wel, maar antwoordt in de verkeerde vorm", dan komt fine-tuning in beeld.

Hebben we een vectordatabase nodig?

Niet per se. Draait u al Postgres, dan verwerkt pgvector tienduizenden passages moeiteloos. Een aparte vectordienst verdient zijn plek bij grotere schaal of specifieke filterwensen, en tot die tijd is het een extra systeem om te hosten, te beveiligen en te betalen.

Waarom citeert onze assistent een verouderd document?

Omdat het nog in de index staat. Of de bronmap bevat de vervangen versie, of de index is niet herbouwd sinds het document wijzigde. Herstel eerst de bron, dan het verversingsschema, en voeg een controle toe die zoekt naar verwijzingen naar documenten die weg hadden moeten zijn.

Hoe weten we of het ophalen werkt?

Meet het los van het antwoord. Neem vijftig echte vragen, noteer per vraag welke passage gevonden moest worden, en controleer hoe vaak die in de opgehaalde set zit. Dat getal vertelt u of u aan de zoekfunctie of aan de prompt moet werken, en zonder dat getal gokt u naar allebei.