Slimme diagnostiek: een ontologisch reparatiesysteem

"Hij gaat opeens niet meer aan."

Dit is de klacht van de gebruiker. Na een uur analyseren, meten en demonteren, concludeert de reparateur:

"Motor defect."

Tussen deze twee zinnen – de klacht en de conclusie – ligt een wereld van expertise. Het is een complex web van hypotheses, tests, observaties en deductie, vaak gebaseerd op jarenlange ervaring.

De vraag is: hoe leg je deze kennis vast zodat je er beter gebruik van kunt maken?

Ontologisch systeem

Kennis is meer dan data en het antwoord is een ontologisch systeem. Dat is de blauwdruk van concepten, relaties en regels wat samen het semantisch raamwerk vormt voor je data.

De blauwdruk
Vanuit de W3c zijn er een aantal standaarden die ons kunnen helpen hierbij: OWL (Web Ontology Language) en SWRL: A Semantic Web Rule Language.

Het OWL format definieert concepten en relaties, bijvoorbeeld:

@prefix ex: <http://example.org/repair#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Ketting a owl:Class ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:onderdeelVan ;
        owl:someValuesFrom ex:Fiets
    ] .

ex:Fiets a owl:Class .
ex:onderdeelVan a owl:ObjectProperty .

Hier staat (in turtle syntax): een ketting is een onderdeel van een fiets.

In SWRL leg je de regels vast:

Fiets(?f) ^ heeftOnderdeel(?f, ?k) ^ Ketting(?k) ^ Roestig(?k)
→ ReparatieNodig(?f)

Oftewel: Als een fiets een roestige ketting heeft, dan heeft die fiets een reparatie nodig.

Dit soort classificaties, relaties en regels kun je vastleggen met Protege en en ook naar andere formaten zoals RDF/XML exporteren.

De data

Met deze blauwdruk leg je het concept, relaties en regels vast maar niet de data zelf. Bijvoorbeeld alle reparatiedossiers met alle diagnosestappen.

Traditionele relationele databases zijn hier niet voor ontworpen. Ja, je kan er prima relaties in vastleggen, maar niet makkelijk wat voor relaties.

Beter geschikt is een kennisgraaf (knowledge graph) die data als triple store opslaat. Een triple store legt data vast in deze vormen:

Onderwerp — Predicaat — Object

Ketting isOnderdeelVan Fiets

Het predicaat (ook wel gezegde genaamd in het Nederlands) vertelt iets over het onderwerp en kan dus een definitie zijn in de blauwdruk (OWL).

Een knowledge graph kan gebruik maken van de eerder gemaakte blauwdruk van onze data. Je definieert dan niet alleen wat waar is maar ook welke regels gelden. Hierdoor ontstaat een declaratief systeem waar vanzelf de logica uit vloeit en waar een reasoner nieuw triple store data uit kan afleiden (inference).

Je weet dat A is een Ketting en Ketting ⊑ OnderdeelVan Fiets
⇒ Je kunt afleiden dat A onderdeel is van een Fiets.

Met een query taal zoals SPARQL (speciaal voor triple store patterns) kan je bijvoorbeeld:

PREFIX ex: <http://example.org/repair#>

SELECT ?fiets
WHERE {
  ?fiets a ex:ReparatieNodig .
}

Hier zie je nu de kracht van de reasoner: in onze data hadden we nergens vastgelegd dat een bepaalde fiets een reparatie nodig had. Maar omdat de reasoner dit afgeleid heeft uit de regels, hebben we deze kennis wel!

Voorbeeld: zaklamp

Laten we nog op een andere manier bekijken aan de hand van een object dat we allemaal kennen: een simpele, ouderwetse zaklamp (met gloeilampje). Een zaklamp is een perfect voorbeeld. Hij heeft weinig onderdelen, maar de diagnostische logica is rijk en niet-lineair.

Laten we onze zaklamp 'ontologisch' ontleden.

Stap 1: De Bouwstenen (concepten)

Eerst definiëren we de 'dingen' in onze wereld. In een ontologie noemen we dit de concepten of klassen.

Product: Zaklamp
Componenten:
- Batterijen
- Lampje (gloeilamp)
- Schakelaar
- Contactpunten (de metalen veertjes en strips)
- Behuizing

Stap 2: De Klachten (symptomen)

Vervolgens definiëren we de klachten die een gebruiker kan melden. Dit zijn de symptomen.

Symptoom A: "Hij gaat helemaal niet aan."
Symptoom B: "Hij geeft maar zwak licht."
Symptoom C: "Het licht flikkert."

Stap 3: Het echte probleem (oorzaak)

Dit zijn de daadwerkelijke, vastgestelde defecten.

Oorzaak 1: Batterijen zijn leeg (of bijna leeg).
Oorzaak 2: Lampje is doorgebrand.
Oorzaak 3: Contactpunten zijn vies of gecorrodeerd.
Oorzaak 4: Schakelaar is mechanisch defect.

De blauwdruk

Tot nu toe is dit een verzameling simpele lijstjes. Een standaard database zou dit ook kunnen opslaan. De echte kracht van een ontologie zit in het vastleggen van de concepten, regels en relaties tussen deze concepten.

Hiervoor moeten we eerst het denkproces van de expert vastleggen. Dit doen we met een gedetailleerd logboek, dat we kunnen visualiseren als een 'diagnostisch pad': elke hypothese, test, observatie, (de)montage, vervanging en conclusie wordt een diagnosestap.

Zaklamp flowchart — De mogelijke diagnosestappen van symptoom naar oorzaak

Volledige flowchart bekijken

Een flowchart zoals deze is eigenlijk een visuele representatie van de OWL+WSRL regels.

Ons systeem is niet langer een dom logboek. Het wordt een kennisgraaf die "begrijpt" dat één oorzaak meerdere symptomen kan hebben, en dat één symptoom meerdere oorzaken kan hebben, elk met hun eigen diagnostische pad.

Van data naar een expert-systeem

Naarmate dit systeem groeit, kunnen we er verschillende voordelen uit halen:

Geleide Diagnostiek: Een junior reparateur krijgt een zaklamp met Symptoom C (Flikkert). Het systeem zegt: "Begin met het controleren van de Contactpunten. Dit is in 82% van de eerdere gevallen de oorzaak."
Patroonherkenning: Het systeem ontdekt misschien dat Behuizing type Y vaker leidt tot Oorzaak 3 (Corrosie) dan Behuizing type Z. Dit is cruciale feedback voor productontwerp.
Kennisbehoud: De expertise van uw senior reparateur wordt gedigitaliseerd. Zijn unieke 'gevoel' voor een probleem wordt omgezet in gewogen relaties binnen de kennisgraaf.

Immers de juiste diagnose stellen is essentieel om uiteindelijk tot reparatie over te gaan.

Ai echt slim maken

Door niet alleen de data, maar juist de concepten, relaties en regels daartussen vast te leggen in een ontologie, bouwen we een declaratief systeem dat niet alleen onthoudt wat er is gebeurd, maar begrijpt waarom. Dit werkt fundamenteel anders dan een Ai model dat veronderstelt verbanden uit grote hoeveelheden getrainde data, terwijl een ontologisch systeem de verbanden kent die door experts zijn vastgelegd.

In bovenstaande komt geen Ai (in de zin van een LLM taal of multimodel, of agents) te pas. Maar Ai kan dit systeem wel als tool gebruiken. In die zin kan een Ai de user interface vormen om gebruik te maken van de kennis. Het voordeel is dat je dan Ai in zijn kracht zet maar tegelijkertijd een deterministisch en betrouwbaar systeem ontwerpt.