Wat betekent betrouwbare AI voor Laravel-applicaties?
Betrouwbare AI in Laravel vraagt meer dan een API-call. In dit artikel lees je hoe je AI integreert met dezelfde kwaliteitseisen als de rest van je applicatie.
AI in maatwerksoftware: wat komt er écht bij kijken?
AI is krachtig, maar heeft een duidelijke beperking: het weet niet automatisch wat er binnen je organisatie speelt.
Een taalmodel kan algemene kennis gebruiken, teksten formuleren en verbanden leggen. Maar het kent niet vanzelf je interne processen, klantafspraken, projectdocumentatie, handleidingen, supporthistorie of dossiers.
Daar ontstaat een belangrijk verschil tussen AI gebruiken en AI toepassen binnen je eigen organisatie.
Want veel waardevolle AI-toepassingen draaien niet om algemene kennis, maar om eigen kennis.
Een medewerker wil weten wat er met een klant is afgesproken. Een supportteam wil snel relevante documentatie vinden. Een projectleider wil inzicht in openstaande actiepunten. Een klantportaal moet vragen kunnen beantwoorden op basis van specifieke dossiers. Een applicatie moet kunnen werken met actuele informatie uit de eigen database.
Daarvoor is alleen een AI-model niet genoeg. Je hebt een manier nodig om het model gecontroleerd toegang te geven tot relevante, actuele en toegestane informatie.
Een veelgebruikte aanpak hiervoor is RAG: Retrieval Augmented Generation.
Binnen ons R&D-traject NoardCode AI Gateway onderzoeken we hoe technieken zoals RAG kunnen helpen om grote hoeveelheden informatie beter te ontsluiten voor AI. Daarbij kijken we onder andere naar segmentatie, contextbeheer, promptoptimalisatie en retrieval-technieken om kwaliteitsverlies bij grote vraag- en antwoordreeksen te voorkomen.
RAG staat voor Retrieval Augmented Generation.
In gewone taal betekent dit: voordat AI een antwoord formuleert, zoekt het systeem eerst relevante informatie op uit een eigen kennisbron. Die opgehaalde informatie wordt vervolgens als context meegegeven aan het AI-model.
Het model antwoordt dus niet alleen op basis van algemene trainingsdata, maar gebruikt actuele informatie uit bijvoorbeeld:
Een simpele vergelijking:
Zonder RAG vraag je aan AI: "Wat weet jij hierover?"
Met RAG vraag je: "Gebruik deze relevante informatie uit onze eigen bronnen om deze vraag te beantwoorden."
Dat verschil is belangrijk.
Veel organisaties hebben veel kennis opgeslagen, maar die kennis is versnipperd.
Informatie staat in documenten, mailboxen, projectmanagementtools, CRM-systemen, klantportalen, wiki's, gedeelde mappen of databases. Mensen weten vaak wel dat de informatie ergens bestaat, maar niet altijd waar.
AI kan helpen om die kennis toegankelijker te maken. Niet door alles zomaar in een model te stoppen, maar door relevante informatie op het juiste moment op te halen.
RAG maakt het mogelijk om AI te laten werken met informatie die:
Daarmee wordt AI minder een algemene chatbot en meer een slimme toegangspoort tot eigen kennis.
Een veelgestelde vraag is: waarom trainen we een AI-model niet op alle bedrijfsinformatie?
Dat klinkt logisch, maar is vaak niet de beste eerste stap.
Een model trainen of fine-tunen kan nuttig zijn, maar heeft nadelen: het is complexer, kost meer tijd en geld, nieuwe informatie zit er niet automatisch in, oude of foutieve informatie is lastiger te verwijderen, rechten en toegangscontrole zijn moeilijker af te dwingen en bronverwijzingen zijn niet vanzelfsprekend.
Bij RAG blijft de kennis buiten het model staan. Het systeem haalt informatie op wanneer die nodig is.
Dat heeft een groot voordeel: je kunt bronnen aanpassen, verwijderen, vernieuwen of opnieuw indexeren zonder het hele model opnieuw te trainen.
Voor veel bedrijfsapplicaties is dat praktischer en veiliger.
Een RAG-proces bestaat meestal uit twee fasen: voorbereiden en gebruiken.
1. Voorbereiden van kennis
Eerst wordt informatie geschikt gemaakt voor gebruik door AI. Dat betekent bijvoorbeeld documenten uitlezen, tekst opschonen, informatie opdelen in kleinere stukken, metadata toevoegen, toegangsrechten vastleggen, embeddings maken en informatie opslaan in een zoekbare index of vector database.
Dit klinkt technisch, maar het doel is eenvoudig: informatie moet zo worden voorbereid dat het systeem later snel relevante stukken kan terugvinden.
2. Gebruiken bij een vraag
Wanneer een gebruiker een vraag stelt, gebeurt er iets anders dan bij een gewone chatbot. Het systeem analyseert de vraag, zoekt relevante stukken informatie op, filtert op rechten, actualiteit en relevantie, geeft de geselecteerde context mee aan het AI-model, laat het model een antwoord formuleren en toont eventueel welke bronnen zijn gebruikt.
Het AI-model wordt dus gevoed met context uit je eigen organisatie.
Stel dat een medewerker vraagt: "Wat hebben we met klant X afgesproken over support na oplevering?"
Zonder RAG moet een AI-model gokken op basis van algemene kennis. Dat is onbruikbaar, want het model kent klant X niet.
Met RAG kan het systeem zoeken in relevante bronnen: de offerte, het contract, projectnotities, e-mailverslagen, SLA-afspraken, supporttickets en interne overdrachtsdocumentatie.
Daarna krijgt het model alleen de relevante passages mee en kan het bijvoorbeeld antwoorden met een concrete afspraak inclusief nazorg en supportgrenzen.
Belangrijk is dat zo'n antwoord herleidbaar moet zijn. De gebruiker moet kunnen zien waarop het antwoord gebaseerd is.
Daar zit veel van de waarde van RAG: niet alleen sneller antwoord, maar ook beter controleerbare antwoorden.
RAG wordt soms gezien als zoeken plus AI. Dat is deels waar, maar het doet de complexiteit tekort.
Een gewone zoekmachine geeft documenten of resultaten terug. RAG moet bepalen welke informatie bruikbaar is voor een antwoord.
Dat vraagt om extra keuzes: welke stukken informatie zijn inhoudelijk relevant, welke bron is het meest betrouwbaar, is de informatie actueel, heeft de gebruiker toegang, hoeveel context past in het model, welke context moet eerst komen, zijn er tegenstrijdige bronnen en moet het model antwoorden of aangeven dat informatie ontbreekt.
Een goede RAG-implementatie is dus geen simpele zoekbalk. Het is een contextlaag tussen bedrijfsdata en AI.
Een AI-model kan alleen goed antwoorden als de opgehaalde context goed is.
Daarom is de voorbereiding van informatie cruciaal. In deel 3 van deze serie schreven we al over het slim opdelen van grote hoeveelheden data. Dat is direct relevant voor RAG.
Als documenten verkeerd worden opgeknipt, kan context verloren gaan. Als metadata ontbreekt, kan oude informatie als actueel worden gezien. Als rechten niet worden meegenomen, kan AI informatie tonen die niet zichtbaar had mogen zijn. Als de zoekindex slecht is ingericht, krijgt het model de verkeerde context.
RAG lost dus niet automatisch alles op. Het maakt AI pas waardevol wanneer de onderliggende informatie goed is georganiseerd.
Metadata is bij RAG vaak net zo belangrijk als de inhoud zelf.
Een tekstfragment kan inhoudelijk relevant lijken, maar toch niet geschikt zijn om te gebruiken. Bijvoorbeeld omdat het document verouderd is, bij een andere klant hoort of alleen voor een specifieke rol zichtbaar mag zijn.
Daarom wil je bij elk stukje informatie weten waar het vandaan komt, wanneer het is aangemaakt of gewijzigd, bij welke klant of entiteit het hoort, welke status het heeft, wie het mag zien, hoe betrouwbaar de bron is en of er een actuelere versie is.
Zonder metadata wordt retrieval al snel rommelig. Met metadata kun je veel gerichter bepalen welke informatie aan AI wordt meegegeven.
Een belangrijk aandachtspunt is autorisatie.
Als een medewerker via de normale applicatie geen toegang heeft tot bepaalde informatie, mag AI die informatie ook niet gebruiken om een antwoord te geven.
Een RAG-laag moet dus dezelfde rechten respecteren als de applicatie zelf. Niet alleen bij het tonen van bronnen, maar al bij het ophalen van context.
Anders kan AI een onbedoelde achterdeur worden naar afgeschermde informatie.
Een veelgenoemd voordeel van RAG is dat het hallucinaties kan verminderen. Dat klopt, maar alleen onder voorwaarden.
Als een AI-model relevante en betrouwbare context krijgt, is de kans kleiner dat het zelf informatie gaat verzinnen. Maar het model kan nog steeds fouten maken in interpretatie, samenvatting of formulering.
Daarom moet je RAG combineren met duidelijke instructies en controles. Bijvoorbeeld: antwoord alleen op basis van opgehaalde bronnen, geef aan wanneer informatie ontbreekt, noem onzekerheden, verwijs naar bronnen en maak onderscheid tussen feit en interpretatie.
RAG is dus een belangrijke bouwsteen, maar geen garantieknop.
Een goede RAG-toepassing moet niet altijd proberen een antwoord te geven.
Soms is het juiste antwoord: "Ik heb hiervoor onvoldoende informatie gevonden."
Dat is beter dan een overtuigend maar onjuist antwoord.
Daarom onderzoeken we ook hoe AI-systemen kunnen omgaan met ontbrekende of onzekere context. Wanneer is de opgehaalde informatie voldoende? Wanneer moet het systeem doorvragen? Wanneer moet een gebruiker worden gewaarschuwd dat het antwoord onzeker is?
Voor Laravel- en maatwerksoftware is RAG interessant omdat veel relevante kennis al in de applicatie aanwezig is.
Denk aan Eloquent-modellen, relationele databases, klantdossiers, bijlagen, opmerkingen, workflows, tickets, auditlogs, documentgeneratie, gebruikersrollen en permissies.
De uitdaging is om die informatie op een gecontroleerde manier beschikbaar te maken voor AI.
Dat vraagt om keuzes in architectuur: welke data wordt geindexeerd, hoe vaak de index wordt bijgewerkt, hoe wijzigingen verwerkt worden, welke metadata meegaat, hoe rechten worden toegepast, hoe bronnen gekoppeld worden aan antwoorden, hoe logging geregeld wordt en hoe gevoelige data beschermd blijft.
Daarmee wordt RAG geen losse plugin, maar een onderdeel van de softwarearchitectuur.
Binnen de NoardCode AI Gateway onderzoeken we RAG niet als los trucje, maar als onderdeel van een bredere infrastructuurlaag.
RAG raakt aan meerdere onderzoekslijnen: bij connection management kan RAG helpen om ontbrekende context op te halen, bij grote datasets helpt RAG om relevante context te selecteren, bij beveiliging moet RAG rekening houden met gevoelige data en logging, bij hybride AI speelt de vraag waar retrieval plaatsvindt en bij energie-efficientie voorkomt goede contextselectie onnodig grote prompts.
In het projectplan wordt RAG specifiek genoemd bij het efficient verwerken van grote datasets en het voorkomen van kwaliteitsverlies bij grote vraag- en antwoordreeksen.
Voor organisaties die AI willen toepassen op eigen kennis, is de belangrijkste vraag niet: welk AI-model moeten we gebruiken?
Maar eerder: hoe zorgen we dat het AI-model de juiste informatie krijgt?
Dat vraagt om inzicht in je informatiehuishouding: waar staat kennis, welke bronnen zijn betrouwbaar, welke informatie is actueel, wie mag wat zien, welke data is gevoelig, hoe wil je antwoorden controleren en hoe ga je om met ontbrekende informatie?
RAG maakt AI pas echt waardevol wanneer deze vragen goed worden beantwoord.
De belangrijkste les is dat AI met eigen kennis niet begint bij het model, maar bij de context.
Een goed RAG-systeem zorgt ervoor dat AI niet zomaar algemene antwoorden geeft, maar werkt met relevante, actuele en toegestane informatie uit je eigen organisatie.
Maar dat vraagt om meer dan documenten uploaden. Het vraagt om structuur, metadata, rechten, logging, bronverwijzingen en kwaliteitscontrole.
Daarmee wordt RAG een belangrijke stap richting AI die niet alleen slim klinkt, maar ook bruikbaar, controleerbaar en betrouwbaar is.
RAG maakt het mogelijk om AI toegang te geven tot je eigen kennis, zonder die kennis volledig in een model te hoeven trainen.
Dat biedt veel kansen voor organisaties die AI willen inzetten binnen klantportalen, interne systemen, kennisbanken, administratieve processen of maatwerkapplicaties.
Maar de waarde van RAG hangt af van de kwaliteit van de contextlaag eromheen.
Binnen de NoardCode AI Gateway onderzoeken we hoe zo'n contextlaag betrouwbaar, veilig en schaalbaar kan worden ingericht. Want AI wordt pas echt interessant wanneer het niet alleen taal begrijpt, maar ook de juiste kennis op het juiste moment kan gebruiken.
In de volgende blog gaan we dieper in op privacy: waarom gevoelige data al beschermd moet worden voordat een prompt naar een AI-model gaat.