- A OpenAI construiu internamente um agente de dados de IA personalizado para analisar com eficiência mais de 3.500 usuários internos e 600 PB de dados
- Apenas com perguntas em linguagem natural, ele automatiza um workflow de análise end-to-end, desde a exploração de tabelas e execução de SQL até a publicação de notebooks e relatórios
- Garante precisão ao combinar 6 camadas de contexto (uso de tabelas, anotações humanas, análise de código baseada em Codex, conhecimento organizacional, memória e contexto de runtime)
- Opera com uma estrutura de loop fechado de autoaprendizado que investiga por conta própria a causa de resultados intermediários incorretos e ajusta a abordagem
- Com um sistema de avaliação estruturado baseado na Evals API, detecta regressões de qualidade precocemente e mantém a confiabilidade herdando o modelo existente de segurança e permissões
Por que é necessário um agente de dados personalizado
- A plataforma de dados da OpenAI tem mais de 3.500 usuários internos, 600 petabytes de dados e mais de 70 mil datasets; encontrar a tabela certa é, por si só, a etapa que mais consome tempo na análise
- Há muitas tabelas parecidas, o que dificulta entender as diferenças entre tabelas, como incluir ou não usuários deslogados e duplicidade de campos
- Mesmo ao escolher a tabela correta, joins many-to-many, erros de filter pushdown e tratamento inadequado de null podem invalidar os resultados
- Analistas devem se concentrar em definição de métricas, validação de hipóteses e tomada de decisão orientada por dados, e não em depuração de SQL
Como o agente funciona
- Baseado em GPT-5.2
- Pode ser acessado nos ambientes que os funcionários já usam, como agente no Slack, interface web, IDE, Codex CLI (com integração MCP) e aplicativo interno do ChatGPT
- Consegue lidar com perguntas complexas e abertas
- Entendimento da pergunta
- Exploração de dados
- Execução de SQL
- Execução end-to-end até a análise e o resumo dos resultados
- Exemplo: análise, no dataset de táxis de NYC, da combinação com maior variabilidade no tempo de deslocamento entre pares de ZIP de embarque e desembarque
- Em vez de seguir scripts fixos, avalia o próprio progresso e, se os resultados intermediários estiverem errados (por exemplo, 0 linhas por causa de joins ou filtros incorretos), investiga a causa, ajusta a abordagem e tenta novamente
- Cobre todo o workflow de análise: descoberta de dados, execução de SQL, publicação de notebooks e relatórios, consulta a conhecimento interno, busca na web e aprendizado baseado em memória
Estrutura em camadas de contexto
-
Layer 1: Uso de Tabelas (Table Usage)
- Grounding de metadados: usa metadados de schema (nomes de colunas, tipos de dados) para escrever SQL e entende relações entre tabelas por meio de lineage (relações entre tabelas upstream e downstream)
- Inferência de queries: coleta queries passadas para que o agente aprenda a própria forma de escrever consultas e combinações de tabelas que normalmente são unidas por joins
-
Layer 2: Anotações Humanas (Human Annotations)
- Especialistas de domínio escrevem descrições curadas sobre tabelas e colunas, capturando intenção, semântica, contexto de negócio e observações conhecidas que são difíceis de inferir a partir do schema ou de queries passadas
- Como é difícil distinguir tabelas apenas pelos metadados, é essencial entender como foram geradas e de onde vieram
-
Layer 3: Análise de código baseada em Codex (Codex Enrichment)
- Extrai a definição em nível de código das tabelas para entender profundamente o conteúdo real dos dados
- Fornece nuances baseadas em eventos analíticos, como unicidade de valores, frequência de atualização dos dados e escopo dos dados (se certos campos são excluídos, nível de granularidade etc.)
- Permite entender o contexto de uso em diversos sistemas de dados, como Spark e Python, além de SQL
- Permite diferenciar tabelas que parecem semelhantes, mas são essencialmente diferentes (por exemplo, se uma tabela inclui apenas tráfego 1st-party do ChatGPT)
- Esse contexto é atualizado automaticamente, sem necessidade de manutenção manual
-
Layer 4: Conhecimento Organizacional (Institutional Knowledge)
- Coleta contexto da empresa a partir de Slack, Google Docs, Notion etc., incluindo lançamentos, incidentes, codinomes internos e definições padronizadas e lógica de cálculo de métricas-chave
- Opera um serviço de busca que coleta documentos, gera embeddings, armazena com metadados e permissões, e trata controle de acesso e cache em runtime
-
Layer 5: Memória (Memory)
- Quando o agente recebe correções ou descobre nuances em perguntas sobre dados, ele as armazena para começar a próxima análise com uma baseline mais precisa
- O objetivo da memória é preservar e reutilizar correções, filtros e restrições não óbvios que são difíceis de inferir nas outras camadas
- Exemplo: ao filtrar um experimento analítico específico, era necessário corresponder uma string definida no gate do experimento; sem memória, ocorria o erro de tentar fuzzy string matching
- Quando há correções ou descobertas de aprendizado, o agente induz o armazenamento em memória, e o usuário também pode criar e editar manualmente
- O escopo da memória é dividido em nível global e nível pessoal
-
Layer 6: Contexto de Runtime (Runtime Context)
- Quando não há contexto prévio sobre uma tabela ou a informação está desatualizada, ele emite queries ao vivo no data warehouse para validar o schema e entender os dados em tempo real
- Também se comunica com outros sistemas da Data Platform, como serviço de metadados, Airflow e Spark, para obter contexto de dados fora do warehouse
-
Pipeline offline diário e RAG
- Opera um pipeline offline diário que agrega uso de tabelas, anotações humanas e informações enriquecidas por Codex em uma representação normalizada única
- Converte o contexto enriquecido em embeddings com a OpenAI Embeddings API e o armazena; na consulta, recupera apenas o contexto relevante via RAG (Retrieval-Augmented Generation)
- Mantém o entendimento de tabelas rápido e escalável em dezenas de milhares de tabelas, com latência de runtime previsível e baixa
Um design para pensar e colaborar como um colega de equipe
- Em vez de respostas one-shot, oferece exploração iterativa em conversa, mantendo contexto completo entre turnos para que não seja necessário explicar tudo de novo em perguntas de seguimento ou mudanças de direção
- Se o agente estiver indo na direção errada, o usuário pode intervir no meio da análise e redirecioná-lo
- Quando a instrução é ambígua, ele faz perguntas de esclarecimento proativamente; se não houver resposta, segue com defaults razoáveis (por exemplo, últimos 7 ou 30 dias)
- Após observar padrões em que a mesma análise é executada repetidamente, empacota análises recorrentes como workflows reutilizáveis (instruction set)
- Relatórios semanais de negócio e validação de tabelas são exemplos
- Ao codificar contexto e boas práticas uma vez, garante resultados consistentes entre usuários
Um sistema de avaliação para melhorar rápido mantendo a confiança
- Como o agente está sempre evoluindo, é fácil ocorrer drift de qualidade e, sem avaliação sistemática, regressões podem avançar sem serem percebidas
- Com base na OpenAI Evals API, é construído um conjunto curado de pares de pergunta e resposta, e para cada pergunta é associada manualmente uma query SQL “golden”
- A pergunta em linguagem natural é enviada ao endpoint de geração de queries, o SQL gerado é executado e depois comparado com o resultado esperado do SQL
- Em vez de simples correspondência de strings, tanto o SQL quanto os dados resultantes são comparados e enviados ao grader do Evals para gerar a pontuação final e a explicação, refletindo precisão e variação tolerável
- Essa avaliação funciona como teste de unidade executado continuamente durante o desenvolvimento e como canário em produção para capturar regressões cedo
Segurança do agente
- Conecta-se diretamente ao modelo existente de segurança e controle de acesso da OpenAI, herdando e aplicando as mesmas permissões e guardrails na camada de interface
- Todo acesso ocorre em modo pass-through: o usuário só pode consultar tabelas para as quais já tem permissão; se não tiver, o agente informa isso ou faz fallback para um dataset alternativo
- Para transparência, expõe o processo de raciocínio: resume premissas e etapas executadas junto com a resposta, e fornece link direto para os resultados brutos das queries executadas, permitindo que o usuário verifique todas as etapas da análise
Lições aprendidas durante a construção
-
Lesson 1: Menos é mais (Less is More)
- No início, todo o conjunto de ferramentas foi exposto ao agente, mas isso gerou confusão por sobreposição de funcionalidades
- Funcionalidades redundantes que são úteis quando chamadas manualmente por humanos causam ambiguidade para o agente; por isso, restringir e consolidar chamadas de ferramentas melhorou a confiabilidade
-
Lesson 2: Oriente o objetivo, não o caminho (Guide the Goal, Not the Path)
- Prompts excessivamente prescritivos acabaram piorando os resultados
- Como os detalhes variam em cada pergunta, instruções rígidas podem empurrar o agente para o caminho errado; fornecer guidance de alto nível e delegar ao raciocínio do GPT-5 a escolha do caminho de execução se mostrou superior
-
Lesson 3: O significado está no código (Meaning Lives in Code)
- Schema e histórico de queries explicam apenas a forma da tabela e como ela é usada; o significado real está no código que gera a tabela
- A lógica dos pipelines captura premissas, garantias de frescor e intenção de negócio, e isso não aparece no SQL nem nos metadados
- Ao rastrear a codebase com Codex para entender como os datasets são realmente construídos, tornou-se possível responder com precisão a “o que está incluído” e “quando pode ser usado”, algo impossível apenas com sinais do warehouse
Direção futura
- A OpenAI segue avançando em melhor tratamento de perguntas ambíguas, maior confiabilidade e precisão por meio de validação mais robusta e integração mais profunda com workflows
- O objetivo é que ele se integre naturalmente à forma como as pessoas já trabalham, e não como uma ferramenta separada
- Com a evolução das tecnologias de base para raciocínio, validação e autocorreção do agente, ele continuará evoluindo, e
a missão da equipe é oferecer análise de dados rápida e confiável de forma fluida em todo o ecossistema de dados da OpenAI
1 comentários
Comentários do Hacker News
Confiabilidade e explicabilidade são os maiores problemas
Estamos desenvolvendo análise em linguagem natural na Veezoo há 10 anos, e uma abordagem simples de Text-to-SQL não escala bem
Quando um CFO pergunta sobre a receita, um número que acerta só 99% não serve, e o CFO também não consegue validar o SQL diretamente
Por isso, criamos uma camada de abstração chamada Knowledge Graph, na qual a IA converte a linguagem natural em uma linguagem de consulta baseada em significado, que depois é compilada de forma determinística para SQL
No sentido inverso, essa consulta semântica é convertida novamente em uma explicação em linguagem natural, para que o usuário possa verificar facilmente se o resultado corresponde ao que ele pretendia
A lógica de negócio existe no Knowledge Graph, e o compilador garante que todas as consultas a sigam 100%
A estrutura detalhada está resumida na documentação de arquitetura da Veezoo
Minha dúvida é como vocês lidam com explosão de cardinalidade e como tratam solicitações de múltiplas consultas que dependem dos resultados de consultas anteriores
Deveria ser possível rastrear qual consulta foi usada em determinada data e como ela foi validada
(Claro, os prompts também precisam de versionamento)
Fiquei surpreso como o primeiro exemplo é completamente ilógico
Se isso passou por revisão humana, então provavelmente foi escrito por IA, e nesse caso a confiabilidade do sistema fica em dúvida
Link para a imagem problemática
No desktop está o prompt correto,
e no mobile está o prompt incorreto
Pela minha experiência usando vários sistemas de BI, acho que esse tipo de agente de IA é um caso de uso perfeito
BI já nasce com erros em várias camadas — a própria consulta pode estar errada, ou a interpretação dos dados pode estar errada
Quando essas duas coisas se combinam, você já entrou em um “mundo imaginário”, então é até melhor deixar a IA cuidar da etapa 1
Eu esperava que a OpenAI tivesse resolvido o problema da confiabilidade, mas infelizmente não foi o caso
Etapa 0: os dados foram armazenados incorretamente
Etapa -1: o modelo foi entendido de forma errada
Etapa -2: o processo de negócio já estava errado desde o começo
Por isso eu chamo de “fonte única da mentira”, e não de “fonte única da verdade”
Escalar confiança é a parte mais difícil
Também estamos construindo algo parecido, e por melhor que seja o loop do agente, no fim ainda é preciso ter métricas canônicas curadas por humanos
Caso contrário, usuários não técnicos acabam tomando decisões arriscadas com base em SQL que eles não conseguem validar
Nossa abordagem é:
Com o tempo, a maioria das consultas passa a usar métricas padronizadas, e o agente deixa de ser apenas um gerador de SQL para virar um roteador inteligente de intenção → métrica validada
O sistema de avaliação de SQL dourado na seção “mover-se rápido sem quebrar a confiança” também carrega essa mesma percepção
Escrevemos sobre isso neste post do blog
Se existem vários caminhos até a resposta, os resultados saem diferentes
LLMs muitas vezes inventam métricas sem sentido como
xyz_index, e os usuários simplesmente usam porque parece plausívelNa minha opinião, o verdadeiro impacto da IA nos empregos de desenvolvedores será na qualidade dos dados e da documentação
O quanto os dados de uma empresa são bem organizados determina a eficiência do uso de IA
Os dados públicos já se esgotaram, e o próximo recurso são documentos internos, repositórios de código e data lakes
Empresas com essa base bem estruturada conseguem criar e manter novos serviços com IA de forma rápida e barata
Já empresas com documentação e gestão de código caóticas não conseguem fazer a IA funcionar direito
No fim, vão perder mercado para a concorrência
Por isso, quando eu procurar emprego no futuro, pretendo perguntar obrigatoriamente sobre o nível de organização da documentação, dos dados e dos repositórios
Na Amplitude, eles criaram um sistema parecido chamado Moda
Há alguns meses, o Wade mostrou um vídeo de demonstração para a Claire Vo, e foi realmente excelente
Eu uso isso todos os dias, fazendo vários tipos de perguntas
Nós também oferecemos algo parecido na Definite.app em 5 minutos
Não precisa de Spark nem de Snowflake
Oferecemos data lake, pipeline, camada semântica e agente de dados em um único app
Na verdade, montar a infraestrutura de dados é muito mais difícil do que o próprio agente
Se o agente só consegue escrever SQL, ele é bastante limitado, mas nós permitimos gerenciar a própria infraestrutura, o que virou um grande ponto de virada
Conteúdo realmente muito bom
Só acho que faltou a parte de explicar como o resultado foi calculado
Como é para uso interno da OpenAI, faz sentido assumir que o usuário consegue ler SQL, mas para usuários não técnicos isso é um grande desafio de design
Quando você trabalha com sistemas de dados, percebe rapidamente que tão importante quanto a “resposta” é “como essa resposta foi obtida”
Pessoalmente, acho o In-House Data Agent da Kimi mais interessante
Problemas de dados não são problemas técnicos, e sim problemas organizacionais
Pela minha experiência, a causa dos problemas de dados não é uma “escolha errada de tecnologia”, e sim decisões de governança e ownership
No fim, tudo converge para a Lei de Conway