Scopri l'agente dati interno di OpenAI

I dati sono alla base dell'apprendimento dei sistemi, dell'evoluzione dei prodotti e delle scelte delle aziende. Tuttavia, ottenere risposte rapide, corrette e contestualizzate è spesso più difficile di quanto dovrebbe essere. Per semplificare questo processo con l'espansione di OpenAI, abbiamo creato un nostro agente di dati IA interno su misura che esplora e analizza la nostra piattaforma.

Il nostro agente è uno strumento personalizzato ad uso esclusivamente interno (non un'offerta esterna), sviluppato appositamente per i dati, le autorizzazioni e i flussi di lavoro di OpenAI. Vogliamo mostrare come l'abbiamo creato e come lo usiamo per aiutare a trovare esempi reali e significativi di come l'IA può supportare il lavoro quotidiano dei nostri team. Gli strumenti di OpenAI che abbiamo usato per svilupparlo e gestirlo (Codex, il nostro modello di punta GPT‑5, l'API Evals⁠(si apre in una nuova finestra) e l'API Embeddings⁠(si apre in una nuova finestra)) sono gli stessi strumenti che mettiamo a disposizione degli sviluppatori di tutto il mondo.

Il nostro agente dati consente ai dipendenti di passare dalla domanda alla risposta in pochi minuti, anziché in giorni. Ciò semplifica l'estrazione dei dati e l'analisi approfondita in tutte le funzioni, non solo da parte del nostro team dedicato ai dati. Oggi, i team di OpenAI nei settori dell'ingegneria, della scienza dei dati, della strategia di commercializzazione, della finanza e della ricerca si affidano all'agente per rispondere a domande sui dati ad alto impatto. Ad esempio, può aiutare a rispondere a domande su come valutare i lanci e comprendere lo stato di salute dell'azienda, il tutto attraverso il formato intuitivo del linguaggio naturale. L'agente combina le conoscenze a livello di tabella fornite da Codex con il contesto del prodotto e dell'organizzazione. Il suo sistema di memoria in continuo apprendimento gli consente di migliorare ad ogni utilizzo.

In questo post analizzeremo perché avevamo bisogno di un agente di dati IA personalizzato, cosa rende così utili il suo contesto di dati arricchito dal codice e l'autoapprendimento, e le lezioni che abbiamo imparato lungo il percorso.

La piattaforma dati di OpenAI serve più di 3.500 utenti interni che lavorano nei settori di ingegneria, prodotto e ricerca, coprendo oltre 600 petabyte di dati distribuiti su 70.000 set di dati. Con dimensioni di questo tipo, anche solo trovare la tabella giusta può essere una delle parti più dispendiose in termini di tempo dell'analisi.

Come ha affermato un utente interno:

"Abbiamo molte tabelle che sono abbastanza simili e passo un sacco di tempo a cercare di capire quali sono le differenze e quale utilizzare. Alcune includono utenti disconnessi, altre no. Alcune hanno campi che si sovrappongono; è difficile capire a cosa servono".

Anche selezionando le tabelle corrette, ottenere risultati corretti può essere difficile. Gli analisti devono ragionare sui dati delle tabelle e sulle relazioni tra le tabelle per garantire che le trasformazioni e i filtri siano applicati correttamente. Modalità di errore comuni, quali collegamenti molti a molti, errori di pushdown dei filtri e valori nulli non gestiti, possono invalidare i risultati senza accorgersene. Alla scala di OpenAI, gli analisti non dovrebbero perdere tempo nel debug della semantica SQL o delle prestazioni delle query: il loro obiettivo dovrebbe essere quello di definire metriche, convalidare ipotesi e prendere decisioni basate sui dati.

Vediamo insieme cos'è il nostro agente, come gestisce il contesto e come continua a migliorarsi.

Il nostro agente è basato su GPT‑5.2 ed è progettato per operare sulla piattaforma dati di OpenAI. È disponibile ovunque lavorino già i dipendenti: come agente Slack, tramite un'interfaccia web, all'interno di IDE, nella CLI Codex tramite MCP⁠(si apre in una nuova finestra) e direttamente nell'app ChatGPT interna di OpenAI tramite un connettore MCP⁠(si apre in una nuova finestra).

Gli utenti possono porre domande complesse e aperte che normalmente richiederebbero più passaggi di analisi manuale. Prendiamo ad esempio questo prompt, che utilizza un set di dati di prova, "Per le corse in taxi a New York, quali coppie di codici postali di partenza e di arrivo sono le meno affidabili, con il divario maggiore tra i tempi di percorrenza tipici e quelli peggiori, e quando si verifica tale variabilità?"

L'agente gestisce l'analisi dall'inizio alla fine, dalla comprensione della domanda all'esplorazione dei dati, all'esecuzione delle query e alla sintesi dei risultati.

Uno dei superpoteri dell'agente è il modo in cui elabora i problemi. Anziché seguire uno script prestabilito, l'agente valuta i suoi progressi. Se un risultato intermedio sembra errato (ad esempio, se ha zero righe a causa di un collegamento o filtro errato), l'agente indaga su cosa è andato storto, modifica il proprio approccio e riprova. Durante questo processo, conserva il contesto completo e trasferisce le conoscenze acquisite tra un passaggio e l'altro. Questo processo di autoapprendimento a ciclo chiuso sposta l'iterazione dall'utente all'agente stesso, consentendo risultati più rapidi e analisi di qualità costantemente superiore rispetto ai flussi di lavoro manuali.

L'agente copre l'intero flusso di lavoro di analisi: individuazione dei dati, esecuzione di SQL e pubblicazione di notebook e report. Comprende le conoscenze interne dell'azienda, è in grado di effettuare ricerche sul web per trovare informazioni esterne e migliora nel tempo grazie all'utilizzo e alla memoria acquisiti.

Le risposte di alta qualità dipendono da un contesto ricco e accurato. Senza contesto, anche modelli potenti possono produrre risultati errati, come una stima grossolanamente errata del numero di utenti o un'interpretazione errata della terminologia interna.

Per evitare questi tipi di errore, l'agente è stato progettato con diversi livelli di contesto che lo radicano nei dati e nelle conoscenze istituzionali di OpenAI.

• Metadati di base: l'agente si basa sui metadati dello schema (nomi delle colonne e tipi di dati) per informare la scrittura SQL e utilizza la genealogia delle tabelle (ad esempio, le relazioni tra tabelle a monte e a valle) per fornire un contesto su come le diverse tabelle sono correlate.
• Inferenza delle query: l'acquisizione delle query storiche aiuta l'agente a capire come scrivere le proprie query e quali tabelle vengono solitamente unite.

• Descrizioni curate di tabelle e colonne fornite da esperti del settore, che catturano l'intento, la semantica, il significato aziendale e le avvertenze note che non sono facilmente deducibili dagli schemi o dalle query precedenti.

I metadati da soli non sono sufficienti. Per distinguere realmente le tabelle, è necessario capire come sono state create e da dove hanno origine.

• Derivando una definizione a livello di codice di una tabella, l'agente acquisisce una comprensione più approfondita di ciò che i dati contengono effettivamente. 
  • Le sfumature su ciò che è memorizzato nella tabella e su come è derivato da un evento di analisi forniscono informazioni aggiuntive. Ad esempio, possono fornire un contesto sull'unicità dei valori, sulla frequenza di aggiornamento dei dati della tabella, sull'ambito dei dati (ad esempio, se la tabella esclude determinati campi, ha questo livello di granularità), ecc.
• In questo modo si ottiene un contesto di utilizzo migliorato, mostrando come la tabella viene utilizzata oltre SQL in Spark, Python e altri sistemi di dati.
• Ciò significa che l'agente è in grado di distinguere tra tabelle che sembrano simili, ma che differiscono in aspetti fondamentali. Ad esempio, è in grado di stabilire se una tabella include solo traffico ChatGPT di prima parte. Anche questo contesto viene aggiornato automaticamente, quindi rimane aggiornato senza manutenzione manuale.

• L'agente può accedere a Slack, Google Docs e Notion, che raccolgono informazioni fondamentali sull'azienda, quali lanci, incidenti relativi all'affidabilità, nomi in codice e strumenti interni, definizioni canoniche e logica di calcolo per le metriche chiave.
• Questi documenti vengono acquisiti, incorporati e archiviati con metadati e autorizzazioni. Un servizio di recupero gestisce il controllo degli accessi e la memorizzazione nella cache durante l'esecuzione, consentendo all'agente di recuperare queste informazioni in modo efficiente e sicuro.

• Quando l'agente riceve correzioni o scopre sfumature su alcune domande relative ai dati, è in grado di memorizzare questi apprendimenti per la prossima volta, consentendogli di migliorare costantemente con i propri utenti. 
  • Di conseguenza, le risposte successive partono da una base più accurata, anziché incontrare ripetutamente gli stessi problemi.
  • L'obiettivo della memoria è conservare e riutilizzare correzioni, filtri e vincoli non ovvi che sono fondamentali per la correttezza dei dati, ma difficili da dedurre dagli altri livelli da soli. 
  • Ad esempio, in un caso, l'agente non sapeva come filtrare un particolare esperimento di analisi (si basava sulla corrispondenza con una stringa specifica definita in un gate dell'esperimento). La memoria è stata di fondamentale importanza in questo caso per garantire che fosse in grado di filtrare correttamente, invece di cercare di abbinare le stringhe in modo approssimativo.
• Quando fornisci all'agente una correzione o quando apprende qualcosa dalla tua conversazione, ti chiederà di salvare quella memoria per la prossima volta. 
  • Anche gli utenti possono creare e modificare manualmente le memorie.
  • Le memorie hanno portata globale e personale e gli strumenti dell'agente ne facilitano la modifica.

• Quando non esiste un contesto precedente per una tabella o quando le informazioni esistenti sono obsolete, l'agente può inviare query in tempo reale al data warehouse per ispezionare e interrogare direttamente la tabella. Ciò consente di convalidare gli schemi, comprendere i dati in tempo reale e rispondere di conseguenza.
• L'agente è anche in grado di comunicare con altri sistemi della piattaforma dati (servizio metadati, Airflow, Spark) in base alle necessità, per ottenere un contesto di dati più ampio che esiste al di fuori del data warehouse.

We run a daily offline pipeline that aggregates table usage, human annotations, and Codex-derived enrichment into a single, normalized representation. This enriched context is then converted into embeddings using the OpenAI embeddings API⁠(si apre in una nuova finestra) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(si apre in una nuova finestra) (RAG) instead of scanning raw metadata or logs. This makes table understanding fast and scalable, even across tens of thousands of tables, while keeping runtime latency predictable and low. Runtime queries are issued to our data warehouse live as needed.

Together, these layers ensure the agent’s reasoning is grounded in OpenAI’s data, code, and institutional knowledge, dramatically reducing errors and improving answer quality.

One-shot answers work when the problem is clear, but most questions aren’t. More often, arriving at the correct result requires back-and-forth refinement and some course correction.

The agent is built to behave like a teammate you can reason with. It’s a conversational, always-on and handles both quick answers and iterative exploration.

It carries over complete context across turns, so users can ask follow-up questions, adjust their intent, or change direction without restating everything. If the agent starts heading down the wrong path, users can interrupt mid-analysis and redirect it, just like working with a human collaborator who listens instead of plowing ahead.

When instructions are unclear or incomplete, the agent proactively asks clarifying questions. If no response is provided, it applies sensible defaults to make progress. For example, if a user asks about business growth with no date range specified, it may assume the last seven or 30 days. These priors allow it to stay responsive and non-blocking while still converging on the right outcome.

The result is an agent that works well both when you know exactly what you want (e.g., “Tell me about this table”) and just as strong when you’re exploring (e.g., “I’m seeing a dip here, can we break this down by customer type and timeframe?”). 

After rollout, we observed that users frequently ran the same analyses for routine repetitive work. To expedite this, the agent's workflows package recurring analyses into reusable instruction sets. Examples include workflows for weekly business reports and table validations. By encoding context and best practices once, workflows streamline repeat analyses and ensure consistent results across users.

Building an always-on, evolving agent means quality can drift just as easily as it can improve. Without a tight feedback loop, regressions are inevitable and invisible. The only way to scale capability without breaking trust is through systematic evaluation.

In this section, we’ll discuss how we leverage OpenAI’s Evals API⁠(si apre in una nuova finestra) to measure and protect the agent’s response quality.

Its Evals are built on curated sets of question-answer pairs. Each question targets an important metric or analytical pattern we care deeply about getting right, paired with a manually authored “golden” SQL query that produces the expected result. For each eval, we send the natural language question to its query-generation endpoint, execute the generated SQL, and compare the output against the result of the expected SQL.

Evaluation doesn’t rely on naive string matching. Generated SQL can differ syntactically while still being correct, and result sets may include extra columns that don’t materially affect the answer. To account for this, we compare both the SQL and the resulting data, and feed these signals into OpenAI’s Evals grader. The grader produces a final score along with an explanation, capturing both correctness and acceptable variation.

These evals are like unit tests that run continuously during development to identify regressions as canaries in production; this allows us to catch issues early and confidently iterate as the agent's capabilities expand.

Our agent plugs directly into OpenAI’s existing security and access-control model. It operates purely as an interface layer, inheriting and enforcing the same permissions and guardrails that govern OpenAI’s data. 

All of the agent’s access is strictly pass-through, meaning users can only query tables they already have permission to access. When access is missing, it flags this or falls back to alternative datasets the user is authorized to use.

Finally, it's built for transparency. Like any system, it can make mistakes. It exposes its reasoning process by summarizing assumptions and execution steps alongside each answer. When queries are executed, it links directly to the underlying results, allowing users to inspect raw data and verify every step of the analysis.

Building our agent from scratch surfaced practical lessons about how agents behave, where they struggle, and what actually makes them reliable at scale.

Early on, we exposed our full tool set to the agent, and quickly ran into problems with overlapping functionality. While this redundancy can be helpful for specific custom cases and is more obvious to a human when manually invoking, it’s confusing to agents. To reduce ambiguity and improve reliability, we restricted and consolidated certain tool calls.

We also discovered that highly prescriptive prompting degraded results. While many questions share a general analytical shape, the details vary enough that rigid instructions often pushed the agent down incorrect paths. By shifting to higher-level guidance and relying on GPT‑5’s reasoning to choose the appropriate execution path, the agent became more robust and produced better results.

Schemas and query history describe a table’s shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata. By crawling the codebase with Codex, our agent understands how datasets are actually constructed and is able to better reason about what each table actually contains. It can answer “what’s in here” and “when can I use it” far more accurately than from warehouse signals alone. 

We’re constantly working to improve our agent by increasing its ability to handle ambiguous questions, improving its reliability and accuracy with stronger validations, and integrating it more deeply into workflows. We believe it should blend naturally into how people already work, instead of functioning like a separate tool.

While our tooling will keep benefiting from underlying improvements in agent reasoning, validation, and self-correction, our team’s mission remains the same: seamlessly deliver fast, trustworthy data analysis across OpenAI’s data ecosystem.