Sie arbeiten in einem Unternehmen und nutzen einen KI-Assistenten mit Zugriff auf alle internen Dokumente. Sie fragen nach Kundenabwanderung. Der Assistent gibt eine kluge Antwort – Zahlen, Zusammenhänge, eine flüssige Erklärung. Doch wenn Sie nach der Quelle fragen, wird es vage. Der Assistent zitiert Passagen, aber gehören sie wirklich zusammen? Stammen sie aus demselben Bericht oder aus verschiedenen Kontexten? Dieses Gefühl der Unsicherheit ist kein Zufall. Viele Unternehmen erleben das mit KI-Agenten: plausible Antworten, aber keinen verlässlichen, nachvollziehbaren Kontext. Genau hier setzt eine Überlegung an, die über typische RAG-Ansätze hinausgeht.
Wenn der Agent Fakten vermischt
Amarnath Byakod beschreibt in seinem Artikel „Context Engineering and Knowledge Cataloging for AI Agents“ ein Experiment. Sein Team ließ einen Agenten aus klinischen Dokumenten Informationen abrufen. Das System fand semantisch ähnliche Textstellen und setzte sie zu einer Antwort zusammen. Auf den ersten Blick sah alles gut aus. Bei genauerer Prüfung zeigte sich: Der Agent hatte Daten von verschiedenen Patienten zu einem einzigen, erfundenen klinischen Profil vermischt. Die Antwort war sprachlich korrekt, aber fachlich falsch. Byakod zieht eine klare Schlussfolgerung: „Das ist kein Retrieval-Problem. Es ist ein Knowledge-Catalog-Problem.“ Es bringt wenig, wenn ein Agent beliebige Textfragmente findet, solange er nicht versteht, was sie bedeuten, wie sie zusammenhängen und ob sie gemeinsam verwendet werden dürfen.
Dieses Problem betrifft nicht nur die Medizin. Es ist relevant, wo immer Unternehmen KI-Agenten zur Entscheidungsunterstützung einsetzen: Finanzanalyse, Kundenbetreuung, Supply-Chain-Planung. Die meisten Initiativen beginnen mit dem Zugang. Teams verbinden den Agenten mit SharePoint, Confluence, Datenbanken oder APIs. Sie fügen Embeddings und Retrieval hinzu und testen, ob der Agent Fragen beantworten kann. Oft entsteht der Eindruck, der Agent verstehe das Unternehmen. In Wirklichkeit sind Zugang und Verständnis zwei verschiedene Dinge. Ein Agent muss wissen, welche Informationen zusammengehören, welche Quelle eine Tatsache belegt, welches Datenprodukt einen Geschäftsfall unterstützt und welche Begriffe eine vereinbarte Bedeutung haben. Auch Qualitätserwartungen, Service-Level, Zugriffsmethoden und Governance-Einschränkungen sind nötig. Das geht über reines Retrieval hinaus. Es betrifft die Struktur und den Kontext von Datenprodukten.
Stellen Sie sich vor, Sie suchen in einer Bibliothek nach Informationen zum Thema „Kundenbindung“. Ein klassischer Retrieval-Ansatz wäre ein Bibliothekar, der Ihnen die relevantesten Seiten aus verschiedenen Büchern bringt – ohne zu sagen, ob sie aus demselben Buch stammen, ob sie aktuell sind oder wer sie geschrieben hat. Sie erhalten viele Fragmente, aber keinen roten Faden. Was Sie brauchen, ist ein kuratiertes Dossier: genau die Informationen, die für Ihre Fragestellung relevant sind, mit klarer Herkunft, Zusammenhängen zwischen den Fakten und Hinweisen, unter welchen Bedingungen Sie sie verwenden dürfen. Genau das meint Byakod mit „Knowledge Cataloging“. Es geht nicht darum, mehr Daten abzurufen, sondern den richtigen Kontext zu kompilieren.
Ein Wissensmodell, viele Repräsentationen
Byakod schlägt eine Architektur vor, in der ein einziger Extraktionsprozess mehrere parallele Repräsentationen desselben Wissens erzeugt. Ein Graph unterstützt die Navigation über Beziehungen. Ein kompilierter Markdown-Wiki gibt dem Sprachmodell dichten, verbundenen Kontext. Ein portables Open-Knowledge-Format-Bündel ermöglicht lokale oder Offline-Nutzung. Eine Query-Engine wählt dann die Repräsentation aus, die am besten zur Frage passt. Dieses Prinzip lässt sich direkt auf Datenprodukte übertragen. Ein Datenprodukt – eine bereitgestellte, qualitätsgesicherte Dateneinheit für einen bestimmten Zweck – kann verschiedene Ansichten haben: eine grafische für das Portfoliomanagement, eine maschinenlesbare für die Plattform, eine vertragliche für die Governance und eine komprimierte für den Agenten. Wichtig ist nicht, alle Konsumenten in ein Format zu zwingen. Wichtig ist, ein einziges, gemanagtes Modell zu pflegen und dann die Repräsentation zu kompilieren, die jeder Anwendungsfall benötigt.
Eine der stärksten Empfehlungen in Byakods Artikel lautet: „Kompiliere Kontext, retriev ihn nicht nur.“ Dieses Prinzip sollte direkten Einfluss darauf haben, wie Agenten Datenprodukte konsumieren. Ein Agent, der das Kundenbindungsrisiko bewerten soll, sollte nicht den gesamten Unternehmenskatalog oder fünfzig Fragmente erhalten, die zufällig „Kundenabwanderung“ erwähnen. Er sollte ein vorbereitetes Kontextpaket bekommen: genau die Produkte, Definitionen, Beziehungen und Betriebsbedingungen, die für diese Aufgabe relevant sind. Dieses Paket könnte das Geschäftsziel, die Kennzahl, den genehmigten Anwendungsfall, die unterstützenden Produkte, die erforderlichen Qualitätsbedingungen, die verfügbaren Zugangsdienste und das im Unternehmen verwendete Vokabular umfassen. Auch Produktabhängigkeiten, Quellennachweise, erlaubte Zwecke und die aktuelle Produktversion sollten enthalten sein.
Maysano Studio als Kontext-Compiler
In der Praxis setzt Maysano Portfolio Studio dieses Modell bereits um. Das Studio beginnt mit Quelldokumenten – Strategieberichten, Präsentationen oder Tabellen – und extrahiert daraus Geschäftsziele, Signale, Anwendungsfälle und Datenproduktbedarfe. Diese werden in einem verbundenen Portfoliomodell organisiert. Die Quelldokumente bleiben am Portfolio haften, sodass der ursprüngliche Beleg stets in der Nähe des daraus erstellten Kontexts liegt. Das ist ein entscheidender Unterschied zu einem typischen Retrieval-Setup. Das System behandelt Quelldateien nicht als lose Sammlung von Textfragmenten, sondern wandelt sie in explizite Geschäftsobjekte um. Ein Ziel wird zu einem definierten Knoten. Ein Signal wird zu einem definierten Knoten. Ein Anwendungsfall wird zu einem definierten Knoten. Ein Datenprodukt wird zu einem definierten Knoten. Diese Objekte sind nicht isoliert gespeichert. Ihre Beziehungen erscheinen in einem Graphen, der zeigt, wie Geschäftsabsicht, Belege, Anwendungsfälle und Produktbedarfe miteinander verbunden sind. Jeder Knoten hat auch eine strukturierte YAML-Repräsentation. Dadurch hat dasselbe Portfolio mehrere nützliche Formen gleichzeitig. Geschäftsanwender sehen ein reichhaltiges, verständliches Portfolio. Der Graph offenbart die Beziehungen. Das YAML gibt Plattformen, Entwicklern und Agenten eine maschinenlesbare Definition. Das Quelldokument, das Geschäftsobjekt, die Graphbeziehung und der YAML-Knoten – sie alle beschreiben denselben zugrunde liegenden Kontext aus unterschiedlichen Perspektiven.
Das Studio fungiert als Business-Context-Compiler für Datenprodukte. Es bereitet den Kontext vor, bevor ein Agent ihn benötigt. Die Quelldokumente erklären, woher das Wissen stammt. Die Portfolio-Objekte erklären, was dieses Wissen bedeutet. Der Graph erklärt, wie die Objekte zusammenhängen. Das YAML bietet die Struktur, die Software und KI-Agenten benötigen. Das Data Product SDK kann diesen Kontext dann validieren, verpacken, traversieren, transformieren und über Schnittstellen wie ODPC, ODPG, ODPS, Sidecars, Workflows und Agenten-Interfaces verfügbar machen. Zusammen bilden Studio und SDK zwei Schichten desselben Systems: Das Studio ist die Business-Entwicklungs- und Portfolio-Bildungsschicht; das SDK ist die technische und operative Schicht, die dieses Modell in spezifikationskonforme, portierbare Kontextpakete für Agenten verwandelt.
Herkunft und drei Wissensebenen
Ein weiterer wichtiger Punkt ist die Herkunft der Informationen. Byakod stellt die Provenienz ins Zentrum der Architektur. Extrahierte Entitäten verweisen auf exakte Stellen im Quellmaterial. Das System überprüft diese Verweise unabhängig, anstatt der Ausgabe des Sprachmodells zu vertrauen. Dieses Prinzip ist auch für die Generierung von Datenproduktdefinitionen aus Geschäftsdokumenten entscheidend. Wenn das System ein Geschäftsziel, einen Produktbedarf, eine Kennzahl, einen Konsumenten, eine Einschränkung oder eine Beziehung extrahiert, sollte es den Beleg hinter dieser Extraktion bewahren. Eine Aussage wie „Das Kundenrisikoprodukt unterstützt das Ziel der Abwanderungsreduzierung“ sollte auf die Seite, die Folie, die Tabellenzelle oder den Textabschnitt verweisen, der diese Aussage stützt. Maysano Portfolio Studio hält die Quelldokumente bereits am Portfolio fest. Der nächste Schritt ist, diese Beziehung auf Knotenebene zu vertiefen: Jedes Ziel, jedes Signal, jeder Anwendungsfall und jedes Produkt sollte direkte Verweise auf den exakten Quellennachweis enthalten, aus dem es erstellt wurde.
Das System sollte außerdem drei Informationsebenen trennen. Die erste Ebene ist der Quellennachweis – also das, was das Originaldokument aussagt. Die zweite Ebene ist die maschinelle Interpretation – also das, was der Extraktionsprozess aus diesem Nachweis abgeleitet hat. Die dritte Ebene ist das genehmigte Portfoliowissen – also das, was ein Mensch in das aktive Modell übernommen hat. Diese Trennung verhindert, dass generierte Spezifikationen von ihrem Quellmaterial losgelöst werden. Ohne sie sehen Prüfer eine polierte Produktbeschreibung, können aber nicht feststellen, welche Teile direkt aus Belegen stammen, welche aus Interpretationen und welche während der Prüfung hinzugefügt wurden. Quellengestützte Generierung würde Portfolioentscheidungen leichter erklärbar, anfechtbar und prüfbar machen.
Schema-Validierung allein reicht nicht. Das Data Product SDK validiert bereits die Struktur von Spezifikationen, aber strukturelle Gültigkeit beweist nicht, dass der generierte Inhalt korrekt ist. Eine Produktdefinition kann perfekt dem ODPS-Schema entsprechen und trotzdem ein nicht unterstütztes Ziel, einen erfundenen Konsumenten oder eine falsche Beziehung enthalten. Die Datei ist technisch valide, aber das Produktwissen darin ist unzuverlässig. Byakod bietet hier einen wichtigen Hinweis: Das Sprachmodell schlägt Entitäten und Beziehungen vor, aber deterministischer Code überprüft, ob der Quellennachweis existiert. Das Modell assistiert bei der Interpretation, es fungiert nicht als letzte Autorität. Dasselbe Prinzip sollte auch für die Arbeit mit Maysano Portfolio Studio und dem Data Product SDK gelten. Das Sprachmodell kann bei der Extraktion und Zusammenfassung helfen, aber die finale Verantwortung für die Korrektheit liegt beim Menschen und bei nachvollziehbaren Belegen.
Was bedeutet das konkret für Unternehmen, die KI-Agenten einführen wollen? Der Fokus sollte nicht auf besseren Retrieval-Methoden liegen – nicht auf größeren Vektordatenbanken oder ausgefeilteren Embeddings. Der Fokus sollte auf der Strukturierung und Katalogisierung des Wissens liegen – auf der Schaffung von Datenprodukten mit klarem Kontext, klaren Beziehungen und klarer Herkunft. Ein KI-Agent, der auf solche Datenprodukte zugreift, kann nicht nur Texte abrufen, sondern auch verstehen, was sie bedeuten, wofür sie gelten und woher sie kommen. Er wird zu einem verlässlichen Werkzeug, statt zu einer Blackbox, die eloquent, aber unzuverlässig antwortet. Die Zukunft der Unternehmens-KI liegt nicht im Retrieval, sondern im Context Engineering. Dieser Kontext muss aus Datenprodukten kommen – nicht aus loser Textsammlung. Das ist der Schritt, um KI-Agenten von Demonstrationsobjekten zu ernsthaften Arbeitshilfen zu machen.
Quelle: blog.opendataproducts.org
