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

新智元報(bào)道

編輯：peter東

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

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

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

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

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

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

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

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

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

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

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

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

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

將自然語(yǔ)言變成SQL語(yǔ)句，這樣的工具很多，而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ǔ)義、業(yè)務(wù)含義以及無(wú)法從模式或歷史查詢中輕松推斷的已知注意事項(xiàng)。這一層相當(dāng)于給智能體對(duì)每個(gè)表的信息進(jìn)行了基礎(chǔ)培訓(xùn)。

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

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

有了通過(guò)外在文本獲取的背景信息，智能體就不會(huì)犯下常識(shí)性錯(cuò)誤。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考資料：

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

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