一、項目背景和目標

1. 項目背景：大模型賦能智能 BI

我們先來看一份報告，2023 年，國家發布了《數字中國發展報告》，報告顯示我國的數字經濟規模已經達到了 50 多億，位居世界第二。這一成就的取得，離不開像 ChatBI 這樣的創新性產品的貢獻。

我們做 ChatBI 這款產品的原因主要有三個：

• 第一，傳統的 BI 產品在數據指標、預測能力方面遇到了技術瓶頸，用戶體驗也不夠友好；
• 第二，隨著 GPT 的發展，GPT 技術在文本和圖像生成上取得了突破性進展，為 ChatBI 在企業中的落地提供了堅實的基礎；
• 第三，許多企業對數字化和 BI 的發展也越來越重視。

因此，平安人壽也在積極推進 ChatBI 產品的應用，我們主要在解放手、解放腦、開藥方這三個方面做一些積極的改變。

我們認為 ChatBI 能夠在大模型領域落地，主要有四個方面的原因：

• 一是語言能力，大模型已經能夠理解自然語言的語法結構和詞的含義；
• 二是學習能力，我們可以通過 RAG 技術讓大模型快速學習特定領域的知識；
• 三是工具調用，我們可以通過 Agent 編排，可以快速調用現有工具，并生成代碼；
• 四是邏輯推理，我們可以通過大模型結合人工對數據進行洞察分析，檢查出異常點和問題。

比如我們在實踐應用中的一個案例場景，當用戶詢問業績情況時，大模型能夠根據后臺計算提供數據結果。用戶進一步詢問原因時，大模型則可以基于邏輯推理得出具體原因。

2. 項目目標：智能 BI 3.0

隨著平安人壽進入 BI 3.0 時代，我們進行了用戶調研，發現用戶對 BI 3.0 有三大需求：智能化、自動化和實時化。

• 智能化意味著需要大模型為用戶提供智能的分析建議；
• 自動化則是自動生成可視化報表；
• 實時化要求秒級返回底層數據庫的所有數據。

我們的目標是讓管理者，基層員工，甚至 ToC 的客戶，都能享受到全面的數字化服務。

為什么平安人壽能夠快速落地 ChatBI 產品呢，我們主要是基于以下幾點基礎：

• 第一，我們擁有完善的數據中臺，包含豐富的數據域；
• 第二，我們進行了長期的數據治理，擁有上萬個規范的數據指標供用戶使用；
• 第三，我們擁有豐富的可視化組件可以復用；
• 第四，我們的服務平臺也已經實現了數據服務的 API 化；
• 最后，我們內部已經具備私有部署大模型和模型調優的能力。

基于這些優勢，我們才能快速地成功搭建并落地了 ChatBI 產品。

3. 項目愿景：人人都是數據分析師

我們的愿景是為用戶帶來如下三個方面的體驗：

• 第一，通過零學習成本，降低報表的使用門檻，讓數據的使用變得極其簡單；
• 第二，提供智能的分析建議，使數據分析變得智慧化；
• 第三，通過嵌入方式將 ChatBI 產品整合到多個內部平臺中，實現快速查詢數據，提升用戶體驗，讓每個人都能成為數據分析師。

二、解決方案

1. 總體架構方案

我們的整體解決方案大致分為四層。

• 最底層是數據中臺，包含各種數據域和指標。
• 往上一層是平臺層，集成了 API 服務、知識管理、大模型以及 Cube 和 GS 平臺，以及北斗可視化平臺。這些平臺主要覆蓋從用戶提問到代碼生成，再到可視化等功能點。
• 在 Agent 這一層，我們分為四類：問數、分析、數據解讀以及公共能力 Agent。
• 最后是應用層，我們實現了三個核心功能：What（解放手）、Why（解放腦）和How（開藥方）。
  What 指的是用戶可以通過對話方式查詢數據，實現零代碼和實時數據獲取，并通過圖表進行可視化生成，數據獲取速度從以前的天級提升到現在的秒級。
  Why 主要指通過大模型實現根因分析、數據洞察、維度分析等，替代人工進行數據分析，將數據分析流程從原來的"提需求→分析需求→獲取數據→進行數據分析→制作分析報告"變成現在的一步到位，通過自然語言提問即可直接生成分析報告。
  How 則是開藥方，通過大模型的洞察能力和分析能力，提供數據建議和措施，讓洞察分析從依賴人工經驗變成自動化智能生成。

2. 業務架構

我們的產品是直接面向用戶的，因此我們首先梳理了用戶的需求，并將其大致分為三類：產品功能、問法和指標。

• 在產品功能方面，業務用戶不僅需要查詢數據，還需要了解指標口徑、元數據等信息，并希望有指標推薦、代碼生成、可視化以及通過多輪對話提升體驗等。
• 在問法方面，除了簡單問題，還支持復雜問題的查詢，如同比、環比、累計和排序等。
• 在指標方面，我們提供全域數據指標，并能支持日頻、月頻和年頻指標的查詢能力，最關鍵的是指標權限管理，確保每個用戶根據賬號確定其指標使用范圍，保障數據安全。

我們的業務流程從用戶提問開始，首先通過 BI 大模型的語義理解，多輪對話和意圖識別準確摘取用戶提問中的關鍵信息，如指標、時間和維度。然后，通過 API 和 Doris 快速從數據庫中找到所需數據。接下來是對查詢后的數據進行可視化組裝，我們支持提供各種可視化模板進行圖表組裝。最后是在客戶端呈現數據報告。

3. 技術架構

在技術架構方面，底層包括公共服務、BI 大模型、數據中臺和知識庫，這些都是我們的基礎服務。

在基礎服務之上有五大部分：

• 第一是前端用戶，我們可以通過插件的形式插入到不同的平臺，支持用戶訪問、提問、鑒權和網關控制。
• 第二是多輪對話，多輪對話部分通過上下文理解能力捕獲業務客戶的意圖，為下一步的任務編排做準備。
• 第三是 Agent 編排，其中任務執行是整個系統的大腦，通過任務編排調用不同的工具和知識庫。
• 第四是 AI+BI 工具箱，這是我們開發過程中面臨的最大挑戰，需要針對不同場景開發不同的小模型，比如預測預警、時間序列預測和指標分析等，通過定制化的模型來適應不同的場景。
• 最后是可視化系統，我們通過可視化平臺和一些可視化布局的插件快速生成可視化圖表。

我們整個問數的流程，包括意圖識別、知識提取、文本生成、數據生成等步驟，整個過程中會多次與大模型進行交互。

另外知識庫是我們的開發過程中最重要的工作之一，我們采用了兩種技術：RAG 技術和外掛知識庫。

• RAG 技術用于提高準確率，大模型在進行語義解析后會調用知識庫進行檢索，然后用這些知識進行文本和數據的語義分析和生成，從而大幅提高準確率。
• 知識庫分為常見知識庫和進階知識庫，常見知識庫包含常見名詞、知識和 SQL 語法等，而進階知識庫則是垂直領域內的知識，如 BI 知識庫的同環比、累計等術語，保險知識庫的各種保險行業名詞，以及 SQL 知識庫的 SQL 編寫規范。

知識庫的維護需要投入大量的精力，但是知識庫的豐富度與語義解析和結果生成的準確性息息相關，是非常必要的工作。

三、產品效果

案例 1：對話式問數

我們已經上線了隨機報表功能，主要功能是問數，支持用戶隨機提問，系統快速解答，同時支持同比、環比和排序等復雜查詢。

用戶可以隨機提問，例如查詢某個機構的業績。系統通過大模型、意圖識別和知識庫對意圖進行識別，解析出時間、指標、計算方法和維度，然后通過知識庫進行二次校準，進入任務編排階段。接下來是 UM 鑒權，根據用戶賬號確定用戶是否有權限使用該指標。之后是 SQL 生成，調用數據庫進行秒級查詢。最后是對結果進行可視化包裝和美化。

案例 2：言出必答

我們還實現了一些其他功能點，比如“言出必答”，用戶可以查詢指標的元數據和口徑，系統能快速展示數據庫底層的數據治理知識。

案例 3：SQL 生成與問題推薦

此外，隨機報表功能提供了兜底話術，當用戶提問不完整時，系統可以補齊默認信息，如補齊時間。還能幫助有代碼能力的人員直接使用我們系統生成的代碼。

四、落地挑戰

我們在開發過程中也遇到了很多挑戰。

• 第一是大模型的幻覺問題，即同一個問題可能會出現不同的回答，我們的解決方案是通過知識庫和數據中臺進行兜底策略。
• 第二是根因分析，這是我們認為最難的問題，當分析指標變動的深層原因時，需要在后臺有大量的指標圖譜和知識庫支撐，需要花費大量的精力建設小模型，這也是我們未來重點的方向。
• 第三，用戶權限管理也是一個重要但容易被忽略的點，我們需要長期的數據治理和盤點，以確保每個用戶只能使用其授權的指標，避免出現數據安全問題。

五、總結與展望

整體而言，我們認為這個項目的價值在于以下六個方面：

• 首先，我們的產品不僅限于管理層使用，而是可以覆蓋到所有員工和客戶。
• 其次，我們可以實現 7×24 小時的在線應用。
• 第三，我們可以無縫銜接到不同的客戶端。
• 第四，我們提供的是標準一致的全域數據。
• 第五，我們能提供智能化的分析，降低分析門檻。
• 最后，我們能提供數據洞察的結論或建議，使數據洞察成為一個完整的分析過程。

感謝各位同仁的聆聽。我們平安人壽的大模型智能化報表——ChatBI 產品的介紹和討論到此結束。期待與各位進一步交流和合作，共同推動數字化轉型的進程。

六、問答環節

Q1：平安人壽的 Chat BI 生成是使用專用的大模型，還是通過微調通用大模型來實現的？另外，在 Python 和 SQL 兩個選擇之間，您的規劃和側重點是什么？

A1：我們目前使用的大模型是私有部署的 Qwen 72b 模型，并進行了微調和多項工程優化。由于金融企業的特殊規范，我們更傾向于私有化部署。對于 SQL 生成和 Python 功能，我們根據不同場景進行規劃。例如，我們上線的隨機報表功能主要生成 SQL 語句，大模型主要負責語義理解，之后通過 API 方式和 NLP 技術生成代碼，我們底層的數據服務中臺可以快速生成數據查詢。之前嘗試過讓大模型生成 SQL，但發現實現路徑和精準度提升較慢，難度較高，因此我們采用了現有的指標平臺。Python 功能我們規劃用于數據分析。

Q2：關于數據權限的管理，您是如何控制行列權限的？

A2：我們的數據權限管理已經從早期的行級別權限服務，進化到可以進行列級別的權限管理，我們認為列級別的權限管理更為細致和安全。為此，我們在數據指標上投入了兩三年的時間進行數據治理和數據庫中臺的搭建。目前，我們底層有一個權限服務，每次用戶調用時，都會進行鑒權檢查，確保用戶和指標的權限范圍和關系已經預設好。

Q3：關于用戶提問的問題，不同的用戶可能對同一個問題有不同的描述，大模型可能會給出不同的判斷。您提到的兜底方案，能否詳細說明一下？

A3：關于大模型的幻覺問題，我們確實遇到過，這個問題需要花費大量時間去分析 bad case，我們認為沒有什么捷徑可走，需要不斷收集 bad case，并在意圖識別中加入各種知識。同時，我們的模型也需要不斷細化，針對不同場景和用戶提問進行服務細分。我們已經分析了十幾輪，上千個 bad case，并不斷進行分析。我們在產品端設置了點贊功能，對于點贊的問題，我們會進行重點關注，產品運營人員會對每個案例進行分析。我們認為，通過知識庫和數據中臺的維護和優化，可以解決這個問題，而不是通過調整一兩個參數就能解決的。

Q4：關于根因分析，如果我們要做好它，需要給大模型輸入哪些東西？

A4：要做好根因分析，我們需要輸入指標之間的勾稽關系和相關性，這些知識需要形成知識圖譜輸入給大模型。我們通過業內調研了解到，方向都是要梳理好自己的指標圖譜，因為一個指標可能受多個指標的影響，包括顯性和隱性的影響。這需要在底層做好數據模型去支持計算他們的相關性，包括時間滯后性等問題。大方向就是要有指標圖譜，我們已經開始著手這個工作了。

Q5：關于知識圖譜，除了指標圖譜之外，是否還涉及到其他的圖譜？

A5：我們的知識圖譜主要涉及指標圖譜，包括指標之間的血緣關系等，我們的數據中臺已經包含了這些關系。至于是否涉及到企業或其他實體或關系，我們的圖譜主要是指標方面的，因為我們的產品是對內的。技術方案方面，我們把圖譜直接放在數據庫里面，作為一個服務，通過接口進行調用。我們有能力窮舉它們之間的關系，并通過算法計算出指標和指標之間的隱性關系，因此我們也具備相關的圖算法能力。