從數據到決策：AI 驅動的 Quick BI 架構設計與實踐

演講嘉賓｜王璟堯

編輯 ｜Kitty

策劃 ｜QCon 全球軟件開發大會

在生成式 AI 重構數據生產力的時代，BI 工具正從"被動響應"走向"主動洞察"。在 2025 年 4 月 InfoQ 舉辦的 QCon 全球軟件開發大會（北京站）上，阿里云智能集團瓴羊高級技術專家王璟堯分享了“從數據到決策：AI 驅動的 Quick BI 架構設計與實踐”，他介紹了阿里云 Quick BI 如何通過技術架構躍遷、結合大模型的突破實現從傳統 BI 到 AI 驅動的智能 BI 的跨越式進化。并重點解析領域大模型與 BI 引擎的協同設計、NL2SQL 算法調優與架構演進、AI + BI 在場景落地實踐過程中的技術權衡，為行業提供可復用的技術范式。

預告：將于 4 月 16 - 18 召開的 QCon 北京站策劃了「AI 重塑數據生產與消費」專題，將深入探討如何系統化地運用大模型與智能體技術，重塑數據全鏈路的每一個環節。內容涵蓋引擎與架構優化、數據治理、開發與運維提效、下一代 BI 與數據工具，以及智能的取數與分析等多個方向。如果你也有相關方向案例想要分享，歡迎提交至

https://jinshuju.com/f/Cu32l5

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

BI 領域的技術演進及趨勢

傳統 BI VS 大模型驅動 BI

早期 BI 是在數據倉庫和數據庫不斷發展演進后形成的需求場景：數據倉庫會將各類數據融合到一起進行數據清洗和分析，隨后業務人員對自助分析產生了一系列訴求，早期的 BI 工具便應運而生，像 90 年代的 Business Object 就是一個比較有代表性的例子，具有一定限度的自助式分析能力。當時其實還沒有“商業智能”這一概念，隨著自助分析能力要求的不斷提高，可視化、自助式可交互的分析需求也越來越強烈，于是敏捷 BI 應運而生：基于可視化的自助式、可交互的分析，以 Tableau/Qlik 為代表，其最大特點是可通過拖拉拽、按鈕點擊等簡單操作就能完成報表的搭建工作。

進入大模型時代，大模型強大的語言分析和生成能力以及更接近人類思維的推理方式，讓 BI 領域進行了重新定位：即從一個單純的工具到數字助手的進化，模型能力的突破讓正在的商業“智能”可以從 DEMO 和實驗室走向實際應用。Quick BI 也在各類大模型技術發展的時代洪流中逐步演進，不斷成熟與發展，實踐落地智能小 Q 系列，給用戶帶來全新的、端到端到產品體驗。

傳統數據分析存在局限性，它幾乎主要聚焦于報表平臺的工作流程：業務方提出需求，產研團隊加工執行，然后制作簡單的報表，以輔助管理儀表板。傳統數據分析主要面向一線業務和老板，工具即使再敏捷，交付物本質上也是以固定式報表作為承載。盡管敏捷 BI 的誕生緩解了部分問題，但業務團隊和數據團隊之間難以融合貫通的問題依然無法避免。而在 AIGC 時代，大模型加持的對話式分析可以對自然語言靈活響應，簡單、自動地完成需求，或許“人人都是數據消費者”及“數據民主化”不再僅僅是一句口號了。

大模型驅動的業務落地方向

基于用戶的實際需求和大模型 Agent 技術發展，我們對大模型驅動的業務落地演進方向做了大致判斷。從執行到思考，從智能到智慧，難度系數逐步增加。大模型剛出現的初期，大家都在做 Copilot（即搭建助手）：用戶通過 Copilot 用簡單指令或描述就能輔助搭建報表，從而降低 BI 工具的使用門檻和成本。然后是 Chat BI，理論上它會改變整個分析流程，用戶像和人類對話一樣向系統提問，由系統即時理解并返回準確的分析結果，所有人都可以隨時隨地的獲取數據，降低傳統 BI 報表和儀表板出現的必要性。

再接著是洞察分析：基于數據、業務知識，利用機器學習算法、數據挖掘技術的融合，疊加上大模型的語言理解和推理能力，讓使用傳統算法的洞察分析脫胎換骨，實現更精準的總結、診斷、歸因，能夠自動發現數據中隱藏的價值。第四階段可能還為時過早，很多廠商將其稱為 DI（即決策智能 Decision Intelligence）。

隨著數據量爆炸式增長和分析技術進步，如多模態、多元信息整合、多 Agent 技術等，我們可能不再滿足于單個功能，產品形態會演變成分析平臺主動在海量數據中發現價值，通過完整數據報告或主動 Feeds 流方式推送給我，不僅能給出“發生了什么”，還能進一步解釋 “為什么會發生”、“未來會怎么樣”，為用戶提供更高階的決策支持，這是也許是目前能看得到的數據分析領域的理想態。

基于對業務落地的判斷，企業級智能 BI 分析離不開 BI 工具、大模型和企業私域知識這三者的有效融合。首先，BI 工具作為核心框架，憑借強大的數據分析和可視化能力，將規模龐大和復雜的數據轉化為直觀易懂的圖文報表，為企業搭建洞察業務的橋梁。要最大化的發揮 BI 工具本身的作用，如高性能分析引擎、可視化、安全管控、開放集成能力、協調辦公能力等。其次，BI 工具并非孤立的存在，大語言模型的加入為其注入了靈魂，通過大模型理解自然語言指令，精準理解用戶意圖，大大降低數據分析門檻。此外，隨著多模態、multi-agent 等技術的成熟，大模型的記憶、推理、規劃、反思、工具使用能力反過來推動大模型在各領域的豐富應用，包括數據分析產品。最后，絕大部分企業級的智能數據應用都離不開私域數據，作為大模型應用的根據，只有將企業數據、企業內部知識、行業知識深度整合，才能讓 BI 分析更具針對性和業務價值。

大模型落地 QuickBl 全景

Quick BI 是阿里云上的一款 SaaS 的 BI 產品，連續 6年入選 Gartner 的商業智能和數據分析魔力象限，也連續 6 年作為國內唯一入選榜單的國產 BI 產品，承載其智能化能力的產品叫智能小 Q。

大模型重塑整個 BI 分析流程

在大模型時代，有句話說得非常到位：所有產品都值得用大模型技術重做一遍，BI 產品也不例外。傳統的 BI 產品，其分析流程在模式上相對比較固定，從數據到結果，基本要經歷從數據連接、到數據建模、到數據分析、到數據可視化、再到數據協同和消費的整個流程。這個流程離不開業務人員的人工搭建操作，對用戶的模型理解和配置技能有較高要求。而在大模型時代，這個流程的每一個環節都有可能被重塑。例如，在數據連接環節，我們可以對數據準備的 ETL 任務進行輔助開發，對連接的數據源進行數據探查和校驗；在建模上，可以對字段質量進行評估，實現計算字段生成優化和 SQL 診斷；在數據分析階段，對報表一鍵美化、洞察歸因和自然語言生成報表；在消費端，有 Chat BI 智能問數；最終的消費態則可以有智能決策和數據解讀報告這樣的形態。當我們打開思維去嘗試探索后會發現，這里面的發揮空間會非常大。

BI Copilot

BI Copilot 的具體形式就是智能搭建。分析師在原有搭建報表的流程時，用自然語言替代繁雜的功能尋找、拖拉拽按鈕和配置，直接完成用戶想要的操作。在這個領域，我們更多瞄準的是那些高頻多步的、或者強依賴分析師經驗的功能。例如：

1. 金額大于 3000 的標紅 - 就是個典型的條件格式場景；

2. 幫我美化下這個報表

從技術流程圖可以看出，我們將原本強耦合在底層產品內部的一些能力做了解耦和開放，在渲染引擎、搭建引擎和用戶會話之間構建了一整套指令系統和前端 API 層。大模型作為穩定的“中介”，負責對接會話層和指令系統，將用戶自然語言意圖轉換成底層引擎能識別的“API”指令。在這個部分，我們基于基座模型微調了適合 QBI 搭建的增強指令識別系統，即帶有指令 CMD 和參數 Params 的 NL2API。初級 API 進過指令系統的復雜處理，如依賴檢測、指令調度、執行等，最終會調用暴露出來的 API 層，最終在渲染引擎和搭建引擎的加持下，完成一整套動作。不過，在這層面上 NL2API 系統相對封閉，因為大模型本質上主要是為 Quick BI 或自身應用系統內部業務服務的。

BI copilot 的另一個重要應用是數據洞察。用戶對洞察的期望通常是：看懂圖表 ->補充信息 ->分析和解釋數據現象 ->定位問題 ->支撐行動決策。這幾個步驟里，任意一個步驟想要做好都需要天時地利人和的：算法夠優秀、支撐數據夠多、流程組織夠清晰。

目前我們在洞察領域做了如下三方面的探索：

一是內置洞察算法，這部分主要使用經典統計計算模型，畢竟智能化并不能完全等于大模型。例如，關注指標變動是否正常，若不正常，是哪些維度造成異常，本質上是參考歷史數據、行業經驗及其他關聯數據，尋找對業務目標最具解釋力的維度，這就是內置洞察算法。

二是大模型的洞察解讀，將報表數據和背后所在數據集的數據以及配置元數據等信息組合，利用通用模型在數據解讀、語義理解等方面的優勢，通過 Prompt 工程 +Multi-Agent 的方式完成的解讀方式。

第三，QuickBI 具備外置 Agent 接入能力（如 Dify 或百煉等），讓客戶特定的工作流和業務邏輯對接到小 Q 對話流里。作為一款通用工具型產品，一定沒法滿足所有用戶的個性化定開需求，這算是一種體驗很好的曲線救國方式。

Chat BI

在當今的商業智能（BI）領域，Chat BI 這一概念正逐漸成為焦點。Quick BI 已經成功落地了智能問數這一場景，這在國內國際都引起了眾多企業的濃厚興趣。目前，眾多廠商的 Chat BI 產品都在致力于實現類似的功能，技術路線也呈現出多樣化，如 NL2DSL（自然語言到領域特定語言）、NL2Python、NL2SQL 等，可謂是百家爭鳴。

以 QuickBI 的智能問數為例，一個智能問數的用戶旅程大致如下：用戶首先輸入一個問題，系統在前置處理階段會進行權限管控和流量管理等操作。隨后，我們利用經過訓練的大模型領域模型對問題意圖進行判斷。如果該任務需要多步才能完成，系統會將其拆分為多個子任務；若單步即可返回結果，則直接進入核心流程。通過一系列召回算法，我們將元數據、知識庫等信息組合起來，輸入到大模型中。最終，大模型以 DSL 和 SQL 的形式將結果傳遞給 BI 底層的查詢引擎。查詢引擎負責方言翻譯、高級計算下推等復雜流程，并最終以圖表形式呈現結果。這些圖表在呈現過程中仍然可以進行交互和調整。整個流程的關鍵在于，我們能夠清晰地梳理從上到下的所有字段血緣關系。

通用大模型與自研領域模型的混合流程設計

在通用大模型與自研領域模型的流程設計中，我們秉持著開放的態度。本質上，用戶的自然語言通過大模型轉換為代碼，代碼再通過我們工程內部的方式轉化為技術邏輯，最終在產品中體現為具體的展現形式。BI Agent（在某些場合被稱為 AI 中間層），它通過組織編排各種大模型的輸出和流程代碼，實現自然語言與代碼的有效連接。BI Agent 會定義一些 API 和 DSL，為了讓模型能夠與應用系統有效交互，我們正在通過 MCP 的方式將其能力開放。

BI Agent 與中間層的控制中心配合，經過業務上下文處理、意圖識別、任務拆分等步驟，使 BI 系統能夠理解模型的返回結果，并據此進行進一步的操作。此外，在處理復雜任務時，我們還會按照正確的順序執行編排的子任務，確保任務的成功完成。舉個例子，需要獲取“X 部門的經營分析報告”，LLM 本身是不會直接總結的，它需要調用取數工具先獲取每個月的銷量情況，再基于各種拆解數據做歸納分析，這里的“取數工具”就作為最原子化的 BI Agent 存在。

工程架構設計

在設計工程架構的最初階段，我們在最初階段經歷了諸多糾結與討論。我們曾反復思量，是要打造一個代碼助手，還是 SQL 插件，又或是增強版的 BI 工具呢？無論最終選擇何種形態，技術路徑的抉擇都必須著重考量幾個關鍵問題。首先，該系統是否具備企業級的特性。這關乎到權限管理、租戶隔離等諸多方面，以及它能否與現有的業務場景無縫兼容。其次，系統的前端界面是否交互便捷、易于使用，這至關重要。再者，系統是否擁有開放集成的能力，能否提供 API 接口，是否能夠嵌入到自有系統，或是接入自有知識庫和數據源。此外，多場景的適應性也不容忽視。在早期，我們發現許多開源的 Demo 項目，它們僅用幾行代碼就跑起來一個 Chat BI，雖在特定場景下效果顯著，但難以在企業級的真實場景中落地應用。最后，系統的未來拓展性也是必須考量的因素之一。

智能小 Q 分層架構

下圖展示了智能小 Q 的整體技術架構。從圖中可以清晰地看到，智能小 Q 從上至下依次為應用層、AI 中間層、自研領域大模型和通用模型層，以及 BI 基座引擎層。AI 中間層處于上層應用與大模型之間，主要承擔任務分發與協同的職責。我們通過構建 API 和 DSL，實現了 Agent 與算子的有效對接，讓大模型應用更具確定性，避免以前通過自然語言輸入的應用表達不穩定，使得在 BI 領域的大模型的應用編程變成確定性應用編程。作為支撐小 Q 的關鍵部分，基座的 BI 引擎確保了數據分析的強復用性。分析引擎涵蓋了從數據連接建模到復雜分析的全方位能力，而渲染引擎則承載著圖表可視化及交互的重任。整套系統都是在 Quick BI 已有的能力基座上進行開發的。

自研模型在 SQL 語義生成的可控性

在自研模型的 SQL 語義生成技術路線上，目前主流的有兩種方式：Text to SQL 和 Text to DSL。我們對這兩種技術路線進行了長期且深入的對比分析。Text to SQL 是直接將文本轉換為 SQL 語句，直接在物理數據源上進行查詢；而 Text to DSL 則是先經過一層抽象的語法，再分發到數據源進行查詢。從業務特性來看，Text to SQL 在門檻較低的情況下，能夠充分利用大模型的泛化能力，簡化數據分析過程。然而，它也存在一些局限性。由于缺乏數據模型的抽象定義，直接對標物理表，使得大模型生成 SQL 的過程變得異常復雜。

此外，大模型不可能被訓練去了解市面上眾多數據源的方言。以 Quick BI 為例，它支持四五十種方言，如果要對私域數據進行私有模型訓練，成本將難以控制。而且，即使是同一數據源的不同版本，如 MySQL 5.7 和 8.0，它們支持的函數也有差異（如開窗函數），這對大模型來說并不友好。從技術限制角度而言，DSL 的靈活性相對較弱，其查詢能力受限于 BI 引擎的能力邊界。從適用場景來看，Text to SQL 更適合門檻較低、沒有復雜業務分析要求的場景；而 Text to DSL 則更適合業務場景明確、面向大型團隊和企業級應用的場景。對于 QuickBI 來說，技術路線從純 Text to DSL 到 Text to SQL to DSL，再到混合模式，可謂是吸收各個路線的優勢。

一個問數問題的工程鏈路

我們從工程鏈路的角度剖析一下問數。用戶問了一個相對復雜的問題后，經過模型的復雜鏈路處理，包括 Agent 路由、各種實體召回，由自研 BI 大模型生成 DSL，經由工程端的查詢參數構造后，發給查詢引擎進行取數。查詢分析引擎會處理復雜計算字段（如 LOD 函數、自定義抽象函數）、注入用戶的行列權限等，最終翻譯成物理 SQL 和內存計算進行取數處理。從下圖的例子可以看到，相對抽象的 LOD 函數會被穩定轉義成適配不同數據源方言的 JOIN, 大大降低了模型生成 SQL 的難度和穩定性。在這種工程架構下，可以解決傳統 NL2SQL 面臨的三大關鍵問題：1）保證可用，具備企業級的管控能力，如完備的權限能力、開放集成能力等；2）保證可信，BI 引擎的引入降低模型生成原生 SQL 的難度，對取數的每個鏈路都做到邏輯有跡可循，查詢元數據血緣透出，提升結果的可信度；3）結果可交互，復用了 BI 豐富的可視化能力，在生成的圖表后鏈路上可修改并進行二次查詢。

工程架構設計

NL2SQL 算法的挑戰

與通用模型處理的其他類型問題相比，NL2SQL 算法領域面臨的挑戰主要集中在以下三個部分：

1. 語義的模糊到精確：自然語言天然是非精確的，同樣一個意圖可以有多種不同方式的表達，而 SQL 代碼及執行是精確的，用戶對結果的正確性的容忍度非常低。因此 NL2SQL 天然屬于模糊到精確的多對多映射問題。

2. 語言結構化：SQL 是“結構化查詢語言”，而對比與 Python/C++ 等其他編程語言是過程化的語言。這里有什么區別呢？過程化語言可以做片段化的邏輯生成，對模型推理的要求偏低，但結構化語言需要結構和邏輯整體正確，難度相對大些。

3. 在問數任務的絕大部分場景下，用戶的問題只提供了信息的局部，只是回答信息必須上下文的很少一部分。有更多信息以企業內部約定俗稱、表元數據的簡稱、數據的具體內容形式存在。這點相信在這個領域的各位應該也有比較深刻的體會。事實上，有大量的 Query 之外的“隱藏信息”需要補全，而這又無形中對系統的配套設施提出了更高要求。

我們在訓練模型前，對要達到的效果做了定義和預演。即什么樣的數據分析助手是“好”的助手？

首先在風格和調性上來說，主要有以下幾點：

1. 有效性，模型必須保證準確和穩定，即單位 token 的有效信息密度高，不啰嗦；

2. 準確性，在最小可用的數據和關聯拓展之間做一個平衡。用戶問數往往是看一系列數據，不是單個數據，我們會在某些場景下主動給一些關聯數據，實踐下來帶來會給用戶一些“小驚喜”；

3. 在復雜任務上的表現，過程中逐步規劃、反饋，通過多個簡單任務組合解決復雜任務。當然，這里如何拆分子任務、子任務的粒度也是另外一個較大的話題了（過于原子化和過于抽象都是有問題的）。

其次對于大模型能力，主要有以下幾點：

1. 基礎能力穩定性高：在問數基礎、高頻場景下需要穩定且高準確度的表現，避免過多的過程性解釋；

2. 在數據分析場景下的專業性：模型訓練能夠對數據分析師、業務常用的分析思路有理解，能給出專業的數據建議。比如用戶問單個指標的時候，同時看一下指標趨勢也沒有壞處；

3. 規劃、矯正能力：具備將復雜任務拆解為用戶易于理解。易于干預的子任務，能根據不同的上下文、用戶提示，矯正復雜任務的執行規劃。

一個問數問題的大模型旅程

從算法的視角來重新看問數的鏈路：大模型在生成抽象 SQL/DSL 的過程中，經歷了元數據選取、上下文添加、問題改寫、完整 Prompt 構建、輸出、轉譯等步驟。。這其中最重要的一步就是領域模型的訓練，領域模型訓練需要足夠的信息來進行正確推理，這些信息主要包括任務描述和通識能力，例如大模型不知道今天是哪天，我們需要將當前時間戳加入其中。其次是表和字段信息，這是非常關鍵的，如果沒有表的字段信息和維度枚舉值，對于 NL2SQL 來說將是一場災難。再者是私域知識庫，相關的知識條目以及是否做強制改寫等，都會給大模型提供啟發。另外，參考樣例也很重要，什么是好、什么是壞的，我們在產品上通過點贊、點踩等方式給大模型提供真實的 few-shot 示例。經過各種選表問題改寫 SQL 等流程后，最終生成的 Prompt 會交給領域模型完成推理。

基于 BI 引擎的 NL2SQL 算法演進

前面有講到，最初我們定義了特定的查詢語言 DSL, 用于表達對于不同查詢參數的描述，由大模型直接學習并生成 DSL，再通過中間層將抽象的 DSL 在元數據和知識庫的召回后實例化，轉換成實際 QBI 的查詢參數執行真實的取數；這里的幾個好處，比如 SQL 方言屏蔽、高級計算能力復用等等。但隨著支持的問數能力越來越多，問數的意圖千變萬化，要準備這套 DSL 語義的樣本成本在逐漸增大，畢竟 DSL 是我們自定義的，通用模型訓練并不含這部分內容。同時，各類通用基座模型本身對意圖轉簡單 SQL 確是有大量積累的。于是我們在單表查詢的標準 SQL 基礎上拓展了抽象函數和高級計算符，變成增強 SQL 語言，以訓練基座模型對于增強 SQL 的生成來提升對復雜意圖的理解準確度，然后通過自研語法解析器來改寫成 DSL 映射。也就是說，增強 SQL 和 DSL 是可以穩定轉換的。這樣既能巧妙利用通用模型的能力，又能大大降低訓練樣本的準備成本。至此，復雜查詢意圖到取數流程就被串聯起來了。

Text2DSL：豐富的算子和函數

對于上述架構的最終選擇，有兩個重要因素支撐才能成立。第一個是豐富的算子和函數，得益于 Quick BI 內置大量邏輯函數，如聚合數值處理、文本處理，以及 LOD 函數、時間算子等。例如，計算環比對于 SQL 來說可能很復雜，我們會將大量復雜分析場景定義封裝在這些算子和函數里，大模型在生成增強 SQL 時不需要感知這些復雜內容，它只需要知道如何使用這些算子和函數即可，這有點像現在流行的 Agent 方式。第二個是完善的數據模型，我們作為 BI 系統本身就支持很多關聯模型，包括自定義 SQL 模型，如單表星形、雪花星系等經典 BI OLAP 模型。實際上，我們會將復雜的多表關聯合并和嵌套查詢下推到數據建模層，這些信息對大模型來說是透明的。大模型不需要感知這些，因為 Chat BI 不僅僅是 NL2SQL 算法的炫技，更重要的是解決實際客戶的問題。有時我們會將復雜建模放在前面，對于整個大模型來說，它只是一個單表的、帶有各種復雜函數的 SQL 生成邏輯。

另一個重要的計算邏輯是多步計算。多步計算是為了解決一些純 NL2SQL 無法處理的問題，轉而通過 NL2Python，或者說 NL2Python Agent 的方式來解決。舉個簡單例子，詢問銷售金額日環比超過 40% 的用戶有哪些？我們可能只能算日環比，超過 40% 對于人來說很簡單，但實際上這是一個多步計算的解決方案。在這個流程中，大模型會進行多次推理，這里的 Python Agent 會觸發大模型在當前輸入上進行二次推理。通過合理的任務拆解，可以降低整個復雜問題的解決難度。

此外，關于領域模型的訓練，我們這邊的訓練主要分為三個部分：繼續預訓練、微調和 GRPO。簡單來說，在預訓練階段，我們會把 Query 質量不高但有大量抽象 SQL 的東西作為預訓練的一部分。在微調階段，我們會把高質量的 query 和 SQL 對應關系放到微調中進行訓練。最終通過強化學習 GRPO 的方式把整個模型訓練好。

大模型與好數據：訓練數據準備

大模型是離不開好數據的，只有大量 + 優質的訓練數據加持，模型才有可能突破。下圖是我們數據準備的一個數據飛輪：

一方面我們依賴了人工構造，我們有一只專門的數據團隊去構造、收集復雜的訓練數據。其次，利用模版、AI 去生成，各類大小模型的結合提升訓練數據的質量和覆蓋。然后是數據蒸餾，對一些復雜問題，我們會通過大模型訓練小模型的方式。與此同時，我們還會在數據準備過程中利用若模型生成一些有價值的錯誤，這些樣本隨后可以在執行引擎的協助下執行驗證并進行錯誤歸納，相當于反例的標注，這對于訓練非常有必要。我們實踐下來發現，有價值的錯誤在整個訓練過程中是非常有必要的。

業務價值與展望

智能小 Q 客戶實踐場景

以零售品牌為例，它們直接利用我們的 SaaS 產品來推進功能演進。還有快消品客戶，更是將我們的小 Q 直接嵌入到他們的業務系統中。實際上，在客戶那里，我們進行了一些實踐和調優工作。作為一個通用的 BI 工具，無需任何配置的前提下想要直接達到 90% 以上的準確率是不現實的。事實上，脫離具體應用場景談準確率，多少有些不切實際。這里有一個案例，一開始我們完全沒有介入時，準確率僅為 65%。通過交付過程中的介入，引導用戶如何使用、如何提問，以及讓用戶通過點贊、點踩的方式參與，我們的模型可以自動進行 SFT。在這種場景下，最終將模型強化后的問數準確率提升到了 92%。主要提升點在于指標維度的擴充、指標覆蓋等，讓用戶盡可能多地提供信息，針對復雜問題進行自動拆解。很多時候，客戶的問題并非單純的問數問題，比如他們可能會讓你去分析一下某個情況，這就需要進行問題拆解。此外針對無法回答的問題，提供用戶提示，即拒識方面的引導優化也是非常有必要的。

Bl 未來發展

目前大模型擅長的包括：語義理解、代碼生成、分析思路、文本生成、任務編排… 我認為大模型在以下幾個方面會有長足進步，具體進步包括：

1. 動態推理能力：包括任務拆分、邏輯推演、沖突解決；

2. 多模態感知能力：未來可能會整合跨平臺的報表數據、根據截圖、報告來挖掘出更有意義的數據科學部分；

3. 模型能力本身的持續進化、自我反思機制的增強：在整體水位線上能讓智能來的更加真切；

4. 自主決策能力：非預設路徑的行動生成和決策。在更高的角度來看，隨著大模型這些能力的持續進化，我相信將會推動智能 BI 從任務執行者向決策主體跨越，進而讓整個領域在交互模式和能力邊界上都有相應的變化。

嘉賓介紹

王璟堯，畢業于浙江大學信電系，10 年數據產品建設和技術架構經驗?，F任阿里云智能集團高級技術專家，Quick BI 數據智能研發負責人，負責 BI 平臺架構、新一代智能 BI 建設等工作，在元數據管理、BI + AI、大模型應用等領域上有豐富經驗。

會議推薦

從基礎設施、推理與知識體系，到研發與交付流程，再到前端、客戶端與應用體驗——AI 正在以更工程化的方式進入軟件生產。2026 年QCon 全球軟件開發大會（北京站）將以「Agentic AI 時代的軟件工程重塑」作為大會核心主線，把討論從「AI For What」，走向真正可持續的「Value From AI」。