De semantic training gap is het verschil tussen de woorden van een vak kennen en weten hoe één bedrijf ze gebruikt. Een AI-model heeft genoeg gelezen om vlot over machines en foutcodes te praten. Het weet niet dat het lijmstation in jouw database "S4" heet. Dus verzint het misschien een aannemelijke code als "BOND-1", vindt geen gegevens en meldt dat er geen problemen zijn.
Waar komt de term vandaan?
Grama Chethan van Siemens Digital Industries Software introduceerde hem in een paper over AI-agents in de maakindustrie (mei 2026). Hij beschrijft een kloof tussen hoe AI-systemen in hun training de woordenschat van een vakgebied leren en hoe een fabriek die woorden betekenis geeft: via de verbanden tussen apparatuur, procesparameters, foutcodes en regelgeving. Zijn openingsvoorbeeld is één temperatuursensor met drie namen: TT-4201 voor de procesingenieur, %IW64 in het PLC-programma en ReflowZone4 in het manufacturing execution system. Een AI-agent kent het jargon van alle drie de systemen, maar weet niet dat de drie namen naar één sensor verwijzen. Zijn antwoord klinkt taalkundig precies en is operationeel fout. De auteur benadrukt dat training alleen die kloof niet kan dichten.
Wat gaat er in de praktijk mis?
Op een analyseplatform in ontwikkeling, waarvan de twaalf tools vrije tekst als parameter accepteerden, kreeg de agent de vraag naar trends in afkeurmeldingen bij het lijmstation. Hij schreef een vlotte analyse, maar zijn databasequery vroeg om station "BOND-1". Dat station bestaat niet; het lijmstation heet S4. De query leverde niets op, en de agent meldde dat er geen fouten waren geregistreerd, terwijl juist dat station die week het hoogste aandeel afkeurmeldingen van de lijn had.
Het paper noemt dit tool-parameter fabrication en onderscheidt het van feitelijke hallucinatie: een verzonnen feit kun je controleren, maar een verzonnen queryparameter levert ongemerkt verkeerde gegevens op. Bij meerdere agents zonder gedeelde definities ziet het paper ook semantic drift: de ene agent schrijft "S1", de andere "CNC-Bay-1", en hun antwoorden lopen uiteen.
Hoe dicht het paper de kloof?
Het zet de ontologie van de fabriek, een beschrijving van haar stations, producten, foutcodes en certificeringen en hoe die samenhangen, als getypeerd configuratiebestand per domein in de toollaag. De tools draaien op een MCP-server, en een orkestratielaag dwingt een contract van drie bewerkingen af:
- Resolve: elke identifier in een tool-aanroep moet overeenkomen met een item in de geladen ontologie voordat de query draait. Zo niet, dan wordt de aanroep geweigerd met de lijst geldige waarden.
- Contextualize: een geldige identifier brengt zijn context mee, zoals de foutcodes en regels die gelden.
- Annotate: elk resultaat draagt die context en de versie van de ontologie.
Toen de agent get_station_performance("BOND-1") aanriep, werd de aanroep geweigerd met de geldige set S1 tot en met S6, en corrigeerde de agent zichzelf naar S4.
Wat liet het experiment zien?
De test gebruikte 72 vragen, één per tool voor elk van zes industrieconfiguraties, op gesimuleerde fabrieksdata, met het model Qwen3-32B op temperatuur 0. Met vrije-tekstparameters gebruikten 31 van de 72 tool-aanroepen (43%) een verzonnen identifier, en gaven er maar 14 (19%) het juiste resultaat. Met parameters die beperkt waren tot waarden uit de ontologie werd niets verzonnen en waren alle 72 juist.
Wat zijn de beperkingen?
Het paper noemt ze zelf:
- De vergelijking is zwak. De aanpak werd vergeleken met helemaal geen beperkingen. Volgens de auteur zou een gewone lijst toegestane waarden bij function calling het grootste deel van die 43% al wegnemen. RAG, few-shot prompting en fine-tuning zijn niet getest.
- De 43% geldt voor één model en is niet te generaliseren. De 0% volgt uit de controle zelf en geldt dus voor elk model dat zo'n lijst respecteert.
- Alle resultaten komen uit een simulatie waarvan het team van de auteur de zes configuraties schreef. In een bestaande fabriek moet de ontologie eerst gevonden worden voordat je haar kunt afdwingen.
- De auteur werkt bij Siemens, en het paper is een preprint.
De blogpost over AI-agent-loops zet het naast twee andere projecten die zulke controles naar code verplaatsen.