RAG in Xcellerate OPS: AI die zoekt op betekenis

In het kort: Xcellerate OPS draait voortaan retrieval-augmented generation (RAG) bovenop een vectorindex van je eigen kennis. Je kennisbank, playbooks, klantdocumentatie, productcatalogus, nagekeken oplossingen en ticketcategorieën worden met het embeddingmodel van Mistral omgezet in embeddings en opgeslagen in de eigen database van je werkruimte. Wanneer een AI-collega zoekt, combineert OPS het klassieke zoeken op trefwoorden met zoeken op betekenis. Zo vindt hij het artikel dat de vraag beantwoordt, ook als het ticket andere woorden gebruikt. Tekst wordt afgeschermd vóór hij wordt omgezet, klantspecifieke documentatie verschijnt alleen voor die klant, en zoeken op trefwoorden blijft werken als er in het vectorgedeelte iets misloopt.

Wat is RAG?

Een groot taalmodel weet veel over de wereld, maar niets over jouw klanten, jouw printers of de workaround die je meest ervaren technicus vorige lente heeft gevonden. Stel het een vraag over je omgeving en het antwoordt toch, soms overtuigend en verkeerd.

Retrieval-augmented generation (RAG), vrij vertaald: antwoorden genereren op basis van opgezochte informatie, lost dat op door het werk in twee te splitsen:

1. Opzoeken. Vóór het model antwoordt, zoekt het systeem in je eigen inhoud de passages op die het meest relevant zijn voor de vraag.
2. Genereren. Het model schrijft zijn antwoord met die passages als bronmateriaal.

Zie het als een examen met open boek. Het model doet nog altijd het denkwerk en het schrijfwerk, maar het werkt vanuit jouw boek in plaats van uit het hoofd. Het antwoord wordt beter zodra de juiste pagina gevonden is, en je kunt zien welke pagina dat was.

Wat zijn embeddings en een vectordatabase?

Het moeilijke deel van RAG is de eerste stap: de juiste passage vinden. Klassiek zoeken vergelijkt woorden. Een ticket met "niemand op de tweede verdieping kan printen" vindt geen KB-artikel met de titel "Afdrukspooler hangt na een driverupdate", hoewel dat precies de oplossing is.

Embeddings lossen dat op. Een embeddingmodel leest een stuk tekst en zet het om in een lange reeks getallen, een vector, die vastlegt wat de tekst betekent in plaats van welke woorden hij gebruikt. Teksten over hetzelfde onderwerp komen in die ruimte dicht bij elkaar terecht, ook als ze geen enkel woord gemeen hebben. "Kan niet printen", "printer offline voor iedereen" en "spooler hangt" liggen dicht bij elkaar; "factuur vervallen" ligt ver weg.

Een vectordatabase (of vectorindex) bewaart die vectoren en beantwoordt één vraag heel snel: welke opgeslagen vectoren liggen het dichtst bij deze? Die nabijheid wordt meestal gemeten met cosinusgelijkenis, de hoek tussen twee vectoren. De zoekvraag wordt met hetzelfde model omgezet in een vector, en de dichtstbijzijnde passages zijn de kandidaten die het taalmodel te lezen krijgt.

Waarom dit telt voor een servicedesk

• Mensen beschrijven problemen in hun eigen woorden. Klanten schrijven symptomen op, technici schrijven oplossingen op. Zoeken op betekenis slaat een brug tussen die twee.
• Je kennis zit verspreid. KB-artikelen, playbooks, documentatie per klant, productnotities en de oplossingen die je team al heeft gevonden. Met RAG kan een AI-collega dat allemaal lezen op het moment dat hij het nodig heeft.
• Onderbouwde antwoorden zijn na te kijken. Wanneer een antwoord gebaseerd is op een bepaald artikel of playbook, kan een technicus de bron openen en controleren. Dat is het verschil tussen een assistent die je kunt vertrouwen en een die je van voren af aan moet nakijken.
• Minder gissen, minder herhaalde vragen. Wanneer de AI de eerdere oplossing vindt, krijgt je senior technicus de vraag niet voor de derde keer deze maand.

Wat we in Xcellerate OPS hebben ingebouwd

Eén semantische index per werkruimte

OPS houdt een semantische index bij van zes soorten inhoud:

• KB-artikelen (mappen worden overgeslagen);
• Playbooks, inclusief hun notitie over wanneer ze van toepassing zijn en de procedure;
• Documentatie die je per klant bijhoudt;
• Producten uit je catalogus, met hun beschrijving en AI-instructies;
• Oplossingen gedistilleerd uit opgeloste tickets (een oplossing die een teamleider als onjuist heeft gemarkeerd, blijft erbuiten);
• Ticketcategorieën en de AI-hints die je ervoor hebt geschreven.

Elk item wordt opgedeeld in overlappende stukken van ongeveer 800 tokens. Zo wordt een lang artikel meerdere doorzoekbare passages, en wint de beste passage. De index staat in de eigen database van je werkruimte, naast de gegevens die hij beschrijft. Documentatie die bij één klant hoort, komt alleen naar boven wanneer de AI voor die klant werkt.

Embeddings van Mistral

De vectoren worden gemaakt door het embeddingmodel van Mistral, mistral-embed, dat vectoren met 1.024 dimensies produceert. Twee waarborgen zijn hier belangrijk:

• Eerst afgeschermd. Elke tekst gaat door dezelfde afschermingsstap als elke andere AI-oproep in OPS, vóór hij het platform verlaat. Persoonsgegevens zoals e-mailadressen worden vervangen door plaatshouders.
• Eén model, één ruimte. Vectoren van twee verschillende modellen zijn niet met elkaar te vergelijken. Is er ooit een reserveprovider nodig, dan schakelt OPS alleen over naar een provider die hetzelfde model aanbiedt. Zo raakt de index nooit vermengd.

Hybride zoeken: trefwoord en betekenis samen

OPS vertrouwt nooit alleen op vectoren. Elke zoekopdracht volgt twee paden:

1. Zoeken op trefwoorden in titels en geëxtraheerde trefwoorden, dat altijd draait;
2. Vectorzoeken naar de passages die qua betekenis het dichtst bij de vraag liggen.

De twee resultatenlijsten worden samengevoegd met reciprocal rank fusion: een item dat hoog scoort in een van beide lijsten stijgt, een item dat hoog scoort in allebei stijgt het meest. Vectortreffers die te zwak zijn (cosinusgelijkenis onder 0,2) worden als ruis weggelaten, en elk document verschijnt één keer, vertegenwoordigd door zijn beste passage. Een productcode of foutnummer dat alleen zoeken op trefwoorden opvangt, gaat nooit verloren, en een anders verwoord symptoom dat alleen zoeken op betekenis opvangt, wordt ook gevonden.

Native vectorzoeken, met een vangnet

Waar de database native vectorzoeken ondersteunt, gebruikt OPS dat (cosinusafstand in SQL). Waar dat niet kan, berekent een ingebouwde engine de gelijkenis zelf. Loopt het native pad om welke reden ook mis, dan valt de zoekopdracht voor die vraag terug op de ingebouwde engine. Het opzoeken valt nooit uit door de vectorlaag.

Altijd actueel, nooit twee keer betaald

• Wanneer iemand een KB-artikel, playbook, document, product, oplossing of categorie opslaat, indexeert OPS het kort daarna opnieuw. Verwijder je het, dan verdwijnen ook de vectoren.
• Alleen passages waarvan de inhoud is gewijzigd, worden opnieuw omgezet; elk stuk draagt een hash van zijn inhoud. Identieke tekst hergebruikt een bestaande vector in plaats van voor een nieuwe te betalen.
• Ook de vector van een zoekvraag wordt in de cache bewaard: dezelfde vraag wordt één keer omgezet.
• Tijdens een gegevensimport wordt er niets in de wachtrij gezet; een nachtelijke afstemming haalt de achterstand daarna in.

Waar je team het merkt

• AI-collega's zoeken beter. Wanneer ze iets opzoeken in de kennisbank, playbooks, documentatie of producten, zetten ze de semantische treffers vooraan en houden ze de trefwoordtreffers daarachter.
• Gerelateerde inhoud bij een ticket. Voor de categorie van het ticket krijgt een AI-collega de inhoud die je hebt gekoppeld, de oplossingen die eerder gelijkaardige tickets hebben opgelost, en de documenten die qua betekenis het dichtst bij de titel van het ticket liggen.
• Een netter oplossingsgeheugen. Een nieuwe oplossing die bijna identiek is (cosinusgelijkenis van 0,92 of meer) aan een oplossing die al voor dezelfde categorie is opgeslagen, wordt als dezelfde oplossing behandeld. Zo loopt je lijst niet vol met dubbels.

Echte screenshot uit onze demo-omgeving, met fictieve gegevens.

Privacy en controle

• Tekst wordt afgeschermd vóór hij wordt omgezet, en de opgeslagen oplossingen behouden de plaatshouders.
• De index staat in de eigen database van je werkruimte; klantdocumentatie is beperkt tot die klant.
• Een teamleider kan een oplossing markeren als onjuist (dan verdwijnt ze uit de index) of verwijderen; wie een geïndexeerd item verwijdert, verwijdert ook de vectoren.
• De AI-noodstop stopt het omzetten naar embeddings samen met elke andere AI-oproep.
• Het AI Transparency Center vermeldt het AI-geheugen in je AI Act-register ("Bewaard tot wissen; opgeslagen geanonimiseerd"), en Instellingen → AI-geheugen toont wat het geheugen bevat. Meer over het register lees je op onze pagina over AI-governance.

Echte screenshot uit onze demo-omgeving; één kolom is vervaagd.

Wat het kost

Embeddings maken verbruikt AI-credits in de categorie AI-geheugen, en elke oproep wordt gelogd zoals elke andere AI-actie. Omdat ongewijzigde passages en herhaalde vragen nooit twee keer worden omgezet, volgt de kost hoeveel je kennis verandert, niet hoe vaak je team zoekt. De Oversight-pagina in het AI Transparency Center toont wat het hergebruik heeft bespaard.

Aan de slag

Er valt niets aan te zetten: het indexeren start vanzelf en blijft bij wanneer je inhoud verandert. Hoe meer je vastlegt in artikelen, playbooks en klantdocumentatie, en hoe meer tickets je oplost, hoe meer materiaal je AI-collega's hebben om mee te werken.

Ben je nieuw bij Xcellerate OPS? Op de pagina over AI-collega's lees je wat de collega's doen, en ons artikel over hoe elk ticket dat je afsluit het volgende goedkoper maakt gaat over het AI-geheugen waar deze index deel van uitmaakt.

Start gratis