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

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

1. 業(yè)務(wù)團(tuán)隊(duì)痛點(diǎn)

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

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

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

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

2. 業(yè)務(wù)團(tuán)隊(duì)訴求

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

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

3. 數(shù)據(jù)團(tuán)隊(duì)痛點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

這種方式帶來(lái)的好處：一是零門檻，無(wú)需額外提需求，只需語(yǔ)音提問(wèn)即可；二是靈活，PC 端和手機(jī)端都支持；三是隨問(wèn)隨答，秒級(jí)回復(fù)。

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

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

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

3. 融合 Chat BI + Headless BI

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

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

三、Chat BI 與 Headless BI 融合實(shí)踐

在第三部分，將詳細(xì)介紹 Chat BI 與 Headless BI 的融合實(shí)踐。

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

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

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

2. Scheme Mapper：提升語(yǔ)義實(shí)體識(shí)別準(zhǔn)確性

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

3. QueryFilterMapper：支持 Copliot Chat 模式

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

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

4. Semantic Corrector：解決大模型幻覺(jué)問(wèn)題

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

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

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

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

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

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

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

其它外部工具和服務(wù)可以不斷注冊(cè)進(jìn)來(lái)，注冊(cè)后作為一個(gè) Agent，由 Planner Agent 進(jìn)行召回和選擇。

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

7. 抽象核心組件+SPI 機(jī)制：解決框架擴(kuò)展性問(wèn)題

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

8. 面向業(yè)務(wù)團(tuán)隊(duì)查詢數(shù)據(jù)

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

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

9. 面向數(shù)據(jù)團(tuán)隊(duì)治理數(shù)據(jù)

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

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

四、未來(lái)展望

最后來(lái)分享一下對(duì)未來(lái)工作的展望。

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

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

五、Q&A

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

A1：我們?cè)?GitHub 上會(huì)發(fā)布具體計(jì)劃。此外，還可以關(guān)注“SuperSonic” 微信公眾號(hào)獲取最新信息。目前我們的開(kāi)發(fā)模式是針對(duì)具體 issue 進(jìn)行討論，再進(jìn)行相應(yīng)的開(kāi)發(fā)，未來(lái)會(huì)考慮將每個(gè)版本應(yīng)具備的功能以 roadmap 的形式展示出來(lái)。

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

A2：前面講到，我們通過(guò) Mapper、Corrector 以及 Semantic layer 等一系列優(yōu)化來(lái)提升準(zhǔn)確性。我們?cè)?nbsp;CSipder 上進(jìn)行了評(píng)估，在兩三個(gè)月前的評(píng)估中，準(zhǔn)確性大概為 80%+。