AI-assistent op een eigen tekstcorpus met RAG (Bijbel Assistent)

We bouwden de assistent als een RAG-toepassing (retrieval-augmented generation): het taalmodel krijgt bij elke vraag eerst de relevante brontekst aangereikt en redeneert daarover, in plaats van uit eigen parametergeheugen te putten.

1. RAG in plaats van fine-tuning: waarom#

Fine-tunen zou de kennis in de modelgewichten bakken — precies wat je hier niet wilt. Een fijngetuned model kan nog steeds niet zeggen waar iets staat, en elke corpuswijziging vraagt om opnieuw trainen.

Met RAG blijft het corpus de bron van waarheid: de assistent haalt passages op, geeft die mee als context en verwijst er in het antwoord naar. Bijwerken betekent dan documenten toevoegen, niet een model hertrainen.

Die afweging speelt bij vrijwel elke AI-assistent op bedrijfsdata; we hebben hem apart uitgewerkt in RAG vs. fine-tuning.

“

Ontwerpdoel van deze architectuur: elk inhoudelijk antwoord is te herleiden tot een aanwijsbare passage — een vers in een genoemde vertaling, een commentaarregel of een grondtaal-lemma. Dat is het gestelde ontwerpdoel en de reden om voor RAG te kiezen, geen extern gemeten nauwkeurigheidsscore.

2. De ophaallaag: PostgreSQL met pgvector#

De vector-database is PostgreSQL met pgvector. Bewuste keuze: het corpus, de gebruikersdata en de embeddings staan zo in hetzelfde systeem, met dezelfde back-ups en dezelfde transacties.

Een aparte vector-store toevoegen levert bij deze omvang vooral extra infrastructuur op. Semantisch zoeken loopt daardoor over dezelfde database die ook bladwijzers, notities en abonnementen bijhoudt; Redis vangt caching en snelle sessie-toegang op.

3. Antwoorden met bronvermelding via de Claude API#

Als redeneerlaag gebruiken we de Claude API van Anthropic. De opgehaalde passages gaan als context mee en het antwoord verwijst terug naar wat er is opgehaald — vertaling erbij, commentaar erbij.

Waar een generieke chatbot een vlot verhaal produceert, is de opdracht hier omgekeerd: liever een korter antwoord dat aanwijsbaar in de tekst staat dan een lang antwoord dat nergens naar terugleidt.

4. Van chat naar werkinstrument#

Een chatvenster alleen is geen product. De assistent kent daarom:

• Prediker-modus voor exegese en preekvoorbereiding
• Woordstudie op Strong-nummers, met kruisverwijzingen tussen teksten
• Groepsstudie voor gezamenlijk gebruik, plus bladwijzers met eigen notities
• TTS-audio om teksten te laten voorlezen
• Een REST-API voor externe integraties

Een zusterproject op hetzelfde fundament genereert gepersonaliseerde Bijbelleesplannen.

5. De productielaag: abonnementen, privacy, mobiel#

De frontend draait op Next.js en React, de backend op Fastify (Node), met JWT-authenticatie. Abonnementen lopen via Mollie met iDEAL — de Nederlandse betaalstandaard, niet een creditcard-only-oplossing.

Privacy is ingebouwd in plaats van eromheen gebouwd: gebruikers kunnen hun data exporteren en hun account laten verwijderen (GDPR). Naast de web-app is er een React Native-app en een PWA met offline-ondersteuning, zodat teksten ook zonder verbinding beschikbaar zijn.

De codebase wordt getest met Vitest.

6. Wat een AI-assistent op eigen data kost#

De vraag die bij elk AI-agent- of chatbot-traject terugkomt is wat zoiets kost. Deze case laat vooral zien waar de kosten zitten, en dat is zelden bij het taalmodel.

Het zwaartepunt ligt vóór het chatvenster: het corpus opschonen en in bruikbare stukken knippen, embeddings genereren en actueel houden, en — het meest onderschat — evalueren of de assistent de juiste passage ophaalt. Daarna komen de gebruikelijke productiekosten: authenticatie, betalingen, privacyfuncties, monitoring.

Wie een chatbot wil implementeren op eigen documenten begroot doorgaans het modelgebruik en vergeet die drie voorbereidende stappen; daar loopt een traject vast, niet op de API-rekening.