Daten-zu-Intelligence-Architektur
Von Rohdaten zu agentengesteuerten Entscheidungen – erfasst über Adapter, Zero-Copy-Federation und Datensammler; gespeichert in SQL und MPP; abstrahiert in Ereignisse, Profile, Metriken und Beziehungen; anschließend verbunden über eine Ontologie für den KI-Agenten.
Warum die vier Ebenen für einen KI-Agenten wichtig sind
Ein Agent ist nur so gut wie der Kontext, über den er argumentiert. Durch die Trennung von Aufnahme, Rohspeicherung, Abstraktion und Ontologie erhält das Modell auf jeder Ebene eine saubere, kontrollierte und verbundene Schnittstelle – sodass seine Entscheidungen fundiert, erklärbar und kostengünstig weiterentwickelt werden können.
Der Agent liest den Kontext, nicht die Rohdaten.
Jede Ebene stellt dem Agenten eine stabile Schnittstelle bereit – Ereignisse, Profile, verwaltete Metriken und eine verbundene Ontologie. Er analysiert den Kontext anstatt Rohdatensätze zum Zeitpunkt der Inferenz zu parsen und zu verknüpfen, was seine Antworten reproduzierbar macht.
Quellunabhängige Datenerfassung
Da die Datenerfassung eine eigene Ebene darstellt, ist das Modell unabhängig davon, wie ein System verbunden ist. Fügen Sie einen Adapter hinzu, integrieren Sie ein bestehendes Data Warehouse oder nutzen Sie die offene Schnittstelle API – alle oben genannten Systeme verwenden dieselben Daten, sodass neue Datenquellen Ihre Eingabeaufforderungen oder Logik nicht beeinträchtigen.
Eine einheitliche Plattform
Die SQL- und MPP-Speicher bleiben durch Änderungsdatenerfassung synchronisiert, sodass der Kontext des Agenten auf einer einzigen, unverfälschten Datenbasis beruht und nicht auf voneinander abweichenden Kopien. Operative Lesevorgänge und umfangreiche analytische Scans greifen auf dieselben Datensätze zu.
Geregelte Geschäftswahrheit
Metriken haben eine eindeutige Definition in einer semantischen Schicht. Die Zahlen, mit denen ein Agent arbeitet, entsprechen also den Zahlen, die Ihre Dashboards anzeigen. Entscheidungen bleiben nachvollziehbar und auditierbar, anstatt auf Ad-hoc-Aggregationen zu basieren.
Explizite, nachvollziehbare Beziehungen.
Die Ontologie verknüpft Absicht, Profil und Geschäftswert, sodass eine Empfehlung exakt auf den Kontext zurückgeführt werden kann, aus dem sie erstellt wurde – die Beziehungen sind im Modell enthalten und müssen nicht bei jedem Anruf vom Agenten neu abgeleitet werden.
Sicher für die Weiterentwicklung
Tauschen Sie Modelle aus, fügen Sie Datenquellen hinzu oder ändern Sie den Speicher hinter stabilen Layer-Verträgen. Der Agent nutzt weiterhin dieselben Abstraktionen, sodass sich die darüberliegende Intelligenz ohne grundlegende Überarbeitung weiterentwickelt.
Von Rohdaten zu einer vernetzten Ontologie
Jede Ebene bietet der darüberliegenden eine sauberere, besser kontrollierte Schnittstelle – Datenerfassung, Rohdatenspeicherung, Abstraktion und schließlich die Ontologie, auf der die KI arbeitet. So entwickelt sich die Intelligenz der oberen Ebene weiter, ohne dass die darunterliegende Ebene neu geschrieben werden muss.
Datenerfassungsschicht
Daten aus Unternehmenssystemen mit hoher Leistung und Offenheit erfassen.
Diese Ebene erkunden →Adapter der Enterprise-Klasse
Vorgefertigte Adapter für gängige Unternehmenssysteme – CDP, CRM, ERP, OMS und Commerce.
Zero-Copy-Technologie
Fragen Sie große Lagerdaten vor Ort ab – keine Datenkopie (Snowflake, Databricks, Data Cloud, Delta Sharing).
Datenverfolgungssammler
Umfassendes Web- und App-Event-Tracking und Verhaltensanalyse über SDK.
Offene Daten API / SDK
Standardisierte APIs und SDKs für jede benutzerdefinierte Quelle.
Rohdatenschicht
Rohdaten erfassen und in SQL- und MPP-Datenbanken mit Echtzeit-CDC-Synchronisierung speichern.
Diese Ebene erkunden →SQL-Datenbank
Strukturierter Shop für Transaktionen und Vorgänge.
MPP-Datenbank
Massiv parallele Verarbeitung für groß angelegte Analysen.
Datenabstraktions- und -analyseschicht
Rohdaten in aussagekräftige Modelle und Erkenntnisse abstrahieren.
Diese Ebene erkunden →Benutzerprofil & Tagging
Rohdaten werden in Mitglieds-Tags abstrahiert und Benutzerprofile erstellt.
Ereignismodell und Absichtserkennung
Abstrahieren Sie das Rohverhalten in Ereignismodelle und leiten Sie die Nutzerabsicht ab.
Metrikextraktion und Geschäftswahrheit
Aus Rohdaten relevante Kennzahlen extrahieren und die geschäftliche Wahrheit aufdecken.
Beziehung & Affinität
Abstrahieren Sie Empfehlungen und Bestellungen in einem Mitgliederbeziehungsdiagramm – mit realen, konvertierten Verbindungen, Hubs und wahrscheinlichen Haushalten.
Affinität & Ähnlichkeit
Statistische Ähnlichkeit anhand realer Daten modellieren – gemeinsame Produktkäufe, Kategorieaffinität und Lookalike-Mitglieder.
Ontologie-Aktionsschicht
Verknüpfen Sie Absicht, Profil und Geschäft über das Benutzerentitätsmodell und ermöglichen Sie agentengesteuerte Entscheidungen.
Diese Ebene erkunden →Wie aus einer einzelnen Aktion eine Entscheidung wird
Die Schichten sind in Bewegung leichter zu erkennen. Hier ist ein Einzelhandelssignal, das alle vier durchläuft – vom einfachen Klick bis zur nächstbesten Aktion eines Agenten.
Die Aktionen eines Käufers treffen ein
Ein Mitglied sieht sich dieselbe Jacke dreimal an, legt sie in den Warenkorb und verlässt die Seite, ohne sie zu kaufen. Diese Aufrufe und Warenkorb-Ereignisse werden über den Tracking-Collector erfasst, zusammen mit der Bestellhistorie aus den verbundenen Handels- und CRM-Systemen.
Alles kommt als ungeschminkte Wahrheit an
Ereignisse und Datensätze werden gleichzeitig als Rohdaten in die SQL- und MPP-Speicher geschrieben und durch Änderungsdatenerfassung synchronisiert. Dadurch stehen dieselben Daten sowohl für operative Abfragen als auch für umfassende Analysen zur Verfügung.
Rohdaten werden aussagekräftig
Das Ereignismodell interpretiert „wiederholte Ansicht + Warenkorb, kein Kauf“ als Signal für hohe Kaufabsicht; Tags kennzeichnen sie als auslaufendes, wertvolles Mitglied; die Metrikschicht kennt bereits ihren Kundenwert und ihre Einlösungsrate – jeweils eine festgelegte Definition.
Der Agent entscheidet
Die Ontologie verknüpft ihre Absicht, ihr Profil und ihren Wert zu einem zusammenhängenden Bild. Der Agent analysiert diesen Kontext und entscheidet über eine personalisierte Rückgewinnung mit einem begrenzten Anreiz – und die Entscheidung lässt sich auf die exakten zugrunde liegenden Signale zurückführen.
Wo man es anschließen kann
Sie entwickeln auf der Basis der Schichten, nicht der Infrastruktur. Jede der folgenden Oberflächen ist einer stabilen Schnittstelle mit eigener Dokumentation zugeordnet – wählen Sie Ihren Arbeitsbeginn.
Verbinden Sie Ihre Systeme
Bringen Sie Daten über Produktadapter, Zero-Copy-Föderation oder die offene Datenschnittstelle ein – keine maßgeschneiderten Pipes.
Integrationsleitfaden →Web- und App-Verhalten verfolgen
Seitenaufrufe, Produktaufrufe, Such- und Warenkorbereignisse mit dem Collector SDK am Interaktionspunkt erfassen.
Web-Tracking →Lesen Sie verwaltete Metriken und Profile.
Fragen Sie die semantische Metrikebene und die Mitgliederprofile über die Tools API und MCP ab – überall gelten die gleichen Definitionen.
MCP & Kennzahlen →Modell erweitern
Stellen Sie benutzerdefinierte Quellen über das offene API bereit, abonnieren Sie ausgehende Webhooks und modellieren Sie benutzerdefinierte Objekte.
API Referenz →Die Fragen, die die Architektur bestimmen
Wenn wir Ihre semantische Schicht und Ontologie standardisieren, wie vermeiden wir dann eine Abhängigkeit von einem bestimmten Anbieter?
Die Ebenen sind Verträge, keine Blackbox. Ihre Rohdaten bleiben in Standard-SQL- und MPP-Speichern – oder per Zero-Copy in Ihrem eigenen Warehouse, wo wir Sie nie zum Kopieren verpflichten – und Ihre Metrik-, Tag- und Identitätsdefinitionen sind deklarativ, versioniert und in einer von Ihnen festgelegten Form exportierbar. Sie behalten die Daten und Definitionen; Die Abstraktion basiert auf offenen Speichern, anstatt sie in einem proprietären Format einzufangen.
Wo werden unsere Daten physisch gespeichert und was genau überschreitet die Grenze bei Zero-Copy-Federation?
Bei föderierten Datenquellen wird die Abfrage an Ihr Data Warehouse – Snowflake, Databricks, Salesforce Data Cloud oder Delta Sharing – weitergeleitet und dort unter den von Ihnen festgelegten Zugangsdaten eingelesen. Die Rohdatentabellen werden niemals in unseren Speicher dupliziert, sodass Ihr Data Warehouse das führende System bleibt und dessen Speicherort- und Zugriffskontrollen weiterhin gelten. Was Ihren Bereich verlässt, ist das Ergebnis der eingeschränkten Abfrage, nicht die zugrunde liegenden Tabellen. Eingelesene Datenquellen landen in einem mandantenisolierten Speicher, und der Einwilligungs- und Datenschutzstatus wird versioniert, sodass regulierte Daten gemäß Richtlinien und nicht ad hoc verarbeitet werden.
Wer legt die Bedeutung einer Kennzahl fest und wie wird dies für Tausende von Nutzern geregelt?
Metrikdefinitionen befinden sich in einer zentralen semantischen Ebene und sind nicht über Dashboards und Notebooks verstreut. Jede Definition hat einen Verantwortlichen; zertifizierte Metriken erfordern dessen Freigabe; Änderungen werden geprüft und versioniert, ein Audit-Trail wird erstellt und der zugehörige Cache ungültig gemacht, sodass veraltete Werte nicht bestehen bleiben. Dadurch wird das Problem „gleicher KPI, drei verschiedene Ergebnisse“ im gesamten Unternehmen vermieden.
Wie werden unsere Daten von anderen Mandanten isoliert, und wie groß ist der Wirkungsradius eines einzelnen Fehlers?
Der Mandantenbereich wird im Datenpfad erzwungen und nicht dem Anwendungscode überlassen, einen Filter zu speichern. Der Zugriff auf Metriken und Profile erfolgt schreibgeschützt auf mandantenbezogene Vertragsansichten – eine Sicherheitsbarriere, die vor jeder Abfrage nach Mandant filtert. So kann selbst eine benutzerdefinierte Abfrage nicht auf die Daten anderer Mandanten oder die Rohdatentabellen zugreifen. Da die Isolation eine Eigenschaft des Abfragepfads und nicht der jeweiligen Entwicklerdisziplin ist, wird ein Anwendungsfehler nicht mandantenübergreifend sichtbar.
Wie können wir Aktionen des Agenten protokollieren und einschränken?
Jede Agentenaktion basiert auf den kontrollierten Abstraktionen und der Ontologie. So lässt sich eine Entscheidung exakt auf die zugrunde liegende Absicht, das Profil und den verwendeten Metrikkontext zurückführen – nicht auf eine undurchsichtige Eingabeaufforderung. Die Schreibvorgänge eines Agenten sind durch serverseitige Sicherheitsvorkehrungen und Ratenbegrenzungen eingeschränkt. Fehlerhafte Aktionen wie Anreize oder Ausgaben erfordern eine manuelle Genehmigung, und jede Aktion wird zu Prüfungszwecken protokolliert. Der Agent analysiert Ihre festgelegten Fakten und bleibt überprüfbar, anstatt auf Basis eines nicht rekonstruierbaren Kontextes zu handeln.
Warum ist eine mehrschichtige Architektur über fünf Jahre hinweg kostengünstiger als unsere Warehouse-plus-Punktlösungen?
Die wiederkehrenden Kosten eines Warehouse-Plus-Tool-Stacks entstehen durch Integration und Datenabgleich: Jede neue Datenquelle erfordert eine individuelle Schnittstelle, jedes Tool definiert Metriken und Identitäten neu, und Ihr Team muss die Diskrepanz zwischen ihnen bewältigen. Die Trennung von Datenerfassung, Speicherung, Abstraktion und Ontologie bedeutet, dass eine Datenquelle nur einmal verbunden, eine Metrik nur einmal definiert und eine Identität nur einmal aufgelöst wird – alles darüber liegende nutzt diese Daten wieder. Sie tauschen eine wachsende Vielzahl fehleranfälliger Integrationen und widersprüchlicher Definitionen gegen eine einheitliche Basis und einen Satz festgelegter Definitionen.
Entwickeln Sie auf Basis vernetzter Kontexte, nicht auf Basis von Rohdaten.
Datenerfassung über Adapter, Zero-Copy-Federation, Tracking-Collector und eine offene API/SDK; Speicherung der Rohdaten in einem CDC-synchronisierten SQL- und MPP-Speicher; Abstraktion in Ereignismodelle, Zeitachsen, Profile und Metriken; anschließende Verknüpfung über das Benutzerentitätsmodell, sodass der Agent Entscheidungen anhand des verbundenen Kontexts trifft.
Verwandte Themen: die Plattformschleife und Web-Tracking SDK.