# Een tweede brein bouwen met RAG: Geen beste oplossing, alleen de beste context De afgelopen twee jaar hebben bijna alle teams die aan grote taalmodellen werken hetzelfde gedaan: RAG toevoegen aan hun model. De reden is simpel. Grote taalmodellen hebben twee fundamentele gebreken: hun kennis heeft een vervaldatum en ze verzinnen dingen. RAG wordt gezien als de oplossing voor beide problemen: geef het model de nieuwste externe informatie en laat het antwoorden op basis van die informatie. Dit heeft geleid tot een wijdverbreid misverstand: **RAG is een technologie. Kies de juiste en je wint.** Maar de realiteit is: RAG is geen technologie. **RAG is een verzamelnaam voor een klasse van architecturen.** Verschillende contexten vereisen totaal verschillende architectuurkeuzes. Net zoals grote taalmodellen hun eigen toepassingen hebben – een 4B lichtgewicht model is niet waardeloos; het is praktischer in edge-reasoning, lage latentie en kostenefficiënte scenario's dan een model met honderden miljarden parameters. Een biljoen-parameter model is krachtig in redeneren, maar bedrijven kunnen het niet implementeren. Elk heeft zijn eigen plek. Dezelfde verschillen bestaan tussen RAG-oplossingen. Geen enkele oplossing is absoluut de beste. Alleen de beste voor de huidige context. **Dit artikel wil zeggen: in de specifieke context van 'notities + documenten + RAG' – oftewel het bouwen van een tweede brein met AI – wat is de optimale oplossing? En waarom.** --- ## 1. Waar RAG in 2025 echt moeilijk is Een RAG-demo is in een middag klaar. Maar de problemen in een productieomgeving concentreren zich op drie dimensies: ### Indexeren is geen eenmalige klus, maar een langetermijnlast "Alle documenten in een vector database stoppen" klinkt simpel. Maar in de praktijk: bij een modelupgrade moeten 10 miljoen documenten opnieuw worden verwerkt, wat ongeveer 5 miljard tokens kost, alleen al aan API-kosten van $300-650. Bij het verwijderen van documenten kunnen verlopen items in de vector database dagenlang niet worden opgeruimd. Bij wijzigingen in rechten kan er een beveiligingsvenster van enkele uren zijn als de index van documenten van vertrokken medewerkers niet tijdig wordt bijgewerkt. Bij platformbeperkingen beperken tools zoals Slack en Notion al het bulksgewijs ophalen van gegevens door derden. ### Latentie is een keten van meerdere niveaus Elke query doorloopt: vraag begrijpen → vector zoeken → resultaten sorteren → context samenvoegen → AI-antwoord genereren. Als één niveau traag is, is het geheel traag. LLM-reasoning neemt 60-80% van de end-to-end tijd in beslag. ### Kosten stijgen met de hoeveelheid data Hoe meer documenten, hoe meer verwerking. Alle drie de fasen groeien mee. **Gemeenschappelijke oorzaak: documenten moeten eerst worden geïndexeerd voordat query's kunnen worden uitgevoerd.** Dit is 'Search-centric' RAG. --- ## 2. Twee gangbare oplossingen ### Oplossing 1: Vector database + statische index Documenten worden eerst versnipperd, getransformeerd en opgeslagen in een vector database. Bij een query wordt de meest vergelijkbare inhoud uit de database gezocht. **Sterk in:** Zeer veel documenten, vaste inhoud. **Zwak in:** Inhoud die vaak verandert; elke bewerking vereist herbouw van de index. ### Oplossing 2: Real-time datastroom + event-driven Gegevenswijzigingen triggeren updates, de index wordt real-time gesynchroniseerd. **Sterk in:** Seconden-niveau actualiteit. **Zwak in:** Complexe infrastructuur, vereist cachelaag, event-mechanisme, dubbele opslaglaag. ### Er is een scenario dat beide routes niet bedienen Een advocate stelt een samenvatting van een zaak op. 200 zaaknotities, 50 wetsdocumenten. Ze schrijft en zoekt tegelijk – "Hoe werd de vorige zaak over non-concurrentie beargumenteerd?" Na het schrijven van een alinea wijzigt ze de inhoud en zoekt een paar seconden later opnieuw. De nieuwe inhoud zou al in de zoekresultaten moeten zitten. Kenmerken van dit scenario: **Inhoud verandert vaak** (geen statische bibliotheek), **zoeken en creëren zijn verweven** (schrijven en zoeken tegelijk), **de gebruiker is een gewoon persoon** (schrijft geen code, begrijpt geen vector databases), **gegevens en privacy zijn een rode lijn**. **Dit is geen behoefte aan 'hogere technische complexiteit'. Dit is een behoefte aan 'een technische oplossing die niet zo zwaar hoeft te zijn'.** --- ## 3. Van Search-centric naar Memory-centric Gangbare oplossingen gaan ervan uit dat **de kennisbank statisch is**. Een query is een eenmalige zoekactie. Dit paradigma wordt **Search-centric RAG** genoemd. Model: kennisbank = verzameling documenten, RAG = intelligente zoekopdracht. Maar het bouwen van een tweede brein vereist een ander paradigma. Je schrijft, wijzigt, verwijdert en importeert dagelijks nieuwe documenten. Kennis groeit en evolueert continu. Je wilt dat AI niet 'even zoekt', maar **continu 'onthoudt' wat je weet en het natuurlijk oproept wanneer nodig.** Dit is **Memory-centric RAG**. Model: kennisbank = continu evoluerend geheugen, RAG = natuurlijke toegang. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | Begrip van kennis | Statische verzameling documenten | Continu groeiend geheugen | | Data-actualiteit | Afhankelijk van index-updatefrequentie | Real-time, direct na schrijven | | Manier van zoeken | Actief zoeken | Natuurlijk gesprek | | Relatie met creëren | Zoeken en creëren gescheiden | Verweven – bewerken is geheugenupdate | | Typisch scenario | Bedrijfszoekopdracht, beleidsvragen | Persoonlijk kennisbeheer, tweede brein | **De twee paradigma's vervangen elkaar niet. Ze dienen totaal verschillende contexten.** Net als een zoekmachine versus een persoonlijke assistent. --- ## 4. Welke architectuur heeft Memory-centric RAG nodig? Vier vereisten voor de architectuur: **1. Geen afhankelijkheid van vooraf indexeren.** Elke bewerking vereist herbouw van de index, waardoor real-time prestaties onmogelijk zijn. Het zoeksysteem moet gegevens delen met de editor – zodra de inhoud verandert, moet de volgende query dit weerspiegelen. **2. Minimale context.** Notities zijn privégegevens, kunnen niet volledig worden geüpload. Maar AI moet informatie zien om te kunnen antwoorden. Balans: alleen de meest relevante zinnen doorgeven, fragmenten comprimeren, na verwerking verwijderen. **3. Beste cloudmodel voor generatie.** Gebruiker hoeft niets te doen, server ziet alleen minimale context. **4. Bewerken is geheugenupdate.** Wijzigingen worden direct in het geheugen opgenomen, de volgende query weerspiegelt dit. --- ## 5. NoteRich's Memory-centric RAG in de praktijk ### Notities blijven altijd lokaal, volledige data wordt niet geüpload Notities worden lokaal in de browser opgeslagen. Niet toegestaan (kostenexplosie) en niet nodig (privacy gebruiker). ### Bij query's alleen minimale noodzakelijke context doorgeven Alleen de meest relevante zinnen uit de zoekopdracht worden doorgegeven, gecomprimeerde fragmenten. Server verwijdert na verwerking – geen opslag, geen registratie, geen training. **Beperkte upload is onvermijdelijk, volledige upload is volledig te vermijden.** ### Geen vooraf indexeren, bewerken is geheugen Geen vooraf gebouwde vector database. Terwijl je notities schrijft, is het zoeksysteem al online. Inhoudsveranderingen worden real-time weerspiegeld. ### Multi-dimensionele evaluatie + precisie tot op zinsniveau + server stateless Niet alleen afhankelijk van semantische gelijkenis. Retourneer precisie tot op zinsniveau, dedupliceer en voeg samen. Backend slaat niets op, registreert niets, traint niets. --- ## 6. Vier niveaus van het tweede brein **Niveau 1: Geheugen.** AI 'onthoudt' alle notities die je hebt geschreven. **Niveau 2: Ondersteuning bij creëren.** Genereer nieuwe inhoud op basis van oude notities. **Niveau 3: Real-time feedback.** AI voelt direct aan wanneer je een alinea hebt geschreven. **Niveau 4: Bewerken is geheugen.** Wijzigingen in door AI gegenereerde inhoud worden direct in het geheugen opgenomen. Kennisomgeving is gesloten. --- ## 7. Grenzen erkennen en overstijgen ### Grens 1: Capaciteit van de browser De online versie draait volledig in de browser. Getest met tienduizenden teksten en tientallen miljoenen karakters, zeer soepel. **Tot enkele honderdduizenden documenten geen probleem, daarboven prestatiedaling.** Dit is de fysieke grens van de browser. Maar individuele gebruikers komen deze grens bijna nooit tegen. Als je hem wel tegenkomt – dan heb je een enterprise-behoefte. In de offline implementatie draait dezelfde architectuur op de server, schaalbaar naar behoefte. ### Grens 2: Multi-modale ondersteuning Momenteel gericht op tekst. OCR voor afbeeldingen, transcriptie voor audio, video-analyse – online versie beperkt door browser-rekenkracht. Enterprise offline implementatie kan op maat worden geïntegreerd op de server. **Tekstgeheugen is de basis, multi-modaal geheugen is een upgrade.** ### Grens 3: Complex redeneren over meerdere documenten Meerstaps redeneren is een taak van de generatiefase, niet van de zoekfase. Zoeken gaat alleen over 'vinden', niet over 'afleiden'. NoteRich laat consumentenmodellen praktische resultaten behalen met hoogwaardige context. ### Grens 4: Volledig offline Top grote taalmodellen kunnen niet op een gewone computer draaien – dit is een natuurkundige wet. Offline implementatie kan worden aangesloten op lokaal geïmplementeerde modellen van het bedrijf. --- ## 8. Offline oplossing Advocatenkantoren, ziekenhuizen, financiële instellingen – gegevens mogen absoluut niet buiten het interne netwerk komen. Offline implementatie verpakt de Memory-centric architectuur als een single-component backend, met één klik te implementeren, volledig binnen het bedrijfsnetwerk. --- ## 9. Uiteindelijke visie **Search-centric RAG lost het 'vinden' op.** Memory-centric RAG lost het 'onthouden' op. De twee zijn geen concurrenten. Wat NoteRich doet, is slechts enkele directere keuzes maken op het pad van Memory-centric RAG. **Snel, goedkoop, hoogwaardig.** Laat gewone mensen binnen 30 seconden beginnen met het beheren van kennis met AI, en laat bedrijven volledig vertrouwen binnen de firewall. **[Probeer NoteRich →](https://noterich.com/app/)** *Open-source concept project [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*