新智元報道

編輯：peter東

【新智元導讀】2026年初，當大多數(shù)企業(yè)還在用數(shù)據(jù)分析師手動寫SQL查表時，OpenAI內部曝光的能自主思考、推理甚至自我進化的數(shù)據(jù)分析智能體，將數(shù)據(jù)查詢從「天數(shù)級」縮短至「分鐘級」。

為什么數(shù)據(jù)團隊總在「踩同一個坑」？

答案往往不是算力不夠多，而是表太多、定義太多、經(jīng)驗散落太多：

同樣叫「活躍用戶」，不同表的口徑可能完全不一樣；即便選對表，也要寫出上百行 SQL 才能跑出結果，錯一個連接條件就前功盡棄。

在內部，OpenAI做了一件更激進的事：讓 Codex 驅動的數(shù)據(jù)智能體接管「找表—懂表—寫SQL—校驗結果」這條鏈路，用一套六層上下文架構，把數(shù)據(jù)語義補齊、把組織知識接入、把經(jīng)驗記憶沉淀，讓工程師用提問取代搬磚。

數(shù)據(jù)查詢不再需要手動查表

「我們有大量結構相似的表，我花費大量時間試圖弄清楚它們之間的區(qū)別以及該使用哪個?！挂晃籓penAI工程師的日常抱怨，道出了數(shù)據(jù)工作者的共同困境。

OpenAI內部數(shù)據(jù)平臺的600PB數(shù)據(jù)，分布在7萬個數(shù)據(jù)集中，想象一下：當OpenAI的工程師需要分析ChatGPT用戶增長時，面對數(shù)十個相似的用戶表，每個表都聲稱記錄「用戶活躍度」，但定義卻各不相同。

選錯表意味著數(shù)天的努力付諸東流，更糟糕的是可能基于錯誤數(shù)據(jù)做出關鍵決策。

更令人頭疼的是，即使選對了表格，生成正確結果也充滿挑戰(zhàn)。

下圖中展示的一個180多行的SQL語句，像一座難以逾越的大山——復雜的表連接、聚合操作，任何一個細微錯誤都可能導致整個分析失效。

而現(xiàn)在有了由 Codex 驅動，具有自主學習能力的智能體，工程師不必寫上百行的SQL查詢語句，只需要提問就能從數(shù)據(jù)海洋中找到所需的信息，例如下圖查詢中要求對比兩個時間點的活躍用戶數(shù)。

六層架構的「數(shù)據(jù)大腦」

將自然語言變成SQL語句，這樣的工具很多，而OpenAI內部使用的數(shù)據(jù)智能體，其核心創(chuàng)新在于其多層上下文架構。

最底層的基礎元數(shù)據(jù)包括表結構、列類型等基礎信息，為智能體提供數(shù)據(jù)圖譜的骨架。

在其一層是人工標注，是由領域專家精心編寫的表和列描述，捕捉意圖、語義、業(yè)務含義以及無法從模式或歷史查詢中輕松推斷的已知注意事項。這一層相當于給智能體對每個表的信息進行了基礎培訓。

之后的Codex增強通過推導表的代碼級定義，讓智能體能夠更深入地理解數(shù)據(jù)實際內容。這一層提供了關于值唯一性、表數(shù)據(jù)更新頻率、數(shù)據(jù)范圍等關鍵信息。這一層的引入，讓智能體能夠明白不同表在構建，更新上的差異。

再往上的機構知識層，智能體可以訪問Slack、Google Docs和Notion，獲取關鍵的公司背景信息，如產(chǎn)品發(fā)布、可靠性事件、內部代號和工具，以及關鍵指標的規(guī)范定義和計算邏輯。

有了通過外在文本獲取的背景信息，智能體就不會犯下常識性錯誤。

例如，當用戶詢問「12月連接器使用量為何大幅下降」時，智能體沒有簡單地報告數(shù)字下降，而是通過機構知識發(fā)現(xiàn)這主要是測量/日志記錄問題，而非真正的使用量崩潰，與ChatGPT 5.1發(fā)布導致的數(shù)據(jù)收集變化相關。

而最關鍵的第五層學習進化，讓智能體擁有持久的記憶。當它從用戶那里獲得糾正，或發(fā)現(xiàn)數(shù)據(jù)問題的細微差別時，能夠保存這些經(jīng)驗供下次使用。記憶也可以由用戶手動創(chuàng)建和編輯?？梢匀诌m用，也可以是只獨屬于某個使用者。

而最上一層的運行時上下文，能夠讓智能體在沒有現(xiàn)有上下文或現(xiàn)有信息過時時，通過實時查詢數(shù)據(jù)倉庫，直接檢查和查詢表。它還能夠與其他數(shù)據(jù)平臺系統(tǒng)（元數(shù)據(jù)服務、Airflow、Spark）通信以獲取更廣泛的數(shù)據(jù)上下文。

離線檢索與在線查詢間的動態(tài)切換

而上述6層系統(tǒng)，是在如何協(xié)同工作的？

具體可分為離線和在線兩步。

每天凌晨，智能體會系統(tǒng)性地掃描昨天成千上萬張數(shù)據(jù)表的實際用法與調用軌跡，汲取數(shù)據(jù)專家們留下的批注與洞察，并調用Codex來解讀代碼深處的邏輯，衍生出表格背后更豐富的業(yè)務語義。所有這些散落的「知識碎片」被融合成一個統(tǒng)一、標準化的「知識圖譜」。

隨后，通過OpenAI的嵌入模型，被轉化、壓縮為一組組向量嵌入，存入高速檢索庫中。至此，一個為AI智能體準備的、立即可用的「數(shù)據(jù)記憶宮殿」便鑄造完成。

當用戶的一個問題抵達時，智能體不再需要像人類分析師那樣，一頭扎入元數(shù)據(jù)的汪洋大海進行耗時的手工打撈。而是通過檢索增強生成技術，精準定位并提取出與當前問題最相關的數(shù)據(jù)表。這個過程快速、可擴展，且延遲極低。

而對于那些需要最新數(shù)據(jù)的請求，智能體則同步啟動實時查詢通道，直接向數(shù)據(jù)倉庫發(fā)起查詢請求，由此既實現(xiàn)了運行時上下文的即時性，又能做到與離線知識的深度結合。于是，一個復雜的業(yè)務問題，便在離線記憶的「閃電檢索」與實時數(shù)據(jù)的「精確制導」協(xié)同下，化為秒級可得的清晰洞察。

從靜態(tài)工具到動態(tài)隊友的范式轉變

這個智能體最令人驚嘆的，不是它的技術復雜度，而是它如何融入日常工作流程，成為真正的「隊友」。與傳統(tǒng)的「一問一答」式工具不同，OpenAI內部使用的數(shù)據(jù)分析智能體被設計為「可以與之推理的隊友」。它是對話式的、始終在線的，既能處理快速答案，也能處理迭代探索。

想象這樣一個場景：一個產(chǎn)品經(jīng)理的提問不明確或不完整時，智能體會主動提出澄清問題。如果沒有回應，它會應用合理的默認值來推進工作。例如，如果用戶詢問關于業(yè)務增長但沒有指定日期范圍，它可能會假設最近七天或三十天。這讓智能體能夠保持一邊回復，一邊與用戶合作得到更準確的結果。

而為了避免不斷進化的智能體在學習過程中跑偏，OpenAI團隊利用EvalsAPI為智能體配備了一位嚴格的監(jiān)管者。

Evals API每個重要問題都配有手動編寫的，可作為「黃金標準」查詢語句，智能體的表現(xiàn)被持續(xù)監(jiān)控和評分。

這些評估不僅檢查SQL語法正確性，還比較結果數(shù)據(jù)的準確性。當智能體「學壞」時，系統(tǒng)會立即發(fā)出警報，確保問題在影響用戶前被發(fā)現(xiàn)和修復。

而在數(shù)據(jù)安全方面，該智能體規(guī)定用戶只能查詢他們已經(jīng)有權訪問的表。當訪問權限缺失時，它會標記這一點或回退到用戶被授權使用的替代數(shù)據(jù)集。

而為了確保數(shù)據(jù)分析的過程透明，智能體會在每個答案旁邊總結假設和執(zhí)行步驟來暴露其推理過程。當查詢被執(zhí)行時，它直接鏈接到底層結果，允許用戶檢查原始數(shù)據(jù)并驗證分析的每個步驟。

怎么搭建一個數(shù)據(jù)分析智能體

OpenAI的上述數(shù)據(jù)分析智能體，并沒有開源，不過若想手搓一個類似的智能體，OpenAI的工程師也給出了其中踩過的坑。

最初，智能體能訪問到完整的數(shù)據(jù)集，但這很快讓智能體迷失在功能重疊數(shù)據(jù)表中。為了減少歧義并提高可靠性，開發(fā)者不得不對智能體能訪問的數(shù)據(jù)表進行了限制，由此減少歧義，提高查詢的可靠性。

另一個坑來自開發(fā)者給出的高度規(guī)范的系統(tǒng)提示詞。雖然許多問題共享類似的分析形狀，但細節(jié)變化足夠大，以至于僵化的指令會適得其反。當關注點轉向真實使用時的效果時，將如何實現(xiàn)交由智能體而非系統(tǒng)級提示詞決定，會讓智能體變得更加穩(wěn)健，產(chǎn)生更好的結果。

而最關鍵的一點，是意識到相比專家對數(shù)據(jù)表給出標注，數(shù)據(jù)的真正意義存在于代碼中。查詢歷史更精準地描述表的形狀和用法，能捕獲了從未在SQL或元數(shù)據(jù)中浮現(xiàn)的假設與業(yè)務意圖。通過使用Codex爬取代碼庫，智能體能理解數(shù)據(jù)集實際如何構建，并能夠更好地推理每個表實際包含的內容。與僅從數(shù)據(jù)倉庫中獲取信息相比，構建數(shù)據(jù)的代碼能更準確地回答「這表里有什么」和「我何時可以使用它」。

隨著企業(yè)數(shù)據(jù)環(huán)境日益復雜，類似OpenAI數(shù)據(jù)智能體的工具可能成為未來企業(yè)數(shù)據(jù)分析的標準配置，推動整個行業(yè)向更高效、更智能的數(shù)據(jù)驅動決策范式轉變。

這些智能體的目標不是替代數(shù)據(jù)分析師，而是增強其能力，將數(shù)據(jù)分析師從繁瑣的查詢編寫和調試中解放出來，專注于更高級別的定義指標、驗證假設和制定數(shù)據(jù)驅動決策。

參考資料：

https://openai.com/index/inside-our-in-house-data-agent/

https://x.com/OpenAIDevs/status/2016943147239329872