本文整理自QCon北京《王新波 - AI取數到智能分析演進之路》通過AI音視頻轉錄總結工具Ai好記視頻轉文字轉錄整理以下為精煉整理后的會議筆記內容。做 AI 取數Text-to-SQL的同學應該都體會過那種落差。學術界的 benchmark 上Spider 這類數據集的 SOTA 方案準確率能做到 85% 到 91%跟人的水平差不多了。可一旦把同樣這套方案搬到真實企業的生產環境里準確率直接掉到 10% 到 40%連 SQL 的語法準確率都只有五成上下。這篇內容講的就是一個團隊用兩年時間把一個簡單的一周做出來的 AI 取數 demo一步步迭代成支撐幾千人生產使用的企業級智能分析 Agent 的全過程。整個過程踩坑密集很多思路對做數據平臺和 Agent 的人都挺有參考價值。背景數據消費進入 4.0 階段數據消費大體經歷四個階段。1.0 是傳統 BI 時代以 SAP 為代表報表交付靠開發團隊寫 SQL。2.0 是自助式 BI以看板類工具為代表但作者提到自家月活 2 萬多的看板里只有不到 10% 的人是報表生產者大部分人的數據消費還是要靠少數據 BI 同學手工操作。3.0 是增強分析開始引入 AI 輔助但流程仍由人驅動。4.0 才是 AI 原生的 Agent 時代用戶直接用自然語言提交分析需求Agent 自主完成從取數到智能分析的全過程。第一版 demo 暴露的五大問題他們的第一版架構很典型把平臺上近 30 天有訪問的約 100 萬張表做向量索引用戶問題來了就基于相似檢索召回相關表構造 prompt 交給大模型直接生成 SQL。結果第一版評測集上找表準確率只有 56%SQL 執行準確率不到 40%。同時期商業模型裸跑企業級 benchmark 也只有 10% 左右。總結下來有五大核心問題找表不準數倉分層多相似表成百上千向量模型難以區分細微差別召回的通常是語義相關但不正確的表。SQL 語義錯誤只用 Hive 元數據缺少業務規則和數據口徑生成的 SQL 能跑但計算邏輯和結果不對。SQL 語法錯誤大模型混用各引擎專有語法在目標引擎上直接報錯。模型幻覺生成表里不存在的字段、引用其他表的列名。交互割裂取數、找數、可視化幾個入口相互獨立連續分析要在入口間來回切。評測缺失評測集只有 50 多條脫離生產環境沒有說服力。五次關鍵躍遷從單鏈路到場景化分析整個演進就是被這五大問題驅動的五次躍遷。第一次躍遷Multi-Agent 加元數據漸進式披露核心是雙層架構。上層 Supervisor Agent 負責背景知識加載、意圖識別、任務拆解和編排調度下層專業 Agent 分三個角色數據域確認 Agent、表發現 Agent、SQL 生成 Agent。關鍵設計是在確認數據域和發現相似表之后都引入用戶確認環節兩層確認機制保證 Agent 生成過程不走偏。配合漸進式披露解決上下文浪費。傳統 RAG 一次性召回十幾張表、每張上百字段上下文能占到 100K 上下但真正有用的可能只有 1 到 3 張表還容易觸發長上下文腐化。他們的方案分三層先基于意圖和背景定位業務域從百萬級表縮到域內數百張再做域內表發現靠語義檢索加熱度排名挑出候選表交用戶確認確認后才展開完整字段和業務規則。一個用戶問「東南亞昨天 GMV 多少」能精準定位到 marketplace_order 域再落到訂單明細表。第二次躍遷雙層個性化AI 回答千篇一律是新的痛點。同樣是問「GMV 為什么下跌」電商運營關心的是 marketplace 訂單表數據財務關心的是全局匯總數據。他們引入兩層個性化一是用戶畫像從權限平臺拉取組織架構、角色、地域、數據權限等靜態數據讓 Agent 開口之前就認識用戶自動傾向于推 SG 相關表和加地域過濾條件二是用戶記憶把點贊、點踩、常搜表、歷史口徑確認等交互行為持久化跨 session 加載讓 Agent 越用越懂用戶。第三次躍遷語義模型突破準確率天花板純大模型生成 SQL 有三重挑戰業務語義理解口徑怎么定表關聯推理數倉層級多SQL 物理實現分區怎么選、多方言語法方案是引入語義模型作為數據抽象層做三件事業務數據映射到物理表字段和計算邏輯預定義標準指標、維度、過濾條件封裝復雜性對外呈現統一的寬表概念。處理同一個問題純 Text-to-SQL 要串行推斷口徑、對應物理表、過濾條件、按什么口徑算任何一步錯數據就錯。基于語義模型只需生成一個極簡 DSL后面的 SQL 映射交給語義引擎用工程方式翻譯。最終采用混合路由簡單探索性問題走傳統 Text-to-SQL復雜且有語義模型覆蓋的走 Text-to-DSL 鏈路。配套做了輔助語義建模 Agent輸入表結構、線上 SQL 運行日志、現有報表配置三類元數據輸出指標推薦、維度識別、關鍵路徑發現、數語關系映射的建模草案人工審校后才上線并形成「建模、查詢、驗證、優化」四步反饋循環持續迭代。第四次躍遷復雜工程底座面向生產穩定運行工程體系分技術、評測、運營三塊。技術部分重點講了兩個。文件系統上下文取數場景的上下文比普通 chat agent 復雜得多表元數據、語義規則、個性化數據、用戶補充的內容全塞進去必然溢出。他們把知識用文件系統接口按層級組織最上層只加載用戶畫像定位數據域再加載域知識確認表后才展開詳情不需要的信息隨時從窗口 offload。中間結果也以 dataframe 形式存進虛擬文件系統模型只持有路徑引用按需加載避免了多步驟分析中途結果擠爆上下文。隔離沙箱每個 session 的 Agent 跑在權限隔離、資源隔離的沙箱里高危的代碼執行、Python 執行工具都在沙箱內運行防止惡意 prompt 借強大工具做破壞性操作。評測體系從踩坑中總結早期 QA 只做了 50 多條脫離場景的評測集沒法用。后來改為面向分析主題、用線上真實執行成功且頻繁的 SQL 構造評測集讓大模型反向生成自然語言問題再人工 review最終積累三四千條。結果比較放棄語法樹對比同一語義多種寫法和大模型對比復雜場景分數差改以執行準確性為主配合時間字段規整、列一致性編輯距離、浮點容差比較。第五次躍遷Skill 機制實現場景化分析讓 Agent 自由做歸因探索時發現它常繞過關鍵維度下鉆直接給結論專業 BI 無論對錯都不敢用因為過程不可驗證。Skill 機制在模型自主分析和定制流程間找到平衡。以歸因分析典型 Skill 為例是嚴格五步指標趨勢判斷按國家品類渠道維度拆解計算貢獻度排名和交叉分析按影響因子排序找根因生成結構化分析報告步驟不可跳過中間結果可追溯可驗證。價值在于一次定義全員出發、過程可信、可擴展。元數據治理這個臟活作者特意強調data agent 不能只關心模型和工程架構數據質量同樣關鍵。平臺百萬級表大量缺描述他們設計了 AI 加人工的四步治理按業務過程和數倉層級分組AI 生成描述草案依賴表名字段和業務域建模文檔業務方逐條審查采納血緣擴散自動為下游生成效果是 AI 生成描述直接被采納的比例 70%一張 40 列表治理時間從 30 分鐘縮到 10 分鐘人工治理 2000 張表通過血緣擴散覆蓋了 15 萬張以上找表準確率最大提升 15 個百分點。未來趨勢判斷作者給了幾個個人判斷harness 會是 Agent 的操作系統Agent 等于 LLM 加 harnessAgent-First 是說數據平臺應該面向 Agent 設計Agent 成為人和數據交互的新界面從工具到員工演進Agent 會獲得自主調度、Skill 自我生成與進化能力變成可獨立接收任務、修復、迭代的勞動力Agent 治理能力要始終伴隨落地。以上內容由 Ai好記 轉錄整理。Ai好記是一款支持音視頻轉圖文筆記的AI知識庫工具支持B站、小紅書、抖音、小宇宙等平臺鏈接及本地音視頻文件視頻轉文字后自動生成精華速覽、思維導圖和結構化圖文筆記幫助你把幾小時的視頻內容變成可搜索、可復習的圖文筆記。