Dentro do agente de dados interno da OpenAI

Os dados permitem que os sistemas aprendam, que os produtos evoluam e que as empresas façam escolhas. Mas obter respostas rápidas, corretas e com o contexto certo é muitas vezes mais difícil do que deveria ser. Para facilitar esta tarefa à medida que a OpenAI se expande, criámos o nosso próprio agente de dados de IA interno que explora e raciocina sobre a nossa própria plataforma..

O nosso agente é uma ferramenta interna personalizada (não é uma oferta externa), criada especificamente com base em dados, permissões e fluxos de trabalho da OpenAI. Estamos a mostrar como o criámos e utilizamos para ajudar a mostrar exemplos das formas reais e impactantes de como a IA pode apoiar o trabalho diário das nossas equipas. As ferramentas da OpenAI que utilizámos para o construir e executar (Codex, o nosso modelo principal GPT‑5, as Evals API⁠(abre numa nova janela) e as Embeddings API⁠(abre numa nova janela)) são as mesmas ferramentas que disponibilizamos aos programadores de todo o mundo.

O nosso agente de dados permite que os colaboradores passem de uma pergunta para insight em minutos, e não em dias. Isto reduz a dificuldade da obtenção de dados e as análises diferenciadas em todas as funções, não só para a nossa equipa de dados. Atualmente, as equipas de Engenharia, Ciência de Dados, Go-To-Market, Finanças e Investigação da OpenAI recorrem ao agente para responder a questões de dados de grande impacto. Por exemplo, pode ajudar a responder a como avaliar lançamentos e compreender a saúde do negócio, tudo através do formato intuitivo da linguagem natural. O agente combina o conhecimento ao nível da tabela baseado no Codex com o contexto do produto e da organização. E graças ao sistema de memória de aprendizagem contínua, também melhora a cada etapa.

Nesta publicação, vamos partilhar porque é que precisávamos de um agente de dados de IA adaptado, o que torna o contexto de dados enriquecido com código e a autoaprendizagem tão úteis, e as lições que aprendemos ao longo do caminho.

A plataforma de dados da OpenAI serve mais de 3500 utilizadores internos que trabalham em Engenharia, Produto e Investigação, abrangendo mais de 600 petabytes de dados em 70 mil conjuntos de dados. Com este tamanho, simplesmente encontrar a tabela certa pode ser uma das partes mais demoradas da análise.

Como disse um utilizador interno:

"Temos muitas tabelas que são bastante semelhantes, e passo imenso tempo a tentar perceber quais são as diferenças e quais utilizar. Algumas incluem utilizadores com sessão terminada, outras não. Algumas têm campos que se sobrepõem, pelo que é difícil dizer o que é o quê."

Mesmo com as tabelas certas selecionadas, produzir resultados corretos pode ser um desafio. Os analistas têm de raciocinar sobre os dados e as relações das tabelas para garantir que as transformações e os filtros são aplicados corretamente. Modos de falha comuns (junções de muitos para muitos, erros de pushdown de filtros e nulos não tratados) podem invalidar silenciosamente os resultados. Na escala da OpenAI, os analistas não devem ter de perder tempo a depurar a semântica SQL ou o desempenho da query: estes devem concentrar-se na definição de métricas, na validação de pressupostos e na tomada de decisões baseada em dados.

Vamos explicar-lhe o que é o nosso agente, como seleciona o contexto e como se autoaperfeiçoa.

O nosso agente é baseado no GPT‑5.2 e foi criado para raciocinar sobre a plataforma de dados da OpenAI. Está disponível onde quer que os colaboradores já trabalhem: como um agente Slack, através de uma interface web, dentro de IDEs, no Codex CLI por MCP⁠(abre numa nova janela), e diretamente na aplicação interna do ChatGPT na OpenAI através de um connector MCP⁠(abre numa nova janela).

Os utilizadores podem fazer perguntas complexas e abertas que normalmente exigiriam várias rondas de exploração manual. Veja este exemplo de prompt, que utiliza um conjunto de dados de teste: "Para viagens de táxi em Nova Iorque, quais são os pares ZIP de recolha-chegada menos fiáveis, com a maior diferença entre os tempos de viagem típicos e os piores, e quando é que essa variabilidade ocorre?"

O agente processa da análise completa, desde a compreensão da pergunta até à exploração dos dados, à execução de queries e à síntese dos resultados.

Um dos superpoderes do agente é a forma como raciocina através de problemas. Em vez de seguir um script fixo, o agente avalia o próprio progresso. Se um resultado intermédio parecer errado (por exemplo, se tiver zero linhas devido a uma junção ou filtro incorreto), o agente investiga o que correu mal, ajusta a abordagem e tenta novamente. Ao longo deste processo, o agente mantém o contexto completo e transporta as aprendizagens entre as etapas. Este processo de ciclo fechado e de autoaprendizagem transfere a iteração do utilizador para o próprio agente, permitindo resultados mais rápidos e análises de qualidade consistentemente mais elevada do que os fluxos de trabalho manuais.

O agente abrange todo o fluxo de trabalho de análise: descobrindo dados, executando SQL e publicando notebooks e relatórios. Este compreende o conhecimento interno da empresa, consegue pesquisar informações externas na Web e melhora ao longo do tempo através da utilização e memórias aprendidas.

As respostas de alta qualidade dependem de um contexto extenso e exato. Sem contexto, mesmo os modelos mais fortes podem produzir resultados errados, como uma estimativa muito errada da contagem de utilizadores ou uma interpretação errada da terminologia interna.

Para evitar estes modos de falha, o agente é construído com base em várias camadas de contexto que o fundamentam nos dados e no conhecimento institucional da OpenAI.

• Fundamentação de metadados: O agente baseia-se nos metadados do schema (nomes de colunas e tipos de dados) para informar a escrita SQL e utiliza linhagem da tabela (por exemplo, relações entre tabelas upstream e downstream) para fornecer contexto sobre a forma como as diferentes tabelas se relacionam.
• Inferência de query: A ingestão de queries históricas ajuda o agente a compreender como escrever as próprias queries e que tabelas são normalmente unidas.

• Descrições selecionadas de tabelas e colunas fornecidas por especialistas do domínio, capturando a intenção, a semântica, o significado comercial e as ressalvas conhecidas que não são facilmente inferidas a partir de schemas ou queries anteriores.

Os metadados por si só não são suficientes. Para distinguir realmente as tabelas, precisa de compreender como foram criadas e qual a sua origem.

• Ao derivar uma definição ao nível do código duma tabela, o agente constrói uma compreensão mais profunda do que os dados realmente contêm. 
  • As nuances sobre o que é armazenado na tabela e como é derivado de um evento analítico fornecem informações adicionais. Por exemplo, pode fornecer contexto sobre a singularidade dos valores, a frequência com que os dados da tabela são atualizados, o âmbito dos dados (por exemplo, se a tabela excluir determinados campos, tem este nível de granularidade), etc.
• Isto fornece um contexto de utilização melhorado que mostra como a tabela é utilizada além do SQL no Spark, no Python e noutros sistemas de dados.
• Isto significa que o agente pode distinguir entre tabelas que parecem semelhantes, mas que diferem em aspetos críticos. Por exemplo, consegue saber se uma tabela inclui apenas o tráfego primário do ChatGPT. Este contexto também é atualizado automaticamente, pelo que se mantém em dia sem manutenção manual.

• O agente é capaz de aceder ao Slack, ao Google Docs e ao Notion, que capturam o contexto crítico da empresa, como lançamentos, incidentes de fiabilidade, alcunhas e ferramentas internas, bem como as definições canónicas e a lógica de compute das principais métricas.
• Estes documentos são ingeridos, incorporados e armazenados com metadados e permissões. Um serviço de recuperação processa o controlo de acesso e a colocação em cache no runtime, permitindo que o agente obtenha estas informações de forma eficiente e segura.

• Quando o agente recebe correções ou descobre nuances sobre determinadas questões de dados, este é capaz de guardar estas aprendizagens para a próxima vez, possibilitando-lhe melhorar constantemente com os seus utilizadores. 
  • Como resultado, as respostas futuras partem de uma base mais exata em vez de se depararem repetidamente com os mesmos problemas.
  • O objetivo da memória é reter e reutilizar correções, filtros e restrições não óbvios que são críticos para a correção dos dados e difíceis de inferir apenas a partir das outras camadas. 
  • Por exemplo, num caso, o agente não sabia como filtrar uma determinada experiência analítica (que dependia da correspondência com uma string específica definida num experiment gate). Neste caso, a memória foi crucialmente importante para garantir que era capaz de filtrar corretamente, em vez de tentar fazer uma correspondência imprecisa de string.
• Quando dá uma correção ao agente ou quando este encontra uma aprendizagem da sua conversa, ser-lhe-á apresentado um prompt para guardar essa memória para a próxima vez. 
  • As memórias também podem ser criadas e editadas manualmente pelos utilizadores.
  • As memórias são delimitadas a nível global e pessoal, e as ferramentas do agente facilitam a sua edição.

• Quando não há contexto prévio para uma tabela ou as informações existentes são obsoletas, o agente pode emitir queries em tempo real no warehouse de dados para inspecionar e fazer query na tabela diretamente. Isto permite-lhe validar schemas, compreender os dados em tempo real e responder em conformidade.
• O agente também tem a capacidade de falar com outros sistemas da plataforma de dados (serviço de metadados, Airflow, Spark), conforme necessário, para obter um contexto de dados mais amplo que existe fora do warehouse.

As Evals são construídas com base em conjuntos de pares selecionados de perguntas e respostas. Cada pergunta visa uma métrica importante ou um padrão analítico que nos interessa profundamente acertar, emparelhado com uma query SQL "Dourada" de autoria manual que produz o resultado esperado. Para cada Eval, enviamos a pergunta em linguagem natural para o respetivo endpoint de geração de query, executamos o SQL gerado e comparamos a saída com o resultado do SQL esperado.

A avaliação não depende Da correspondência ingénua de strings. O SQL gerado pode diferir sintaticamente e estar correto na mesma, e os conjuntos de resultados podem incluir colunas extra que não afetam materialmente a resposta. Para ter isto em consideração, comparamos tanto o SQL como os dados resultantes e alimentamos esses sinais no pontuador de Evals da OpenAI. O pontuador produz uma pontuação final juntamente com uma explicação, capturando tanto a correção como a variação aceitável.

Estas Evals são como testes unitários que são executados continuamente durante o desenvolvimento para identificar regressões como canários na produção; isto permite-nos detetar cedo os problemas e iterar com confiança à medida que as capacidades do agente se expandem.

O nosso agente integra-se diretamente no modelo de segurança e controlo de acesso existente da OpenAI. Este funciona apenas como uma camada de interface, herdando e aplicando as mesmas permissões e proteções que regem os dados da OpenAI. 

Todo o acesso do agente é estritamente transitório, o que significa que os utilizadores só podem fazer query em tabelas a que já têm permissão de acesso. Quando não há acesso, isto é sinalizado ou ocorre fallback para conjuntos de dados alternativos que o utilizador está autorizado a utilizar.

Por último, foi criado para transparência. Como qualquer sistema, pode cometer erros. O agente expõe o processo de raciocínio ao resumir pressupostos e passos de execução ao lado de cada resposta. Quando as queries são executadas, este liga-se diretamente aos resultados subjacentes, permitindo que os utilizadores inspecionem os dados em bruto e verifiquem cada passo da análise.

Criar o nosso agente de raiz revelou lições práticas sobre como os agentes se comportam, onde têm dificuldades e o que realmente os torna fiáveis em escala.

No início, expusemos todo o nosso conjunto de ferramentas ao agente, e rapidamente nos deparámos com problemas de sobreposição de funcionalidade. Embora esta redundância possa ser útil para casos personalizados específicos e seja mais óbvia para um humano que invoca manualmente, é confusa para os agentes. Para reduzir a ambiguidade e melhorar a fiabilidade, restringimos e consolidámos certas chamadas de ferramentas.

Também descobrimos que o prompt altamente prescritivo degradou os resultados. Embora muitas perguntas partilhem uma forma analítica geral, os detalhes variam o suficiente para que instruções rígidas levem o agente para caminhos incorretos. Ao mudar para uma orientação de nível superior e confiar no raciocínio do GPT‑5 para escolher o caminho de execução apropriado, o agente tornou-se mais robusto e produziu melhores resultados.

Os schemas e o histórico de query descrevem a forma e o uso de uma tabela, mas o verdadeiro significado está no código que a produz. A lógica do pipeline captura suposições, garantias de frescura e intenção comercial que nunca aparecem no SQL ou nos metadados. Ao rastrear a base de código com o Codex, o nosso agente compreende como os conjuntos de dados são realmente construídos e consegue raciocinar melhor sobre o que cada tabela realmente contém. Este pode responder a "o que está aqui" e "quando é que o posso usar" com muito mais precisão do que apenas com os sinais do warehouse. 

Estamos constantemente a trabalhar para melhorar o nosso agente, aumentando a capacidade de processamento de perguntas ambíguas, melhorando a fiabilidade e a precisão com validações mais fortes, e integrando-o mais profundamente em fluxos de trabalho. Acreditamos que este deve integrar-se naturalmente na forma como as pessoas já trabalham, em vez de funcionar como uma ferramenta separada.

Embora as nossas ferramentas continuem a beneficiar de melhorias subjacentes no raciocínio, na validação e na autocorreção dos agentes, a missão da nossa equipa continua igual: fornecer análises de dados rápidas e fiáveis em todo o ecossistema de dados da OpenAI.