數(shù)勢科技研發(fā)的數(shù)據(jù)資產(chǎn)和數(shù)據(jù)分析相關產(chǎn)品，主要面向零售和金融企業(yè)，幫助其進行業(yè)務語義層資產(chǎn)構建，為企業(yè)提供基于大模型增強的數(shù)據(jù)分析 AI Agent、智能指標平臺、智能標簽平臺及智能營銷平臺，從而助力企業(yè)提升數(shù)字化決策能力，推動企業(yè)數(shù)字化升級。本文將分享如何基于大模型能力，疊加指標和標簽平臺能力，構建企業(yè)內(nèi)智能數(shù)據(jù)分析產(chǎn)品。

一、企業(yè)經(jīng)營分析的難點和挑戰(zhàn)

企業(yè)內(nèi)部的數(shù)據(jù)分析涉及到諸多方面，包括：加工制作報表；基于數(shù)據(jù)發(fā)現(xiàn)異常因素，開發(fā)人員需要通過 SQL 或算法去做多維異常檢測；進一步挖掘異常背后的原因，又需要因果推斷或者歸因洞察等算法；分析之后還需要撰寫數(shù)據(jù)分析報告。

早期的企業(yè)經(jīng)營分析主要是基于數(shù)據(jù)庫進行開發(fā)，通過寫 SQL 或者 Python 等編碼方式實現(xiàn)，開發(fā)門檻很高，企業(yè)內(nèi)部受眾大約只有 1% 左右。隨著 BI 時代的到來，利用無代碼化平臺，可以在平臺上拖拉拽，通過業(yè)務規(guī)則和業(yè)務邏輯配置的方式，快速生成報表和可視化展示，得到想要的結論。然而使用 BI 的人要有業(yè)務分析思維，同時熟悉產(chǎn)品和配置，這些要求也無法推廣到一線業(yè)務人員，因此受眾人群在企業(yè)內(nèi)部大概僅有 15% 到 20%。企業(yè)內(nèi)部其余的人想看數(shù)據(jù)做決策就需要提需求，經(jīng)過層層傳遞，最后通過業(yè)務分析師幫助得到想要的結果。

因此，業(yè)務團隊的痛點是在洞察數(shù)據(jù)時需要在一系列的鏈路層層傳遞需求，看到數(shù)據(jù)和結論需要很長時間的等待。而數(shù)據(jù)開發(fā)人員的痛點則是需要每天把時間和精力投入到開發(fā)無限的報表之中。因此我們希望利用智能分析相關產(chǎn)品來解決這些痛點。

智能分析需求大概可以總結為 5 個范式，面臨諸多挑戰(zhàn)：

• 最近 7 天 XX 產(chǎn)品的訂單總量多少？這種需求需要找到時間范圍、維度以及指標字段，比如訂單總量。
• XX 產(chǎn)品今年累計賣了多少？人通過語言提問有時會語義模糊，“賣了多少”可能指銷售量、訂單量、銷售額，大模型對這句話進行翻譯時，很難找到背后的字段和含義。
• 今年 XX 品牌在國內(nèi)和海外的整體銷量是多少？這個需求可能涉及多表查詢，比如國內(nèi)和國外分別有一張數(shù)據(jù)表，就需要通過 join 關聯(lián)關系把兩個銷量字段取出來。如何通過語言去實現(xiàn)跨表的關聯(lián)是一個挑戰(zhàn)。
• XX 品牌最近 3 個月國內(nèi)銷量最好的產(chǎn)品哪一款？每個產(chǎn)品平均每月銷量多少？用戶一句話的需求可能會有多個任務，這個示例是兩段式的任務，第一個要先找到國內(nèi)前三個月銷量最好的產(chǎn)品，然后再找到這個產(chǎn)品平均每個月銷量是多少。
• 華北地區(qū) XX 的銷量月環(huán)比為什么下降了？這個需求是一個隱含性假設任務，要先找到華北地區(qū) XX 的銷量的月環(huán)比，再判斷月環(huán)比下降值，再基于下降值，通過歸因算法去做一些維度歸因。用戶可能還會需要根據(jù)歷史銷量值生成折線圖等圖表生成任務。這些任務單純通過 NLP2SQL 是難以實現(xiàn)的。

用戶的一句話需求任務具有多樣性，利用大模型，可以把用戶的需求任務拆成多個子任務，再讓每個子任務根據(jù)對應的能力需求做串行或者并行的調(diào)用。Agent 的工作就是將任務拆解，拆解后的每個任務是一個最簡單的原子任務，再調(diào)用具有對應能力的 function 或 API，返回執(zhí)行結果，再根據(jù)結果反思是否需要做進一步的拆解，或者重新規(guī)劃求解。這就是 Agent 為數(shù)據(jù)分析領域帶來的幫助。

二、智能分析的路線選擇

智能分析有不同的實現(xiàn)路線：

• NLP2SQL：本質(zhì)是取數(shù)，大模型通過微調(diào)或 SQL 訓練集生成 SQL。當前更多地會結合 RAG，把生成式的任務改成填充式的任務，在生產(chǎn)中發(fā)現(xiàn)大模型做填空要比做生成穩(wěn)定性更高，其生成穩(wěn)定性會受到多方面影響，固定住 temperature 或隨機種子，模型在生成 100 個 token 之后隨機性會增加，大模型網(wǎng)絡間的梯度傳遞也會有隨機性波動，導致生成的 token 波動。在 SQL 生成時也會面臨一些問題，如何結合一系列衍生的能力，比如基于指標的歸因洞察、異常檢測以及制作可視化報告和圖表，還需要給到大模型各表描述，讓大模型去找到多表之間的關聯(lián)關系，大模型在判斷表之間關系方面的穩(wěn)定性會相對不足。
• NLP2API：把數(shù)據(jù)語義化封裝到 API。其本質(zhì)也是做填空題，確定 k 值之后根據(jù) k 的描述去填充其對應的 value，API 能把產(chǎn)品功能里復雜的邏輯封裝到 API，大模型只需要把用戶的語句 NLP2API，這種方式穩(wěn)定性會更高。
• NLP2Python：開發(fā)時用 code 的靈活性很高，code 可以突破 SQL 本身的一些局限性，通過 Python 代碼可以生成算法預測和歸因的模塊，但同時也會帶來穩(wěn)定性的不足。但隨著大模型代碼生成能力的增強，這種方式的能力也會逐步增強。

上圖示例是 NLP2SQL 的實現(xiàn)路徑，左邊是來自 OpenAI 的一個標準的生成 SQL 的示例，但是在實際生產(chǎn)過程中并非如此簡單。先指定一個系統(tǒng)指令 system prompt，還要告訴模型擁有的數(shù)據(jù)庫以及數(shù)據(jù)庫中表的具體描述，再基于標準的 SQL 拼接規(guī)范，生成 SQL。

同時，還要根據(jù)問題去設計 prompt 模板，并且要對 NLP2SQL 模型微調(diào)、評測和訓練。評測也存在挑戰(zhàn)，如何定義 SQL 生成的準確度，如何評估 SQL 的可執(zhí)行性？SQL 的可執(zhí)行性還需要考慮性能，不能只是可以執(zhí)行出結果，也要評估執(zhí)行出結果的耗時，才能達到企業(yè)級應用的標準。

NLP2API 是先定義好數(shù)據(jù)分析相關 API，比如 BI 系統(tǒng)和指標平臺的 API 和算法 API 等很多 API 池子，這樣就能通過 API 路徑實現(xiàn)搜索，通過搜索，找到合適的 API，再把用戶的語句翻譯成 API 參數(shù)完成對 API 的調(diào)用。這種方式的好處是 API 自帶校驗性，并且通過工程化而不是通過大模型生成的方式可以實現(xiàn)性能較好的 SQL 結果生成。

如何定義 Semantic API？數(shù)據(jù)本身沒有語義，我們要通過工具和手段對已有數(shù)據(jù)定義出其語義。

• 語義統(tǒng)一：大模型對語義理解相對比較好，但是模型學不到在企業(yè)內(nèi)部的行業(yè)黑話和術語，所以需要增加企業(yè)內(nèi)部的同義詞，幫助大模型去理解。
• 口徑統(tǒng)一：需要統(tǒng)一數(shù)據(jù)字段在企業(yè)內(nèi)部的技術口徑和業(yè)務口徑，保證字段和描述之間的口徑統(tǒng)一。
• 權限統(tǒng)一：企業(yè)內(nèi)部每個人或者不同部門能看到的數(shù)據(jù)應該不一樣，因為數(shù)據(jù)權限不一樣，在企業(yè)內(nèi)部做數(shù)據(jù)要考慮權限統(tǒng)一問題并融合到語義層。

為什么要基于指標和標簽去做 NLP2API？

• 面向對象理解：指標和標簽中封裝了業(yè)務邏輯和口徑，其分層結構設計包含了很多過濾條件和表達式，模型不需要理解具體內(nèi)容，而是將指標和標簽視為對象，面向對象去理解。
• 指標和標簽體系化設計：體系化設計增加了大模型召回命中率，因為每個指標層級下指標維度是少數(shù)的幾個，天然會有助于進行語義上的過濾， 使召回的范圍少且準，進而生成效果就比較準，所以指標體系輔助了語義理解召回的效果。
• 可解釋性高：解析結果可以通過要素反顯給用戶，相較于 SQL 更易被非技術人員理解。
• 衍生能力：通過指標體系可以衍生很多 API 或者 function 等分析能力（如歸因，預警，趨勢預測等），被大模型合理并無縫地銜接和調(diào)用。

上圖是上述三種實現(xiàn)路徑的優(yōu)劣勢對比，在實際場景中需要根據(jù)具體情況去選擇。在表不是特別多邏輯不復雜的時候，可以采用 NLP2Code 和 NLP2SQL。當業(yè)務邏輯復雜時或表多時，要通過一種底座和手段把數(shù)據(jù)在工程層面上提前做聚合，再讓大模型更好地去理解。

三、如何設計經(jīng)營分析 Agent

上圖展示了 SwiftAgent 的流轉鏈路。在用戶提出請求時，沒有完全拋棄 NLP2SQL 和 NLP2Code 的方式，我們通過一套意圖路由機制，在用戶 query 進來的每個節(jié)點做意圖判斷和路由，判斷是否能通過指標和標簽解決問題，在 Agent 機制下去做技能的采樣、元數(shù)據(jù)采樣、記憶采樣，即圍繞指標和標簽有哪些方式和 API 技能，元數(shù)據(jù)，以及歷史記憶。如果是指標和標簽之外的問題，我們會通過開放性的分析生成 SQL 的方式去做兜底。

上圖是 Agent 的簡要框架，不是每個問題需要通過 Agent 去做規(guī)劃和任務拆解，用戶的問題既有簡單又有復雜，而交互時效性要求較高，所以前期通過意圖識別機制，判斷問題類型是簡單還是復雜。針對簡單問題，就直接調(diào)用相關的技能做參數(shù)的 mapping 和解析。對于復雜問題，則通過 planner 機制，包括 ReAct 和 P&E，P&E 是做分步執(zhí)行，沒有反思，而 ReAct 時間較長，每步做反思，通過之前任務的結果去做校正。此外，還利用 RAG 去做動態(tài)的 embedding 嵌入，以及做歷史的上下文反饋，告訴大模型 goodcase 和 badcase。

總結來說，它具有規(guī)劃反思能力、意圖路由能力、垂直領域調(diào)優(yōu)能力。每個技能都要定義好描述，包括出參和入?yún)?，才能解析，之后拼接各項技能串行或者并行?zhí)行，匯總最終的結果，再通過 reward 分數(shù)判斷是否需要重新規(guī)劃路徑，如果是完成狀態(tài)，將結果發(fā)回給前端。

我們在設計 Agent 時遇到了以下難點：

1. 靜態(tài)規(guī)劃思路無法解決所有個性化提問方式

Planner 機制無法滿足千人千面的用戶個性化 query 實現(xiàn)。規(guī)劃方式有很多種，包括逐步思考分解法、P&E、批判法、假設法等。我們把每種方式形成原子 module，當用戶 query 請求時，通過判斷對應 query 應該選擇的思考 module，然后讓大模型基于選擇的思考方式組件，形成 planner 的 prompt，實現(xiàn)通過不同的思考方式執(zhí)行任務的鏈路。因此，對應的解決方法是首先進行思考方式的選擇，然后基于用戶的 query 和思考方式對 prompt 做修正，最后基于修正后的 prompt 讓大模型做解析。另外，還引入動態(tài)的 Few-Shot 的方式引導大模型持續(xù)執(zhí)行。

2. 任務規(guī)劃“穿越性”問題

指標分為原子指標、派生指標和衍生指標。比如用戶想要查詢過去一個月的累計銷售額，數(shù)據(jù)庫里可能既有原子指標銷售額，也有派生指標月累計銷售額，那么大模型如何生成規(guī)劃呢？如果只有月累計銷售指標，那只能生成上圖中第二種方式的規(guī)劃。如果兩個指標都有，可以規(guī)劃成兩個方式的任務，第一個是先查詢過去一個月每天的原子指標銷售額，然后再基于時間窗口累計求和，第二個是直接查詢最新時間一個月的月累計銷售額，這種情況下應該選擇哪種路徑去解決？有以下兩種解法，當前我們也在對比其效果：

• 第一種方式是基于指標樹關系設計，我們編排一個 DSL 模板，里面有 SUM 算子。當指標識別到月累積銷售額，口徑包含 SUM，就把 DSL 模板里的 SUM 算子去掉；而如果指標是銷售額就要用到 DSL 里的 SUM 算子。
• 第二種方式是在規(guī)劃時提前把已有的指標告訴大模型，它通過向量和關鍵詞召回等方式，返回相關的候選指標，再根據(jù)候選指標生成規(guī)劃路徑，一條規(guī)劃路徑是不穩(wěn)定的，我們會生成多條規(guī)劃路徑，從中選擇最短可執(zhí)行路徑，再拆分成具體的任務分步執(zhí)行。

3. 提升工具調(diào)用的效果

接下來探討如何提高 API 的調(diào)用能力。如果每次通過語言去解析到對應的參數(shù)，難以保證穩(wěn)定性。我們的基座模型是針對一些 case 去生成相應的結果，下一次它能夠遵循相應的結果去解析，這種方法穩(wěn)定性會比較高。告訴大模型工具的 description 和出參、入?yún)?，生?query，再基于這些 query 正向解析去調(diào)用工具得到對應的結果，這樣就會產(chǎn)生很多正負樣例，存到數(shù)據(jù)庫里，下一次調(diào)用相應的工具時，可以索引到對應工具的樣例，把樣例動態(tài)去引入到 prompt 里，再通過 prompt 調(diào)優(yōu)的方式學習，從而保證執(zhí)行的準確性。

4. 時間推理效果不穩(wěn)定

大模型時間推理效果極其不穩(wěn)定，主要原因包括：

• 語義割裂問題：比如“幫我看一下去年的銷售額是多少，按月呈現(xiàn)”，大模型理解時間實體時可能會忽略掉后面“按月呈現(xiàn)”的描述，而解析成 2023 年。
• 時間推理判斷：比如“6 月第 3 周”，大模型可能先去推理 6 月第 3 周是哪一周，具體是幾號之間，經(jīng)常會存在解析的日期不準的情況。
• 陳述模糊：比如“幫我看一下最近幾天的銷售額”，最近幾天表述模糊，大模型可能今天返回最近三天，明天又會返回最近 7 天，回答結果不穩(wěn)定。
• 歧義沖突：比如“幫我查看一下 6 月前兩天的銷售額是多少”，大模型可能有三種理解結果：6 月 1 號和 6 月 2 號，5 月 30 號和 5 月 31 號，或者是 5 月 31 號和 6 月 1 號。

大模型這種解析結果的不穩(wěn)定，會使用戶感覺效果不好，不利于用戶的使用體驗。

針對上述問題，我們的解決思路是，先以規(guī)則去保障穩(wěn)定性，開發(fā)一系列包括農(nóng)歷日和公歷日日期識別的相關算子，通過規(guī)則性實體抽取，把實體通過規(guī)則解析成具體的年月日。抽取時間實體時，讓大模型去判斷規(guī)則抽取的實體是否能夠去滿足用戶的 query。經(jīng)測試，這樣做能使準確性達到 98% 以上。大模型判斷能滿足時，用時間解析 Parser 解析成具體的時間，對于剩下 2% 的 badcase，大模型先去抽取時間的實體，再基于實體去解析成對應的時間，而不是讓大模型直接端到端地把用戶的 query 去解析成具體日期。

5. Agent 記憶緩存和命中較難

大模型每次做新題不會保證答案的穩(wěn)定，而舊題可以參考歷史答案。Agent 是產(chǎn)品里的一個機制，并不是算法的能力。所以我們通過用戶以往問詢的一些樣例，去解析正確要素，然后復用到相似的樣例上。除了歷史問詢記憶，我們還有知識庫里的記憶，通過記憶對用戶的 query 做標準化的改寫。實驗發(fā)現(xiàn)如果 query 改寫成標準化的版本大模型會理解得非常準確，實現(xiàn)標準問詢，標準出結果，從而保證穩(wěn)定性。Query 改寫同樣也遵循通用公式：最近性、相關性和重要性。

上圖是我們產(chǎn)品的架構，核心優(yōu)勢包括：

• 統(tǒng)一語義層的構建：即指標和標簽，確保數(shù)據(jù)分析準確可靠。
• 用戶可干預：用戶的每一次的干預都是對模型的一種反饋，對大模型的迭代和微調(diào)，以及產(chǎn)品邏輯和業(yè)務規(guī)則的迭代都有幫助。
• 多源異構數(shù)據(jù)鏈接：分析不僅需要結構化的數(shù)據(jù)分析，還需要知道分析之后的決策和行動，可搭配知識庫，把結構和非結構化數(shù)據(jù)串聯(lián)起來，通過企業(yè)內(nèi)部的知識文檔，在分析洞察完數(shù)據(jù)產(chǎn)生的原因后告訴業(yè)務人員下一步的行動。
• 持續(xù)反思學習：讓系統(tǒng)更懂用戶。
• 數(shù)據(jù)計算加速引擎：在 API 內(nèi)部通過工程化手段做 SQL 的底層優(yōu)化，讓查詢性能得到極大的提升。

四、企業(yè)經(jīng)營分析的展望和思考

對經(jīng)營分析 Agent 的未來發(fā)展有如下一些展望和思考：

• 大模型從能聽懂人話升級為幫人說話：我們當前對 chatbot 是被動式使用，我問你答的模式。在未來，我們希望大模型能夠主動去幫人，構思業(yè)務分析的場景，根據(jù)使用者用戶畫像，以往的提問歷史，角色部門權限，可以每天生成目標和任務，用戶點擊確認，整個 Agent 到后臺自動運行，最終跑出來用戶需要的分析報告，還能幫助用戶額外產(chǎn)出其它有洞見的分析報告和結論。
• 能和人一樣總結歸納升級為總結之后自動決策：數(shù)據(jù)分析是為了發(fā)現(xiàn)數(shù)據(jù)背后的本質(zhì)和原因，再進行下一步的行動。Agent 的本質(zhì)是連接，Agent 的方式，能夠把企業(yè)內(nèi)部的系統(tǒng)工具和產(chǎn)品連接起來，做到整體互聯(lián)互通，進行各種決策和行動。
• 能像人一樣規(guī)劃升級為像業(yè)務專家一樣規(guī)劃：Agent 初期階段，還無法達到專家的規(guī)劃能力，未來希望它能夠像專家一樣去幫助用戶解決問題。

未來通過上述三個方向的升級，能夠讓產(chǎn)品基于大模型的工具和能力更有價值。

五、問答環(huán)節(jié)

Q1：企業(yè)用到您介紹的分析產(chǎn)品之后，數(shù)據(jù)分析人員的職業(yè)定位會有什么改變？

A1：產(chǎn)品并不是替代分析人員，而是作為一個助手，幫助其完成日常大量枯燥的、沒有技術含量的報表開發(fā)工作，而分析人只需要聚焦于更復雜的工作，比如像專家一樣做更深度的洞察和分析。

Q2：醫(yī)療行業(yè)的企業(yè)使用你們的產(chǎn)品，怎么確保數(shù)據(jù)的安全性？

A2：首先該產(chǎn)品并非為醫(yī)療行業(yè)訂制，而是用于企業(yè)經(jīng)營分析。從產(chǎn)品本身來看，可私有化部署，所以數(shù)據(jù)可以不出企業(yè)，也就不存在數(shù)據(jù)出域的安全性問題。

Q3：Agent 應用開發(fā)是定制化的，還是依據(jù)幾個主要的成熟的 Agent 開發(fā)框架來開發(fā)，您更傾向于哪種方式？

A3：我傾向于第 2 種，做 Agent 開始要參考一些開源的 Agent 框架，現(xiàn)在已經(jīng)公布了十幾種 Agent 開源框架，一定會有一種是適合你當前場景的，然后基于這種框架的思路，再去做針對性的業(yè)務的嵌套和開發(fā)。我們會參考多種框架，因為每個開源框架都有各自的優(yōu)劣勢。AutoGPT 是大模型 Agent 鼻祖，但存在不穩(wěn)定的問題。單 Agent 可以參考 ReAct 的方式，多 Agent 可以參考阿里的通義千問 Agent，或者國外的一些開源框架。需要根據(jù)具體的場景去選最適合的。

Q4：在產(chǎn)品和技術上怎么去引導用戶更高質(zhì)量地提問？

A4：內(nèi)部技術層面，query 改寫讓用戶無感知是最好的，但是難度比較高。產(chǎn)品引導層面其實也包含很多技術，比如搜索聯(lián)想，提供一些標準問題供用戶參考；又比如要素的聯(lián)想，用戶問“賣了多少”，產(chǎn)品可以給出銷售額、訂單量等選擇，讓用戶去選一個。搜索聯(lián)想的方式可能效果會更好，因為給出的是一個完整的問題，而不會像要素聯(lián)想那樣打斷用戶輸入思路。

Q5：怎么能讓用戶相信返回的數(shù)據(jù)是準確的？

A5：這里包括兩層，第一層是相信大模型翻譯出來的是準確的，第二層是基于翻譯出來的取的數(shù)字結果是準確的。第一層是通過要素的反寫，讓用戶知道把他的提問翻譯成了哪些要素的組合，從而增加可信度。第二層在做指標和標簽開發(fā)的時候，從數(shù)倉到平臺里的數(shù)據(jù)核準和校驗要做準確，這是和大模型本身沒有關系的基礎工作。

Q6：Agent 現(xiàn)在是內(nèi)部自己訓練，還是外面公共的大模型。在一些解決方案上發(fā)現(xiàn)對大模型本身的能力是要有一定要求的。如果想要在一個私有環(huán)境中使用，是需要自己部署一個大模型，還是可以配其他大模型。

A6：有兩方面考慮，第一個是在部署時需要考慮企業(yè)內(nèi)部可承擔的算力成本，百億左右的模型成本相對來說比較低，但超過 500 億以上的成本相對來說就會比較高，這要看企業(yè)的選擇。根據(jù)我們的經(jīng)驗，300 億以下要靠微調(diào)，300 億尤其 500 億以上，靠 prompt 微調(diào)就可以。500 億以上通過 prompt 和工程的方式能夠避免很多錯誤的情況。但是在 500 億以下，可能有很多情況是工程手段無法避免的，這種情況下需要靠調(diào)，而部署方式要看客戶對資源的要求。

Q7：SwiftAgent 流轉框架里有 check system 和 retry system，它們都有最終的 output 分支，其執(zhí)行標準是什么？

A7：Check system 是我們內(nèi)部的一個重試機制，針對于不同的情況，比如當它發(fā)現(xiàn)找不到對應的指標，或者用指標的 API 邏輯回答的結果是錯的，或者和用戶提問的要素不匹配的時候，我們會通過 SQL 的方式直接侵入到底層模型表以下，通過 SQL 生成的方式，去檢索出來相應的結果。其中，判斷用戶的 query 和解析的要素是否一致，是由大模型來完成的。此外，還有很多工程化手段，比如 API 底層引擎里直接有代碼報錯，此時也需要重試的機制。

對于 retry system，一部分會到 Agent 重試，還有一部分會到 SQL generate。因為 Agent 部分融合了標簽和指標，而生成 SQL 是一種兜底，它是一個單獨的線路和技能，SQL 本身生成效果也有不穩(wěn)定，一般也會讓它重試，但是會設置最大重試次數(shù)。

Q8：用戶對數(shù)據(jù)的信任問題，除了用數(shù)據(jù)治理去解決一些事情之外，還有什么其他方式解決嗎？

A8：這個只能保證底層數(shù)據(jù)的準確，數(shù)據(jù)治理是必不可少的。

Q9：產(chǎn)品的優(yōu)勢之一是用戶可干預，在哪些環(huán)節(jié)是用戶比較適合介入干預的？干擾和輔助提問的臨界點應該怎么把握？

A9：其實是召回和生成的平衡。比如大模型召回的字段生成的結果，你判斷它生成的結果在你之前的候選集里分數(shù)排得并不是特別靠前，但是大模型選擇了它，那你就要反問，同時要附上分數(shù)較高那幾個，這個是要根據(jù)具體的業(yè)務場景去做一個抉擇。出現(xiàn)沖突矛盾的時候，就需要去做反問。除了反問，還有對結果的贊和踩也可視為一種用戶干預，但其實是對結果的校準。