Flyttbare forretningsontologier for KI-agenter

Begrepet «ontologi» er på moten for tiden. Hvorfor? Agenter og språkmodellene (LLM-ene) som driver dem, trenger relevant forretningskontekst.

Før du kjøper en ontologi, bør du spørre leverandøren: «Når ontologien tar feil om virksomheten vår, hvordan kan medarbeiderne våre rette på den – og hva er fortsatt avhengig av dere?» Svaret vil fortelle deg mye om hvem sin modell av virksomheten du kjøper deg inn i. Det viser også hva som står på spill i et større perspektiv: muligheten din til å forbedre modellen etter hvert som virksomheten endrer seg, og til å holde investeringen nyttig hvis du bytter plattform.

Det er nyttig å skille mellom en ontologi og en kunnskapsgraf, selv om de to ofte overlapper.

Ontologi: Hvilke typer ting som finnes, hva relasjoner betyr, og hvilke regler som gjelder. Utstyr, komponenter, team, roller, prosesser. En ontologi kan for eksempel definere typen «Utstyr» og relasjonen «Inneholder» til en «Komponent». En kunnskapsgraf kan deretter slå fast: «Pumpe P-101 inneholder tetning S-7» – to spesifikke entiteter og relasjonen mellom dem.

Tenk deg at du ber en agent: «Beregn veksten i sammenlignbart butikksalg, men vis en sammenligning side om side der vi først viser alle butikkene, og deretter en visning der vi utelater butikker som har vært åpne i mindre enn 2 år. Del så begge visningene inn i innenlandske, internasjonale og samlede tall.»

Denne forespørselen avhenger av detaljer en agent ikke kan gjette seg til:

• hvilke butikker som finnes, og når de åpnet
• hvor de ligger
• den interne definisjonen av «sammenlignbart butikksalg»

En policy kan utelukke butikker til de har vært åpne i ett år; den etterspurte gruppen med en toårsgrense legger til et ytterligere filter. Men også da gjenstår spørsmålet: Sammenligner du kalendermåneder så snart en butikk kvalifiserer, eller tar du den først med når den har et helt foregående regnskapsår bak seg?

Ontologien må knytte butikkene til policyen som styrer beregningen. Det hjelper å finne relaterte fakta, men det er bruken av riktig regel som gjør svaret nyttig.

En agent kan bruke relasjoner i grafen til å hente relevant kontekst før den svarer på et spørsmål. Det er ikke rart at dette er nyttig når kunnskapsområder lett kan bli svært komplekse.

Figur 1: Graf over kombinerte offentlige SysML-modeller: 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), samt fiktivt innhold om MDC-konstellasjonen og offentlige spesifikasjoner (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Gjengitt i Kamiwaza Kaizen.

Men uttrekk kan også bygge inn feil. Team kan bruke ulike navn på samme entitet og dermed skape duplikater. Kilder kan være uenige eller bli utdaterte. Selv en feilfri kilde kan bli feiltolket av en LLM. At slike feil framstår som autoritative, gjør dem ikke mindre farlige.

Risikoen øker når en modell av virksomheten blir til et system som handler på dens vegne. Da kan en feil relasjon utløse en feil handling, ikke bare et feil svar.

Risikoer ved ontologiprodukter

Vær først og fremst på vakt mot ufleksible modeller. For å tilby «alt inkludert» kan en leverandør gjøre sine egne entiteter til førsteklasses objekter, samtidig som den begrenser hva dine egne kan gjøre. Tilpasningsmuligheter er ikke nok hvis egendefinerte typer mister søke-, validerings- eller handlingsfunksjonalitet.

For det andre bør du se etter en vei fra oppdagelse til styring. Et verktøy bør gjøre det mulig å opprette en første versjon av en graf ut fra det en LLM ser, og deretter validere den mot uttrykkelige begrensninger. Du bør kunne løfte unntak til mennesker og bevare utforskende kunnskap uten å behandle den som godkjente forretningsdata.

Den største risikoen er å knytte forretningsprosesser til en plattform du ikke kan forlate. Ontologien representerer virksomheten din: kunnskapen, prosessene og relasjonene dens. Investeringen i kuratering og forretningslogikk bør fortsatt være nyttig selv om du bytter verktøy. Hvorfor skal en leverandør få legge dette under lås og slå?

Når grafinnbygginger er nyttige

Når kunnskapsgrafer vokser seg svært store, kan det være verdt å velge et verktøy eller en leverandør som støtter grafinnbygginger. Disse ligger tett opp til de semantiske vektorrepresentasjonene som driver mange RAG-applikasjoner. Det er verdt å vurdere to nyttige fordeler.

For det første kan noen få hopp gjennom en tett sammenkoblet graf gi for mange entiteter til at de kan behandles. Ved å lære numeriske representasjoner av entiteter og relasjoner gir innbygginger en annen måte å finne relevante deler av grafen på. For den rette oppgaven kan dette være mer effektivt enn å traversere grafen.

For det andre kan innbyggingsmodeller rangere mulige manglende relasjoner. Den samme læringen kan avdekke mønstre i attributtene og relasjonene som er typiske for en entitetstype, og dermed bidra til å bygge en mer komplett graf.

Argumentet for gradvis forbedring

Hvordan kommer du i gang uten en hel hær av ingeniører utplassert ute hos kunden, slik at du kan styre din egen utvikling, unngå leverandørlåsing og modellere den faktiske virksomheten din i stedet for en karikatur diktert av en leverandør? Her mener jeg moderne KI virkelig kommer til sin rett, hvis verktøyene støtter en vei fra oppdagelse til verifisering.

Begynn med automatisert oppdagelse og uthenting av informasjon. Fra forretningsdokumenter, retningslinjer, e-post eller Slack-meldinger kan du utarbeide et første bilde av et fagområde. Det avgjørende er at du ikke kan stole på at bildet er korrekt før det er verifisert.

Verifisering er det andre trinnet. Verktøyene dine må gjøre det enkelt å gå fra mulige opplysninger som er hentet ut, til påstander forankret i kilder og kunnskap som er validert av en ansvarlig person eller et autoritativt system. Behold kilden for hver påstand.

Å holde informasjonen oppdatert er et kontinuerlig arbeid. Måten en supportsak håndteres på, eller svaret på «hvor mange butikker er det i New Jersey», er kanskje ikke den samme i dag som for tre år siden. Men når dagens kunnskap oppdateres, må ikke gårsdagens virkelighet viskes ut. Tidspunktet da en opplysning ble registrert, kan være et annet enn tidspunktet den gjaldt; en nyttig ontologi må støtte både svar om nåtiden og et korrekt historisk bilde. Noen må fortsatt sørge for at kunnskapen holdes oppdatert.

Omfanget kan være enormt. Begynn med et mindre datakorpus, kartlegg et nyttig fagområde, og bygg gradvis opp et helhetlig bilde samtidig som du skaper verdi underveis.

Kundestøtte er et nyttig avgrenset område: innkommende samtaler, e-poster, et saksbehandlingssystem, automatisk løste saker, et kundestøtteteam som kan svare kundene, og en måte å eskalere reelle feil til utviklingsteamet på. Dette knytter kunnskap til handling og synliggjør de samme risikoene og gevinstene innenfor et håndterbart fagområde.

ServiceNows Common Service Data Model illustrerer begrensningen. I hvitboken om CSDM 5 advares det: «Uten disse dataene i de angitte tabellene får du kanskje ikke fullt utbytte av ServiceNow AI Platform.» Selve advarselen skaper en begrensning for utforming og drift: Du må enten satse på leverandørens modell eller akseptere en risiko. Hva om det betyr at du må presse en rund plugg inn i leverandørens firkantede hull?

Tenk deg nå at en ontologiplattform også tilbyr datainnhenting, transformasjoner, handlinger og forretningsregler. Det kan hende du kan eksportere entiteter, attributter og relasjoner. Men kan du også flytte transformasjoner og handlingsforløp som utfører endringer i databasene dine, kaller webhooks og skaper andre sideeffekter? Tett sammenkoblede integrasjoner kan føre til at selve virksomheten blir låst til plattformen.

Hvorfor fleksibilitet er viktig nå

Programvare sluker verden, og KI sluker programvare. Når team bruker KI både til å utvikle programvare og til å drive den, kan mer av forretningslogikken bli knyttet til disse plattformene. Hver nyttige automatisering kan også bli enda en avhengighet ved plattformbytte. Det er risikabelt å la en leverandør stå mellom deg og fleksibilitet.

Konklusjoner

For en fantastisk tid å leve i! Det er ikke rart at folk utforsker ontologier for å gi agenter kontekst. Å utvide denne konteksten til prosesser og integrasjoner kan skape reell verdi. La oss gå tilbake til spørsmålet innledningsvis. Korrigeringene fra medarbeiderne dine bør gjøre modellen til et bedre speilbilde av virksomheten. Denne opparbeidede forståelsen er for verdifull til å bli stående igjen når du bytter plattform. Det er også en elendig tid for å male seg inn i et hjørne.