一、ABI 方向的演進及 ChatBI 領域現狀

1. BI 產品的演進方向

BI 產品的發展經歷了從報表式 BI 到自助式 BI 的演變，而當前智能 BI 則吸引了大家的廣泛關注與大量投入。無論是早期的增強分析技術，還是如今新興的 ChatBI 產品形態，其核心目的都在于降低用戶利用數據的門檻與成本。我們期望通過融入 AI 的洞察力，使用戶能夠更加便捷地訪問并應用數據資源，從而實現數據普惠。

2. 智能 BI 背后的技術演進

在 23 年之前，或許有些同學已經聽說過增強分析這一領域。增強分析技術涵蓋了智能圖表、數據解讀、數據預測、異動分析、智能歸因等多個方面，這些功能的實現依賴于機器學習和規則引擎等底層技術。然而，那時這一領域似乎并未引起廣泛的熱潮，處于一種相對平穩的發展狀態。盡管我們擁有了這些技術能力，但在幫助用戶獲得深刻的數據洞察和滿足期望的結果方面，似乎還有所欠缺。

自 23 年起，業內眾多公司在傳統 BI 基礎上進行了大量探索，技術上涵蓋了智能問答、意圖識別等領域。有趣的是，在 ChatGPT 時代，我們通過 LLM 大模型的意圖識別能力，將以往的增強分析功能都串聯了起來，用戶現在可以通過自然語言進行數據的解讀、預測和異動分析。事實上，我們團隊在 22 年之前已經開發了許多增強分析的功能，現在開發 ChatBI 時，發現這些功能被完美地整合在了一起，形成了 ChatBI 的堅實基礎。

3. 當前 ChatBI 的兩種探索路徑

目前，業內對于 ChatBI 的探索呈現出百花齊放的態勢。無論是創業公司還是傳統BI 優勢企業，都在這一領域投入了大量精力，顯然對此抱有極高的期望。這一領域的發展主要有兩條路徑。

一條路徑是以 BI 平臺為核心，許多擁有傳統 BI 優勢的企業傾向于采用這種方式。他們側重 Copilot，以 BI 平臺為起點，構建和運用 ChatBI。這一路徑的啟動成本相對較低，BI 平臺背后已有成型的數據集，這些數據集可直接用于提問和初步分析。然而，這一路徑也面臨著一定的歷史遺留問題。因為這些數據集并非專為提問和終端消費者而構建，而是主要服務于報表制作人員。因此，數據集的非標準化可能導致問答的準確率相對較低。

另一種路徑則是以指標平臺為中心，我們可以看到許多新興的 BI 創業公司傾向于采用這種方式，他們更注重 AI-Native，即先建立指標平臺，再在此基礎上搭建 BI 產品。這一路徑被視為實現 ChatBI 的理想方式，因為指標是標準化的，問答口徑也相對清晰，可以有效避免重名、同義或模糊字義等問題。然而，這一路徑對基礎設施建設的要求相對較高。在大型企業或公司中，要實現指標的全面標準化，需要付出一定的成本。這些公司的產品在形態上大同小異，都是基于數據集的問答形態，相似度很高。

4. 個人觀察到的 ChatBI 行業發展現狀

總體而言，ChatBI 似乎仍處于行業探索的早期。

從技術現狀來看：

• 用戶意圖理解的準確性已得到驗證。
• NL2SQL 取數的準確性有待進一步突破。
• 深度數據分析所依賴的模型基座能力還有待大幅提升。

從應用現狀來看：

• 垂直標準場景（標準數據源）落地速度較快。
• 通用非標場景（非標數據源）落地挑戰較大。

二、滴滴 ChatBI 的探索和實踐

1. 滴滴 BI 平臺發展

滴滴 BI 平臺的發展和業內相似，從可視化報表平臺，到一站式報表平臺，再到自助分析平臺，最后到今天的智能分析平臺。

2. 滴滴 ChatBI 產品功能及落地情況

數小智是我們內部 ChatBI 的落地產品，產品形態包含 Copilot、PC 站點、IM 移動端，核心功能包括找數、分析、SQL 輔助 ALL In One，其中絕大部分流量是在 Copilot 這個形態下貢獻的。

3. 滴滴 ChatBI 實踐中的關鍵思考

（1）技術關鍵思考-NL2SQL 的準確率如何提升

分析技術：LLM 升級 + 規模化訓練集

• LLM：LLM1 10B>LLM2 33B->LLM3 72B
• NL2SQL 微調數據：數萬量級 + 半自動標注平臺
• 每周線上巡檢：快速修復用戶提問的 badcase

分析對象：指標標準化建設

• 滴滴統一指標平臺建設：1w+服務化標準業務指標
• 數據口徑清晰唯一，指標加工邏輯封裝在指標平臺內
• 通過 API 對外直接服務指標

分析產品：可信度增強設計

• 模型拒答、反問機制
• 提問可視化為篩選項
• 生成 SQL 的可視化
• 行業黑話支持傳入 prompt

在 NL2SQL 的流程上，存在許多節點會影響準確率。首先，關于用戶提問的處理，會經過多輪問題的合并，整合成一個問題進行輸出，這一環節的準確率高達約 98%。接下來，整合后的問題會進入意圖識別的小模型，該模型負責將問題的意圖歸類。這一環節的模型準確率大約維持在 96% 左右。隨后，如果是一個數據分析任務，會遇到 LLM 72B 模型，這是一個經過高質量微調數據精心調校的自研模型。當面對異動分析、數據解讀或數據預測等類型的問題時，通常會直接調用 NL2API 功能。普遍情況下會進入 NL2SQL 取數環節，在這一環節，我們首先利用模型生成一個 SQL 的結果，隨后將其轉化為 DSL。最后通過 SQL 或者調用 API 生成智能圖表。

在整個流程中都會有所損耗，綜合來看，數據分析類的問題，目前端到端的解決率為 85% 左右，端到端是指從用戶提問到最終渲染出圖表。

要實現理想態的 ChatBI 對數據資產標準化建設不足的企業而言，會是一個長期工程。報表數據集和底層 Hive 表，指標維度定義不規范，并非面向終端分析人員建設，靈活問答準確率低。需要推動標準指標集，快速覆蓋公司內各種關鍵用數場景，并逐步替代其它分析源。

（2）產品關鍵思考-如何培養用戶使用 ChatBI 的習慣

雖然對 ChatBI 的產品探索如火如荼，但用戶層面尚未到深度依賴的程度。準確性固然有影響，但用戶習慣也是很大的因素。

基于 Copilot 形態，設計面向靈活分析場景的產品觸點。例如充當報表組件的靈活篩選器、報表上任意波動字段的歸因分析、數據集/Hive 表的字段靈活探查。

（3）業務關鍵思考—如何提供深度價值

ChatBI 產品要能夠提供靈活的異動分析和歸因能力。異動分析是用戶邁入深度分析的剛需，也是智能BI 的典型產品功能，ChatBI 產品形態對該功能起到靈活放大的作用。

生成業務數據分析日報：借助 ChatBI + LLM 在特定的業務分析場景下每日自動生成類似上圖的業務數據分析日報。

4. 滴滴數小智產品架構

最終，我們的產品架構涵蓋了 Copilot、PC 站點、IM 移動端的三種主要產品形態。從分析到 SQL 再到找數，都已實現了全面的落地實施。就今年而言，在公司內部的整體落地情況符合預期。

三、走向 ChatBI 的未來

1. ChatBI 提供的產品價值分層

NL2SQL 問答取數只是 ChatBI 實現深度分析價值的基礎，行業的期待遠高于此。而深度分析價值的實現是要基于業務場景的，非通用性分析。

2. ChatBI 深度價值的實現有賴于 Agent 架構的場景化落地

在分析深度增強的過程中，業務場景和背景知識的融入至關重要。這包括了解特定行業（如能源業務）的關鍵指標和趨勢，以提供針對性的分析建議，為決策提供有力支持。

四、問答環節

Q1：如果要快速搭建 Chat BI，有哪些基礎設施可以用？

A1：我們內部一些基礎模型也是基于開源模型去做的，包括這塊 LLM 72B 的開源模型，然后在這個模型的基礎上進行微調。但是微調數據的過程相當耗時，并且需要大量積累資源。盡管存在一些現成的開源訓練數據集可供使用，但在應對我們真實的業務場景和用戶提問時，這些開源數據集所能提供的幫助只是一個基礎起點，遠不能滿足我們的全部需求，仍需我們自己補充大量內容。

除此之外，很大程度上依賴于原先 BI 的基礎設施，如果 BI 的基礎設施原本就建設得相對完善，那么今天開發 Chat BI 就會省力很多。

Q2：指標解讀是指什么？

A2：指標解讀指的是指標的極值、均值、趨勢以及指標間的相關性等基本信息。目前，我們尚未發現除了提升語義潤色效果之外的其他深度價值。因此，我們還需要思考如何更好地利用大模型，結合真正的業務背景知識進行數據解讀，發揮出更好的效果。

Q3：為什么要先做一次 NL2SQL 再轉 DSL？

A3：NL2SQL 的過程中靈活度過高，包含了一些子查詢，甚至可能涉及多表查詢，這些都對底層支持提出了很高的要求。如果底層支持不夠完善，就可能會遇到解析困難的問題。相對而言，DSL 至少能夠對這些復雜的查詢進行較好的解析和處理，此外，對于模糊指標的處理，也有部分可以在此階段進行一定程度的優化。

還有一個歷史原因，因為在 Chat BI 系統建立之前，BI 平臺就已經存在這一層，并且承擔了一些權限相關的校驗任務，以及與其他系統的關聯工作。因此，在 Chat BI 的架構中，我們依然保留了這一層，因為它確實為我們提供了一些必要的幫助和支持。