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

新智元報道

編輯：peter東

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在其一層是人工標(biāo)注，是由領(lǐng)域?qū)＜揖木帉懙谋砗土忻枋觯蹲揭鈭D、語義、業(yè)務(wù)含義以及無法從模式或歷史查詢中輕松推斷的已知注意事項。這一層相當(dāng)于給智能體對每個表的信息進(jìn)行了基礎(chǔ)培訓(xùn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考資料：

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

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