Productiehal, twee uur 's nachts. Een ervaren technicus zoekt in een handleiding van 3.400 pagina's welk type en welke hoeveelheid smeermiddel de fabrikant voorschrijft voor een lager bij temperaturen boven 80 °C. Het PDF heeft inconsistente paginanummering, de tabel met waarden is ingescand als afbeelding, en de norm waarnaar de handleiding verwijst staat in een apart bestand. Na 40 minuten vindt hij wat hij zocht. Dezelfde situatie herhaalt zich tientallen keren per dienst, door de hele fabriek heen.
Precies dit probleem lossen LLM's over industriële documentatie op. Het gaat niet om een buzzword — het is een concrete, verifieerbare use-case waarbij een correct ingezet systeem meetbaar uren per operator per maand bespaart. Dit artikel geeft de beslissing: wat werkt, waar de naïeve aanpak faalt, en wat u moet oplossen voordat u begint.
Wat u eigenlijk wilt bereiken
Voordat u architectuur bespreekt, moet u helder hebben wat u van het systeem verwacht. In de praktijk zien we drie verschillende use-cases die op elkaar lijken maar andere eisen stellen:
1. Zoeken en Q&A voor technici — de technicus stelt een vraag in gewone taal, het systeem antwoordt met een verwijzing naar een specifiek deel van de handleiding of norm. Geen kopie van de tekst, maar een antwoord met bronvermelding: "Volgens sectie 7.3.2 van de handleiding van apparaat XY is het voorgeschreven smeermiddel ISO VG 220, elke 2.000 bedrijfsuren aan te brengen."
2. SOP-navigatie en stap-voor-stap begeleiding — de operator werkt volgens een procedure en heeft uitleg nodig bij een stap, een alternatief bij een niet-beschikbaar gereedschap, of een snelle verificatie of hij het juiste doet. Het systeem moet deterministisch en nauwkeurig zijn — een fout antwoord bij een productieproces heeft directe kosten.
3. Normatieve conformiteit en auditondersteuning — de ingenieur moet snel vaststellen welke delen van de documentatie de eisen van een specifieke norm dekken (bijv. ISO 9001, IEC 62443, ATEX), of hiaten identificeren. Dit vereist begrip van zowel de structuur van de norm als de interne documentatie.
Elk van deze use-cases heeft andere eisen aan nauwkeurigheid, latency en evaluatiemethode. Ze door elkaar halen in één pilot is een veelgemaakte fout.
Waarom naïeve RAG op industriële documenten niet werkt
RAG — afkorting voor retrieval-augmented generation — is de basisarchitectuur: u splitst documenten op in stukken (chunks), slaat ze op in een vectordatabase, zoekt bij een vraag relevante stukken op en legt ze aan het model voor. Op gewone documenten werkt dat goed. Op industriële documenten stuit u op vier problemen die actief moeten worden opgelost.
Probleem 1: Naïeve chunking versnippert tabellen
Een apparaathandleiding bevat een tabel met 30 rijen en 8 kolommen: apparaattype, bedrijfstemperatuur, type smeermiddel, interval, hoeveelheid, norm, opmerking, hoogte boven zeeniveau. Naïeve chunking op tekencount snijdt deze tabel in 4 fragmenten. Elk fragment verliest de context van de kolommen die op de vorige pagina stonden.
Oplossing: een documentparser die tabellen herkent en als geheel bewaart, of ze omzet naar een gestructureerde vorm (JSON, Markdown-tabel). Hulpmiddelen zoals LlamaIndex hebben gespecialiseerde parsers voor deze gevallen. Multimodale modellen (bijv. Qwen2.5-VL) kunnen tabellen ook uit ingescande PDF's extraheren — wat gangbaar is in oudere handleidingen.
Probleem 2: Tekeningen en schema's zijn onzichtbaar voor text-only RAG
Elektrische schema's, hydraulische diagrammen, P&ID's (piping and instrumentation diagrams) — dit zijn essentiële onderdelen van technische documentatie die een text-only pipeline simpelweg overslaat. Als de technicus vraagt "waar bevindt klep V-12 zich op het hydraulische schema van lijn L2", antwoordt text-only RAG "de informatie is niet in de documenten aanwezig" of hallucineert.
De oplossing hangt af van de beschikbare middelen. De eenvoudigere weg: voor de belangrijkste tekeningen eenmalig gestructureerde tekstbeschrijvingen aanmaken (handmatig of met een VLM), die samen met de rest van de tekst worden geïndexeerd. De zwaardere weg: een volwaardige multimodale pipeline waarbij een VLM direct bij indexering een beschrijving van de afbeelding genereert — dit werkt, maar vereist een rekenintensief model bij elk toegevoegd document.
Probleem 3: Normaversies en kruisverwijzingen
Industriële documentatie staat vol met verwijzingen: "handel volgens ISO 14119:2013, bijlage D" of "zie tekening D-04-7812-rev3". Naïeve RAG lost deze verwijzingen niet op — het laadt het fragment waar de norm wordt vermeld, maar heeft geen toegang tot de inhoud van de norm zelf als die niet in de index staat. Resultaat: een antwoord dat de verwijzing citeert maar geen werkelijke informatie bevat.
Oplossing: zorgvuldig bronbeheer. Vóór ingebruikname moet expliciet worden besloten welke normen en welke versies deel uitmaken van de index, en er moet een updateproces worden ingevoerd bij revisies. Dit is evenzeer een organisatorisch als een technisch vraagstuk.
Probleem 4: Het contextvenster is niet onbeperkt
Zelfs een contextvenster van 1 miljoen tokens van frontier-modellen is geen oplossing voor een handleiding van 5.000 pagina's. De aandacht van het model verspreidt zich bij extreem lange invoer — een verschijnsel dat onderzoek herhaaldelijk bevestigt. RAG blijft relevant ook bij modellen met een lang contextvenster, omdat het selectief alleen de relevante delen laadt in plaats van het volledige document.
Hoe u een betrouwbare pipeline bouwt
Een goed doordachte pipeline voor industriële documentatie heeft meerdere lagen bovenop basis-RAG.
Documentvoorbereiding (ingestion)
Dit is de langste stap en de meest onderschatte. Vóór indexering:
- Onderscheid inhoudstypen: pure tekst, tabellen, afbeeldingen, tekeningen. Elk type verdient een andere verwerking.
- Ingescande documenten via OCR — niet de oude
Tesseractvoor complexe technische documenten, maar een gespecialiseerde VLM of document intelligence API die de paginacontext begrijpt (een getal in de rechterbovenhoek = paginanummer, hetzelfde getal in een tabel = kritieke waarde). Meer over deze laag in het artikel OCR en document intelligence voor de industrie. - Metadata: sla voor elk chunk het brondocument, paginanummer, sectie, documentversie en geldigheidsdatum op. Zonder metadata zijn citaties niet mogelijk.
- Hiërarchische structuur: hoofdstuk → subhoofdstuk → tabel/procedure.
LlamaIndexheeft native ondersteuning voor hiërarchische chunking.
Retrieval — meer dan alleen vectorzoeken
Puur vectorzoeken heeft zwakke plekken: het vangt semantisch vergelijkbare stukken op, maar kan een exacte treffer op een sleutelwoord missen (onderdeelnummer, alarmcode, apparaataanduiding). Hybrid search — een combinatie van BM25 (trefwoorden) en vectoren — is in een industriële context belangrijker dan in gewone toepassingen. Zie hybrid search met BM25 en vectoren voor een uitgebreide behandeling.
Voeg boven hybrid search een reranker toe — een model dat resultaten op relevantie ten opzichte van de vraag herordent. Een BGE reranker (vrij beschikbaar) of een API (bijv. Cohere Rerank) verbetert de nauwkeurigheid aanzienlijk bij lange documenten met terugkerende frasen.
Genereren met citaties
Dit is het cruciale verschil met een gewone chatbot: elk antwoord moet een verwijzing naar een specifieke bron bevatten. De prompt moet expliciet vereisen: - Welk document, sectie, pagina. - Letterlijk citeren van de kritieke waarde in plaats van parafraseren. - Expliciet aangeven als de informatie in de beschikbare documenten niet aanwezig is.
Dit laatste punt is doorslaggevend. Het antwoord "ik kan deze informatie niet vinden in de beschikbare handleidingen" is aanzienlijk beter dan een zelfverzekerde gehallucineerde waarde. De system prompt zo instellen dat het model expliciet onzekerheid uitdrukt, is belangrijker dan de keuze van het model. Meer over citaties en grounding in RAG in het artikel citaties en grounding in RAG.
Evaluatie vóór ingebruikname
Stel technici niet bloot aan een systeem dat u niet op echte vragen hebt getest. Een basisset voor evaluatie:
- 50–100 vragen uit echte situaties die technici werkelijk oplossen
- Voor elke vraag een geverifieerd antwoord met bronverwijzing (gouden standaard)
- Meting: faithfulness (klopt het antwoord met de bron?), answer relevance (beantwoordt het de vraag?), hallucinatiepercentage
Productiesystemen stellen doelen: faithfulness ≥ 95%, hallucinatiepercentage ≤ 2%. Correct geïmplementeerde RAG vermindert hallucinaties met 60–71% ten opzichte van pure LLM zonder grounding — maar elimineert ze niet volledig.
Modelkeuze: cloud versus on-prem
Voor industriële documenten geldt een andere logica dan voor publieke deployments. Technische documentatie bevat vaak interne knowhow, constructieparameters en veiligheidsprocedures. Veel bedrijven, met name in gereguleerde sectoren, willen deze data niet buiten hun eigen infrastructuur.
On-prem open-weight modellen zijn in 2026 een reële keuze:
- Familie
Qwen 2.5enQwen 3(Apache 2.0-licentie, geschikt voor commerciële inzet) — sterk in document understanding, inclusief multimodale varianten. Mistral Small(~22B) — goede verhouding tussen prestatie en hardwarevereisten.DeepSeek R1/V3(MIT-licentie) — sterk redeneerend, geschikt voor complexere vragen over normen en hun interpretatie.
Indicatieve hardwarevereisten: voor een 7B-model volstaat een GPU met 12–14 GB VRAM (QLoRA/quantized inference), voor een 22B-model heeft u 24 GB+ of meerdere GPU's nodig. Meer over hardwarekeuze in het artikel custom pc voor lokale LLM's.
Voor bedrijven zonder gevoelige data of met een helder data governance-beleid presteren frontier-modellen (Claude Sonnet, GPT-4o-klasse) aanzienlijk beter bij complex redeneren over gestructureerde documenten — tegen de prijs van API-kosten en data-egress.
Organisatorische randvoorwaarden die technologie niet oplost
Na tientallen RAG-deployments over documentatie zien we dat het technische deel doorgaans het kleinste probleem is; het organisatorische deel is het grotere.
Versiebeheer van documenten. Als een handleiding in vijf versies op verschillende gedeelde schijven staat zonder duidelijke markering van de actuele versie, indexeert u chaos. Vóór de AI-implementatie moet er een single source of truth bestaan — één gezaghebbende bron van de actuele documentatie. Dit is geen AI-probleem, maar document management.
Verantwoordelijkheid voor het bijwerken van de index. Wie voegt wanneer een nieuwe handleiding toe? Wie maakt de oude versie van een norm ongeldig? Zonder een vastgelegd proces werkt het systeem na 6 maanden met verouderde data en verliezen technici hun vertrouwen erin.
Passende verwachtingen bij technici. Een systeem dat 10% van de vragen niet beantwoordt en "weet ik niet" zegt, is correct geconfigureerd. Als technici 100% dekking verwachten, zal de eerste "weet ik niet" als een mislukking worden uitgelegd. Onboarding is een onderdeel van het project.
Waar het systeem faalt — en wat u daartegen kunt doen
Zelfs een goed gebouwd systeem heeft grenzen. Die grenzen eerlijk vastleggen vóór de lancering beschermt het project tegen teleurstelling.
Procedurele veiligheid: Het systeem mag nooit de enige bron van waarheid zijn voor procedures bij spanningvoerende werkzaamheden, werk in een ATEX-zone of andere veiligheidskritieke operaties. RAG vs. fine-tuning voor industriële toepassingen bespreekt wanneer fine-tuning beter is dan RAG juist voor deze gevallen — maar ook een fine-tuned model vervangt geen gecertificeerde training en beoordeling door een verantwoordelijke persoon.
Nieuwe apparatuur zonder documentatie: Als een apparaat niet in de index staat, antwoordt het systeem niet. Dit is een feature, geen bug — erger is als het documentatie zou hallucineren die niet bestaat.
Complexe diagnostiek: Vragen als "waarom trilt mijn apparaat meer dan gewoonlijk" gaan verder dan document-Q&A. Hier is ruimte voor voorspellende analyse en sensordata, niet voor RAG over handleidingen.
Veelgestelde vragen
Hebben we fine-tuning nodig, of is RAG voldoende?
Voor de meeste use-cases over documentatie volstaat RAG — het vereist geen voorbereiding van een dataset, geen training en geen risico op modeldegradatie. Fine-tuning voegt waarde toe als u wilt dat het model bedrijfsspecifieke terminologie begrijpt of antwoordt in een bepaald format. Het beslissingsraamwerk staat in het artikel RAG vs. fine-tuning.
Hoe zorgen we dat het systeem geen technische waarden hallucineert?
Combinatie van drie maatregelen: (1) een prompt die het model expliciet verbiedt buiten de beschikbare bronnen te antwoorden en een citaat vereist, (2) een reranker die de kwaliteit van de opgehaalde context verbetert, (3) een evaluatieset met regelmatige tests. Een hallucinatiepercentage onder de 2–3% bereikt u bij zorgvuldige implementatie — nul nooit.
Kan het systeem documenten in het Duits, Engels én Nederlands verwerken?
Ja, moderne embedding-modellen (bijv. BGE-M3) zijn meertalig en werken goed over talen heen. Vragen en antwoorden kunnen in een andere taal zijn dan het brondocument. In de praktijk raden we aan documenten in hun originele taal te indexeren en het model te laten vertalen in het antwoord — zo blijft de terminologieprecisie bewaard.
Hoe lang duurt de implementatie van een pilot?
Een pilotsysteem voor één type documentatie (bijv. handleidingen van één apparaat) met een evaluatieset en een basisinterface kost 4–8 weken. Meer tijd gaat zitten in de datavoorbereiding (OCR, opschonen, versiebeheer) dan in de technische implementatie zelf. Een volwaardig productiesysteem met meerdere documenttypen en integratie in bestaande systemen: 3–6 maanden.
Werkt dit ook voor ISO-normen en regelgevende documenten?
Ja, maar met een belangrijke kanttekening: normen zijn auteursrechtelijk beschermd (ISO, EN, NEN). U kunt een gekochte norm niet zomaar uploaden in een intern systeem — controleer de licentievoorwaarden. In de praktijk indexeren bedrijven interne documenten die de norm implementeren (technische voorschriften, checklists) en verwijzen ze naar specifieke eisnummers in plaats van de normatieve tekst letterlijk te citeren.
*Als u overweegt hoe u in de specifieke omstandigheden van uw documentatie de eerste stappen kunt zetten — verificatie van de use-case, beoordeling van beschikbare data, architectuurontwerp — staan we klaar voor een consultatie. MP Industrial Solutions implementeert RAG over industriële documentatie van de eerste datavoorbereiding tot en met productie-deployment.*