Een AI-assistent die vragen beantwoordt uit je eigen documentatie — het is de toepassing waar vrijwel elke organisatie als eerste aan denkt. De standaardtechniek daarvoor heet RAG: retrieval-augmented generation. Het taalmodel krijgt bij elke vraag de relevante stukken uit jouw kennisbank mee en baseert zijn antwoord daarop, in plaats van op wat het ooit op internet las.
Het gangbare recept voor RAG begint met een vectordatabase. Wij bouwden een testopstelling op onze eigen interne kennisbank in Confluence — en lieten die vectordatabase bewust weg. In plaats daarvan volgden we een jonge specificatie van Google: het Open Knowledge Format (OKF). Dat leverde inzichten op die we graag delen.
Het klassieke recept: knip alle documenten in stukjes ("chunks"), reken van elk stukje een wiskundige vingerafdruk uit (een embedding), stop die in een vectordatabase en zoek bij elke vraag naar de stukjes die er het meest op lijken. Dat werkt, maar het brengt gedoe mee. Je hebt er een extra database voor nodig die synchroon moet blijven met de bron: wijzigt een pagina, dan moeten de embeddings opnieuw. Het knippen sloopt structuur — juist tabellen en stappenplannen, vaak het waardevolste deel van een kennisbank, overleven het chunken slecht. En als het antwoord ernaast zit, is moeilijk uit te leggen wáárom de zoekstap deze stukjes koos: gelijkenis is een getal, geen redenering.
Het Open Knowledge Format draait dat om. Kennis is een map met markdown-bestanden: één bestand per onderwerp, met bovenin een klein blokje metadata — titel, samenvatting, labels en een link naar de oorspronkelijke bron. Verwijzingen tussen onderwerpen zijn gewone links tussen bestanden, en indexbestanden per niveau geven de structuur: van het overzicht via een deelgebied naar de individuele pagina. Documenten blijven heel; er wordt niets geknipt.
Een update is een bestand overschrijven. Versiebeheer is git. Er valt geen database te synchroniseren, want er ís geen database.
Onze testopstelling exporteert Confluence-ruimtes automatisch naar zo'n OKF-bundle: elke pagina wordt één markdown-bestand met titel, samenvatting, labels en een link terug naar de bronpagina. Het zoeken gebeurt met een beproefde, deterministische tekst-zoektechniek waarbij titel en labels zwaarder wegen dan de lopende tekst, en Nederlandse samenstellingen ook gedeeltelijk matchen — wie naar "factuur" zoekt, vindt ook de pagina over het "factuuradres". Van de best scorende pagina's reizen de gelinkte pagina's één stap mee als extra context. Het taalmodel formuleert vervolgens het antwoord en zet er de bronpagina's bij, zodat je altijd kunt doorklikken naar de oorspronkelijke Confluence-pagina om het na te lezen.
Een set geautomatiseerde tests bewaakt de bundle: elk bestand heeft de verplichte metadata, elke onderlinge link verwijst naar een bestaand bestand en elke pagina houdt een link naar zijn bron.
Hoe ver je komt zonder vectordatabase, verraste ons. Voor een kennisbank met duidelijke vaktermen — en dat zijn interne kennisbanken vrijwel altijd — vindt deterministisch zoeken de juiste pagina's betrouwbaar. Bovendien is het uitlegbaar: dezelfde vraag geeft dezelfde documenten, en je kunt precies zien waarom een pagina scoorde. Het geheel is te beheren zoals we software beheren: wijzigingen zijn zichtbaar als een diff, en de kennisbank reist gewoon mee in versiebeheer.
Eerlijk is eerlijk: embeddings kunnen iets wat tekstzoeken niet kan. Wie in heel andere woorden vraagt dan de documentatie gebruikt, wordt door een vectordatabase soms beter begrepen. Voor de kennisbanken die wij tegenkomen weegt dat zelden op tegen de eenvoud — maar het blijft een afweging per geval, geen dogma.
Staat jullie kennis in Confluence, SharePoint of een map handleidingen, dan is een AI-assistent op eigen documentatie dichterbij dan vaak gedacht — zonder zware extra infrastructuur. Belangrijk daarbij: het doorzoeken gebeurt binnen de eigen omgeving, alleen de pagina's die relevant zijn voor de vraag gaan als context naar het taalmodel, en elk antwoord vermeldt zijn bron. Geen antwoorden uit de losse pols, maar controleerbare antwoorden uit jullie eigen kennis.
Benieuwd wat dit voor jullie kennisbank kan betekenen? Laat het ons weten via het formulier hieronder, bel 010 270 75 75 of mail hallo@admix.nl. Loopt er al iets bij ons? Dan kan het ook via support.
Adres
Postbus
Benieuwd wat dit voor jouw site betekent? Laat je gegevens achter en vertel kort waar je tegenaan loopt, dan nemen we contact met je op. We reageren doorgaans binnen één werkdag.
Liever direct contact? Bel of mail ons gerust.
RAG is de techniek waarbij een taalmodel bij elke vraag eerst de relevante stukken uit jouw eigen documentatie aangereikt krijgt, en zijn antwoord daarop baseert. Zo antwoordt de AI met jullie informatie in plaats van met wat het model ooit op internet las — en kan elk antwoord een bron vermelden.
Nee. Een vectordatabase is de gangbare aanpak, maar geen vereiste. Het Open Knowledge Format van Google laat zien dat een kennisbank ook een map markdown-bestanden kan zijn, doorzocht met deterministische tekst-zoektechniek. Voor kennisbanken met duidelijke vaktermen werkt dat betrouwbaar en is het eenvoudiger te beheren; embeddings blijven nuttig wanneer synoniemen en vrije vraagstelling zwaar wegen.
Ja. Onze testopstelling exporteert Confluence-pagina's automatisch naar het Open Knowledge Format, inclusief metadata, labels en onderlinge links. Dezelfde aanpak werkt voor elke bron die via een API te lezen is, zoals SharePoint of een documentatiesite.
Het doorzoeken van de kennisbank gebeurt binnen de eigen omgeving. Alleen de pagina's die relevant zijn voor een concrete vraag gaan als context naar het taalmodel, en elk antwoord verwijst naar de bronpagina zodat het controleerbaar blijft.