從0到1拆解FreeWheelChatBI：大模型如何重塑影片廣告智慧資料分析新生態

作者 | 鍾雨

導讀：本文將為大家介紹 ChatBI 系統的核心功能與技術實踐

核心功能

資料查詢與視覺化：支援將自然語言精準轉化為查詢 SQL，並自動選擇最優的視覺化圖表，直觀呈現資料洞察。
互動式資料分析：依託 LLM 的推理能力和演算法庫，實現異常檢測、根因排查等分析任務，並提供最佳化建議。
內部儀表盤導航：可根據使用者意圖，自動推薦合適的儀表盤，滿足日常工作需求。
知識問答：快速回答業務知識、資料模型及指標解釋等相關問題。
智慧追問與多輪對話：透過人機協同（HITL）機制澄清使用者的模糊意圖，支援連貫、深入的資料分析互動

核心技術實踐

為了實現以上功能，我們進行了一系列核心技術探索與實踐：
讓 LLM 理解業務問題：將業務概述作為 System Prompt，並構建向量資料庫來儲存全量的業務術語、指標定義等，再透過 RAG 機制在對話中動態檢索，讓 LLM 能真正理解業務問題。
意圖識別：準確識別使用者意圖並將其路由到相應的功能模組，同時提取關鍵資訊，將口語化表達改寫為結構化請求。
智慧選表：融合向量檢索、TF-IDF、GraphRAG 等多種檢索方法召回候選的欄位和表，再經過業務約束過濾、LLM 智慧決策及規則校驗，最終選表準確率達到 95% 以上。
Text2SQL：基於 LLM 構建的 Text2SQL 系統，已覆蓋內部 300 餘張業務表，在常見問題上的 SQL 生成全流程準確率超過 90%。
智慧資料分析：我們構建了一套包含時序預測、異常檢測、下鑽分析、漏斗分析與指標相關性分析等能力的演算法服務。透過融合 Workflow（預定義常見問題的分析流程）與 Agent（動態排程工具處理長尾需求）的模式，靈活滿足各類分析需求。
系統實現架構：基於 LangGraph 搭建 Agentic 框架。由 Router 負責識別意圖和路由，同時最佳化上下文管理，支援多輪對話歷史追溯，並引入使用者反饋閉環，持續提升系統準確率。

在接下來的系列文章中，我們將圍繞背景、概述、LLM 業務理解力構建、智慧資料查詢、智慧資料分析、系統實現與最佳實踐等幾個部分，對 ChatBI 進行更詳細的拆解。主要內容包括以下幾個部分：1. 背景2. 概述3. 讓 LLM 理解業務問題4. 智慧資料查詢5. 智慧資料分析

6. 系統實現與最佳實踐

7. 總結與展望

背景

在數字化時代，資料已成為企業核心資產之一，如何高效提取有價值資訊、助力精準決策，正成為企業競爭力的關鍵。然而，傳統的商業智慧（BI）工具操作複雜、分析效率低，難以滿足日益複雜的業務需求。基於大型語言模型（LLM，下文均簡稱 LLM）的對話式分析（ChatBI） 突破了傳統 BI 的限制，它透過對話實現資料分析，讓“人人都是資料分析師“成為可能，從而加速企業的決策效率。

FreeWheel 作為一家全球領先的數字廣告管理技術與服務提供商，致力於為高階影片媒體提供廣告投放、監測、預測等全鏈路解決方案，主營業務為高階影片媒體的廣告服務，透過銷售方直賣、程式化交易、私有 Marketplace、Exchange 等廣告銷售渠道，助力供給方（通常是流媒體提供商）和需求方（廣告代理商或者廣告主）更加高效的連線。讓流媒體提供商能對他們的流量高效地變現，最大化收益，讓廣告主能實現廣告投放目標，最大化目標人群觸達。

這種複雜的業務模式催生了海量的 BI 分析場景，如流量分析、MKPL 訂單分析、程式化交易分析、定向資料分析、廣告計劃檢測和最佳化等等。隨著公司業務擴張，資料指標激增、模型邏輯複雜化，傳統資料分析模式弊端凸顯：業務人員依賴資料團隊層層提數，響應遲緩；同時受專業門檻限制，缺乏自主分析能力，資料價值難以釋放。ChatGPT 的興起給我們帶來新啟發 —— 以自然語言互動替代複雜工具操作，能顛覆傳統的資料分析方式，ChatBI 這一概念重新進入了我們的視野。我們開始探索構建公司內部的 ChatBI 系統，服務於廣告運營、資料分析與問題排查等關鍵場景。透過 ChatBI，業務人員可以用對話的方式自主查詢資料，系統則自動完成 SQL 生成與結果視覺化，甚至進行更深入的洞察分析，從而大幅提升資料獲取效率、降低跨團隊溝通成本。

本文正是結合我們在 FreeWheel 的實際應用經驗，分享構建 ChatBI 系統過程中的核心實踐與思考，內容將涵蓋智慧選表、Text2SQL、資料視覺化及分析 Agent 等關鍵模組，希望能為從事相關領域的同仁帶來一些參考與幫助。

概述

首先介紹下我們的 ChatBI 系統”Insights Chatbot“有哪些功能。

資料查詢與視覺化：基於自然語言的資料查詢是 Chatbot 的核心功能，也是使用者最普遍的需求。Chatbot 能理解日常口語、行業術語甚至模糊表達，將自然語言精準轉化為查詢指令，同時可自動推薦最適合的資料視覺化方式，並支援一鍵切換圖表型別，使資料洞察直觀清晰。本文第三章將重點介紹資料查詢，典型的問題例如：“幫我看看最近的收入趨勢” (Show me recent revenue trends)，“展示昨天請求量排名前 10 的站點” (Display the top 10 sites ranked by requests from yesterday)。
互動式資料分析：使用者經常會問某個指標有沒有異常，異常發生的原因（如“為什麼 XXX 業務昨天的曝光量下降了？”- Why did the impressions for network XXX decline yesterday?），或者希望下鑽到某一個維度（如“是哪個站點導致的問題？” – Which site cause the issue?），又或者僅僅是查詢跟某指標變化相關的指標，依託 LLM 的推理能力和外部演算法庫，快速定位資料，執行統計分析、異常檢測、根因排查等任務，並提供最佳化建議，為決策提供及時有力的資料支援。本文第四章重點介紹資料分析。
內部儀表盤導航：我們在內部監控系統中沉澱了大量的 Dashboard（儀表盤），其中很多已能滿足使用者日常的工作需求，系統可自動推薦合適的儀表盤給使用者
知識問答等：Chatbot 可以回答一些業務知識，尤其是資料模型、指標解釋等，以及 Chatbot 擅長的其他問題，如生成摘要等
智慧追問與多輪對話：透過引入 HITL（Human-in-the-Loop 人在迴環）機制，面對模糊提問時主動追問澄清意圖；支援多輪對話，能夠準確理解上下文，持續、連貫地推進資料分析。

接下來，我們看看 Insights Chatbot 的整體架構。它建立在強大的 模型底座 之上，包括 Azure OpenAI 提供的 GPT 系列模型、AWS Bedrock 提供的 Claude 系列模型，以及我們基於 SageMaker 私有部署的 Gemma 模型和時序預測大模型（如 N-BEATS, Timer 等）。資料底座 依託於分層資料倉庫，以及我們統一構建和梳理的資料目錄和指標定義，再透過 Presto 進行統一查詢。基於此，我們透過 LLM 實現了若干原子功能，包括意圖識別、關鍵詞提取、智慧選表、Text2SQL、SQL 評估、資料視覺化等。在演算法能力方面，我們擁有時序預測、異常檢測、下鑽分析、漏斗分析等多種演算法。最終，透過 Workflow（工作流）和 Agent（智慧體），將這些原子功能和演算法能力有機地結合起來，共同支撐了 Insights Chatbot 的四大核心功能：智慧查數、互動式根因分析、儀表盤導航和知識問答。

讓 LLM 理解業務問題

由於 LLM 本身對公司具體的業務細節缺乏先驗知識，因此我們面臨的首要問題是：如何讓大模型精準理解我們的業務問題？我們的核心解法是 Prompt + RAG。

我們從以下三個層面入手：

1. 傳遞核心業務知識

我們提煉了 Freewheel 影片廣告業務中的核心概念，包括 Supply vs Demand 模型、廣告投放（Ad Serving）核心流程等，整理成千餘字的業務概述，作為 System Prompt 的一部分注入模型，為 LLM 提供基本的業務背景。

2. 引入術語體系與知識庫

針對業務術語、行業黑話及關鍵指標，我們分為兩部分處理：

高頻術語與常用黑話：作為 System Prompt 的一部分，直接提供給 LLM；
全量術語、資料指標等複雜知識資產：構建在向量資料庫中，透過 RAG 機制動態檢索，輔助模型理解更細節的問題。

3. 使用者意圖識別與資訊提取

進一步讓 LLM 理解使用者的問題，就要識別使用者的意圖，我們將業務問題分為四類，對應上文的四大功能：資料查詢、根因分析、儀表盤導航和知識問答。我們把常見的業務問題整理到向量資料庫中，也是透過 RAG 的方式提高意圖識別的準確率。

關鍵詞提取

理解了使用者意圖之後，對業務問題的進一步理解就是能夠對問題進行結構化表達，我們把這一步叫做關鍵詞提取。系統會精準識別使用者表達中的關鍵資訊，提取包括維度、查詢指標、過濾條件、時間區間、時區等關鍵詞。同時，為了解決指標別名或同義問題，我們將上述業務知識嵌入到提示詞中，提升 LLM 對業務語義的感知能力。例如，在我們的業務語境中，“Asset” 和 “Video” 表示相同含義。

關鍵詞提取完成後，系統會結合上下文語義對原始問題進行改寫，將使用者的口語化表達轉化為結構清晰、邏輯嚴謹的資料查詢或者分析請求。

智慧資料查詢

接下來，讓我們看看智慧資料查詢的落地實踐。

Freewheel 的分層資料倉庫系統包括了維度資料表、明細事實資料（主要是廣告日誌明細）、通用聚合資料、領域聚合資料、應用聚合資料，基於聚合資料構建了若干資料產品，如 Analytics, Insights 等。明細層資料都是廣告日誌明細資料，很多指標的計算需要複雜的邏輯，且查詢效能較差，一般僅用於廣告工程團隊排查問題使用，不適合於 ChatBI。三層聚合資料粒度分別從細到粗，定位不同的產品用途，可以支援不同的查詢需求。當前使用者在即席查詢時面臨很多挑戰，這也是 ChatBI 需要解決的問題。

對於使用者的問題，多個表都可以滿足查詢需求。但有的表維度多，資料量大，查詢效能差，因此我們需要選擇滿足使用者查詢需求並且效能最優的表。例如在廣告銷售表可能存在多個版本，分別記錄不同維度的銷售資訊，如按流量特徵、按產品線等，Chatbot 需要理解使用者查詢意圖，判斷應從哪個表中查詢資料。
在同一張表中或者不同的表中都存在很多非常相似的指標，有的指標名字相似（或者字面上沒有關聯）代表相同的含義（同一個指標還有很多別名），有的看似相似的指標卻表達完全不同的含義
指標因其業務邏輯特點只能對應某些維度，在其他維度上沒有意義

我們透過“智慧選表”和理解業務語義的 Text2SQL 解決以上問題，下文將會重點闡述。

下圖是資料查詢的整體流程，接下來會詳細介紹每一個部分，並花較大篇幅介紹智慧選表。整個流程包括關鍵詞提取、智慧選表、SQL 生成與最佳化，最終實現資料視覺化。列表召回和排序、選表選列於列表校驗這三步組成了智慧選表，接下來會重點介紹。列表校驗、SQL 校驗失敗都會退回到上一步重試，SQL 校驗時，如果發現這張表無法解決使用者的問題，說明選擇的表不合適，重新進行選表。

指標與資料目錄

在介紹智慧選表前，先介紹下資料目錄與指標定義，這是選表和 Text2SQL 的基礎。我們透過建立資料目錄和元資料管理系統，對資料倉庫進行統一梳理和標註，涵蓋以下多個方面：

資料目錄與資料倉庫概述：對資料目錄和資料倉庫進行高層次描述，闡明其分層架構、資料來源、表的種類以及業務場景等。
表的詳細說明：清晰闡述每張表的功能，以及其在資料產品中的應用場景，例如某張程式化交易廣告銷售資料表，可用於生成程式化交易洞察分析、第三方 DSP 競價儀表盤等資料產品。
表的選擇邏輯：明確界定表的適用範圍，比如某些表僅適用於特定業務場景，如 Marketplace 訂單銷售表，僅適應於 Marketplace 業務下的供需分析和銷售分析；同時說明哪些場景下該表不適用，避免錯誤使用導致資料分析偏差。
欄位詳情：針對每個欄位，明確其型別，判斷是維度（用於描述業務實體的特徵，如網站、地區等）、指標（可量化的業務衡量標準，如請求量、曝光量）還是錯誤度量（用於記錄廣告投放過程中的相關問題，如行業限制、競爭失敗等）；闡述欄位含義，列舉可能的取值範圍；若為維度欄位，指出與之關聯的維度表，類似資料庫中的外部索引鍵關係，方便資料關聯。
衍生指標（Derived Metric）：詳細解釋衍生指標的計算邏輯與業務含義，例如，廣告填充率 = 填充廣告數 / 影片廣告位。
欄位唯一性保障：我們仔細梳理不同資料表中的同名或同義字段，明確其語義一致性，針對欄位含義的特殊情況，進行詳細說明與標註，確保資料解讀的準確性與連貫性。
SQL 限制條件：列出表在 SQL 查詢中的限制條件，例如對某些敏感欄位的訪問限制，或是特定業務邏輯下對資料檢索的條件約束，確保資料使用的合規性與準確性。

技術方案的選擇

自然語言互動的資料查詢通常有 Text2SQL 和 Text2DSL 兩大主流方案：Text2SQL 可將自然語言直接轉為標準 SQL 查詢，便於整合，且透過對多表 JOIN、聚合等操作的支援，它能夠靈活應對複雜的業務查詢需求，但因 SQL 語法與邏輯複雜，基於 LLM 生成的 SQL 很難保證業務邏輯的絕對準確。Text2DSL 透過預先設計的 DSL（如 LookML，明確規定資料模型、查詢維度、指標、時間區間等結構）結構化對映為 SQL 查詢，能提升準確性，卻面臨維護成本高、複雜查詢（如多表 JOIN、巢狀聚合）支援不足的問題。

鑑於 Chatbot 使用者多具備資料倉庫與 SQL 基礎，我們最終選擇 Text2SQL。系統能夠針對使用者的問題自動生成 SQL 並可視化呈現，使用者可以對生成的 SQL 進行審查，詢問 SQL 表示式的含義，透過多輪對話不斷最佳化，直至精確獲取所需資料。

如何選表（Schema Linking）

確定 Text2SQL 技術路徑之後，我們面臨的問題是如何選取合適的表，學術界一般也稱作 Schema Linking。因為 Schema 資料特有的結構化特性，我們擴充套件了傳統 RAG 中檢索的方式，綜合運用多種檢索方法。

表和列的初步召回

選表的第一步是在大量的表和欄位中召回可能相關的表和欄位。我們根據提取的維度和指標等關鍵詞，結合元資料資訊，透過融合多種檢索方式從資料目錄中初步篩選相關表和欄位。

在文件檢索中，常用的檢索方式包括：

Embedding 向量檢索，透過預訓練模型將文字資料轉化為高維向量，在高維空間中快速定位語義相近的資料，透過計算餘弦相似度，按相似度排序取 Top-N 結果。擅長處理自然語言變體（如如 “address” 匹配 “country”, “state”, “post_code”）、長文字語義理解（如表描述中的業務邏輯說明）
基於 TF-IDF 的排序檢索，基於詞頻 – 逆文件頻率演算法評估關鍵詞重要性，BM25 作為改進版引入引數調節，提升短文字匹配精度，可以用於計算問題和所有文件之間的相似度取 Top-N 結果
基於 Edit distance 的檢索，Edit distance（編輯距離）用於衡量兩個字串之間的差異程度，可以設定閾值（如≤2）過濾近似匹配結果。

除了傳統的檢索方式外，GraphRAG 是一種融合知識圖譜的檢索與生成整合框架，先借助 LLM 將原始資料轉換為知識圖譜結構，透過社群檢測演算法劃分圖譜並生成各社群的語義摘要。對查詢預處理後，利用社群摘要檢索全域性資訊，鎖定關鍵社群範圍，再利用圖嵌入向量檢索子圖，最後融合社群摘要與子圖資訊生成回答。

列與表的差異化召回策略

1. 列級檢索：傳統檢索方法和 GraphRAG 的結合

向量檢索：最初我們採用列 Embedding 向量檢索的方法，也就是最傳統的 RAG 方法，根據列名、別名、解釋摘要構建向量資料庫，它的問題就是準確率不高，在有其他方法之後基本只保留相似度很高的結果；
BM25：可以把列的詳細解釋以及維度列的列舉值都作為文字進行檢索，並強化關鍵詞權重（優先返回包含 “request”“impression” 等高頻業務詞的列）；
編輯距離：我們透過設定很小的閾值，比如 2，可以比較好得處理拼寫變異的問題（如 “avail” 匹配 “avails”）；
GraphRAG：我們借鑑 Graph RAG 的思路，但不需要社群摘要的步驟。首先借助 LLM 構建 entity-column 知識圖譜，實體包括兩類，一類是抽象實體，另一類是列實體，抽象實體包括了業務概念、抽象的維度、指標大類等，人工可以 Review 並修改實體和關係的定義。檢索時，一方面透過 embedding 向量檢索 entity，再召回連結的列，另一方面檢索關係，再傳播到 entity 和列。

2. 表級檢索：區分事實表和維度表

在表召回上，事實表和維度表採用不同的召回策略。由於事實表都是大寬表，很難在表的語義層面召回，因此我們用召回列反向關聯的方式得到。對維度表，一個是表描述的 Embedding 向量召，另一個是表名的編輯距離檢索。

完成召回之後，我們會先按照業務約束，比如資料過期、許可權限制等進行過濾。然後對列進行排序，進一步篩選掉關聯性很差的列。對錶的初步排序可以協助 LLM 進行最終的選表。

檢索結果最佳化與智慧決策

1. 初步過濾與重排序

業務約束：過濾許可權不足、資料過期（如使用者需最近一年的資料但表的 Retention 為 3 個月）
重排序：按照原始的相似度得分與 LLM ReRanker 排序權重的融合值進行重排序

2.LLM 智慧決策

設計如下提示詞模板，引導 LLM 輸出最優表：
LLM 角色和任務描述
Freewheel 廣告業務介紹
術語黑話對映表: 包括了常見的黑話和透過 RAG 方式召回的部分
資料目錄與倉庫概述
候選表和列：也就是上一步召回的表和列，包括每個表的描述和選表邏輯
通用選表規則：應該遵守的規則，例如什麼時候應該選擇事實表或者維度表，什麼時候應該選擇多張表
選表樣例：我們收集了多樣化的問題並標註了最優選擇的表，儲存到選表樣例向量資料庫中，透過 RAG 的方式找到和使用者提問相似的例子。

下面舉一個例子，有如下候選表：

demand_portfolio_summary（相關欄位：sales_channel, revenue；選表邏輯：該表為粗粒度彙總表）
demand_portfolio_details（相關欄位：sales_channel, revenue；選表邏輯：該表包含細粒度資料）
inventory_performance（相關欄位：sales_channel）
programmatic_summary（相關欄位：sales_channel, revenue；選表邏輯：該表為 Programmatic 渠道彙總表）
programmatic_details（相關欄位：sales_channel, revenue；選表邏輯：該表為 Programmatic 渠道細粒度表）

當用戶提出 “上個月程式化交易渠道的收入趨勢如何” 的問題時，系統會自動解析 “程式化交易”“收入” 等核心關鍵詞。隨後，LLM 會參考元資料中對各資料表的詳細描述及選表邏輯，並結合與該問題語義相近的過往示例，從資料庫中精準篩選出程式化交易事實表中粗粒度表 programmatic_summary（鑑於問題未涉及更多維度），以及渠道維度表。當用戶問題為統計 2025 年 Q1 各銷售渠道的收入時，同理則需要選擇 demand_portfolio_summary。

3. 規則校驗與重試

透過與 Schema 校驗，確保 LLM 輸出的真實存在的表並且包含所需的列，如果校驗不透過，就需要重試，避免 LLM 出現“張冠李戴” 的幻覺資訊。

其他方法比較

除了讓 LLM 直接參與選表外，我們也對比其他的選表方法，供讀者參考

SQL 生成

完成表的選擇後，接下來就是生成 Presto SQL，首先根據選表選列結果，從常見問題 SQL 樣例資料庫中召回與表和列有關的相似的問題和 SQL，然後構建 Text2SQL Prompt，生成 SQL 語句。生成 SQL 後，我們會進行語法檢查，一旦發現錯誤，立即反饋給 LLM 去修正，語法檢查之後，會對 SQL 進行業務正確性的評估，同樣讓 LLM 來完成，如果評估失敗，同樣把錯誤原因反饋給 LLM 重新生成 SQL。

生成 SQL 的 Prompt 分為以下幾個部分：

LLM 角色和任務描述
Freewheel 廣告業務介紹
術語黑話對映表: 包括了常見的黑話和透過 RAG 方式召回的部分
表的 Schema：包括表的說明，列的資訊，包括維度列的列舉值和關聯的維度表，指標列的語義，以及 SQL 限制條件
從知識庫中召回的跟問題相關的“Question – SQL” 例子
業務相關的 SQL 規則
業務無關的 SQL 規則，比如如何處理時區
Presto 語法規則，比如陣列列如何處理

高質量的樣例是關鍵

無論是選表樣例還是 SQL 樣例，都存在冷啟動的問題，提供高質量的樣例是解決冷啟動問題的關鍵。在問題收集上，一方面我們透過人工收集常見問題，另一方面利用 LLM 驅動的 SQL2Text 方法將線上系統中取樣的 SQL 轉換為問題。有了問題後，我們先用初始版本的 Text2SQL 生成 SQL，並進行人工 Review 和修改，形成了剛上線時的 SQL 樣例庫。後面會介紹我們上線之後的資料閉環。

資料視覺化

資料視覺化方面，我們在前端集成了公司自主研發的 Circle UI 元件，能夠無縫對接 Grafana Panel 支援的視覺化設定和資料格式，包括 Stat、趨勢圖、表格、柱狀圖、餅圖、熱力圖等多種視覺化效果，確保資料以直觀、易懂的方式呈現給使用者。

拿到正確的 SQL 之後，一邊進行資料查詢，另一邊進行視覺化圖表的選擇，藉助 LLM，結合使用者問題的意圖和 SQL 選擇最為適宜的圖表型別，輸出 Grafana Panel ID 和資料結果的 Schema，根據這個 Schema 對查詢到的資料進行解析，轉換為相應的資料格式，傳遞給前端 Circle UI 元件。

效果總結

我們的資料查詢能力涵蓋 300 餘張表，其中事實表 30 餘張，平均欄位數超 100 個，唯一欄位約 1000 個；維度表 280 餘張，平均欄位數為十幾個。

智慧選表：鑑於欄位繁多，選表的難點聚焦於事實表，透過標註 400 餘個選表示例，系統在事實表選擇上的準確率基本達到 95% 以上，在多表中篩選效能最優表的準確率亦達 85% 以上。

SQL 生成：標註了高質量的 SQL 例子 300 餘個，常見的問題全流程準確率在 90% 以上。

智慧資料分析

如果說智慧資料查詢是 ChatBI 的基礎，解決了“能問”的問題，那智慧資料分析則是 ChatBI 的昇華，幫助使用者從資料中發現業務異常、尋找根因，獲取洞察。

我們首先來看下資料分析的三個關鍵要素：正確的資料、強大的演算法和合理的業務流程。正確的資料是資料分析的基礎，我們上面講的智慧選表、Text2SQL，給資料分析提供了所需要的資料；強大的演算法決定分析的上限，雖然 LLM 可以直接理解資料，但是效率低、容易出錯，這就依賴於我們自建的資料分析演算法庫；合理的業務流程可以事半功倍，尤其是根因分析，涉及複雜的業務，需要合理的流程進行分析，而不是一股腦得把所有指標都拿出來扔給演算法，那樣不僅效率低，而且可能得出錯誤的結論。

演算法介紹

為了支援 Chatbot 的異常檢測和根因分析能力，我們構建了一套完備的演算法服務，核心功能涵蓋：

時序預測：該能力不僅能為使用者輸出指標預測結果，更是異常檢測、下鑽分析等複雜業務分析的基礎。目前線上部署的模型包括針對特定業務指標最佳化的 NBEATS 模型，以及基於開源 timer 模型微調的定製化模型。
指標時序異常檢測：在《從零開始構建業務異常檢測系統，Freewheel 面臨過的問題和解決方案》一文中，介紹了我們的解決方案和線上系統。我們部署了基於特定業務指標訓練的 NBEATS 模型、開源 Timer 模型微調等多個神經網路模型，將核心系統服務化，實現對各類業務指標的動態異常監測，Precision 和 Recall 均超過 90%。
業務實體離群點檢測，透過分析同一類廣告實體（如 Campaign）的某一個業務指標，精準識別偏離正常分佈的異常實體（即那些指標不符合正常分佈的 Campaign）。
轉化漏斗分析：對業務轉化漏斗建模，當漏斗底部指標出現異常下降時，該演算法可回溯各環節資料，快速定位影響轉化效果的關鍵節點。
下鑽（Drill Down）分析：作為最常用的分析手段，包括單維度下鑽和動態維度下鑽，支援 Hotspot、Adtributor 等多種下鑽演算法，幫助使用者層層拆解資料維度。
指標相關性分析：透過量化指標間的關聯關係，輔助使用者定位業務異常的根源。

Workflow or Agent

最後來說最重要的，合理的業務流程。面對豐富的演算法體系，如何將其轉化為便捷可用的分析服務？我們融合業界主流的 Workflow 與 Agent 兩種模式，構建起演算法服務與資料分析全流程之間的橋樑，確保演算法精準執行，為使用者提供可靠的答案。

Workflow

在資料分析場景中，有大量的問題是頻繁被問到的，例如 "Why impression drop"（為什麼曝光數下降了）、"Why the fill rate is low"（為什麼廣告填充率低）等，這些問題通常有明確的診斷路徑和解決方案。而 Workflow，也就是工作流，具有解決方案成熟、流程相對固定、準確率高的特點。因此，我們基於已有演算法能力，構建工作流，將這些常見問題的解決思路進行標準化預定義，將資料查詢、演算法處理、視覺化等流程封裝為統一的工作流，供使用者直接呼叫，實現高效準確的分析。

以廣告曝光數（impression）下降為例，這是它的 Workflow，透過下鑽分析定位問題，依次檢查廣告填充率、渲染率、廣告位數和流量等，最終找到根因是流量下降。

下面看一個更復雜一點的業務問題分析的例子。使用者發現他的負責的某一個 Network 的廣告曝光量出現了下降，希望知道原因，但他並沒有太多分析經驗，有了 Chatbot 之後，可以直接提問“Why the impression drop for network XXX yesterday?" 這個問題直接命中了系統內建的工作流，執行路徑如下：

定位 impression 異常下降的具體時間段→從可能的維度進行下鑽，定位到發生問題的 inventory（流量實體）→確認 fill rate（廣告填充率）是否同步下降→是→分析 placed rate（預填充率）是否同步下降→按 sales channel（銷售渠道）進行下鑽→定位發生問題的（多個）銷售渠道→對具體的銷售渠道的廣告投放進行轉換漏斗分析→定位到某銷售渠道 candidate ads（候選廣告數）出現下降→定位到具體的 demand entity（廣告銷售實體）

Agent（智慧代理）

工作流的侷限在於靈活性不足，難以覆蓋所有使用者的長尾需求。為滿足靈活分析場景，我們引入 Agent 機制。透過將 Text2SQL、資料查詢與解析、上述演算法服務封裝為 Tool，交由 LLM 排程與組合執行，生成個性化、動態的資料分析流程，靈活響應複雜多變的使用者需求。

我們看下 Agent 的結構，它由 Planner 和 Executor 組成，如下圖所示：

Planner 負責制定計劃、彙總當前的狀態，給出結論，可以搜尋知識庫中的解決方案，在不確定時詢問使用者，讓使用者給出更多資訊或者請求使用者審批下一步動作；
Executor 負責呼叫取數工具和演算法工具（包括時序預測、異常檢測、下鑽分析、漏斗分析等多種演算法），診斷錯誤並自適應調整演算法引數，同樣在遇到處理不了的錯誤時詢問使用者的處理意見。

在處理使用者需求時，Agent 會基於資料分析經驗與典型工作流示例，讓 LLM 透過 CoT 的方式動態規劃處理路徑。典型流程為：先透過 Text2SQL 完成資料檢索，再呼叫下鑽分析等演算法進行深度挖掘，如果中間遇到錯誤，Agent 將診斷錯誤並自適應調整演算法引數進行重試，最終將結構化分析結論反饋給使用者。

Agent 的架構設計我們也在持續探索中，包括引入反思，多 Agent 協同等，受限於篇幅，Agent 系統的具體實現將在後續文章中詳細展開。

那麼，系統如何決定是呼叫 Workflow 還是 Agent？我們擴充套件了意圖識別模組，透過分析使用者提出的問題並識別其屬於常見場景還是複雜個性化需求，自動路由至對應的處理方案。後面我們將對該模組進行詳細介紹。

系統實現與最佳實踐

在 Chatbot 的功能體系中，資料查詢、視覺化與分析能力固然重要，而準確把握使用者意圖、智慧追問與多輪對話則為其賦予了“思考深度”和“互動溫度”。在複雜多變的實際場景中，使用者需求往往模糊難辨，單次提問難以完整傳達意圖。Chatbot 的智慧追問與多輪對話功能，透過主動澄清意圖、延續分析脈絡，實現高效人機協同，顯著提升互動體驗與分析準確性。

架構

我們透過 Agentic 系統來實現智慧追問與多輪對話，以及 Chatbot 的整體架構，我們透過 LangGraph 搭建了 Agentic 的整體框架，如圖所示：

Router

Router 是核心節點，藉助 LLM 識別使用者的意圖，並透過呼叫多個工具、Workflow 或者 Agent 來回答使用者的問題。

LLM 繫結的 Tools 包括：

Ask Human：Ask Human 是實現 HITL 的核心，透過呼叫 Ask Human 暫停 Graph 的執行，並將 LLM 追問的問題返回給使用者，等待使用者回答後，將答案返回給 Router
Keywords Extraction：上文提到的，提取問題中的關鍵詞，包括維度、指標、條件、時間等
Search Knowledge：從知識庫中檢索相關知識，知識庫主要包括通用業務知識庫、資料目錄和元資料，針對不同的資料融合利用上文提到的多種檢索方式，確保相關知識被檢索到

Router 的 LLM 提示詞中包括了通用業務知識、意圖分類指導、知識問答指導等。

對於知識問答來說，Router 可以直接生成答案，也可以呼叫 Search Knowledge 從知識庫中檢索相關知識後再生成答案。
對於單純的資料查詢，Router 在呼叫 Keywords Extraction，確保使用者提供的資訊完整之後，直接呼叫 Text2SQL 即可，如何使用者的問題模稜兩可，則會呼叫 Ask Human 進行追問。
最複雜的是資料分析，如果問題被某 FAQ 工作流覆蓋，Router 會直接選擇執行該工作流；否則，Router 會將資料分析任務交給 Agent 來處理。

一個例子

以一個實際場景為例：當用戶提出問題 “Which site caused the impression drop for ABC during XXXXXX?” 時，Chatbot 會按以下流程完成分析：

意圖解析與關鍵資訊提取：Router 模組首先識別該問題屬於資料分析範疇，透過呼叫 Keywords Extraction ，精準提取出分析維度（site）、核心指標（impression）、限定條件（ABC）以及時間區間（XXXXXX），並路由至資料分析 Agent。
SQL 查詢構建與資料獲取：Agent 呼叫 Text2SQL 功能，根據提取的條件自動生成 SQL 查詢語句。為了更科學地對 “異常下降”進行下鑽分析，系統會將時間區間向前拓展，以便獲取更多歷史資料用於預測異常區間的期望值。生成的查詢語句如下：

SELECT event_time, site, SUM(impression) as impressionFROMtableWHERE condition_ABC and time_condition_XYZGROUPBY1,2

執行該查詢後，結果將被解析為各個 site 對應的 impression 時間序列資料。

預測與異常定位：Agent 呼叫 Prediction 模組，對當前時間區間的指標資料進行預測。最後，Agent 呼叫下鑽分析演算法，精準定位導致 impression 下降的那些異常的 site。
總結結論，輸出支援性資料和圖表

上下文最佳化

對於有十幾個與 LLM 互動的節點的這樣一個 Agentic 系統來說，為了能保持對全域性上下文的敏感，又能確保單輪任務的高效與精準，各模組設計如下。

Router: 作為直接和使用者互動的模組，Router 在利用 LLM 識別意圖時可以看到 Session 內完整的歷史對話，包括使用者的問題以及 Chatbot 的回覆摘要，摘要主要是對其中的 SQL、資料圖表進行抽象，避免冗餘資訊，節省 token 數；
Text2SQL: 作為相對獨立的模型，Text2SQL 僅能看到歷次對話的原始問題和 Router 基於上下文擴寫之後的問題，以及 SQL 生成結果，控制 token 數目，確保專注於生成 SQL，提高生成效率；
Agent: Agent Planner 與 Router 一樣，同樣可以看到 Session 內完整的歷史對話，以及 Agent 內部的 Plan 與 Execute 日誌，從而在制定與執行任務時，結合全域性和自身反饋即時調整策略。

使用者反饋

鑑於業務場景與資料結構的複雜性，Chatbot 無法始終保證回答絕對準確。為此，我們引入使用者反饋學習，構建閉環最佳化流程，以不斷提升系統準確率與使用者滿意度。具體流程如下：

使用者反饋收集： 透過引導使用者對結果點踩或點贊，收集使用者反饋，點讚的 SQL 可以加入樣例庫中，使用者可對生成的 SQL 提出修改建議，或對分析結論進行質疑。
LLM 驅動預審： 引入 LLM 對使用者反饋與現有知識進行自動比對，若模型判斷反饋與當前系統輸出存在顯著偏差，則標記為“高風險反饋”，並提交人工稽核，否則可以即時更新知識庫。
人工複核與歸檔： 業務專家對高風險反饋進行稽核和修正，經人工確認的更新同步回知識庫，完成閉環。

透過上述機制，系統不僅能夠快速吸納使用者智慧，還能在自動化與人工複核的協同下，持續提升回答質量和使用者體驗。

實踐經驗

下面分享下我們的一些實踐經驗。

開發框架

在開發框架選擇上，一開始我們用了 LangChain 和 LlamaIndex；後來感覺到有倆問題，一個是框架用起來很繁瑣，第二個是不夠透明，不好 debug，因此我們改成不用框架自己手寫；LangGraph 出來以後呢，一是正好解決了我們 HITL 的需求，二是 Graph 的結構清晰，能夠表達我們的流程，就逐步切到了 LangGraph 上。

基座大模型

LLM 目前我們同時在用 GPT 4.1 和 Claude 4 Sonnet，互為熱備，生成出錯或者檢測到幻覺可以動態切換。意圖識別和語義理解等多數任務預設使用 GPT，GPT 4.1 在成本和速度上都優於 Claude 4 Sonnet。在 SQL 生成 Agent 中優先使用 Claude 4，它的程式碼生成和問題規劃能力要強於 GPT。

資料安全

由於我們對 LLM 的依賴較深，尤其在推理能力與低幻覺表現方面，Chatbot 需接入如 Claude 3.5/4、GPT-4o/4.1 等公有云上強大的模型。這也帶來了資料安全的關鍵問題：如何確保公司和客戶資料不被洩露？除了依賴 LLM 服務商自身的安全合規承諾外，我們還引入了 私有化部署小模型的協同方案。我們基於 AWS SageMaker 部署瞭如 Gemma-4B 等成本可控的小模型，承擔資料預處理任務。具體做法包括：由小模型先行進行資料脫敏處理，如識別並提取客戶 ID 等敏感欄位，將其替換為隨機佔位符，在與外部 LLM 互動時避免洩露真實資料；最終結果返回後，再將佔位符替換為原始資訊，確保使用者體驗完整且資料安全。此外，諸如資料總結等通用性強、對推理能力要求相對較低的任務，也完全可以交由本地小模型獨立完成，進一步降低風險和成本。

Prompt Engineer

我們的 Prompt 統一使用 Markdown 格式，使用 Promptfoo 進行 Prompt 測試，使用 Langfuse 作為 Tracing 工具。

總結與展望

Insights Chatbot 上線後收穫了使用者的廣泛好評，尤其是在以下人群中效果顯著：花費大量時間手寫 SQL 的資料分析師、頻繁尋找資料的運營人員、以及需快速定位線上問題根因的 Account 團隊。同時，我們也收到了許多寶貴的使用者反饋，例如，不知道如何提問、不確定資料是否可信、根因分析流程不夠透明等。針對這些問題，我們已著手進行了多項最佳化：

引入“提問建議”功能引導使用者提問；
我們開放 Text2SQL 模組的關鍵中間結果（如選表依據、生成的 SQL 和相應的解釋）以增強可解釋性，展示 SQL 自評估結果；告知使用者當前查詢結果的注意事項，如業務上的預設過濾條件，資料能否去重等；
對於根因分析演算法過程不夠透明的問題，我們展示演算法過程中的決策資料和支援資料，比如，在下鑽分析中增加子屬性的統計資訊與趨勢圖。

展望未來，我們將持續推動系統能力提升。Text2SQL 方面，透過包括 RAG 精細最佳化、最佳化語義表達、借鑑 Alpha-SQL 的思路進一步拆分流程，進一步提升生成準確率，對常見問題快取可以提高響應速度。Agent 上我們計劃支援生成並執行資料分析 Python 程式碼，以及探索更多 Agent 架構，進一步提升 Agent 的能力。同時，覆蓋更多的業務場景，幫助使用者解決更多的問題。隨著 LLM 能力演進與系統持續最佳化，我們相信 ChatBI 將真正融入日常業務流程，幫助使用者節省 90% 的重複性工作，讓資料的價值最大化。

作者簡介

鍾雨，本科和研究生就讀於清華大學，現任 FreeWheel 資料應用部門主任演算法工程師，資料智慧演算法團隊負責人，負責業務異常檢測、根因分析、ChatBI 等。曾供職於京東廣告資料團隊，Spark Contributor，具備豐富的大資料開發與調優、資料探勘和機器學習、大語言模型應用等經驗。

程式設計師還寫啥前端？Claude 工程師凌晨2點造出Artifacts：AI直接生成可互動App，現在又重磅升級了

一天 15k 星，程式碼生成碾壓 Claude，連 Cursor 都慌了？谷歌 Gemini CLI 殺瘋了

React 被指“淪為 Vercel 打工仔”，力推框架只為圈錢？核心成員親自下場回應卻遭群嘲