Ontologiestruktur versus Modellgröße: Was das Design eines Graphen einen KI-Agenten kostet.

Wenn ein Agent unter seinen Leistungsstandards bleibt, ist die gängigste Lösung bei den meisten Teams ein größeres Modell. Das funktioniert zwar, kostet aber etwa vierzehnmal so viel wie die Behebung des Problems durch Anpassung des Graphen. Diese Zahl stammt aus einem Experiment, in dem dieselben Fakten auf drei verschiedene Arten modelliert wurden und ein einzelner Agent auf Microsoft Foundry vier Durchsuchungswerkzeuge sowie keine anderen Möglichkeiten zur Lösung hatte. Gemessen wurde dabei die Kostenstruktur des Wissens pro Frage.

Drei Darstellungsweisen derselben Faktenbasis sind oben dargestellt, insgesamt 2.435 Fakten. Jedes Panel ist ein echter Teilgraph aus den Experimentaldaten, der zeigt, wie jede Ontologie das Umfeld genau derselben drei Versicherungsansprüche darstellt. In der flachen Darstellung ist die Struktur in Eigenschaften eingebettet, sodass kaum Verbindungen bestehen. In der normalisierten Darstellung wird jedes Faktum zu einem eigenen Knoten: Nichts fehlt, doch nichts trägt einen Namen. In der gestalteten Darstellung wird jede Entität benannt und jede Kante beschriftet. Agent, Modell und Datenbank bleiben in allen drei Darstellungen identisch, und nur die Gestaltung ändert sich.

Zunächst ein Wort zu den Daten. Alles darin ist erfunden: Personen, Unternehmen, Orte sowie die Versicherungsgesellschaft stammen aus künstlich erstellten Wörterlisten mit fester Ausgangsdatenbasis, sodass nichts davon auf etwas Reales verweist. Die Messwerte stammen aus Live-Tests in Schweden Mitte. Die Berechnungen erfolgten auf einer speziellen Microsoft Foundry-Instanz, die Daten lagen in einem Azure Cosmos DB-Konto für Apache Gremlin, und jeder Toolaufruf war eine Gremlin-Abfrage, die auf einem Live-Graphen ausgeführt wurde. Insgesamt ergaben sich 480 Agent-Episoden, 4,3 Millionen Tokens sowie 8,09 Dollar. Ein erster Durchlauf derselben Struktur, bei dem die Tools die Generator-Dateien statt der Datenbank lasen, kostete 7,74 Dollar; dieser wird als Kreuzprüfungslauf bezeichnet. Alle angegebenen Zahlen stammen aus den Cosmos-Kampagnen, und die Kreuzprüfung wird nur dann durchgeführt, wenn zwei Durchläufe gemeinsam etwas zeigen, was ein einzelner Durchlauf nicht konnte.

Die Schicht, die niemand aktualisiert

Teams, die Agenten veröffentlichen, wiederholen in der Regel ein bestimmtes Muster. Der Agent versagt bei Fragen, die er eigentlich bewältigen sollte. Jemand schlägt ein komplexeres Modell vor. Die Rechnung verdoppelt sich, die Fehler verschieben sich auf andere Fragen, und am Ende kommt man zu dem Schluss, dass die Agenten noch nicht bereit sind.

Fast niemand bringt das eigentliche Material zur Sprache: die Struktur des Wissens, das dem Agenten mitgegeben wurde. Vergessen wir für einen Moment die Fakten. Man sollte sich fragen, ob der Schadensbehandler ein Knoten oder eine Zeichenkette in einem JSON-Objekt ist, ob die Verbindung mit assessed_by oder lediglich related bezeichnet wird, und ob der Weg von einer Schadensmeldung zum Versicherungsnehmer einen oder fünf Schritte erfordert.

Frühere Messungen betrafen ein System, das Entscheidungen trifft, sowie ein Werkzeug, das diese Entscheidungen festhält. An anderer Stelle erstellte eine dreiteilige öffentliche Serie eine dauerhafte Wissensschicht, führte daraufhin Agenten mit eigenen synthetischen Versicherungsdaten durch und argumentierte dafür, Wissen als gezieltes Konstrukt statt als reines Abrufwerkzeug zu betrachten. Was diesem Argument fehlte, waren Messungen – dieses Experiment liefert solche. Es fügt einer Schicht, über die die Agenten reasoningen, eine weitere Ebene hinzu und stellt eine Frage, auf die selten Zahlen vorliegen: Wenn Modell, Werkzeuge, Anfragen und Fakten unverändert bleiben und nur die Struktur der Ontologie geändert wird, wie reagieren Genauigkeit, Aufwand und Kosten darauf?

Diese erste Antwort lädt zu einem Einwand ein, weshalb das gesamte Modell auf einem viel größeren Modell erneut ausgeführt wurde, um zu prüfen, ob Geld einfach einen schlecht geformten Graphen überholen kann. Das ist möglich. Interessant ist dabei der Preis sowie das, was er über die Form aussagt, die es lohnt, zu erstellen. Wie zuvor benötigt jede Behauptung einen Nachweis.

Drei Formen derselben Wahrheit

Das Testgebiet ist ein Versicherungsgeschäft mit Versicherten, Policen, Versicherungssummen, Schadensansprüchen, Schadensbegutachtern, Reparaturdienstleistern, Zahlungen und Regionen. Ein vordefinierter Script erstellte all das einmal und ergab 2.435 kanonische Fakten zu 507 Entitäten – alle fiktiv.

Drei Ontologien entstehen aus dieser einen Faktenbasis. Sie als drei Datensätze zu bezeichnen wäre falsch; es handelt sich um drei verschiedene Darstellungsformen derselben Daten unter einer einzigen Leitregel: Jede Variante muss die Fakten ohne Zuwachs und ohne Verlust erneut darstellen. Um dies durchzusetzen, durchläuft ein Skript jeden erstellten Graphen, rekonstruiert die Fakten und stellt sicher, dass das Ergebnis exakt mit der Quelle übereinstimmt. Eine Variante, die einen Fakt mehr oder weniger kennt als eine andere, würde den Wettbewerb zu einem Test der Datenerfassungsgenauigkeit machen. Der Repository-CI führt diese Überprüfung bei jedem Push auf die Hauptbranche sowie bei jedem Pull Request durch, zusammen mit einer Prüfung, ob die gespeicherten Daten bytegenau mit dem übereinstimmen, was aus der Ausgangsdatenquelle erzeugt wird – das Experiment gilt als ungültig, sofern nicht beides besteht. Es gilt eine Einschränkung hinsichtlich der Gerechtigkeit: Die Implementierungen für die flache und geformte Struktur wurden ohne Bezug auf den Faktensatz entwickelt, wodurch ihre Überprüfungen inhaltlich fundiert sind, während der normalisierte Graph direkt aus den Fakten kodiert wird und somit durch seine Konstruktion verlustfrei enger an die Realität angelehnt ist als durch Beweise.

Die flache Struktur ist es, die viele Teams zunächst bereitstellen, und sie verwendet lediglich zwei Haupttypen von Knoten. Jeder Policeninhaberknoten speichert seine Policen sowie deren Leistungen als JSON-Objekt in einem Attribut. Jeder Schadensfallknoten enthält auf dieselbe Weise seinen Schadensregler, Anbieter und Zahlungen. Ein einziger generischer Kantentyp, related, verbindet die Policeninhaber mit den Schadensfällen – das ist das gesamte Schema. Alle Informationen sind vorhanden, allerdings versteckt.

Die Normalisierung versagt in die entgegengesetzte Richtung und ist kein Scheinargument, da ein Lehrbuch sie loben würde. Sie verdinglicht alles. Entitäten werden zu einfachen Resource-Knoten, die nur ihren Typ enthalten, jedes Attribut wird zu einem Attribute-Knoten, der über eine generische has-Kante erreichbar ist, und jede Beziehung wird zu einem Relation-Knoten mit subject- und object-Kanten. Auf dem Papier sieht das makellos aus, doch um irgendetwas zu lernen, sind vier Schritte nötig.

Shaped ist um den Verbraucher konzipiert, der es tatsächlich nutzen wird. Die Knotentypen sind in absichtlich definierte Kategorien unterteilt, und jede Kante verfügt über eine Richtung, einen Typ sowie einen aussagekräftigen Namen wie filed_against, assessed_by oder settles. Richtlinien verweisen mit held_by auf die Versicherungsnehmer, und derselbe Name wird absichtlich noch einmal verwendet – genauer gesagt für neunzig abgeleitete held_by-Kanten, die direkt von einer Schadensmeldung zu deren Versicherungsnehmer führen und so den Weg von Schadensmeldung zu Versicherungsnehmer auf einen einzigen Schritt verkürzen. Die Wiederverwendung des Namens ist beabsichtigt, da die Beziehung von beiden Seiten aus gleich aussieht und der Agent kein zweites Wörterbuch benötigt. Die neunzig Kanten tragen ein derived-Flag, liefern keine zusätzlichen Informationen und werden bei der verlustfreien Nachweisführung weggelassen, da sie sich auf bereits vorhandene Fakten beziehen.

Abbildung 1 skizziert eine einzige Beziehung – eine Anspruchsanmeldung und ihren prüfenden Schadensbehandler – in allen drei Formen. Bei der flachen Darstellung wird der Schadensbehandler in eine JSON-Eigenschaft der Anspruchsanmeldung eingebettet und fast nichts weiter verknüpft. Bei der normalisierten Darstellung erhält die Beziehung einen eigenen Knoten, zwei Kanten sowie einen separaten Attributknoten für jeden Fakt. Bei der gestalteten Darstellung wird lediglich der Name der Kante angegeben, und das zugehörige Panel zeigt außerdem auf, warum es diesen einzigen abgeleiteten Abkürzungsweg gibt. Ein Rekonstruktionsskript bestätigt, dass alle drei Darstellungen genau dieselben 2.435 Fakten enthalten.

Die Anzahl der Knoten gibt einen Überblick über die Struktur. Ein Satz Wahrheiten benötigt 130 Knoten bei der flachen Darstellung, 507 bei der gestalteten Darstellung und 2.942 bei der normalisierten Darstellung; jeder zusätzliche Knoten stellt einen Punkt dar, den der Bearbeiter möglicherweise aufsuchen muss.

Eine konkrete Entität macht den Unterschied besser sichtbar als eine Beschreibung. Nehmen wir die Police, die durch die Ergebnisse berühmt werden wird – sie wird in jeder Variante tatsächlich gespeichert:

Abbildung 2 lädt die Richtlinie P-7009 direkt über das Abbildungsrendering-Skript aus den gespeicherten Ontologie-Dateien herunter – denselben Dateien, die auch in Cosmos geladen wurden – sodass genau dargestellt wird, welchen Weg der Agent eingeschlagen hat. Flat speichert die Richtlinie als Zeichenkette innerhalb einer Eigenschaft des Versicherungsnehmers: Sie existiert zwar, ist aber kein Knoten und kann daher nicht adressiert werden. Normalized speichert sie als einen einfachen Resource-Knoten, wobei die Attributwerte jeweils in separaten Knoten, zwei Schritte entfernt, gespeichert sind. Shaped hingegen verwendet einen typisierten Knoten, dem die Eigenschaften zugeordnet sind sowie benannte Kanten, die von ihm ausgehen. Die Prämie bleibt in allen drei Fällen gleich, befindet sich jedoch in unterschiedlichen Entfernungen zum Ausgangspunkt der Frage.

Jede Form befindet sich in ihrem eigenen Graphen-Container innerhalb von Azure Cosmos DB für Apache Gremlin, und genau diesen durchquert der Agent; jeder unten aufgeführte Toolaufruf wird zu Gremlin-Durchquerungen im laufenden Graphen. Der Generator erzeugt die Faktabasis, ein Lader schreibt sie in Cosmos ein, und der Lader prüft sich selbst: Die Anzahl der Knoten und Kanten muss der im Quellcode angegebenen entsprechen, andernfalls wird ein Mismatch gemeldet, anstatt später ein unvollständig erstellter Graph gefunden zu werden.

Eine Datenbank, eine Tool-Schicht sowie identische Standardindizes sorgen dafür, dass die Designs vergleichbar sind und zugleich sichtbar werden. Ein Property Graph versteckt nichts. Fragen Sie ihn, was er weiß – die Antwort ist das Design selbst.

Tabelle 1 zählt die gleichen 2.435 Fakten unter jedem Schema, die aus den Graphen-Dateien stammen. Bei der flachen Struktur gibt es mehr Knoten als Kanten, und fünf Knoten sind nicht mit etwas verbunden. Die normalisierte Struktur ist einheitlich und enthält keine Texte. Die gestaltete Struktur ist am besten vernetzt, und ihre Beschriftungen verwenden das Vokabular des jeweiligen Bereichs.

Zur flachen Struktur zurück: Die Anzahl der Kanten ist geringer als die der Knoten, und fünf Knoten sind mit nichts verbunden; es handelt sich dabei um Versicherungsnehmer ohne Ansprüche, und bei dieser Struktur führt nichts anderes in der Welt zu ihnen. Das ist eine Graph-Datenbank, die etwas speichert, das kaum noch als Graph gilt. Die Struktur existiert zwar weiterhin, doch sie wurde in 8,2 Eigenschaften pro Knoten aufgelöst, wodurch sie sich wie Text und nicht wie Topologie verhält. Die Ergebnisse hängen von dieser Gestaltungsoption ab, und die Graph-Datenbank gibt dies als Faktum statt als Meinung an.

Die normalisierte Spalte spiegelt dies wider. Dies ist der einheitlichste der drei Diagramme: ungefähr eine Kante pro Knoten, nichts Isoliertes, 1,6 Eigenschaften pro Knoten, da die Reifikation jeden Fakt in dieselben drei Bausteine umwandelt, die insgesamt 2.942 Mal wiederholt werden. Die Struktur ist reichhaltig, während ein Wortschatz fehlt – drei Knotenbezeichnungen und drei Kantenbezeichnungen genügen, um ein ganzes Versicherungsgeschäft abzubilden.

Mit 1,36 Kanten pro Knoten ist das geformte Diagramm am besten vernetzt, es weist acht Knotenbezeichnungen und neun Kantenarten auf. Der Unterschied wird sofort sichtbar, wenn von jedem Diagramm gefragt wird, welche Arten von Elementen es enthält:

g.V().groupCount().by(label)

• Die Flat-Struktur enthält nur Ansprüche (90) und Versicherungsnehmer (40).
• Die normalisierten Berichte umfassen Ressourcen (507), Attribute (1834) und Beziehungen (601).
• Die geformten Listen enthalten acht Domänenschilder: 216 für Absicherung, 90 für Ansprüche, 75 für Policen, 59 für Zahlungen, 40 für Versicherungsnehmer, 12 für Anbieter, 10 für Schadensregulierer und 5 für Regionen.

Eine zweite Abfrage zählt die Policen nach den Schildern:

g.V().hasLabel('policy').count()

Tabelle 2 stellt eine Abfrage neben drei Antworten. Beide Nullwerte stellen Versagen unterschiedlicher Art dar. Im flachen Graphen gibt es einfach keine Richtlinie zu finden. Im normalisierten Graphen existiert zwar eine Richtlinie, doch sie macht sich nicht bemerkbar. Der flache Graph hat die Entität verloren; der normalisierte Graph hat die Entität beibehalten, aber das Vokabular verloren, sodass auf eine Richtlinie nur durch Schreiten darauf zugegangen werden kann, niemals durch Benennung. Nichts davon resultiert davon, wie die Daten zufällig gespeichert wurden: drei Schemata, eine Datenbank, eine Abfrage.

Das gleiche Ungleichgewicht tritt bei der Beantwortung einer realistischen Frage auf. In welcher Stadt wohnt der Versicherungsnehmer bei der Police hinter der Anfrage C-31020? Jeder Graph gibt Larkfield an, weil jeder Graph dieselben Fakten enthält. Was sich unterscheidet, ist der Weg dorthin. Im geformten Graphen verkürzt die abgeleitete Kante diesen Weg:

# shaped - the derived shortcut collapses the path
g.V().has('number','C-31020').out('held_by').values('city')

Die flachen und normalisierten Diagramme benötigen stattdessen dieses:

# flat - one hop, but only because claims and holders are the only two things
g.V().has('number','C-31020').in('related').values('city')# normalized - the same answer, five steps and two unwrappings later
g.V().has('value','C-31020').in('has')
     .in('subject').has('kind','filed_against').out('object')
     .in('subject').has('kind','held_by').out('object')
     .out('has').has('attr','city').values('value')

Flat bewältigt die Aufgabe in nur einem Schritt, weil in diesem Schema eine Anspruchserklärung und ein Inhaber zufällig die einzigen beiden Datentypen sind. Normalisiert erfordert es fünf Schritte sowie zwei Entpackvorgänge. Ein Agent stellt diese Abfragen niemals selbst zusammen; er findet den Weg Schritt für Schritt durch jeweils einen Toolaufruf – genau das ist der Zweck des Experiments. Dennoch zeigen die Abfragen, was entdeckt wird und wie viel davon vorhanden ist.

Abbildung 3 zeigt, dass dieselbe Abfrage auf allen drei Graphen innerhalb des Cosmos DB Data Explorers ausgeführt wird. Egal, ob ein Graph zwei Labels, drei Meta-Labels oder die Informationen im eigenen Wortlaut bereitstellt – die Schemata enthalten nicht unterschiedliche Daten, sondern ein einziges Datensatz in verschiedenen Formen.

In Abbildung 4 wird in jeder Grafik die Schadensmeldung C-31020 ausgewählt, wodurch der Data Explorer ihre Nachbarn anzeigen kann. In der flachen Grafik ist nur ein Knoten erreichbar – ein Versicherungsnehmer – über eine Kante, die lediglich mit related beschriftet ist. Der Schadensbearbeiter AJ-09 sowie die Police PL-043 sind im Eigenschaftenfeld sichtbar, allerdings nur als Text, sodass der Agent keinen Weg zu ihnen hat. In der normalisierten Grafik kommen acht Knoten, sechs Attribute und zwei Beziehungen zum Vorschein, wobei keine davon in der Fachsprache benannt sind. In der gestalteten Grafik sind drei davon benannt: filed_against, assessed_by und held_by. Eine Schadensmeldung, eine Datenbank, drei Entfernungen.

Das Instrument: vier Werkzeuge und eine Quittung

Der Agent wird absichtlich auf ein Minimum beschränkt, da er nicht das getestete Objekt ist. Es handelt sich um einen einfachen Funktionsaufruf-Loop, der gegen eine Microsoft Foundry-Modellverteilung läuft und so konfiguriert ist, wie die Foundry-Dokumentation die Verwendung von Tools über die Chat Completions API beschreibt. Ein fester Systemprompt, eine Obergrenze von sechzehn Modellaufrufen pro Frage (danach wird das Szenario beendet) sowie vier Tools vervollständigen die Konfiguration, wobei die Signaturen in allen drei Ontologien identisch sind.

Abbildung 5 zeigt die gesamte Rechenlast: Eine einzige Microsoft Foundry-Ressource, die zwei Modellverteilungen enthält – agent-small, der gpt-5.4-nano ausführt, und agent-large, der gpt-5.5 ausführt, beides vom Typ Global Standard. Die Namen und Versionen stammen aus dem Infrastruktur-Template im Repository, sodass hinter den Darstellungen keine versteckten Ressourcensteuerungen vorhanden sind.

Die vier Tools sind:

• find_nodes durchsucht die Eigenschaften und IDs von Knoten nach Teilstringen, wobei maximal zwanzig Treffer erfasst werden
• get_node liest den Typ sowie die Eigenschaften eines Knotens aus
• traverse gibt bis zu dreißig Nachbarn eines Knotens zurück, die nach Kantenart und Richtung gefiltert werden können
• describe_edges fasst zusammen, welche Kanten einen Knoten verlassen oder betreten und wie viele es davon gibt

Im Hintergrund wird jedes Tool in Gremlin auf Cosmos umgewandelt. get_node und find_nodes benötigen jeweils eine Durchquerung – einen Punktabruf sowie einen Scan – während traverse und describe_edges drei Durchquerungen benötigen, da sie zunächst überprüfen, ob der Knoten existiert, und anschließend nacheinander die ausgehenden und eingehenden Kanten durchlaufen. Der Agent schreibt nichts davon selbst. Er beantragt einen Knoten oder einen Nachbarn und erhält eine kompakte JSON-Antwort, die übliche Form einer Schnittstelle für Produktivwerkzeuge zu einem Graphen-Speicher, wodurch auch die Abfragesprache vom Modell getrennt bleibt.

Das Durchlaufen des Graphen ist der einzige Weg zu einer Antwort. Der Agent betrachtet niemals das Schema oder schreibt Gremlin, und er hat die Anweisung, bei Fehlen der für eine Frage benötigten Informationen mit dem literalen Wert NOT_MODELED zu antworten. Die Großschreibung ist wichtig: Ein schlecht strukturierter Graph kostet durch zusätzliche Toolaufrufe, anstatt durch eine einzige umfangreiche Antwort, genau wie es bei realen Toolbudgets der Fall ist. Die Obergrenze von sechzehn Schritten zählt die Gesprächsschritte und nicht die Toolaufrufe – in einem Schritt können mehrere Tools gleichzeitig angefordert werden; so wurden in der intensivsten Folge innerhalb der sechzehn Schritte insgesamt sechzig Aufrufe durchgeführt.

Drei praktische Erkenntnisse aus dem Vergleich mit einer echten Graph-Datenbank, bei der jeweils ein Neubau erforderlich war: Cosmos lehnt mehrstufige Skripte ab, wodurch das Laden einer Anfrage eine einzige Durchsuchung bedeutet, und die Durchsatzleistung entsteht durch den parallelen Ausführung vieler Anfragen statt durch Batching. Eine feste Anfragenzeit von sechzig Sekunden verhindert, dass g.V().drop() einige tausend Knoten vollständig löscht – der Vorgang bricht ab und hinterlässt einen teilweise gelöschten Graphen, weshalb das Löschen in Schritten erfolgt. Auch die serverlose Ebene weist eine Durchsatzobergrenze auf, die einen Schub von vierzig gleichzeitigen Schreibvorgängen in Zeitüberschreitungen umwandelt; deshalb versuchen sowohl der Loader als auch das Agent-Tool mit Verzögerungen erneut. Nichts davon ist außergewöhnlich, doch es unterscheidet einen Graphen-Speicher im Ruhezustand von einem unter Last.

Bewertung ohne Richter

Die Bewertung der Agenten wird in der Bewertungsphase tendenziell nachlässiger, weshalb dieser Fall am meisten Aufmerksamkeit erhielt, und es taucht kein LLM-Bewerter irgendwo auf. Vierzig Fragen bilden vier Gruppen à zehn: Suchanfragen nach einzelnen Fakten, kurze Suchwege von zwei oder drei Schritten, Fragen, die einen langen Weg oder eine Aggregation über einen Teilgraphen erfordern, sowie Fragen, die nicht beantwortet werden können. Ein Skript erzeugt sie aus der Faktenbasis und leitet jede richtige Antwort aus den Rohfakten ab. Die Benotung erfolgt mechanisch: Eine Zahl muss dem berechneten Wert entsprechen, eine Zeichenkette muss ihn enthalten, und eine unbeantwortbare Frage zählt nur dann als richtig, wenn der Agent ausdrücklich sagt, dass er sie nicht beantworten kann. Keine Ontologie bewertet sich selbst, kein Modell bewertet ein anderes Modell, und die Richtigkeit ergibt sich aus dem Vergleich statt aus Meinungen.

Da der Agent nur über seine vier Werkzeuge handeln kann, enthält jede Antwort die vollständige Liste der Aufrufe, die sie erzeugt haben. Bei den früheren Messungen des Routers war das Feld model die Quittung; hier ist es der Pfad. Eine richtige Antwort kann Schritt für Schritt nachverfolgt werden, und ein Fehler zeigt genau an, wo die Struktur den Agenten verloren hat.

Abbildung 6 zeigt die Konfiguration. Eine seedbasierte Faktenbasis versorgt drei verlustfreie Strukturen, die zu drei Graphenkontainern in Azure Cosmos DB für Apache Gremlin werden, während ein separater Zweig den Orakel-Algorithmus versorgt, der aus denselben Fakten jede richtige Antwort ableitet. Der Agent erreicht die Graphen ausschließlich über die vier Werkzeuge, wobei pro Aufruf eine Gremlin-Anfrage erfolgt. Werkzeuge, Schleifen und Fragen bleiben konstant, während sich die Strukturen ändern, und jede Ausführung erzeugt Quittungen: Werkzeugaufrufe, Tokens, Latenzzeit sowie ein Urteil des Orakels.

Die unbeantwortbare Klasse verdient einen eigenen Satz. Ihre zehn Fragen beziehen sich auf Dinge, die die Faktendatenbasis niemals abbildet: Telefonnummern, E-Mail-Adressen, Wetter, Fahrzeugidentifikationsnummern. Das richtige Verhalten besteht darin, zu antworten, dass das Graph dies nicht angeben kann. Ein Agent, der anstelle davon eine Kante erfindet, anstatt zuzugeben, dass das Graph keine solchen Kanten besitzt, weist den gefährlichsten Fehler in dieser Systemklasse auf – und kaum jemand misst diesen Fehler.

Was die Durchlaufkosten sind

Die Hauptkampagne wurde auf den aktiven Cosmos DB-Graphen durchgeführt, wobei die Berechnungen auf einer speziellen Microsoft Foundry-Installation in Schweden zentral erfolgten. Sie umfasste drei Ontologien, vierzig Fragen sowie drei vollständige Durchläufe bei konstanter Verwendung eines kleinen Modells – insgesamt ergaben sich 360 Agent-Episoden, 3,1 Millionen Tokens und siebzig Cent. Jeder Tool-Aufruf war eine Gremlin-Anfrage. Eine zweite Kampagne, die später beschrieben wird, führt den Prozess mit einem größeren Modell für weitere 120 Episoden und 7,39 Dollar durch. Ein Repository-Skript berechnet alle unten aufgeführten Werte aus den aufgezeichneten Belegen; keiner dieser Werte wurde von Hand eingegeben.

Tabelle 3 fasst die durchgeführte Kampagne zusammen: kleines Modell, drei Durchläufe, 360 Episoden sowie eine Gremlin-Anfrage hinter jedem Tool-Aufruf. Grün markiert das beste Ergebnis in jeder Zeile. Die Zeilen mit Ressourceninformationen bleiben absichtlich unfarbig, da der Wert „flat“ in allen vier Kategorien am niedrigsten ist – und wie später in den Abschnitten gezeigt wird, deckt dieser sparsame Ansatz teilweise die Kosten für Antworten, die nie geliefert wurden.

Zunächst wird die erste Zeile abgezogen, da sie die am wenigsten aussagekräftige Zahl in der Tabelle ist. „Shaped“ beantwortete 84,2 % der Fragen richtig, „flat“ 78,3 % und „normalized“ 59,2 %. Dennoch schwankte die Genauigkeit der Varianten bei drei ansonsten identischen Durchläufen jeweils um 0,075, 0,150 und 0,075, sodass der sechspunkte Unterschied zwischen „shaped“ und „flat“ innerhalb des eigenen Rauschens liegt. Bei drei Durchläufen lässt sich anhand der Gesamtgenauigkeit nichts ausmachen, was diese beiden Varianten voneinander unterscheidet. Der Vorsprung von 25 Punkten gegenüber „normalized“ beseitigt das Rauschen hingegen mühelos.

Das klingt schwächer, als es ist. Die Gesamtzahl ist unklar, weil sie Bereiche mit starken Unterschieden durchschnittlich berücksichtigt – und gerade dieser Unterschied ist die entscheidende Erkenntnis:

Tabelle 4 erläutert das Problem mit der Aggregation. Die Formen unterscheiden sich nicht überall nur geringfügig; sie teilen sich in klar abgegrenzten Bereichen auf, und jeder Bereich stellt unterschiedliche Anforderungen an das Diagramm.

Betrachten Sie zunächst die Abfragen mit einem einzigen Faktor. Die Werte liegen bei 0,967 für die gestaltete Variante und 0,533 für die flache Variante – ein Unterschied von 43 Punkten – gegenüber einem Rauschpegel von 0,100 bei der einen Variante und 0,200 bei der anderen, wodurch das Signal als echt angesehen werden kann. Bei zweistufigen und dreistufigen Abläufen erreichen beide Varianten ebenfalls 0,967. In der schwierigsten Kategorie lassen die Rauschwerte von 0,300 bzw. 0,400 keinen Sieger erkennen.

Die beiden Varianten sind daher weder besser noch schlechter. Sie brechen an unterschiedlichen Stellen zusammen, und ihre Zusammenfassung in einer einzigen Zahl verdeckt den nützlichen Teil. Wenn etwas gefunden werden muss, versagt die flache Variante immer wieder. Wenn der Agent bereits einen Ausgangspunkt hat und nur noch voranschreiten muss, leistet die flache Variante genauso gute Arbeit wie der ursprünglich entworfene Graph.

Die normalisierte Variante spiegelt dies wider, wie ihre Werte zeigen: 0,867 bei den Abfragen, was besser ist als bei der flachen Variante, da jede Entität ein echter Knoten darstellt; anschließend 0,467 und 0,133, je länger die Abläufe werden. Sie findet zwar alles, schafft es aber nicht, etwas abzuschließen.

Wie jede Variante versagt

Die verschiedenen Ansätze unterscheiden sich sowohl in der Art als auch im Ort ihres Versagens. Jeder Ansatz beantwortete dreißig Fragen dreimal, insgesamt neunzig Episoden, und die Gruppierung der Fehlschläge nach Versagertypen macht den Mechanismus sichtbar.

Tabelle 5 gruppiert die Fehlschläge in diesen neunzig Episoden. Normalized verbraucht sein Zeitbudget; Flat stoppt früh und zuversichtlich bei Fragen, die die Datenbank hätte beantworten können.

Bei neunzig Episoden von Normalized endeten zweiundzwanzig, etwa ein Viertel, damit, dass das Budget aufgebraucht war und der Agent mitten im Vorgehen steckte. Flat tat das selten. Es stoppte früh und selbstsicher und lehnte achtzehn Fragen ab, obwohl die Antworten in der Datenbank vorhanden waren. Der eine Ansatz erschöpft sich, der andere gibt auf.

Der plötzliche Ausfall ist der deutlichere, und die Spuren deuten auf einen Mechanismus hin, den niemand erwartet hatte. Hier sind zwei reale Fälle. Beide fordern die Prämie für die Police P-7009, und sie unterscheiden sich nur darin, welches Schema hinter den Tools steht:

flat                                       shaped
find_nodes "P-7009"          -> 1 hit:     find_nodes "P-7009" type=policy
   policyholder:PH-05 "Ivo Renner"            -> 1 hit: policy:PL-009 "P-7009"
find_nodes "7009"            -> 1 hit      get_node policy:PL-009
find_nodes "P-7009" type=policy       -> 0     -> premium 750
find_nodes "P-7009" type=policyholder -> 1 hit
ANSWER: NOT_MODELED                        ANSWER: 750

Auf dem gestalteten Graphen reichen zwei Aufrufe aus. Man fragt nach der Police anhand der Nummer, erhält einen Vertex für die Police, liest dort die Prämie ab – fertig.

Der flache Graph erzählt eine andere Geschichte. Die erste Suche lieferte einen Vertex, genauso wie die zweite. Die dritte Suche bat um type=policy und fand nichts, da diese Bezeichnung in diesem Schema nicht existiert. Die vierte Suche bat um type=policyholder und fand einen Treffer. Somit fand der Agent nach Art der Anfrage den exakt richtigen Vertex mit der Antwort – erklärte die Daten dennoch als fehlend.

Die Prämie befand sich innerhalb dieses Knotens, in einer Eigenschaft – nur einen get_node-Aufruf entfernt. In den zehn fehlerhaften Fällen mit Prämien lieferte die unfilterte Suche den entsprechenden Knoten fünfzehnmal, während get_node insgesamt null Mal darauf angewendet wurde. Der Knoten trug die Bezeichnung „Ivo Renner“, eine Person. In den übrigen fehlerhaften Fällen gehörte die Bezeichnung einem der beiden anderen Versicherungsnehmer, niemals der Versicherungspolice selbst, und ein Personennamen liefert keinerlei Hinweis darauf, dass die gesuchte Police sich darin befindet.

Das ist die besondere Gefahr dabei, eine Entität zu verstecken – eine Graph-Datenbank macht sie zwar auffindbar, doch sie bleibt unerkennbar. Die Daten sind indiziert, werden durch die Abfrage zurückgegeben und befinden sich im Kontext des Agents, antworten aber auf keinen der verwendeten Namen.

Die Normalisierung scheitert offenbar und kostspielig. Das Lesen eines Attributs erfordert einen Weg durch einen Attribute-Node, und das Verfolgen einer Beziehung bedeutet einen Umweg über einen Relation-Node. Die Spalte „Tokens“ zeigt die Rechnung: 13.701 pro Frage im Vergleich zu 7.176 bei der gestalteten Variante, sowie 12,15 Toolaufrufe gegenüber 7,24. Fünfundzwanzig der 120 Episoden erreichten die Grenze von sechzehn Schritten, im Gegensatz zu drei bei der gestalteten Variante und zwei bei der flachen Variante; die schwierigste Gruppe erzielte einen Wert von 0,133. Dem Graphen fehlte nichts. Der Agent hatte einfach vor dem Beenden des Satzes keine Luft mehr.

Die günstigste Variante ist tatsächlich die billigste – was allerdings kein Kompliment ist. Die „Flat“-Variante kostet 0,109 Dollar pro hundert Fragen, während die „Shaped“-Variante 0,165 Dollar verlangt; auch bei Berücksichtigung der Genauigkeit bleibt die „Flat“-Variante vorteilhaft, mit 0,14 Dollar pro hundert richtiger Antworten gegenüber 0,20 Dollar. Nach diesem Modell ist die „Flat“-Variante tatsächlich günstiger in der Anwendung. Was der Preis jedoch nicht ausgleicht, sind die achtzehn Antworten, die sie ablehnte. Schnelles Aufhören ist kostengünstig, doch eine niedrige Rechnungssumme unter einer hohen Obergrenze stellt keine Ersparnis dar – etwas, das eine Kostenübersicht allein niemals zeigt.

Das Ablehnungsparadox

Sobald die beantwortbaren Fragen berücksichtigt werden, tauschen die beste und die schlechteste Variante ihre Plätze in der Kategorie der unbeantwortbaren Fälle. Die „Flat“-Variante lehnte alle dreißig unbeantwortbaren Fälle korrekt ab und erzielte damit die einzige perfekte Punktzahl in der Tabelle. Die „Shaped“-Variante erreichte 0,933 und nach Normalisierung 0,900; ihre Fehlerraten entstanden durch das Auslaufen der Antwortmöglichkeiten, nicht durch erfundene Antworten.

Allein betrachtet ist diese Gruppe am besten. Neben der Anzahl der falschen Ablehnungen ändert sich die Reihenfolge: Die Gruppe mit der perfekten Ablehnungsrate hat achtzehn Fragen ignoriert, die sie hätte beantworten können, während die Gruppe mit der schlechtesten Ablehnungsrate dreizehn Fragen ignoriert hat. „Flat“ ist nicht besser darin, Abwesenheit zu erkennen – es neigt eher dazu, sie anzukündigen, und diese Neigung, bei unbeantwortbaren Fragen zu gewinnen, führt bei beantwortbaren Fragen zum Verlust. Eine Ablehnungsmetrik ohne eine entsprechende Beantwortbarkeitsmetrik führt dazu, dass der schlechteste mögliche Graph erstellt wird.

Eine Erkenntnis gegen das Design

Ein Ergebnis widerspricht dem vom Experiment bevorzugten gestalteten Design, und die zweite Kampagne hat es noch verstärkt. In der gestalteten Variante existiert nur ein einziger abgeleiteter Abkürzungsweg: held_by, der eine Schadensmeldung direkt mit ihrem Versicherungsnehmer verbindet. Bei der Frage nach der Verbindung zwischen Schadensmeldung, Versicherungsnehmer und Stadt erzielte diese Variante einen Wert von 0,83, während die normalisierte Variante 0,33 erreichte; die einfache Variante hingegen erreichte 0,92 – ohne jegliche Abkürzung –, da in diesem Schema lediglich eine Schadensmeldung und ein Versicherungsnehmer vorhanden sind. Ein Ergebnis, das die Variante ohne die zusätzliche Struktur besser erzielt, kann daher nicht der zusätzlichen Struktur zugeschrieben werden.

Schlimmer noch: Der fehlende Shortcut hatte dort Kosten, wo er erwartet wurde. Die Zählung der verschiedenen Abdeckungsarten über die Policen eines Inhabers ergab 0,17 im angeblich gut gestalteten Graphen und 0,67 im flachen Graphen, wodurch beide in einer lesbaren Eigenschaft zusammengefasst werden. Die Gesamtbeträge für die Zahlungen bei Ansprüchen eines Inhabers lagen bei 0,33. Bei der Aggregation über einen Teilgraphen verliert das vorgeschlagene Design gegen das sogenannte „broken“-Design. Denormalisierung ist kein Kompromiss gegenüber gutem Design, sondern ein Bestandteil davon – und der gestaltete Graph wendete sein eigenes Prinzip genau dort zu sparsam an, wo die Arbeitsbelastung es erfordert hätte.

Sich mit einem größeren Modell herauskaufen

Das vollständige Gitter wurde anschließend ein zweites Mal auf einem weitaus größeren Modell ausgeführt, und die Antwort auf die Hauptfrage ergab sich aus seinem unerwarteten Verhalten. Ursprünglich ging man davon aus, dass das kleine Modell auf einem gut geformten Graphen das große Modell auf einem schlecht geformten Graphen übertreffen würde. Das war jedoch nicht der Fall. Nur beantwortbare Fragen kommen in diesen Vergleich, sodass Ablehnungen unbeantwortbarer Fragen keiner Graphenform zugutekommen können. Jede Zeile mit dem kleinen Modell umfasst neunzig Episoden über drei Durchläufe, während jede Zeile mit dem großen Modell dreißig Episoden aus einem einzigen Durchlauf enthält.

Tabelle 6 beschränkt sich auf beantwortbare Fragen, wodurch richtige Ablehnungen einer zur Ablehnung neigenden Graphenform keinen Vorteil verschaffen können.

Das große Modell liest versteckte Eigenschaften problemlos. Es beantwortete alle dreißig beantwortbaren Fragen zum flachen Graphen, einschließlich jener zu Entitäten, die das Schema in Text umgewandelt hatte, und die achtzehn falschen Ablehnungen, die das kleine Modell behinderten, verschwanden. Die ehrliche Bilanz ist nicht die, die jemand erwartet hatte.

Eine schlecht gestaltete Ontologie kann sich auszahlen. Der Preis liegt etwa vierzehnmal über der Kosten pro Frage: Das große Modell am flachen Graphen kostet 1,90 Dollar pro hundert Fragen, das kleine Modell am gestalteten Graphen dreizehn Cent. Behalten Sie den flachen Graphen bei und aktualisieren Sie nur das darunterliegende Modell – dann beträgt die Rechnung zwanzigmal so viel wie die Kosten für dasselbe kleine Modell auf diesem Graphen.

Dieses Ergebnis ist aufgrund dessen, was es impliziert, nützlicher als das vorhergesagte. Mit einem Grenzmodell und beantwortbaren Fragen war die Formgebung kein Korrektheitsproblem mehr, sondern wurde zu einem Kostenproblem: Sowohl die flache als auch die geformte Variante beantworteten alle dreißig Fragen, und nur die Rechnung unterschied sie. Bei einem kleinen Modell war die Formgebung selbst die Korrektheit. Eine gut gestaltete Ontologie bringt daher weniger Qualität mit sich als die Fähigkeit, ein günstiges Modell zu nutzen. Ein flaches Graphen verbindet die Wissensschicht mit dem Modellbudget und funktioniert nur solange, wie die Zahlungen für ein groß genuges Modell weiterlaufen, um bei jeder Frage unbegrenzt darauf zuzugreifen.

In allen vier Bereichen ist die Sortierung ordentlicher, als es aus der reinen Ansicht der beantwortbaren Fragen hervorgeht. Bei dem großen Modell erreichte die geformte Variante in jedem Bereich, einschließlich dem der unbeantwortbaren Fragen, einen perfekten Wert von 1,000. Die flache Variante erreichte 0,950 und normalisiert 0,825. Geld verbessert die Korrektheit nur teilweise, während die Rechnung unverändert bleibt.

Was die Überprüfung über Vorsicht lehrte

Die Durchführung der Überprüfung (dieselbe Gitterstruktur, dieselben Fragen, Tools, die Dateien statt Cosmos lesen) ergab das beunruhigendste Ergebnis des Projekts – und es stammte vom gestalteten Diagramm. Als gefragt wurde, wie das Wetter am Tag eines Vorfalls war, was die Ontologie absichtlich nicht modelliert, antwortete das System mit „Hagelschaden“. Es hatte die Eigenschaft cause der Anzeige gefunden und diese als Wetter dargestellt. Zu diesem Zeitpunkt wurde dies als der gefährlichste Fehler des bevorzugten Designs protokolliert, wobei darauf hingewiesen wurde, dass es sich um einen einzelnen Fall aus einer Durchlaufsequenz handelte, um eine Beobachtung und nicht um eine Messung, ohne Grundlage für ein Gesetz.

Das Erneuten Ausführen auf echter Infrastruktur war die richtige Entscheidung. In der durchgeführten Kampagne lehnte das grafisch dargestellte Modell korrekt alle zehn Fragen ab, auf die das große Modell keine Antwort hatte, während auf dem flachen Graphen Falschantworten auftauchten, die auf dieselben Fragen mit „Hagel“ antworteten. Das Modell, die Frage und die Falle waren identisch; nur die Form, die erwischt wurde, unterschied sich.

Die Erkenntnis lautet daher nicht, dass komplexe Graphen zu Falschantworten führen. Eine Ursache-Eigenschaft mit dem Wert „Hagelschaden“ wird jedes Modell, das nach dem Wetter gefragt wird – unabhängig davon, wo es gespeichert ist – verleiten, und welche Form erwischt wird, variiert bei verschiedenen Ausführungen. Das ist eine geringere Behauptung als die, die fast aufgestellt wurde, und es ist das, was die Beweise stützen. Es bedeutet außerdem, dass die Gefahr nicht von der Form abhängt: Wenn ein Graph ein Feld enthält, das wie die Antwort auf etwas aussieht, was es tatsächlich nicht beantwortet, wird irgendein Modell irgendwo darauf antworten.

Die normalisierte Form bei beiden Modellen

Die Normalisierung sank insgesamt bei beiden Modellen. Beim kleineren Modell belegte es den letzten Platz, und beim größeren Modell lag es bei fragbaren Fragen weiterhin bei 0,867, während die Kosten 9,31 Dollar pro Hundert betrugen – fast fünfmal so viel wie beim flachen Graphen desselben Modells – und es verfügte sieben Mal über keine weiteren Anfragen mehr. Auch beim größeren Modell verbessert sich die Leistung nicht, da das Problem nie im Verständnis lag, sondern in der Entfernung: Fünfzehn Toolaufrufe pro Frage im Vergleich zu 8,3 beim „geformten“ Modell, einem Modell, das nie etwas falsch interpretierte.

Die normalisierte Variante verlor nicht überall, und genau diese Ausnahmen lehren am meisten. Bei Abfragen mit einem einzigen Faktor erzielte die normalisierte Variante 0,867 gegenüber 0,533 bei der flachen Variante, und bei den beiden Fragen, bei denen die flache Variante versagte, war die normalisierte Variante eindeutig besser: 0,83 gegenüber 0,17 bei der Prämie für eine Versicherungspolice und 0,83 gegenüber 0,33 bei der Spezialisierung eines Anbieters. Die Reifikation ist äußerst aufwendig, versteckt aber nichts. Jede Entität ist ein Knoten, sodass jede Entität gefunden werden kann.

Das fasst den Argumentationsverlauf zusammen: Jede versagende Variante behielt die Hälfte des Problems bei und warf die andere Hälfte weg. Die flache Variante behielt die Distanz bei, verlor aber die Adressierbarkeit. Die normalisierte Variante behielt die Adressierbarkeit bei, verlor aber die Distanz. Jede Variante konkurriert mit dem, was sie behalten hat, und versagt bei dem anderen Aspekt.

Shaped ist keine Kompromisslösung zwischen den beiden Ansätzen. Er erzielt 0,967 auf der Skala für „flacher“ Vergleich und ebenfalls 0,967 auf der Skala für „normalisierten“ Vergleich, wodurch er diesen Kompromiss ablehnt. Genau darin liegt sein Vorteil – doch eine einzige Gesamtrechnung der Genauigkeit verdeckt ihn vollständig.

Verzögerung gegenüber einer echten Datenbank

Verzögerung ist eine Messgröße, die die Überprüfung nicht unterstützen konnte. Bei Dateien schwankten die Zeiten pro Aufruf bei identischen Durchläufen stark; derselbe Vorgang konnte bei einem Durchlauf 1,17 Sekunden und bei einem anderen 4,21 Sekunden dauern, weshalb keine Angaben gemacht wurden, da die Variabilität des Services die Ontologie überwog. Gegenüber Cosmos ist das Bild geordneter – aus einem leicht entlastenden Grund.

Tabelle 7 zeigt die Zeit pro Frage, die klar zwischen den verschiedenen Formaten unterschieden wird und innerhalb dieser Formate konstant bleibt. Gleichzeitig sind die Zeiten pro Tool-Aufruf bei allen drei Formaten identisch, wodurch die Tabelle letztlich die Anzahl der Tool-Aufrufe in Sekunden darstellt.

In jeder einzelnen Variante beträgt die größte Abweichung sieben Sekunden, während der Unterschied zwischen flacher und normalisierter Variante fast fünfzig Sekunden beträgt. Eine normalisierte Frage dauert zweieinhalbmal so lange wie eine flache. Die letzte Spalte reduziert das Ergebnis: Bei jeder Anfrage kosten alle drei Formen ungefähr gleich viel Zeit, zwischen 6,2 und 7,4 Sekunden, unabhängig vom Schema. Es handelt sich daher um keine unabhängige Erkenntnis. Die Datenbank sorgt für Konsistenz, da eine Cosmos-Rundreise vorhersehbar ist, wo ein lokales Wörterbuch das nicht war – und genau das macht es überhaupt möglich, Zahlen zu berichten.

Daraus folgt eine praktische Konsequenz: Da die Latenz pro Anfrage mehr oder weniger konstant ist, bestimmt die Ontologie-Form-Struktur die Reaktionszeit genauso direkt wie die Kosten für die Token, und diese Werte können bereits vor dem Aufbau durch Zählen der Schritte geschätzt werden.

Prinzipien, jeweils mit ihrer Begründung

Die Abhandlungen zum Entwurf von Ontologien bieten in der Regel Prinzipien als Frage des Geschmacks. Die meisten der unten aufgeführten Prinzipien sind mit der Zahl versehen, die ihnen zugeordnet wurde, und diejenigen, denen diese fehlt, geben das an.

Alles, was befragt werden kann, muss ein Knoten sein. Wenn man ein Prinzip über die Tür meißelt, soll es dieses sein. Der flache Graph speichert jede Versicherungsprämie sowie jede Anbieter-Spezialität, indiziert, in derselben Datenbank wie alles andere, und das kleine Modell fand sie kaum. Prämien wurden zu 17 Prozent der Fälle und Spezialitäten zu 33 Prozent gefunden, während das gesteuerte Modell 100 Prozent bzw. 83 Prozent erzielte. Der gesamte Bereich liegt zwischen 0,533 und 0,967. Das Verstecken einer Entität innerhalb einer Eigenschaft einer anderen Entität macht es nicht schwieriger, sie zu finden. Es sorgt lediglich dafür, dass eine berechtigte Anfrage unter einem anderen Namen zurückkommt, was der Agent als Beweis dafür interpretiert, dass die Entität fehlt. Der Crossover fügt eine Bedingung hinzu, da das Grenzmodell sie alle ausgrub. Das Verbergen ist keine absolute Barriere, sondern lediglich eine „Steuer“, die im Modell-Level gezahlt werden muss.

Die Granularität stellt eine Art Budget dar, und die Reifikation verbraucht es schnell. Jeder für die Schema-Reinheit hinzugefügte Knoten verursacht bei jeder Anfrage Kosten. Im Vergleich zum normalisierten Format benötigte das geformte Format 3,7-mal so viele Toolaufrufe für Suchanfragen mit einem einzigen Faktor, 2,3-mal so viele für kurze Durchgänge sowie viermal so viele Tokens im Bereich der langen Pfade. Zudem wurde in 25 von 120 Episoden die Anzahl der Schritte überschritten, während es beim normalisierten Format nur drei Mal der Fall war. Ein Modell, dessen Kosten pro Eingabetoken 25-mal höher lagen, verbesserte die Leistung bei beantwortbaren Fragen von 0,489 auf 0,867. Das ist zwar eine echte Verbesserung, doch sie kostete 9,31 Dollar pro Hundert Anfragen – fast fünfmal so viel wie der gleiche Modell bei normalen Bedingungen. Distanz ist niemals günstig, unabhängig vom Budget.

Die Eingangspunkte sind die Architektur, und sie stützen sich stark auf das Modell. Jede Frage beginnt mit einem Namen oder einer Zahl, und das Ergebnis des ersten Tool-Aufrufs entscheidet darüber, ob der Agent mit der Arbeit beginnt oder erst raten muss. Beim kleinen Modell war dieser Aufruf in 10 % der gestalteten Episoden, 26 % der flachen Episoden und 53 % der normalisierten Episoden leer – in diesen Fällen führte die Suche zu einem Attribute-Knoten statt zur Entität. Beim Frontier-Modell war der Aufruf hingegen niemals leer, unabhängig von der Form. Somit ist ein verschwendeter Eröffnungszug nicht nur eine Eigenschaft des Graphen – er tritt auf, wenn ein schwächeres Modell auf einen Eingangspunkt stößt, den es nicht erwartet hat. Bauen Sie die Strukturen für das Modell, das in der Produktion eingesetzt wird, und nicht für das, das nur zum Testen verwendet wird.

Denormalisieren Sie absichtlich und geben Sie es zu, wenn die Ausgabe nicht übereinstimmt. Ein abgeleiteter Abkürzungsweg, held_by, wurde unter der Annahme eingesetzt, dass er auf dem Pfad von Anspruch zu Inhaber zum Erfolg führen würde. Dort erzielte er 0,83 gegenüber 0,33 bei der normalisierten Variante, während die einfache Variante ohne Abkürzung bei derselben Frage 0,92 erzielte – daher steht kein Kredit zur Verfügung, und der saubere Test (mit Kantenvergleich versus ohne) wurde nicht durchgeführt. Die fehlende Abkürzung lehrt mehr. Die Zählung der Abdeckungsarten über die Policen der Inhaber erzielte im gut gestalteten Graphen 0,17 und in der einfachen Variante 0,67, wodurch sie in einer lesbaren Eigenschaft zusammengefasst werden. Bei der Aggregation über einen Untergraphen unterlag das vorgeschlagene Design dem als fehlerhaft gekennzeichneten Design. Die Auswahl von Abkürzungen ist Teil des Designs, die Arbeitsbelastung zeigt an, welche benötigt werden – hier wurde die falsche Abkürzung gewählt, und die Daten bestätigten das.

Die Ausbreitung wurde begrenzt. Die Suche wurde auf zwanzig Ergebnisse beschränkt und die Durchquerung auf dreißig, wodurch ein übermäßig vernetzter Knoten zu sichtbaren, zählbaren zusätzlichen Aufrufen führte – anstatt einer einzigen großen Antwort. Es wurden keine unbegrenzten Verarbeitungsschritte ausgeführt, sodass die Ersparnisse unbekannt sind. Was bekannt ist: Ohne solche Beschränkungen versteckt sich die Kostenstruktur in der Größe der Antwort, wo keine Metrik zur Aufrufanzahl vorhanden ist.

Machen Sie Abwesenheit lesbar und bewerten Sie sie ehrlich. Behandeln Sie den unbeantwortbaren Bereich als Designanforderung und nicht als Testtrick, lesen Sie ihn jedoch neben dem beantwortbaren Bereich. Flat erzielte bei Ablehnungen eine perfekte Wertung von 1,000, obwohl es achtzehn Fragen ablehnte, die es hätte beantworten können. Shaped lehnte am wenigsten ab; seine beiden fehlgeschlagenen, unbeantwortbaren Fälle endeten damit, dass es aufgab, anstatt etwas zu erfinden. Eine gute Ontologie ermöglicht es, dass „Wir modellieren das nicht“ sowohl erreichbar als auch wahr ist, und eine Bewertung benötigt beide Aspekte, um einen Graphen, der sich seiner Grenzen bewusst ist, von einem zu unterscheiden, der seine eigenen Inhalte nicht finden kann.

Names sind die API. Der Agent liest die Namen der Ränder genauso wie ein Entwickler eine Funktionssignatur liest, und in diesem Experiment werden Namensgebung und Struktur absichtlich in einer einzigen Variablen namens design zusammengefasst. Keine Zahl stützt dieses Prinzip für sich allein. Die Trennung der beiden ist die offensichtliche nächste Abwandlung, und das klar zu benennen, ist besser, als mehr zu behaupten, als gemessen wurde.

Was das nicht ist

Das ist kein Vergleich von Graph-Datenbanken. Alle drei Ansätze teilen sich ein einziges Cosmos DB-Konto, eine gemeinsame Tool-Schicht sowie dieselben Standard-Einstellungen für die Indizierung. Daher ist der Speicher eine Konstante und keine Variable, und es wird Cosmos weder mit anderen Graph-Datenbanken verglichen noch angepasst. Ebenso wird nicht behauptet, dass allein das Durchlaufen der Struktur der richtige Weg sei, damit Produktionsagenten alles abrufen können – schließlich erfordern unklare Anfragen ohne klaren Eingangspunkt eine Suche. Die Ergebnisse zeigen, wo das einfache Durchlaufen der Struktur sinnvoll ist und wo nicht. Es werden keine Argumente gegen die Normalisierung in transaktionalen Systemen vorgebracht, denn die normalisierte Struktur ist in diesem Fall für diesen Nutzer, einen Agenten, der pro Schritt bezahlt, ungeeignet – nicht jedoch im Allgemeinen. Es handelt sich außerdem nicht um einen Vergleich verschiedener Anbieter: Microsoft Foundry ist die Konstante, nicht die Variable, und die Methode ließe sich auf jede Plattform mit Funktionsaufrufen übertragen.

Würde eine Datenbank im Lauf des Prozesses das Ergebnis verändern? Dafür ist eine Antwort erforderlich, keine Garantie. Vor den durchgeführten Kampagnen wurden die gleichen vier Tools zweimal eingesetzt – einmal über Cosmos und einmal über die von dem Generator erzeugten Dateien – und die aufgezeichneten Toolaufrufe wurden gegen beide Ansätze wiederholt: insgesamt 3.056 unterschiedliche Aufrufe, jeweils für jede einzigartige Kombination aus Tool und Argument, die die Kampagnen erzeugten. Beide Implementierungen gaben in allen Fällen identische Ergebnisse zurück. Die Datenbank spielt weiterhin eine Rolle: Sie verursacht Verzögerungen sowie zusätzliche Anfragen, und Cosmos benötigt im Vergleich zu den auf Dateien basierenden Ansätzen etwa 4 % mehr Agentenschritte, wobei der größte Teil dieser Zusatzbelastung auf dem normalisierten Graphen entfällt. Doch die von dem Agenten erhaltenen Ergebnisse stammten von der Ontologiestruktur und nicht vom darunterliegenden Engine-Teil – und das ist alles, was für den Vergleich notwendig ist. Die Wiederholung der Prozesse liegt als Skript im Repository vor.

Beschränkungen des Instruments

Mehrere Einschränkungen übertragen sich aus der Arbeit mit Routern. Vierzig synthetische Fragen in einem einzigen synthetischen Bereich ergeben ein kleines Instrument. Die Kontraste sind stark, da es sich um Archetypen handelt, und eine Produktionsontologie liegt dazwischen – weshalb gerade die Endpunkte gemessen wurden. Die Kampagne mit dem kleinen Modell wurde dreimal vollständig durchgeführt, und ihr Rauschpegel wird überall angegeben. Das Großmodell-Grid wurde nur einmal durchgeführt, sodass nur seine gesättigten Ergebnisse, nämlich dreißig richtige Antworten bei zwei Formen, zuverlässig sind. Ein Abstand von zwei Fragen innerhalb dieses Grids gilt als Anekdote, und nichts hier wird auf dieser Grundlage argumentiert. Ebenfalls wurden nur ein kleines und ein großes Modell verglichen, wodurch die Kurve zwischen ihnen unermessen bleibt.

Durch die Prüfung des Codes vor der Veröffentlichung wurden zwei Mängel im Instrument aufgedeckt. Erstens: Wenn die angeforderte Kantenart im Graphen nicht vorhanden ist, gibt traverse eine leere Nachbarnliste zurück, die sich nicht von einem Knoten unterscheiden lässt, der tatsächlich keine Nachbarn hat. Der Agent führte im Laufe der Kampagnen 112 solcher Aufrufe durch, und neun der 22 falschen Ablehnungen im normalisierten Graphen enthalten einen solchen Fall; das Analyse-Skript zählt beide mit. Die ermittelte Lücke bleibt bestehen, da shaped die meisten solcher Aufrufe vornahm, aber die wenigsten Anfragen ablehnte. Dennoch stellt ein Tool, das bei „keine solche Kantenart“ mit „Hier ist nichts“ antwortet, eine Verzerrung dar; die ehrlichere Alternative wäre ein Fehler, bei dem die verfügbaren Typen benannt werden. Zweitens: Der verlustfreie Nachweis vergleicht rekonstruierte Fakten, wodurch Kanten, die keine eigenen Fakten enthalten, nicht erkannt werden können – also die Verbindungs-Kanten in flat sowie die abgeleiteten Abkürzungen in shaped. Eine zweite Überprüfung prüft nun diese Kanten anhand der von ihnen wiedergegebenen Fakten und erkennt bei jeder Kante Löschungen sowie falsche Verweise. Die Kampagnen entstanden vor dieser Überprüfung, sodass zu ihrem Laufzeitpunkt keine Garantie vorhanden war.

Die Struktur ist die Systemanweisung

Vielfach wird Aufwand in die Worte investiert, die vor einem Modell platziert werden, während fast kein Aufwand in die Struktur des dahinterliegenden Wissens geht. Für einen toolverwendenden Agenten ist die Ontologie eine Anweisung: Sie beschreibt die vom Weltmodell zulässigen Aktionen, wird in Knotentypen und Kantenbezeichnungen dargestellt und wird Schritt für Schritt bei jeder Toolaufruf verarbeitet. Sie muss für den tatsächlich existierenden Benutzer konzipiert werden.

Die Unterstützungsmaterialien befinden sich im Experimentiercode-Repository: die Faktenbasis, drei Ontologien, ein Beweis für Verlustfreiheit, Fragen, ein Oracle, der Agent sowie jede Kampagnenquittung. Jeder, der dieselbe Wahrheit auf eine vierte Weise modelliert und bei den Fragen, die die anderen Ansätze scheitern ließen, besser abschneidet, würde der Vergleichsmöglichkeit etwas Reales hinzufügen.

Zur Einordnung der verwendeten Komponenten enthält die entsprechende Referenzdokumentation Informationen zu Azure Cosmos DB für Apache Gremlin, der Aufruf von Funktionen mit Microsoft Foundry-Modellen sowie der Azure Retail Prices REST API, die die Preise pro Token lieferte, auf deren Basis die Kostenangaben ermittelt wurden.

Verwandte Artikel

• Ihr erster LangGraph-Agent: Ein Fußball-Assistent mit Tools und Routing — Schritt-für-Schritt-Tutorial zu LangGraph: gemeinsamer Zustand, Tools, ein Planungsknoten, bedingte Kanten sowie eine Zusammenfassung im Markdown-Format, entwickelt um einen simulierten Fußball-Statistik-Assistenten herum.
• Ihr Agent Graph gehört in YAML: Kompilierung eines 17-Agenten-LangGraphs beim Starten — Wie eine kleine Laufzeitumgebung eine YAML-Spezifikation in einen LangGraph StateGraph umwandelt: erzeugter Zustand, importlib-Plugins, Label-Routen, adaptive Aufrufe sowie Node-Austausche pro Sitzung.
• Optimierung eines Terraform Agents mit DSPy: Erstellen Sie zunächst den Verifier, bevor Sie den Optimierer bauen — Terraform Agents erfinden Schemata. Erstellen Sie einen deterministischen Verifier, legen Sie eine Baseline für den Agenten fest und nutzen Sie anschließend DSPy sowie GEPA, um dessen Skill-Datei mit ehrlichen Ergebnissen zu optimieren.
• Warum Merkmalstests für Agenten in die Irre führen und wie man anhand eigener Daten bewerten kann — Offizielle Merkmalstests für das Gedächtnis haben fehlerhafte Lösungsschlüssel und Bewertungskriterien. Trennen Sie die Informationsabrufung von den Antworten, fügen Sie Überprüfungen auf Konsistenz, Aktualität, Enthaltung und Vergessen hinzu sowie einen Kostenverfolger.