Een kennisbank bouwen: artikelen, zoeken, rechten en AI-antwoorden
Een kennisbank is een doorzoekbare bibliotheek van antwoorden: hoe doe je iets, hoe los je iets op, wat is de regel. Om er een te bouwen heb je artikelen nodig die in een paar duidelijke categorieën zijn gegroepeerd, een editor die je schrijvers daadwerkelijk gebruiken, zoekfunctionaliteit die het juiste artikel vindt op basis van de woorden die mensen echt intypen, en een beslissing over wie wat mag lezen: het publiek, klanten die zijn ingelogd, of alleen medewerkers. Een AI-app-builder kan de structuur, editor en zoekfunctie in een korte sessie opleveren. Wat een kennisbank bruikbaar maakt, is het schrijfwerk en het onderhoud, dus ontwerp vanaf dag één voor makkelijk bewerken en voor het herkennen van verouderde artikelen.
Bepaal eerst voor wie het is
Dezelfde functies dienen heel verschillende sites:
- Openbaar helpcentrum — voor klanten en potentiële klanten. Moet snel zijn, door zoekmachines te indexeren zijn en in hun eigen woorden geschreven.
- Alleen-klantdocumentatie — achter een login, voor betalende klanten of partners.
- Interne kennisbank — beleid, processen, handleidingen voor medewerkers. Moet privé zijn; zoeken en actualiteit zijn belangrijker dan het design.
Publiek en intern materiaal in één site mengen is waar de meeste lekken ontstaan. Heb je beide nodig, geef dan elk artikel een duidelijke zichtbaarheidsinstelling, of gebruik twee aparte sites.
Wat de app nodig heeft
Data
| Tabel | Belangrijkste velden |
|---|---|
| Artikelen | Titel, slug, samenvatting, tekst, categorie, tags, status (concept, gepubliceerd, gearchiveerd), zichtbaarheid, eigenaar, laatst beoordeeld op, bijgewerkt op |
| Categorieën | Naam, slug, beschrijving, volgorde, bovenliggende categorie (optioneel) |
| Revisies | Artikel, tekst, auteur, opgeslagen op |
| Feedback | Artikel, nuttig ja/nee, opmerking, aangemaakt op |
| Zoeklogboek | Zoekopdracht, aantal resultaten, aangeklikt artikel, aangemaakt op |
Twee velden doen veel werk: eigenaar (wie houdt dit artikel juist) en laatst beoordeeld op (wanneer iemand voor het laatst heeft bevestigd dat het nog klopt). Samen laten ze je artikelen zien die zes maanden lang niemand heeft gecontroleerd.
Pagina's
- Lezer: home met zoekbalk en categorieën, categoriepagina's, artikelpagina's met inhoudsopgave, gerelateerde artikelen en een vraag „Was dit nuttig?”.
- Editor: artikellijst met filters (concepten, verouderd, laag beoordeeld), een editor met voorbeeld en revisiegeschiedenis.
- Beheerder: categorieën, gebruikers en rollen, en rapporten over zoekopdrachten zonder resultaten.
Rechten
Lezers zien gepubliceerde artikelen die ze mogen zien. Editors maken en bewerken artikelen, misschien beperkt tot bepaalde categorieën. Beheerders publiceren, archiveren en beheren gebruikers. Voor een interne kennisbank heeft iedereen een login nodig; voor een openbaar helpcentrum alleen de schrijvers.
Keuzes en afwegingen
Editor: Markdown of rich text
Markdown is snel, draagbaar en werkt goed met versiegeschiedenis, maar sommige schrijvers vinden het afstotend. Een rich-text-editor met koppen, lijsten, afbeeldingen, callouts en codeblokken voelt vertrouwd. Wat je ook kiest, bewaar de inhoud in een formaat dat je later kunt exporteren.
Zoeken
Eenvoudige tekstzoekopdrachten in de database zijn genoeg voor een paar honderd artikelen als je op titels, samenvattingen en teksten zoekt en titeltreffers hoger rangschikt. Daarboven, of als typfouten en synoniemen belangrijk zijn („factuur” versus „rekening”), gebruik je echte full-text-zoekfunctionaliteit of een gehoste zoekdienst. Onze gids voor het toevoegen van zoekfunctionaliteit loopt de opties door. Log elke zoekopdracht die niets oplevert: het is een gratis lijst met artikelen die je moet schrijven.
AI-antwoorden
Een „stel een vraag”-vak dat antwoordt op basis van je artikelen is nu gangbaar. Het werkt door de meest relevante passages op te halen en een taalmodel te vragen alleen daarop te antwoorden — zie wat RAG is. Toon altijd de bronartikelen, sta „ik weet het niet” toe, en houd rekening met het feit dat het met overtuiging elke verouderde zin in je artikelen zal herhalen. Bouw het pas nadat de artikelen op orde zijn, niet ervoor.
Versiebeheer en beoordeling
Bewaar revisies zodat je ziet wie wat heeft gewijzigd en kunt terugdraaien. Voor gereguleerde inhoud (HR-beleid, veiligheidsprocedures) voeg je een goedkeuringsstap toe voordat een wijziging wordt gepubliceerd.
Een eerste prompt die werkt
Bouw een openbaar helpcentrum voor Parcelly, een app voor verzendlabels voor kleine webwinkels. Startpagina met een grote zoekbalk en zes categorieën (Aan de slag, Labels printen, Vervoerders, Facturatie, Retouren, Problemen oplossen). Artikelen hebben een titel, samenvatting, tekst in Markdown met afbeeldingen en callouts, categorie, tags, status (concept, gepubliceerd, gearchiveerd), eigenaar en datum van laatste beoordeling. Artikelpagina's tonen een inhoudsopgave, gerelateerde artikelen en een „Was dit nuttig?” met ja/nee en een optionele opmerking. Zoeken dekt titels, samenvattingen en teksten, met titeltreffers eerst, en logt elke zoekopdracht en of die resultaten gaf. Een editorgedeelte (login vereist, rollen editor en beheerder) toont concepten, artikelen die 180 dagen niet zijn beoordeeld en artikelen met lage nuttig-scores, en houdt revisiegeschiedenis bij. Elk artikel krijgt een eigen paginatitel en metaomschrijving voor zoekmachines. Strak, rustig, leesbaar design. Mobile-first.
Bouwstappen
- Maak een lijst van je eerste 20 tot 30 artikelen op basis van echte supportvragen voordat je iets bouwt. Die lijst bepaalt de categorieën.
- Genereer de site en controleer het lezen op een telefoon — regellengte, koppen, afbeeldingen.
- Editor en rollen. Schrijvers moeten artikelen kunnen toevoegen en repareren zonder een ontwikkelaar te vragen.
- Zoeken, en test het daarna met de woorden die klanten echt gebruiken, inclusief typefouten.
- Feedback en zoeklogging.
- Rapport over verouderde artikelen op basis van eigenaar en datum van laatste beoordeling.
- SEO-basics voor een openbare site: unieke titels, omschrijvingen, nette URL's, een sitemap. Zie SEO voor met AI gebouwde websites.
- Koppel het aan je product en je supportantwoorden, en controleer het log met zoekopdrachten zonder resultaat wekelijks.
- AI-antwoorden, zodra de inhoud op orde is.
Veelgemaakte fouten
- Organiseren naar afdeling in plaats van naar wat de lezer probeert te doen.
- Lange artikelen die vijf taken behandelen. Eén taak per artikel, met een titel die zegt wat het oplost.
- Geen eigenaar per artikel. Niemand werkt iets bij, en het vertrouwen daalt na het eerste foute antwoord.
- Interne notities in openbare artikelen. Gebruik aparte zichtbaarheid en controleer vóór publicatie.
- Zoeken dat alleen titels matcht. Lezers typen symptomen, geen artikelnamen.
- Screenshots zonder alt-tekst of context. Ze veroudering snel; beschrijf de stap daarom ook in woorden.
Wanneer een kant-en-klaar product de betere keuze is
Als je team al werkt in een documentatie- of wikitool, is een interne kennisbank daarin meestal het pad van de minste weerstand — onze vergelijking Notion versus Confluence behandelt twee veelgemaakte keuzes. Als je een helpdeskproduct gebruikt, koppelt het ingebouwde helpcentrum artikelen aan tickets en stelt het artikelen aan klanten voor, wat lastig na te bootsen is. Generatoren van docsites zijn ideaal voor ontwikkelaarsdocumentatie die naast de code wordt bijgehouden.
Bouw zelf wanneer je eigen structuur of rechten nodig hebt (artikelen per klant, per locatie, per rol), de kennisbank binnen je product wilt in plaats van op een aparte site, goedkeuringsstappen nodig hebt die een wiki niet afdwingt, of AI-antwoorden over je inhoud wilt zonder nog een abonnement. Het past goed bij een eigen helpdesk.
Bouwen met Mythex
Bij Mythex beschrijf je de kennisbank in de chat en wordt hij gebouwd in een live preview; artikelen, revisies en feedback worden opgeslagen in een Postgres-database die de agent toevoegt wanneer nodig, en afbeeldingen komen in de bestandsopslag van het project. Inloggen van editors gebruikt een authenticatiemethode die jij kiest, omdat Mythex geen ingebouwde login voor eindgebruikers heeft. Voor AI-antwoorden gebruik je de API-sleutel van je eigen AI-provider, opgeslagen als projectgeheim, en het verbruik wordt gefactureerd via je provideraccount, niet via Mythex-credits (AI-recept). Nieuwe Mythex-apps starten als client-side gerenderde React-single-page-app, wat zwakker is voor zoekmachines. Vraag voor een openbaar helpcentrum dus om een statisch vriendelijke of server-side gerenderde opzet, zoals Next.js (SEO-recept).
Als startprompt kun je de templates productkennishub of team docs-app proberen.
Veelgestelde vragen
Wat is het verschil tussen een kennisbank en een wiki?
Een kennisbank wordt meestal gecureerd: een klein team schrijft en onderhoudt antwoorden voor een afgebakend publiek, vaak klanten. Een wiki laat iedereen bewerken en groeit meestal breder en rommeliger. Dezelfde software kan beide dienen; het verschil zit in wie schrijft en wie controleert.
Hoe moet een kennisbank georganiseerd zijn?
Op basis van wat lezers proberen te doen, niet naar je organogram. Een paar hoofdcategorieën, korte taakgerichte artikelen met duidelijke titels en links tussen gerelateerde artikelen werken beter dan diepe mappenstructuren.
Kan ik AI-antwoorden aan een kennisbank toevoegen?
Ja. De gangbare aanpak, retrieval-augmented generation genoemd, doorzoekt je artikelen op relevante passages en vraagt een taalmodel om alleen met die passages te antwoorden, met links naar de bronnen. Dat werkt het best als de artikelen zelf juist en actueel zijn.
Moet een openbaar helpcentrum door zoekmachines worden geïndexeerd?
Meestal wel. Mensen zoeken hoe ze een probleem oplossen voordat ze support contacteren, dus elk artikel moet een eigen pagina, titel en omschrijving hebben. Houd interne artikelen op een aparte site die achter een login staat.