OpenAI-ийн дотоод өгөгдлийн агентын дотор

Өгөгдөл нь системүүд хэрхэн суралцдаг, бүтээгдэхүүнүүд хэрхэн хөгждөг, компаниуд хэрхэн шийдвэр гаргадагийг тэтгэдэг. Гэвч хариултыг хурдан, зөв, зөв контексттэйгээр олох нь байх ёстойгоосоо илүү хэцүү байх нь олонтаа. OpenAI өргөжин тэлэхийн хэрээр үүнийг хялбарчлахын тулд бид манай өөрсдийн тусгай дотоод AI өгөгдлийн агент-ыг бүтээсэн бөгөөд энэ нь манай платформ дээр судалж, сэтгэн боддог.

Манай агент нь OpenAI-ийн өгөгдөл, зөвшөөрөл, workflow-уудад тусгайлан тохируулж бүтээгдсэн, зөвхөн дотоод хэрэглээний зориулалттай хэрэгсэл (гадаад санал болголт биш) юм. Бид үүнийг хэрхэн бүтээж, ашиглаж байгаагаа харуулж, AI нь манай багуудын өдөр тутмын ажлыг бодитоор, нөлөөтэйгээр хэрхэн дэмжиж чаддгийг харуулах жишээ гаргахыг зорьж байна. Үүнийг бүтээж, ажиллуулахад ашигласан OpenAI-ийн хэрэгслүүд (Codex, манай GPT‑5 тэргүүлэх загвар, Evals API⁠(шинэ цонхонд нээгдэнэ), болон Embeddings API⁠(шинэ цонхонд нээгдэнэ)) нь бидний дэлхий даяарх хөгжүүлэгчдэд нээлттэй болгосон ижил хэрэгслүүд юм.

Манай өгөгдлийн агент ажилтнуудад асуултаас ойлголт руу өдрөөр биш, хэдхэн минутад хүрэх боломж олгодог. Ингэснээр зөвхөн манай өгөгдлийн баг бус, бүх чиг үүргийн хүмүүс өгөгдөл татах, нарийн шинжилгээ хийх босгыг бууруулж байна. Өнөөдөр OpenAI-ийн Инженерчлэл, Data Science, Go-To-Market, Санхүү, Судалгааны багууд өндөр нөлөөтэй өгөгдлийн асуултуудад хариу авахын тулд агентэд түшиглэдэг. Жишээ нь, энэ нь нээлтүүдийг хэрхэн үнэлэх, бизнесийн эрүүл мэндийг ойлгоход тусалж чадна—энэ бүхнийг байгалийн хэлний ойлгомжтой хэлбэрээр. Агент нь Codex-оор дэмжигдсэн хүснэгтийн түвшний мэдлэгийг бүтээгдэхүүн болон байгууллагын контексттэй хослуулдаг. Түүний тасралтгүй суралцдаг дурсамжийн систем нь эргэлт бүрээр улам сайжирдаг гэсэн үг.

Энэ нийтлэлд бид яагаад тусгай AI өгөгдлийн агент хэрэгтэй болсон, түүний кодоор баяжуулсан өгөгдлийн контекст болон өөрөө суралцах чадвар нь юугаараа тустай вэ, мөн энэ замд бид ямар сургамж авснаа тайлбарлана.

OpenAI-ийн өгөгдлийн платформ нь Инженерчлэл, Бүтээгдэхүүн, Судалгааны чиглэлд ажилладаг 3.5k-аас дээш дотоод хэрэглэгчид үйлчилдэг бөгөөд 70k dataset-д тархсан 600 петабайт-аас дээш өгөгдлийг хамардаг. Ийм хэмжээнд зөв хүснэгтийг олох нь шинжилгээ хийх хамгийн их цаг авдаг хэсгүүдийн нэг болж хувирдаг.

Нэг дотоод хэрэглэгчийн хэлснээр:

“Манайд хоорондоо нэлээд төстэй маш олон хүснэгт байдаг, би тэдгээр нь юугаараа өөр, алийг нь ашиглахаа ойлгоход асар их цаг зарцуулдаг. Заримд нь системээс гараагүй хэрэглэгчид ордог, заримд нь ордоггүй. Зарим нь давхцсан талбаруудтай; яг юу нь юу вэ гэдгийг ойлгоход хэцүү.”

Зөв хүснэгтүүдийг сонгосон ч зөв үр дүн гаргах нь хэцүү хэвээр байж болно. Шинжээчид хувиргалт, шүүлтүүрүүдийг зөв хэрэглэж байгааг батлахын тулд хүснэгтийн өгөгдөл болон хүснэгтүүдийн харилцааг тунгаан бодох шаардлагатай. Олон-олонтой join, filter pushdown алдаа, боловсруулаагүй null зэрэг нийтлэг алдааны горимууд нь үр дүнг анзаарагдалгүй хүчингүй болгож чадна. OpenAI-ийн ийм цар хүрээнд шинжээчид SQL семантик эсвэл query гүйцэтгэлийг засахад цагаа үрэх ёсгүй: тэд metric-үүдийг тодорхойлох, таамаглалуудыг батлах, өгөгдөлд тулгуурласан шийдвэр гаргахад анхаарах ёстой.

Манай агент юу болох, контекстыг хэрхэн цэгцэлдэг, өөрийгөө хэрхэн байнга сайжруулдгийг хамтдаа үзье.

Манай агент GPT‑5.2-оор ажилладаг бөгөөд OpenAI-ийн өгөгдлийн платформ дээр сэтгэн бодохоор бүтээгдсэн. Энэ нь ажилтнуудын аль хэдийн ажиллаж байгаа бүх газарт нээлттэй: Slack агент, вэб интерфэйс, IDE-үүдийн дотор, MCP-ээр дамжих Codex CLI⁠(шинэ цонхонд нээгдэнэ), мөн MCP connector-оор OpenAI-ийн дотоод ChatGPT апп дотор⁠(шинэ цонхонд нээгдэнэ).

Хэрэглэгчид ердийн үед олон үеийн гар ажиллагаатай хайгуул шаарддаг төвөгтэй, нээлттэй асуултуудыг асууж болно. Туршилтын өгөгдлийн багцыг ашигласан энэ жишээ өгөгдлийг авч үзье: “NYC таксины trip-үүдийн хувьд ердийн ба хамгийн муу тохиолдлын аяллын хугацааны хоорондох хамгийн их зөрүүтэй, хамгийн найдваргүй pickup-to-dropoff ZIP хосууд аль нь вэ, мөн энэ хэлбэлзэл хэзээ тохиолддог вэ?”

Агент шинжилгээг төгсгөлөөс төгсгөл хүртэл удирдана—асуултыг ойлгохоос эхлээд өгөгдлийг судлах, query ажиллуулах, олдворуудыг нэгтгэн дүгнэх хүртэл.

Агентын супер чадваруудын нэг нь асуудлыг хэрхэн тунгаан боддогод оршдог. Тогтсон скрипт дагахын оронд агент өөрийн ахицыг өөрөө үнэлдэг. Хэрэв завсрын үр дүн буруу харагдвал (ж.нь., буруу join эсвэл шүүлтүүрээс болж мөрийн тоо тэг болсон бол) агент юу буруу болсныг шалгаж, арга барилаа засч, дахин оролддог. Энэ бүх явцад тэр бүрэн контекстыг хадгалж, алхмуудын хооронд сурсан зүйлсээ авч явдаг. Энэ хаалттай циклтэй, өөрөө суралцдаг үйл явц нь давталтыг хэрэглэгчээс агент руу шилжүүлж, гар ажиллагаатай workflow-оос илүү хурдан үр дүн, тогтмол өндөр чанартай шинжилгээг боломжтой болгодог.

Агент нь analytics workflow-ийг бүтнээр нь хамардаг: өгөгдөл хайх, SQL ажиллуулах, notebook болон тайлан нийтлэх. Энэ нь компанийн дотоод мэдлэгийг ойлгодог, гадаад мэдээлэлд вэб хайлт хийж чаддаг, мөн сурсан хэрэглээ ба дурсамжаар дамжин цаг хугацааны явцад сайжирдаг.

Өндөр чанартай хариулт нь баялаг, үнэн зөв контекст-ээс хамаардаг. Контекстгүй бол хүчтэй загварууд хүртэл хэрэглэгчийн тоог асар ихээр буруу тооцох эсвэл дотоод нэр томьёог буруу ойлгох зэрэг буруу үр дүн гаргаж чадна.

Эдгээр алдааны горимоос зайлсхийхийн тулд агент нь түүнийг OpenAI-ийн өгөгдөл болон байгууллагын мэдлэг дээр үндэслэлтэй болгодог олон давхар контекст-ийн эргэн тойронд бүтээгдсэн.

• Metadata үндэслэл: Агент SQL бичихдээ схемийн metadata-д (баганын нэрс ба өгөгдлийн төрлүүд) тулгуурладаг бөгөөд хүснэгтийн lineage-ийг (ж.нь., upstream ба downstream хүснэгтийн харилцаа) ашиглан өөр хүснэгтүүд хэрхэн холбоотойг ойлгох контекст өгдөг.
• Query inference: Түүхэн query-үүдийг шингээж авах нь агентэд өөрийн query-г хэрхэн бичих, ямар хүснэгтүүд ихэвчлэн хамт join хийгддэгийг ойлгоход тусалдаг.

• Схем эсвэл өмнөх query-уудаас амархан дүгнэх боломжгүй зорилго, семантик, бизнесийн утга, мэдэгдэж буй анхааруулгуудыг агуулсан, домэйн мэргэжилтнүүдийн өгсөн хүснэгт ба баганын нягтлан боловсруулсан тайлбарууд.

Зөвхөн metadata хангалтгүй. Хүснэгтүүдийг үнэхээр ялгаж танихын тулд тэдгээрийг хэрхэн бүтээсэн, хаанаас үүсэлтэйг ойлгох хэрэгтэй.

• Хүснэгтийн кодын түвшний тодорхойлолтыг гаргаж авснаар агент өгөгдөл яг юуг агуулж байгааг илүү гүн ойлгодог. 
  • Хүснэгтэд яг юу хадгалагддаг, analytics event-ээс хэрхэн үүсдэг талаарх нарийн ялгаанууд нь нэмэлт мэдээлэл өгдөг. Жишээ нь, утгуудын давтагдашгүй байдал, хүснэгтийн өгөгдөл хэр ойрхон шинэчлэгддэг, өгөгдлийн хамрах хүрээ (ж.нь., хүснэгт тодорхой талбаруудыг хасдаг бол ямар нарийвчлалтай вэ) гэх мэт контекст өгч чадна.
• Энэ нь хүснэгт SQL-ээс цааш Spark, Python болон бусад өгөгдлийн системүүдэд хэрхэн ашиглагддагийг харуулснаар хэрэглээний илүү баяжуулсан контекст өгдөг.
• Ингэснээр агент гадаад төрхөөрөө төстэй ч чухал талаараа ялгаатай хүснэгтүүдийг ялгаж чадна. Жишээ нь, хүснэгт зөвхөн ChatGPT‑ийн first-party урсгалыг багтааж байгаа эсэхийг таньж чадна. Энэ контекст мөн автоматаар шинэчлэгддэг тул гар ажиллагаатай арчилгаагүйгээр шинэ хэвээр үлддэг.

• Агент Slack, Google Docs, Notion-д хандаж чаддаг бөгөөд эдгээрт нээлтүүд, найдвартай байдлын зөрчил, дотоод код нэрүүд ба хэрэгслүүд, мөн гол metric-үүдийн canonical тодорхойлолт ба тооцооллын логик зэрэг компанийн чухал контекст агуулагддаг.
• Эдгээр баримтуудыг metadata болон зөвшөөрлийн хамт шингээж, embedding хийж, хадгалдаг. Татан авах үйлчилгээ нь ажиллах үеийн хандалтын хяналт ба cache-ийг удирдаж, агент энэ мэдээллийг үр ашигтай, аюулгүй татаж ашиглах боломжийг олгодог.

• Агентэд засвар өгсөн эсвэл тодорхой өгөгдлийн асуултуудын нарийн ялгааг олж мэдсэн үедээ эдгээр сургамжийг дараа ашиглахаар хадгалж чаддаг тул хэрэглэгчидтэйгээ хамт байнга сайжирдаг. 
  • Үүний үр дүнд дараагийн хариултууд нэг ижил асуудалтай дахин дахин тулгарахын оронд илүү зөв сууринаас эхэлдэг.
  • Дурсамжийн зорилго нь өгөгдлийн зөв байдалд чухал боловч бусад давхаргаас дангаар нь дүгнэхэд хэцүү, илт биш засвар, шүүлтүүр, хязгаарлалтуудыг хадгалж, дахин ашиглах явдал юм. 
  • Жишээ нь, нэг тохиолдолд агент тодорхой analytics experiment-ийг хэрхэн шүүхээ мэдэхгүй байсан (энэ нь experiment gate-д тодорхойлсон тодорхой мөртэй тааруулахад тулгуурлаж байсан). Энд дурсамж маш чухал байсан бөгөөд ингэснээр агент бүдэг бадаг мөр тааруулах гэж оролдохын оронд зөв шүүж чадсан.
• Та агентэд засвар өгөх эсвэл тэр ярианаас тань шинэ сургамж олж мэдэх үедээ түүнийг дараагийн удаад хадгалахыг санал болгоно. 
  • Дурсамжийг хэрэглэгчид гараар үүсгэж, засварлаж мөн болно.
  • Дурсамжууд нь глобал болон хувийн түвшинд хүрээгээр хуваагддаг бөгөөд агентын tooling нь тэдгээрийг засахыг хялбар болгодог.

• Хүснэгтэд өмнөх контекст огт байхгүй эсвэл одоо байгаа мэдээлэл хуучирсан үед агент өгөгдлийн агуулах руу шууд query илгээж, хүснэгтийг шууд шалгаж, query хийж чадна. Энэ нь түүнд схемүүдийг батлах, өгөгдлийг бодит цагт ойлгох, түүнд нийцүүлэн хариулах боломж олгодог.
• Агент мөн агуулахаас гадуур байдаг илүү өргөн өгөгдлийн контекст авахын тулд шаардлагатай үед Data Platform-ийн бусад системүүдтэй (metadata service, 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.