RAG Anything Veranderde Mijn Gescande PDF's in Doorzoekbare Kennis

RAG Anything Veranderde Mijn Gescande PDF's in Doorzoekbare Kennis

Ik had drie weken lang een financieel rapport van 47 pagina's op mijn bureaublad staan. Gescande PDF. Staafdiagrammen op elke andere pagina. Omzettabellen weergegeven als afbeeldingen, niet als echte data. Het soort document waarbij elk RAG-systeem dat ik ooit heb gebouwd zijn schouders ophaalt en zegt: "hier is wat wartaal die ik tussen de koppen gevonden heb."

Ik had LightRAG al maanden draaien -- tekstopname, kennisgraafconstructie, hybride ophaling. Het verwerkte mijn markdown-bestanden en plain-text documenten prachtig. Maar elke keer dat ik er iets met grafieken, diagrammen of gescande pagina's in probeerde te laden, was de uitvoer ergens tussen nutteloos en hilarisch fout. Een keer vroeg ik naar de omzettrends in Q3 en ik kreeg een alinea terug over de opmaak van de inhoudsopgave. De kennisgraaf had de OCR-rommel van de paginakoppen trouw geïndexeerd en de werkelijke data in het staafdiagram eronder genegeerd.

Dat financiële rapport was het kantelpunt. Ik had een RAG-systeem nodig dat documenten begrijpt zoals ik ze begrijp -- niet alleen de woorden op de pagina, maar ook de grafieken, de afbeeldingen, de visuele data die de helft van de betekenis draagt in elk serieus zakelijk document. En dat is toen ik RAG Anything ontdekte.

Gebouwd door hetzelfde HKUDS-team achter LightRAG, is RAG Anything een wrapper die multimodale documentverwerking koppelt aan je bestaande LightRAG-setup. Het vervangt LightRAG niet. Het breidt het uit. En de manier waarop het de splitsing tussen tekst- en visuele inhoud aanpakt is werkelijk slim -- slim genoeg dat ik in één weekend mijn hele documentopnamepijplijn eromheen herbouwde.

Hier is de volledige uitsplitsing van hoe het werkt, hoe ik het heb opgezet en wat er gebeurde toen ik dat financiële rapport er eindelijk doorheen haalde.

Waarom Standaard RAG Instort bij Documenten uit de Echte Wereld

Het vuile geheim van de meeste RAG-tutorials is dat ze demonstreren op perfecte markdown-bestanden en schone PDF's. Het soort documenten waarbij elk teken al machineleesbaar, netjes gestructureerd en klaar voor chunking is. Dat is misschien 30% van de documenten waar ik mee te maken heb.

De andere 70%? Gescande contracten. Diavoorstellingen geëxporteerd naar PDF. Onderzoekspapers met LaTeX-vergelijkingen. Financiële rapporten waarbij de belangrijkste data in staaf- en cirkeldiagrammen zit. Interne memo's die iemand heeft afgedrukt, met de hand ondertekend en vervolgens ingescand. Overheidsformulieren. Facturen met logo's en tabellen die als afbeeldingen zijn weergegeven.

Standaard RAG-pijplijnen -- inclusief vanilla LightRAG -- gaan met deze documenten om via wat ik de "tuurprocedure en hopen maar"-aanpak noem. Ze voeren basiscodering uit, halen gedeeltelijke rommel op uit de OCR-laag, chunken welke tekst ze ook vinden, embedden het en noemen het klaar. De grafieken? Onzichtbaar. De afbeeldingen? Genegeerd. Het gescande handschrift? Een salade van slecht herkende tekens.

Ik probeerde workarounds. Ik runde documenten door aparte OCR-tools voordat ik ze aan LightRAG voerde. Ik gebruikte GPT-4o om afbeeldingen te beschrijven en injecteerde die beschrijvingen dan als tekst. Ik bouwde zelfs een voorverwerkingspijplijn die afbeeldingen uit PDF's haalde, ze naar een visiemodel stuurde, tekstbeschrijvingen terugkreeg en die beschrijvingen samenvoegde in de originele tekststroom voor het chunken.

Het werkte. Nauwelijks. De onderhoudsoverhead was zwaar, de verwerkingskosten waren hoog omdat elke afzonderlijke afbeelding door een cloud-vision-API ging, en de kennisgraaf eindigde met vreemde ontkoppelingen tussen de "echte" tekstentiteiten en de "beschreven" afbeeldingsentiteiten. Ze bestonden in parallelle universums binnen dezelfde database.

RAG Anything lost dit op op een fundamenteel andere manier. In plaats van afbeeldingen te behandelen als een bijkomstigheid die naar tekst moet worden geconverteerd, verwerkt het ze als een first-class datatype met hun eigen embedding-ruimte en hun eigen tak van de kennisgraaf -- en voegt dan alles samen in een uniforme ophaallaag. Het onderscheid is belangrijker dan het misschien klinkt.

Maar voordat ik de architectuur uitleg, moet je de documentparser begrijpen die het allemaal mogelijk maakt.

MinerU: De Documentparser die het Zware Werk Doet

In het hart van RAG Anything zit MinerU, een open-source documentparser van het OpenDataLab-team. Als je het nog niet bent tegengekomen, MinerU is wat er gebeurt als je een PDF-extractietool bouwt die werkelijk de complexiteit van echte documenten respecteert.

De meeste PDF-parsers behandelen een pagina als een platte tekststroom. MinerU behandelt het als een lay-out -- met koppen, alinea's, tabellen, afbeeldingen, vergelijkingen, voetnoten en zijbalken, elk geïdentificeerd en doorgestuurd naar een gespecialiseerd extractiemodel. Zie het als een triage-systeem. Het document raakt MinerU, en MinerU zegt: "Dit blok is een kop. Dit blok is hoofdtekst. Dit is een tabel. Dit is een grafiekafbeelding. Dit is een LaTeX-vergelijking." Elk onderdeel wordt verwerkt door het model dat het meest geschikt is.

Voor tekst gebruikt MinerU PaddleOCR -- Baidu's open-source OCR-engine die vanaf PP-OCRv5 meer dan 100 talen ondersteunt. PaddleOCR is niet alleen tekens herkennen. Het verwerkt complexe lay-outs, meerkolomstekst, geroteerde tekst en tekst ingebed in afbeeldingen. Wanneer MinerU een tekstblok in een gescande PDF identificeert, haalt PaddleOCR de werkelijke tekens op met verrassend hoge nauwkeurigheid.

Voor niet-tekstelementen -- grafieken, diagrammen, foto's, schematische tekeningen -- neemt MinerU een andere aanpak. Het legt ze vast als schermopnames. Schone, bijgesneden schermopnames die de visuele informatie precies bewaren zoals die op de pagina verschijnt.

Deze scheiding is het kernin­zicht dat RAG Anything laat werken. In plaats van te proberen alles naar tekst te forceren (wat informatie verliest) of te proberen alles als afbeeldingen te verwerken (wat duur en traag is), splitst MinerU het document in twee nette bakken:

• Tekstbak: Alles dat werkelijk tekst is, geëxtraheerd via OCR met hoge getrouwheid
• Afbeeldingsbak: Alles dat visueel is, vastgelegd als schermopnames met volledige context

Beide bakken voeden de volgende fase van de pijplijn. En hier wordt de architectuur van RAG Anything interessant -- want elke bak krijgt zijn eigen parallelle verwerkingstrack.

MinerU draait volledig lokaal. Geen API-aanroepen voor de parsefase. Geen data die je machine verlaat. De wisselwerking is dat het zwaarder is dan een eenvoudige PDF-bibliotheek -- je downloadt echte ML-modellen voor lay-outdetectie, OCR en componentclassificatie. Op mijn M2 MacBook Pro was de initiële modeldownload ongeveer 2 GB. Daarna duurt het parsen van een gescande PDF van 50 pagina's op CPU ongeveer 45 seconden. Overschakelen naar GPU (wat ik in de instellingsectie zal behandelen) verkort dit tot ongeveer 12 seconden.

De lokale verwerking is het benadrukken waard. Elke pagina van je document blijft op je hardware tijdens het parsen. De enige keer dat data je machine verlaat is in de volgende fase, wanneer geëxtraheerde tekst en afbeeldingen naar een LLM worden gestuurd voor entiteitsextractie en embedding-generatie.

De Dual-Pipeline-architectuur: Hoe RAG Anything Eigenlijk Werkt

Hier wordt de engineering echt slim. Zodra MinerU je document in tekst- en afbeeldingsbakken heeft gesplitst, voert RAG Anything twee parallelle verwerkingspijplijnen uit -- één voor elke bak. Beide pijplijnen doen dezelfde twee dingen, maar op een andere manier.

Pijplijn 1: Tekstverwerking

De tekstbak gaat naar een LLM (standaard GPT-4o mini, hoewel je elk model kunt verwisselen). Het LLM voert twee bewerkingen uit:

1. Entiteits- en relatieextractie -- Het leest de tekst en identificeert entiteiten (mensen, bedrijven, concepten, datums, financiële cijfers) en de relaties daartussen. Dit worden knooppunten en randen in een kennisgraaf.
2. Embedding-generatie -- De tekstchunks worden omgezet naar vectorembeddings (standaard met text-embedding-3-large) en opgeslagen in een vectordatabase.

Dit is in wezen wat vanilla LightRAG al doet. Niets nieuws hier.

Pijplijn 2: Afbeeldingsverwerking

De afbeeldingsbak gaat naar hetzelfde LLM, maar de interactie is anders. Elke schermopname -- elk diagram, elke grafiek, elk schematisch tekening en visueel element dat MinerU heeft geëxtraheerd -- wordt naar de visiemogelijkheden van het LLM gestuurd. Het LLM analyseert de afbeelding en voert dezelfde twee bewerkingen uit:

1. Entiteits- en relatieextractie uit visuele inhoud -- Het model bekijkt een staafdiagram en extraheert entiteiten zoals "Q1 Omzet: $2,4M" en "Q3 Omzet: $3,1M" en de relatie "omzet steeg 29% van Q1 naar Q3." Dit worden knooppunten en randen in een afbeeldingsspecifieke kennisgraaf.
2. Embedding-generatie vanuit visuele beschrijvingen -- Het model genereert rijke tekstbeschrijvingen van elke afbeelding, en die beschrijvingen worden omgezet naar embeddings en opgeslagen in een afbeeldingsspecifieke vectordatabase.

Nu heb je vier datastructuren:

De Samenvoeging

RAG Anything voegt deze vier structuren vervolgens samen tot twee: één uniforme vectordatabase en één uniforme kennisgraaf. De tekst- en afbeeldingsentiteiten bestaan naast elkaar in dezelfde graaf. De tekst- en afbeeldingsembeddings leven in dezelfde vectorruimte. Wanneer je het systeem bevraagt, vindt ophaling plaats over beide modaliteiten tegelijk.

Dit is het deel dat mijn "parallel universum"-probleem oploste. Toen ik afbeelding-naar-tekst-conversie deed als een voorverwerkingsstap, waren de afbeeldingsafgeleide entiteiten en de tekstafgeleide entiteiten ontkoppeld. De samenvoeging van RAG Anything zorgt ervoor dat ze gekoppeld zijn. Als de tekst "Q3-omzet" vermeldt en een staafdiagram Q3-omzetgegevens toont, bestaan beide entiteiten in dezelfde kennisgraaf met overlappende relaties. De ophaallaag kan uit beide bronnen putten om een volledig antwoord te construeren.

En hier is het deel dat ik niet had verwacht: de samengevoegde RAG Anything-database combineert vervolgens met je bestaande LightRAG-database. Als je al LightRAG hebt gedraaid met tekstdocumenten, overschrijft RAG Anything dat niet. Het voegt eraan toe. Je eindigt met één geconsolideerde vectordatabase en één geconsolideerde kennisgraaf die alles overspant -- je originele tekstdocumenten EN je nieuw opgenomen multimodale documenten.

De query-ervaring verandert helemaal niet. Dezelfde API. Dezelfde prompts in natuurlijke taal. Dezelfde ophaalmodussen. Het systeem handelt de complexiteit van multi-bron, multi-modale ophaling achter de schermen af.

Die naadloosheid was wat me overtuigde het te adopteren. Ik hoefde niets te herbouwen. Ik hoefde mijn querypatronen niet te wijzigen. Ik kreeg gewoon de mogelijkheid om een geheel nieuwe categorie documenten op te nemen.

Hoe Ik Alles Heb Opgezet (Stap voor Stap)

Ik zal het niet mooier maken dan het is: de initiële setup is zwaarder dan vanilla LightRAG. Je voegt een documentparser met ML-modellen, een OCR-engine en extra Python-afhankelijkheden toe. Maar eenmaal geconfigureerd is de dagelijkse ervaring soepel.

Dit is de exacte setup die ik heb gevolgd.

Stap 1: Zorg dat LightRAG al draait.

Als je LightRAG nog niet hebt opgezet, begin daar dan. RAG Anything omhult LightRAG -- het heeft een werkende installatie nodig om uit te breiden. De LightRAG GitHub-repository heeft duidelijke instructies. Ik runde LightRAG met de Docker-gebaseerde UI, die een webinterface geeft voor het uploaden van tekstdocumenten en het bevragen van de kennisgraaf.

Stap 2: Installeer RAG Anything en zijn afhankelijkheden.

RAG Anything is installeerbaar via pip:

pip install raganything

Dit haalt het kernframework binnen. Maar je hebt ook MinerU nodig voor documentparsing:

pip install mineru

De eerste keer dat MinerU draait, downloadt het zijn lay-outdetectie- en classificatiemodellen. Verwacht ongeveer 2 GB aan downloads. PaddleOCR wordt meegeleverd als een MinerU-afhankelijkheid, dus je hoeft het niet apart te installeren.

Stap 3: Gebruik de Claude Code one-shot setup prompt.

Dit was het deel dat me uren bespaarde. De RAG Anything-repo bevat een Claude Code-prompt die de configuratie automatiseert:

• Werkt opslagpaden bij om overeen te komen met je bestaande LightRAG-datamap
• Configureert de AI-modellen (GPT-4o mini voor entiteitsextractie, text-embedding-3-large voor embeddings standaard)
• Herstelt een bekende bug waarbij embeddings dubbel worden gewikkeld tijdens de samenvoeging

Ik runde de prompt in Claude Code gericht op mijn LightRAG-projectmap, en het regelde de configuratie in ongeveer 90 seconden. Zonder dit had ik handmatig configuratiebestanden moeten bewerken en waarschijnlijk een uur moeten vechten tegen de double-wrap bug voordat ik het GitHub-issue erover vond.

Stap 4: Configureer je API-sleutels.

RAG Anything heeft toegang nodig tot een LLM met visiemogelijkheden voor beeldverwerking. Ik gebruikte GPT-4o mini omdat de kosten laag zijn en de visiekwaliteit goed is voor grafiek- en diagraminterpretatie. Je hebt je OpenAI API-sleutel nodig ingesteld in de omgeving of het configuratiebestand.

Voor embeddings is de standaard text-embedding-3-large. Dezelfde API-sleutel dekt het.

Stap 5: Test met een eenvoudig document.

Voordat ik er complexe gescande PDF's in gooit, testte ik met een eenpaginadocument met één alinea tekst en één staafdiagram. Dit valideert dat MinerU correct parseert, PaddleOCR tekst extraheert, het visiemodel het diagram interpreteert en de samenvoeging een uniforme database produceert.

from raganything import RAGAnything

rag = RAGAnything(
    working_dir="./rag_storage",
    llm_model="gpt-4o-mini",
    embedding_model="text-embedding-3-large"
)

# Verwerk een multimodaal document
rag.insert("./test_document.pdf")

# Bevraag over zowel tekst als visuele inhoud
result = rag.query("Wat laat het staafdiagram zien over de omzet?")
print(result)

Toen dit werkelijke numerieke data uit het diagram teruggaf -- niet een beschrijving van het diagram, maar de specifieke waarden die het bevatte -- wist ik dat de pijplijn werkte.

Stap 6: Verwerk je echte documenten.

Hier is een belangrijke operationele detail: het opnemen van niet-tekstdocumenten kan niet via de LightRAG-webUI. De UI weet niets van MinerU of de dual-pipeline-architectuur. Je moet opname uitvoeren via het Python-script (of een Claude Code-skill die het omhult).

Tekstdocumenten kunnen nog steeds via de LightRAG-UI gaan zoals gewoonlijk. Alleen multimodale documenten hebben de scriptgebaseerde aanpak nodig.

Na opname merkte ik dat het opnieuw starten van de Docker-container die de LightRAG-UI draait soms nodig was om de nieuw samengevoegde database op te pikken. Niet elke keer, maar vaak genoeg dat ik een containerherstart aan mijn opnamescript toevoegde.

Als je liever iemand deze soort pijplijn helemaal opnieuw laat bouwen voor je specifieke documentworkflow, neem ik AI-integratieprojecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Pro-tip: Schakel MinerU over naar GPU-verwerking. Op CPU is MinerU functioneel maar traag voor grote documenten. Als je een NVIDIA GPU hebt (of een M-serie Mac met Metal-ondersteuning), maakt het configureren van MinerU om GPU-versnelling te gebruiken een dramatisch verschil. Mijn gescande PDF van 50 pagina's ging van 45 seconden naar 12 seconden. Claude Code kan je helpen de MinerU-configuratie aan te passen om GPU in te schakelen -- het is een configuratievlag-wijziging, geen herinstallatie.

Wat Ik Er Eigenlijk Doorheen Heb Gegooid (En Wat Er Terugkwam)

De echte test was dat financiële rapport. 47 pagina's. Ingescand van een afgedrukt document. Staafdiagrammen met maandelijkse omzet van januari tot september 2025. Tabellen weergegeven als afbeeldingen. Bedrijfslogo's. Voetnoten in kleine letters. Het soort document dat het ergste geval vertegenwoordigt voor traditionele RAG.

Ik runde het door het opnamescript en bekeek de logs. MinerU verwerkte elke pagina, classificeerde de componenten en splitste ze in de twee bakken. PaddleOCR extraheerde tekst uit de hoofdalinea's en koppen. De staafdiagrammen, tabellen en logo's gingen naar de afbeeldingsbak. Het LLM verwerkte beide bakken, extraheerde entiteiten en relaties, genereerde embeddings en voegde alles samen in de uniforme database.

Totale verwerkingstijd: ongeveer 3 minuten voor alle 47 pagina's op GPU. API-kosten voor de LLM-aanroepen: ongeveer $0,08. De lokale verwerking (MinerU + PaddleOCR) was gratis.

Toen bevroeg ik het.

"Wat waren de maandelijkse omzettrends van januari tot september 2025?"

Het antwoord kwam terug met specifieke cijfers. Januari: $1,2M. Februari: $1,4M. Maart: $1,3M. Helemaal door tot september: $2,1M. Het identificeerde de algehele opwaartse trend, noteerde de dip in maart en verwees naar de Q3-versnelling. Deze data bestond alleen in een staafdiagram. Er was geen tekst in het document die deze cijfers opsomde. Het visiemodel had het diagram gelezen, de waarden geëxtraheerd, entiteiten voor elk datapunt gemaakt en relaties daartussen opgebouwd in de kennisgraaf.

Ik runde een tweede query: "Welke afdelingen lieten de hoogste groei zien?"

Deze haalde uit beide modaliteiten. De tekstsecties van het rapport bespraken afdelingsprestaties in proza. De grafieken lieten de cijfers zien. Het antwoord combineerde beide -- specifieke groeiperc­entages citerende uit de grafieken en contextuele analyse uit de tekst. Uniforme ophaling, precies werkend zoals ontworpen.

Ter vergelijking runde ik hetzelfde document door mijn oude pijplijn -- vanilla LightRAG met basiscodering. De eerste query retourneerde niets nuttigs. De tweede query retourneerde een vage alinea uit de samenvatting die "sterke afdelingsprestaties" noemde zonder enige cijfers. Zwart op wit verschil.

De Eerlijke Afwegingen die Niemand Noemt

RAG Anything is indrukwekkend. Het heeft werkelijk een probleem opgelost waar ik maanden mee had geworsteld. Maar het is niet zonder wrijving, en ik zou je een slechte dienst bewijzen als ik de nadelen niet duidelijk uiteenzette.

De setup is zwaarder dan vanilla LightRAG. Je draait de ML-modellen van MinerU lokaal, wat betekent dat je ~2 GB modelgewichten downloadt, extra Python-afhankelijkheden beheert en af en toe versieconflicten tussen PaddleOCR en andere pakketten behandelt. Mijn eerste installatiepoging mislukte vanwege een numpy-versie-mismatch tussen MinerU en een andere bibliotheek in mijn omgeving. Een schone virtuele omgeving loste het op, maar het debuggen kostte me 30 minuten.

Niet-tekst opname vereist de opdrachtregel. Je kunt een gescande PDF niet slepen naar de LightRAG-webUI en het laten verwerken via de multimodale pijplijn. Je moet het Python-script uitvoeren. Voor een ontwikkelaar is dit een kleine ongemakkelijkheid. Voor iemand die hoopte op een puur GUI-gebaseerde workflow is het een beperking.

Docker-containerherstart na opname zijn vervelend. De LightRAG-UI detecteert niet altijd de samengevoegde database onmiddellijk. De container opnieuw starten is een 10-secondenoplossing, maar het onderbreekt actieve sessies. Ik heb dit ongeveer 60% van de tijd na multimodale opname zien gebeuren.

Nauwkeurigheid van het visiemodel varieert. GPT-4o mini doet een solide werk bij het interpreteren van standaard staafdiagrammen, lijngrafieken en eenvoudige tabellen. Maar het heeft moeite met dichtbevolkte spreidingsdiagrammen, complexe stroomdiagrammen en grafieken met overlappende labels. Ik had één infographic met een kleurgecodeerde matrix waarbij het model twee van de zes categorieën verkeerd identificeerde. Voor kritieke financiële data raad ik aan de geëxtraheerde entiteiten steekproefsgewijs te controleren aan de hand van het brondocument.

Kosten schaalt met afbeeldingsaantal, niet documentlengte. Elke afbeelding in de afbeeldingsbak maakt een aparte API-aanroep naar het visiemodel. Een document van 10 pagina's met 2 grafieken kost ongeveer hetzelfde als een tekstondersteund document van 100 pagina's. Maar een document van 10 pagina's met 30 ingesloten afbeeldingen? Dat zijn 30 vision API-aanroepen. De per-aanroepkosten zijn klein (fracties van een cent met GPT-4o mini), maar het telt op als je afbeeldingszware documenten op schaal verwerkt. Monitor je gebruik voor de eerste paar batches.

MinerU's classificatie is niet perfect. Ongeveer 5% van de tijd in mijn tests classificeerde MinerU een tekstblok verkeerd als een afbeelding of vice versa. Een alinea weergegeven in een ongebruikelijk lettertype werd vastgelegd als een schermopname in plaats van OCR'd. Een decoratieve koptekstafbeelding werd naar de OCR-pijplijn gestuurd in plaats van de visiepijplijn. Deze randgevallen breken het systeem niet -- ze betekenen gewoon dat sommige inhoud via het minder optimale pad wordt verwerkt.

Ondanks deze afwegingen is het nettoresultaat overweldigend positief. Ik ging van een RAG-systeem dat misschien 30% van mijn echte documenten kon verwerken naar één dat 90%+ aankan. Die sprong in dekking veranderde wat voor soort vragen ik kon stellen en wat voor soort workflows ik kon bouwen.

Waar Dit Naartoe Gaat (En Wat Ik Volg)

RAG Anything lanceerde in begin 2026 en het is al op een punt waar ik het productie-klaar acht voor de meeste use cases. Maar er zijn een paar ontwikkelingen die ik volg.

MinerU-Diffusion, een onderzoekspaper van het MinerU-team gepubliceerd in 2026, stelt voor OCR van documenten te behandelen als "omgekeerde rendering" met behulp van diffusiemodellen. Als dit in productie MinerU terechtkomt, kan de kwaliteitssprong van OCR significant zijn -- met name voor beschadigde scans en handgeschreven aantekeningen.

Multi-parser ondersteuning. RAG Anything ondersteunt al zowel MinerU als Docling als documentparsers, automatisch de betere kiezend op basis van documenttype. Naarmate meer parsers worden toegevoegd, zal de dekking van randgevaldocumentformaten blijven uitbreiden.

Lokale LLM-integratie. Op dit moment vereisen de entiteitsextractie- en afbeeldingsbeschrijvingsstappen een cloud-LLM met visiemogelijkheden. Maar de Ollama-gemeenschap experimenteert al met het draaien van RAG Anything tegen lokale visiemodellen zoals LLaVA. Als lokale visiemodellen GPT-4o mini-kwaliteit bereiken voor grafiekinterpretatie, zou de hele pijplijn kunnen draaien zonder cloud-API-aanroepen. Nul data die je machine verlaat. Nul per-document kosten na de initiële setup.

LightRAG's eigen evolutie. LightRAG passeerde 28.000 GitHub-sterren in begin 2026 en werd geaccepteerd op EMNLP 2025. Het project wordt actief onderhouden met incrementele updates die de grafiekstructuur niet verstoren -- wat betekent dat RAG Anything's samenvoeging compatibel zou moeten blijven naarmate LightRAG evolueert.

De bredere trend is duidelijk: RAG-systemen bewegen van tekst-alleen naar werkelijk multimodaal. De vraag is niet of je RAG-pijplijn afbeeldingen en grafieken moet kunnen verwerken. Het is of je er klaar voor bent wanneer het volgende belangrijke document als een gescande PDF vol visuele data op je bureau belandt.

De Setup die Nu Voor Mij Werkt

Na twee weken dagelijks gebruik is dit de configuratie waar ik op ben uitgekomen:

• Documentparser: MinerU met GPU-versnelling ingeschakeld
• OCR-engine: PaddleOCR (gebundeld met MinerU) -- verwerkt mijn Engelse en Bengaalse documenten zonder problemen
• LLM voor entiteitsextractie: GPT-4o mini -- snel, goedkoop en goed genoeg voor grafiekinterpretatie
• Embeddingmodel: text-embedding-3-large -- het kwaliteitsverschil ten opzichte van kleinere modellen is merkbaar in ophaalkwaliteit
• Opslag: Lokaal bestandssysteem met Docker-volumes voor de LightRAG-UI
• Opname-workflow: Claude Code-skill die het Python-opnamescript omhult, de containerherstart afhandelt en verwerkingsstatistieken logt
• Query-interface: LightRAG-webUI voor ad-hoc queries, Python API voor programmatische toegang

De totale maandelijkse kosten voor het draaien van deze setup over mijn documentbibliotheek zijn ongeveer $3-5 aan API-aanroepen. Het meeste daarvan is de initiële opname van afbeeldingszware documenten. Zodra documenten zijn opgenomen, slaan queries eerst de lokale kennisgraaf en vectordatabase aan -- het LLM wordt alleen aangeroepen voor responsegeneratie, niet voor ophaling.

Ter vergelijking: mijn vorige aanpak -- elke afbeelding door de vision API van GPT-4o als een voorverwerkingsstap laten gaan -- kostte me $15-20 per maand voor een kleinere documentbibliotheek. RAG Anything's lokaal-eerste parsing met selectieve cloudverwerking verlaagde mijn kosten met ongeveer 75%.

Wat Hierna Komt Als Je Dit Wilt Bouwen

Dit is wat ik zou doen als ik vandaag van nul zou beginnen.

Ten eerste, laat vanilla LightRAG draaien. Verwerk een paar tekstdocumenten. Stel enkele queries. Begrijp hoe de kennisgraaf werkt, hoe entiteiten en relaties worden geëxtraheerd en hoe de tweeniveau-ophaling (laagniveau voor specifieke feiten, hogniveau voor conceptuele thema's) zich gedraagt. Mijn vorige post over het bouwen van AI-onderzoekssystemen behandelt de kennisbeheerpatronen die hier van toepassing zijn.

Ten tweede, installeer RAG Anything en MinerU in een schone virtuele omgeving. Meng het niet met andere ML-projecten -- de afhankelijkheidsboom is diep genoeg dat versieconflicten waarschijnlijk zijn als je een omgeving deelt.

Ten derde, test met één, matig complex document. Niet je moeilijkste geval. Iets met een mix van tekst en een paar grafieken. Verifieer dat de vier datastructuren correct worden gegenereerd en samengevoegd.

Ten vierde, breid geleidelijk uit. Voeg meer documenten toe. Probeer verschillende typen -- gescande PDF's, diavoorstellingen, afbeeldingszware rapporten. Noteer waar de classificatie- of extractiekwaliteit daalt en of het uitmaakt voor je queries.

Ten vijfde, zet de opname-automatisering op. Of het nu een Claude Code-skill, een cron-taak of een handmatig script is dat je wekelijks uitvoert -- zorg voor een betrouwbaar proces voor het krijgen van nieuwe documenten in de pijplijn.

De kloof tussen "ik heb documenten" en "ik kan mijn documenten intelligent bevragen" was vroeger enorm voor alles buiten schone tekst. RAG Anything verkleint die kloof tot iets beheersbaars. Niet nul -- de setup is echt werk. Maar beheersbaar.

Dat financiële rapport dat drie weken op mijn bureaublad stond? Ik bevraag het nu dagelijks. Afgelopen dinsdag vroeg een klant naar seizoensgebonden omzetpatronen en ik had het antwoord -- met specifieke maandelijkse cijfers gehaald uit gescande staafdiagrammen -- in minder dan tien seconden. Niet omdat ik de data had onthouden. Omdat ik een systeem heb gebouwd dat de documenten die ik het geef werkelijk begrijpt, visuele data en al.

De gescande PDF hield op een dood bestand te zijn op het moment dat ik stopte afbeeldingen als tweederangsburgers in mijn RAG-pijplijn te behandelen.

Veelgestelde Vragen

Kan RAG Anything documenten verwerken zonder cloud-API-aanroepen?

De documentparsefase (MinerU + PaddleOCR) draait volledig lokaal zonder cloud-aanroepen. Entiteitsextractie en embedding-generatie vereisen momenteel een cloud-LLM met visiemogelijkheden, hoewel lokale alternatieven met Ollama en LLaVA in actieve ontwikkeling zijn door de gemeenschap.

Welke documentformaten ondersteunt RAG Anything?

RAG Anything verwerkt PDF's (zowel native als ingescand), DOCX, PPTX, XLSX en veelgebruikte afbeeldingsformaten. MinerU identificeert lay-outcomponenten in al deze formaten, waarbij tekst automatisch naar OCR en visuele elementen naar schermopname worden gerouteerd.

Hoeveel kost het om RAG Anything per document te draaien?

Tekst-alleen documenten kosten fracties van een cent. Voor afbeeldingszware documenten maakt elk visueel element één LLM vision API-aanroep -- ongeveer $0,001-0,003 per afbeelding met GPT-4o mini. Een gescande PDF van 50 pagina's met 20 grafieken kost ongeveer $0,04-0,08 in totaal. Zie voor de volledige kostenbreakdown de setup-sectie hierboven.

Vervangt RAG Anything LightRAG?

Nee. RAG Anything is een wrapper die LightRAG uitbreidt met multimodale mogelijkheden. Je bestaande LightRAG-database, kennisgraaf en query-interface blijven ongewijzigd. RAG Anything voegt eraan toe door multimodale data samen te voegen in dezelfde uniforme structuren.

Hoe nauwkeurig is de grafiek- en diagramdataextractie?

Voor standaard staafdiagrammen, lijngrafieken en eenvoudige tabellen is de nauwkeurigheid hoog -- GPT-4o mini identificeert waarden en trends correct in de grote meerderheid van gevallen. De nauwkeurigheid daalt bij dichtbevolkte spreidingsdiagrammen, overlappende labels en complexe grafieken met meerdere assen. Controleer kritieke financiële data steekproefsgewijs aan de hand van brondocumenten.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur schalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (zakelijke oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io