數(shù)據(jù)分析平臺作為企業(yè)內(nèi)部數(shù)據(jù)價值變現(xiàn)的重要載體，在企業(yè)數(shù)字化進程中發(fā)揮著重要作用。企業(yè)數(shù)據(jù)需求的復雜性以及當前平臺存在使用高門檻、口徑不統(tǒng)一、需求響應不及時等問題，使得分析平臺價值體現(xiàn)受到影響。如何解決這些挑戰(zhàn)，成為業(yè)界普遍關(guān)心的議題。我們?nèi)诤?Chat BI 與 Headless BI，構(gòu)建了新一代數(shù)據(jù)分析平臺，為用戶提供了更高效、更智能的數(shù)據(jù)分析服務和體驗。

一、數(shù)據(jù)分析平臺現(xiàn)狀

1. 業(yè)務團隊痛點

我們從數(shù)據(jù)分析平臺的現(xiàn)狀講起。當前，數(shù)據(jù)分析主要采用三種模式。

第一種是 SQL 探索式，即數(shù)據(jù)工程師開發(fā)一個平臺，通過寫 SQL 來查取數(shù)據(jù)或進行探索。這種方式有兩個不足之處，一是 SQL 學習門檻高，對普通業(yè)務人員來說上手較慢；二是元數(shù)據(jù)、庫表和字段信息很多很復雜，業(yè)務人員很難快速理解，需要不斷詢問數(shù)據(jù)工程師字段含義、表的位置以及庫里有哪些表等，數(shù)據(jù)工程師只能忙于處理這些繁雜的需求。

第二種是拖拽式。將一些維度指標放在一起，通過拖拽來查看數(shù)據(jù)。這種模式也存在不足之處，首先，分析場景有限，如果針對特定領(lǐng)域，就需要創(chuàng)建很多這樣拖拽式的已建模好的數(shù)據(jù)；此外，操作門檻也較高，需要不斷進行下鉆、查看等操作；再者，缺乏數(shù)據(jù)解讀，難以直接獲知數(shù)據(jù)內(nèi)涵，業(yè)務方常常需要將數(shù)據(jù)下載后再通過 Excel 等離線方式自行解讀。

第三種是看板式。這種方式在數(shù)據(jù)解讀等方面做得不錯，但看板不夠靈活，想增加一些維度就需要額外提需求，再制作一個看板，導致開發(fā)效率低下。

2. 業(yè)務團隊訴求

在當前模式下，數(shù)據(jù)團隊提供保姆式服務。業(yè)務團隊提出需求，數(shù)據(jù)團隊按需求制作報表，發(fā)布到自助分析平臺上，業(yè)務團隊查看報表和看板，再下載數(shù)據(jù)進行分析。本質(zhì)上，這個分析平臺采用的是抽取元數(shù)據(jù)后寫 SQL 的簡單模式，效率低下。

業(yè)務團隊期望的模式是變數(shù)據(jù)方主導為業(yè)務方主導。他們能直接向數(shù)據(jù)分析平臺詢問和查詢數(shù)據(jù)，自主、自由地進行可視化數(shù)據(jù)分析，并進行數(shù)據(jù)解讀等。而數(shù)據(jù)團隊只需做一些標準化的工作，將數(shù)據(jù)模型標準化，并提供智能化服務插件等。

3. 數(shù)據(jù)團隊痛點

再來看看數(shù)據(jù)團隊的痛點。數(shù)據(jù)加工鏈路如上圖所示，從原始層接入，到加工層，通常分為 ODS 層、DWD 層、DWS 層、ADS 層等進行分層的數(shù)據(jù)加工處理。加工處理后，基于 ADS 層或 DWD 層的表，寫 SQL 創(chuàng)建數(shù)據(jù)集，再發(fā)布到 BI 平臺上，或?qū)悠渌到y(tǒng)。

這樣的模式下需要制作很多數(shù)據(jù)集，一個數(shù)據(jù)場景就要注冊一個數(shù)據(jù)集，并且權(quán)限分配在數(shù)據(jù)集層面，比如同一指標在不同數(shù)據(jù)集會定義不同權(quán)限，因此存在大量冗余。二是指標邏輯不一致，難以復用。這些是數(shù)字團隊面對的主要痛點。

二、架構(gòu)演進思考

1. 引入 Headless BI 解決數(shù)據(jù)治理問題

針對上述痛點，我們考慮引入 Headless BI 方案來解決數(shù)據(jù)治理問題。Headless BI 主要包括兩塊，一個是 semantic model（語義模型），另一個是 semantic layer（語義層）。通過抽象出指標、維度等語義對象，將這些語義對象暴露給外部系統(tǒng)直接使用。這樣做的最大好處是口徑統(tǒng)一，可以一處定義，多處復用。第二個好處是權(quán)限可控。以前，一個數(shù)據(jù)集里設置一個權(quán)限，另一個數(shù)據(jù)集中又設置一個權(quán)限，導致權(quán)限不可控，可能引發(fā)數(shù)據(jù)泄露。現(xiàn)在我們針對指標設置權(quán)限，當外部系統(tǒng)對接時，權(quán)限能夠得到控制，不會產(chǎn)生誤解。

我們現(xiàn)有實踐中的 Headless BI 架構(gòu)設計如上圖所示。最底層是數(shù)字層，包括 StarRocks、Doris、ClickHouse、MySQL 等數(shù)據(jù)引擎。通過這些數(shù)據(jù)引擎進行語義建模，建立維度、指標。在維度和指標上進行權(quán)限設置，如行列權(quán)限、指標/維度權(quán)限、主題域/模型權(quán)限等。此外，還有對物化和血緣的管理，以及術(shù)語處理。

Headless BI 第二個重要模塊是 semantic layer，也就是查詢層。我們抽象了一個語言 S2SQL，所有對外數(shù)據(jù)都是通過 S2SQL 來查詢的。對外支持以 JDBC 模式來連接，也可以通過 HTTP 請求來連接。Semantic layer 還有一個重要功能，是把 S2SQL 轉(zhuǎn)譯成物理 SQL。這涉及到緩存，SQL 解析和 SQL 優(yōu)化。

最上層是應用層，Dashboard、BI 系統(tǒng)以及其它業(yè)務系統(tǒng)都通過 S2SQL 這一語言進行查詢。

這就是 Headless BI 架構(gòu)的整體設計。

2. 引入 Chat BI 解決業(yè)務易用性問題

引入 Headless BI 后，還有一個問題未解決，即業(yè)務的易用性問題。如何讓業(yè)務更便捷更好地使用數(shù)據(jù)呢？如今大模型技術(shù)發(fā)展如火如荼，我們考慮通過結(jié)合 Chat BI 技術(shù)進行問數(shù)和取數(shù)。例如，在電腦 PC 端輸入一段文本，就能讓數(shù)據(jù)看板實時展現(xiàn)出來，還可以在移動端，直接通過語音或文字的方式進行提問，非常方便。

這種方式帶來的好處：一是零門檻，無需額外提需求，只需語音提問即可；二是靈活，PC 端和手機端都支持；三是隨問隨答，秒級回復。

但是當前的 Chat BI 仍存在一些問題。我們先來看看當前的模式是什么樣的。Chat BI 通過給大模型一些語料，讓它生成 SQL。比如提問“一路生花昨天的播放量和結(jié)算播放量相加是多少？”然后，我們需要提供建表語句，維度表包括歌曲 ID、歌曲名；指標表包含播放量、結(jié)算播放量，以及與維表的關(guān)聯(lián)關(guān)系，比如歌曲 ID。把這些信息一起告訴大模型，讓其生成一個物理 SQL。這種方式非常依賴于大模型的能力，如果大模型能力有限，生成的 SQL 很可能是錯的。

一篇論文中指出了生成 SQL 通常出錯的點在哪里。第一個是 schema linking，占了 37%；join 占了 21%；group by 占了 23%，還有其他一些點。因此直接讓大模型去執(zhí)行 SQL 是很困難的，而且大模型經(jīng)常產(chǎn)生幻覺問題，生成的 SQL 經(jīng)常會出錯。

主要問題可以歸納為四大方面：首先是數(shù)據(jù)安全問題，可能出現(xiàn)元數(shù)據(jù)以及業(yè)務數(shù)據(jù)泄露；另外，如前文提到的，復雜 SQL 生成困難；第三，私域知識識別難，例如“一路生花”，大模型可能不知道這是一個維度值，可能會把它誤認為是緯度名；第四個問題就是權(quán)限無法管控，比如結(jié)算播放量指標屬于敏感指標，只允許特定的人去查看，而大模型生成 SQL 語句時很難做到權(quán)限管控。

3. 融合 Chat BI + Headless BI

前面介紹了 Chat BI 和 Headless BI 的優(yōu)勢，和它們存在的問題。我們將二者進行了融合。

首先，我們將 Headless BI 的 Semantic layer 作為大模型查詢的基礎底座，復用其中定義的一些語義對象，這樣能夠降低生成 SQL 的復雜程度，像權(quán)限、計算公式、關(guān)聯(lián)等操作都可以由語義層來處理。這樣，大模型只需要專注于提取實體的語義，進而生成一個簡單的 S2SQL，就能用來查詢數(shù)據(jù)了。這里的 S2SQL 不會涉及敏感信息，它屬于一種邏輯概念，不會把真實的數(shù)據(jù)表提供給大模型，避免了真實數(shù)據(jù)表的暴露。而查詢數(shù)據(jù)也是通過語義層來操作的，這樣也防止了真實數(shù)據(jù)出現(xiàn)泄露的情況。

三、Chat BI 與 Headless BI 融合實踐

在第三部分，將詳細介紹 Chat BI 與 Headless BI 的融合實踐。

1. 融合 Chat BI + Headless BI 的初始版本

最初，我們通過融合這兩者制作了一個初始版本。首先，定義好 semantic model，包括歌曲名、數(shù)據(jù)日期等維度，以及播放量、結(jié)算播放量、總播放量等指標，以及“熱歌”這一術(shù)語，并為指標、維度設置權(quán)限。將這些語義在 Headless BI 中明確下來。定義好后，將這些語義告知大模型。例如，可以看到其數(shù)據(jù)庫類型是 MySQL，table 是歌曲庫，分區(qū)字段為數(shù)據(jù)日期，以及維度信息和涉及的指標。根據(jù)這些信息就會生成一個簡單的 S2SQL，與前面包含 join 關(guān)系和計算公式的復雜 SQL 相比，這個 S2SQL 非常簡單。對于大模型來說，生成 SQL 的復雜度大大降低。然后，我們通過這個 S2SQL 到 semantic layer，進行一些操作，比如權(quán)限控制、緩存，以及 SQL 解析和優(yōu)化，最終得到一個物理 SQL。

初始版本的準確率較高。但存在一個比較大的問題，因為庫有很多，比如歌曲庫、藝人庫、專輯庫等等，每個庫又包含很多字段，在這種情況下，由于上下文不夠，而裝載的數(shù)據(jù)太多，模型就容易產(chǎn)生幻覺，導致生成的 SQL 錯誤。因此我們抽象了一個 Schema Mapper 組件來解決這一問題。

2. Scheme Mapper：提升語義實體識別準確性

首先，我們將維度和指標都存入知識庫（向量庫+詞典庫）；然后，通過相似度（向量空間距離、編輯距離）召回所需的語義，而不是將所有語義都帶給大模型。這樣，大模型就能更好地聚焦，從而提升其實體識別的準確性。通過 Mapper 之后，把這些識別到的語義對象 Schema Elements 一起組裝給大模型，讓大模型再生成 SQL，這樣生成的準確率可以得到大幅提升。

3. QueryFilterMapper：支持 Copliot Chat 模式

除了利用 Embedding Mapper 和 Keyword Mapper 來進行召回以外，我們還抽象出了一個 QueryFilter Mapper。因為除了 Chat BI 還有一些原有的BI系統(tǒng)，所以需要進行集成。利用 QueryFilter Mapper 組件，其它系統(tǒng)能夠通過 copilot 的方式進行問數(shù)。比如可以通過小助手直接提問，就可以獲得原有看板之外的數(shù)據(jù)信息。

用戶直接在當前上下文里提問，通過 QueryFilter Mapper 組件，會將 table、維度等關(guān)鍵信息直接提供給大模型，這樣就實現(xiàn)了將 Chat BI 集成到現(xiàn)有系統(tǒng)中。

4. Semantic Corrector：解決大模型幻覺問題

前面提到，即便對大模型進行了諸多優(yōu)化，它仍有可能出現(xiàn)幻覺問題。主要問題有三類，即 Schema 錯誤、語法錯誤和時間錯誤。需要針對性地修正：Schema Corrector，修正錯誤的維度和指標；Grammar Corrector，修正語法錯誤，例如計算結(jié)算播放量大于 100 萬，要加上按維度分組，再進行后過濾，加上一個 HAVING SUM；Time Corrector，沒有分區(qū)日期過濾可能導致查詢超時，因此需要限制數(shù)據(jù)日期，修正時間語義。

5. 記憶管理：持續(xù)學習領(lǐng)域知識

另一個關(guān)鍵點是記憶功能，即大模型是否有學習到領(lǐng)域知識。我們需要將歷史問題和相關(guān)數(shù)據(jù)收集起來，作為后續(xù)大模型生成的參考。這樣，大模型就能學習到更多領(lǐng)域知識，生成的 SQL 也會更符合業(yè)務方的需要，Chat BI 會越來越聰明。

我們添加了一個 Chat Memory 模塊，主要包括兩部分：短期記憶和長期記憶。短期記憶用于收集最近幾次的上下文信息，包括問題、示例、生成的 SQL 以及 schema 映射到的信息，構(gòu)造 prompt，用于多輪對話。長期記憶，會把評估正確的對話上下文信息存儲到向量庫。這里的評估有兩種模式，一種方式是由業(yè)務方、數(shù)字分析師等進行評估；另一種方式是通過大模型自行評估。通過長期記憶，讓大模型持續(xù)積累領(lǐng)域知識。

6. 引入 Agent：解決復雜數(shù)據(jù)需求

我們還引入了 Agent，來解決復雜數(shù)據(jù)需求。

首先，我們將前面提到的 Mapper、Parser、Corrector、Semantic layer 抽象成一個 text2SQL 工具，然后把這個工具注冊為一個 text2SQL Agent。另外，在最前面設置一個 Planner Agent，去做具體 Agent 的選擇，召回可能用到的 Agent，接著為每個工具制定 plan，判斷這個工具能否執(zhí)行，工具執(zhí)行完成后進行結(jié)果的收集，并對數(shù)據(jù)進行總結(jié)和解讀。

其它外部工具和服務可以不斷注冊進來，注冊后作為一個 Agent，由 Planner Agent 進行召回和選擇。

這樣，數(shù)據(jù)團隊可以更加專注于開發(fā)數(shù)據(jù)工具。同時，數(shù)據(jù)解讀問題也得到了解決，業(yè)務方不再需要導出數(shù)據(jù)自行解讀，現(xiàn)在 Planner Agent 會對數(shù)據(jù)進行總結(jié)再返回給業(yè)務端。

7. 抽象核心組件+SPI 機制：解決框架擴展性問題

前面講到的各種組件，如 Mapper、Parser 等等，都較為復雜，我們將核心組件抽象出來，再加上 SPI 機制，解決了框架擴展的問題。我們可以插件化地對工具進行修改，修改可以立即生效，還可以根據(jù)特定場景進行自定義的配置，其它第三方語義層也可以很方便地集成進來。

8. 面向業(yè)務團隊查詢數(shù)據(jù)

下面來看一下面向業(yè)務方的查詢數(shù)據(jù)的效果。業(yè)務方只需輸入一個問題，就可以得到所需數(shù)據(jù)，操作非常方便。結(jié)果也一目了然，非常方便業(yè)務方展示和使用。另外，業(yè)務方經(jīng)常想要了解表、指標或維度的定義口徑。在指標市場中，用戶可以輕松查詢定義口徑。

另外，針對用戶提問，Agent 可以自動拆解問題，調(diào)用所需工具，將查詢到的數(shù)據(jù)返回給客戶端，并進行數(shù)據(jù)總結(jié)。這樣我們就能清晰地看到數(shù)據(jù)的變化，獲得更深層次的數(shù)據(jù)趨勢。除此以外，還會給出參考鏈接。這個真正實現(xiàn)了由業(yè)務方主導的數(shù)據(jù)分析平臺。

9. 面向數(shù)據(jù)團隊治理數(shù)據(jù)

面向數(shù)據(jù)團隊，主要進行語義建模，設置好關(guān)聯(lián)關(guān)系，定義好維度指標。定義好之后，就不需要對每個需求開發(fā)看板了，借助 Chat BI 加大模型和語義層即可實現(xiàn)復雜查詢需求。

數(shù)據(jù)團隊還有一項重要的工作，就是開發(fā)插件，例如詞曲作品解讀插件、熱點線索插件、訪問統(tǒng)計插件等等。開發(fā)完成后自動加載入 Agent 即可生效。

四、未來展望

最后來分享一下對未來工作的展望。

Headless BI 方面，我們將持續(xù)推進血緣構(gòu)建和物化加速等方面的建設。比如，從數(shù)倉的 DWS、DWD、ADS 層進行血緣關(guān)聯(lián)關(guān)系的構(gòu)建。另外，數(shù)據(jù)團隊進行建模成本較高，因此我們希望探索借助大模型的能力進行智能建模。例如只要連接到一個庫、一張表，就能自動給出維度指標、別名等內(nèi)容，實現(xiàn)一鍵智能建模。從而減少數(shù)據(jù)開發(fā)的工作量，降低建模成本。

Chat BI 方面，希望結(jié)合移動端和語音轉(zhuǎn)文字技術(shù)，進一步提升便捷性。同時，開發(fā)和集成更多數(shù)據(jù)工具，并優(yōu)化召回準確率，以便拓展到更多場景。

五、Q&A

Q1：可否透露一下 SuperSonic 的未來發(fā)布計劃以及路線圖？

A1：我們在 GitHub 上會發(fā)布具體計劃。此外，還可以關(guān)注“SuperSonic” 微信公眾號獲取最新信息。目前我們的開發(fā)模式是針對具體 issue 進行討論，再進行相應的開發(fā)，未來會考慮將每個版本應具備的功能以 roadmap 的形式展示出來。

Q2：針對分享中介紹的一系列技術(shù)，包括結(jié)合大語言模型的一些技術(shù)，如何保證數(shù)據(jù)輸出的準確性？是否有一些實際的量化指標？

A2：前面講到，我們通過 Mapper、Corrector 以及 Semantic layer 等一系列優(yōu)化來提升準確性。我們在 CSipder 上進行了評估，在兩三個月前的評估中，準確性大概為 80%+。