想上線一個ChatBI，都需要關(guān)注什么？

ChatBI是今年比較火的一個話題，它和企業(yè)知識庫問答一樣，是ToB領(lǐng)域極少數(shù)有希望用相對低成本落地的LLM應(yīng)用；很多企業(yè)已經(jīng)對此有過一些探索，還有更多企業(yè)認為該技術(shù)尚不成熟， 還處在觀望狀態(tài)。

朋友圈看到有人說，預計90%的ChatBI項目都會失敗——在不做任何相關(guān)配套工作的前提下，的確如此。

關(guān)于下面的問題，相信計劃或正在探索ChatBI的很多朋友也都有困惑：

選擇什么樣的技術(shù)路線？

適合什么用戶來用？

想要落地成功，要做哪些準備？

經(jīng)過20余項目陪跑和100余客戶的深入交流，帆軟FineChatBI團隊積累了不少ChatBI的實踐經(jīng)驗，得到了很多反直覺的認知，在這里做一些分享，希望能可以幫助你少走一些彎路。 

技術(shù)路線選擇

帆軟的第一個觀點是：LLM寫SQL不靠譜。

LLM寫SQL是真的不靠譜，體現(xiàn)在3個方面：精度、性能和可信性。 

1、精度

帆軟判斷，對業(yè)務(wù)用戶來說，即使再有容忍度，平均精度要達到75%~80%才能保證不會棄用。 

LLM幻覺是一個已知問題，它在一定程度上是可以被容忍的，但如果在數(shù)據(jù)的應(yīng)用，它會被嚴重放大；在用戶眼里，對于非結(jié)構(gòu)化的數(shù)據(jù)，結(jié)果不滿意，大不了我再問一次，而結(jié)構(gòu)化數(shù)據(jù)答案是不可以錯的。 

LLM寫SQL時，會在哪些地方會有幻覺？帆軟和一些客戶對LLM寫SQL做過不少嘗試，目前已經(jīng)發(fā)現(xiàn)并且判斷很難解決的地方比如對時間理解錯誤、排序邏輯錯誤、子查詢錯誤、錯誤理解表關(guān)聯(lián)關(guān)系等等； 

FineChatBI的選擇是，用LLM把用戶的問題轉(zhuǎn)寫成結(jié)構(gòu)清晰的查詢語言（表達清晰的語句甚至不需要轉(zhuǎn)寫），用OLAP分析操作指令集調(diào)用FineBI這樣一個成熟的底座，以模擬人工拖拉拽的形式直接出圖，這樣生成的圖表直接和轉(zhuǎn)化后清晰的問題意圖相匹配，精度得到大幅的提升。 

2、性能

現(xiàn)在一個寫SQL為主的產(chǎn)品，返回一個問題能做到6s已經(jīng)是優(yōu)秀了，部分Text2SQL產(chǎn)品的返回時間甚至能到都在12s甚至15s以上。一個問題等10s，這個性能，用戶真的能接受么？ 

帆軟認為，一個用戶能接受的最長問題的返回時長必須控制在3S內(nèi)，否則體驗太過糟糕，用戶也不會堅持用下去； 

影響LLM寫SQL性能的變量有：LLM模型的尺寸、是否本地化部署、硬件資源投入如何、SQL語句復雜度等； 

上面已經(jīng)提到了，F(xiàn)ineChatBI并沒有選擇讓LLM寫SQL，而是通過一個小尺寸的語義解析模型處理清晰語義，LLM去處理模糊語義，帆軟實現(xiàn)了清晰語義返回平均能到0.2s，模糊語義平均能做到2s。 

3、可信性

ChatBI在應(yīng)用中，難免會有錯誤的答案，怎么才能排查到結(jié)果對錯？如果答案是錯的，怎么能快速修復？解決這兩個問題，才能代表一個ChatBI產(chǎn)品具有可信性。 

Text2SQL路線，一般會給到用戶一串SQL語句，這個思路最開始被很多IT認可，因為直覺表明這樣是可以看清楚答案，也容易調(diào)試；實際上，這不是一個用戶思維導向的設(shè)計：業(yè)務(wù)用戶看得懂SQL么？他們想要看SQL么？另一方面，帆軟發(fā)現(xiàn)SQL的調(diào)試工作難易程度是和SQL語句的復雜度正相關(guān)的，再考慮到多表關(guān)聯(lián)查詢，如果在測試期間沒有探索到它的邊界，在應(yīng)用實際落地的時候，結(jié)果排查和錯題修復的挑戰(zhàn)會很大。 

FineChatBI給到了用戶一段可以清楚讀懂的圖表生成規(guī)則，同時，用戶可以調(diào)整其中的維度、指標、枚舉值、分組條件等，按照自己的設(shè)想二次點選生成新的相關(guān)圖表；另外，結(jié)合強大的FineBI底座，對于一些SQL很難支持的問法都可以通過FineBI原生支持的快速計算輕松實現(xiàn)。 

ChatBI怎么落地？

帆軟的第二個觀點是：ChatBI不能開箱即用。

一個ChatBI項目想要成功落地，需要有它的天時地利人和： 

天時，是要公司內(nèi)能找到真場景，業(yè)務(wù)真的有需求；

地利，是要落地團隊有成熟的數(shù)據(jù)和知識的底層準備；

人和，是要有配套的組織驅(qū)動力，能鏈接到業(yè)務(wù)調(diào)研到真實需求，有明確的責任人能披荊斬棘往前推進。

1、真場景

2024年的FineChatBI就像是一個創(chuàng)新藥在上市前需要做臨床試驗，帆軟在與客戶共創(chuàng)的過程中，遇到過最大的挑戰(zhàn)是，一些客戶并沒有找到自己的痛點，硬套ChatBI作為一個解決方案，最后發(fā)現(xiàn)沒有效果。 

建議最好是能多和業(yè)務(wù)團隊對話，了解他們?nèi)粘Ｈ?shù)場景是什么樣的，遇到過哪些痛苦，然后對癥下藥去干。 

當然，如果客觀上存在困難，不得不先嘗試，基于成熟的數(shù)據(jù)去開發(fā)demo給用戶中的積極分子，通過這個過程去找場景，但是成功率恐怕會很低，需要有一定的心理準備。 

那么ChatBI的用戶到底是誰? 

從用戶數(shù)、使用頻次、使用場景來出發(fā)，帆軟分別來看，適合使用ChatBI的用戶群： 

2、底層準備

1）數(shù)據(jù)側(cè)

重要的事情說三遍：LLM并不擅長數(shù)據(jù)加工！LLM并不擅長數(shù)據(jù)加工！LLM并不擅長數(shù)據(jù)加工！  

帆軟判斷，50%的數(shù)據(jù)消費應(yīng)用的推動都受到了數(shù)據(jù)底層準備的影響，ChatBI對數(shù)據(jù)的要求比BI要更高一些，一般體現(xiàn)在避免字段名歧義、數(shù)據(jù)不能有冗余、確保字段類型正確等； 

準備好寬表，或干脆搭配指標管理平臺吧，否則你會無比痛苦。 

2）知識側(cè)

知識配置是不可避免的，它并不是丟一些語料給LLM就可以解決的； 

就好像所有梁山好漢都喊宋江一聲“哥哥”（語料），那么再先進的LLM也不可能知道宋江就是及時雨（黑話），既然黑話要準備映射表，為什么不直接做配置，反而舍近求遠去訓練LLM呢？ 

在帆軟的實踐中，知識配置分為兩類，一類是同義詞，一類是企業(yè)獨有的一些其他知識，如重點城市=成都市+貴陽市 華北地區(qū)=山東+山西+河南+河北； 

在FineChatBI中，同義詞只需要配置必要的、預計AI肯定猜不出來的企業(yè)獨有知識，相似的語義或相似的字段是不需要配置的： 

對于相似的語義，如字段名為銷售額，問業(yè)績，這個通過LLM是可以猜出來的； 

對于相似的字段，如字段名為娃哈哈100ml礦泉水，問娃哈哈礦泉水，這個通過算法可以匹配到的。 

3、組織驅(qū)動力

帆軟的第三個觀點是：ChatBI不適合先給領(lǐng)導用。 

帆軟認為，ChatBI項目要成功，在企業(yè)內(nèi)部需要至少3個角色的，這三個角色可能是2個人，也可能不止3個人，他們分別是：領(lǐng)導、產(chǎn)品經(jīng)理和IT。 

1）產(chǎn)品經(jīng)理：最核心的角色，承擔整個項目成敗的KPI，整體節(jié)奏規(guī)劃，用戶群確定、需求收集和識別、內(nèi)部推廣，拓展運營等； 

ChatBI的上線是一個循序漸進的過程，由產(chǎn)品經(jīng)理主導，大概執(zhí)行下面的流程： 

①項目團隊組建——>職責拉通——>需求調(diào)研——>需求評估——> 

②選定目標業(yè)務(wù)域1——>數(shù)據(jù)準備——>知識配置——>權(quán)限配置——>內(nèi)部測試——>試點運行——>后臺分析——>用戶回訪——>用戶培訓——>系統(tǒng)上線——>錯題修復——>成果匯報——> 

③選定目標業(yè)務(wù)域2…………………… 

從上面的流程中，相信各位不難看出，當項目之初，產(chǎn)品經(jīng)理還不具備一定經(jīng)驗，該項目還沒有獲得領(lǐng)導的信任和理解時，可以確定很難做好對領(lǐng)導的需求收集、預期管理等。 

因此，ChatBI并不適合一開始就給大領(lǐng)導用，也不適合大規(guī)模并行推廣，而應(yīng)該線性推廣，不斷地干成、夯實，再拓展。 

2）領(lǐng)導：拍板決策投入，保障產(chǎn)品經(jīng)理獲得必要的業(yè)務(wù)支持，參加項目啟動儀式，現(xiàn)場明確項目范圍、項目成功標準、時間節(jié)奏等； 

3）IT：數(shù)據(jù)準備，數(shù)據(jù)底層設(shè)計，IT配置。 

另外還有2個角色會起到很重要的作用： 

①業(yè)務(wù)代表，代表本業(yè)務(wù)團隊為產(chǎn)品經(jīng)理輸入需求，講清楚痛點； 

②業(yè)務(wù)團隊中的ITBP，這個角色可以協(xié)助IT進行知識配置和數(shù)據(jù)維護、權(quán)限配置，否則IT單方面很難完整收集到業(yè)務(wù)團隊里的知識和權(quán)限配置要求。 

對于第一個完整業(yè)務(wù)閉環(huán)，帆軟經(jīng)過這一年來的打磨，推出了一個【場景陪跑服務(wù)】，幫助客戶把第一個場景用起來。 

想正式上線一個ChatBI，還有哪些要關(guān)注的？

在預計場景、底層準備、組織驅(qū)動力三個條件都具備的前提下，ChatBI的落地成功率是很高的，這個時候如果要正式上線，安全性、算力成本、持續(xù)運營投入是你一定會關(guān)注的地方。 

1、安全性：

是否具備企業(yè)級權(quán)限控制能力、LLM是否支持本地化部署。 

2、算力成本：

理論上LLM的尺寸越大效果越好，但更大尺寸意味著更高昂的硬件資源成本，F(xiàn)ineChatBI采用基于小尺寸開源 LLM 完成多任務(wù)精調(diào)的FineLLM，對資源成本要求是很低的。 

3、持續(xù)運營投入：

我們常常會感嘆模型日新月異的能力效果，卻忽略了這個效果背后的迭代頻率。 

同理，我們常常會關(guān)注一個ChatBI產(chǎn)品的精度，卻忽略了這個精度背后的定義和條件，是1個人使用下的精度，是10個維度指標下自由組合的精度，還是上線僅兩天的平均精度？ 

當用戶數(shù)擴大，當數(shù)據(jù)范圍擴大，當時間線拉長，對精度的影響都是立竿見影的，這背后的迭代頻率也是非常快的； 

在企業(yè)內(nèi)部，ChatBI的受眾肯定是逐步在增大的，所以團隊是否考慮過單獨的資源來承接這些運營調(diào)優(yōu)的工作，是否有方法論指導怎么優(yōu)化，產(chǎn)品是否有相關(guān)功能支撐范圍擴大后去運營提升問答效果，都是需要重點考慮的。 

最后：對LLM的祛魅

ChatBI首先是一個嚴肅的企業(yè)級應(yīng)用，其次才是AI；而LLM，它包含于AI，而不是等于AI。

一個企業(yè)級應(yīng)用，不管有沒有AI，不管用了什么技術(shù)，它的核心目的始終都是幫助客戶安全、穩(wěn)定、低成本地解決業(yè)務(wù)上的問題，進而創(chuàng)造價值。 

FineChatBI在設(shè)計過程中，帆軟綜合去考慮穩(wěn)定性、性能、客戶成本等很多因素去選擇實現(xiàn)方法，對LLM的使用始終持著謹慎樂觀的態(tài)度； 

有一些能力比如模糊檢索，LLM可以做，有成熟算法也可以實現(xiàn)，帆軟可以提供的方案是把枚舉值都給LLM做訓練，客戶擴大自己的模型尺寸就行，但如果用算法實現(xiàn)，客戶的成本是不是會更低，所以帆軟的方案未必是LLM實現(xiàn)； 

有一些配置工作，比如知識配置，交給LLM去落地，客戶的綜合成本是人工配置的幾十倍，效果也不穩(wěn)定，所以帆軟并不建議客戶交給LLM去處理； 

再比如很多能力，LLM原本就不擅長，如預測、離群點識別等，都是靠其他更適合的AI能力實現(xiàn)的； 

而AI之外的功能，比如可視化，更不是LLM擅長的。 

商業(yè)化的ChatBI，是一個很考驗廠商態(tài)度、研發(fā)投入和能力的事情，做這個事情是為了炫技，還是為了落地，背后的難度和投入不是一個數(shù)量級的； 

本文主要是講今年業(yè)內(nèi)較為普遍地把【快速問數(shù)】作為ChatBI第一階段的落地經(jīng)驗，實際上的ChatBI不只是查數(shù)，它希望能幫助到廣大沒有專業(yè)分析背景的業(yè)務(wù)用戶自主完成一些個性化的分析工作，例如思路拆解、異常檢測、歸因分析、趨勢預測、報告生成等。 

挑戰(zhàn)重重，但走在正確的路上，ChatBI幫助100%業(yè)務(wù)用戶用好數(shù)據(jù)，最終有一天是能實現(xiàn)的。