Platform
Neural search en retrieval: wat het MKB moet begrijpen vóór het aan RAG of ‘eigen kennis’ begint
Lessen uit publieke inzichten over neural search en RAG: dichte informatie voor modellen, filters, en hybrid retrieval—zonder valse eenvoud over ‘één knop oplossing’.
Begrippen: RAG, vector, chunks
Basis eerst
Staat RAG of vector nieuw voor u? Lees het korte begrippenartikel over RAG en vector (andere post in dit blog). Verderop in dit stuk nemen we dit als bekend: RAG = eerst relevante stukken uit uw documenten halen, dan het antwoord laten formuleren. Vector- of semantisch zoeken = stukken vinden op betekenis, niet alleen op identieke woorden. Chunks = de brokken waarin u lange documenten knipt vóór u ze indexeert.
Waarom ‘Google voor mensen’ niet genoeg is voor AI
Klassieke zoekmachines geven u een lijst met links; u leest, vergelijkt, klikt. Een model dat een taak eindigt, wil fragmenten die dicht op de vraag zitten—liefst schoon, met bron en filters (domein, periode) waar nodig. Dat is de verschuiving achter neural search (zoeken op betekenis en context, niet alleen op losse trefwoorden) en retrieval voor LLM’s: semantische indexen, afspraken over latency, en soms korte uittreksels in plaats van hele documenten (om ruimte in het model te sparen).
Voor MKB: als u RAG (retrieval-augmented generation) boven eigen documenten overweegt, geldt hetzelfde principe: wat u opslaat, in welke stukken u lange bestanden knipt, en hoe u ophaalt, bepaalt ongeveer de helft van de kwaliteit—niet alleen ‘welk model’ u kiest.
Chunking, metadata en hybrid
RAG-discussies in de vakwereld wijzen op de balans tussen te kleine en te grote brokken: te klein verliest context, te groot laat alles plausibel lijken. Titel, sectie en metadata vooraan een chunk (contextueel knippen) helpen. In de praktijk kiest men vaak een hybride mix: BM25-achtig zoeken (klassiek op trefwoorden, zoals bij intranet-zoekbalken) plus vector/semantisch zoeken, soms met een herordening (rerank) bovenop.
Documentbeheer eerst
Zonder schoon documentbeheer, versiebeheer en labels blijft retrieval gokken. Een goede index compenseert geen rommel in SharePoint of onduidelijke mappenstructuur.
Filters en kosten: wat retrieval-producten expliciet maken
Aanbieders in deze ruimte documenteren o.a. semantisch/vector search op schaal (snel stukken vinden op betekenis), metadata filtering (datum, bron, type) en keuze tussen snelle of diepere zoek- of onderzoeksmodes. Dat vertaalt naar MKB-VRAG: u bepaalt vooraf: mag het antwoord alleen uit interne kennis, mag het web erbij (zoals Nova), en binnen welke voorwaarden van de partij met wie u in contract staat.
Een duidelijk contract met uw leverancier (waar draait data, logging, retentie) blijft nodig. In Orbit kunt u Zero Data Retention (ZDR) inschakelen wanneer uw beleid dat eist; dan is dat expliciet onderdeel van het ontwerp, niet iets dat u achteraf moet repareren.
Wat u morgen kunt doen
- Inventariseer 3 topprioriteit-vragen die uw medewerkers echt stellen; test retrieval daarop, niet op ‘random chat’.
- Leg vast of webbronnen (agentic) of alleen vaste kennisdomeinen de bron van waarheid zijn.
- Breek documenten bewust, met betekenisvolle koppen; voeg metadatavelden toe (productlijn, juridische status, geldig tot).
Veelgestelde vragen
Is RAG ‘gewoon een vector database’?
Nee. Een vector database (of vector store) is één schakel: tekststukken bewaren en doorzoeken op onderlinge gelijkenis. Minstens even belangrijk: hoe u documenten in stukken knipt, welke metadata u meestuurt, hoe u de vraag herformuleert, en of het antwoord in uw vakgebied houdbaar is. Zie het begrippenartikel RAG en vector in dit blog.