RAG-systeem of AI-assistent bouwen: checklist voor de scope

De meeste projecten met een AI-assistent die tegenvallen, mislukken niet door het model. Ze mislukken omdat niemand het eens was over waar de assistent voor dient, omdat de onderliggende content onvolledig of verouderd was, omdat er pas achteraf over rechten is nagedacht, of omdat er geen manier was om te zien of een wijziging het beter of slechter maakte. De keuze van het model doet ertoe, maar is meestal een van de makkelijkere beslissingen.

Deze checklist bundelt de vragen die wij doorlopen voordat we een systeem met retrieval-augmented generation (RAG) of een AI-assistent op bedrijfsdata bouwen. Gebruik hem om een intern project voor te bereiden, om een leverancier te briefen of om te controleren of een offerte die je hebt ontvangen de essentie afdekt. Je hoeft niet op dag één elk antwoord te hebben, maar je moet wel weten welke vragen nog openstaan.

1. Use case en succescriteria#

Leg dit vast voordat iemand een notebook opent of modellen gaat vergelijken.

• Eén primaire taak. Benoem de ene taak die de assistent als eerste goed moet doen, bijvoorbeeld productvragen van supportmedewerkers beantwoorden of clausules vinden in leverancierscontracten. Andere use cases kunnen volgen zodra de eerste is gemeten; als je er bij de start meerdere door elkaar haalt, vertroebel je zowel de eisen als de evaluatie.
• Gebruikers en hun situatie. Beschrijf wie de vragen stelt, hoe vaak, in welke taal en op welk apparaat, en wat diegene met het antwoord doet. Een interne expert die bronnen controleert heeft iets anders nodig dan een klant die direct op het antwoord afgaat.
• Echte vragen met ideale antwoorden. Verzamel 20–50 echte vragen uit tickets, e-mails of chatlogs, en laat een domeinexpert het ideale antwoord opschrijven en de bron noemen waar het uit moet komen. Deze set bepaalt wat ‘goed’ betekent en vormt de kiem van je evaluatieset.
• Buiten scope en weigeringen. Zet op een rij wat de assistent niet mag doen: juridisch, medisch of financieel advies geven, verder gaan dan zijn bronnen, toezeggingen doen namens het bedrijf. Bepaal wat hij in plaats daarvan moet zeggen en waar hij de gebruiker naartoe moet verwijzen.
• Nulmeting van het huidige proces. Leg vast hoe het werk vandaag wordt gedaan, hoelang het duurt, wie het doet en wat het kost. Zonder nulmeting is ‘de assistent helpt’ een mening en geen resultaat.

2. Databronnen#

De kwaliteit van de antwoorden wordt begrensd door de kwaliteit en de toegankelijkheid van de content erachter.

• Inventaris van bronnen. Maak een lijst van elke bron die de assistent moet gebruiken: wiki's, mappen in SharePoint of Google Drive, ticketsystemen, databases, pdf's, websites. Noteer per bron hoe je erbij kunt (API, export, crawl) en of die toegang is toegestaan.
• Formaten en documentkwaliteit. Controleer op gescande pdf's die OCR nodig hebben, complexe tabellen, formulieren, slides en afbeeldingen met essentiële inhoud. Bij tabellen en scans verliezen naïeve pipelines de meeste informatie, dus neem daar vroeg steekproeven van.
• Eigenaarschap en actualiteit. Wijs voor elke bron een eigenaar aan en leg vast hoe vaak de bron verandert. Als niemand eigenaar is van de content, lost ook niemand de foute antwoorden op die eruit voortkomen.
• Duplicaten, versies en talen. Breng verouderde kopieën, concepten en parallelle versies van hetzelfde beleidsdocument in kaart en bepaal welke leidend is. Noteer de talen van zowel documenten als vragen, want retrieval over taalgrenzen heen moet je expliciet testen.

3. Toegangscontrole en privacy#

Regel dit voordat er echte data je systemen verlaat.

• Rechten doorgevoerd in retrieval. Als gebruikers alleen bepaalde documenten mogen zien, moet retrieval filteren op de rechten van de gebruiker die de vraag stelt, gesynchroniseerd vanuit de bronsystemen. Instructies in de prompt of erop vertrouwen dat het model content achterhoudt, is geen toegangscontrole.
• Persoonsgegevens en rechtsgrond. Breng persoonsgegevens in documenten, vragen en logs in kaart en documenteer de AVG-rechtsgrond en het doel van de verwerking. Betrek je functionaris gegevensbescherming aan het begin, niet bij de lancering.
• Contract met de provider en dataresidentie. Sluit een verwerkersovereenkomst met elke model- en infrastructuurprovider, bekijk hun subverwerkers en ga na of de verwerking in een EU-regio kan blijven als je dat eist. Laat schriftelijk bevestigen dat je data niet wordt gebruikt om de modellen van de provider te trainen.
• Bewaartermijnen, logging en maskering. Bepaal hoelang prompts, opgehaalde passages en antwoorden worden bewaard, wie ze kan lezen en of persoonsgegevens vóór het loggen worden gemaskeerd. Logs zijn nodig voor debugging en evaluatie, dus het doel is gecontroleerd bewaren, niet helemaal niets loggen.

4. Ontwerp van de retrieval#

De meeste foute antwoorden in RAG-systemen zijn terug te voeren op retrieval en niet op het model; bij een klein, stabiel corpus kan een lange context met prompt caching retrieval helemaal vervangen (zie RAG vs fine-tuning).

• Chunking langs de documentstructuur. Splits content op koppen, secties, lijstitems en tabelgrenzen in plaats van op een vast aantal tekens. Bewaar het koppenpad bij elke chunk, zodat een passage ook op zichzelf nog te begrijpen is.
• Metadata en filters. Sla bij elke chunk titel, bron, sectie, datum, taal, versie en toegangsgroepen op. Metadata maakt filteren op rechten, regels als ‘alleen de nieuwste versie’ en bruikbare bronvermeldingen mogelijk.
• Hybride zoeken en reranking. Combineer zoeken op trefwoorden voor exacte termen zoals productcodes, artikelnummers en namen met vector search over embeddings voor betekenis, en rerank daarna de gecombineerde kandidaten. Test elke stap met je voorbeeldvragen in plaats van aan te nemen dat de standaardinstellingen goed genoeg zijn.
• Bronvermelding verplicht. Eis dat de assistent de passages citeert die hij heeft gebruikt, met een link naar het brondocument en de sectie. Dankzij bronvermeldingen kunnen gebruikers antwoorden verifiëren en kunnen reviewers zien of een fout antwoord uit slechte retrieval of slechte generatie voortkwam.

5. Keuze van model en provider#

Kies het model zodra je een evaluatieset hebt, zodat de beslissing op jouw data rust en niet op generieke benchmarks.

• Hostingoptie. Vergelijk een gehoste API, dezelfde of vergelijkbare modellen in een EU-cloudregio, en een zelf gehost open-weight model op je eigen infrastructuur. Elke optie verschuift de balans tussen antwoordkwaliteit, controle over data, operationele inspanning en kosten.
• Latency en kosten per query. Meet de end-to-end responstijd en de kosten per beantwoorde vraag op je eigen voorbeeldvragen, inclusief retrieval, reranking en input- en outputtokens. Prompt caching en kleinere modellen voor eenvoudige stappen kunnen deze cijfers flink veranderen.
• Fallback en lock-in. Bedenk wat er gebeurt als de provider down is of een model uitfaseert: een tweede provider, een beperkte modus of een duidelijke foutmelding. Houd prompts, de evaluatieset en de retrievallaag providerneutraal, zodat overstappen een configuratiewijziging plus een eval-run is en geen herbouw.

6. Evaluatie#

Als je kwaliteit niet kunt meten, kun je haar niet verbeteren en de beslissing om live te gaan niet verdedigen.

• Eerst de evalset, dan bouwen. Maak van de echte vragen uit sectie 1 een evaluatieset onder versiebeheer, met verwachte antwoorden en verwachte bronnen, en vul die aan met moeilijke gevallen en randgevallen. Bouw hem vóór het eerste prototype, niet na de eerste demo.
• Kwaliteit van retrieval en antwoord. Meet afzonderlijk of de juiste passages zijn opgehaald en of het antwoord correct, volledig en trouw aan die passages is. Controleer de nauwkeurigheid van de bronvermeldingen: de geciteerde passage moet de bewering ook echt onderbouwen.
• Tests op weigeringen en prompt injection. Neem vragen op die de assistent moet weigeren en vragen die zijn bronnen niet kunnen beantwoorden, en verifieer dat hij dat zegt in plaats van te gokken. Voeg documenten en inputs toe die zijn instructies proberen te overschrijven of data van andere gebruikers proberen te ontfutselen, en bevestig dat die pogingen mislukken.
• Regressieruns en menselijke review. Draai bij elke wijziging in prompts, modellen, chunking of data de volledige evalset en vergelijk de resultaten met de vorige run. Automatisch beoordelen met een model versnelt dit, maar een domeinexpert hoort de resultaten regelmatig steekproefsgewijs te controleren.

7. Integratie en beheer#

De assistent moet ergens wonen, en iemand moet hem na de lancering draaiende houden.

• Kanaal en inloggen. Bepaal waar de assistent komt te staan: een widget op de website, Slack of Microsoft Teams, een interne tool of een bestaand ticketsysteem. Gebruik je bestaande SSO, zodat identiteit en rechten uit dezelfde bron komen als overal elders.
• Overdracht aan een mens en feedback. Leg vast hoe een gebruiker bij een persoon terechtkomt als de assistent niet kan helpen, waarbij het gesprek wordt meegegeven. Voeg eenvoudige feedbackknoppen toe en leid negatieve feedback door naar de evaluatieset.
• Kostenmodel en monitoring. Schat de kosten per query en per maand in bij verwacht gebruik en bij piekgebruik, en stel budgetalerts in. Monitor latency, foutpercentages, weigeringspercentages en gebruikersfeedback, met logs die zijn gemaskeerd zoals afgesproken in sectie 3.
• Herindexeren, eigenaarschap van content en incidenten. Automatiseer het herindexeren wanneer brondocumenten veranderen, ook bij verwijderingen, zodat de assistent nooit ingetrokken content citeert. Benoem wie contentproblemen oplost en definieer een incidentproces voor foute, schadelijke of gelekte antwoorden, inclusief hoe je de assistent snel uitzet.

8. Go/no-go-criteria#

Spreek de beslisregels af voordat de resultaten binnenkomen, zodat de beslissing niet wordt genomen op basis van een goede demo.

• Drempelwaarden vooraf afgesproken. Leg minimumniveaus vast voor de correctheid van antwoorden en de nauwkeurigheid van bronvermeldingen op de evalset, een acceptabele latency en acceptabele kosten per query, en nultolerantie voor antwoorden die rechtengrenzen overschrijden. Vergelijk de resultaten met de nulmeting uit sectie 1.
• Pilot met vaste looptijd en een duidelijke exit. Draai een pilot met een kleine groep echte gebruikers gedurende een vaste periode, met een bij naam genoemde persoon die de knoop doorhakt. De scope verkleinen of stoppen is een legitieme uitkomst, en veel goedkoper dan er na een volledige uitrol achter komen.

Hoe wij kunnen helpen#

Wil je deze checklist samen met ons doorlopen, dan is onze AI Proof-of-Value Sprint met vaste scope de meest directe route. In twee weken bepalen we samen met jou de scope van de use case, bouwen we een RAG- of agent-prototype op je eigen data, maken we een evaluatieset, stellen we een kostenmodel op en leveren we een go/no-go-rapport waarmee je naar je beslissers kunt. Details vind je op onze pagina met prijzen en bij onze diensten voor AI & automatisering.

Voordat een van je documenten een model bereikt, spreken we met je af hoe er met data wordt omgegaan; je kunt vooraf nalezen hoe we in AI-projecten met klantdata omgaan. Begin je liever met een gesprek, vraag dan een gratis raming aan en beschrijf de use case die je in gedachten hebt.