OKF – eine kurze Übersicht

Am 12.06. dieses Jahres hat Google das Open Knowledge Format auf den Markt gebracht. OKF hat die Sicht des Marktes auf Wissen und GenAI komplett umgekrempelt und viele  begeisterte Reaktionen mit sich gebracht. Kurz gesagt ist OKF ein Format, das Wissen bzw. Dokumente strukturiert. Die Einheit des Wissens ist dabei ein Dokument, das mit seinen Beziehungen zu anderen Dokumenten dargestellt wird. Mehrere Dokumente, die zusammengehören werden als „bundle“ bezeichnet und können so auch ausgeliefert werden. Eine detaillierte Beschreibung des OKF Formats findet man unter https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing?hl=en

Die fachliche Herausforderung

Direkt nach dem Erscheinen schien uns OKF sofort ein spannendes Format zu sein. Die Grundidee von Google sahen wir als Türöffner zu einer neu AI Welt, da die Strukturierung von Wissen ein Aspekt ist, der uns in der Vergangenheit sehr deutlich gefehlt hat. Und da wir mit unserem AI Assistent zu unserer eigenen Software schon erste Erfahrungen gemacht hatten, wollten wir das auf neue Beine stellen und erste Erfahrungen mit OKF sammeln.

Der Service Assistant unterstützt unsere eigenen Servicekräfte durch eine AI basierte Suche in unseren Produktdokumenten. Diese umfassen rund 500 Seiten an pdf Dokumenten, die die wesentlichen Funktionen des Produktes beschreiben und die eigentlich ein Servicemitarbeiter im Kopf haben sollte. Was natürlich ganz schön schwierig ist.

Und noch eine Anmerkung zur Klarstellung: Es handelt sich NICHT um eine FAQ Datenbank, in der typische Fragen und Antworten, Probleme und Lösungen dokumentiert sind. Vielmehr handelt es sich einfach um die Produktdokumentation. Möchte man hier also Lösungen finden, dann geht es nicht einfach um das Finden relevanter und passender Texte, sondern das LLM muss die Lösung durch Schlussfolgern finden.

Mit dem aktuellen Service Assistant hatten wir schon recht gute Erfahrungen gemacht. Der Pflegeaufwand ist natürlich signifikant geringer als bei einer FAQ Datenbank, da man die Produktdokumentation sowieso haben muss. Allerdings bestanden schon auch einige Schwächen.

• Eine symptombasierte Suche, die einfach nur ein Problem beschreibt, findet oft keine passende Lösung, da das System diesen Zusammenhang nicht wissen kann.
• Die Dokumente sind in einer produktabhängigen Fachterminologie geschrieben. Verwendet der Anwender diese Fachterminis nicht, dann fällt es dem System recht schwer, die passenden Abschnitte und Lösungen zu finden.
• Die Dokumente sind teilweise sehr lange und verwenden des Designs wegen komplexe Formatierungen. Diese führen zuweilen dazu, dass aus Sicht der KI Abschnitte auf einmal beendet werden, obwohl sie inhaltlich noch fortgeführt werden. Steht beispielswiese eine „Überschrift“ einfach nur als „fetter Text“ an der falschen Stelle, interpretiert die AI das als Abschnittsende und ordnet die folgenden Texte einem anderen Thema zu.

Wie alle Software gibt es innerhalb der Module und Bausteine unserer Software „Ist Teil von“ oder „Umfasst“ Beziehungen oder auch „ist genereller“, „ist Spezialisierung von“ Beziehungen. Wenn die KI und der Anwender diese Beziehungen in der Problemsuche nicht berücksichtigen, können die passenden Lösungen auch nicht generiert werden.

Das Konzept

Da wir in der bisherigen Nutzung die Erfahrung gemacht haben, dass gerade das fehlende Begriffs- und Beziehungswissen für Probleme gesorgt hat, sahen wir in OKF einen hervorragenden Ansatz, um das Problem besser in den Griff zu bekommen.

Damit hatten wir auch die Möglichkeit, auf einen agentenbasierten Suchprozess zu wechseln. Eine rein semantische Suche oder auch eine Hybridsuche konnten zum Beispiel Symptom-/Baustein-/Lösungs-Beziehungen nicht auflösen. Ebenso wären sie nicht in der Lage, gezielt zum Beispiel Known Issues mit in die Suche aufzunehmen. Beispielsweise sucht der Anwender nach einem Problem in einer Funktion, die durch einen speziellen Baustein der Software zuständig ist. Und für diesen Baustein gibt es einen Known Issue. Hier ist der Verweis durch die OKF Struktur auf die entsprechenden Konzepte (Hier im Beispiel Known Issues) schlicht Gold wert. Allerdings mussten wir auch feststellen, dass der OKF Ansatz nur auf „Konzept-Ebene“ greift. Dabei ist ein Konzept ein Dokument. Die Begrifflichkeiten und die semantischen Beziehungen dieser Begriffe sind damit nicht abgedeckt.

Das führt dazu, dass wir neben der OKF Struktur als in die OKF Struktur integriertes Dokument eine als .md file erstellte Ontologie mit in den Wissensbestand integrieren.

Diese Ontologie kennt Beziehungen zwischen den Bausteinen der Software (ist allgemeiner / spezieller, ist Teil von / umfasst und die funktionale Beschreibung).

Im alltäglichen Betrieb hatten wir auch gemerkt, dass ein Service Assistent, der sich nur auf das spezielle Wissen rund um unsere Software kümmert in der Praxis nicht so hilfreich ist. Tatsächlich sind ja viele auftretende Fehler eher ganz allgemeiner Natur. So setzen wir einen im Markt verfügbaren HTML Editor in unserer Software ein. Natürlich treten im Service Center auch Fragen und Probleme zu diesem Softwarebestandteil auf. Um diese Fragen zu beantworten, benötigt man aber kein USU Wissen, sondern allgemeines IT Wissen. Dennoch wird dieses Wissen natürlich von den Kollegen und Kolleginnen im Support erwartet. Daher ergänzten wir die vom System verwendeten Daten um eine Beschreibung der verwendeten Architektur wie die Tatsache, dass es sich um eine browserbasierte Software handelt und der genutzten Basissysteme wie beispielsweise Java Script, die Datenbank oder auch den Editor. Dieses zusätzliche Wissen erlaubt es der Anwendung, auch Probleme mit der technischen Basis bearbeiten zu können.

Als weiteren Aspekt erkannten wir in der testweisen Nutzung, dass die monatlich für die Software verfügbaren Fixes eine wesentliche Wissensquelle sind. Betreffen Kundenmeldungen schon bekannte Fehler ist es wichtig, diese einfach und rasch mit bestehenden Abhilfemaßnahmen bearbeiten zu können.

Um auch auf dieses Wissen zugreifen zu können sollten die Known Issues ebenfalls in die Wissensbasis aufgenommen werden.

Die Vorgehensweise

Aufsplitten in Einzeldokumente mithilfe einer Funktionsliste

Wie schon beschrieben: Die Basisdokumente sind recht umfangreich und unterschiedlich groß. Entsprechend bestand die Anforderung zuerst darin, die Dokumente in hinreichend homogene, kleinere und fragebezogene Einheiten aufzusplitten.

Dazu wurde mithilfe von AI (Claude Cowork) der gesamte Dokumentenbestand auf „Funktionsbeschreibungen“ untersucht. Die dabei entstehende „Funktionsliste“ wurde manuell kontrolliert und optimiert.

Mithilfe dieser Funktionsliste wurde dann der Dokumentenbestand in entsprechende Einzelabschnitte zu jeder Funktion umgebaut. Dabei wurden mehrere Funktionen in ein Dokument zusammengefasst, so dass sich folgendes Bild in der Übersicht ergab.

Da die Basisdokumente im Format pdf vorlagen und der Dokumentenbestand ja sowieso umgearbeitet werden musste, wurde das Format noch in ein einfacher zu lesendes markdown umgewandelt.

Die agentische Suche wurde einfach so umgesetzt, dass der Content in einem Claude Project hinterlegt wurde. Damit ist eine agentische Suche einfach realisierbar. Der Vorteil der agentischen Suche zeigt sich recht rasch, wenn man beispielweise das System anweisen kann, in welcher Reihenfolge Datenbestände abgearbeitet werden sollen.

Erstellen des OKF Bundles

Um es der agentischen Suche einfach zu machen wurde der komplette Dokumentenbestand als OKF Bundle verpackt. Dazu wurde jede Datei um einen entsprechenden YAML Frontmatter Header erweitert und die notwendigen Index-Dateien angelegt. Dieser Prozess konnte im Wesentlichen automatisch ablaufen und war in wenigen Minuten erledigt.

Anlegen einer erläuternden Ontologie des Themenbereiches

Wie schon erwähnt genügen die in OKF definierten Beziehungen nicht, den Themenbereich semantisch zu erläutern und das Wissen zu „enthält“ oder „umfasst“ in der Verarbeitung von Fragen mit zu berücksichtigen. Daher wurde der Content-Bestand um eine automatisch erzeugte und manuell kontrollierte Ontologie erweitert. Für die Erstellung der Ontologie wurde AI verwendet, die nur die Anweisung bekam, nach Objekten, Funktionen und den definierten Beziehungen zu schauen. Die Ontologie wurde der Einfachheit wegen ebenfalls als md-Datei erzeugt.

Auch der hier investierte Aufwand lag im Stundenbereich, da die Ontologie maschinell erzeugt wurde und die Prüfung der Inhalte aufgrund der bestehenden Fachkompetenz der Anwender rasch und einfach möglich war. Wären es hier komplett unbekannte Dokumente gewesen, dann wäre diese Prüfung natürlich sehr aufwändig geworden.

Die Integration Known Issues und monatlicher Fixes

Die monatlichen Fixes werden sehr kurz und kryptisch mit dem Hinweis auf die damit gelösten Tickets beschrieben. Diese stecken in anderen Systemen und sind nicht so einfach greifbar. Um die Beschreibungen dennoch einfach und sinnvoll nutzen zu können, werden die Issues über einen Ingestion Process anhand der Ontologie so erweitert, dass sie verständlich auf die Objekt- und Funktionswelt der Anwendung abgebildet werden können.

Die Arbeitsanweisung für den Agenten

Die Arbeitsanweisung in dem Claude Cowork Projekt umfasst grob die folgenden Punkte:

• Rolle, Kommunikationsstil und Handlungsrahmen des Agenten, um den Kontext für die Anwendung zu setzen
• Umschreiben der vom Anwender eingegebenen Frage mithilfe der Ontologie, so dass Bestandteile und Funktionen korrekt klassifiziert werden können.
• Ausführen der Suche
• Danach Analyse eventueller Known Issues zu dem Thema
• Die Anweisung enthält auch den Aspekt, dass der Agent zwischen konkretem Spezialwissen zur Anwendung und allgemeinem IT Wissen gut abgrenzen soll und in seinen Antworten begründen soll, aus welchem Wissenspool er die Antwort generiert hat. Damit weiß der Nutzen, wie verlässlich die entsprechende Auskunft ist.

Erfahrungen

Um die Erfahrungen bewerten zu können ist es wichtig, zuerst einmal die Anforderungen zu definieren.

So sollen die Antworten des Systems „verlässlich“ sein. Verlässlich bedeutet hier, dass das System in der Lage sein soll, vollständig alle möglichen Antworten zu liefern. Es ist nicht kritisch, wenn falsche Antworten geliefert werden. Werden aber nicht alle möglichen Lösungen berücksichtigt, dann wird dies als nicht verlässlich gewertet. Diese Bewertung ergibt sich aus dem Umfeld, in dem Service Mitarbeiter versuchen, bestehende Anwenderprobleme zu beheben. Sofern hier eine falsche Lösung vorgeschlagen wird, die sich beim Testen als unzureichend erweist ist ja nichts „Schlimmes“ passiert. Werden jedoch nicht alle Lösungen gefunden, dann bietet das System nicht den erwarteten Service.

Modellleistungsfähigkeit

Um tatsächlich die Funktion nutzen zu können muss das angewandte Modell hinreichend leistungsfähig sein. Ein Sonnet 4.6 ist nicht in der Lage, verlässliche Antworten zu liefern. Wird die Anwendung mit Sonnet 4.6 betrieben, dann findet das System bei Weitem nicht alle möglichen Anwendungen und lässt damit den Anwender schon eher alleine. Die doch recht komplexe Umgebung mit OKF und der Ontologie überfordert das System bzgl. seiner Schlussfolgerungsfähigkeiten. Hier setzen wir in der Praxis Opus 4.8 ein.

Umschreiben der Frage als wesentliches Erfolgskriterium

Wir haben das System auch so getestet, dass wir konkret von Anwendern geschriebene Tickets 1:1 in den Assistenten kopiert haben. Wir stellen natürlich fest, dass Anwender oft nicht in der Lage sind, ihr tatsächliches Problem auszudrücken. Das Umschreiben der Frage hilft daher sowohl dem Service Agenten als auch dem System als solchem, die Frage korrekt einordnen zu können und die Frage zu beantworten. Dies und die intelligente agentische Suche führen zu einem deutlichen Anstieg korrekter Antworten im Vergleich zu einem einfachen System, in das man die PDFs reinkopiert hat.

Einfache Integration der Known Issue und einfache Aktualisierung

Die Integration der Known Issues führt zu einer deutlichen Vereinfachung in der Service Bearbeitung, da die bekannten Fehler nicht manuell geprüft werden müssen. Das Aufnehmen neuer Dokumente oder auch neuern Known Issues zeigt sich als einfach und effizient und hält das System damit mit geringem Aufwand aktuell, da einfach bestehende Dokumente verwendet werden können und das Umarbeiten der Dokumente maschinell erfolgt.

Fazit

Die Nutzung von OKF in dem beschriebenen Service Agenten hat das Potential und die Grenzen von OKF deutlich gezeigt. Gerade für agentische Suche ist OKFein großer Vorteil, aber schon in mittelkomplexen Fällen sollte man überlegen, OKF durch eine konkrete Ontologie zu erweitern, da OKF nur ein Navigieren in den Datenbeständen ermöglicht, nicht jedoch in den Themen und Begriffen.