談談緣何元數據死灰復燃

一家金融公司的AI項目，準確率從40%飆到87%，只改了一樣東西——不是模型，不是算力，而是元數據。

這事得從一個真實案例説起。

一家頭部金融機構，去年上了一套AI智能問答系統，想讓業務方直接問數據："東南區上季度銷售額下降了多少？""這個產品線退貨率為什麼突然變高？"

技術團隊用的是最主流的方案：用户提問 → 大模型轉SQL → 數據倉庫執行 → 返回結果。團隊用了最好的模型，調了三輪prompt，信心滿滿地上線。

兩周后，準確率不到40%。

問題出在哪？不是模型不夠聰明，是大模型根本不認識這家公司的數據。

公司里有6張表都叫"銷售相關"，大模型不知道該選哪張；"東南區"按哪個字段定義？省份還是大區代碼？"銷售額"是含税還是不含税？是已開票還是已回款？這些信息，人類分析師靠經驗和部門里的口口相傳都能搞定，但AI agent沒有同事可以問。

它能依賴的只有一種東西：結構化的、機器可讀的、能在毫秒內被檢索到的元數據。

團隊重做了系統。把所有業務定義、字段口徑、表歸屬、質量標籤、血緣關係全部喂進元數據平臺，然后讓agent在生成SQL之前先做一步"上下文檢索"——從元數據系統里拉出相關的上下文。

準確率從40%跳到87%。

這個故事揭示了一個正在發生的深刻變化：元數據，這個被行業嫌棄了十幾年的"倉庫管理員"，正在AI時代迎來第二春。

用四個字形容就是——死灰復燃。

一、元數據是怎麼"死"的

先説"死"的部分。

元數據——關於數據的數據——在數據領域已經存在了三十多年。但長期以來，它在企業里的處境可以用三個詞概括：重要、無聊、沒人管。

上世紀90年代，元數據就是數據庫的"説明書"。管理員手工錄入字段描述，批量更新，年度審計。開發者改了表結構，沒人去同步元數據系統。三個月后去看，發現里面描述全是錯的。整個行業都接受了這個現實——元數據是"參考資料"，不是"事實"。

到了大數據時代，LinkedIn做了DataHub，Lyft做了Amundsen，Uber做了Databook。這些工具解決了"數據資產有哪些"的問題，但本質依然是被動的、給人查詢的。一個數據分析師有需求 → 去目錄里搜 → 找到表 → 寫SQL。整個流程由人發起，元數據只是中間的導航工具。

數據管道跑得再快，元數據更新依然周期性同步、有時差、有遺漏。兩條軌道，互不干擾。

於是，元數據管理變成了一個典型的"吃力不討好"的活：花錢做沒人看，不做也沒人投訴。很多企業的數據治理團隊，元數據頁面常年掛着"建設中"的橫幅，最終淪為擺設。

但就在大家以為元數據會這樣温水煮青蛙般沉淪下去時，AI來了。

二、四個時代，一次反轉

元數據的"死灰復燃"不是突然爆發的，而是一場三十年的量變引發的質變。我們可以清晰地看到四個時代：

第一代：説明書時代（1990s-2000s）

代表產品是Informatica、IBM InfoSphere。元數據本質上是給IT部門用的數據庫schema文檔系統。純文檔、手工錄入、和數據運行完全解耦。一句話總結：給IT人看的説明書。

第二代：治理入口時代（2010s-2020s初）

Hadoop和數據湖興起，數據量從TB跳到PB。LinkedIn做了DataHub，Apache Atlas成為治理框架。元數據從"文檔"變成"治理入口"——開始有數據目錄、有血緣關係、有數據資產盤點。但依然是被動記錄，主要給人搜索用。

第三代：協作層時代（2020s中）

Snowflake、dbt、Airflow等工具組合流行，數據團隊不再只有工程師，分析師、產品經理都參與進來。Gartner提出"主動元數據"（Active Metadata）概念——元數據通過事件流實時更新，不只是給人看，機器也在消費。元數據變成了"數據基礎設施的神經系統"。

第四代：上下文圖譜時代（2026至今）

大模型和AI Agent進入企業。元數據不再只是治理工具，而是AI理解企業數據的"上下文層"。OpenMetadata 1.13版本直接內置了知識圖譜，把表、字段、血緣、Owner、術語、分類全部放成一張可推理的網絡。Google Cloud把Knowledge Catalog定位為"面向AI Agent的企業上下文引擎"。

四個時代的演變可以用一張表概括：

注意最后一行的變化——服務對象從"人"變成了"AI Agent為主"。這不是漸進式改良，而是範式反轉。

三、數據變成了元數據的副產品

這句話聽起來很反直覺，但站在AI Agent的視角看，它極其準確。

過去三十年的工作流程是這樣的：業務需求 → 設計數據模型 → 建數據倉庫 → 跑管道 → 產生數據 → 寫文檔 → 錄入元數據。元數據永遠是流程的最后一步、補救步、可選步。"數據優先，元數據其次"。

但在AI Agent落地的場景里，流程悄悄變成了：業務需求 → 設計Agent任務 → 定義Agent需要的上下文 → 檢查元數據是否完備 → 不完備的部分回頭補元數據 → Agent跑起來 → 數據被消費。

元數據反而變成了第一公民。Agent能不能跑、跑得好不好、結果能不能信，根本不取決於"數據是否存在"——數據早就存在了。它取決於"元數據是否完備到Agent能正確理解和使用這些數據"。

數據是燃料，元數據是導航+油表+儀表盤+副駕駛。沒有元數據，再多的數據對Agent來説都是"無法消費的暗物質"。

Gartner有個很扎心的預測：到2026年，60%的AI項目會被放棄，主要原因不是模型質量，而是上下文和數據準備的差距。

更有説服力的證據來自Meta。2026年4月，Meta發佈了一篇博客——他們爲了讓AI Agent能正確修改一個跨4個代碼庫、3種語言、4100+文件的大規模數據管道，專門搞了一套"50+個AI Agent組成的預計算引擎"。這些Agent唯一的工作就是讀所有代碼，然后生成59份結構化文件，把工程師腦子里的"部落知識"轉化成AI可讀的上下文。

最終效果：AI Agent的工具調用次數減少40%，覆蓋率從5%提升到100%。

在Meta這種頂級技術公司，已經開始投入巨大的工程資源，專門為AI Agent生產元數據。不是爲了人，是爲了Agent。

這就是範式反轉的最清晰證據——元數據的生產，已經從"數據團隊的副業"變成了"AI項目的主線工作"。

四、從"主動"到"自主"：下一站是Agentic Metadata

第三代元數據的關鍵詞是Active（活的、實時的），而第四代的關鍵詞正在變成Agentic（自主的、可推理的、雙向交互的）。

三個信號説明這個趨勢已經發生：

信號一：MCP正在成為元數據系統的標準接口。

DataHub在2026年初已經把MCP Server作為元數據系統的標準API之一，Atlan也跟進了。這意味着以后所有AI Agent框架都可以通過MCP直接查詢企業的元數據系統。元數據系統正在變成"企業數據的USB-C接口"——任何AI工具都能即插即用。

信號二：元數據系統開始嵌入Agent自身。

DataHub自己在目錄里跑Agent，用來自動做schema推斷、自動寫表描述、自動檢測異常血緣、自動給字段打敏感數據標籤。Atlan的AI Copilot在做同樣的事。元數據系統不再只是被動響應查詢，而是主動產出和維護自己的元數據——它本身變成了一個Agent。

信號三：Context Engineer正在變成一個獨立工種。

DataHub的2026報告顯示，95%的數據團隊計劃在2026年投資Context Engineering培訓。Context Engineer的工作不是寫SQL、不是建倉庫，而是設計"Agent應該看到什麼上下文、什麼時候看到、如何被維護更新、如何在多步推理中動態裁剪"。

更有意思的是——這個角色最有競爭力的人選，不是來自AI圈，是來自數據工程圈。因為做Context Engineering需要的核心能力是：理解企業數據怎麼組織的、各表的真實業務含義、數據質量陷阱在哪、不同系統如何串聯。這些能力，AI工程師沒有，但每一個有5年經驗的數據工程師都有。

五、元數據市場數據

市場數據也在印證這一趨勢：

全球元數據管理工具市場規模在2024年已達116.9億美元，預計到2030年增長至364.4億美元，年複合增長率20.9%。Gartner在時隔五年后重新發布了元數據管理魔力象限報告，明確將元數據定位為"AI就緒的基礎"。

市場上也出現了一系列併購整合：ServiceNow收購了data.world，Coalesce收購了CastorDoc，Salesforce正在收購Informatica。微軟與Informatica和Solidatus建立生態合作，GCP與Atlan和Collibra深度綁定。

Gartner還預測，到2027年，採用主動元數據實踐的組織將能把新數據資產的交付時間縮短70%。而到2026年，採用主動元數據的組織將增加到30%。

元數據市場正在從"可選項"變成"AI戰略的必選項"。

六、五類元數據，缺一不可

現代元數據管理已遠不止"表結構描述"那麼簡單。企業需要管理五類元數據，每類服務不同場景：

這五類元數據中，"行為元數據"是最新出現的——它記錄的是人和AI Agent如何實際使用數據。當你知道某個數據集被AI Agent每周調用500次，而另一個數據集三個月沒人碰過，治理優先級就不用爭論了。

七、AI時代的血緣革命

元數據"死灰復燃"的另一個維度，是血緣關係的革命性擴展。

傳統血緣只回答一個問題：數據從哪來，流向哪去。但AI時代新增了兩類完全不同的血緣：

機器學習血緣：訓練數據 → 特徵 → 模型版本 → 推理服務 → 業務決策。模型輸出錯了，需要知道它用了哪些數據訓練。

RAG知識血緣：知識文檔 → Chunk → Embedding → 向量庫 → RAG應用 → 回答結果。AI回答錯了，需要知道它引用了哪些文檔、哪些切片、哪個版本的向量索引。

這意味着未來企業需要管理的血緣類型從"數據血緣"一種，擴展到至少六種：數據血緣、模型血緣、特徵血緣、知識血緣、Prompt血緣、Agent行為血緣。元數據平臺從"數據目錄"被推向更廣泛的企業上下文圖譜。

Databricks的Unity Catalog已經走在了前面——它把數據和AI治理放在統一框架下，能夠捕獲查詢運行時血緣，支持到列級，包含Notebook、Job、Dashboard等上下文。這是行業方向。

八、三個判斷和一個窗口

最后，我對元數據未來三年的發展做幾個判斷。

判斷一：元數據系統的預算將從CDO轉移到CAIO。

過去元數據系統的預算來自首席數據官，是數據治理項目的一部分。未來預算會越來越多來自首席AI官——因為AI項目能否落地，前置條件就是元數據是否完備。沒有完備的元數據層，所有AI Agent都只能停留在Demo階段。

判斷二："上下文層"會成為繼數據湖、湖倉之后的下一個基礎設施層。

企業數據架構經歷了：數據倉庫（面向報表）→ 數據湖（面向多樣化數據）→ 湖倉（融合分析與機器學習）→ 上下文層（面向AI Agent）。上下文層不替代湖倉，而是建在湖倉之上，專門用於服務AI Agent的語義、治理、上下文供給。未來三年，所有頭部企業都會有一個"首席上下文架構師"或類似角色。

判斷三：元數據的消費者會發生結構性轉移——從人為主，到機器為主。

今天元數據系統的查詢量可能95%是人發起的。三年后，這個比例會反過來——95%的查詢是AI Agent發起的。這個轉變會帶來元數據系統設計的根本性變化：從"UI優先"變成"API優先"，從"自然語言搜索"變成"結構化上下文檢索"，從"被人瀏覽"變成"被Agent消費"。

而最重要的一點是——傳統數據工程師轉型Context Engineering的窗口期只有18個月。

做Context Engineering需要的核心能力——理解企業數據怎麼組織的、各表的真實業務含義、數據質量陷阱在哪——AI工程師沒有，但每一個有5年經驗的數據工程師都有。兩年后這個角色會被新一代AI原生人才填滿，傳統數據工程師的轉型優勢會消失。

最后三條建議

給數據工程師：從今天起，把你寫的每一段SQL、每一個dbt模型、每一個管道，都加上"AI Agent友好"的元數據。表註釋要詳細，字段口徑要清晰，業務定義要落到文檔里。這些東西過去是"加分項"，未來是"准入門檻"。

給AI應用開發者：停止在Prompt里硬編碼業務上下文。把所有業務知識沉澱到元數據系統里，讓Agent在運行時去查詢。好處是Prompt短了、維護成本低了、知識可複用了。唯一代價是前期搭建一個上下文層——兩個月內就能回本。

給技術決策者：把企業里"數據治理"和"AI項目"兩條原本平行的預算線合併。它們不再是兩件事——AI項目能否成功，本質上就取決於數據治理的成熟度。把元數據投資當成AI投資來做。

過去三十年，我們建設的所有數據基礎設施都圍繞一個假設：最終消費者是人。

未來三十年，所有數據基礎設施會圍繞一個新假設重建：最終消費者是AI Agent。

連接這兩個時代的關鍵基礎設施，叫元數據。

它過去是倉庫角落的目錄卡片。它現在是企業AI戰略的中樞神經。它未來會是整個數字世界的語義底層。

所謂的"死灰復燃"，不過是烈火終於找到了它該燒的地方。

本文來自微信公眾號「數據驅動智能」（ID：Data_0101），作者：王建峰，36氪經授權發佈。