Wenn du eine Software entwickelst und Dutzende Ansätze ausprobierst, hast du nach Stunden die beste Lösung – aber die Zwischenschritte sind nur in deinem Kopf oder in verstreuten Notizen. Experience Graphs speichern diese Erfahrungsstruktur in einer durchsuchbaren, wiederherstellbaren und gemeinsam nutzbaren Form. Sie sind das Datenfundament für KI-Agenten, die iterativ nach besseren Lösungen suchen.
Gang Liao und Kollegen von der University of Maryland und Meta schlagen mit Trellis eine Datenbank-Architektur vor, die diesen Experience Graph speichert. Bisher behandeln Agenten-Frameworks diese Daten als flüchtigen Zustand: JSON-Checkpoints und Sitzungslogs, die nach einem Absturz verloren sind. Trellis lagert den Experience Graph in eine Datenbank aus und macht frühere Probleme zu Abfragen.
Jeder Schritt wird zum Knoten
Agenten für Codegenerierung, wissenschaftliche Entdeckungen oder Hardware-Optimierung arbeiten nicht mit einem Durchlauf. Sie explorieren: Sie erzeugen Artefakte, führen Werkzeuge aus, beobachten Fehler, verzweigen, reparieren und vergleichen Alternativen. Jeder Schritt erzeugt einen Knoten im Experience Graph: das Prompt, das Artefakt, die Tool-Ausgaben, eine Bewertung, die Verbindung zum Elternknoten und zu Geschwistern. Dieser Graph ist ein kausaler Baum von Versuchen, kein bloßes Wissen.
Die Autoren kritisieren die übliche Einteilung in deklaratives, prozedurales und episodisches Gedächtnis. Sie erfasst nicht den Experience Graph, der entsteht, wenn ein Agent über viele Sessions sucht. Produktionssysteme wie Metas KernelEvolve haben die Schmerzgrenze erreicht: Fortschritt ging bei Abstürzen verloren, parallele Arbeiter brauchten ad-hoc-Koordination, frühere Entdeckungen ließen sich nicht wiederverwenden. Die Lösung: die Datenbasis ändern.
Eine Architektur aus zwei Schleifen
Die Autoren schlagen eine Zwei-Schleifen-Architektur vor. In der inneren Schleife arbeiten Agenten als zustandslose, serverlose Funktionen – sie erhalten eine Aufgabe, generieren einen Knoten, evaluieren und terminieren. Die äußere Schleife entscheidet anhand einer Suchstrategie (gierig, MCTS, evolutionär), welcher Knoten als nächstes expandiert wird. Der Graph liegt persistent in Trellis, einer Datenbank für diese Zugriffsmuster: Anhängen von Knoten, Aktualisieren von Pfaden, Vektor-Ähnlichkeitssuche für Wiederverwendung und Zeitreise-Abfragen.
Die Vorteile: Crash Recovery wird trivial, da der Graph in der Datenbank gespeichert ist. Zweitens: Wiederverwendung über Sessions hinweg – ein Agent kann den Graph ähnlicher Suchen durchsuchen, per Vektor-Embedding vielversprechende Teilbäume identifizieren und als Startpunkt nutzen. Drittens: Datenextraktion für Training – der Graph liefert alle Knoten mit hohem Reward per Datenbank-Abfrage. Viertens: Horizontale Skalierung – zustandslose Agenten lassen sich parallel laufen lassen, die Datenbank übernimmt die Konsistenz.
Messbare Vorteile und Grenzen
In einer kontrollierten Studie mit KernelEvolve erreichten die Agenten mit Trellis eine Zielbeschleunigung etwa 10-mal schneller, bei 52 % niedrigeren Token-Kosten pro gültiger Lösung. Allerdings zeigte sich ein Exploration-Anker-Effekt: zu starker Fokus auf bisherige Lösungen kann die Exploration neuer Regionen beeinträchtigen. Der Trade-off muss bewusst gesteuert werden.
Die Autoren argumentieren, dass Experience Graphs eine ähnliche Transformation auslösen könnten wie Logs für Datenbanken. Früher waren Logs flüchtige Dateien – heute sind sie zuverlässig, durchsuchbar und wiederherstellbar. Genauso könnten Experience Graphs zu einem dauerhaften Vermögenswert werden. Wenn jeder KI-Agent seine Sucherfahrungen in einer gemeinsamen Datenbank ablegt, entsteht ein kumulativer Wissensschatz.
Offene Fragen für die Forschung
Trellis ist kein ausgereiftes Produkt, sondern eine Systemarchitektur, die viele Forschungsfragen aufwirft: Wie plant man Abfragen über multimodale Daten? Wie hält man Konsistenz bei parallelen Suchstrategien? Wie gestaltet man das physische Layout für typische Zugriffsmuster? Wie bildet man bi-temporale Aspekte ab? Das sind offene Probleme – sie zeigen, dass die Datenbank-Community hier eine entscheidende Rolle spielen kann.
Die nächste Generation von KI-Werkzeugen braucht nicht nur bessere Modelle, sondern auch klügere Datenhaltung. Statt jeden Agenten wie eine Einweg-Applikation zu behandeln, versteht man die Suche als Datenbank-Problem. Experience Graphs sind kein akademisches Konzept – sie ermöglichen selbstverbessernde Agenten. Wie ein Spalier das Wachstum einer Pflanze lenkt, ohne selbst zu wachsen, gibt diese Datenbasis den Agenten Halt, weiterzukommen.
Quelle: arxiv.org
