เอเจนต์ข้อมูลภายในของ OpenAI

ข้อมูลเป็นพลังขับเคลื่อนให้ระบบต่างๆ เรียนรู้ ผลิตภัณฑ์พัฒนา และช่วยให้บริษัทต่างๆ ตัดสินใจได้อย่างเหมาะสม แต่การได้รับคำตอบอย่างถูกต้องรวดเร็ว และมีบริบทที่เหมาะสมนั่นไม่ใช่เรื่องง่าย เพื่อให้การขยายระบบง่ายขึ้น OpenAI จึงพัฒนาเอเจนต์ข้อมูล AI ภายในองค์กรแบบพิเศษ ที่สามารถสำรวจและให้เหตุผลเกี่ยวกับข้อมูลบนแพลตฟอร์มของเรา

เอเจนต์ของเราเป็นเครื่องมือเฉพาะภายในองค์กร (ไม่เปิดให้ภายนอกใช้งาน) สร้างขึ้นโดยเฉพาะสำหรับจัดการข้อมูล สิทธิ์การเข้าถึง และกระบวนงานของ OpenAI เรากำลังแสดงให้เห็นกระบวนการสร้างและการใช้งานเอเจนต์ เพื่อช่วยให้เห็นตัวอย่างที่สะท้อนผลลัพธ์จริงของการใช้ AI ในการสนับสนุนงานประจำวันทั่วทั้งองค์กร เครื่องมือของ OpenAI ที่เราใช้ในการสร้างและใช้งาน (Codex, โมเดลเรือธง GPT‑5 ของเรา, Evals API⁠(เปิดในหน้าต่างใหม่) และ Embeddings API⁠(เปิดในหน้าต่างใหม่)) เป็นเครื่องมือเดียวกันกับที่เราเปิดให้ใช้งานแก่นักพัฒนาทั่วโลก

เอเจนต์ข้อมูลของเราช่วยให้พนักงานเปลี่ยนคำถามเป็นข้อมูลเชิงลึกได้ภายในไม่กี่นาที แทนที่จะต้องรอนานหลายวัน สิ่งนี้ช่วยลดความยุ่งยากในการดึงข้อมูลและวิเคราะห์เชิงลึกในทุกฝ่าย ไม่จำกัดเพียงทีมข้อมูลของเราเท่านั้น วันนี้ทีมต่างๆ ในฝ่ายวิศวกรรม วิทยาศาสตร์ข้อมูล กลยุทธ์การเข้าสู่ตลาด การเงิน และการวิจัยที่ OpenAI พึ่งพาเอเจนต์ในการตอบ คำถามข้อมูลที่มีผลกระทบสูง ตัวอย่างเช่น ระบบนี้สามารถช่วยตอบคำถามเกี่ยวกับการประเมินการเปิดตัวและเข้าใจสถานะธุรกิจ ทั้งหมดผ่านภาษาธรรมชาติที่เข้าใจง่าย เอเจนต์ผสานรวมความรู้ระดับตารางที่ขับเคลื่อนด้วย Codex เข้ากับบริบทของผลิตภัณฑ์และองค์กร ระบบหน่วยความจำที่เรียนรู้อย่างต่อเนื่องช่วยให้มันปรับปรุงตัวเองได้ทุกครั้งที่โต้ตอบ

ในโพสต์นี้เราจะชี้แจงว่าทำไมจึงจำเป็นต้องมีเอเจนต์ข้อมูล AI เฉพาะตัว สิ่งที่ทำให้บริบทข้อมูลที่เสริมด้วยโค้ดและการเรียนรู้ด้วยตนเองมีประโยชน์ และบทเรียนที่เราได้เรียนรู้ระหว่างทาง

แพลตฟอร์มข้อมูลของ OpenAI ให้บริการแก่ผู้ใช้งานภายในมากกว่า 3,500 คน ที่ทำงานในฝ่ายวิศวกรรม ผลิตภัณฑ์ และการวิจัย โดยครอบคลุมข้อมูลมากกว่า 600 เพตะไบต์ จาก 70,000 ชุดข้อมูล การค้นหาตารางที่เหมาะสมในระดับนี้อาจเป็นหนึ่งในขั้นตอนที่ใช้เวลามากที่สุดในการทำการวิเคราะห์

ตามที่ผู้ใช้ภายในคนหนึ่งกล่าวไว้ว่า

“เรามีตารางข้อมูลหลายตารางที่ค่อนข้างคล้ายกัน และฉันต้องใช้เวลามากในการหาให้เจอว่าตารางไหนต่างกันอย่างไรและควรเลือกใช้อะไร บางตารางนับผู้ใช้ที่ยังไม่ได้เข้าสู่ระบบ ใขณะที่บางตารางก็ไม่นับ บางอันมีฟิลด์ทับซ้อนกัน ทำให้ยากที่จะบอกได้ว่าอะไรเป็นอะไร

ถึงแม้เลือกตารางถูกต้องแล้ว การได้ผลลัพธ์ที่ถูกต้องก็ยังเป็นเรื่องยาก นักวิเคราะห์ต้องพิจารณาข้อมูลในตารางและความสัมพันธ์ระหว่างตาราง เพื่อให้แน่ใจว่าการแปลงและตัวกรองถูกใช้อย่างถูกต้อง ปัญหาที่พบบ่อยอย่างการเชื่อมข้อมูลแบบ many-to-many การผลักตัวกรองผิดตำแหน่ง และค่า null ที่ไม่ได้จัดการ สามารถทำให้ผลลัพธ์ผิดได้แบบไม่รู้ตัว ในระดับของ OpenAI นักวิเคราะห์ไม่ควรต้องเสียเวลาไปกับการดีบักความหมายของ SQL หรือประสิทธิภาพของการคิวรี พวกเขาควรมุ่งเน้นไปที่การกำหนดตัวชี้วัด การตรวจสอบสมมติฐาน และการตัดสินใจโดยใช้ข้อมูล

มาดูกันว่าเอเจนต์ของเราคืออะไร จัดการบริบทอย่างไร และพัฒนาตัวเองอย่างต่อเนื่องได้อย่างไร

เอเจนต์ของเราขับเคลื่อนโดย GPT‑5.2 และออกแบบมาเพื่อวิเคราะห์ข้อมูลบนแพลตฟอร์มของ OpenAI พร้อมใช้งานได้ในทุกที่ที่พนักงานทำงานอยู่แล้ว ไม่ว่าจะเป็นเอเจนต์ใน Slack ผ่านอินเทอร์เฟซเว็บ ภายใน IDEs เอเจนต์ใน Codex CLI ผ่าน MCP⁠(เปิดในหน้าต่างใหม่) และแอป ChatGPT ภายในของ OpenAI ผ่านตัวเชื่อมต่อ MCP⁠(เปิดในหน้าต่างใหม่)

ผู้ใช้สามารถถามคำถามที่ซับซ้อนและปลายเปิดได้ แม้ปกติจะต้องใช้การสำรวจหลายรอบกว่าจะหาคำตอบเจอ ยกตัวอย่างคำสั่งนี้ซึ่งใช้ชุดข้อมูลทดสอบ: “สำหรับการเดินทางด้วยแท็กซี่ในนิวยอร์กซิตี้ คู่รหัสไปรษณีย์ระหว่างจุดรับถึงจุดส่งใดที่ไม่น่าเชื่อถือที่สุด โดยมีช่องว่างระหว่างเวลาเดินทางทั่วไปกับกรณีเลวร้ายที่สุดมากที่สุด และความแปรปรวนนั้นเกิดขึ้นเมื่อใด”

เอเจนต์จัดการการวิเคราะห์ตั้งแต่ต้นจนจบ ตั้งแต่การทำความเข้าใจคำถาม การสำรวจข้อมูล การรันคิวรี และการสังเคราะห์ข้อค้นพบ

จุดเด่นหนึ่งของเอเจนต์คือการวิเคราะห์และใช้เหตุผลแก้ปัญหา แทนที่จะทำตามสคริปต์ที่กำหนดไว้ เอเจนต์จะประเมินความก้าวหน้าของตนเอง หากผลลัพธ์ระหว่างทางดูผิดปกติ (เช่น มีแถวเป็นศูนย์เพราะการเชื่อมข่อมูล หรือฟิลเตอร์ผิด) เอเจนต์จะตรวจสอบว่าเกิดอะไรผิดพลาด ปรับวิธีการ แล้วลองใหม่อีกครั้ง ตลอดกระบวนการนี้ระบบจะรักษาบริบททั้งหมดไว้ และนำสิ่งที่เรียนรู้ไปใช้ในขั้นตอนถัดไป กระบวนการ แบบวงจรปิดที่เรียนรู้ด้วยตนเอง ย้ายการลองผิดลองถูกจากผู้ใช้ไปอยู่ในเอเจนต์แทน ทำให้ได้ผลลัพธ์เร็วขึ้นและการวิเคราะห์มีคุณภาพสูงกว่าวิธีทำมือ

เอเจนต์ครอบคลุมเวิร์กโฟลว์การวิเคราะห์แบบครบวงจร ไม่ว่าจะเป็นการค้นหาข้อมูล การรัน SQL และการเผยแพร่โน้ตบุ๊กและรายงาน เอเจนต์เข้าใจข้อมูลภายในองค์กร สามารถค้นหาข้อมูลภายนอกทางเว็บและพัฒนาขึ้นเรื่อยๆ ผ่านการเรียนรู้จากการใช้งานและหน่วยความจำ

คำตอบคุณภาพสูงขึ้นอยู่กับ บริบทที่สมบูรณ์และถูกต้อง แม้แต่โมเดลที่มีประสิทธิภาพสูงก็อาจให้ผลลัพธ์ที่ผิดพลาดได้หากขาดบริบท เช่น การประเมินจำนวนผู้ใช้ที่คลาดเคลื่อนอย่างมาก หรือการตีความคำศัพท์ภายในที่ผิดพลาด

เพื่อหลีกเลี่ยงโหมดความล้มเหลวเหล่านี้ เอเจนต์จึงถูกสร้างขึ้นโดยมี บริบทหลายชั้นที่ยึดโยงกับข้อมูลและความรู้องค์กรของ OpenAI

• การยึดโยงกับ Metadata: เอเจนต์อาศัย Metadata ของ Schema (ชื่อคอลัมน์และชนิดข้อมูล) เพื่อช่วยในการเขียน SQL และใช้ Lineage ของตาราง (เช่น ความสัมพันธ์ของตารางต้นทางและปลายทาง) เพื่อให้บริบทว่าตารางต่างๆ เชื่อมโยงกันอย่างไร
• การอนุมานคิวรี: การนำเข้าคิวรีในอดีตช่วยให้เอเจนต์เข้าใจวิธีการเขียนคิวรีของตนเองและตารางที่มักจะถูกเชื่อมต่อกัน

• คำอธิบายที่คัดสรรมาแล้ว ของตารางและคอลัมน์ที่จัดทำโดยผู้เชี่ยวชาญในสาขา โดยถ่ายทอดเจตนา ความหมายเชิงนัย ความหมายทางธุรกิจ และข้อควรระวังที่ทราบซึ่งไม่สามารถอนุมานได้ง่ายจาก Schema หรือคำสั่งที่เคยใช้ในอดีต

ข้อมูล Metadata เพียงอย่างเดียวไม่เพียงพอ การแยกความต่างของตารางให้ถูกต้องต้องเข้าใจกระบวนการสร้างและแหล่งที่มาของแต่ละตาราง

• โดยการสร้างนิยามของตารางในระดับโค้ด เอเจนต์จะพัฒนาความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับเนื้อหาที่ข้อมูลมีอยู่จริง 
  • รายละเอียดเชิงลึกเกี่ยวกับข้อมูลที่จัดเก็บในตารางและวิธีที่ได้มาจากเหตุการณ์การวิเคราะห์ช่วยเพิ่มข้อมูลประกอบ ตัวอย่างเช่น มันสามารถให้บริบทเกี่ยวกับความแตกต่างของค่า ความถี่ในการอัปเดตข้อมูล และขอบเขตของข้อมูล (เช่นถ้าตารางตัดบางฟิลด์ออก ความละเอียดของข้อมูลก็จะอยู่ในระดับนั้น) เป็นต้น
• ข้อมูลนี้ช่วยเสริมบริบทการใช้งาน โดยแสดงการใช้ตารางนอก SQL เช่น ใน Spark, Python และระบบข้อมูลอื่นๆ
• ซึ่งหมายความว่าเอเจนต์สามารถแยกแยะระหว่างตารางที่ดูคล้ายกันแต่แตกต่างกันในประเด็นสำคัญ ตัวอย่างเช่น ระบบสามารถบอกได้ว่าตารางมีเฉพาะทราฟฟิก ChatGPT แบบ First-Party หรือไม่ บริบทนี้จะได้รับการรีเฟรชโดยอัตโนมัติ ดังนั้นจึงมีความทันสมัยอยู่เสมอโดยไม่ต้องบำรุงรักษาด้วยตนเอง

• เอเจนต์สามารถเข้าถึง Slack, Google Docs และ Notion ซึ่งรวบรวมบริบทสำคัญของบริษัท เช่น การเปิดตัว เหตุการณ์ด้านความน่าเชื่อถือ โค้ดเนมและเครื่องมือภายใน และคำนิยามที่เป็นมาตรฐาน รวมถึงตรรกะการคำนวณสำหรับเมตริกหลัก
• เอกสารเหล่านี้ถูกป้อน ฝัง และจัดเก็บพร้อมข้อมูล Metadata และสิทธิ์การเข้าถึง บริการการดึงข้อมูลจัดการการควบคุมการเข้าถึงและการแคชในขณะรันไทม์ ทำให้เอเจนต์สามารถดึงข้อมูลนี้ได้อย่างมีประสิทธิภาพและปลอดภัย

• เมื่อเอเจนต์ได้รับการแก้ไขหรือค้นพบรายละเอียดเฉพาะเกี่ยวกับคำถามข้อมูลบางอย่าง มันสามารถบันทึกความรู้นั้นไว้ใช้ครั้งต่อไป ทำให้พัฒนาต่อเนื่องไปพร้อมกับผู้ใช้ 
  • ดังนั้นคำตอบครั้งถัดไปจะมีความแม่นยำตั้งแต่ต้น แทนที่จะเจอข้อผิดพลาดเดิมซ้ำอีก
  • เป้าหมายของหน่วยความจำคือเก็บรักษาและนำการแก้ไข ตัวกรอง และข้อจำกัดที่ไม่ชัดเจนกลับมาใช้ซ้ำ ซึ่งสำคัญต่อความถูกต้องของข้อมูลแต่ยากที่จะสรุปจากเลเยอร์อื่นเพียงอย่างเดียว
  • ยกตัวอย่างเช่น ในกรณีหนึ่งเอเจนต์ไม่สามารถกรองข้อมูลสำหรับการทดลองวิเคราะห์เฉพาะได้ (มันพึ่งพาการจับคู่กับสตริงเฉพาะที่กำหนดใน Experiment Gate) หน่วยความจำมีความสำคัญมากในกรณีนี้ เพื่อช่วยให้เอเจนต์กรองข้อมูลอย่างแม่นยำ แทนที่จะพยายามจับคู่สตริงแบบคลุมเครือ
• เมื่อคุณให้แก้ไขเอเจนต์หรือเมื่อเอเจนต์พบสิ่งที่เรียนรู้จากบทสนทนา มันจะถามว่าต้องการบันทึกความรู้นั้นไว้ใช้ครั้งถัดไปหรือไม่ 
  • ผู้ใช้สามารถสร้างและแก้ไขหน่วยความจำด้วยตนเองได้เช่นกั
  • หน่วยความจำครอบคลุมทั้งระดับทั่วโลกและระดับบุคคล และเครื่องมือเอเจนต์ทำให้การแก้ไขรวดเร็วและสะดวก

• เมื่อตารางไม่มีบริบทก่อนหน้า หรือเมื่อข้อมูลที่มีอยู่ล้าสมัย เอเจนต์สามารถส่งคำสั่งคิวรีแบบสดไปยังคลังข้อมูลเพื่อทำการตรวจสอบและคิวรีตารางนั้นโดยตรง งนี้ทำให้เอเจนต์สามารถตรวจสอบ Schema เข้าใจข้อมูลแบบเรียลไทม์ และตอบสนองตามข้อมูล
• เอเจนต์ยังสื่อสารกับระบบอื่นของ Data Platform (เช่น บริการ Metadata, Airflow และ Spark) เพื่อดึงบริบทข้อมูลที่อยู่นอกคลังข้อมูลได้ตามต้องการ

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⁠(เปิดในหน้าต่างใหม่) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(เปิดในหน้าต่างใหม่) (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⁠(เปิดในหน้าต่างใหม่) 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.