Ein Blick auf OpenAIs internen Datenagenten

• OpenAI hat einen maßgeschneiderten KI-Datenagenten selbst entwickelt, um mehr als 3.500 interne Nutzer und 600 PB an Daten effizient zu analysieren
• Nur mit natürlichsprachlichen Fragen automatisiert er End-to-End-Analyse-Workflows von der Tabellenerkundung über die SQL-Ausführung bis zur Veröffentlichung von Notebooks und Reports
• Er sichert die Genauigkeit, indem er 6 Kontextebenen kombiniert: Tabellennutzung, menschliche Annotationen, Codex-basierte Codeanalyse, Organisationswissen, Memory und Runtime-Kontext
• Er arbeitet mit einer selbstlernenden Closed-Loop-Struktur, die bei fehlerhaften Zwischenergebnissen selbst die Ursache untersucht und den Ansatz anpasst
• Ein systematisches Evaluierungssystem auf Basis der Evals API erkennt Qualitätsregressionen frühzeitig und übernimmt gleichzeitig das bestehende Sicherheits- und Berechtigungsmodell zur Wahrung der Zuverlässigkeit

---

Warum ein maßgeschneiderter Datenagent nötig ist

• OpenAIs Datenplattform umfasst mehr als 3.500 interne Nutzer, 600 Petabyte an Daten und über 70.000 Datensätze; allein das Finden der richtigen Tabelle ist in der Analyse oft die zeitaufwendigste Aufgabe
• Es gibt viele ähnliche Tabellen, wodurch es schwierig ist, Unterschiede zwischen Tabellen zu erkennen, etwa ob ausgeloggte Nutzer enthalten sind oder ob Felder doppelt vorkommen
• Selbst wenn die richtige Tabelle gewählt wird, können Many-to-many-Joins, Fehler beim Filter-Pushdown oder nicht behandelte null-Werte die Ergebnisse ungültig machen
• Analysten sollten sich auf Metrikdefinitionen, Hypothesenprüfung und datenbasierte Entscheidungen konzentrieren statt auf SQL-Debugging

Wie der Agent arbeitet

• Läuft auf Basis von GPT-5.2
• Zugänglich in Umgebungen, die Mitarbeitende bereits nutzen, darunter Slack-Agent, Weboberfläche, IDE, Codex CLI (mit MCP-Integration) und die interne ChatGPT-App
• Kann auch komplexe und offene Fragen verarbeiten
  • Verständnis der Frage
  • Datenerkundung
  • SQL-Ausführung
  • End-to-End-Ausführung bis zur Analyse und Zusammenfassung der Ergebnisse
  • Beispiel: Analyse der Kombinationen mit der größten Schwankung der Fahrzeit zwischen Abhol- und Ziel-ZIP-Code-Paaren im NYC-Taxi-Datensatz
• Folgt keinen starren Skripten, sondern bewertet seinen eigenen Fortschritt; wenn Zwischenergebnisse fehlerhaft sind, etwa 0 Zeilen durch falsche Joins oder Filter, untersucht er die Ursache, passt den Ansatz an und versucht es erneut
• Deckt den gesamten Analyse-Workflow ab: Datenfindung, SQL-Ausführung, Veröffentlichung von Notebooks und Reports, Verweis auf internes Wissen, Websuche und Memory-basiertes Lernen

Kontextschichten

• Layer 1: Tabellennutzung (Table Usage)

  • Metadata Grounding: Nutzt Schema-Metadaten wie Spaltennamen und Datentypen zum Schreiben von SQL und versteht mit Table Lineage die Beziehungen zwischen Tabellen, also Ober- und Untertabellen
  • Query Inference: Sammelt frühere Queries, damit der Agent lernt, wie Queries formuliert werden und welche Tabellen typischerweise gemeinsam gejoint werden

• Layer 2: Menschliche Annotationen (Human Annotations)

  • Domain-Experten verfassen kuratierte Beschreibungen für Tabellen und Spalten und erfassen damit Absicht, Semantik, geschäftlichen Kontext und bekannte Hinweise, also Informationen, die sich schwer aus Schema oder früheren Queries ableiten lassen
  • Da Tabellen allein anhand von Metadaten oft schwer zu unterscheiden sind, ist ein Verständnis ihrer Entstehung und Herkunft essenziell

• Layer 3: Codex-basierte Codeanalyse (Codex Enrichment)

  • Leitet Definitionen auf Code-Ebene der Tabellen ab, um den tatsächlichen Inhalt der Daten tiefgehend zu verstehen
    • Liefert Nuancen auf Basis von Analyseereignissen, etwa Einzigartigkeit von Werten, Aktualisierungsfrequenz der Tabellendaten oder Datenumfang, z. B. ob bestimmte Felder ausgeschlossen sind und wie fein die Granularität ist
  • Kann neben SQL auch Nutzungskontexte in verschiedenen Datensystemen wie Spark und Python erfassen
  • Kann Tabellen unterscheiden, die ähnlich aussehen, aber in einem entscheidenden Punkt verschieden sind, etwa ob eine Tabelle nur 1st-party-ChatGPT-Traffic enthält
  • Dieser Kontext wird automatisch aktualisiert, sodass keine manuelle Pflege nötig ist

• Layer 4: Organisationswissen (Institutional Knowledge)

  • Sammelt Unternehmenskontext aus Slack, Google Docs, Notion usw., darunter Launches, Störungsfälle, interne Codenamen sowie formale Definitionen und Berechnungslogiken zentraler Metriken
  • Dokumente werden erfasst, eingebettet und zusammen mit Metadaten und Berechtigungen gespeichert; ein Retrieval-Service verarbeitet zur Laufzeit Zugriffskontrolle und Caching

• Layer 5: Memory

  • Wenn der Agent Korrekturen erhält oder Nuancen einer Datenfrage entdeckt, speichert er diese, damit die nächste Analyse mit einer genaueren Baseline beginnt
  • Das Ziel von Memory ist, nicht offensichtliche Korrekturen, Filter und Constraints zu bewahren und wiederzuverwenden, die sich aus anderen Schichten nur schwer ableiten lassen
    • Beispiel: Beim Filtern eines bestimmten Analyseexperiments war ein spezifischer String-Match nötig, der am Experiment-Gate definiert war; ohne Memory trat der Fehler auf, fuzzy String Matching zu versuchen
  • Wenn Korrekturen oder Lernerkenntnisse entstehen, regt der Agent das Speichern in Memory an; Nutzer können Einträge auch manuell erstellen und bearbeiten
  • Der Geltungsbereich von Memory ist in globale und persönliche Ebene unterteilt

• Layer 6: Runtime-Kontext (Runtime Context)

  • Wenn es keinen Vorabkontext zu einer Tabelle gibt oder Informationen veraltet sind, sendet der Agent Live-Queries an das Data Warehouse, um das Schema zu validieren und Echtzeitdaten zu erfassen
  • Er kommuniziert auch mit anderen Systemen der Data Platform wie Metadatenservices, Airflow und Spark, um Datenkontext außerhalb des Warehouses zu erhalten

• Tägliche Offline-Pipeline und RAG

  • Es gibt eine tägliche Offline-Pipeline, die Informationen aus Tabellennutzung, menschlichen Annotationen und Codex-basierter Anreicherung in einer einzigen normalisierten Darstellung zusammenführt
  • Der angereicherte Kontext wird mit der OpenAI Embeddings API in Embeddings umgewandelt und gespeichert; bei Queries wird per RAG (Retrieval-Augmented Generation) nur relevanter Kontext abgerufen
  • So bleibt das Tabellenverständnis über Zehntausende Tabellen hinweg schnell und skalierbar, während die Runtime-Latenz vorhersagbar und niedrig bleibt

Eine Architektur, die wie ein Teammitglied denkt und zusammenarbeitet

• Unterstützt interaktive, iterative Erkundung statt einmaliger Antworten und behält vollständigen Kontext über mehrere Turns hinweg, sodass bei Rückfragen oder Richtungswechseln nicht alles von vorn erklärt werden muss
• Wenn der Agent in die falsche Richtung läuft, kann der Nutzer während der Analyse eingreifen und umleiten
• Sind Anweisungen unklar, stellt er proaktiv Rückfragen zur Präzisierung; bleibt eine Antwort aus, arbeitet er mit sinnvollen Standardwerten weiter, etwa den letzten 7 oder 30 Tagen
• Nachdem wiederkehrende Muster derselben Analyse beobachtet wurden, werden wiederholte Analysen als wiederverwendbare Workflows (instruction set) paketiert
  • Beispiele sind wöchentliche Business-Reports oder Tabellenvalidierung
  • Kontext und Best Practices werden einmal kodiert, um konsistente Ergebnisse über verschiedene Nutzer hinweg sicherzustellen

Evaluierungssystem für schnelle Verbesserungen bei stabilem Vertrauen

• Da der Agent sich ständig weiterentwickelt, kann Qualitätsdrift leicht auftreten; ohne systematische Evaluierung bleiben Regressionen unsichtbar
• Auf Basis der OpenAI Evals API wird ein kuratierter Satz aus Frage-Antwort-Paaren aufgebaut, wobei jeder Frage eine manuell erstellte „Golden“-SQL-Query zugeordnet wird
• Natürlichsprachliche Fragen werden an den Endpoint zur Query-Generierung gesendet, die erzeugte SQL wird ausgeführt und anschließend mit den erwarteten SQL-Ergebnissen verglichen
• Statt einfachem String-Matching werden sowohl SQL als auch Ergebnisdaten verglichen und in den Evals-Grader eingespeist, um Endscore und Begründung zu erzeugen, die Genauigkeit und zulässige Abweichungen berücksichtigen
• Diese Evaluierung dient während der Entwicklung als Unit Test und in Produktion als Canary, um Regressionen früh zu erkennen

Sicherheit des Agenten

• Ist direkt an OpenAIs bestehendes Sicherheits- und Zugriffskontrollmodell angebunden und übernimmt dieselben Berechtigungen und Guardrails auf der Interface-Ebene
• Sämtliche Zugriffe erfolgen als Pass-through-Modell: Nutzer können nur Tabellen abfragen, für die sie bereits Berechtigung haben; fehlt diese, informiert der Agent darüber oder fällt auf alternative Datensätze zurück
• Zur Transparenz legt er seinen Denkprozess offen: Annahmen und Ausführungsschritte werden zusammen mit der Antwort zusammengefasst, und die Rohresultate der ausgeführten Queries sind direkt verlinkt, sodass Nutzer jeden Analyseschritt prüfen können

Erkenntnisse aus dem Aufbau

• Lektion 1: Weniger ist mehr (Less is More)

  • Anfangs wurde dem Agenten das gesamte Toolset offengelegt, was jedoch zu Verwirrung durch Funktionsüberschneidungen führte
  • Was für Menschen bei manuellen Aufrufen nützliche Redundanz ist, erzeugt für den Agenten Mehrdeutigkeit; daher wurden bestimmte Tool-Aufrufe eingeschränkt und konsolidiert, was die Zuverlässigkeit verbessert hat

• Lektion 2: Das Ziel führen, nicht den Pfad (Guide the Goal, Not the Path)

  • Zu stark instruktionales Prompting verschlechterte die Ergebnisse eher
  • Da sich die Details je nach Frage unterscheiden, führen starre Anweisungen den Agenten leicht auf den falschen Weg; besser ist hochgradige Guidance, während GPT-5 die Wahl des Ausführungspfads überlassen wird

• Lektion 3: Bedeutung steckt im Code (Meaning Lives in Code)

  • Schema und Query-Historie beschreiben nur Form und Nutzung einer Tabelle; die eigentliche Bedeutung liegt im Code, der die Tabelle erzeugt
  • Pipeline-Logik erfasst Annahmen, Frischegarantien und geschäftliche Intentionen, die in SQL oder Metadaten nicht sichtbar sind
  • Indem mit Codex die Codebasis gecrawlt wird, um zu verstehen, wie ein Datensatz tatsächlich aufgebaut ist, lassen sich „was ist enthalten?“ und „wann kann es verwendet werden?“ präzise beantworten, was allein mit Warehouse-Signalen nicht möglich wäre

Ausblick

• OpenAI arbeitet weiter daran, den Umgang mit mehrdeutigen Fragen zu verbessern, Zuverlässigkeit und Genauigkeit durch stärkere Verifikation zu steigern und die Workflow-Integration zu vertiefen
• Ziel ist keine separate Anwendung, sondern eine Form, die sich natürlich in bestehende Arbeitsweisen einfügt
• Mit Fortschritten bei Agenten-Reasoning, Verifikation und Selbstkorrektur entwickelt sich das System weiter,
  und die Mission des Teams ist es, im gesamten OpenAI-Datenökosystem schnelle und verlässliche Datenanalyse nahtlos bereitzustellen