Ihr KI-Analyst braucht ein Gehirn, keinen Vector Store

Fragen Sie eine neue Analystin, was sie in den ersten Monaten wirklich bremst, und sie wird nicht SQL sagen - sie wird Konventionen sagen. Welche Benchmark für welches Mandat gilt, und die zwei Mandate, bei denen die naheliegende Antwort falsch ist. Warum Vergleiche vor 2024 die _hist-Tabellen brauchen, weil die Migration in jenem Jahr die Schlüsselung der Positionen geändert hat. Die Tatsache, dass der ESG-Provider auf SEDOL schlüsselt und das Warehouse auf ISIN - und dass vierzehn Namen still aus jedem Join verschwinden, der die Bridge-Tabelle vergisst.

Nichts davon steht irgendwo Brauchbares geschrieben. Es lebt in den Köpfen der zwei dienstältesten Leute am Desk, in Chat-Verläufen, die niemand durchsuchen kann, und am Rand von Präsentationen, die zweimal ersetzt wurden. Es ist das Wissen, das Analysen korrekt macht - und sobald ein KI-Agent Analysen erstellt, ist die Frage, ob er dieses Wissen hält, kein Nice-to-have mehr, sondern der Unterschied zwischen einer Antwort und einem Vorfall.

Die Standardantwort der Branche ist Retrieval-Augmented Generation: Dokumente einbetten, per Ähnlichkeit suchen, die nächstgelegenen Chunks in den Kontext stopfen. Wir haben etwas anderes gebaut, und dieser Artikel ist das Argument dafür. Die Kurzfassung: Institutionelles Wissen ist strukturell, und Ähnlichkeitssuche ist strukturblind.

Warum Ähnlichkeitssuche strukturiertes Wissen verliert

Hier ist eine reale Form von Wissen aus der Welt unserer Demo-Szenarien - der kanonische Join für As-of-Preise und der Caveat, der ihn korrekt macht:

1SELECT h.*, p.close2FROM holdings h3ASOF JOIN prices p4ON p.isin = h.isin AND p.ts <= h.ts5-- never p.ts = h.ts: look-ahead bias.6-- promoted to house standard after the Q1 incident.

Das SQL ist die leichte Hälfte. Die tragende Hälfte ist alles, was daran hängt: Dieses Muster gilt für Backtests und jede Analyse, die Preise mit Beständen verknüpft; es wurde validiert vom Desk-Head nach einem Vorfall; es beschränkt eine bestimmte Klasse von Queries; und das <= ist keine Stilfrage, sondern der ganze Punkt. Nun der Fehlerfall: Ein Embedding-Memory, nach dem Verknüpfen von Preisen gefragt, findet das SQL bereitwillig - es ist der Frage sehr ähnlich - und lässt den Caveat ebenso bereitwillig weg, weil der in einem anderen Chunk mit einem anderen Embedding lebt und nichts Strukturelles sagt: diese zwei sind untrennbar. Der Agent schreibt einen sauber aussehenden Join mit = statt <=, der Backtest schaut still in die Zukunft, und der Fehler ist unsichtbar - gerade weil alles Gefundene "relevant" war.

Ähnlichkeit sagt Ihnen, was verwandt klingt. Sie kann nicht sagen, was gilt, was dazugehört oder was ersetzt wurde - denn das sind Kanten, keine Distanzen.

Ein Wissensgraph, kein Dokumentenstapel

DataQubes Memory ist ein Graph. Definitionen, Beispiel-Queries, Caveats, Entscheidungen und Skills sind typisierte Knoten, verknüpft mit den Workspaces, für die sie gelten, den Datenquellen, die sie beschreiben, und den Tools, die sie beschränken. Auch die Kanten sind typisiert - gilt-für, caveats, abgeleitet-aus, ersetzt - und ein einzelnes Knotenpaar kann mehrere zugleich tragen: Der Look-Ahead-Caveat oben ist gleichzeitig über die Preisquelle und eine Beschränkung des Join-Musters - genau deshalb kann kein Abruf dieses Musters ohne ihn ankommen.

Recall ist dann eine Graph-Traversierung, keine Nächste-Nachbarn-Suche. Wenn ein Agent in einem Workspace zu arbeiten beginnt, zieht er die Nachbarschaft: die dort geltenden Definitionen, die Caveats an jeder Quelle und jedem Tool, das er gleich berührt, die Skills aus früherer validierter Arbeit. Der Preis-Caveat wird nicht abgerufen, weil er der Frage ähnelt - er wird abgerufen, weil er an der Sache hängt, die benutzt wird. Ähnlichkeit ist optional; Verknüpfung nicht.

Wissen, das weiß, wann es falsch ist

Speichern war nie der schwere Teil. Der schwere Teil - und, so würden wir argumentieren, das eigentliche Produkt - ist die Invalidierung. Institutionelles Wissen veraltet ohne Fahrplan: Eine Definition ändert sich nach einem Vorfall, eine Datenquelle wird umgeschlüsselt, eine Konvention wird von einem Komitee gekippt, das niemandem Bescheid sagt.

So spielt sich das in DataQube ab, am Vorfall, auf dem unser Demo-Szenario beruht. Ein Pricing-Snapshot-Problem zwingt den Desk, seine Definition der aktiven Rendite zu ändern. In dem Moment, in dem die neue Definition validiert ist, wird die alte ersetzt: Sie wird sofort nirgendwo mehr abgerufen, ohne Cache, der altern müsste. Aber sie wird nicht gelöscht - sie bleibt im Graphen, verknüpft mit ihrem Nachfolger, gestempelt mit dem Zeitpunkt, an dem sie aufhörte, wahr zu sein. Diese letzte Eigenschaft macht das System auditierbar statt bloß aktuell: Prüft jemand eine Analyse von vor der Änderung, zeigt das Protokoll, dass sie unter der damals gültigen Definition entstand - der Unterschied zwischen "die Analyse war falsch" und "die Definition änderte sich später", eine Unterscheidung, die Auditoren sehr wichtig nehmen.

Die Eingangstür zählt so viel wie der Ausgang. Kandidaten aus Gesprächen - "der Agent hat bemerkt, dass der Desk Seed-Anteilsklassen immer ausschließt" - kommen quarantänisiert an: sichtbar, zuordenbar und nie abgerufen, bis ein Mensch sie validiert. Nichts, was der Agent gefolgert hat, kann still zu etwas werden, worauf der Agent sich stützt. Die Validierung selbst ist ein Event im Protokoll: Wer dieses Wissen freigegeben hat, wann, aus welchem Gespräch es stammt. Hausstandards tragen ihre ganze Kette.

Die verworfene Alternative ist die verführerischste: das System kontinuierlich lernen lassen und darauf vertrauen, dass gutes Wissen schlechtes verdrängt. In einem Consumer-Produkt eine vertretbare Wette. In einem regulierten bedeutet sie: Die Überzeugungen Ihres Agenten sind ein unauditiertes, selbstmodifizierendes Eingangssignal für jede Zahl, die er produziert - und wenn eine falsche Folgerung zum ersten Mal ein Quartal an Antworten kontaminiert, können Sie weder sagen, wann sie ankam, noch, was sie berührt hat.

Wie Recall in einem echten Lauf aussieht

Hier ist der volle Kreislauf im Produkt - validiertes Wissen kommt an, bevor die erste Query läuft, und ein neuer Kandidat geht am Ende in Quarantäne:

Lauf wiederholen

Auf Basis realer Kundengespräche — alle Daten fiktiv.

Beachten Sie die Form des Abgerufenen: keine Dokumente, die der Frage ähneln, sondern die Definitionen dieses Workspace und die Caveats an den Quellen, die dieser Lauf gleich benutzt. Und beachten Sie, was hinausgeht: ein Kandidat, klar als validierungsbedürftig markiert, der künftigen Abrufen fernbleibt, bis jemand mit der nötigen Befugnis ihn freigibt.

Der Ein-Fragen-Test

Wenn Sie Agenten-Memory evaluieren, fragen Sie den Anbieter dies: Wenn sich eine Definition ändert - zeigen Sie mir, was mit der alten passiert, und zeigen Sie mir, was Ihr System für eine Analyse mit Datum vor der Änderung liefert. Ein Ähnlichkeitsspeicher hat keine gute Antwort; alte und neue Chunks koexistieren, und der Abruf entscheidet nach Ähnlichkeits- und Aktualitätsheuristiken. Ein Graph mit Supersession-Semantik antwortet präzise: die neue Definition überall ab dem Moment der Validierung, die alte erhalten mit ihrem Gültigkeitsfenster - für jeden, der die Vergangenheit prüft.

Ein Memory-System ohne Supersession-Semantik sammelt kein Wissen. Es sammelt Verbindlichkeiten - flüssig, selbstbewusst und zunehmend falsch. Wie das Memory-Modul in den Rest der Plattform greift, steht auf der Produktseite - und wenn Sie den Quarantäne-Ablauf live sehen wollen, buchen Sie eine Demo und bringen Sie dem Agenten etwas Falsches bei. Dann sehen Sie zu, wie es folgenlos bleibt.