原文鏈接：https://mp.weixin.qq.com/s/53KZsrAIGCAdF1_LZ5ORPw

大模型和算力的快速發(fā)展，促進(jìn)了很多行業(yè)的變革，即使目前AI仍然處于“自主行動(dòng)”的初級(jí)階段，即“輔助人”的階段，其巨大的潛力和演進(jìn)路徑卻是相對(duì)明確的。

讓AI評(píng)測(cè)AI：構(gòu)建智能客服的自動(dòng)化運(yùn)營(yíng)Agent體系

一、基于NLP的傳統(tǒng)機(jī)器人客服

傳統(tǒng)機(jī)器人的工作重點(diǎn)：

1. 知識(shí)庫(kù)建設(shè)： 將常見(jiàn)的客戶(hù)問(wèn)題整理成“問(wèn)題-答案”對(duì)；
2. 同義詞和規(guī)則配置： 為每個(gè)問(wèn)題配置大量可能的關(guān)鍵詞和同義句。例如，為“如何退款”配置“想退貨”、“錢(qián)怎么退”、“不要了”等；
3. 對(duì)話(huà)流程設(shè)計(jì)： 設(shè)計(jì)復(fù)雜的、樹(shù)狀的對(duì)話(huà)流程（SOP、決策樹(shù)等），例如，“用戶(hù)選擇A -> 跳轉(zhuǎn)到流程A1 -> 詢(xún)問(wèn)信息A2...”；
4. 監(jiān)控與維護(hù)： 監(jiān)控哪些關(guān)鍵詞被觸發(fā)，哪些問(wèn)題未被識(shí)別，然后不斷打補(bǔ)丁，添加新規(guī)則；

機(jī)器人的智能水平上限在設(shè)計(jì)之初就被規(guī)則庫(kù)的規(guī)模鎖死了，無(wú)法處理規(guī)則外的問(wèn)題。

二、基于RAG的智能客服

：為了提升文檔問(wèn)答的準(zhǔn)確率、降低知識(shí)的運(yùn)營(yíng)成本
RAG從“知識(shí)庫(kù)”中找出最相關(guān)的內(nèi)容，將“檢索到的信息”和“用戶(hù)問(wèn)題”打包成一個(gè)超級(jí)提示詞，它既有更加準(zhǔn)確的知識(shí)作為供給，也能經(jīng)過(guò)LLM的潤(rùn)色表達(dá)的更加自然。

• 在檢索（Retrieval）方面, 引入向量化檢索方式

  
  
  ES方式與向量方式.png

• 在增強(qiáng)（Augmentation）方面，將檢索到的信息片段和用戶(hù)問(wèn)題，精心組裝成一個(gè)LLM能理解的"提示詞"，為生成環(huán)節(jié)奠定基礎(chǔ)

  • 信息組裝：在工程側(cè)，將檢索環(huán)節(jié)得到的候選知識(shí)分片，按相關(guān)性排序，結(jié)合歷史對(duì)話(huà)內(nèi)容拼接成一個(gè)完整的"上下文背景信息"
  • 提示詞工程，這是"增強(qiáng)"環(huán)節(jié)的靈魂，通常包含以下部分：
    • 系統(tǒng)角色： 定義LLM的身份。例：“你是一個(gè)專(zhuān)業(yè)的客服助手，嚴(yán)格根據(jù)提供的背景信息回答問(wèn)題”；
    • 背景信息/指令： 明確告知LLM答案的來(lái)源和規(guī)則。例：“請(qǐng)嚴(yán)格根據(jù)以下用```標(biāo)記的背景信息來(lái)回答最終的問(wèn)題。如果背景信息中沒(méi)有答案，請(qǐng)直接說(shuō)'根據(jù)現(xiàn)有信息，我無(wú)法回答這個(gè)問(wèn)題'，不要編造信息”；
    • 背景信息內(nèi)容： 前面提到的上下文；
    • 用戶(hù)問(wèn)題： 放入原始的用戶(hù)問(wèn)題；
    • 輸出格式要求（可選）： 要求LLM以特定格式（如Markdown、帶項(xiàng)目符號(hào)的列表）輸出，或要求其引用來(lái)源。

• 在生成（Generation）方面，將組裝好的提示詞發(fā)送給大語(yǔ)言模型。

  • 理解指令： 識(shí)別自己的角色和回答規(guī)則；
  • 關(guān)聯(lián)信息： 在提供的背景信息中，定位與問(wèn)題直接相關(guān)的部分；
  • 總結(jié)和生成： 對(duì)找到的信息進(jìn)行歸納、總結(jié)和重新組織，用更自然、流暢的語(yǔ)言表達(dá)出來(lái)

RAG機(jī)器人客服主鏈路.png

三、基于AI原生的智能客服

AI原生的智能客服主鏈路.png

鏈路中使用模型的地方都切換為了LLM。因?yàn)榛５膹?qiáng)大，我們可以把更多的內(nèi)容讓LLM去推理判斷（相比之前，進(jìn)化很多），比如可以把復(fù)雜的業(yè)務(wù)邏輯，通過(guò)自然語(yǔ)言描述成“如果xxx，那么xxx”這種格式，結(jié)合上下文信息，讓LLM決策該走什么樣的邏輯分支，我們把它稱(chēng)之為“智能SOP”。智能SOP（依然存在很大的優(yōu)化空間）中需要?jiǎng)討B(tài)調(diào)用LLM以外的內(nèi)容，可以通過(guò)Function-Call的方式實(shí)現(xiàn)。

對(duì)于知識(shí)類(lèi)的問(wèn)答，RAG仍然必不可少，而且也在不斷進(jìn)化：

RAG進(jìn)化.png

四、對(duì)話(huà)效果如何評(píng)測(cè)

是運(yùn)營(yíng)人員通過(guò)指定評(píng)測(cè)集，或者從生產(chǎn)環(huán)境抽取服務(wù)記錄，線(xiàn)下進(jìn)行人工標(biāo)注看效果。如果發(fā)現(xiàn)問(wèn)題，需要單獨(dú)記錄，找技術(shù)進(jìn)行定位，是問(wèn)答鏈路中哪個(gè)環(huán)節(jié)可能出了問(wèn)題導(dǎo)致了BadCase，修復(fù)方案可能是需要運(yùn)營(yíng)介入、也可能是技術(shù)介入就夠了，修復(fù)之后再重新評(píng)測(cè)看結(jié)果，整個(gè)過(guò)程費(fèi)時(shí)、費(fèi)力。

結(jié)合知識(shí)Agent和對(duì)話(huà)中控Agent，構(gòu)建智能化的AI原生服務(wù)閉環(huán)體系

"評(píng)估-診斷-優(yōu)化"三位一體的運(yùn)營(yíng)Agent平臺(tái).png

五、評(píng)測(cè)怎么落地

• 識(shí)別出AI原生客服機(jī)器人的回答準(zhǔn)確性
• 對(duì)BadCase需要根因的歸類(lèi)
• 對(duì)BadCase自動(dòng)生成優(yōu)化建議、優(yōu)化建議具備自動(dòng)執(zhí)行的能力。

完整的對(duì)話(huà)鏈路.png

效果評(píng)測(cè)的主框架脈絡(luò)

效果評(píng)測(cè)的主框架脈絡(luò).png

• 評(píng)測(cè)集的構(gòu)建

  • 根據(jù)知識(shí)內(nèi)容自動(dòng)生成評(píng)測(cè)集
  • 文件上傳原聲評(píng)測(cè)集
  • 支持動(dòng)態(tài)根據(jù)多種組合條件，從生產(chǎn)環(huán)境直接篩選服務(wù)記錄作為評(píng)測(cè)集

• 評(píng)判的規(guī)則

  • 語(yǔ)義相關(guān)性
  • 表達(dá)質(zhì)量
  • 內(nèi)容合規(guī)性
  • 信息完整性

• 根因歸類(lèi)

  • 粗召檢測(cè)問(wèn)題
  • 精排問(wèn)題
  • 生成錯(cuò)誤問(wèn)題
  • 生成幻覺(jué)問(wèn)題

• 自動(dòng)生成優(yōu)化建議、并且自動(dòng)執(zhí)行

  • 缺少知識(shí)的根因類(lèi)別，可以結(jié)合對(duì)話(huà)上下文自動(dòng)觸發(fā)從互聯(lián)網(wǎng)檢索關(guān)聯(lián)知識(shí)
  • 粗召遺漏的場(chǎng)景、精排遺漏的場(chǎng)景，可以對(duì)識(shí)別出的關(guān)聯(lián)分片信息增加相似問(wèn)，以期再遇到類(lèi)似Query時(shí)增加被召回的概率。實(shí)際使用下來(lái)，自動(dòng)生成相似問(wèn)的場(chǎng)景更加容易落地一些。

• 為什么起到“裁判”評(píng)測(cè)的效果

  • 更大尺寸的LLM，并且針對(duì)性開(kāi)啟了思考模式
  • 輸入給到LLM的關(guān)聯(lián)內(nèi)容（對(duì)話(huà)上下文、參考知識(shí)、業(yè)務(wù)規(guī)則等）也更加全面

六、遇到了哪些難題

建設(shè)運(yùn)營(yíng)Agent進(jìn)行對(duì)話(huà)效果評(píng)測(cè)的過(guò)程是痛苦的，規(guī)則如何準(zhǔn)確生效、上下文怎么設(shè)計(jì)、怎么降低LLM的抽風(fēng)等

6.1 正向評(píng)判還是負(fù)向評(píng)判

“純正向”的評(píng)判比較寬松，可能遺漏問(wèn)題。
“純負(fù)向”的判斷會(huì)讓LLM過(guò)度關(guān)注缺陷，忽略整體的價(jià)值

正向與負(fù)向判斷.png

采用“混合策略”的方式，分層評(píng)估，既有明確的紅線(xiàn)扣分點(diǎn)，也會(huì)給LLM的發(fā)揮空間，在一定分值波動(dòng)閾值內(nèi)進(jìn)行綜合判斷，LLM的思考過(guò)程就會(huì)變?yōu)椤罢覂?yōu)點(diǎn) → 找缺點(diǎn) → 綜合權(quán)衡”，更接近人類(lèi)的全面評(píng)估。

混合策略的分值判斷.png

6.2 業(yè)務(wù)場(chǎng)景的強(qiáng)依賴(lài)

AI不懂業(yè)務(wù)怎么辦？比如用戶(hù)問(wèn)“怎么退課”，A課和B課規(guī)則不同。AI不知道用戶(hù)是哪種課，就容易瞎判。

在運(yùn)營(yíng)Agent進(jìn)行Judge服務(wù)記錄對(duì)話(huà)內(nèi)容是否為BadCase之前需要做兩件事情：

1. 識(shí)別出客戶(hù)的訴求
2. 根據(jù)客戶(hù)訴求獲取強(qiáng)關(guān)聯(lián)的業(yè)務(wù)內(nèi)容作為參考知識(shí)給LLM

6.2.1 客戶(hù)訴求

如何準(zhǔn)確的識(shí)別出客戶(hù)的訴求？

• 對(duì)當(dāng)前Query內(nèi)容進(jìn)行提取會(huì)存在準(zhǔn)確性的問(wèn)題
• 涉及到多輪對(duì)話(huà)，更需要結(jié)合歷史對(duì)話(huà)內(nèi)容一起才能提取訴求
• 業(yè)務(wù)場(chǎng)景是比較復(fù)雜的，

  某健身企業(yè)，包含多種健身品牌，每種品牌下又都有類(lèi)似名稱(chēng)的課程（比如私教課、團(tuán)課），每種課程下又有類(lèi)似的子場(chǎng)景（比如預(yù)約課程、取消課程等），這些細(xì)分的子場(chǎng)景有些描述內(nèi)容是比較接近的，會(huì)影響客戶(hù)訴求的識(shí)別。

• 客戶(hù)的問(wèn)法千奇百怪，而一個(gè)企業(yè)客戶(hù)服務(wù)的業(yè)務(wù)范圍是明確的、可枚舉的

構(gòu)建“意圖分層體系”（業(yè)務(wù)品類(lèi) -> 業(yè)務(wù)場(chǎng)景）。

• 業(yè)務(wù)品類(lèi)類(lèi)似于“業(yè)務(wù)線(xiàn)”的概念，類(lèi)似螞蟻花唄業(yè)務(wù)、借唄業(yè)務(wù)。
• 業(yè)務(wù)場(chǎng)景，屬于業(yè)務(wù)二級(jí)分類(lèi)，比如“如何開(kāi)通借唄服務(wù)”、“借唄如何還款”等

通過(guò)對(duì)服務(wù)記錄數(shù)據(jù)的分析、以及和業(yè)務(wù)同學(xué)的溝通，梳理出上述KA健身企業(yè)7個(gè)業(yè)務(wù)品類(lèi)、40多個(gè)業(yè)務(wù)場(chǎng)景信息，作為輸入內(nèi)容放入Prompt中，結(jié)合歷史對(duì)話(huà)內(nèi)容，讓LLM把Query信息和品類(lèi)/場(chǎng)景信息做映射判斷，同時(shí)兼顧了歷史訴求的延續(xù)、新訴求的產(chǎn)生等，從而識(shí)別出客戶(hù)的當(dāng)前最新訴求是什么。

案例

{
  "customerQuery": "轉(zhuǎn)讓",
  "robotAnswer": "請(qǐng)問(wèn)您是想咨詢(xún)哪種類(lèi)型的課程轉(zhuǎn)讓呢？例如私教課或其他類(lèi)型？"
},
{
  "customerQuery": "會(huì)員卡",
  "robotAnswer": "請(qǐng)問(wèn)您是想咨詢(xún)關(guān)于會(huì)員卡轉(zhuǎn)讓的具體問(wèn)題嗎？"
}

用戶(hù)提問(wèn)單純是「會(huì)員卡」三個(gè)字的話(huà)，歷史情況下非常容易識(shí)別為會(huì)員卡咨詢(xún)等意圖，產(chǎn)生誤判。經(jīng)過(guò)上述邏輯的處理后，能有效地識(shí)別用戶(hù)意圖為會(huì)員卡轉(zhuǎn)讓咨詢(xún)

{
  "customerDemand": "會(huì)員卡轉(zhuǎn)讓咨詢(xún)",
  "brand": "**健身會(huì)員卡",
  "scene": "會(huì)員卡轉(zhuǎn)讓場(chǎng)景",
  "thought": "客戶(hù)當(dāng)前問(wèn)題為'會(huì)員卡'，結(jié)合歷史對(duì)話(huà)中客戶(hù)連續(xù)提及'轉(zhuǎn)讓'和'會(huì)員卡'，且客服明確詢(xún)問(wèn)'是否咨詢(xún)會(huì)員卡轉(zhuǎn)讓問(wèn)題'，可判定客戶(hù)訴求聚焦于會(huì)員卡轉(zhuǎn)讓。根據(jù)品類(lèi)信息列表匹配規(guī)則，'會(huì)員卡'屬于xx健身的業(yè)務(wù)種類(lèi)且未提及其他品牌，品牌xxx，結(jié)合業(yè)務(wù)種類(lèi)記錄為'xxxx'。場(chǎng)景匹配【場(chǎng)景信息】列表第28項(xiàng)'會(huì)員卡轉(zhuǎn)讓場(chǎng)景'的核心詞'轉(zhuǎn)讓卡'、'會(huì)員卡轉(zhuǎn)讓'。"
}

意圖分層體系構(gòu)建

意圖分層體系構(gòu)建.png

6.2.2 參考知識(shí)

評(píng)測(cè)，需要用“懷疑”的視角看待對(duì)話(huà)鏈路中的每一個(gè)環(huán)節(jié)，比如RAG檢索到的知識(shí)是不是ok的，有沒(méi)有可能漏掉一些分片信息？

對(duì)話(huà)鏈路.png

這就和上文中的對(duì)話(huà)鏈路的梳理進(jìn)行了關(guān)聯(lián)，我們和知識(shí)Agent、對(duì)話(huà)Agent約定，將每個(gè)中間環(huán)節(jié)的輸出結(jié)果進(jìn)行持久化保存，比如知識(shí)Agent在做檢索的時(shí)候，需要把粗召的結(jié)果分片信息保存、精排的結(jié)果也需要保存，運(yùn)營(yíng)Agent會(huì)對(duì)每個(gè)階段的結(jié)果數(shù)據(jù)進(jìn)行判斷，如果發(fā)現(xiàn)有候選分片在粗召結(jié)果中未出現(xiàn)，就會(huì)把根因歸類(lèi)視為“粗召遺漏”；或者目標(biāo)分片在粗召的結(jié)果數(shù)據(jù)中存在，但是在精排的結(jié)果分片中卻消失了，就會(huì)把根因歸類(lèi)視為“精排遺漏”。

根據(jù)上面這個(gè)邏輯，現(xiàn)在就有了一個(gè)首要問(wèn)題，如何知道和Query關(guān)聯(lián)的所有的目標(biāo)知識(shí)分片？

把和當(dāng)前機(jī)器人綁定的所有知識(shí)文檔作為候選知識(shí)，用Query、歷史對(duì)話(huà)、提取出來(lái)的業(yè)務(wù)品類(lèi)/業(yè)務(wù)場(chǎng)景/客戶(hù)訴求，綜合作為輸入信息，讓LLM校驗(yàn)候選知識(shí)中哪些分片內(nèi)容是和Query強(qiáng)關(guān)聯(lián)的目標(biāo)分片知識(shí)。

知識(shí)召回.png

這種方式，對(duì)于機(jī)器人綁定的資料比較少的情況下，是可以適用的，會(huì)對(duì)機(jī)器人綁定資料的每一個(gè)分片都做檢查，找出目標(biāo)分片。但是當(dāng)機(jī)器人綁定的資料多的時(shí)候就不適合了，因?yàn)樘耍?/p>

正常的RAG問(wèn)答鏈路中，也會(huì)根據(jù)設(shè)定的閾值從知識(shí)庫(kù)中召回TopN的知識(shí)內(nèi)容，我們?cè)谶@個(gè)基礎(chǔ)上，把閾值適當(dāng)降低，擴(kuò)大TopN的數(shù)量，盡可能的使得和Query相關(guān)的內(nèi)容都被獲取到。

6.2.3 豁免

由于一些業(yè)務(wù)場(chǎng)景的特殊性，客戶(hù)的Query會(huì)被規(guī)則命中后走特殊的邏輯，比如觸發(fā)機(jī)器人轉(zhuǎn)人工、或者機(jī)器人吐出固定的話(huà)術(shù)等，即使這些機(jī)器人回答的內(nèi)容并不能解決客戶(hù)的訴求，但是在這種特殊場(chǎng)景下，它的回答內(nèi)容是符合業(yè)務(wù)預(yù)期的，就不能被判為BadCase，應(yīng)該被豁免。

最初這個(gè)豁免的判斷，是和BadCase的發(fā)現(xiàn)的邏輯放在一個(gè)Prompt中灌輸給LLM，符合豁免規(guī)則的對(duì)話(huà)內(nèi)容不被標(biāo)記為BadCase。但是實(shí)操下來(lái)，發(fā)現(xiàn)識(shí)別會(huì)有偏差，為了避免“誤殺”，我們把豁免判斷抽成了獨(dú)立的邏輯，先進(jìn)行豁免的檢測(cè)，再進(jìn)行BadCase的識(shí)別。

6.3 LLM的對(duì)抗

“隨機(jī)性”導(dǎo)致的問(wèn)題

• 使用同一個(gè)LLM（業(yè)界頭部的LLM）、相同的Prompt，多次調(diào)用，LLM輸出的結(jié)果并不完全一樣；
• 相同的Prompt，不同的LLM（業(yè)界頭部的LLM），輸出的結(jié)果也不完全一樣，結(jié)果甚至相反；

6.3.1 第一個(gè)問(wèn)題

當(dāng)你輸入一個(gè)Prompt后，模型會(huì)執(zhí)行如下幾個(gè)步驟：

• step1：處理輸入內(nèi)容；
• step2：計(jì)算出所有可能的下一個(gè)token的概率分布；
• step3：從這些分布中選出一個(gè)token，作為輸出；
• step4：把這個(gè)新生成的token追加到原有上下文中，再重復(fù)上述過(guò)程，生成下一個(gè)token，如此循環(huán)；

關(guān)鍵在于第2步和第3步。為了增加隨機(jī)性，LLM使用了兩個(gè)重要的參數(shù)：Temperature 和 Top-P
Temperature（溫度）

• 溫度是一個(gè)在Softmax計(jì)算之前應(yīng)用的參數(shù)，它直接重塑概率分布概率 = Softmax(原始分?jǐn)?shù) / Temperature)
• 低溫度（如 0.1）： 除以一個(gè)很小的數(shù)，會(huì)放大高分?jǐn)?shù)和低分?jǐn)?shù)之間的差距；
  效果：讓高概率的詞（如“公園”）概率更高，低概率的詞（如“飛翔”）概率更低。模型輸出變得更確定、保守；
• 高溫度（如 1.5）： 除以一個(gè)大于1的數(shù)，會(huì)縮小分?jǐn)?shù)之間的差距；
  效果：讓概率分布變得更平緩。低概率的詞（如“吃飯”、“飛翔”）機(jī)會(huì)變大了；輸出變得更多樣、更有創(chuàng)意，但也更不穩(wěn)定。

Top-P
Top-P是在Softmax計(jì)算之后應(yīng)用的篩選機(jī)制，它將候選詞按概率從高到低排序，然后只保留一個(gè)最小集合，使得這個(gè)集合中所有詞的概率之和剛剛超過(guò)Top-P中的P（例如 p=0.9）。
過(guò)程如下：

• 排序：公園(65%)，散步(24%)，吃飯(9%)，飆車(chē)(2%)……；
• 計(jì)算累積概率：公園(65%)，公園+散步=89%，公園+散步+吃飯=98%（已經(jīng) > 90%）；
• 篩選：只保留 {公園， 散步， 吃飯}。概率極低的“飆車(chē)”被剔除；
• 重新歸一化：將這三個(gè)詞的概率重新縮放，使其和為100%（例如：公園 ~66%，散步 ~25%，吃飯 ~9%）；
• 最后，從這個(gè)新的、篩選后的集合中進(jìn)行隨機(jī)采樣。

由此可見(jiàn)，只要 Temperature > 0 或 Top-P < 1.0，模型在每一步都面臨隨機(jī)的結(jié)果，而一次完整的結(jié)果生成又是順序的過(guò)程，每一步的隨機(jī)選擇都會(huì)影響后續(xù)步驟。

6.3.2 第二個(gè)問(wèn)題

為什么相同的Prompt，不同的LLM輸出結(jié)果卻可能不同（即使都是國(guó)內(nèi)頂流的LLM）？這主要是分詞和訓(xùn)練參數(shù)的差異導(dǎo)致。

• 分詞差異：不同模型的分詞器（Tokenizer）不同
• 訓(xùn)練參數(shù)差異：不同的LLM其訓(xùn)練的過(guò)程和訓(xùn)練的參考數(shù)據(jù)都不盡相同
• LLM的指令微調(diào)和RLHF也千差萬(wàn)別

6.3.3 怎么解決

對(duì)于第一個(gè)問(wèn)題，在調(diào)用LLM的時(shí)候，可以通過(guò)嘗試調(diào)整Tempture和Top-P的值來(lái)解決（阿里云百煉的SDK支持動(dòng)態(tài)設(shè)置），雖然不能完全避免它隨機(jī)性導(dǎo)致的問(wèn)題，但是可以降低發(fā)散的概率。

對(duì)于第二個(gè)問(wèn)題，我們采用了多個(gè)LLM對(duì)抗的方式來(lái)解決，即BadCase在識(shí)別的時(shí)候，通過(guò)兩個(gè)、三個(gè)LLM執(zhí)行相同的Prompt，采用統(tǒng)計(jì)學(xué)的方式得到最終結(jié)果（需要對(duì)LLM的執(zhí)行耗時(shí)不是非常敏感）。

示例

{
  "qwen3-235b-a22b" : "{\"score\":30,\"thought\":\"1. **內(nèi)容合規(guī)性**：客服回答未直接處理客戶(hù)因店面裝修申請(qǐng)停卡的訴求，且未正確引用參考知識(shí)中關(guān)于特殊情況（如裝修）需聯(lián)系人工或店長(zhǎng)的規(guī)則，違反了特殊場(chǎng)景需轉(zhuǎn)人工的合規(guī)要求，扣20分。\\\\n2. **語(yǔ)義相關(guān)性**：客戶(hù)明確訴求為停卡一周，但客服未提供有效解決方案（如指引停卡路徑或確認(rèn)資格），僅重復(fù)引導(dǎo)選擇訂單或轉(zhuǎn)人工，未解決實(shí)際問(wèn)題，扣30分。\\\\n3. **表達(dá)質(zhì)量**：語(yǔ)言結(jié)構(gòu)合理，但未明確說(shuō)明停卡規(guī)則，導(dǎo)致信息模糊，扣5分。\\\\n4. **信息完整性**：未提及?？l件（如需備注原因、審核時(shí)間等）或操作路徑（如鏈接申請(qǐng)），核心信息缺失，扣15分。\\\\n綜合評(píng)分：100-20-30-5-15=30\"}",
  "deepseek-r1" : "{\"score\":60,\"thought\":\"客戶(hù)訴求識(shí)別：客戶(hù)問(wèn)題'店面還在裝修，申請(qǐng)?？ㄒ恢?為肯定句式，但含業(yè)務(wù)動(dòng)詞'申請(qǐng)停卡'，根據(jù)規(guī)則視為明確訴求（停卡申請(qǐng)）。參考知識(shí)分析：分片'我可以停卡一周嗎？'直接匹配客戶(hù)問(wèn)題，chunkContent明確'不支持自定義?？〞r(shí)長(zhǎng)或指定到某一時(shí)間'，僅支持無(wú)理由?？?0天或特殊情況需證明?？头卮鹱尶蛻?hù)'返回訂單列表選擇訂單'或'轉(zhuǎn)人工'，未引用該核心知識(shí)，且與參考知識(shí)中自助停卡路徑（如分片1的鏈接）矛盾，內(nèi)容合規(guī)性扣20分。語(yǔ)義相關(guān)性：參考知識(shí)有完全匹配分片，但客服回答缺失核心信息（不支持自定義時(shí)長(zhǎng)），扣10分；歷史對(duì)話(huà)顯示客戶(hù)重復(fù)訴求（多次'轉(zhuǎn)人工'），但回答包含轉(zhuǎn)人工語(yǔ)義，不額外扣分，得40分。表達(dá)質(zhì)量：語(yǔ)言流暢，無(wú)語(yǔ)法錯(cuò)誤或質(zhì)疑語(yǔ)句，得10分。信息完整性：未提供?？ㄒ?guī)則（如時(shí)長(zhǎng)限制）或自助路徑，核心信息缺失，扣10分，得10分?？偡郑?（合規(guī)性）+40（相關(guān)性）+10（表達(dá)）+10（完整性）=60。\"}"
}

兩個(gè)LLM雖然給的判斷分值不同的，但是都遠(yuǎn)小于我們?cè)O(shè)定的BadCase閾值，最終結(jié)果為45分（求的均值），準(zhǔn)確識(shí)別為BadCase，符合預(yù)期。

6.4 深度思考模式

開(kāi)啟LLM的深度思考模式后（比如百煉可以通過(guò)sdk的enableThinking參數(shù)控制），與普通的“鏈?zhǔn)剿伎肌毕啾?，“深度思考”可以理解為啟?dòng)了一個(gè)高級(jí)的、內(nèi)置的“系統(tǒng)Prompt”，這個(gè)Prompt專(zhuān)門(mén)指示模型做如下事情：

• 問(wèn)題解析與規(guī)劃：不要急于回答，先徹底理解問(wèn)題的核心、邊界條件等；
• 多路徑推理：構(gòu)思多種解決方案或思路，并比較它們的優(yōu)劣點(diǎn)差異；
• 逐步執(zhí)行與驗(yàn)證：嚴(yán)格的、一步一步的執(zhí)行計(jì)劃，每一步都進(jìn)行自我檢查，確保邏輯和事實(shí)的正確性；
• 自我批判與修正：主動(dòng)尋找自己推理中的漏洞、假設(shè)或可能錯(cuò)誤的地方，并嘗試修正它們；
• 最終整合：在確認(rèn)推理過(guò)程沒(méi)問(wèn)題后，給出一個(gè)精煉、準(zhǔn)確的最終答案；

在實(shí)際使用中，既在Prompt中詳細(xì)描述了讓LLM執(zhí)行操作的步驟，同時(shí)也根據(jù)場(chǎng)景復(fù)雜度開(kāi)啟了LLM的“深度思考模式”，因?yàn)椤吧疃人伎寄Ｊ健辈粌H僅是執(zhí)行我們給的步驟，它包含了更高層次的推理執(zhí)行：

• 理解“為什么”要這么做：即使你列出了步驟，模型也可能不理解每一步的意圖，開(kāi)啟“深度思考”會(huì)迫使它去理解其背后的邏輯，從而在執(zhí)行時(shí)更不容易出錯(cuò)（注意，也是無(wú)法完全避免）；
• 自我驗(yàn)證：我們給的步驟可能本身就有漏洞，或者模型在執(zhí)行某一步時(shí)可能出錯(cuò)，“深度思考”模式下的LLM自我批判機(jī)制能主動(dòng)發(fā)現(xiàn)并糾正這些錯(cuò)誤；
• 處理模糊和意外情況：如果你的步驟描述不夠精確，或者問(wèn)題中出現(xiàn)意外情況（例如數(shù)據(jù)單位不統(tǒng)一），開(kāi)啟深度思考的模式會(huì)更有可能發(fā)現(xiàn)并處理這些歧義，而關(guān)閉模式則可能直接導(dǎo)致錯(cuò)誤（這一點(diǎn)很重要）

需要注意的是

• LLM的響應(yīng)時(shí)間也會(huì)顯著變長(zhǎng)，需要結(jié)合自己的場(chǎng)景看能否接受
• “深度思考模式”也不是一開(kāi)啟就能帶來(lái)明顯的效果，對(duì)于事實(shí)查詢(xún)、摘要、簡(jiǎn)單分類(lèi)、格式轉(zhuǎn)換，“深度思考”模式是可以關(guān)閉的
• 對(duì)于需要LLM進(jìn)行復(fù)雜推理分析、需要得到高可靠性的輸出結(jié)果時(shí)，“深度思考模式”的開(kāi)啟通常會(huì)帶來(lái)不錯(cuò)的效果。

6.5 上下文工程

通過(guò)上面的一系列處理，有了讓LLM執(zhí)行的規(guī)則、操作步驟、參考數(shù)據(jù)，還有了運(yùn)行態(tài)的動(dòng)態(tài)參數(shù)調(diào)整（Tempture等），LLM理論上可以按照我們的期望進(jìn)行推理、輸出結(jié)果了，實(shí)則不然，還有很多事情需要做，這就是上下文工程（Context Engineering），而且需要持續(xù)去做。

之前有個(gè)概念叫“Prompt Enineering”，我理解其實(shí)屬于現(xiàn)在這個(gè)“Context Engineering”概念的子集，前者更關(guān)注如何與LLM溝通，后者在此基礎(chǔ)上，更關(guān)注提供合適的、有效的信息給LLM。這個(gè)概念之所以大受關(guān)注，本質(zhì)上在于給到LLM的上下文內(nèi)容，太長(zhǎng)或太短都會(huì)出問(wèn)題。

在實(shí)際使用中發(fā)現(xiàn)，很多LLM號(hào)稱(chēng)窗口可以支持幾十萬(wàn)、上百萬(wàn)的Token量級(jí)，但實(shí)際也僅是能“支持”而已，“效果”會(huì)得不到保證。

案例
因?yàn)橐峁┖芏鄥⒖贾R(shí)（和Query相關(guān)的文檔分片內(nèi)容、智能SOP內(nèi)容、FAQ內(nèi)容等），讓LLM進(jìn)行推理判斷，而分片的內(nèi)容本身包含很多的文字，加上其他的內(nèi)容（規(guī)則、步驟、歷史對(duì)話(huà)、Few-Shot等），這些累加起來(lái)每次需要大幾萬(wàn)的Token，LLM在思考的時(shí)候就會(huì)時(shí)常出現(xiàn)推理錯(cuò)誤的情況（即使開(kāi)啟了上文描述的“深度思考模式”也不可避免）

{
  "chunkContent": "xxxxxxxxxxxxxxxxxxxxxxxxxxx，上百個(gè)字符)",
  "chunkId": "123456789034576961536",
  "chunkRelatedQuestion": [
    "aaaaaaaaaaaaa，幾十個(gè)字符"
  ],
  "chunkTitle": "aaaaaa"
}
……
……
{
  "chunkContent": "yyyyyyyyyyyyyyyyyy，上百個(gè)字符)",
  "chunkId": "123456789034576961578",
  "chunkRelatedQuestion": [
    "bbbbbbbbbbbb，幾十個(gè)字符"
  ],
  "chunkTitle": "ccccccc"
}

LLM會(huì)把chunkId為“123456789034576961536”的數(shù)據(jù)，誤認(rèn)為是“1920679034576961578”，出現(xiàn)張冠李戴的問(wèn)題

6.5.1 為什么會(huì)這樣

LLM的“記憶力”完全依賴(lài)于工作記憶（Working Memory），也就是通常說(shuō)的“上下文窗口”?？梢园汛竽Ｐ拖胂蟪梢粋€(gè)擁有海量長(zhǎng)期記憶（從訓(xùn)練數(shù)據(jù)中學(xué)到的知識(shí)）但只有極短的工作記憶（上下文窗口）的機(jī)器人，它的思考過(guò)程完全依賴(lài)于當(dāng)前上下文窗口中的信息，一旦超出窗口，它就“看不見(jiàn)”了，而即使是窗口內(nèi)的信息，處理機(jī)制也因?yàn)榈讓蛹軜?gòu)的注意力機(jī)制而存在局限性

• 注意力權(quán)重稀釋
• 緩存局限
• 位置編碼局限

上下文失效的四個(gè)場(chǎng)景

• 上下文沖突場(chǎng)景
  即上下文中包含了相互矛盾的信息或指令，LLM輸出混亂或偏向某一方。
  • 近因效應(yīng)與首因效應(yīng)：
  • 注意力競(jìng)爭(zhēng)
    當(dāng)兩條沖突（或者不同維度）指令A(yù)和B分別位于上下文的不同位置時(shí)，模型會(huì)陷入“注意力內(nèi)戰(zhàn)”。
  • LLM沒(méi)有一個(gè)內(nèi)部的“邏輯仲裁器”
• 上下文混淆場(chǎng)景
  即LLM混淆了不同實(shí)體、概念或話(huà)題的來(lái)源。例如，將用戶(hù)A說(shuō)過(guò)的話(huà)安在用戶(hù)B身上。比如上文中我們遇到的chunkId內(nèi)容混淆問(wèn)題就屬于該場(chǎng)景。
  • 注意力泛化
  • 位置編碼模糊
  • 缺乏實(shí)體追蹤
• 上下文干擾場(chǎng)景
  即無(wú)關(guān)緊要的背景信息或之前的失敗案例影響了LLM當(dāng)前的表現(xiàn)。
  • 注意力稀釋
  • 激活值的傳播
  • 指令遵循的脆弱性
• 上下文丟失
  即LLM忘記了上下文窗口開(kāi)頭部分的內(nèi)容。
  • 緩存的先進(jìn)先出
  • 注意力權(quán)重衰減

6.5.2 怎么解決

整個(gè)“上下文工程”的核心，就是給LLM在合適的場(chǎng)景、提供的合適的內(nèi)容

• 邏輯的分拆
  在設(shè)計(jì)之初，我們高估了LLM的能力，把大量復(fù)雜的邏輯寫(xiě)在一個(gè)Prompt中，讓LLM去分析。比如在做BadCase根因歸類(lèi)的時(shí)候，我們把所有的根因歸類(lèi)及其規(guī)則描述都放在了一個(gè)Prompt中，結(jié)合Prompt中輸入的歷史對(duì)話(huà)等上下文，讓LLM判斷當(dāng)前的BadCase屬于哪種根因，這個(gè)模式其實(shí)類(lèi)似于Function-Call。

實(shí)際運(yùn)行發(fā)現(xiàn)會(huì)有誤判根因的情況，我們根據(jù)前文的分析做了邏輯的拆分，把每一種根因歸類(lèi)都單獨(dú)拆出來(lái)，由一次大模型調(diào)用，改為多次調(diào)用，降低每次給LLM任務(wù)的復(fù)雜度，拆分之后的LLM識(shí)別效果要比混在一起好很多。

• 內(nèi)容精簡(jiǎn)

  • 明確告訴LLM需要“請(qǐng)一步一步進(jìn)行分析”等類(lèi)似的語(yǔ)句，是十分必要的；
  • 根據(jù)上文LLM注意力機(jī)制的分析，降低Prompt的長(zhǎng)度（目前5w以?xún)?nèi)，該值不固定，LLM也在發(fā)展ing）；
  • 將重點(diǎn)的規(guī)則描述放到了Prompt的頭部。比如我們將“內(nèi)容合規(guī)性”的判斷放到了BadCase識(shí)別規(guī)則中靠前的位置，降低該規(guī)則放到后面時(shí)被LLM漏掉的概率，因?yàn)椤昂弦?guī)”是底線(xiàn)；
  • Prompt中只包含必要的信息，尤其給LLM的參考知識(shí)內(nèi)容比較多的時(shí)候，減少冗余信息，就是減少對(duì)LLM的干擾。比如文檔分片包含了很多屬性，分片名稱(chēng)、相似問(wèn)、分片ID、標(biāo)簽、創(chuàng)建時(shí)間、修改時(shí)間、創(chuàng)建人、修改人、狀態(tài)、來(lái)源等等，我們只把最重要、最需要的ID、名稱(chēng)、內(nèi)容、相似問(wèn)信息給到LLM，其他冗余信息全部丟棄。
  • 壓縮數(shù)據(jù)。一些id、變量名等信息等需要傳遞給LLM，但是其原始格式受上游系統(tǒng)的設(shè)計(jì)原因，可能很長(zhǎng)（例123456789066515357696），這些長(zhǎng)ID所占用的Token就會(huì)很多，我們?cè)诮M裝Prompt內(nèi)容之前，先對(duì)這些數(shù)據(jù)做了一把映射，比如“1123456789515357696”映射為“1”，“123456789515357697”映射為“2”，映射的時(shí)候保證唯一性，這樣也會(huì)大大減少Prompt的長(zhǎng)度。

• 強(qiáng)制性的約束
  期望LLM執(zhí)行完后吐出固定的格式，就需要明確出來(lái)

# 輸出規(guī)范（請(qǐng)嚴(yán)格按照標(biāo)準(zhǔn)的json格式輸出!） 請(qǐng)嚴(yán)格遵循：
## 直接輸出純凈JSON對(duì)象，禁止包含```json等代碼塊標(biāo)識(shí)符
## 使用標(biāo)準(zhǔn)JSON格式：
    ### 取消所有換行符，保持單行結(jié)構(gòu)
    ### 必須使用雙引號(hào)
    ### 結(jié)尾不要帶多余符號(hào)
## 錯(cuò)誤示例： x ```json\n{\n...}\n``` （含代碼塊標(biāo)識(shí)） x {'tasks': [...]} （單引號(hào)非法）
## 輸出必須為正確可解析的json格式(嚴(yán)禁多余、缺少和錯(cuò)誤的{}和`符號(hào)和多余的json字母)

# 禁止行為
    × 使用非工具庫(kù)中的工具
    × 情感化表達(dá)或主觀(guān)猜測(cè)
    × 非標(biāo)準(zhǔn)JSON格式的輸出

• Few-Shot
  在Prompt中添加適當(dāng)?shù)腇ew-Shot，可以有效引導(dǎo)大模型參考我們給出的示例、思考步驟進(jìn)行推理，對(duì)于提升整體的推理準(zhǔn)確性效果是有很大幫助的。

6.6 并發(fā)和限流

對(duì)于QPM的限流，我們只有控制線(xiàn)程調(diào)用的并發(fā)數(shù)。同時(shí)我們觀(guān)察到，當(dāng)并發(fā)調(diào)用大的時(shí)候，即使還沒(méi)達(dá)到限流的閾值，也會(huì)影響并發(fā)調(diào)用LLM的響應(yīng)速度，甚至幾十秒才返回結(jié)果，雖然可以改為L(zhǎng)LM流式的輸出，但是對(duì)我們的場(chǎng)景而言，是需要獲取到完整的結(jié)果才能知曉對(duì)錯(cuò)。

對(duì)于TPM的限流，不僅是輸入的Token會(huì)有影響，如果開(kāi)啟了思考模式，輸出的時(shí)候思考過(guò)程數(shù)據(jù)的輸出，也會(huì)占用TPM的閾值，輸出Token量可以通過(guò)max_tokens的參數(shù)來(lái)進(jìn)行限制。

6.7 中斷及恢復(fù)

運(yùn)營(yíng)Agent執(zhí)行的效果評(píng)測(cè)的任務(wù)，是需要長(zhǎng)時(shí)間運(yùn)行的，每一個(gè)任務(wù)都包含了很多服務(wù)記錄的檢測(cè)，每一條服務(wù)記錄又包含多個(gè)階段的邏輯處理。

如果遇到服務(wù)重啟或者其他原因，運(yùn)行中的任務(wù)就會(huì)被中斷。這種異常的中斷，會(huì)影響使用體驗(yàn)，因?yàn)槭情L(zhǎng)時(shí)間運(yùn)行的任務(wù)，當(dāng)用戶(hù)察覺(jué)到異常時(shí)已經(jīng)滯后了，重新開(kāi)始運(yùn)行又要耗費(fèi)大量時(shí)間，更不要說(shuō)LLM的重復(fù)調(diào)用（Token的浪費(fèi)）。

中斷與恢復(fù).png

核心思路就是每個(gè)階段運(yùn)行的時(shí)候，該階段中每條服務(wù)記錄在做邏輯處理時(shí)都會(huì)上報(bào)心跳，更新該對(duì)應(yīng)任務(wù)的最新?tīng)顟B(tài)，定時(shí)任務(wù)會(huì)輪詢(xún)當(dāng)前超期的任務(wù)，將未開(kāi)始、失敗的服務(wù)記錄進(jìn)行重新該階段邏輯的執(zhí)行。

七、效果

一些指標(biāo)性的結(jié)果在前面第4小節(jié)中已經(jīng)做了概要的描述（BadCase發(fā)現(xiàn)的準(zhǔn)確率85%+、根因歸類(lèi)和優(yōu)化建議生成的準(zhǔn)確率80%+等）。

找出BadCase的根因只是第一步，更進(jìn)一步的事情是如何解決？

• 有些根因是需要運(yùn)營(yíng)協(xié)作才能解決，比如轉(zhuǎn)人工策略的優(yōu)化等。

• 有些根因需要技術(shù)協(xié)作才能解決，比如生成內(nèi)容的prompt優(yōu)化等。

• 還有一些場(chǎng)景，運(yùn)營(yíng)Agent可以直接給出優(yōu)化建議：

  • 如“粗召遺漏問(wèn)題根因”、“精排遺漏問(wèn)題根因”等，這些根因我們可以理解為和Query相關(guān)的內(nèi)容確實(shí)已經(jīng)存在于知識(shí)庫(kù)中了，但是召回的時(shí)候因?yàn)橄嗨贫鹊仍驅(qū)е略谧詈蟮沫h(huán)節(jié)沒(méi)有被用上，我們給出的優(yōu)化建議一般是給強(qiáng)關(guān)聯(lián)的候選分片增加“相似問(wèn)”，可以自動(dòng)入庫(kù)生效，也可以運(yùn)營(yíng)審核之后入庫(kù)生效。
  • 又例如“缺少知識(shí)”等根因，運(yùn)營(yíng)Agent會(huì)根據(jù)當(dāng)前服務(wù)記錄的上下文和客戶(hù)意圖，自動(dòng)從互聯(lián)網(wǎng)檢索相關(guān)知識(shí)，并且對(duì)檢索到的知識(shí)內(nèi)容進(jìn)行二次校驗(yàn)，將高度匹配的內(nèi)容抽取成知識(shí)自動(dòng)入庫(kù)，或者運(yùn)營(yíng)審核之后入庫(kù)（但是客服場(chǎng)景，從互聯(lián)網(wǎng)抓取到高匹配內(nèi)容的概率還是比較小，絕大部分情況都是運(yùn)營(yíng)Agent把意圖和業(yè)務(wù)場(chǎng)景提供出來(lái)，讓運(yùn)營(yíng)同學(xué)手動(dòng)補(bǔ)充相關(guān)知識(shí)）。

八、還能做什么

如果將關(guān)注點(diǎn)從BadCase的粒度放大到整個(gè)服務(wù)鏈路，AI還能做什么？

從服務(wù)爬坡階段（非初始化冷啟動(dòng)）的提效（滿(mǎn)意度、服務(wù)成本等）角度來(lái)看，一般期望通過(guò)機(jī)器人承擔(dān)更多的客戶(hù)服務(wù)，減少人工服務(wù)，只有機(jī)器人服務(wù)不了的，才通過(guò)轉(zhuǎn)人工服務(wù)來(lái)兜底承接。量化這個(gè)“期望的效果”一般有兩個(gè)指標(biāo)，機(jī)器人回答準(zhǔn)確率、機(jī)器人解決率。

機(jī)器人回答準(zhǔn)確率
準(zhǔn)確，一般指機(jī)器人的回答內(nèi)容是否符合預(yù)期；
機(jī)器人回答解決率
解決，一般指機(jī)器人回答的內(nèi)容，解決了客戶(hù)的咨詢(xún)問(wèn)題；
但是準(zhǔn)確率其實(shí)并不等于解決率，即使機(jī)器人按照運(yùn)營(yíng)（業(yè)務(wù)）的要求吐出了符合預(yù)期的回答內(nèi)容，但是并不一定能解決客戶(hù)的問(wèn)題，客戶(hù)還是要轉(zhuǎn)人工；而機(jī)器人即使沒(méi)有吐出預(yù)期的答案，比如用詞不是很恰當(dāng)、引用的參考知識(shí)不全等，但是客戶(hù)覺(jué)得ok，能解決他的問(wèn)題；更有甚者，客戶(hù)因?yàn)閭€(gè)人心智原因，一接通就轉(zhuǎn)人工，不給機(jī)器人回答的機(jī)會(huì)。

一通轉(zhuǎn)人工的服務(wù)（轉(zhuǎn)人工，就視為機(jī)器人服務(wù)未解決客戶(hù)問(wèn)題）具體是哪方面原因?qū)е碌?？我們利用AI建設(shè)了服務(wù)分析的能力，幫助運(yùn)營(yíng)同學(xué)可以從三個(gè)方面來(lái)分析其原因：

轉(zhuǎn)服務(wù)的原因.png

• 服務(wù)策略的配置導(dǎo)致觸發(fā)轉(zhuǎn)人工
  運(yùn)營(yíng)人員可以配置攔截策略，命中策略的客戶(hù)咨詢(xún)內(nèi)容，會(huì)中斷機(jī)器人服務(wù)，觸發(fā)轉(zhuǎn)人工請(qǐng)求。如果一段時(shí)間內(nèi)，忽然有大量的轉(zhuǎn)人工請(qǐng)求出現(xiàn)，也可能是因?yàn)槟硞€(gè)策略異常變動(dòng)導(dǎo)致，運(yùn)營(yíng)Agent也可以發(fā)揮能力，做到自動(dòng)分析識(shí)別。
• 客戶(hù)心智問(wèn)題
  用戶(hù)心智導(dǎo)致的轉(zhuǎn)人工，比如客戶(hù)不說(shuō)話(huà)，或者只表達(dá)“轉(zhuǎn)人工”等內(nèi)容，屬于心智問(wèn)題。這種場(chǎng)景機(jī)器人服務(wù)階段很難做功，它間接決定了“解決率”的上限。

不過(guò)，仍然可以根據(jù)“是否復(fù)訪(fǎng)”拆解出有多少是之前沒(méi)有服務(wù)好、導(dǎo)致本次服務(wù)客戶(hù)一接通就想轉(zhuǎn)人工。

另外可以結(jié)合用戶(hù)的個(gè)人最近的訂單記錄、咨詢(xún)記錄，以及當(dāng)前整體Top的問(wèn)題，把“猜問(wèn)”進(jìn)一步個(gè)性化，理論上也可以起到正向的效果。

• 機(jī)器人的回答內(nèi)容不能解決客戶(hù)問(wèn)題

機(jī)器人按照預(yù)期提出了回答內(nèi)容，但是客戶(hù)仍然觸發(fā)了轉(zhuǎn)人工，運(yùn)營(yíng)Agent需要深度分析這種場(chǎng)景。

它可能是機(jī)器人問(wèn)答鏈路的問(wèn)題導(dǎo)致，結(jié)合前文大篇幅描述的對(duì)話(huà)效果評(píng)測(cè)內(nèi)容；也可能是機(jī)器人覆蓋范圍受限制導(dǎo)致，需要利用LLM，結(jié)合機(jī)器人服務(wù)對(duì)話(huà)內(nèi)容和人工服務(wù)對(duì)話(huà)內(nèi)容，分析出機(jī)器人給的方案和人工服務(wù)階段給的方案的差異性，根據(jù)進(jìn)一步下鉆的分析調(diào)整機(jī)器人所能服務(wù)的覆蓋業(yè)務(wù)、知識(shí)內(nèi)容等。
也可能是業(yè)務(wù)本身的異動(dòng)，如大促活動(dòng)等。

人工處理與機(jī)器處理的對(duì)比.png