Portabla verksamhetsontologier för AI-agenter

Begreppet ”ontologi” är på modet. Varför? Agenterna och de LLM:er som driver dem behöver relevant verksamhetskontext.

Innan du väljer en ontologi bör du fråga leverantören: ”Om ontologin beskriver vår verksamhet fel, hur kan våra medarbetare rätta till det – och vad är fortfarande beroende av er?” Svaret säger mycket om vems verksamhetsmodell du köper in dig på. Det visar också vad som står på spel i ett större perspektiv: din förmåga att förbättra modellen när verksamheten förändras och att fortsätta ha nytta av investeringen om du byter plattform.

Det är bra att skilja mellan en ontologi och en kunskapsgraf, även om de två ofta överlappar.

Ontologi: Vilka slags företeelser som finns, vad relationer betyder och vilka regler som gäller. Utrustning, komponenter, team, roller, processer. En ontologi kan till exempel definiera typen ”Utrustning” och relationen ”Innehåller” till en ”Komponent”. En kunskapsgraf kan sedan ange: ”Pump P-101 innehåller tätning S-7” – två specifika entiteter och relationen mellan dem.

Föreställ dig att du säger till en agent: ”Beräkna tillväxten i jämförbar butiksförsäljning, men visa en jämförelse sida vid sida: först med alla butiker och sedan en där vi exkluderar butiker som har varit öppna i mindre än 2 år. Dela sedan upp båda sidorna i inhemska, internationella och sammanlagda siffror.”

Den begäran bygger på detaljer som en agent inte kan gissa sig till:

• vilka butiker som finns och när de öppnade
• var de ligger
• den interna definitionen av ”jämförbar butiksförsäljning”

En policy kan innebära att butiker exkluderas tills de har varit öppna i ett år; den begärda tvåårsgruppen lägger till ytterligare ett filter. Men även då: jämför man kalendermånader så snart en butik uppfyller villkoret, eller tar man med den först efter ett helt föregående räkenskapsår?

Ontologin måste koppla butikerna till den policy som styr beräkningen. Det hjälper att hitta relaterade fakta, men det är tillämpningen av rätt regel som gör svaret användbart.

En agent kan använda relationer i grafen för att hämta relevant kontext innan den besvarar en fråga. Det är inte konstigt att agenter är användbara när kunskapsområden lätt kan bli mycket komplexa.

Figur 1: Graf: kombinerade offentliga 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 innehåll om MDC-konstellationen och offentliga specifikationer (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Renderad i Kamiwaza Kaizen.

Men extraheringen kan också föra in fel. Team kan använda olika namn för samma entitet, vilket skapar dubbletter. Källor kan motsäga varandra eller bli inaktuella. Även en felfri källa kan misstolkas av en LLM. Att få sådana misstag att framstå som auktoritativa gör dem inte mindre farliga.

Riskerna ökar när en verksamhetsmodell blir ett system som agerar utifrån den. Då kan en felaktig relation utlösa en felaktig åtgärd, inte bara leda till ett felaktigt svar.

Risker med ontologiprodukter

Var först försiktig med oflexibla modeller. För att kunna hävda att ”allt ingår” kan en leverantör göra sina egna entiteter till förstaklassobjekt och samtidigt begränsa vad dina entiteter kan göra. Anpassningsmöjligheter räcker inte om anpassade typer saknar sök-, validerings- eller åtgärdsfunktioner.

För det andra bör du leta efter en väg från upptäckt till styrning. Ett verktyg bör låta dig skapa en första version av en graf utifrån det en LLM uppfattar och sedan validera den mot uttryckliga begränsningar. Du bör kunna föra undantag vidare till människor och bevara utforskande kunskap utan att behandla den som godkända verksamhetsdata.

Den största risken är att knyta verksamhetsprocesser till en plattform som du inte kan lämna. Din ontologi representerar din verksamhet: dess kunskap, processer och relationer. Investeringen i kvalitetssäkring och verksamhetslogik bör fortsätta vara värdefull även om du byter verktyg. Varför skulle en leverantör få låsa in allt detta?

När grafembeddingar kan vara till hjälp

När kunskapsgrafer växer sig mycket stora kan det vara värt att välja ett verktyg eller en leverantör som har stöd för grafembeddingar. De är nära besläktade med de semantiska embeddingar som driver många RAG-tillämpningar. Det finns två användbara fördelar att ta hänsyn till.

För det första kan några få steg genom en tätt sammankopplad graf ge fler entiteter än vad som går att bearbeta. Genom att lära sig numeriska representationer av entiteter och relationer erbjuder embeddingar ett annat sätt att hitta relevanta delar av grafen. För rätt uppgift kan det vara effektivare än att gå igenom grafen.

För det andra kan embeddingmodeller rangordna möjliga saknade relationer. Samma inlärning kan blottlägga mönster i attributen och relationerna som är typiska för en entitetstyp, vilket bidrar till att bygga en mer fullständig graf.

Argument för stegvis förbättring

Hur kan du styra över din egen framtid, undvika inlåsning och modellera din faktiska verksamhet i stället för en leverantörsstyrd karikatyr av den – utan en armé av ingenjörer på plats hos kunderna? Det är här jag tycker att modern AI kommer till sin rätt, om verktygen erbjuder en väg från upptäckt till verifiering.

Börja med automatiserad upptäckt och extrahering. Med hjälp av affärsdokument, policyer, e-post eller Slack-meddelanden kan du skapa en första bild av ett verksamhetsområde. Det avgörande är att du inte kan lita på att den stämmer förrän den har verifierats.

Verifiering är nästa steg. Verktygen måste erbjuda en smidig väg från extraherade kandidater till påståenden som stöds av källor och till kunskap som har validerats av en ansvarig person eller ett auktoritativt system. Bevara källan för varje påstående.

Att hålla informationen aktuell är ett löpande arbete. Rutinerna för att hantera ett supportärende, eller svaret på frågan ”hur många butiker finns det i New Jersey?”, kanske inte ser likadana ut i dag som för tre år sedan. Men när dagens kunskap uppdateras får gårdagens verklighet inte raderas. Det kan skilja sig åt när ett faktum registrerades och när det gällde; en användbar ontologi måste kunna ge både aktuella svar och en korrekt historisk bild. Någon måste fortfarande se till att kunskapen hålls aktuell.

Omfattningen kan vara enorm. Börja med ett mindre textunderlag, kartlägg ett användbart område och bygg vidare mot en heltäckande bild samtidigt som du skapar värde längs vägen.

Kundsupport är ett användbart avgränsat område: inkommande samtal, e-post, ett ärendehanteringssystem, automatiserade lösningar, ett supportteam som kan svara kunderna och en möjlighet att eskalera verkliga buggar till utvecklingsteamet. Området kopplar samman kunskap och handling och visar på samma risker och möjligheter i en hanterbar skala.

ServiceNows Common Service Data Model illustrerar begränsningen. I vitboken om CSDM 5 står det: ”Utan dessa data i de föreskrivna tabellerna kanske du inte får ut det fulla värdet av ServiceNow AI Platform.” Varningen skapar i sig en begränsning för utformning och drift: anpassa dig till leverantörens modell eller acceptera en risk. Tänk om det innebär att försöka trycka in en rund kloss i ett fyrkantigt hål?

Anta nu att en ontologiplattform även tillhandahåller inläsning, transformationer, åtgärder och affärsregler. Du kanske kan exportera entiteter, attribut och relationer. Men kan du också flytta över transformationer och åtgärdskedjor som genomför ändringar i dina databaser, anropar webhooks och skapar andra sidoeffekter? Tätt sammankopplade integrationer kan göra att själva verksamheten blir inlåst.

Varför flexibilitet är viktig nu

Programvara äter världen, och AI äter programvara. När team använder AI både för att utveckla programvara och för att driva den kan mer av affärslogiken knytas till dessa plattformar. Varje användbar automatisering kan också bli ytterligare ett beroende vid en migrering. Det är riskabelt att låta en leverantör stå mellan dig och din förmåga att agera snabbt.

Slutsatser

Det är en fantastisk tid att leva i! Det är inte konstigt att människor utforskar ontologier för att ge agenter sammanhang. Att utvidga sammanhanget till processer och integrationer kan skapa verkligt värde. Återvänd till den inledande frågan. Medarbetarnas korrigeringar bör göra modellen till en bättre återspegling av verksamheten. Den samlade förståelsen är alltför värdefull för att bli kvar på en plattform när ni byter. Samtidigt är det en usel tid att måla in sig i ett hörn.