Ein Blick auf OpenAIs internen Datenagenten

 (openai.com)
13 Punkte von GN⁺ 2026-02-13 | 1 Kommentare | Auf WhatsApp teilen
  • 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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-13
Hacker-News-Kommentare

  • Zuverlässigkeit und Erklärbarkeit sind das größte Problem
    Wir entwickeln bei Veezoo seit 10 Jahren Natural-Language-Analytics, aber ein einfacher Text-to-SQL-Ansatz skaliert nicht gut
    Wenn der CFO nach dem Umsatz fragt, ist eine Zahl, die nur zu 99 % stimmt, bedeutungslos, und der CFO kann das SQL auch nicht selbst validieren
    Deshalb haben wir mit dem Knowledge Graph eine Abstraktionsschicht eingeführt, in der die KI natürliche Sprache in eine semantische Abfragesprache umwandelt und diese dann deterministisch zu SQL kompiliert
    Umgekehrt wird diese semantische Abfrage wieder in eine natürlichsprachliche Erklärung umgewandelt, damit Nutzer leicht prüfen können, ob das Ergebnis ihrer Absicht entspricht
    Die Business-Logik existiert im Knowledge Graph, und der Compiler stellt sicher, dass alle Abfragen ihr zu 100 % folgen
    Die genaue Struktur ist in der Veezoo-Architekturdokumentation beschrieben

    • Danke fürs Teilen des Links. Der Architekturüberblick war sehr aufschlussreich
      Ich frage mich, wie ihr Kardinalitätsexplosionen handhabt und wie ihr Multi-Query-Anfragen verarbeitet, die von den Ergebnissen vorheriger Queries abhängen
    • Braucht das generierte SQL-Artefakt trotzdem nicht Versionsverwaltung und Unit-Tests?
      Man sollte nachverfolgen können, welche Query an welchem Datum verwendet wurde und wie sie validiert wurde
      (Natürlich sollten auch Prompts versioniert werden)

  • Ich war überrascht, dass das erste Beispiel völlig unlogisch ist
    Wenn das durch menschliche Prüfung gegangen ist, wurde es vermutlich von einer KI erstellt, und das wirft Fragen zur Zuverlässigkeit des Systems auf
    Link zum problematischen Bild

  • Nach meiner Erfahrung mit mehreren BI-Systemen ist so ein KI-Agent eigentlich ein perfekter Use Case
    BI ist von Natur aus auf mehreren Ebenen fehleranfällig — die Query selbst kann falsch sein oder die Daten werden falsch interpretiert
    Wenn beides zusammenkommt, lebt man ohnehin schon in einer „fiktiven Welt“, also ist es besser, wenn die KI wenigstens Schritt 1 übernimmt
    Ich hatte gehofft, dass OpenAI das Zuverlässigkeitsproblem gelöst hat, aber leider nicht

    • Man darf eines nicht vergessen
      Stufe 0: Die Daten werden falsch gespeichert
      Stufe -1: Das Modell wird von Anfang an falsch verstanden
      Stufe -2: Der Business-Prozess ist von vornherein falsch
      Deshalb nenne ich es statt „Single Source of Truth“ lieber „Single Source of Falsehood“

  • Das Schwierigste ist, Vertrauen zu skalieren
    Wir bauen ebenfalls etwas Ähnliches, und egal wie gut die Agenten-Loop ist, am Ende braucht man menschlich kuratierte Standardmetriken (canonical metrics)
    Sonst treffen nichttechnische Nutzer riskante Entscheidungen auf Basis von SQL, das sie nicht validieren können
    Unser Ansatz ist

    1. Wir kontrollieren die Datenpipeline direkt und verwenden nur Datenquellen mit konsistentem Schema über alle Kunden hinweg
    2. Wenn es validierte Metriken gibt, verwenden wir diese, und nur wenn es keine gibt, weichen wir auf SQL aus und protokollieren diesen Unterschied zur menschlichen Prüfung
      Mit der Zeit verwenden die meisten Queries Standardmetriken, und der Agent wird nicht zu einem bloßen SQL-Generator, sondern zu einem smarten Router von Intention → validierte Metrik
      Das Golden-SQL-Evaluierungssystem im Abschnitt „Schnell handeln, ohne Vertrauen zu zerstören“ enthält dieselbe Einsicht
      Mehr dazu steht in diesem Blogpost
    • Genau, man braucht unbedingt eine klare semantische Schicht
      Wenn es mehrere Wege zur Antwort gibt, kommen unterschiedliche Ergebnisse heraus
      LLMs erfinden oft Metriken mit bedeutungslosen Namen wie „xyz_index“, und Nutzer halten sie für plausibel und verwenden sie einfach

  • Ich denke, der eigentliche Einfluss von KI auf Entwicklerjobs wird die Qualität von Daten und Dokumentation sein
    Wie gut die Daten eines Unternehmens organisiert sind, bestimmt, wie effizient es KI einsetzen kann
    Öffentliche Daten sind bereits erschöpft, und die nächste Ressource sind interne Dokumente, Code-Repositories und Data Lakes
    Unternehmen mit einer guten Basis können mit KI neue Services schnell und günstig bauen und betreiben
    Dagegen funktioniert KI in Unternehmen mit chaotischer Dokumentations- und Codeverwaltung nicht richtig
    Am Ende werden sie Marktanteile an Wettbewerber verlieren
    Deshalb werde ich bei künftigen Bewerbungen auf jeden Fall nach dem Niveau der Verwaltung von Dokumentation, Daten und Repositories fragen

    • Mich würde interessieren, worauf du bei Dokumentation, Daten und Repositories konkret achtest, um gute von schlechter Architektur zu unterscheiden

  • Bei Amplitude wurde ein ähnliches System namens Moda gebaut
    Vor einigen Monaten hat Wade Claire Vo ein Demo-Video gezeigt, und es war wirklich hervorragend
    Ich nutze es täglich für die unterschiedlichsten Fragen

  • Wir bieten bei Definite.app in 5 Minuten etwas Ähnliches an
    Spark oder Snowflake werden nicht benötigt
    Wir liefern Data Lake, Pipeline, semantische Schicht und Datenagenten als eine einzige App
    Tatsächlich ist der Aufbau der Dateninfrastruktur viel schwieriger als der Agent selbst
    Wenn ein Agent nur SQL schreiben kann, sind die Grenzen groß, aber wir haben einen echten Wendepunkt geschaffen, indem wir die Infrastruktur selbst verwaltbar gemacht haben

  • Wirklich guter Inhalt
    Allerdings scheint der Teil zu fehlen, der erklärt, wie das Ergebnis berechnet wurde
    Für den internen Einsatz bei OpenAI ist die Annahme okay, dass Nutzer SQL lesen können, aber für nichttechnische Nutzer ist das gestalterisch eine große Herausforderung
    Wenn man mit Datensystemen arbeitet, merkt man schnell, dass nicht nur die „Antwort“ wichtig ist, sondern auch, wie die Antwort hergeleitet wurde

  • Persönlich finde ich Kimis In-House Data Agent interessanter

  • Datenprobleme sind keine technischen Probleme, sondern organisatorische Probleme

    • Stimme ich voll zu
      Meiner Erfahrung nach liegen die Ursachen von Datenproblemen nicht in der „falschen Technologieentscheidung“, sondern in Entscheidungen zu Governance und Ownership
      Letztlich läuft alles auf Conways Gesetz hinaus