作者 | 趙鈺瑩

2025 年 4 月 22 日，Aloudata 大應科技自研的 Aloudata Agent 分析決策智能體首秀上線，這是一款基于 NoETL 明細語義層、以“萬數皆可問”為目標的 Chat BI 智能體。

不得不說，“萬數皆可問”聽起來就很爽。

眾所周知，Chat BI 在數據查詢中面臨諸多挑戰，例如數據覆蓋度不足、口徑不一致導致的準確性問題、性能不穩定或不可控的查詢響應問題，以及數據越權或泄露的安全問題。

因此，這個賽道內一直存在諸多企業試圖解決這些問題，“Data+Agent”的產品形態下也有眾多解決方案。那么，這類解決方案應該如何選型？“萬數皆可問”的能力到底來自于哪里？對于常年扛著“數據包袱”前行的企業來說，該方案是否可以無損接入？

1 企業數據分析 Agent 落地的不同路徑

如今，數據分析的重要性無需多言，所有企業都試圖“榨干”數據的一切價值。

從“依靠 IT 人員通過代碼開發來獲取數據洞察”的傳統 BI 時代到“依靠數據分析師 +IT 提前加工的各類寬表制作報表”的敏捷 BI 時代，再到如今我們所希望的“人人都可通過對話的方式進行數據分析”的 Chat BI 時代，產品形態對用戶而言越來越友好，但具體到解決問題的能力上還是需要仔細甄別。

目前，企業數據分析 Agent 落地大致可分為如下三種路徑：

一是 NL2SQL（自然語言到 SQL），目前很多數據庫廠商、中臺廠商和引擎廠商在探索這條道路。數據倉庫的表本身不具備業務語義，這導致很多信息無法讓大模型更好理解，比如如何定義有效訂單、活躍用戶等概念。因此，該路徑需要解決數據和業務語義對齊的問題、大模型根據問題更加準確地鎖定正確的表以避免查詢性能低與資源浪費的問題等。

二是 NL2DSL2SQL（自然語言到領域特定語言，再到 SQL），目前有很多 BI 廠商選擇該路線。該方案將 BI 數據集和報表作為業務語義的知識庫以及查詢數據源，大模型對自然語言進行意圖理解之后調用 BI 工具，由這類工具生成 SQL 語句進行查詢。也就是說，BI 工具在中間進行了一步轉換，將需求與業務語義進行結合，再生成特定的 SQL 進行數據集查詢。該方案也存在一些需要解決的問題，比如不同數據集之間數據口徑不一致的問題，A 部門定義的活躍用戶與 B 部門的有差異；分析的靈活性問題，該類產品所能回答的問題受限于數據集和報表的數據范圍，語料準備工作量大。

三是 NL2MQL2SQL（識別自然語言的意圖，智能轉換為指標語義查詢 MQL 再由指標語義引擎生成可執行的 SQL 語句），面向指標平臺的語義層進行問數，這是當前指標平臺類型的廠商所選擇的路線。相當于將第二種路徑中的“BI 工具”更換為“指標平臺”。指標平臺解決了數據口徑不一致的問題，從企業全局視角看單一指標只會存在一種定義，比如用戶活躍的定義就是近三個月登錄平臺的用戶，如果不同業務之間存在不同的定義，那就從命名上進行區分。同時，這種路徑在數據查詢性能和安全管控方面還能提供有效保障。

大致判斷下，我們就會發現第三種路徑更為可靠。但是要想實現這種路徑的順利落地還需要做很多工作。而且，技術路徑和產品形態都可以被模仿，但如何保障數據分析類 Agent 產品的問數效果？以及其核心壁壘到底是什么？

2 路徑可學，產品可抄，企業知識庫才是數據分析 Agent 的核心壁壘

數據分析 Agent 類產品能不能用好，關鍵在于數據底座是否 AI-Ready。

過去十年，數據倉庫、BI 工具、指標平臺在企業內部均有不同程度的落地。當 DeepSeek 的出現讓大模型平權，越來越多的企業試圖借助 AI 的能力進行數據分析，但是我們需要讓 AI 理解我們的業務和數據。過去，我們的 IT 系統、軟件和數據更多是以人為主的角度構建的，而現在我們需要讓 AI 可以更好地理解和獲取數據，這就是數據底座 AI-Ready 的釋義。同時也是指標平臺爆發式增長的原因之一，指標平臺的語義引擎是 AI 時代數據可理解、可應用的根本。

在 Aloudata 看來，企業要實現真正的 Chat BI 和繁榮的智能體生態，關鍵在于擁有“好數據”，而不僅僅是部署大模型。Aloudata 聯合創始人 & 首席產品官肖裕洪曾表示：“我們希望通過一個強大的 NoETL 數據底座，為上層的 Aloudata Agent 提供更完整的數據覆蓋、更精準的數據語義、更強大的查詢性能和更可靠的安全保障。”

為此，Aloudata 通過 Aloudata CAN 指標平臺（自 2023 年底推出之后獲得了業界的廣泛關注和積極反饋）和 Aloudata AIR（國內首個邏輯數據編織平臺）的深度融合，已經形成了一個路徑更短、成本更低、自動化程度更高的 NoETL 工程體系。

為什么這一融合在當前時間點如此重要？因為隨著大模型和智能體的爆發，企業對數據就緒速度的要求顯著提高。業務側的需求不再局限于高度復用的場景，許多一次性或臨時性的需求也需要快速響應。數據編織（Data Fabric）借助數據虛擬化技術達成輕量級數據集成與準備、按需物化的效果，是 ChatBI 快速、低成本的數據集成準備的理想方案。

更重要的是，Chat BI 的成熟依賴語義層技術的突破——既要理解業務意圖，又要動態適配數據模型，同時保障查詢性能。而基于明細數據的語義層所構建的企業知識庫才是企業數據分析 Agent 的核心壁壘。

從這張圖我們可以看到，企業知識庫構建主要存在三種方式：基于報表的語義層、基于寬表模型的語義層、基于明細數據的語義層。其中，基于報表的語義層和基于寬表模型的語義層均存在明顯弊端：前者是很多 BI 廠商的方案，BI 本身更多是一個數據分析的應用工具，依賴于數據集進行分析，雖然包含了一些業務語義，但無法保障數據口徑一致性，容易導致問數結果出現歧義，也因為無法覆蓋全部明細數據，所以難以支撐靈活的洞察分析；后者是很多指標平臺的方案，由于語義層的建模、指標定義能力與查詢性能的局限，仍要依賴寬表進行指標的定義與查詢，因此無法實現指標和維度的任意組合，分析靈活性大打折扣，且需要預定義全部指標，而現實情況是我們無法窮盡，所以場景覆蓋同樣有所限制。

相較于這兩者，基于明細數據的語義層才是理想的企業知識庫。其不僅能夠沉淀所有明細級語義，可作為 ChatBI 數據底座實現數據分析場景的全覆蓋，還支持指標維度的動態結合和快速衍生，讓智能問數更靈活。在這一方面，AloudataCAN 可提供 NoETL 明細語義層，具有“標準化指標定義、明細級語義沉淀、智能化加速路由、查詢時靈活衍生”四大特性，基于此，最終 Aloudata 推出了覆蓋率與準確性并重的數據分析 Agent。

3 Aloudata Agent：基于 NoETL 明細語義層的分析決策智能體

據 Aloudata 合伙人 & 首席業務架構師杜雪芳介紹，AloudataAgent 是一款以 AloudataCAN 指標平臺的 NoETL 明細語義層為底座的分析決策智能體，基于 COT 和 ReAct 的多 Agent 架構，順利落地了 NL2MQL2SQL 的技術路徑，讓企業告別“數據幻覺”，通過自然語言即可實現靈活、準確、快速、安全的智能分析，并覆蓋了各類復雜分析任務和高階歸因分析場景。

關鍵創新一：NL2MQL2SQL，實現準確、靈活、快速、安全的智能分析

以 NoETL 明細語義層為底座，為 Aloudata Agent 提供了全面、豐富的指標語義知識庫，確保基于用戶問題意圖對齊指標語義，實現精準的指標與維度召回。同時，指標、維度與篩選條件再由指標平臺生成準確和可查詢的 SQL。而智能物化加速和查詢路由改寫的能力加持，保障了 AloudataAgent 跨表動態查詢性能，億級數據穩定秒級產出。在數據安全性方面，AloudataAgent 基于指標平臺的行列權限能力，可實現精細化的權限管控，確保數據的安全。

關鍵創新二：基于 COT 和 ReAct 的多 Agent 架構，高效解決復雜分析問題

基于上述技術路徑和業內先進的大模型思維鏈能力，Aloudata Agent 可以實現復雜的分析任務拆解與動態反饋調整，提升復雜分析任務的解決能力，比如用戶的問題可能是指標口徑查詢、數據查詢、數據報表生成，也可能是數據歸因分析等，可拆解為多個子任務逐步執行，從而高效解決用戶問題。依托 NoETL 明細語義層全面、豐富的指標 / 維度語義信息，Aloudata Agent 更懂數據，更懂業務。同時 AloudataAgent 不止于指標數據查詢，還提供智能歸因分析、數據解讀、深度報告生成等能力，實現從數據呈現到洞察的全面分析技能覆蓋。

關鍵創新三：基于 RAG 和指標語義，提升意圖識別的準確性

雖然意圖識別這一過程是大模型來完成的，但是為了確保準確度，Aloudata Agent 先行判斷用戶的意圖，區分是口徑查詢、指標數據查詢，還是歸因分析或數據分析報告生成。隨后，通過向量檢索、ES 文本檢索以及 KV 關聯指標檢索等多路召回技術高效檢索指標語義層沉淀的指標元數據信息、維度元數據信息、指標血緣關系和邏輯模型關聯關系，確保指標與維度的精準召回。在檢索到相關指標和維度后，AloudataAgent 會進行二次選擇，確保精準定位用戶需求。根據問題的復雜度，可能生成一個或多個 MQL 查詢。隨后，Aloudata CAN 指標平臺語義引擎將 MQL 自動轉換為底層 MPP 引擎可執行的 SQL，返回查詢結果，再由 Aloudata Agent 將查詢結果生成符合意圖的回答（如指標值、圖表或分析報告）返回給用戶。

關鍵創新四：以指標為中心高階分析能力集成，促進更深度的分析洞見

對企業來說，不同的部門肯定都會有自己的 KPI 看板。是否完成 KPI 只是一個結果，復盤時看結果是否完成是企業經營過程中的重要動作，但相較于結果，企業也應該重視影響 KPI 結果的因素，以便在過程中及時干預、校正，保證最終指標的達成。比如某業務單元的 KPI 是利潤，與之相關的營收、成本都是關聯因子。比如當營收數據發生異動，企業自然需要進行多維歸因。在 Aloudata 看來，這類深層次的、智能的、廣泛的歸因是非常重要的一個場景。Aloudata Agent 致力于在這一環節為企業提供更廣泛和深度的數據洞察。

4 “Agent+ 指標平臺”如此性感，企業如何“無損接”

數據分析類 Agent 產品再性感，企業接入之前都需要認真評估。

如果希望更好地體驗 Aloudata Agent 的能力，AloudataCAN 指標平臺肯定是需要配套搭建的。（原因在前面已經說的很清楚了，AI-Ready 的數據底座，特別是 NoETL 明細語義層是重要基礎）。

結合 Aloudata 眾多企業用戶的使用經驗，企業梳理指標體系落地指標平臺的過程可以分兩條腿走路。一方面自上而下進行核心指標體系拆解和在指標平臺的沉淀，另一方面可以通過指標平臺滿足新需求的定義和開發，通過一段時間逐步補充和完善指標體系。因為企業并非從零開始，往往存在大量歷史包袱。由業務需求去觸發和建設，然后通過“拔出蘿卜帶出泥”的方式，像拼圖一樣逐步完善整體的指標體系更為實際。

與 BI 不同，BI 更多是從業務需求出發，自下而上地開發報表。而指標體系則是基于公司的遠景或目標，自上而下地拆解目標并確定相應指標，與業務連接更緊密。指標體系也應追求精簡而非繁多，以避免隨著報表增多形成冗余。

從指標管理和存量報表遷移角度來說，企業可以對指標進行分級：核心指標、關鍵指標、一般指標，明確其重要性和優先級。核心指標對公司戰略和關鍵業務目標有直接影響，需在指標平臺上統一管理；關鍵指標對特定業務領域重要，可按需遷移；一般指標若現有體系能滿足需求，則可暫時保留。所以，企業應該根據指標重要性和業務需求，決定是否遷移至新的指標平臺，合理分配資源，避免帶來額外成本。

從業務角度來說，業務肯定希望指標能夠實現中心化管理，確保在多個產品、看板和平臺中保持一致。因此，在考慮遷移時，企業需要找到合適的時間點。例如，在企業發展的某個階段，如當下兩個月業務相對平穩、落地事務不多、人力相對充裕時，可以利用這一時機推進遷移工作。同時，要結合企業當前的發展階段、業務重點以及指標的重要程度，制定合理的遷移策略，逐步實現指標的中心化管理和一致性。此外，企業還要綜合評估指標在這種自然時間狀態下的質量、對業務的影響等因素。

5 總結

綜上，盡管 Aloudata 推出的這款 Agent 并非成熟的終極形態，但它已經具備了一些重要功能和特性，能夠為企業提供初步的智能化支持。正如杜雪芳所說：“基于 NoETL 明細語義層作為企業的知識庫，加上大模型的能力，我們推出的 AloudataAgent，將是一個更加準確、全面、聰明、友好且安全的分析決策智能體。”

第一、自然語言取數、歸因、解讀，全面的分析場景覆蓋。對話即分析，通過自然語言即刻獲取數據結果，支持智能數據結果解讀，以及智能多維歸因和因子歸因分析，讓企業深層次洞察異常數據波動原因。

第二、用戶友好的交互式引導與追問，多輪連貫問數更懂分析需求。支持聊天 + 點選操作，用戶友好交互式引導，支持結果引用追問，以及基于歷史會話的問題推薦和智能引導，讓操作更簡單，分析更精準。

第三、分析可追溯、可理解、可干預，讓企業問數用數更放心。分析過程“白盒化”，數據口徑清晰明確，數據結果可信有保障，分析過程可理解、可調整、可干預，讓企業管理決策更放心。

未來，Aloudata 會繼續在產品層和技術層進行優化，并計劃推出 Aloudata AI MCP，將數據分析的能力開放出來，讓企業可以將數據分析的能力更好地與內部相關的 Agent 進行結合，圍繞風控、策略等場景加速內部的 AI 應用開發速度。而對企業而言，也不應只盯著 Agent 這樣的產品形態，而更需要關注這類解決方案數據底層的技術能力的差異性，從而選擇更合適業務發展的方案。