動動嘴寫SQL！Codex+終身記憶，OpenAI把查詢難度直接歸零

新智元報道

編輯：peter東

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

為什么數據團隊總在「踩同一個坑」？

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

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

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

數據查詢不再需要手動查表

「我們有大量結構相似的表，我花費大量時間試圖弄清楚它們之間的區別以及該使用哪個。」一位OpenAI工程師的日常抱怨，道出了數據工作者的共同困境。

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

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

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

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

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

六層架構的「數據大腦」

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

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

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

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

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

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

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

而最關鍵的第五層學習進化，讓智能體擁有持久的記憶。當它從用戶那里獲得糾正，或發現數據問題的細微差別時，能夠保存這些經驗供下次使用。記憶也可以由用戶手動創建和編輯。可以全局適用，也可以是只獨屬于某個使用者。

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

離線檢索與在線查詢間的動態切換

而上述6層系統，是在如何協同工作的？

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

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

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

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

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

從靜態工具到動態隊友的范式轉變

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

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

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

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

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

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

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

怎么搭建一個數據分析智能體

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

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

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

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

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

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

參考資料：

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

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