TL;DR
KI-Agents brauchen ein strukturiertes Gedächtnis, das Zusammenhänge zwischen Kunden, Aufträgen, Produkten und Prozessen versteht. Die erste Generation von RAG basierte auf Vektor-Suche - gut für Textähnlichkeit, aber blind für Beziehungen. Knowledge Graphs sind die nächste Stufe: eine semantische Schicht über den bestehenden Systemen, die dem Agent echtes Kontextwissen gibt. Einmal aufgebaut, lassen sich beliebig viele Use Cases darauf aufsetzen.
Inhalt
- Wie hat sich RAG weiterentwickelt?
- Was genau ist Agent Memory?
- Was ist eine Ontologie - und warum ist sie wichtig?
- Was passiert, wenn Agents kein strukturiertes Gedächtnis haben?
- Wie baut man Agent Memory auf?
- Wo liegt der langfristige Hebel?
- Häufige Fragen
Wie hat sich RAG weiterentwickelt?
Kurz: RAG ist nicht gescheitert - es entwickelt sich weiter. Die erste Generation war rein vektorbasiert. Heute umfasst Retrieval auch Graphen, strukturierte Abfragen und Websuche.
Retrieval Augmented Generation war ein wichtiger Durchbruch: Statt ein LLM nur mit seinem Trainingskorpus arbeiten zu lassen, gibt man ihm zur Laufzeit relevanten Kontext aus externen Quellen mit. Die erste Welle war fast ausschliesslich vektorbasiert - Dokumente werden in Embeddings umgewandelt, in einer Vektordatenbank gespeichert, und über semantische Ähnlichkeit abgerufen.
Das funktioniert erstaunlich gut, solange die Aufgabe textbasiert ist: “Finde den Abschnitt in unserer Dokumentation, der am besten zu dieser Frage passt.” Für einen Support-Chatbot oder eine interne Wissenssuche reicht das oft.
Aber Retrieval ist ein breiterer Begriff als Vektor-Suche. RAG bedeutet: dem Model zur Laufzeit die richtigen Informationen geben. Die Quelle kann eine Vektordatenbank sein - oder eine Websuche, eine SQL-Abfrage gegen das ERP, ein API-Call an das CRM, oder eben eine Traversierung durch einen Knowledge Graph.
Graph RAG ist auch RAG. Der Unterschied liegt nicht im Prinzip, sondern in der Art des Retrievals. Und diese Art macht einen erheblichen Unterschied, sobald die Aufgabe über “finde einen ähnlichen Text” hinausgeht.
Ein konkretes Beispiel: Ein Agent soll prüfen, ob ein eingehender Auftrag vollständig ist. Per Vektor-Suche kann er vielleicht ähnliche Aufträge finden. Aber er muss wissen: Ist dieser Kunde freigeschaltet? Hat er offene Rechnungen? Ist das referenzierte Produkt in dieser Konfiguration lieferbar? Wer ist der zuständige Key Account Manager? Das sind keine Textähnlichkeits-Fragen - das sind Beziehungsfragen.
Was genau ist Agent Memory?
Kurz: Ein Knowledge Graph, der als strukturiertes Gedächtnis für KI-Agents dient - nicht nur Inhalte, sondern Entitäten und ihre Beziehungen zueinander abbildet.
Agent Memory basiert auf einer Graphendatenbank, typischerweise Neo4j oder vergleichbare Systeme. Das Grundprinzip: Es gibt Knoten (Entities wie Kunden, Aufträge, Produkte, Mitarbeiter) und Kanten (Beziehungen wie “hat bestellt”, “wird betreut von”, “gehört zu Projekt”).
Das klingt nach dem, was eine relationale Datenbank auch kann. Der Unterschied liegt in der Flexibilität und der Art, wie Abfragen funktionieren.
In einer relationalen Datenbank definiere ich Tabellen mit festen Spalten und verbinde sie über Foreign Keys. Wenn ich eine neue Art von Beziehung abbilden will - etwa “Mitarbeiter X hat an Projekt Y das Review gemacht” - brauche ich eine neue Tabelle oder zumindest eine Schemaänderung. Und Abfragen über mehrere Beziehungsstufen hinweg (von Kunde zu Auftrag zu Auftragsposition zu Produkt zu Lieferant) werden schnell komplex und langsam.
Im Knowledge Graph ist eine neue Beziehung einfach eine neue Kante. Und die Traversierung - “gib mir alles, was mit diesem Kunden zusammenhängt, bis drei Ebenen tief” - ist genau das, wofür Graphdatenbanken optimiert sind.
Für einen Agent bedeutet das: Er kann Fragen beantworten, die mehrere Systeme und Beziehungen betreffen, ohne dass jemand vorher genau definieren musste, welche Joins dafür nötig sind. Er navigiert den Graphen so, wie ein erfahrener Mitarbeiter sein Wissen über das Unternehmen abruft - assoziativ, kontextbezogen, über Zusammenhänge.
Was ist eine Ontologie - und warum ist sie wichtig?
Kurz: Die Ontologie definiert, welche Arten von Dingen es im Unternehmen gibt und wie sie zusammenhängen - sie ist die Landkarte, nach der der Knowledge Graph aufgebaut wird.
In der Praxis heisst Ontologie: Welche Entitätstypen gibt es bei uns? Kunde, Auftrag, Produkt, Mitarbeiter, Standort, Projekt. Welche Beziehungstypen gibt es? “Kunde hat Auftrag”, “Auftrag enthält Position”, “Position referenziert Produkt”, “Mitarbeiter betreut Kunde”.
Das klingt trivial, aber die meisten Unternehmen haben das nie explizit gemacht. Jedes System hat sein eigenes implizites Datenmodell. Im ERP heisst es “Debitor”, im CRM “Account”, in der Projektmanagement-Software “Client” - und alle meinen denselben Kunden, aber keines der Systeme weiss das.
Die Ontologie macht diese impliziten Modelle explizit. Sie ist die gemeinsame Sprache, die sagt: “Ein Kunde ist ein Kunde, egal ob das ERP ihn Debitor nennt.” In der Informatik nennt man das eine kanonische Repräsentation.
Praktisch bedeutet das: Wenn ein Agent im Knowledge Graph nach dem Kunden “Müller GmbH” sucht, findet er alles - Aufträge aus dem ERP, Kontakthistorie aus dem CRM, Projektdaten aus dem PM-Tool, Supporttickets aus dem Helpdesk. Nicht weil all diese Systeme verbunden sind, sondern weil der Graph weiss, dass es sich um dieselbe Entität handelt.
Die Ontologie muss nicht am ersten Tag perfekt sein. In der Praxis starten wir mit den zentralen Entitäten - Kunden, Aufträge, Produkte - und erweitern iterativ. Der Graph ist flexibel genug, um neue Entitätstypen und Beziehungen aufzunehmen, ohne dass man alles umbauen muss.
Was passiert, wenn Agents kein strukturiertes Gedächtnis haben?
Kurz: Ohne strukturiertes Memory machen Agents Annahmen, verlieren Kontext und produzieren Ergebnisse, die auf dem Papier gut aussehen, aber in der Realität nicht halten.
Wir sehen das in Projekten immer wieder. Ein paar typische Szenarien:
Doppelarbeit und Widersprüche. Zwei Agents arbeiten am selben Kunden - einer bearbeitet ein Angebot, ein anderer eine Supportanfrage. Ohne gemeinsames Memory weiss keiner vom anderen. Der Supportagent empfiehlt ein Workaround, während der Vertriebsagent gerade eine Lösung anbietet, die das Problem beheben würde. Das Ergebnis: Beim Kunden kommt ein inkonsistentes Bild an.
Kontextverlust über Prozessgrenzen. Ein Agent nimmt einen Auftrag entgegen und gibt ihn an die Produktion weiter. Aber er kann nicht mitgeben, dass der Kunde beim letzten Mal eine Reklamation hatte und diesmal explizit auf Qualitätskontrolle Wert legt. Diese Information existiert - im CRM-Notizfeld, in einer E-Mail, vielleicht im Kopf des Account Managers. Aber der Agent hat keinen Zugriff darauf, weil sie in keinem strukturierten Format vorliegt.
Halluzinierte Zusammenhänge. Ohne klare Datenstruktur beginnt ein LLM, Zusammenhänge zu inferieren, die nicht existieren. “Kunde A hat vermutlich Interesse an Produkt X, weil ähnliche Kunden das bestellt haben.” Das kann stimmen, muss aber nicht. Und wenn die Grundlage eine Vektorsuche über unstrukturierte Dokumente ist, gibt es keine Möglichkeit, das zu verifizieren. Im Knowledge Graph hingegen lässt sich jede Aussage auf ihre Quelle zurückverfolgen.
Skalierungsprobleme. Der erste Chatbot funktioniert. Also baut man den zweiten. Und den dritten. Jeder hat seine eigene Wissensbasis, seine eigenen Dokumente, seine eigene Vektor-Datenbank. Nach sechs Monaten hat man fünf isolierte Systeme, die sich gegenseitig nicht kennen und teilweise widersprüchliche Informationen enthalten.
Wie baut man Agent Memory auf?
Kurz: Ontologie definieren, bestehende Daten als semantische Schicht abbilden, Agents schrittweise anbinden - ohne die Quellsysteme zu ersetzen.
Die Ontologie erarbeiten
Der erste Schritt ist nicht technisch, sondern konzeptionell: Wie fliesst Arbeit durch unser Unternehmen? Das lässt sich in ein paar fokussierten Workshops klären. Wir schauen uns an, welche Entitäten es gibt, welche Beziehungen bestehen, und welche Attribute relevant sind.
KI kann diesen Prozess beschleunigen. Man gibt einem Model Beispielaufträge, E-Mails, Projektdokumentation, und es schlägt Entitätstypen und Beziehungen vor. Das ersetzt nicht die Fachexpertise, gibt aber einen schnellen ersten Entwurf, den man mit den richtigen Leuten validieren kann.
Den Knowledge Graph als semantische Schicht aufbauen
Ein kritischer Punkt: Der Knowledge Graph ersetzt nicht ERP, CRM oder andere Systeme. Er ist eine semantische Schicht darüber - ein maschinenlesbares Modell des Unternehmens, das die Konzepte aus verschiedenen Systemen verbindet.
Daten fliessen aus den Quellsystemen in den Graphen - entweder per Sync, per Event oder per Batch-Import. Die Quellsysteme bleiben die “Source of Truth” für ihre jeweiligen Domänen. Der Graph wird zur “Source of Context” - er weiss, wie die Dinge zusammenhängen.
Das bedeutet auch, dass nicht jedes Datenfeld im Graphen sein muss. Die Rechnungsadresse bleibt im ERP. Im Graph steht nur: “Kunde A hat Adresse B”, mit einem Verweis auf das ERP für die Details. Weniger ist hier mehr.
Agents schrittweise anbinden
Der dritte Schritt ist, Agents gegen den Graphen arbeiten zu lassen. Das passiert am besten inkrementell: Erst ein Use Case, z.B. Auftragserfassung. Der Agent lernt, den Graphen zu traversieren, fehlende Informationen zu identifizieren und gezielt nachzufragen.
Wenn das läuft, kommt der nächste Use Case dazu - Account Management, Reporting, Projektsteuerung. Jeder neue Agent profitiert von dem, was schon im Graphen ist, und reichert ihn gleichzeitig an.
Wo liegt der langfristige Hebel?
Kurz: Die Ontologie eines Unternehmens ändert sich selten. Technologien ändern sich ständig. Wer in die Datenstruktur investiert, macht sich unabhängig vom nächsten Technologiesprung.
Viele Unternehmen investieren gerade in spezifische KI-Tools: einen Chatbot hier, eine Automatisierung dort. Das bringt kurzfristig Ergebnisse, aber es entsteht keine Grundlage, auf der man aufbauen kann.
Der Knowledge Graph dreht das um. Er ist die stabile Schicht, auf der sich alles andere bewegt. Models werden besser - der Graph bleibt. Neue Agent-Frameworks kommen - der Graph bleibt. Die Art, wie Agents arbeiten, wird sich in den nächsten zwei Jahren massiv verändern. Die Frage, wie ein Unternehmen strukturiert ist, wird sich nicht ändern.
In der Praxis heisst das: Der Aufwand für den ersten Use Case ist am grössten, weil die Ontologie definiert und der Graph initial befüllt werden muss. Der zweite Use Case geht schneller. Ab dem dritten amortisiert sich die Investition, weil die Grundstruktur steht und neue Agents einfach andocken.
Das ist der fundamentale Unterschied zu einem Ansatz, bei dem man für jeden Use Case eine eigene Lösung baut. Statt fünf isolierter Projekte hat man ein System, das mit jedem neuen Agent wertvoller wird.
Häufige Fragen
Muss ich dafür mein ERP ersetzen?
Nein. Der Knowledge Graph arbeitet als semantische Schicht über den bestehenden Systemen. ERP, CRM und andere Tools bleiben die führenden Systeme für ihre jeweilige Domäne. Der Graph verbindet sie, ersetzt sie aber nicht. Daten fliessen per Sync oder Event in den Graphen - und bei Bedarf auch zurück.
Wie aufwendig ist der initiale Aufbau?
Überschaubarer als die meisten erwarten. Die Ontologie lässt sich in wenigen Workshops erarbeiten. Das Befüllen der Daten kann KI-gestützt passieren - ein Model extrahiert Entitäten und Beziehungen aus bestehenden Datenquellen. Der eigentliche Aufwand ist nicht technisch, sondern inhaltlich: einmal die Frage beantworten, wie Arbeit durch das Unternehmen fliesst.
Was ist der Unterschied zwischen einem Knowledge Graph und einer Wissensdatenbank?
Eine Wissensdatenbank (z.B. ein Confluence oder eine Sammlung von Dokumenten in einer Vektordatenbank) speichert Inhalte. Ein Knowledge Graph speichert Entitäten und Beziehungen. Der Unterschied: Aus einer Wissensdatenbank bekomme ich Textabschnitte, die semantisch ähnlich zu meiner Frage sind. Aus einem Knowledge Graph bekomme ich strukturierte Antworten - “Kunde A hat drei offene Aufträge, der grösste ist Auftrag B mit 12 Positionen, betreut von Mitarbeiter C.”
Kann ich nicht einfach mit einem Chatbot anfangen?
Kann man, und für einen klar abgegrenzten Use Case ist das auch sinnvoll. Das Problem entsteht bei der Skalierung. Jeder Chatbot braucht seine eigene Wissensbasis, die gepflegt werden muss. Ab dem zweiten oder dritten Use Case hat man redundante Daten, inkonsistente Antworten und einen wachsenden Wartungsaufwand. Der Knowledge Graph vermeidet das, indem er eine gemeinsame Grundlage für alle Agents schafft.
Brauche ich dafür spezielle Infrastruktur?
Graph-Datenbanken wie Neo4j laufen in der Cloud oder On-Premise. Der Ressourcenbedarf ist moderat - für die meisten Mittelständler reicht eine einzelne Instanz. Die grössere Frage ist nicht die Infrastruktur, sondern die Datenmodellierung: Wer definiert die Ontologie, wer pflegt die Datenflüsse, wer stellt die Qualität sicher?
Fazit
Agent Memory ist die Grundlage, wenn KI im Unternehmen über einen einzelnen Chatbot hinausgehen soll. Der Knowledge Graph als semantische Schicht über den bestehenden Systemen gibt Agents das Kontextwissen, das sie brauchen, um in komplexen Geschäftsprozessen sinnvoll zu arbeiten. Der erste Schritt ist nicht die Technologie, sondern die Frage: Welche Entitäten gibt es bei uns, wie hängen sie zusammen, und wie fliesst Arbeit durch unser Unternehmen?
Wenn Sie wissen wollen, wie ein Agent Memory in Ihrem Unternehmen aussehen könnte, sprechen wir gerne darüber.
Basierend auf einer Folge des SNKI-Podcasts “KI im B2B” mit Manuel Zorzi und Michael Kirchberger: Jetzt anhoren →