የOpenAI ውስጣዊ የውሂብ ወኪል ውስጥ

ውሂብ ሥርዓቶች እንዴት እንደሚማሩ፣ ምርቶች እንዴት እንደሚሻሻሉ እና ኩባንያዎች እንዴት ምርጫዎችን እንደሚያደርጉ ያጎላል። ነገር ግን መልሶችን በፍጥነት፣ በትክክል እና በትክክለኛው አውድ ማግኘት ብዙውን ጊዜ ከሚገባው በላይ ከባድ ነው። ይህንን ቀላል ለማድረግ፣ የOpenAI ሚዛንን በመጠበቅ፣ የራሳችንን መድረክ የሚዳስስ እና ምክንያቶችን የሚጠቀም የራሳችንን ብጁ የውስጥ ሰው ሠራሽ አስተውሎት (AI) ውሂብ ወኪል ገንብተናል።

ወኪላችን በተለይ በOpenAI ውሂብ፣ ፈቃዶች እና የሥራ ፍሰቶች ዙሪያ የተገነባ ብጁ ውስጣዊ ብቻ መሣሪያ ነው (ውጫዊ አቅርቦት አይደለም)። እንዴት እንደገነባነው እና እንደምንጠቀምበት እያሳየን ነው እና ሰው ሠራሽ አስተውሎት (AI) በቡድኖቻችን ውስጥ የዕለት ተዕለት ሥራን ለመደገፍ እውነተኛ እና ውጤታማ መንገዶችን ምሳሌዎችን ለማሳየት እንጠቀምበታለን። ለመገንባትና ለማስኬድ የተጠቀምንባቸው የOpenAI መሣሪያዎች (Codex፣ የGPT‑5 ባንዲራ ሞዴል፣ የEvals API⁠(በአዲስ መስኮት ውስጥ ይክፈታል) እና የEmbeddings API⁠(በአዲስ መስኮት ውስጥ ይክፈታል)) በየቦታው ላሉ ገንቢዎች የምናቀርባቸው ተመሳሳይ መሣሪያዎች ናቸው።

የውሂብ ወኪላችን ሠራተኞችን ከጥያቄ ወደ ማስተዋል በቀናት ሳይሆን፣ በደቂቃዎች እንዲሄዱ ያስችላቸዋል። ይህ የውሂብ ቡድናችን ብቻ ሳይሆን በሁሉም ተግባራት ላይ ውሂብን እና ጥልቅ ትንታኔን የመሳብ ገደብን ይቀንሳል። ዛሬ፣ በOpenAI ውስጥ በኢንጂነሪንግ፣ በውሂብ ሳይንስ፣ ወደ ገበያ ይሂዱ፣ በፋይናንስ እና በምርምር ላይ ያሉ ቡድኖች ከፍተኛ ተጽዕኖ ፈጣሪ የሆኑ የውሂብ ጥያቄዎችን ለመመለስ በወኪሉ ላይ ይደገፋሉ። ለምሳሌ፣ የንግድ ሥራ ጅምርን እንዴት መገምገም እና የንግድ ጤናን መረዳት እንደሚቻል ለመመለስ ይረዳል፣ ይህም በተፈጥሮ ቋንቋ ሊታወቅ በሚችል ቅርጸት ነው። ወኪሉ በCodex የሚመራ የጠረጴዛ ደረጃ እውቀትን ከምርት እና ከድርጅታዊ አውድ ጋር ያጣምራል። የማስታወስ ሥርዓቱን ያለማቋረጥ መማር ማለት በእያንዳንዱ ዙር እየተሻሻለ ማለት ነው።

በዚህ ልጥፍ ውስጥ፣ ለምን ልዩ የሰው ሠራሽ አስተውሎት (AI) ውሂብ ወኪል እንዳስፈለገን፣ ኮድ የበለጸገ የውሂብ አውድ እና ራስ-መማር ለምን እንደሚጠቅሙ እንዲሁም በመንገድ ላይ ያወራነውን ትምህርቶች እንመለከታለን።

የOpenAI የውሂብ መድረክ በምህንድስና፣ በምርት እና በምርምር ዘርፍ የሚሠሩ ከ3.5ሺህ በላይ የውስጥ ተጠቃሚዎችን ያገለግላል፣ በ70ሺህ የውሂብ ስብስቦች ውስጥ ከ600 ፔታባይት በላይ ውሂቦችን ይይዛል። በዚያ መጠን፣ ትክክለኛውን ሠንጠረዥ ማግኘት ብቻ ትንታኔ ለማድረግ በጣም ጊዜ የሚወስድ ክፍል ሊሆን ይችላል።

አንድ የውስጥ ተጠቃሚ እንዳስቀመጠው፦

«በጣም ተመሳሳይ የሆኑ ብዙ ሠንጠረዦች አሉን፣ እና እነሱ እንዴት እንደሚለያዩ እና የትኛውን መጠቀም እንዳለብኝ ለማወቅ ብዙ ጊዜ እጅግ እያሳለፍኩ ነው። አንዳንዶቹ ከመለያ የወጡ ተጠቃሚዎችን ያካትታሉ፣ አንዳንዶቹ ግን አይደሉም። አንዳንዶቹ ተደራራቢ መስኮች አሏቸው፤ ምን እንደሆነ ለመለየት አስቸጋሪ ነው።»

ትክክለኛዎቹ ሠንጠረዦች ቢመረጡም እንኳ ትክክለኛ ውጤቶችን ማግኘት ፈታኝ ሊሆን ይችላል። ተንታኞች የለውጦች እና የማጣሪያዎች በትክክል መተገበራቸውን ለማረጋገጥ የሠንጠረዥ ውሂብ እና የሠንጠረዥ ግንኙነቶችን ማመዛዘን አለባቸው። የተለመዱ የውድቀት ሁነታዎች—ከብዙ እስከ ብዙ መጋጠሚያዎች፣ የማጣሪያ ግፊት ዳውን ስህተቶች እና ያልተያዙ ባዶዎች—ውጤቶችን በፀጥታ ሊያበላሹ ይችላሉ። በOpenAI ሚዛን፣ ተንታኞች የSQL ትርጉሞችን ወይም የጥያቄ አፈጻጸምን ለማረም ጊዜ ማባከን የለባቸውም፤ ትኩረታቸው መለኪያዎችን በመግለፅ፣ ግምቶችን በማረጋገጥ እና በውሂብ ላይ የተመሰረቱ ውሳኔዎችን በማድረግ ላይ መሆን አለበት።

ወኪላችን ምን እንደሆነ፣ አውዱን እንዴት እንደሚያስተካክል እና እራሱን እንዴት እንደሚያሻሽል እንመልከት።

ወኪላችን በGPT‑5.2 የተጎላበተ ሲሆን የOpenAI የውሂብ መድረክን ለማመዛዘን የተነደፈ ነው። ሠራተኞች አስቀድመው በሚሠሩበት ቦታ ሁሉ ይገኛል፦ እንደ Slack ወኪል፣ በድር በይነገጽ በኩል፣ በIDEዎች ውስጥ፣ በMCP በኩል በኮዴክስ CLI⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ውስጥ እና በቀጥታ በOpenAI ውስጣዊ የChatGPT መተግበሪያ ውስጥ በMCP ማገናኛ በኩል⁠(በአዲስ መስኮት ውስጥ ይክፈታል)።

ተጠቃሚዎች ውስብስብ እና ክፍት ጥያቄዎችን መጠየቅ ይችላሉ፣ ይህም በተለምዶ ብዙ ዙሮችን በእጅ ማሰስ የሚጠይቁ ናቸው። የፈተና ውሂብ ስብስብን የሚጠቀመውን ይህንን ምሳሌ እንውሰድ፦ «ለNYC ከተማ የታክሲ ጉዞዎች፣ የትኞቹ የፖስታ-ወደ-ማውረድ ዚፕ ጥንዶች በጣም አስተማማኝ አይደሉም፣ በተለመደው እና በመጥፎ የጉዞ ጊዜዎች መካከል ትልቁ ክፍተት አላቸው፣ እና ያ ተለዋዋጭነት መቼ ይከሰታል?»

ወኪሉ ከጥያቄው መረዳት ጀምሮ እስከ መረጃውን እስከ መመርመር፣ ጥያቄዎችን እስከማሄድ እና ግኝቶችን እስከማዋሃድ ድረስ ትንታኔውን ከዳር እስከ ዳር ያስተናግዳል።

የወኪሉ ልዕለ ኃያላን አንዱ በችግሮች ውስጥ እንዴት እንደሚያመዛዝን ነው። ቋሚ ስክሪፕት ከመከተል ይልቅ፣ ወኪሉ የራሱን እድገት ይገመግማል። መካከለኛ ውጤት የተሳሳተ መስሎ ከታየ (ለምሳሌ፣ በተሳሳተ መቀላቀል ወይም ማጣሪያ ምክንያት ዜሮ ረድፎች ካሉት)፣ ወኪሉ ምን እንደተሳሳተ ይመረምራል፣ አቀራረቡን ያስተካክላል እና እንደገና ይሞክራል። በዚህ ሂደት ውስጥ፣ ሙሉ አውዱን ይይዛል፣ እና በደረጃዎች መካከል ትምህርቶችን ወደፊት ያስተላልፋል። ይህ የተዘጋ ዑደት፣ ራስን የመማር ሂደት ከተጠቃሚው ወደ ወኪል ራሱ ድግግሞሽን ያሸጋግራል፣ ይህም በእጅ ከሚሠሩ የሥራ ፍሰቶች ይልቅ ፈጣን ውጤቶችን እና በተከታታይ ከፍተኛ ጥራት ያላቸውን ትንታኔዎች ያስችላል።

ወኪሉ ሙሉውን የትንታኔ ሂደት ይሸፍናል፦ ውሂብ ማግኘት፣ SQL ማስኬድ እና ማስታወሻ ደብተሮችን እና ሪፖርቶችን ማተም። የኩባንያ ውስጣዊ እውቀትን ይረዳል፣ ውጫዊ መረጃን በድር ላይ መፈለግ ይችላል፣ እና ከጊዜ በኋላ በተማርነው አጠቃቀም እና በማስታወስ ይሻሻላል።

ከፍተኛ ጥራት ያላቸው መልሶች በበለጸገ እና ትክክለኛ አውድ ላይ የተመሰረቱ ናቸው። ያለ አውድ፣ ጠንካራ ሞዴሎች እንኳን የተሳሳቱ ውጤቶችን ሊያስገኙ ይችላሉ፣ ለምሳሌ የተጠቃሚዎችን ብዛት በእጅጉ በተሳሳተ መንገድ መገመት ወይም ውስጣዊ ቃላትን በተሳሳተ መንገድ መረዳት።

እነዚህን የውድቀት ሁነታዎች ለማስወገድ፣ ወኪሉ የተገነባው በOpenAI ውሂብ እና በተቋማዊ እውቀት ላይ የተመሰረቱ በርካታ የአውድ ንብርብሮችን በመጠቀም ነው።

• የዲበ ውሂብ መሰረት፦ወኪሉ የSQL ጽሑፍን ለማሳወቅ በእቅድ ማውጣት ዲበ ውሂብ (የአምድ ስሞች እና የውሂብ ዓይነቶች) ላይ የተመሰረተ ሲሆን የተለያዩ ሠንጠረዦች እንዴት እንደሚዛመዱ አውድ ለማቅረብ የሠንጠረዥ መስመርን (ለምሳሌ፣ የላይኛው እና የታችኛው የሠንጠረዥ ግንኙነቶችን) ይጠቀማል።
• የጥያቄ ማጠቃለያ፦ታሪካዊ ጥያቄዎችን መምጠጥ ወኪሉ የራሱን ጥያቄዎች እንዴት እንደሚጽፍ እና የትኞቹ ሠንጠረዦች በተለምዶ አንድ ላይ እንደሚጣመሩ እንዲረዳ ይረዳል።

• በጎራ ባለሙያዎች የቀረቡ የጠረጴዛዎች እና የአምዶች ዝርዝር መግለጫዎች፣ ከእቅድ ማውጣት ወይም ካለፉ ጥያቄዎች በቀላሉ የማይገመቱ ሀሳቦችን፣ ፍቺዎችን፣ የንግድ ሥራ ትርጉምን እና የታወቁ ማስጠንቀቂያዎችን ይይዛሉ።

ዲበ ውሂብ ብቻ በቂ አይደለም። ሠንጠረዦችን በትክክል ለመለየት፣ እንዴት እንደተፈጠሩ እና ከየት እንደመጡ መረዳት ያስፈልግዎታል።

• የሠንጠረዥን የኮድ ደረጃ ፍቺ በማውጣት፣ ወኪሉ ውሂቡ በትክክል ምን እንደያዘ ጥልቅ ግንዛቤን ይገነባል። 
  • በሠንጠረዡ ውስጥ የተከማቸው ነገር እና ከትንታኔ ክስተት እንዴት እንደሚገኝ የሚያሳዩት ልዩነቶች ተጨማሪ መረጃ ይሰጣሉ። ለምሳሌ፣ የእሴቶች ልዩነት፣ የሠንጠረዥ መረጃው በምን ያህል ጊዜ እንደሚዘመን፣ የውሂብ ወሰን (ለምሳሌ፣ ሠንጠረዡ የተወሰኑ መስኮችን የማያካትት ከሆነ፣ ይህ የንዑስ ደረጃ አለው)፣ ወዘተ ላይ አውድ ሊሰጥ ይችላል።
• ይህ በSpark፣ Python እና በሌሎች የውሂብ ሥርዓቶች ውስጥ ሠንጠረዡ ከSQL ባሻገር እንዴት ጥቅም ላይ እንደሚውል በማሳየት የተሻሻለ የአጠቃቀም አውድ ይሰጣል።
• ይህ ማለት ወኪሉ ተመሳሳይ የሚመስሉ ነገር ግን ወሳኝ በሆኑ መንገዶች የሚለያዩ ሠንጠረዦችን መለየት ይችላል ማለት ነው። ለምሳሌ፣ አንድ ሠንጠረዥ የመጀመሪያ ወገን የChatGPT ትራፊክን ብቻ እንደሚያካትት ማወቅ ይችላል። ይህ አውድ በራስ-ሰር ይታደሳል፣ ስለዚህ በእጅ ጥገና ሳይደረግ ወቅታዊ ሆኖ ይቆያል።

• ወኪሉ Slack፣ Google Docs እና Notionን ማግኘት ይችላል፣ እነዚህም እንደ ጅምር፣ የአስተማማኝነት ክስተቶች፣ የውስጥ የኮድ ስሞች እና መሣሪያዎች ያሉ ወሳኝ የኩባንያ አውዶችን እና ቁልፍ መለኪያዎችን ለማግኘት ቀኖናዊ ትርጓሜዎችን እና የስሌት አመክንዮዎችን ይይዛሉ።
• እነዚህ ሰነዶች በውስጥ የተዋጡ፣ የተካተቱ እና በዲበ ውሂብ እና በፈቃዶች የተከማቹ ናቸው። የማግኛ አገልግሎት በአሂድ ጊዜ የመዳረሻ ቁጥጥርን እና መሸጎጫን ያስተናግዳል፣ ይህም ወኪሉ ይህንን መረጃ በብቃት እና ደኅንነቱ በተጠበቀ ሁኔታ እንዲስብ ያስችለዋል።

• ወኪሉ ስለተወሰኑ የውሂብ ጥያቄዎች እርማቶች ሲሰጠው ወይም ልዩነቶችን ሲያገኝ፣ እነዚህን ትምህርቶች ለቀጣዩ ጊዜ ማስቀመጥ ይችላል፣ ይህም ከተጠቃሚዎቹ ጋር ያለማቋረጥ እንዲሻሻል ያስችለዋል። 
  • በዚህም ምክንያት፣ የወደፊት መልሶች የሚጀምሩት ተመሳሳይ ችግሮችን በተደጋጋሚ ከማጋጠም ይልቅ ከትክክለኛ መነሻ ነጥብ ነው።
  • የማህደረ ትውስታ ግብ ለውሂብ ትክክለኛነት ወሳኝ የሆኑ ነገር ግን ከሌሎች ንብርብሮች ብቻ ለመረዳት አስቸጋሪ የሆኑ ግልፅ ያልሆኑ እርማቶችን፣ ማጣሪያዎችን እና ገደቦችን ማቆየት እና እንደገና መጠቀም ነው። 
  • ለምሳሌ፣ በአንድ ሁኔታ፣ ወኪሉ ለተወሰነ የትንታኔ ሙከራ እንዴት ማጣራት እንዳለበት አያውቅም ነበር (በሙከራ በር ውስጥ ከተገለጸው የተወሰነ ሕብረቁምፊ ጋር በማዛመድ ላይ የተመሰረተ ነው)። እዚህ ማህደረ ትውስታ በጣም አስፈላጊ ነበር እንዲችል በትክክል ማጣራት እንጂ በድብዝዝ ሁኔታ የሕብረቁምፊ ማዛመድ ለመሞከር አይደለም።
• ወኪሉ እርምጃ ሲሰጡት ወይም ከውይይትዎ ትምህርት ሲያገኝ፣ ለቀጣዩ ጊዜ ያንን ማህደረ ትውስታ እንዲያስቀምጡ ይጠይቅዎታል። 
  • ትዝታዎች በተጠቃሚዎች በእጅ ሊፈጠሩ እና ሊስተካከሉ ይችላሉ።
  • ትዝታዎች በዓለም አቀፍ እና በግል ደረጃ ይወሰናሉ፣ እና የወኪሉ መሣሪያዎች እነሱን ለማረም ቀላል ያደርጉታል።

• ለሠንጠረዥ ቀዳሚ አውድ ከሌለ ወይም ነባር መረጃ የቆየ ከሆነ፣ ወኪሉ ሠንጠረዡን በቀጥታ ለመመርመር እና ለመጠየቅ ወደ የውሂብ መጋዘኑ የቀጥታ ጥያቄዎችን ማቅረብ ይችላል። ይህ እቅድ ማውጣት እንዲያረጋግጥ፣ ውሂቡን በእውነተኛ ጊዜ እንዲረዳ እና በዚሁ መሠረት ምላሽ እንዲሰጥ ያስችለዋል።
• ወኪሉ ከመጋዘኑ ውጭ ያለውን ሰፊ የውሂብ አውድ ለማግኘት እንደ አስፈላጊነቱ ከሌሎች የውሂብ መድረክ ሥርዓቶች (ዲበ ውሂብ አገልግሎት፣ የአየር ፍሰት፣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.