Bærbare forretningsontologier til AI-agenter

Begrebet »ontologi« er blevet moderne. Hvorfor? Agenter og de LLM’er, der driver dem, har brug for relevant forretningskontekst.

Før du køber ind på en ontologi, så spørg leverandøren: »Når ontologien beskriver vores forretning forkert, hvordan kan vores medarbejdere så rette den – og hvad afhænger stadig af jer?« Svaret fortæller dig meget om, hvis forretningsmodel du køber ind på. Det peger også på de større spørgsmål: din mulighed for at forbedre modellen, efterhånden som forretningen ændrer sig, og for at holde investeringen nyttig, hvis du skifter platform.

Det er nyttigt at skelne mellem en ontologi og en vidensgraf, selvom de to ofte overlapper.

Ontologi: Hvilke slags ting findes, hvad relationer betyder, og hvilke regler der gælder. Udstyr, komponenter, teams, roller, processer. En ontologi kan for eksempel definere typen »Udstyr« og relationen »Indeholder« til en »Komponent«. En vidensgraf kan derefter fastslå: »Pumpe P-101 indeholder tætning S-7« – to specifikke entiteter og deres relation.

Forestil dig, at du siger til en agent: »Beregn væksten i sammenligneligt butikssalg, men vis mig en sammenligning side om side, hvor vi først viser alle butikker og derefter en anden, hvor vi udelader butikker, der har været åbne i mindre end 2 år; opdel derefter begge sider i indenlandske, internationale og samlede tal.«

Den anmodning afhænger af detaljer, som en agent ikke kan gætte sig til:

• hvilke butikker der findes, og hvornår de åbnede
• hvor de ligger
• den interne definition af »sammenligneligt butikssalg«

En politik kan udelukke butikker, indtil de har været åbne i et år; gruppen med den ønskede grænse på to år tilføjer endnu et filter. Men også da er spørgsmålet, om man sammenligner kalendermåneder, så snart en butik opfylder kriteriet, eller først medregner den efter et helt forudgående regnskabsår.

Ontologien skal forbinde butikkerne med den politik, der styrer beregningen. Det hjælper at finde relaterede oplysninger, men det er anvendelsen af den rigtige regel, der gør svaret nyttigt.

En agent kan bruge relationer i grafen til at hente relevant kontekst, før den besvarer et spørgsmål. Det er ikke så mærkeligt, at de er nyttige, når vidensområder let kan blive meget komplekse.

Figur 1: Graf: kombinerede 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 indhold om den fiktive MDC-konstellation og offentlige specifikationer (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Gengivet i Kamiwaza Kaizen.

Men udtræk kan også indkode fejl. Teams bruger måske forskellige navne for den samme entitet, hvilket skaber dubletter. Kilder kan være uenige eller forældede. Selv en korrekt kilde kan blive fejlfortolket af en LLM. At få sådanne fejl til at se autoritative ud gør dem ikke mindre farlige.

Risiciene vokser, når en model af forretningen bliver til et system, der handler på dens vegne. Så kan en forkert relation udløse en forkert handling, ikke bare føre til et forkert svar.

Risici ved ontologiprodukter

Vær først og fremmest på vagt over for ufleksible modeller. I forsøget på at levere en løsning med »alt inkluderet« kan en leverandør gøre sine egne entiteter til førsteklasses elementer, samtidig med at den begrænser, hvad dine kan gøre. Tilpasning er ikke nok, hvis tilpassede typer mister muligheder for søgning, validering eller handling.

For det andet bør du se efter en vej fra opdagelse til styring. Et værktøj bør gøre det muligt at opbygge en graf på grundlag af det, en LLM ser, og derefter validere den i forhold til eksplicitte begrænsninger. Du bør kunne sende undtagelser videre til medarbejdere og bevare udforskende viden uden at behandle den som godkendte forretningsdata.

Den største risiko er at knytte forretningsprocesser til en platform, du ikke kan forlade. Din ontologi repræsenterer din forretning: dens viden, processer og relationer. Investeringen i kuratering og forretningslogik bør fortsat være nyttig, selv hvis du skifter værktøjer. Hvorfor skulle en leverandør kunne låse det inde?

Hvor grafindlejringer gør nytte

Når vidensgrafer bliver meget store, kan det være værd at vælge et værktøj eller en leverandør, der understøtter grafindlejringer. De minder meget om de semantiske indlejringer, der driver mange RAG-applikationer. Der er to nyttige fordele, man bør overveje.

For det første kan nogle få spring gennem en tæt forbundet graf føre til flere entiteter, end man kan behandle. Ved at lære numeriske repræsentationer af entiteter og relationer giver indlejringer en anden måde at finde relevante dele af grafen på. Til den rette opgave kan det være mere effektivt end at gennemgå grafen.

For det andet kan indlejringsmodeller rangordne mulige manglende relationer. Den samme indlæring kan afdække mønstre i de attributter og relationer, der er typiske for en entitetstype, og dermed bidrage til at opbygge en mere komplet graf.

Argumentet for løbende forbedringer

Hvordan kan du tage styringen over din egen fremtid, undgå leverandørlåsning og modellere din faktiske forretning i stedet for en karikatur dikteret af en leverandør – uden at begynde med en hel hær af ingeniører placeret hos kunden? Det er her, jeg mener, at moderne AI udmærker sig, hvis værktøjerne understøtter en vej fra opdagelse til verifikation.

Begynd med automatiseret kortlægning og udtræk. Ud fra forretningsdokumenter, politikker, e-mails eller Slack-beskeder kan du opbygge et første overblik over et fagområde. Det afgørende er, at du ikke kan stole på, at det er korrekt, før det er blevet verificeret.

Verificering er det næste trin. Dine værktøjer skal give dig en smidig vej fra udtrukne kandidater til påstande, der er underbygget af kilder, og videre til viden, som er valideret af en ansvarlig person eller et autoritativt system. Bevar kilden til hver påstand.

Det kræver løbende arbejde at holde oplysningerne ajour. Processen for håndtering af en supportsag eller svaret på spørgsmålet »Hvor mange butikker er der i New Jersey?« er måske ikke den samme i dag, som den var for tre år siden. Men når dagens viden opdateres, må gårsdagens virkelighed ikke blive slettet. Hvornår en kendsgerning blev registreret, og hvornår den var gældende, kan være forskelligt; en nyttig ontologi skal kunne understøtte både aktuelle svar og et præcist historisk overblik. Nogen skal stadig sørge for, at den viden holdes ajour.

Omfanget kan være enormt. Begynd med et mindre tekstkorpus, kortlæg et nyttigt fagområde, og arbejd dig frem mod et samlet overblik, samtidig med at du skaber værdi undervejs.

Kundesupport er et nyttigt delområde: indgående opkald, e-mails, et sagsstyringssystem, automatiserede løsninger, et supportteam, der kan svare kunderne, og en proces til at eskalere egentlige fejl til udviklingsteamet. Det forbinder viden med handling og synliggør de samme risici og gevinster inden for et overskueligt fagområde.

ServiceNow’s Common Service Data Model illustrerer begrænsningen. I sin hvidbog om CSDM 5 advarer ServiceNow: »Uden disse data i de foreskrevne tabeller får du muligvis ikke det fulde udbytte af ServiceNow AI Platform.« Advarslen skaber i sig selv en designmæssig og operationel begrænsning: Enten tilpasser man sig leverandørens model, eller også accepterer man en risiko. Hvad nu, hvis det betyder, at du skal presse en rund pind ind i deres firkantede hul?

Forestil dig nu, at en ontologiplatform også tilbyder dataindlæsning, transformationer, handlinger og forretningsregler. Du kan måske eksportere entiteter, attributter og relationer. Men kan du også flytte transformationer og handlingsforløb, der udfører ændringer i dine databaser, kalder webhooks og skaber andre følgevirkninger? Tæt sammenkoblede integrationer kan ende med at fastlåse selve virksomheden.

Hvorfor fleksibilitet er vigtig nu

Software er ved at opsluge verden, og AI er ved at opsluge software. Når teams bruger AI både til at udvikle software og til at drive den, kan mere af forretningslogikken blive knyttet til disse platforme. Hver nyttig automatisering kan også blive endnu en afhængighed ved en fremtidig migrering. Det er risikabelt at lade en leverandør stå mellem dig og fleksibilitet.

Konklusion

Det er en fantastisk tid at være i live! Det er ikke så mærkeligt, at folk undersøger, hvordan ontologier kan give agenter kontekst. Hvis denne kontekst også omfatter processer og integrationer, kan det skabe reel værdi. Lad os vende tilbage til det indledende spørgsmål. Dine medarbejderes rettelser bør gøre modellen til et mere præcist billede af din virksomhed. Den samlede forståelse er alt for værdifuld til at gå tabt, når du skifter platform. Det er også et virkelig dårligt tidspunkt at blive malet op i et hjørne.