Tragbare Geschäftsontologien für KI-Agenten

Der Begriff „Ontologie“ ist derzeit in aller Munde. Warum? Agenten und die LLMs, die sie antreiben, benötigen relevanten Geschäftskontext.

Bevor Sie sich für eine Ontologie entscheiden, fragen Sie den Anbieter: „Wie können unsere Mitarbeitenden Fehler korrigieren, wenn die Ontologie unser Unternehmen falsch abbildet – und wovon sind wir weiterhin von Ihnen abhängig?“ Die Antwort verrät Ihnen viel darüber, welches Geschäftsmodell Sie mit dem Kauf übernehmen. Sie verweist zugleich auf die größeren Herausforderungen: Ihre Fähigkeit, dieses Modell weiterzuentwickeln, wenn sich das Unternehmen verändert, und sicherzustellen, dass sich diese Investition auch dann noch lohnt, wenn Sie die Plattform wechseln.

Es ist hilfreich, zwischen einer Ontologie und einem Wissensgraphen zu unterscheiden, auch wenn sich beide häufig überschneiden.

Ontologie: Welche Arten von Dingen existieren, was Beziehungen bedeuten und welche Regeln gelten. Ausrüstung, Komponenten, Teams, Rollen, Prozesse. Eine Ontologie kann beispielsweise einen Typ „Ausrüstung“ und eine Beziehung „Enthält“ zu einer „Komponente“ definieren. Ein Wissensgraph kann dann festhalten: „Pumpe P-101 enthält Dichtung S-7“ – zwei konkrete Entitäten und ihre Beziehung.

Stellen Sie sich vor, Sie sagen zu einem Agenten: „Berechne das Same-Store-Umsatzwachstum, aber stelle die Ergebnisse nebeneinander dar: einmal für alle Filialen und dann noch einmal unter Ausschluss der Filialen, die seit weniger als 2 Jahren geöffnet sind. Unterteile anschließend beide Darstellungen in die Kategorien Inland, Ausland und Gesamt.“

Diese Anfrage hängt von Details ab, die ein Agent nicht erraten kann:

• welche Filialen es gibt und wann sie eröffnet wurden
• wo sie sich befinden
• die interne Definition von „Same-Store-Umsatz“

Eine Richtlinie könnte Geschäfte ausschließen, bis sie seit einem Jahr geöffnet sind; für die angefragte Zweijahresgruppe gilt ein zusätzlicher Filter. Vergleicht man dann bereits die Kalendermonate, sobald ein Geschäft die Kriterien erfüllt, oder wird es erst nach einem vollständigen vorherigen Geschäftsjahr berücksichtigt?

Die Ontologie muss diese Filialen mit der Richtlinie verknüpfen, die der Berechnung zugrunde liegt. Verwandte Fakten zu finden ist hilfreich; erst die richtige Regel anzuwenden, macht die Antwort nützlich.

Ein Agent kann Beziehungen im Graphen nutzen, um relevanten Kontext abzurufen, bevor er eine Frage beantwortet. Kein Wunder, dass sie nützlich sind, denn Wissensdomänen können schnell sehr komplex werden.

Abbildung 1: Graph: kombinierte öffentliche SysML-Modelle: 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), dazu fiktive Inhalte zur MDC-Konstellation und öffentliche Spezifikationen (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Gerendert in Kamiwaza Kaizen.

Bei der Extraktion können jedoch auch Fehler entstehen. Teams verwenden möglicherweise verschiedene Bezeichnungen für dieselbe Entität, wodurch Duplikate entstehen. Quellen können sich widersprechen oder veralten. Selbst eine einwandfreie Quelle kann von einem LLM falsch interpretiert werden. Solche Fehler maßgeblich erscheinen zu lassen, macht sie nicht weniger gefährlich.

Diese Risiken nehmen zu, wenn ein Geschäftsmodell zu einem System wird, das im Unternehmen handelt. Eine falsche Beziehung kann dann eine falsche Handlung auslösen und nicht nur zu einer falschen Antwort führen.

Risiken von Ontologieprodukten

Seien Sie zunächst vorsichtig bei unflexiblen Modellen. Unter dem Vorwand, ein Komplettpaket anzubieten, kann ein Anbieter seine eigenen Entitäten zu erstklassigen Elementen machen und zugleich die Möglichkeiten Ihrer Entitäten einschränken. Anpassbarkeit allein reicht nicht aus, wenn benutzerdefinierte Typen dadurch Such-, Validierungs- oder Aktionsfunktionen verlieren.

Suchen Sie zweitens nach einem Weg von der Erkundung bis zur Governance. Ein Tool sollte es ermöglichen, ausgehend von dem, was ein LLM erkennt, zunächst einen Graphen aufzubauen und ihn anschließend anhand expliziter Einschränkungen zu validieren. Sie sollten Ausnahmen an Mitarbeitende eskalieren und exploratives Wissen bewahren können, ohne es als genehmigte Geschäftsdaten zu behandeln.

Das größte Risiko besteht darin, Geschäftsprozesse an eine Plattform zu binden, die Sie nicht verlassen können. Ihre Ontologie bildet Ihr Unternehmen ab: sein Wissen, seine Prozesse und seine Beziehungen. Die Investition in die Pflege der Ontologie und die Geschäftslogik sollte auch dann noch nützlich sein, wenn Sie die Tools wechseln. Warum sollte ein Anbieter das unter Verschluss halten dürfen?

Wann Graph-Embeddings helfen

Wenn Wissensgraphen sehr groß werden, kann es sich lohnen, ein Tool oder einen Anbieter zu wählen, der Graph-Embeddings unterstützt. Sie sind eng mit den semantischen Embeddings verwandt, auf denen viele RAG-Anwendungen basieren. Dabei sind zwei Vorteile besonders relevant.

Erstens kann man über wenige Schritte in einem dicht vernetzten Graphen auf zu viele Entitäten stoßen, um sie verarbeiten zu können. Embeddings lernen numerische Repräsentationen von Entitäten und Beziehungen und bieten damit eine weitere Möglichkeit, relevante Teile des Graphen zu finden. Für die passende Aufgabe kann das effizienter sein, als den Graphen zu durchlaufen.

Zweitens können Einbettungsmodelle mögliche fehlende Beziehungen bewerten. Derselbe Lernprozess kann typische Muster in den Attributen und Beziehungen eines Entitätstyps aufdecken und so dabei helfen, einen vollständigeren Graphen aufzubauen.

Warum sich schrittweise Verbesserungen lohnen

Wie können Sie Ihr Schicksal selbst in die Hand nehmen, eine Abhängigkeit vermeiden und Ihr tatsächliches Unternehmen statt einer vom Anbieter vorgegebenen Karikatur davon modellieren – und das ohne eine ganze Armee von Ingenieuren, die direkt beim Kunden eingesetzt werden? Hier kann moderne KI meiner Meinung nach ihre Stärken ausspielen, sofern die Tools einen Weg von der Erkundung bis zur Verifizierung ermöglichen.

Nutzen Sie zunächst automatisierte Erkennung und Extraktion. Aus Geschäftsdokumenten, Richtlinien, E-Mails oder Slack-Nachrichten können Sie eine erste Übersicht über einen Fachbereich erstellen. Entscheidend ist, dass Sie dieser Übersicht erst dann vertrauen können, wenn sie überprüft wurde.

Die Überprüfung ist der zweite Schritt. Ihre Tools müssen einen reibungslosen Weg von extrahierten Kandidaten zu durch Quellen belegten Aussagen und zu Wissen bieten, das von einer verantwortlichen Person oder einem maßgeblichen System validiert wurde. Bewahren Sie die Quelle jeder Aussage auf.

Die Aktualität zu gewährleisten, ist eine fortlaufende Aufgabe. Wie ein Support-Ticket bearbeitet wird oder wie die Antwort auf die Frage „Wie viele Filialen gibt es in New Jersey?“ lautet, kann sich im Laufe von drei Jahren ändern. Doch wenn Sie den heutigen Wissensstand aktualisieren, darf die Realität von gestern nicht verloren gehen. Wann ein Fakt erfasst wurde und für welchen Zeitraum er galt, kann voneinander abweichen; eine nützliche Ontologie muss sowohl aktuelle Antworten als auch einen korrekten historischen Überblick ermöglichen. Dieses Wissen muss weiterhin von jemandem aktuell gehalten werden.

Der Umfang kann enorm sein. Beginnen Sie mit einem kleineren Datenbestand, bilden Sie einen nützlichen Fachbereich ab und arbeiten Sie auf ein umfassendes Gesamtbild hin, während Sie nach und nach Mehrwert schaffen.

Der Kundensupport ist ein geeigneter Teilbereich: eingehende Anrufe und E-Mails, ein Ticketsystem, automatisierte Lösungen, ein Support-Team, das Kunden antworten kann, sowie die Möglichkeit, tatsächliche Fehler an die Entwicklungsabteilung weiterzuleiten. So wird Wissen mit konkretem Handeln verknüpft, und dieselben Risiken und Vorteile werden in einem überschaubaren Bereich sichtbar.

Das Common Service Data Model von ServiceNow veranschaulicht die Einschränkung. Im CSDM-5-Whitepaper heißt es: „Ohne diese Daten in den vorgeschriebenen Tabellen erhalten Sie möglicherweise nicht den vollen Mehrwert der ServiceNow AI Platform.“ Diese Warnung schafft selbst eine gestalterische und betriebliche Einschränkung: Entweder richten Sie sich nach dem Modell des Anbieters oder Sie nehmen ein Risiko in Kauf. Was, wenn Sie dafür Ihren runden Pflock in dessen eckiges Loch zwängen müssen?

Nehmen wir nun an, eine Ontologieplattform stellt auch Funktionen für Datenaufnahme, Transformationen, Aktionen und Geschäftsregeln bereit. Möglicherweise können Sie Entitäten, Attribute und Beziehungen exportieren. Aber lassen sich auch Transformationen und Aktionsabläufe übertragen, die Änderungen an Ihren Datenbanken ausführen, Webhooks aufrufen und andere Nebenwirkungen auslösen? Eng gekoppelte Integrationen können dazu führen, dass Ihr Unternehmen selbst an die Plattform gebunden bleibt.

Warum Flexibilität gerade jetzt wichtig ist

Software erobert die Welt, und KI erobert die Software. Wenn Teams KI sowohl zur Entwicklung als auch zum Betrieb von Software einsetzen, kann immer mehr Geschäftslogik an diese Plattformen gebunden werden. Jede nützliche Automatisierung kann zugleich eine weitere Abhängigkeit bei einem Plattformwechsel schaffen. Es ist gefährlich, wenn ein Anbieter zwischen Ihnen und Ihrer Agilität steht.

Schlussfolgerungen

Es ist eine großartige Zeit, um am Leben zu sein! Kein Wunder, dass sich viele mit Ontologien befassen, um Agenten Kontext bereitzustellen. Diesen Kontext auf Prozesse und Integrationen auszuweiten, kann echten Mehrwert schaffen. Kehren wir zu der Eingangsfrage zurück. Die Korrekturen Ihrer Mitarbeitenden sollten das Modell zu einem besseren Abbild Ihres Unternehmens machen. Dieses über die Zeit gewachsene Verständnis ist zu wertvoll, um bei einem Plattformwechsel zurückgelassen zu werden. Zugleich ist es eine denkbar schlechte Zeit, sich in eine Sackgasse manövrieren zu lassen.