Di dalam ejen data dalaman OpenAI

Data menggerakkan bagaimana sistem belajar, produk berkembang, dan bagaimana syarikat membuat keputusan. Tetapi mendapatkan jawapan dengan cepat, tepat, dan dalam konteks yang betul selalunya lebih sukar daripada yang sepatutnya. Untuk memudahkan proses ini apabila OpenAI berkembang, kami membina ejen data AI dalaman yang direka khas yang meneroka dan membuat penaakulan merentas platform kami sendiri.

Ejen kami ialah alat dalaman yang disesuaikan (bukan tawaran luaran), dibina khusus untuk data, kebenaran, dan aliran kerja OpenAI. Kami menunjukkan bagaimana kami membina dan menggunakannya untuk menonjolkan contoh-contoh sebenar dan berimpak tentang cara AI boleh menyokong kerja harian di seluruh pasukan kami. Alat OpenAI yang kami gunakan untuk membina dan menjalankannya (Codex, model terunggul GPT‑5 kami, API Evals⁠(dibuka dalam tetingkap baru), dan API Embeddings⁠(dibuka dalam tetingkap baru)) adalah alat yang sama yang kami sediakan kepada pembangun di seluruh dunia.

Ejen data kami membolehkan pekerja beralih daripada soalan kepada cerapan dalam beberapa minit, bukan beberapa hari. Ini merendahkan halangan untuk mendapatkan data dan analisis bernuansa merentas semua fungsi, bukan hanya oleh pasukan data kami. Hari ini, pasukan merentasi Kejuruteraan, Sains Data, pasaran bersasar, Kewangan, dan Penyelidikan di OpenAI bergantung pada ejen untuk menjawab soalan data berimpak tinggi. Sebagai contoh, ia boleh membantu menjawab persoalan tentang cara menilai pelancaran dan memahami kesihatan perniagaan, semuanya melalui format intuitif bahasa semula jadi. Ejen menggabungkan pengetahuan peringkat jadual yang dikuasakan oleh Codex dengan konteks produk dan organisasi. Sistem memori yang sentiasa belajar ini bermaksud ia juga bertambah baik dengan setiap pusingan.

Dalam catatan ini, kami akan menghuraikan mengapa kami memerlukan ejen data AI yang direka khas, apa yang menjadikan konteks data yang diperkaya dengan kod dan pembelajaran kendiri begitu berguna, serta pengajaran yang kami pelajari sepanjang perjalanan.

Platform data OpenAI berkhidmat kepada lebih daripada 3,500 pengguna dalaman yang bekerja merentasi Kejuruteraan, Produk, dan Penyelidikan, merangkumi lebih 600 petabait data merentasi 70,000 set data. Pada saiz itu, sekadar mencari jadual yang betul boleh menjadi salah satu bahagian yang paling memakan masa dalam melakukan analisis.

Seperti yang dinyatakan oleh seorang pengguna dalaman:

“Kami mempunyai banyak jadual yang agak serupa, dan saya menghabiskan banyak masa cuba untuk mengetahui bagaimana ia berbeza dan yang mana satu untuk digunakan. Sesetengah termasuk pengguna yang telah log keluar, sesetengah tidak. "Sesetengahnya mempunyai bidang yang bertindih; sukar untuk membezakan yang mana satu.”

Walaupun jadual yang betul telah dipilih, menghasilkan keputusan yang betul boleh menjadi mencabar. Penganalisis mesti membuat penaakulan mengenai data jadual dan hubungan jadual untuk memastikan transformasi dan penapis digunakan dengan betul. Mod kegagalan biasa—many-to-many joins, ralat penolakan penapis, dan null yang tidak ditangani—boleh membatalkan keputusan secara senyap. Pada skala OpenAI, penganalisis tidak seharusnya membuang masa untuk menyahpepijat semantik SQL atau prestasi pertanyaan; fokus mereka seharusnya pada mentakrifkan metrik, mengesahkan andaian, dan membuat keputusan berdasarkan data.

Mari kita telusuri apa itu ejen kami, bagaimana ia mengurus konteks, dan bagaimana ia terus memperbaiki diri.

Ejen kami dikuasakan oleh GPT‑5.2 dan direka untuk menaakul di atas platform data OpenAI. Ia tersedia di mana-mana sahaja pekerja sudah bekerja: sebagai ejen Slack, melalui antara muka web, di dalam IDE, dalam Codex CLI melalui MCP⁠(dibuka dalam tetingkap baru), dan secara langsung dalam aplikasi ChatGPT dalaman OpenAI melalui penyambung MCP⁠(dibuka dalam tetingkap baru).

Pengguna boleh bertanya soalan kompleks dan terbuka yang biasanya memerlukan beberapa pusingan penerokaan manual. Ambil contoh prom ini, yang menggunakan set data ujian: “Untuk perjalanan teksi NYC, pasangan ZIP pengambilan-ke-penurunan yang manakah paling tidak boleh dipercayai, dengan jurang terbesar antara masa perjalanan tipikal dan kes terburuk, dan bilakah kebolehubahan itu berlaku?”

Ejen mengendalikan analisis dari awal hingga akhir, daripada memahami soalan kepada meneroka data, menjalankan pertanyaan, dan mensintesis penemuan.

Salah satu kuasa luar biasa ejen ialah cara ia menalar melalui masalah. Daripada mengikuti skrip tetap, ejen menilai kemajuannya sendiri. Jika hasil perantaraan kelihatan salah (cth., jika ia mempunyai sifar baris disebabkan oleh gabungan atau penapis yang tidak betul), ejen menyiasat apa yang tidak kena, melaraskan pendekatannya, dan mencuba lagi. Sepanjang proses ini, ia mengekalkan konteks sepenuhnya dan membawa pembelajaran ke hadapan di antara langkah-langkah. Proses gelung tertutup, pembelajaran kendiri ini mengalihkan iterasi daripada pengguna kepada ejen itu sendiri, membolehkan hasil yang lebih pantas dan analisis yang konsisten berkualiti lebih tinggi berbanding aliran kerja manual.

Ejen ini merangkumi keseluruhan aliran kerja analitik: menemui data, menjalankan SQL, dan menerbitkan buku nota serta laporan. Ia memahami pengetahuan dalaman syarikat, boleh mencari maklumat luaran di web, dan bertambah baik dari masa ke masa melalui penggunaan dan ingatan yang dipelajari.

Jawapan berkualiti tinggi bergantung pada konteks yang kaya dan tepat. Tanpa konteks, walaupun model yang kuat boleh menghasilkan keputusan yang salah, seperti salah menganggarkan bilangan pengguna dengan ketara atau salah mentafsir terminologi dalaman.

Untuk mengelakkan mod kegagalan ini, ejen dibina berasaskan pelbagai lapisan konteks yang menghubungkannya dengan data dan pengetahuan institusi OpenAI.

• Pendasaran metadata: Ejen bergantung pada metadata skema (nama lajur dan jenis data) untuk memaklumkan penulisan SQL dan menggunakan salasilah jadual (contohnya, hubungan jadual hulu dan hilir) untuk memberikan konteks tentang bagaimana jadual yang berbeza saling berkaitan.
• Inferens pertanyaan: Mengambil pertanyaan sejarah membantu ejen memahami cara menulis pertanyaannya sendiri dan jadual mana yang biasanya digabungkan.

• Perihalan terpilih bagi jadual dan lajur yang disediakan oleh pakar domain, merakamkan niat, semantik, makna perniagaan, dan amaran yang diketahui yang tidak mudah disimpulkan daripada skema atau pertanyaan terdahulu.

Metadata sahaja tidak mencukupi. Untuk benar-benar membezakan jadual, anda perlu memahami bagaimana ia dicipta dan dari mana asalnya.

• Dengan memperoleh definisi tahap kod bagi sesebuah jadual, ejen membina pemahaman yang lebih mendalam tentang apa yang sebenarnya terkandung dalam data. 
  • Nuansa tentang apa yang disimpan dalam jadual dan bagaimana ia diperoleh daripada peristiwa analitik memberikan maklumat tambahan. Sebagai contoh, ia boleh memberikan konteks tentang keunikan nilai, kekerapan data jadual dikemas kini, skop data (contohnya, jika jadual mengecualikan medan tertentu, ia mempunyai tahap perincian ini), dan lain-lain.
• Ini menyediakan konteks penggunaan yang dipertingkatkan dengan menunjukkan bagaimana jadual digunakan melangkaui SQL dalam Spark, Python, dan sistem data lain.
• Ini bermakna bahawa ejen boleh membezakan antara jadual yang kelihatan serupa tetapi berbeza dalam cara yang penting. Sebagai contoh, ia boleh memberitahu sama ada jadual hanya merangkumi trafik ChatGPT pihak pertama. Konteks ini juga diperbaharui secara automatik, jadi ia kekal terkini tanpa perlu penyelenggaraan manual.

• Ejen boleh mengakses Slack, Google Docs, dan Notion, yang menangkap konteks syarikat yang kritikal seperti pelancaran, insiden kebolehpercayaan, nama kod dalaman dan alat, serta definisi kanonik dan logik pengiraan untuk metrik utama.
• Dokumen-dokumen ini dimasukkan, dibenamkan, dan disimpan dengan metadata dan keizinan. Perkhidmatan pengambilan mengurus kawalan akses dan caching semasa masa larian, membolehkan ejen menarik maklumat ini dengan cekap dan selamat.

• Apabila ejen diberikan pembetulan atau menemui nuansa tentang soalan data tertentu, ia dapat menyimpan pembelajaran ini untuk kali seterusnya, membolehkannya sentiasa bertambah baik bersama para penggunanya. 
  • Hasilnya, jawapan pada masa hadapan bermula daripada garis dasar yang lebih tepat dan bukannya berulang kali menghadapi isu yang sama.
  • Matlamat memori adalah untuk mengekalkan dan menggunakan semula pembetulan, penapis, dan kekangan yang tidak jelas yang penting untuk ketepatan data tetapi sukar untuk disimpulkan daripada lapisan lain sahaja. 
  • Sebagai contoh, dalam satu kes, ejen tidak tahu cara menapis untuk eksperimen analitik tertentu (ia bergantung pada pemadanan terhadap rentetan tertentu yang ditakrifkan dalam pintu eksperimen). Memori sangat penting di sini untuk memastikan ia dapat menapis dengan tepat, bukannya cuba memadankan rentetan secara samar.
• Apabila anda memberikan ejen pembetulan atau apabila ia menemui pembelajaran daripada perbualan anda, ia akan prom anda untuk menyimpan memori itu untuk kali seterusnya. 
  • Memori juga boleh dicipta dan disunting secara manual oleh pengguna.
  • Ingatan disusun pada peringkat global dan peribadi, dan alat ejen memudahkan penyuntingannya.

• Apabila tiada konteks terdahulu wujud untuk sesuatu jadual atau apabila maklumat sedia ada sudah lapuk, ejen boleh mengeluarkan pertanyaan langsung kepada gudang data untuk memeriksa dan membuat pertanyaan pada jadual tersebut secara langsung. Ini membolehkan ia mengesahkan skema, memahami data dalam masa sebenar, dan memberikan respons sewajarnya.
• Ejen juga boleh berkomunikasi dengan sistem Platform Data lain (perkhidmatan metadata, Airflow, Spark) mengikut keperluan untuk mendapatkan konteks data yang lebih luas yang wujud di luar gudang.

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⁠(dibuka dalam tetingkap baru) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(dibuka dalam tetingkap baru) (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⁠(dibuka dalam tetingkap baru) 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.