Bên trong tác nhân dữ liệu nội bộ của OpenAI

Dữ liệu thúc đẩy cách các hệ thống học hỏi, sản phẩm phát triển và các công ty đưa ra quyết định. Nhưng việc nhận được câu trả lời một cách nhanh chóng, chính xác và trong ngữ cảnh phù hợp thường khó hơn mức cần thiết. Để làm cho việc này dễ dàng hơn khi OpenAI mở rộng quy mô, chúng tôi đã phát triển một tác nhân dữ liệu AI nội bộ được thiết kế riêng để khám phá và suy luận trên nền tảng của chính chúng tôi.

Tác nhân của chúng tôi là một công cụ tùy chỉnh chỉ sử dụng nội bộ (không phải là một sản phẩm cung cấp ra bên ngoài), được xây dựng đặc biệt dựa trên dữ liệu, quyền và quy trình làm việc của OpenAI. Chúng tôi đang trình bày cách chúng tôi đã xây dựng và sử dụng nó để làm nổi bật các ví dụ về những cách thức thực tế, có tác động mà AI có thể hỗ trợ công việc hàng ngày trong các nhóm của chúng tôi. Các công cụ OpenAI mà chúng tôi đã sử dụng để xây dựng và vận hành nó (Codex, mô hình chủ lực GPT‑5 của chúng tôi, Evals API⁠(mở trong cửa sổ mới), và Embeddings API⁠(mở trong cửa sổ mới)) cũng là những công cụ mà chúng tôi cung cấp cho các nhà phát triển ở khắp mọi nơi.

Tác nhân dữ liệu của chúng tôi cho phép nhân viên chuyển từ câu hỏi đến thông tin chi tiết chỉ trong vài phút, không phải vài ngày. Điều này hạ thấp rào cản trong việc trích xuất dữ liệu và thực hiện phân tích tinh vi trên tất cả các bộ phận, không chỉ bởi đội ngũ dữ liệu của chúng tôi. Đến hiện nay, các nhóm thuộc Kỹ thuật, Khoa học Dữ liệu, Tiếp cận Thị trường, Tài chính và Nghiên cứu tại OpenAI dựa vào tác nhân để trả lời các câu hỏi dữ liệu có ảnh hưởng lớn. Chẳng hạn, nó có thể giúp trả lời cách đánh giá các lần ra mắt và hiểu tình hình sức khỏe của doanh nghiệp, tất cả thông qua định dạng trực quan của ngôn ngữ tự nhiên. Tác nhân kết hợp kiến thức cấp bảng được Codex hỗ trợ với bối cảnh sản phẩm và tổ chức. Hệ thống bộ nhớ liên tục học hỏi của nó có nghĩa là nó cũng cải thiện sau mỗi lượt.

Trong bài viết này, chúng tôi sẽ phân tích lý do vì sao chúng tôi cần một tác nhân dữ liệu AI được thiết kế riêng, điều gì khiến ngữ cảnh dữ liệu được làm giàu bằng mã và khả năng tự học của nó trở nên hữu ích, và những bài học chúng tôi đã học được trên chặng đường đó.

Nền tảng dữ liệu của OpenAI phục vụ hơn 3.500 người dùng nội bộ làm việc trong các nhóm Kỹ thuật, Sản phẩm và Nghiên cứu, bao phủ hơn 600 petabyte dữ liệu trên 70.000 bộ dữ liệu. Với quy mô đó, việc tìm kiếm bảng phù hợp có thể là một trong những phần tốn nhiều thời gian nhất khi thực hiện phân tích.

Như một người dùng nội bộ đã nhận xét:

“Chúng tôi có rất nhiều bảng khá giống nhau, và tôi mất rất nhiều thời gian để cố gắng tìm ra sự khác biệt giữa chúng và nên sử dụng bảng nào. Một số bao gồm người dùng đã đăng xuất, một số thì không. Một số có các trường chồng lấn; rất khó để phân biệt cái nào với cái nào.

Ngay cả khi đã chọn đúng các bảng, việc tạo ra kết quả chính xác vẫn có thể là một thách thức. Các nhà phân tích phải suy luận về dữ liệu bảng và mối quan hệ giữa các bảng để đảm bảo các phép biến đổi và bộ lọc được áp dụng chính xác. Các chế độ lỗi thường gặp—phép nối nhiều-nhiều, lỗi đẩy bộ lọc xuống, và các giá trị null không được xử lý—có thể âm thầm làm cho kết quả không còn hợp lệ. Ở quy mô của OpenAI, các nhà phân tích không nên phải tốn thời gian vào việc gỡ lỗi ngữ nghĩa SQL hoặc hiệu suất truy vấn: trọng tâm của họ nên là xác định các chỉ số, xác thực các giả định và đưa ra các quyết định dựa trên dữ liệu.

Hãy cùng tìm hiểu về tác nhân của chúng tôi là gì, cách nó tạo lập ngữ cảnh, và cách nó không ngừng tự cải thiện.

Tác nhân của chúng tôi được hỗ trợ bởi GPT‑5.2 và được thiết kế để suy luận trên nền tảng dữ liệu của OpenAI. Nó có sẵn ở bất cứ nơi nào nhân viên đã làm việc: dưới dạng một tác nhân Slack, thông qua giao diện web, bên trong các IDE, trong Codex CLI qua MCP⁠(mở trong cửa sổ mới), và trực tiếp trong ứng dụng ChatGPT nội bộ của OpenAI thông qua một trình kết nối MCP⁠(mở trong cửa sổ mới).

Người dùng có thể đặt những câu hỏi phức tạp và mở, mà thông thường sẽ cần nhiều vòng khám phá thủ công. Hãy xem xét ví dụ câu lệnh này, sử dụng một tập dữ liệu thử nghiệm: “Đối với các chuyến đi taxi ở NYC, những cặp mã ZIP từ điểm đón đến điểm trả nào là kém tin cậy nhất, với khoảng cách lớn nhất giữa thời gian di chuyển điển hình và trường hợp xấu nhất, và khi nào thì sự biến thiên đó xảy ra?”

Tác nhân xử lý phân tích từ đầu đến cuối, từ việc hiểu câu hỏi đến khám phá dữ liệu, chạy truy vấn và tổng hợp kết quả.

Một trong những siêu năng lực của tác nhân là cách nó suy luận để giải quyết vấn đề. Thay vì tuân theo một kịch bản cố định, tác nhân tự đánh giá tiến độ của mình. Nếu một kết quả trung gian có vẻ sai (ví dụ: nếu nó có 0 hàng do phép nối hoặc bộ lọc không chính xác), tác nhân sẽ điều tra nguyên nhân, điều chỉnh cách tiếp cận và thử lại. Xuyên suốt quá trình này, nó giữ nguyên đầy đủ ngữ cảnh và mang những kiến thức đã học được sang các bước tiếp theo. Quy trình vòng lặp khép kín, tự học này chuyển việc lặp lại từ người dùng sang chính tác nhân, cho phép đạt được kết quả nhanh hơn và các phân tích có chất lượng cao hơn một cách nhất quán so với các quy trình làm việc thủ công.

Tác nhân bao quát toàn bộ quy trình phân tích: khám phá dữ liệu, chạy SQL và xuất bản sổ tay và báo cáo. Nó hiểu kiến thức nội bộ của công ty, có thể tìm kiếm thông tin bên ngoài trên web, và cải thiện theo thời gian nhờ học hỏi từ việc sử dụng và bộ nhớ.

Câu trả lời chất lượng cao phụ thuộc vào ngữ cảnh phong phú và chính xác. Nếu thiếu bối cảnh, ngay cả các mô hình mạnh cũng có thể tạo ra kết quả sai, chẳng hạn như ước tính sai lệch lớn về số lượng người dùng hoặc hiểu sai thuật ngữ nội bộ.

Để tránh các chế độ lỗi này, tác nhân được xây dựng xoay quanh nhiều lớp ngữ cảnh giúp nó gắn kết với dữ liệu và tri thức tổ chức của OpenAI.

• Định hướng theo siêu dữ liệu: Tác nhân dựa vào siêu dữ liệu lược đồ (tên cột và kiểu dữ liệu) để định hướng việc viết SQL và sử dụng mối quan hệ bảng (ví dụ: các mối quan hệ bảng thượng nguồn và hạ nguồn) để cung cấp ngữ cảnh về cách các bảng khác nhau liên quan với nhau.
• Suy luận truy vấn: Việc nạp các truy vấn lịch sử giúp tác nhân hiểu cách viết các truy vấn của chính mình và những bảng nào thường được kết hợp với nhau.

• Mô tả được tuyển chọn về các bảng và cột do các chuyên gia trong lĩnh vực cung cấp, nắm bắt ý định, ngữ nghĩa, ý nghĩa kinh doanh và các điểm cần lưu ý đã biết mà không dễ suy ra từ lược đồ hoặc các truy vấn trước đây.

Chỉ mình metadata thì chưa đủ. Để thực sự phân biệt các bảng, bạn cần hiểu cách chúng được tạo ra và xuất xứ của chúng.

• Bằng cách suy ra một định nghĩa ở cấp độ mã của một bảng, tác nhân phát triển sự hiểu biết sâu sắc hơn về nội dung thực sự của dữ liệu. 
  • Các sắc thái về những gì được lưu trữ trong bảng và cách nó được suy ra từ một sự kiện phân tích mang lại thông tin bổ sung. Ví dụ, nó có thể cung cấp ngữ cảnh về tính duy nhất của các giá trị, tần suất cập nhật dữ liệu bảng, phạm vi của dữ liệu (ví dụ, nếu bảng loại trừ một số trường nhất định, thì nó có mức độ chi tiết như vậy), v.v.
• Điều này cung cấp ngữ cảnh sử dụng nâng cao bằng cách cho thấy cách bảng được sử dụng không chỉ trong SQL mà còn trong Spark, Python và các hệ thống dữ liệu khác.
• Điều này có nghĩa là tác nhân có thể phân biệt giữa các bảng trông giống nhau nhưng khác nhau theo những cách quan trọng. Ví dụ, nó có thể cho biết liệu một bảng chỉ bao gồm lưu lượng truy cập ChatGPT của bên thứ nhất. Ngữ cảnh này cũng được tự động làm mới, vì vậy nó luôn được cập nhật mà không cần bảo trì thủ công.

• Tác nhân có thể truy cập Slack, Google Docs và Notion, các nền tảng ghi lại bối cảnh quan trọng của công ty như các đợt ra mắt, sự cố về độ tin cậy, tên mã nội bộ và công cụ, cũng như các định nghĩa chuẩn và logic tính toán cho các chỉ số chính.
• Các tài liệu này được tiếp nhận, nhúng và lưu trữ cùng với siêu dữ liệu và quyền truy cập. Dịch vụ truy xuất quản lý quyền truy cập và bộ nhớ đệm trong thời gian chạy, cho phép tác nhân thu thập thông tin này một cách hiệu quả và an toàn.

• Khi tác nhân được cung cấp các chỉnh sửa hoặc phát hiện ra các sắc thái về một số câu hỏi dữ liệu nhất định, nó có thể lưu lại những điều học được này cho lần sau, cho phép nó liên tục cải thiện cùng với người dùng. 
  • Kết quả là, các câu trả lời trong tương lai sẽ bắt đầu từ một mốc tham chiếu chính xác hơn thay vì liên tục gặp phải cùng một vấn đề.
  • Mục tiêu của bộ nhớ là lưu giữ và tái sử dụng các chỉnh sửa, bộ lọc và ràng buộc không rõ ràng nhưng rất quan trọng đối với độ chính xác của dữ liệu, nhưng khó có thể suy ra chỉ từ các lớp khác. 
  • Ví dụ, trong một trường hợp, tác nhân không biết cách lọc cho một thử nghiệm phân tích cụ thể (nó dựa vào việc khớp với một chuỗi cụ thể được định nghĩa trong một cổng thử nghiệm). Bộ nhớ rất quan trọng ở đây để đảm bảo nó có thể lọc chính xác, thay vì cố gắng khớp chuỗi một cách mơ hồ.
• Khi bạn đưa cho tác nhân một chỉnh sửa hoặc khi tác nhân tìm thấy một điều rút ra từ cuộc trò chuyện của bạn, nó sẽ đưa ra câu lệnh để bạn lưu bộ nhớ đó cho lần sau. 
  • Bộ nhớ cũng có thể được người dùng tạo và chỉnh sửa thủ công.
  • Bộ nhớ được phân phạm vi ở cấp độ toàn cầu và cá nhân, và công cụ của tác nhân giúp dễ dàng chỉnh sửa chúng.

• Khi không có ngữ cảnh trước đó cho một bảng hoặc khi thông tin hiện có đã lỗi thời, tác nhân có thể thực hiện các truy vấn trực tiếp tới kho dữ liệu để kiểm tra và truy vấn bảng đó ngay lập tức. Điều này cho phép hệ thống xác thực các lược đồ, hiểu dữ liệu theo thời gian thực và phản hồi phù hợp.
• Tác nhân cũng có thể trao đổi với các hệ thống Data Platform khác (dịch vụ metadata, Airflow, Spark) khi cần để có được ngữ cảnh dữ liệu rộng hơn tồn tại bên ngoài kho dữ liệu.

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⁠(mở trong cửa sổ mới) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(mở trong cửa sổ mới) (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⁠(mở trong cửa sổ mới) 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.