Hoe stel je je bedrijfsdatabase een vraag en krijg je een real-time antwoord?

Een collega stuurt je een bericht: "Hoeveel studenten zitten momenteel in de proeflessfase?" of "Wat is het meest recente contract dat we hebben met die klant in Rotterdam?" Je weet dat het antwoord ergens in het systeem zit. Maar om erachter te komen moet je een layout openen, een zoekopdracht instellen, mogelijk twee of drie gerelateerde tabellen controleren, en dan het resultaat terugtypen in een e-mail of Slack-bericht.

Vermenigvuldig dat met elke vraag die je team in een week stelt, en je kijkt naar uren handmatig zoekwerk — werk dat een computer in enkele seconden zou moeten kunnen afhandelen. Dit artikel legt uit waarom de voor de hand liggende oplossing (een AI-chatbot erop plakken) vaak tegenvalt, en wat echt werkt: een LLM rechtstreeks verbinden met je live data in plaats van een statische kopie ervan.

Waarom teleurstelt het toevoegen van een AI-chatbot aan je data meestal?

De standaardbenadering om AI aan een bedrijfssysteem toe te voegen is Retrieval-Augmented Generation, ofwel RAG: exporteer je data, verdeel deze in stukken, bedden deze in een vectordatabase in, en laat een LLM erover zoeken.

Dit werkt goed voor statische, ongestructureerde inhoud — PDF's, handleidingen, gescande contracten, beleidsdocumenten. Het werkt slecht voor live operationele data. Een vector-index is een snapshot, bevroren op het moment waarop deze werd aangemaakt. Zodra een contractstatus verandert, een factuur wordt betaald, of een student van "proef" naar "ingeschreven" gaat, klopt die snapshot niet meer — en dat blijft zo totdat iemand de ingestion-job opnieuw uitvoert, wat in de meeste opstellingen op zijn best eenmaal per nacht gebeurt.

Voor een vraag zoals "wie heeft momenteel een onbetaalde factuur," is een snapshot van gisteravond niet goed genoeg. Je hebt een antwoord nodig gebaseerd op wat de database nu zegt, op het moment dat de vraag wordt gesteld.

Wat is het alternatief voor het indexeren van je data voor AI-zoekopdrachten?

In plaats van data naar een aparte zoekindex te kopiëren, kun je een LLM een directe, real-time lijn naar de API van je database geven. Wanneer een vraag binnenkomt, werkt het systeem in vijf stappen:

1. Leest de vraag om uit te vissen wat eigenlijk wordt gevraagd — een persoon, een status, een aantal, een datumbereik.
2. Vraagt de live database op op dat exacte moment, waarbij de eigen API wordt gebruikt in plaats van een gecachte kopie.
3. Verzamelt gerelateerde records — voor een persoonzoeking kan dat betekenen dat contracten, betalingsvoorwaarden, facturen, notities en open tickets in één keer bij elkaar worden gehaald.
4. Assembleert de resultaten in context voor de LLM, waarbij interne codes en veldnamen worden vertaald in platte taal die een persoon echt zou gebruiken.
5. Retourneert een antwoord in natuurlijke taal, klaar om te lezen of rechtstreeks in een e-mail in te plakken.

Omdat stap 2 elke keer het live systeem raakt, is het antwoord altijd actueel. Er is geen re-ingestion, geen verouderde index, geen "zoals van gisteravond's sync" voorbehoud bij het antwoord.

Hoe ziet dit eruit met een daadwerkelijke vraag?

Iemand typt: "Hoeveel contracten hebben momenteel status 'In Uitvoering'?"

Het systeem:

• Herkent dit als een telvraag gekoppeld aan een specifiek statusveld
• Vraagt de contractentabel live op, gefilterd op die exacte status
• Telt de overeenkomende records
• Retourneert een antwoord in platte taal: "Er zijn momenteel 12 contracten in uitvoering."

Er hoeft geen rapport van tevoren te bestaan. Er hoeft geen dashboard al dat exacte gegevenssegment te dekken. De vraag zelf definieert de zoekopdracht — wat precies dit bruikbaar maakt voor de lange staart van eenmalige vragen die nooit een dedicated rapport rechtvaardigd zouden hebben.

Kan het een echte heen-en-weer conversatie aan, of alleen eenmalige zoekopdrachten?

Een goed gebouwde versie van dit patroon onthoudt ook context tussen vragen, zodat een gebruiker een natuurlijke draad kan volgen in plaats van zichzelf te herhalen:

"Laat me het Jansen-account zien." → "Wat is hun contractstatus?" → "Hebben ze onbetaalde facturen?"

Het systeem herkent korte vervolgvragen en voornaamwoorden zoals "hun" en "ze", en hergebruikt automatisch de persoon of record van de vorige vraag. Zonder dit zou elke vervolgvraag de volledige klantnaam moeten herhalen — wat precies het soort wrijving is dat ervoor zorgt dat mensen een chatbot na de tweede vraag opgeven.

Is je database eigenlijk geschikt voor deze benadering?

Ga deze checklist door voordat je investeert in ofwel RAG of een live-query-benadering:

• Je data verandert frequent — statussen, betalingen, of records worden dagelijks of vaker bijgewerkt
• Je database stelt een API bloot, ofwel natively ofwel via een connector
• Mensen stellen regelmatig dezelfde handvol vraagtypen — aantallen, zoekopdrachten, filters, vervolgvragen
• Je wilt antwoorden gebaseerd op huidige data, niet een periodieke export
• Je wilt liever geen aparte vectordatabase en re-ingestion-pijplijn onderhouden

Als de meeste hiervan waar zijn, zal een direct-naar-live-data-benadering je beter dienen dan een op RAG gebaseerde. Als je "data" daarentegen vooral een map met handleidingen en PDF's is die zelden veranderen, is RAG nog steeds het juiste instrument — de twee benaderingen lossen verschillende problemen op.

Veelgestelde vragen

Wijzigt dit mijn data? Nee. Dit patroon is read-only — het vraagt je bestaande systeem via de API op en schrijft nooit terug, zodat je source of record ongewijzigd blijft.

Worden mijn gegevens naar een externe AI-provider verzonden? Alleen de specifieke records die voor een bepaalde vraag zijn opgehaald, plus de vraag zelf, worden naar de LLM verzonden. Als dat een zorg is, kan een lokaal gehoste model alles on-premises houden.

Moet mijn data eerst worden herstructureerd? Nee. Het systeem leest rechtstreeks van je bestaande tabellen en velden — het werkt met de structuur die je al hebt, niet een heruitgewerkte kopie ervan.

Wat als een naam of term in de vraag verkeerd gespeld is? Goede implementaties bevatten partial-matching en fallback-logica, dus een bijna-raak op een naam of klantnummer vindt nog steeds de juiste record.

Is dit hetzelfde als een chatbot die op een zoekindex is geplakt? Nee — dat is de RAG-benadering. Dit patroon slaat de index helemaal over en vraagt het bronsysteem direct op, wat is wat antwoorden actueel houdt.

Vervangt dit mijn bestaande rapporten en dashboards? Nee. Rapporten zijn nog steeds het juiste instrument voor vragen die je herhaaldelijk stelt en visualiseerd wilt hebben. Dit patroon dekt de eenmalige vragen af die nooit een dedicated rapport rechtvaardigd zouden hebben.

Waar past dit in je bredere datastrategie?

Real-time vraagbeantwoording is geen vervanging voor rapportage of analytics — het is een aanvulling erop. Rapporten en dashboards zijn voor de vragen die je al weet dat je herhaaldelijk zult stellen. Dit patroon is voor de lange staart van dagelijkse eenmalige vragen die in Slack, in een vergadering, of in een telefoongesprek met een klant opduiken — die waar niemand ooit een rapport voor heeft gebouwd omdat daar geen tijd of reden voor was.

Voordat je iets bouwt, zet op kaart welke handvol vraagtypen je team werkelijk dagelijks stelt — aantallen, zoekopdrachten, statuscontroles, vervolgvragen over een specifieke record. Die lijst wordt het echte startpunt: het definieert wat het systeem goed moet kunnen afhandelen voordat het alles moet kunnen afhandelen.

Als dit klinkt als een goed aansluitend patroon voor hoe je team werkt maar je bent niet zeker waar je eigen database — FileMaker, een ERP, of een aangepast systeem — staat op API-toegang of datastructuur, dat is precies het soort vraag dat waard is om eerst met een technische partner in kaart te brengen. Loggix bouwt dit soort real-time AI-verbinding rechtstreeks in bestaande FileMaker-systemen en andere zakelijke databases, en kan het ook aanleggen over meerdere systemen heen via API-integraties waarbij het antwoord op één vraag op meer dan één plaats leeft.