Suche in der Ontologie schlägt die Suche in Dokumenten

Aufgeräumte graue Archivregale mit beschrifteten Ordnern in einem modernen Archivraum, ein Ordner mit blauem Reiter halb herausgezogen, eine Hand greift danach, geringe Schärfentiefe

Ein Unternehmen verbindet ein Sprachmodell mit seiner Dokumentenablage: Verträge, Verfahren, Richtlinien, Besprechungsnotizen, über Jahre gesammelt. Das ist Retrieval-Augmented Generation, kurz RAG: Stellt jemand eine Frage, findet das System die Passagen, die ihr am ähnlichsten sind, und gibt sie dem Modell als Grundlage für die Antwort.

Ein Mitarbeiter im Kundenservice fragt, welche Lieferbedingungen ein bestimmter Kunde hat. Das System findet drei Fassungen des Vertrags dieses Kunden, einen Anhangsentwurf, der nie unterschrieben wurde, und eine E-Mail, in der jemand andere Bedingungen vorgeschlagen hat. Das Modell mischt alles zu einer flüssigen, selbstbewussten Antwort, die zu keinem davon passt. An einem anderen Tag findet es stattdessen die allgemeinen Geschäftsbedingungen des Unternehmens, nicht den kundenspezifischen Anhang, der sie außer Kraft setzt.

Die Ursache liegt in der Funktionsweise der Dokumentensuche. Sie findet Text, dessen Bedeutung der Frage ähnelt. Sie weiß nicht, welche Fassung gilt, welches Dokument ein Entwurf ist, für welchen Kunden eine Klausel gilt oder dass ein Anhang die allgemeinen Bedingungen ersetzt. Das sind keine Eigenschaften von Text. Es sind Zustände und Beziehungen – und genau dafür ist ein Modell des Unternehmens, eine Ontologie, da.

Wo die Dokumentensuche bricht

Fassungen. Ein überholter Vertrag ist der Frage genauso ähnlich wie der aktuelle und wird genauso bereitwillig gefunden. Ähnlichkeit kennt kein „gültig“.

Beziehungen, die beim Zerschneiden verloren gehen. Dokumente werden vor der Indexierung in Abschnitte zerlegt. Eine Klausel zu Lieferbedingungen landet in einem Abschnitt, die Seite mit dem Kundennamen in einem anderen, und die Verbindung ist weg.

Fragen, die eigentlich Zählungen sind. „Wie viele offene Reklamationen hat dieser Kunde?“ steht in keinem Dokument. Es ist eine Zählung über Datensätze, und keine noch so große Textähnlichkeit liefert sie zuverlässig.

Berechtigungen, die zu spät greifen. Enthält der Index Dokumente, die die fragende Person nicht sehen darf, ist das nachträgliche Herausfiltern fragil – und ein Fehler zeigt vertraulichen Text der falschen Person.

Aktualität. Der Index ist so aktuell wie sein letzter Neuaufbau. Der heute Morgen unterschriebene Vertrag ist noch nicht darin.

Quellenangaben, die nichts klären. Die Antwort zitiert eine Passage, aber nichts sagt dem Leser, ob diese Passage aus dem derzeit gültigen Dokument stammt.

Erst im Modell suchen, dann in Dokumenten

Beim Objekt beginnen. Die Frage nennt einen Kunden. Lösen Sie das zum Kundenobjekt in der Ontologie auf und folgen Sie dann seinen Beziehungen: die gültigen Verträge, ihre Anhänge, offene Aufträge, offene Reklamationen. Das Modell des Unternehmens leistet die Eingrenzung, die Ähnlichkeit nicht leisten kann.

In Dokumenten an Datensätzen suchen. Der aktuelle Vertrag ist das Dokument am Vertragsdatensatz mit dem Status „gültig“. Die Textsuche läuft dann innerhalb dieses Dokuments, nicht über alles, was das Unternehmen je geschrieben hat.

Strukturierte Fragen mit Abfragen beantworten. Anzahlen, Summen, Termine und Status kommen aus den Datensätzen, berechnet – nicht aus Passagen, die sie zufällig erwähnen.

Berechtigungen vor der Suche anwenden. Die Rechte der Person entscheiden, welche Objekte überhaupt sichtbar sind. Das Modell erhält den Rest nie und kann ihn deshalb auch nicht preisgeben.

Datensatz und Fassung zitieren. Die Antwort verlinkt den Vertragsdatensatz, seine Fassung und die Klausel, sodass die Person sie mit einem Klick prüfen kann.

Die Dokumentensuche bleibt nützlich für Wissen, das tatsächlich in Fließtext steckt: Verfahren, Handbücher, gesammeltes Know-how. Selbst dort funktioniert sie besser, wenn jedes Dokument an den Objekten hängt, die es beschreibt, sodass die Suche an der richtigen Stelle beginnen kann.

So ist Hurukan angelegt. Jedes Dokument hängt an seinem Datensatz, mit Revisionen und Prüfungen, wie unter Projekte und Dokumente beschrieben. Die Ebene Ontologie hält die Objekte, Beziehungen und Zustände, und die Ebene Superintelligenz ist darauf ausgelegt, ihre Modelle zuerst in dieser Struktur zu verankern, mit bereits angewandten Berechtigungen. Das System ist im Aufbau. Woher ein solches Modell überhaupt kommt, behandelt Ihr Unternehmen hat schon eine Ontologie.

Ein Test, den Sie heute machen können

Sammeln Sie zehn Fragen, die Ihre Mitarbeitenden diesen Monat tatsächlich zu Kunden, Aufträgen, Lieferanten oder Verträgen gestellt haben. Notieren Sie zu jeder, wo die richtige Antwort wirklich steht:

  • in einem Dokument,
  • in mehreren Dokumenten, die kombiniert werden müssen,
  • in einem Datensatz,
  • oder in einer Zählung oder Summe über viele Datensätze.

Stellen Sie dann dieselben zehn Fragen Ihrem aktuellen System zur Dokumentensuche, falls Sie eines haben, und prüfen Sie jede Antwort an der echten Quelle.

Notieren Sie, wo die falsche Fassung, der falsche Kunde oder eine erfundene Anzahl auftaucht. Häufen sich die Fehler in jeder Kategorie außer „ein Dokument“, haben Sie die Grenze der Dokumentensuche gefunden – eine Grenze des Designs, nicht des Modells. Die allgemeinere Frage, wo Sprachmodelle helfen und wo nicht, behandelt wo sich Sprachmodelle bezahlt machen.