基於文心一言的生成式資料分析技術探索

　　本文將深入剖析商業智慧（BI）與生成式模型結合帶來的業務價值和技術實踐經驗。重點從三個視角和大家進行了交流分享。第一，從技術趨勢和業務需求視角，論證了生成式智慧 BI 必然技術趨勢和帶來的巨大業務價值；第二，從系統設計視角，介紹了百度資料中臺 ChatBI 設計思路和關鍵點。第三，從新技術實踐實踐視角，介紹了 Chat BI 在百度落地過程中遇到的問題和解決思路。

　　 01 BI 技術的發展與大模型帶來的新機遇

　　1. 技術視角

　　從技術視角看，不管是什麼新的技術，想要成為新的趨勢，本質是要做到技術的普惠，讓更多的人可以更低成本地使用從而產生更多的價值，BI 的技術趨勢也是一樣的。我們先來回顧下 BI 在這麼多年的發展過程中經歷的幾個階段：

　　第一階段（報表式 BI 產品）：隨著大資料技術的產生，HDFS 技術和 MR 技術開始在各個公司流行，產生了此類 BI 產品。其往往需要按需開發，由分析師或經營者提出資料需求，再由專業的資料研發同學進行取數開發。需求開發成本和週期長，邊際成本高，限制了其廣泛應用。

　　第二階段（自助式 BI 產品）：近些年隨著計算機底層硬體的不斷髮展以及資料查詢技術的迭代（如 MPP 架構、向量化、記憶體化技術等），和早期 MR 時代對比，取數效率有了 10 倍以上的提升。量變帶來質變，在多數場景下，在寬資料集上進行動態查詢就能滿足效能需求，這減少了對資料的開發依賴，使用者可透過 BI 平臺進行自助化、視覺化查詢，使得 BI 技術更為普及。

　　當前第三階段 BI 技術展現出明顯的技術趨勢，即智慧化的發展。隨著大模型技術的出現和快速發展，筆者認為現有 BI 產品可以透過和其結合，更具智慧化，做到更好的技術普惠。

　　第三階段（智慧式 BI 產品）：藉助大模型強大的理解、推理能力，遮蔽更多的底層細節。使用者無需再考慮使用哪個平臺、資料從哪裡來以及查詢方言等問題，只需要自然語言對話，即可完成取數、洞察分析等流程。極大地降低了使用門檻，人人都可以是分析師。　　

　　2. 業務視角

　　從業務視角看，核心在於新的技術是否能帶來足夠的業務價值：

　　首先，從業界近些年對 NL2SQL（自然語言轉化 SQL）的研究看，LLM-base 的解決方案在各個評測集上都取得了更好的分數，這降低了問數場景的使用門檻；其次大模型的超強理解能力使其能夠總結背後資料包表的本質，並進行多輪互動式溝通，提高效率。記憶能力和推理能力使其能夠在資料分析中執行邏輯推理，解決問題，為使用者提供更為深入的資料分析支援。

　　大模型對業務帶來的價值主要體現在兩個方面：

　　（1）降低新手門檻：chat 互動、AI 解讀、資料洞察等能力的建設，實現資料分析的普及，使得全員都能夠輕鬆進行資料分析；

　　（2）存量使用者提效：透過智慧化 BI 技術（例如：自動化糾錯 SQL、生成周報等），對於已經使用 BI 產品的同學，可以幫助提升效率。　　

　　其次，從長遠視角來看，隨著大模型的進一步發展，未來可能演變為一種資料助手的狀態，為每個人提供實時的、個性化的資料支援。

　　在進行資料分析和報表生成的過程中，我們不僅僅是在處理資料，更是在追求資料的深層次理解，以指導未來業務的發展趨勢。現有視覺化 BI 工具與人的協同方式有其侷限性，限制在細分的緯度上。然而，隨著 AI 的介入，我們可以期待更為精細化的分析，應對上千個維度的實際經營需求。

　　在 AI 模型逐步成熟並掌握了長期記憶的情況下，它也可以透過學習使用者習慣，變得更為主動。想象一下，在網際網路行業工作的人每天早上醒來，不再需要花費數小時檢視報表，而是收到一份 AI 生成的短文，簡潔明瞭地指示著昨天業務的重點，哪個維度出現問題，需要重點關注。這樣的智慧推動無疑提高了工作效率。

　　最後，對於這樣的願景，有人可能懷疑其是否能夠實現。然而，AI 時代的摩爾定律已經開啟，算力的不斷提升、模型水平的升級以及推理成本的逐步降低，都在向我們展示這一可能性。

　　以發展的眼光看待，技術進步的速度往往是驚人的。正如在十年前無法想象將 10G 或 20G 的遊戲搬移到移動手機上一樣，當前 AI 時代的發展也為我們帶來了巨大的潛在價值。

　　因此，我堅信 AI 將成為第三代技術探索的熱點，先行突破的公司將具備先進的生產力，這一領域的價值將會是巨大的。　　

　　 02 ChatBI 的設計理念和平臺介紹　　

　　1. NL2SQL 需要具備的能力

　　目前開源的 NL2SQL 的工具一抓一大把，但是想要落地到真實工程上，往往還有很長一段路要走：

　　（1）需要具備完備 BI 能力：比如豐富的圖表能力、複雜的 BI 計算（例如：留存率、週日均、同環比），對 SQL 的生成提出了更高的要求；

　　（2）需要具備極速的互動速度：互動耗時包含推理耗時和查詢耗時，對話式互動需要及時的響應，如何基於 PB 級的資料進行秒級的 Chat 互動挑戰很大。

　　（3）需要保證結果的正確性：資料分析是一個嚴肅的場景，結果要儘可能得正確，以滿足實際生產環境的需求。

　　2. ChatBI 的實現

　　下面開始介紹一下我們實現的 ChatBI 平臺，當前平臺核心設計思路關鍵點聚焦在解決如下兩個問題：

　　使運營人員能夠透過自然語言提出問題，平臺能夠及時作出取數應答；

　　如果運營人員發現了資料異常波動，可以透過平臺進行波動歸因分析。

　　下面截圖展示百度的 Chat BI 的核心能力，以進一步說明平臺的實際效果。

　　首先，使用者可以透過自然語言對話進行資料分析。例如，使用者可以查詢最近 3 天內女性使用者的 DAU 波動情況，系統會自動識別使用者的意圖，並在相應的資料集中選擇指標和維度，生成相應的圖表結果。這些結果可以被儲存到儀表盤來進行復用。　

　　其次，我們對 AI 原生產品創新，在產品首頁和輸入框為使用者推薦了常用查詢意圖，使用者可以選擇並提問。查詢結果並非模型生成，而是來自存量的業務功能儀表盤資料，資料置信度高且支援一鍵跳轉至圖表所在儀表盤，來滿足一些高頻場景。　　

　　最後，展示的是多維度波動歸因服務。例如，在新增使用者查詢結果上，使用者可以在城市級別和作業系統維度進行歸因分析，系統將在秒級內產出歸因結果，幫助使用者快速定位資料波動的原因和貢獻度，提高業務決策的效率。　　

　　 03 ChatBI 背後的技術內幕　　

　　該平臺已經線上上執行了一段時間，吸引了眾多使用者的使用。接下來，我們將探討在平臺開發過程中所面臨的困難以及應對方法，這裡分別討論上一章提到的 3 個 NL2SQL 的產品化挑戰。

　　1. 完成的解決方案

　　我們首先面臨的挑戰是 BI 的完整性。一個真實可用的 BI 平臺，不僅包括生成基本 SQL，還需能夠產生豐富的圖表，並與平臺實現聯動。解決這一問題的思路有兩種：

　　方案一：BI 平臺對接在 NL2SQL 模型下游，進行 SQL 的查詢和視覺化操作。

　　方案二：讓大型語言模型與現有 BI 平臺結合，模型不僅返回 SQL，而且返回 BI 平臺的操作指令集，實現模型對平臺的控制。

　　方案一的問題在於模型和 BI 並沒有打通，只傳遞一個 SQL 給到 BI 平臺，會導致大量BI特有功能缺失。例如應該選擇什麼圖表樣式進行展示、結果修改儲存能力等。方案二的思路類似於讓大語言模型執行生成 PPT 或打遊戲的任務，透過模型控制 BI 平臺，可以做到更加靈活優雅。例如由模型確定資料展示圖表樣式、由模型確定是否在展示當期資料的同時也展示同環比資訊。

　　2. 端到端效能

　　第二個挑戰是產品的端到端效能，其中主要包含了模型的推理效能和資料的查詢效能兩個耗時：

　　推理效能方面，現在的文心一言模型效能可以達到秒級的實時推理，且在持續最佳化中；

　　查詢效能方面，資料儲存基於百度內部強大的 MPP 引擎基座，業務平均查詢能夠做到 2-3s 內完成。

　　3. 準確性

　　第三個挑戰是產品的準確性，因為資料平臺提供的資料往往要求百分百的準確性，而大模型則是基於機率生成的，這成為了資料平臺和模型結合中最關鍵的一點。在此背景下，我們在最佳化模型本身的基礎上，還嘗試了在產品層面做了大量設計，來提升準確性。

　　先來說下模型本身的最佳化，這裡主要是透過 prompt 最佳化和 SFT 微調兩個手段進行的。

　　首先是 prompt 最佳化，一個良好的 prompt 應當包含三個關鍵元素：

　　在 prompt 中明確定義模型的角色，使其能夠在特定領域完成任務；

　　對任務的描述要清晰見解，避免歧義，確保模型不會理解錯誤；

　　提供一些 few shot，可以讓模型更好地學習正規化。

　　此外，在 BI 場景下，prompt 中還需要新增相關的表結構和一些業務私域的增強知識，以確保模型能夠理解一些業務黑話。

　　而 SFT 微調則是在模型預訓練完成後，透過補充業務場景的樣例資料，對模型本身進行二次訓練，讓模型更加擅長解答該業務場景的手段。對於 SFT 來說，訓練樣本集尤為重要。從我們微調的踩坑經驗來看：樣本的質量一定要高，樣本中出現的 bad case 會導致模型學習到不正確的模式；資料要充足，要儘可能覆蓋更多場景，才能得到更高的泛化能力。

　　我們在 ChatBI 的冷啟動階段讓使用者標註少量資料，然後在平臺轉動起來時，依賴使用者反饋的資料飛輪（使用者在使用過程中會提供踩或讚的反饋），進行進一步微調，從而形成一個閉環的反饋機制，提升模型的準確度。

　　這裡額外介紹下我們 SFT 訓練使用的百度雲 千帆平臺，平臺提供了模型開發的一站式解決方案，其整合了樣本資料管理、模型調優（含 SFT）、模型部署等功能。不需要使用者具備模型訓練、部署的專業知識和 GPU 資源，極大地提升了我們的模型迭代效率。　　

　　在模型的真實落地過程中，還有 2 個模型的前後置最佳化，這裡也一併和大家分享一下。

　　首先是選表問題，在實際的業務場景下，同一個業務會有成百上千個表，每個表的欄位也比較多。如果打包扔給大模型，讓它進行選表選欄位，會受到 token 的限制，且模型理解成本也比較高。選表是一個典型的分類問題，我們將選表階段從大模型 prompt 中抽取出來，採用獨立小模型進行。分類模型已經比較成熟，正確率比較容易做到很高，同時耗時也可以做到毫秒級。

　　第二個是模型小機率會出現欄位幻覺問題，模型返回的欄位並不是表中真實存在的，而是一個相近的欄位名稱。這裡主要是透過 SFT 進行強化，同時對模型結果後置新增校驗，來緩解幻覺問題。　　

　　最後，我們再討論下在產品層面如何透過設計進行準確性提升。

　　在使用者輸入層面，我們發現使用者經常會有獨特的口語表達方式，還可能缺失查詢所需要的必須資訊。為此，我們會在使用者輸入的時候，以 sug 的形式給使用者推薦一些相關的結構化表達話術，引導使用者使用結構化的提問方式。

　　在結果展示層面，在給出資料結果的同時，我們還會將查詢語句結構化地呈現給使用者，這裡包含查詢的資料集、資料緯度、資料指標、過濾條件等等。這樣使用者可以直觀地檢查查詢是否正確，如果發現有錯誤，也可以透過在介面上進行二次修改，得到正確的答案。

　　另外，BI 平臺歷史上已經沉澱了大量的業務圖表，其實很多使用者的問題都可以透過已經存在的圖表來進行滿足，對於這種情況，我們會直接召回已經存在的結果，而不是進行生成式產出。　　

　　總體而言，產品的目標在於追求模型生成的準確率達到 100%。然而，當準確率未達到 100% 時，透過一系列產品創新進行兜底，以確保使用者依然能夠得到可靠的查詢結果。

　　 04 落地效果

　　該平臺已經線上執行了相當一段時間，得到了多個業務線的使用，累計使用者數量達到了數百人，使用者的評價也普遍較好。

　　使用者認為智慧查詢和智慧分析方面表現出色，其中兩個主要優勢受到使用者青睞：

　　首先，該平臺降低了使用者的門檻。特別是對於一線運營銷售等使用者，他們無需學習複雜的技術，只需提出一個問題，即可獲得結果。這有效地降低了他們的操作難度，解決了實際工作中的問題。

　　其次，老使用者發現使用 chat 的效率比傳統的拖拽方式更高。以前製作儀表盤可能需要查詢資料集、資料等多個步驟，而現在只需透過提問即可生成報表，使用者只需儲存即可。即便在生成結果不理想的情況下，也可以進行二次修改，這比從零拖拽要方便不少。