Draagbare bedrijfsontologieën voor AI-agenten

De term ‘ontologie’ is tegenwoordig in zwang. Waarom? Agenten en de LLM’s die hen aansturen, hebben relevante bedrijfscontext nodig.

Voordat je voor een ontologie kiest, vraag je de leverancier: ‘Hoe kunnen onze medewerkers fouten corrigeren wanneer de ontologie ons bedrijf verkeerd weergeeft, en wat blijft er dan nog van jou afhankelijk?’ Het antwoord vertelt je veel over wiens bedrijfsmodel je omarmt. Het wijst ook op wat er op het spel staat: je vermogen om dat model te verbeteren wanneer het bedrijf verandert, en die investering waardevol te houden als je van platform wisselt.

Het is nuttig om onderscheid te maken tussen een ontologie en een kennisgraaf, ook al overlappen die twee vaak.

Ontologie: welke soorten dingen bestaan, wat relaties betekenen en welke regels gelden. Apparatuur, onderdelen, teams, rollen, processen. Een ontologie kan bijvoorbeeld een type ‘Apparatuur’ en een relatie ‘Bevat’ met een ‘Onderdeel’ definiëren. Een kennisgraaf kan vervolgens de bewering bevatten: ‘Pomp P-101 bevat afdichting S-7’: twee specifieke entiteiten en hun onderlinge relatie.

Stel dat je een agent vraagt: ‘Bereken de omzetgroei in vergelijkbare winkels, maar geef me een vergelijking naast elkaar: eerst met alle winkels en daarna met uitsluiting van winkels die minder dan 2 jaar open zijn; splits vervolgens beide uitkomsten uit naar binnenland, buitenland en gecombineerd.’

Die vraag hangt af van details die een agent niet kan raden:

• welke winkels er zijn en wanneer ze zijn geopend
• waar ze zich bevinden
• de interne definitie van ‘omzet in vergelijkbare winkels’

Een beleid kan voorschrijven dat winkels pas meetellen als ze een jaar open zijn; de gevraagde groep van twee jaar voegt daar een extra filter aan toe. Maar vergelijk je dan kalendermaanden zodra een winkel aan de voorwaarden voldoet, of neem je die pas mee na een volledig voorafgaand boekjaar?

De ontologie moet die winkels koppelen aan het beleid dat de berekening bepaalt. Verwante feiten vinden helpt; de juiste regel toepassen maakt het antwoord bruikbaar.

Een agent kan relaties in de graaf gebruiken om relevante context op te halen voordat hij een vraag beantwoordt. En dat is niet voor niets nuttig: kennisdomeinen kunnen al snel zeer complex worden.

Figuur 1: Grafiek met gecombineerde openbare SysML-modellen: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), plus fictieve inhoud over de MDC-constellatie en openbare specificaties (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Weergegeven in Kamiwaza Kaizen.

Maar bij het extraheren kunnen ook fouten worden vastgelegd. Teams gebruiken mogelijk verschillende namen voor dezelfde entiteit, waardoor duplicaten ontstaan. Bronnen kunnen elkaar tegenspreken of verouderd raken. Zelfs een betrouwbare bron kan door een LLM verkeerd worden geïnterpreteerd. Zulke fouten een gezaghebbend aanzien geven, maakt ze niet minder gevaarlijk.

Die risico’s nemen toe wanneer een bedrijfsmodel verandert in een systeem dat op het bedrijf handelt. Een onjuiste relatie kan dan leiden tot een verkeerde actie, en niet alleen tot een verkeerd antwoord.

Risico’s van ontologieproducten

Wees allereerst op je hoede voor inflexibele modellen. Onder het mom van een ‘kant-en-klare oplossing’ kan een leverancier zijn eigen entiteiten voorrang geven en tegelijk de mogelijkheden van jouw entiteiten beperken. Aanpassingsmogelijkheden zijn niet voldoende als aangepaste typen geen zoek-, validatie- of actiemogelijkheden hebben.

Kijk ten tweede of er een route is van verkenning naar governance. Een tool moet je in staat stellen een graaf op te zetten op basis van wat een LLM waarneemt en die vervolgens aan expliciete beperkingen te toetsen. Je moet uitzonderingen kunnen voorleggen aan medewerkers en verkennende kennis kunnen bewaren zonder die als goedgekeurde bedrijfsgegevens te behandelen.

Het grootste risico is dat je bedrijfsprocessen koppelt aan een platform waar je niet van af kunt. Je ontologie vertegenwoordigt je bedrijf: de kennis, processen en relaties ervan. Die investering in het beheren van gegevens en bedrijfslogica moet waardevol blijven, zelfs als je van tool wisselt. Waarom zou een leverancier dat mogen vergrendelen?

Waar graafembeddings van pas komen

Wanneer kennisgrafen erg groot worden, kan het de moeite waard zijn een tool of leverancier te kiezen die graafembeddings ondersteunt. Die lijken sterk op de semantische embeddings waarop veel RAG-toepassingen draaien. Er zijn twee nuttige voordelen om in overweging te nemen.

Ten eerste kunnen een paar stappen door een dicht verbonden graaf al te veel entiteiten opleveren om te verwerken. Embeddings leren numerieke representaties van entiteiten en relaties en bieden zo een andere manier om relevante delen van de graaf te vinden. Voor de juiste taak kan dit efficiënter zijn dan de graaf stap voor stap te doorlopen.

Ten tweede kunnen embeddingmodellen mogelijke ontbrekende relaties rangschikken. Hetzelfde leerproces kan patronen aan het licht brengen in de kenmerken en relaties die typisch zijn voor een entiteitstype, en zo helpen een completere graaf op te bouwen.

Pleidooi voor stapsgewijze verbetering

Hoe begin je, zonder een heel leger aan engineers op locatie, aan het vormgeven van je eigen toekomst, het vermijden van leveranciersafhankelijkheid en het modelleren van je werkelijke bedrijf in plaats van een karikatuur die door een leverancier is voorgeschreven? Ik denk dat moderne AI hierbij uitblinkt, mits de tools een route bieden van verkenning naar verificatie.

Begin met geautomatiseerde ontdekking en extractie. Op basis van bedrijfsdocumenten, beleidsstukken, e-mail of Slack-berichten kun je een eerste beeld van een domein opbouwen. Het belangrijkste is dat je dit beeld niet als accuraat kunt beschouwen voordat het is geverifieerd.

Verificatie is de tweede stap. Je tools moeten een soepel traject bieden van geëxtraheerde kandidaat-gegevens naar beweringen die met bronnen zijn onderbouwd, en naar kennis die is gevalideerd door een verantwoordelijke persoon of een gezaghebbend systeem. Bewaar de bron van elke bewering.

Het actueel houden van kennis is doorlopend werk. De procedure voor het afhandelen van een storingsmelding, of het antwoord op de vraag ‘hoeveel vestigingen zijn er in New Jersey?’, is vandaag misschien anders dan drie jaar geleden. Maar door de kennis van vandaag bij te werken, mag de werkelijkheid van gisteren niet worden uitgewist. Het moment waarop een feit is vastgelegd, kan verschillen van de periode waarin het van toepassing was; een bruikbare ontologie moet zowel actuele antwoorden als een nauwkeurig historisch overzicht ondersteunen. Iemand moet die kennis nog steeds actueel houden.

De reikwijdte kan enorm zijn. Begin met een kleiner corpus, breng een bruikbaar domein in kaart en werk toe naar een volledig beeld, terwijl je onderweg waarde creëert.

Klantenondersteuning is een bruikbaar deelgebied: inkomende telefoontjes, e-mails, een ticketsysteem, geautomatiseerde oplossingen, een supportteam dat klanten kan helpen en een route om echte bugs naar het engineeringteam te escaleren. Zo wordt kennis gekoppeld aan actie en komen dezelfde risico’s en voordelen aan het licht binnen een beheersbaar domein.

Het Common Service Data Model van ServiceNow laat zien welke beperkingen dit met zich meebrengt. In de CSDM 5-whitepaper staat: ‘Zonder deze gegevens in de voorgeschreven tabellen ontvangt u mogelijk niet de volledige waarde van het ServiceNow AI Platform.’ Die waarschuwing legt op zichzelf al een ontwerp- en operationele beperking op: je moet je aanpassen aan het model van de leverancier of een risico accepteren. Wat als dat betekent dat je een ronde pen in hun vierkante gat moet duwen?

Stel nu dat een ontologieplatform ook gegevensinname, transformaties, acties en bedrijfsregels biedt. Misschien kun je entiteiten, attributen en relaties exporteren. Maar kun je ook transformaties en actieprocessen overzetten die wijzigingen in je databases uitvoeren, webhooks aanroepen en andere neveneffecten veroorzaken? Door sterk gekoppelde integraties kan ook het bedrijf zelf aan het platform gebonden raken.

Waarom flexibiliteit nu belangrijk is

Software verovert de wereld en AI verovert software. Naarmate teams AI zowel inzetten om software te bouwen als om die aan te drijven, kan steeds meer bedrijfslogica aan deze platforms gekoppeld raken. Elke nuttige automatisering kan ook weer een afhankelijkheid worden bij een migratie. Het is gevaarlijk om een leverancier tussen jou en je wendbaarheid te laten staan.

Conclusies

Wat een geweldige tijd om te leven! Geen wonder dat mensen ontologieën verkennen om agenten context te bieden. Door die context uit te breiden naar processen en integraties kan echte waarde ontstaan. Keer terug naar de vraag waarmee we begonnen. De correcties van je medewerkers moeten het model een betere afspiegeling van je bedrijf maken. Dat opgebouwde inzicht is te waardevol om achter te laten wanneer je van platform verandert. Tegelijkertijd is dit een bijzonder slechte tijd om jezelf klem te laten zetten.