Wat we hebben geleerd van het bouwen van productie-RAG-systemen voor enterprise-klanten

Een RAG-demo is eenvoudig: embed een aantal documenten, haal de beste matches op, stop ze in een prompt. RAG in productie is een compleet andere discipline, en de meeste lastige problemen bevinden zich buiten het model.

Chunkingstrategie is belangrijker dan modelkeuze. Slecht gechunkte documenten, midden in een zin afgekapt, ontbrekende kopjes, geen metadata, leveren zelfverzekerd foute antwoorden op, ongeacht welke LLM eronder ligt. We besteden onevenredig veel tijd vroeg in een traject aan documentstructuur en metadata, voordat we de retrieval-pipeline aanraken.

Evaluatie moet worden opgebouwd voordat de functie live gaat, niet nadat gebruikers klagen. We bouwen vroeg in elk project een kleine, gelabelde evaluatieset op basis van echte zoekopdrachten, en voeren deze opnieuw uit bij elke wijziging in prompt of retrieval, zodat regressies worden opgemerkt voordat een klant ze vindt.

Zuivere vectorsimilariteitszoekopdrachten falen bij zoekopdrachten die afhangen van een exacte term, een productcode of een naam waar het embeddingmodel niet veel gewicht aan geeft. Hybride zoeken, dat vectorsimilariteit combineert met keyword-/BM25-matching en de samengevoegde resultaten herrangschikt, presteert consistent beter dan elke aanpak afzonderlijk zodra de documentenset groot is of de zoekopdrachten specifiek worden. Het kost meer om te bouwen en af te stemmen, en dat is het waard voor alles wat verder gaat dan een kleine, homogene kennisbank.

Metadatafiltering is wat retrieval betrouwbaar maakt op schaal, niet alleen nauwkeurig. Door chunks te taggen met bron, datum, toegangsniveau en documenttype kun je retrieval afbakenen voordat de similariteitszoekopdracht überhaupt draait, wat belangrijk is voor zowel antwoordkwaliteit (geen verouderd beleidsdocument ophalen) als toegangscontrole (geen document ophalen dat deze gebruiker niet zou mogen zien, ongeacht hoe goed het overeenkomt met de zoekopdracht).

Waarborgen en betrouwbaarheidssignalen zijn net zo belangrijk als nauwkeurigheid. Een systeem dat zegt "ik weet het niet zeker, hier is iemand die je kunt vragen" presteert beter dan een systeem dat zelfverzekerd en fout antwoordt, vooral in support- en compliance-achtige toepassingen waar een fout antwoord meer kost dan een traag antwoord.

Observability moet vanaf dag één worden ingebouwd, niet pas worden toegevoegd als er iets misgaat. We loggen de opgehaalde chunks samen met het gegenereerde antwoord bij elke productiezoekopdracht, niet alleen het eindresultaat, want als een antwoord fout is, ligt de oorzaak vrijwel altijd bij retrieval, en je kunt niet debuggen wat je niet hebt vastgelegd.

Kosten en latency zijn productbeslissingen, geen bijzaak van de infrastructuur. Welk model welke zoekopdracht afhandelt, wanneer je cachet, en wanneer een kleiner model goed genoeg is, zijn beslissingen die we expliciet nemen, omdat ze de unit economics van de functie veranderen.