導讀：大模型能力的發展和成熟，催生出新一代智慧化 BI—— ChatBI，即透過自然語言處理（NLP）與大型語言模型（LLMs）的結合，極大簡化資料分析過程，提高效率並降低分析門檻。火山引擎數智平臺旗下智慧資料洞察產品 DataWind 近期上線 ChatBI 能力，提供智慧修復、多語法適用等能力，在效能上實現秒級響應、一鍵生成。使用者只需要透過文字描述需求， 就能生成指標，快速實現資料獲取、分析計算與圖表搭建，大幅降低資料消費門檻。本篇文章將從技術架構、實現路徑、總結展望幾個方面，拆解火山引擎數智平臺如何落地 ChatBI 能力。
BI 其實是一個由來已久的名詞。其中 I——“intelligence”的內涵已經隨著時間推移和時代發展而逐漸發生變化。
起初，人們認為在資料儀表盤和看板上能夠進行篩選條件變更與維度下鑽就是智慧化表現。
而隨著平臺更新迭代，更多高階、複雜的功能以更易操作的形式更新到平臺中，讓沒有計算機背景或程式設計背景的人也能夠深切體會到程式碼、計算機或者大資料時代所帶來的智慧之感。
隨著 AI 時代的來臨，大家對於智慧化有了更多期待。例如： 它是否能夠“猜到”自己的想法進行智慧推薦？或是，當看到資料異常，它能否幫忙找出原因？
客觀而言，從 2018 年開始開發的抖音集團內部 BI 平臺起步較晚。 因此其直接跳過了 BI 平臺早期發展階段，從立項之初，它的目標便是成為能夠滿足公司內部幾乎所有資料分析需求的資料分析平臺。
在抖音集團內部，BI 平臺建設分為以下幾個階段：
一是 2020 年前後的開發建設。在這個階段投入了大量資源，對結果歸因相關功能進行開發，希望能夠幫助使用者解決歸因問題。
二是在 2021 年 4 月，釋出了低程式碼的視覺化建模工具。原因在於，團隊不想讓使用者在資料分析的過程中發現資料尚未準備完畢時，需要去專門聯絡數倉開發人員重新準備一份資料。為此開發了視覺化建模工具，希望使用者僅需要進行簡單的拖拉拽操作就可以輕鬆處理資料。
三是 2023 年年底。內部團隊面對迅速發展的 ChatGPT，認為它會對 BI 產生具有如“掀桌子”一般顛覆性的影響，因此經過一段時間的嘗試，便在今年 4 月份對內進行了產品釋出。就目前而言落地效果不錯，已經有幾千人在高頻使用這一內部產品。
當前，火山引擎數智平臺旗下的智慧資料洞察 DataWind 已構建起包含了資料準備與管理，資料分析，以及多端展示等功能的相對完善的產品能力矩陣，同時賦予產品系統高度可運維優勢。
截至目前，抖音集團 80%內部員工成為產品月活使用者，同時在工作日單日的產品最低查詢量基本處於 200w 次以上。
火山引擎數智平臺高效能資料分析架構方案
資料驅動決策，是在抖音集團內部深入人心的重要概念，並與公司所推行的 OKR 理念相互契合。由於 OKR 通常以指標化方式去衡量，在指標出現問題需要進行排查探尋原因時，資料分析便成了必不可少的過程。同時，在排查過程中使用者腦海中會同時存在多種分析思路，如果資料分析時間過長，就會將原本的分析思路打斷。因此，為了實現高速分析，企業內部員工使用者對分析平臺的效能有著極大要求。
儘管效能十分重要，但 BI 平臺開發廠商往往認為其更多與引擎有關：引擎能力較差會導致 BI 所能處理的事情並不多。
但資料集、資料來源、資料量的大小以及 Query 的複雜程度等並不是使用者所關心的，他們關心的是自己的資料分析能否能快速完成。因此在提高效能方面的開發面臨著很大挑戰。
為了滿足使用者對效能的需求，開發中採取了有別於主流 BI 廠商的思路。雖然 DataWind 產品支援直連目前通用的大部分資料來源、資料引擎與資料庫。但在企業內部使用者更多地使用“抽取”，即圍繞自研分析性資料庫 ByteHouse 建設了非常重的抽取鏈路，把公司內幾乎全部需要進行資料分析的資料全部放入 ByteHouse 中。
由於資料存放方式對於查詢效率有著極大影響，因此 BI 團隊使用了大量的 ByteHouse 叢集來滿足使用者對於實時連線、離線連線、不同表引擎連線的需求
同時，如何充分有效地利用 ByteHouse 高效能引擎也十分重要。比如應該向什麼樣的叢集推薦資料集，選擇什麼樣的表引擎，以及確定什麼樣的分片和排序鍵策略等。這些為問題對於效能而言都相當關鍵。
在這裡，先簡單介紹一下 ByteHouse。相較於原生 Clickhouse，ByteHouse 針對多個領域做了效能最佳化。
首先，是 HaMergeTree 方面的最佳化工作。HaMergeTree 對於大部分企業使用者而言都不可或缺。原生 ClickHouse 在對 Apache ZooKeeper（ZK）存在較大依賴，在檔案的 part 資訊處理方面依賴性更甚。這就導致 ClickHouse 處理大規模資料集時，易造成 ZK 資源緊張，管理的 znode 數量暴增，影響系統效能和穩定性。
ByteHouse 對此進行了大量最佳化，從而降低了對 ZK 的依賴程度。目前在 ByteHouse 中，對 ZK 的一臉僅僅存在於 schema 資訊，以及生成自增序列等極少數場景中，從而保證了 ByteHouse 的整體效能和可用性。
在 HAUniqueMergeTree，即原生 ClickHouse 的 Raplacing MergeTree 方面。相對而言，ClickHouse 引擎在讀取方面並不高效，而 ByteHouse 在處理此方面問題時，會透過建立一定的索引實現對記錄的快速更新和標記刪除，從而提高效能。
此外，原生 Clickhouse 的 join 能力因為對 coordinator 節點壓力較大的問題被大家詬病已久。ByteHouse 在這個方面實現了真正的分散式 join，同時也基於此做了大量最佳化器方面的工作。例如當大表 join 小表時，ByteHouse 會根據小表的資料情況進行自主判斷，去對大表中的部分資料免讀或免下封。
總體而言，把大量資料匯入 ByteHouse 並不意味著表的數量很多。在抖音集團內部，大家更願意把更全面、更明細的資料匯入到 ByteHouse 叢集中，從而避免在做資料分析的過程中出現某一方面的資料不存在或者明細級別不夠的情況。
在使用到非常細的粒度的場景，團隊認為大部分查詢是基於某些高頻指標維度，去找到非常明細的資料所做的查詢。因此會很容易地想到解決方案，即建立一些 Cube 或物化檢視，並且建立一些自動路由。
對於使用者而言，這些操作都是十分透明的。而從工程上值得一提的是，團隊並沒有使用 ByteHouse 自帶的物化檢視或是 projection 方式，因為在開發實踐測試中，發現這種方式對於叢集與整體效能有負面影響。目前，開發中主要使用基於 Hadoop 鏈路與基於 Spark 的鏈路去進行 Cube 建設，並且由此實現自動路由。從使用者角度來看，使用者會面對一張寬泛且明細力度極細的大表。
但這種方法的副作用在於由於產品的各個業務線都採取了付費使用形式，為資料集建設了大量聚合表必然會導致成本的上升。這就涉及到一個新的問題：在滿足了使用者的速度要求情況下，如何降低成本？
針對這個問題，解決的思路是提供資料冷熱分層，對於最為常用的資料，例如最近 7 天或 14 天的資料，可以放置於 ByteHouse 中進行儲存。而相對距離當前時間較遠的資料，則放置在存算分離的 ByteHouse 叢集當中，透過更為廉價的方式來實現查詢。至於時間更為久遠的資料，比如過去一年的資料，就存於 Hive 表內，可以透過 Python 或者 Spark 的方式來進行查詢。
而之所以保留對以 Sparck 方式進行兜底查詢這一方式的支援，是由於 MPP 相關資料庫在兜底能力方面普遍存在硬傷。故而採用 Spark 方式來兜底，如此一來，至少能夠確保使用者在極為極端的情況下仍然能查詢到資料結果。
除此之外，效能最佳化與成本治理也是值得研究的問題。對此開發中所採用的是一種較為偏向“人民戰爭”的方式。鑑於僅依賴平臺運維團隊來監控所有效能指標及具體資料庫表，難以滿足集團公司龐大的業務需求，團隊選擇將這種監控與最佳化的能力內嵌於產品體系中。
從而讓每個業務線的負責人，乃至每個專案管理者，都能直觀地瞭解到哪些資料集消耗資源較多、哪些資料集的成本效益比較低——即投入大額資金但查詢頻率並不高的情況。該策略還可協助他們識別出哪些部分可透過構建多級聚合來提升效能，以及在確保效能不受影響的前提下，如何實施成本控制措施以實現更高效的資源配置。
透過這種方式，不僅能夠分散管理和最佳化的壓力，還能促進全員對資源效率的關注與參與，確保了整個集團在規模擴張的同時保持成本效益與服務效能的最最佳化。
BI + AI 實現智慧資料洞察
抖音集團內部在 BI 平臺建設階段，對智慧部分投入較多。
而對智慧部分的分享可以大致分為三個部分。
其一為資料開發，旨在幫助進行資料準備的人員能夠準備更具價值的資料；其二是資料分析，期望能夠助力使用者進行異常指標查詢以及異常歸因；其三為資料消費，透過對話式問答的方式來提升提取資訊的效率。
資料開發的場景相對簡單，團隊的工作主要是整合多種 AI 運算元至低程式碼視覺化建模工具中，其中運用較多的是預測能力。而使用預測的場景也非常容易理解。
假設使用者有一張表，其中某一列可能表示幾天後的資料，若此時使用者已知道其他列的資訊和歷史資料，便會希望透過機器學習的方式預測出該列的新值。從目前來看，此類需求較多。從運算元角度來講，產品母線已整合約 40 多種運算元，其中特徵工程運算元與預測運算元是被頻繁使用的兩類。
接著是資料分析場景。在資料分析場景中，開發團隊希望能夠幫助使用者更快捷地進行異常指標查詢以及異常歸因，不想再為使用者配置例如當資料指標低於 10%或 5%再傳送警告此類傻瓜式警告方式。
團隊想要開發一個更為靈活、能夠反映指標季節性的預警系統，因此在開發中採用了 STO 演算法，同時結合指標平滑技術，利用殘差結合歷史資料計算出指標的波動範圍，當超出這一波動範圍時，就會進行告警。
從產品形態方面分析，歸因可以分為以下幾類。
從產品形態上即時歸因較易理解，即使用者在發現異常時只需點選一下，系統便會進行歸因。就維度選擇而言，開發團隊參照了一種基於基尼係數的維度選擇方式，基尼係數常被聯合國用於貧富差異比較，將其理解成維度後，可把每個維度視為一個國家，若某個維度中維值對某一指標的貢獻較為平均且無明顯差異性，則認為該維度可能並非主要原因。
在確定維度後會透過一系列方法計算維值的貢獻率。即時歸因對即時性要求較高，其可以在短時間，比如 15 秒鐘左右，返回查詢結果，但即時歸因能分析的事情相對較少，它不會進行相關指標分析，僅會做維度分析，也不會做過多維度組合相關分析，總體功能較為簡單。
而另一種歸因——洞察報告的功能則相對豐富，洞察報告透過非同步通知模式可以處理相對複雜的需求，能夠分析不同指標和進行多種維度組合。
使用者歸因前進行配置，比如選擇指標歸因或維度歸因，選擇大致組合後便可生成洞察報告，洞察報告既可以在系統上檢視，也可以推送給相應的 IM。
此外，還有一種在內部使用較多的歸因——指標分析樹。
在集團內部，大家在進行 OKR 對齊時，指標往往會形成類似指標體系的東西，即：上級重視 GMV 等指標，而下級更關注 PV 等指標，這種差異便會形成樹狀指標結構。如果對於指標存在疑問，就會進行固化的基於維度的分析，其總體思路是將指標分析過程進行固化，確保在檢視 OKR 或指標時，能夠清楚知道出現異常的板塊、維度和節點。
歸因功能從實現角度而言整體相對簡單，難點主要在於產品設計與演算法相關處理，而其在工程角度也是較為簡單的問題。此外，非同步的洞察報告和指標分析數排程在實現時，要儘量避免對線上查詢產生影響，要儘量減少佔用線上查詢資源。
在積極開展指標歸因相關工作時，大模型出現了。隨後，團隊投入了大量的時間去探索與大模型相關的能力，同時也耗費了較多的資源。從結果方面來看，目前集團內部已有大幾千人成為 ABI 的 Copilot 常用使用者，因此整體而言取得了不錯的成果。
從探索角度而言，團隊開發了多樣化的場景，但落地結果有部分相對成功，也有部分相對失敗。
如今回顧那些不太成功的場景，都存在一個共性，即所生成內容的質量並非很高。也就是說，相對而言或許產品互動方面它們還有很大的改進空間，但在內容質量方面的調優往往較為困難。
例如，使用者期望大模型能幫助進行歸因，告知資料為何不對或者接下來應朝哪個方向去檢視。
關於這方面的能力，團隊最初將其上線的原因在於其表現實際上超出了預期。從開發者角度來看，特別容易以較低的預期來看待大模型相關事宜，覺得它能做到與自己一樣的事情就感覺它似乎表現得已經不錯了，但實際上從使用者解決問題的角度來看，往往生成的內容質量沒有那麼高。所以在這一點上特別容易讓團隊產生較為樂觀的預期，而這往往會導致落地效果或落地姿態不夠理想。
目前取得成功的案例存在一些共性特點。首先，如果功能是為了解決諸如使用者在解決問題過程中本身就需要去搜尋資料的問題，與 ChatGPT 相結合往往能獲得較好的解決方式。
在程式碼開發場景方面，團隊產品功能內部落地情況較好，包括此前列舉的 SQL 查詢，圍繞 ABI 所支援的高階 Notebook 做法。這些功能能夠取代使用者在網上搜尋檢視大量 Stack overflow 帖子，之後提煉程式碼編輯思路的場景，而在大模型加持的程式碼編輯器中，DataWind 提供瞭如解釋 SQL、最佳化 SQL、生成註釋以及報錯修復等一系列功能。
又或者說資料準備的第一步：源資料的錄入。起初在錄入指標時，往往需要進行諸多翻譯工作為指標命名。
若是處於多語言環境，還需配置該指標的外語名稱。對於這類問題，以往解決時通常需要查閱公開資料，查詢相關單詞的英文寫法等。而這部分的工作，大模型能夠有較為出色的表現，能夠極大地節省使用者精力。
而在儀表盤的探索分析及解讀中，大模型能發揮的最大作用在於幫助使用者展開潤色工作，因為使用者可能需要迅速地將資料結果傳送給上級，而自己書寫解讀內容可能會相對困難。在這一場景中，DataWind 除了對某一圖表進行資料解釋外，還會推薦一些 follow up 問題，而這些 follow up 問題實則完全由 GPT 所推薦。
當使用者點選一個問題時，它亦會描述接下來要進行的操作，這也變相回應了另一個問題，即如何讓使用者知曉模型後續的行為。因為目前至關重要的一點是，以大模型在現階段的能力，其回答是無法做到百分百準確的。
而在嚴肅場合，需要的是一個非常精準的數字，使用者會非常想要了解其統計口徑是什麼，它又是如何得出這個結論的。因此在落地場景中，一個極為重要的原則是必須讓使用者清楚大模型到底做了什麼，或者說大模型做了哪些部分，以及接下來將如何處理這個請求，這個資料究竟是如何得來的，這一點十分關鍵，否則，即便模型準確率能夠達到 95%以上，其在資料產品中的落地也較為困難。
接著再來看一下 SQL 查詢的場景，本產品能夠進行解釋以及最佳化。在 editor 中可以運用自然語言來幫助生成相應的 SQL 以及與 notebook 相關的一些程式碼。
從實現角度而言。第一點便是合規與內容稽核問題。抖音集團內部實踐最初採用了 GPT 模型，進行了多種嘗試，包括 GPT 3 的 tuning 等，對比後選擇了 GPT 4，同時也在努力對接公司自研大模型，因此在內容稽核方面較為吃力，例如：若認為 table 的 schema 不那麼敏感，而 table 的資料敏感，那麼那些維值應如何處理？是否需要進行向量化匹配？這會涉及到一系列的技術和工程問題。
再如精調問題，究竟是否要採用模型精調以及何時採用？即便到目前內部也未完全放棄模型精調這一路線，開發團隊對於精調一事的理解更多是以空間換取時間，因為有時團隊會發現當使用者將私域問題描述得極為詳盡時提示語過長，過長的提示語一方面可能無法輸入，另一方面也可能影響整體使用效率。此時要透過部分精調的方式來減少需要提供的 prompt 數量。
總結與展望
簡單總結幾個未來展望的要點：
一，企業級 BI 正逐漸成為新趨勢，曾經的普遍情況是諸多業務部門各自購買 BI，而全公司或全員使用的 BI 在當時並不重要，但如今其重要性愈發凸顯。
二，指標治理以及 AI 能力也是至關重要的部分。
三，團隊認為資料消費能夠推動資料建設，總體建設思路是將上層的資料消費打造得極為繁榮，在相對繁榮之後，會持續向下層的資料建設，如 ETL 部分、數倉部分以及資料湖部分提出新的訴求，從而帶動下層基礎設施的建設。
點選 火山引擎DataWind 瞭解更多