觀察：大模型在客服領域的應用趨勢

首先從趨勢上來講,，今年其實大家會更關注落地的效果，更關注投入的產(chǎn)出比,。在交流的過程中,，大家提到的模型相關的內(nèi)容會變少，例如參數(shù)等,，更關心的是模型的效果,、價格、性能,。我們從趨勢中發(fā)現(xiàn)4個大家共性關注的重點,。

1.圍繞數(shù)據(jù)

如果更看重落地的效率，落地的路徑越短見效越快,，那么在質(zhì)檢和VOC這種數(shù)據(jù)集中的場景里是最適合的,，本質(zhì)上一不需要交互,，二和其他的業(yè)務系統(tǒng)的交互集成也會比較少。其次,，它本身富含的數(shù)據(jù)價值較多,，對有價值的文本信息里的數(shù)據(jù)資產(chǎn)的挖掘是很重要的，所以我們觀察到很多企業(yè)在做大模型客服應用的時候,，會把第一批的試點場景選做質(zhì)檢和VOC,。

2.圍繞營收

因為大模型比傳統(tǒng)的客服能力有顯著提升，包括語義的提取,、理解上下文,、把握對話的能力，那么如何利用好這些增值的能力去產(chǎn)生新的業(yè)務價值也是大家想了解的議題,。

3.圍繞交互

大模型在客服的應用中是一個強交互的過程,。整體的交互體驗會直接影響到最終的滿意度和落地成效。在這個主題之下,，其實企業(yè)今天非常關注兩個和技術相關的點,，第一個就是在很好地理解上下文的情況下，看能不能有一個很好的延遲響應去解決用戶體驗的問題,。第二個就是回答出來的問題是不是足夠準確,，具備的通用知識的范圍是不是足夠廣。

4.圍繞工具

因為客服的場景涉及的子場景是很多的,，每一個場景對本身模型能力的要求是不同的,，在落地過程中可能需要的配套模型的落地工具也有一些不同。

01

圍繞數(shù)據(jù)：VOC和質(zhì)檢提供更多業(yè)務洞察

在大量的存量對話記錄里,，其實有非常多的價值點,，不論是還原一個完整的用戶服務鏈路，還是去構建一個完整的用戶畫像,，都能夠用來提升服務質(zhì)量,，指明業(yè)務發(fā)展的方向。我們也一直在嘗試,，從最初的關鍵詞到之后的可能基于政策的規(guī)則,，再到后來的小模型，但始終難以像人一樣去理解一個復雜的規(guī)則,。

那么在復雜場景下要做質(zhì)檢，其實最原始的還是要人工去做這些工作,，需要設定角色,、質(zhì)檢項目以及項目之下不同的條件和條件之間的關聯(lián)。在這種模式下,，人工的投入非常大,，而且維護成本高,，受限于模型能力，它的投入產(chǎn)出比也非常低,。

但今天有了大模型之后,，我們可以把這套質(zhì)檢的邏輯以自然語言的形式放到提示詞里，讓大模型去直接執(zhí)行這個任務,，在這個場景之下,，其實就對模型提出了第一個要求：模型是否有足夠強的綜合基礎能力去理解輸入進去的這些規(guī)則。

其次,，對坐席的這種服務質(zhì)量的監(jiān)督有很多前置條件,，必須是在滿足某特定情況下。這些復雜的規(guī)則之間是有推理關系的,，而且它對應的這個證據(jù)可能在很長的上下文的不同的段落,，所以這背后就對大模型提出了第二個挑戰(zhàn)：怎么去處理比較長的上下文。

針對這兩個挑戰(zhàn),，豆包大語言模型也在持續(xù)地迭代自己的能力,。首先從基礎模型的綜合性能上來講，如上圖左側(cè)是我們9月份發(fā)布最新版模型時模型提升的一個指標,。首先重點提升了模型的推理治理能力,，這個數(shù)學的分值背后就代表了推理能力的提升，其次就是在專業(yè)知識和綜合能力都有25%以上的提升,。

針對長的上下文,，豆包模型除了主流的4K、32K的窗口,，我們也支持256K的窗口,，直觀理解它大概等于33個小時的通話轉(zhuǎn)寫成文字的數(shù)量。其次我們看到在很多案例里業(yè)務真的非常復雜,，在這種情況下,，可能要對對話的記錄進行分段和分類，這會讓整個分析的任務工作量成倍上漲,，也會造成成本的上升,。

但是在質(zhì)檢和VOC這種離線的場景下，其實很多時候不用實時看到結(jié)果,，所以結(jié)合這兩個特點,，我們也推出了大模型的離線批量處理的一種功能，它能一天處理13億的文字,，這樣就能讓企業(yè)以一個更高性價比的方式去完成一個更智能的全量的質(zhì)檢,。

02

圍繞營收：AI客服的“談判/銷售”能力更進一步

營收核心是利用大模型產(chǎn)生出來的一些傳統(tǒng)客服沒有的能力，怎么利用這些能力更好地去多做一些任務,，釋放人的精力,，投入到更有價值的業(yè)務節(jié)點上,，一個比較典型的場景就是電銷和外呼。

在這個場景之下,，傳統(tǒng)的智能外呼更多地是做信息的通知和意向的確認,，這是整個銷售環(huán)節(jié)中的第一環(huán)。大模型具備了一定的磋商,、把握對象,、把握對話上下文走向的能力，所以它其實可以往后多做一步,，對整個銷售漏斗的轉(zhuǎn)化會有非常大的提升,。

如果還是讓人力去做整個的銷售環(huán)節(jié)，有兩個問題,，其一是成本比較高,，其二是很難提高并發(fā)。比如我們有一個非常典型的客戶,，他是招聘行業(yè)的一個企業(yè),，每年招聘季窗口時間是固定的，就會有大量的外呼任務去找求職者確認求職意向,，然后打給企業(yè)詢問有沒有買招聘服務包的這種需求,。

在傳統(tǒng)模式下，傳統(tǒng)外呼只能做一項的確認,，后邊還要人工大量地去篩選這些線索,。但是有了大模型的這種磋商的能力，在外呼的過程中,，首先能夠更準確地去判斷求職的意向,，其次能詢問到更多求職方向上的信息，更精準地去做職位的推薦和匹配,。

此外就是在一些簡單的場景,，在這些環(huán)節(jié)中，很多客戶已經(jīng)進行了實際的上線,，在交易的高峰期,，能夠很快地以AI坐席的這種形式去擴大外呼的規(guī)模，它整體拉新的成功率,，包括磋商的準確率已經(jīng)在很多場景下達到了跟人一樣的水平,，甚至更高。在這個場景之下,，對模型能力的考察更多的是在能不能利用上下文對話很好地理解用戶的問題,，把握整個對話脈絡的走向。

從這個角度上來講,，我們可以看到上圖左部分是一個公開的測評——中文簡短問答,，這個問答是公認的難度非常大的測評。大家能看到不同的模型在各個測評象限下的得分,，但是豆包整體的排名是在國內(nèi)第一的一個位置,，在全球來說是僅次于GPT的。

在[CC]中國文化這個象限下,，豆包的得分是全球最高,，這個測評本質(zhì)上是友商公開做的。從實效性上來講,，右半部分是上個月的最新結(jié)果,，在排名表現(xiàn)的背后其實是我們在大模型上不斷地投入，證明我們整體的技術實力和后勁是非常充足的,。

03

圍繞交互：更智能的上下文對話

對話這個場景在客服行業(yè)是非常重要的一個場景,，要想保證對話的效果，就要能記住更多的上下文,。其實現(xiàn)在已經(jīng)有非常多的方案通過記憶的方式讓大模型理解,，并去引導整個對話的走向，但這背后就有一個要求,，記住的上下文越多對延遲就會有一些影響,，其次就是成本的增加。

基于需要,，我們專門開發(fā)了一個上下文緩存的能力,，基于和豆包大模型的配合就能非常智能地記錄上下文，可以根據(jù)企業(yè)的要求丟棄重復的內(nèi)容,，而且對于監(jiān)測到的重復內(nèi)容價格也會更低,。

其次，對于大家關注的知識回答的準確度,，以及回答范圍的問題,。其實現(xiàn)在大模型這種預訓練的方式本身還是對知識的范圍有一定限制的，他只能訓練數(shù)據(jù)里有的內(nèi)容,，所以對于實時的新聞和企業(yè)獨有的業(yè)務知識,，它肯定是不知道的。

為了解決這個問題,，首先我們開發(fā)了聯(lián)網(wǎng)的內(nèi)容插件去和大模型配合,，讓它能實時搜索互聯(lián)網(wǎng)上的最新內(nèi)容，包括字節(jié)系獨有的內(nèi)容,。另外針對領域適應性和整體的問題,，有了檢索增強RAG的技術，將其和提示詞進行結(jié)合后，就能很好地去解決這樣一個問題,。

在背后其實我們也有一整套圍繞在大模型外圍的一個知識庫的方案,，可以被集成到這些客服的應用型的系統(tǒng)里，如上圖左側(cè)是一個非常典型的怎么去做知識庫檢索的處理流程,。

首先肯定要把這些業(yè)務數(shù)據(jù)上傳,，具有和飛書一樣的這種多類文檔的處理能力，不論您的業(yè)務知識在word,、Excel還是PPT里,，都可以很快地上傳。第二步就是要讓大模型去理解這些知識,，我們用到了豆包字眼的Embedding的向量模型去對知識進行向量化,。第三就是處理完的這個知識要存在一個向量的數(shù)據(jù)庫里，而不是傳統(tǒng)的數(shù)據(jù)庫,，這個數(shù)據(jù)庫和字節(jié)系的其他應用是完全同源的,，它可以在百億級的知識片段的規(guī)模下實現(xiàn)毫秒級的檢索，所以不論您的業(yè)務知識量有多大,，我們都可以保證交互的體驗,。

04

圍繞工具：更豐富的模型工具,，適應不同客服場景的需求

不同的場景有不同的訴求,，所以火山也針對性地有非常多的分支供大家從模型層面進行選擇。

首先是多模態(tài)的大語言模型,，不論您在客服的任何場景,，都推薦您從豆包通用模型Pro32K這個版本開始做嘗試。如果您的場景對延遲有非常高的要求,，您也可以嘗試通用模型lite版本,，花費更低的成本獲得一個更快的響應速度。在這兩個型號之下,，我們還有三個分支模型,，首先是做企業(yè)知識庫掛載非常重要的向量化模型。

第二就是Function Call模型,，客服的應用和企業(yè)的業(yè)務是息息相關的,，所以在服務過程中，要和業(yè)務系統(tǒng)有很多的交互,，比如依據(jù)用戶的問題去查詢訂單系統(tǒng)里用戶的下單時間,，去CRM系統(tǒng)查詢用戶的溝通記錄等，就會涉及和業(yè)務系統(tǒng)的交互,，為了更好地把用戶的自然語言轉(zhuǎn)化成這個機器系統(tǒng)能讀懂的API調(diào)用的語言,，我們專門有一個Function Call模型,，去解決函數(shù)調(diào)用的語言轉(zhuǎn)換的問題。

最后就是在對話過程中,，其實有一些場景客服本質(zhì)上沒有辦法給出現(xiàn)階段的解決方案,，這受制于產(chǎn)品的形態(tài)、市場的要求等,，所以在這些場景下,，當用戶產(chǎn)生一些負面情緒的時候,，更多我們要做的是情感的陪伴和安撫,，而不是說真的能提供解決方案。在這個場景下,，我們也發(fā)現(xiàn)有一些企業(yè)會嘗試把這類場景單獨拆解出來,，然后用角色模型去構建一個陪伴安撫的一個客服角色。

還有一個是現(xiàn)在在公開測試馬上就會正式發(fā)布的一個多模態(tài)的 vision Pro模型,，它能夠同時理解用戶輸入的文字和圖片,。以上就是針對不同的客戶場景下，我們從模型這個層面上做的多樣性的能力的提供,。

從工具的這個多樣性上,，大模型落地的過程中有幾個非常核心的點，第一個就是提示詞,，您可能需要一個工具去幫助您去構建提示詞,，然后去幫助您基于業(yè)務的效果智能優(yōu)化這個提示詞。還會涉及眾多模型分支,、各種溫度參數(shù)的管理,，其實這是需要一整套平臺去做的，我們?yōu)榱俗尨蠹矣幸徽臼降捏w驗,，開發(fā)了一套火山方舟平臺,，在這個平臺上可以對模型、提示詞,、精調(diào)的數(shù)據(jù)有一個端到端的管理,，這些能力也逐漸都被集成到我們的客服產(chǎn)品中，在這個工作臺上可以獲得非常好的一站式的體驗,。

除了模型本身能力之外,，對于落地大家非常關心的還有三個要素。

價格,，火山一直都在引領整個國內(nèi)大模型調(diào)用價格的下降趨勢,。

性能，業(yè)內(nèi)有兩個通用的指標,，第一個叫RPM——每分鐘能接受多少請求,，第二個是TPM——每分鐘能夠處理多少文字,。豆包大模型從初始默認提供給用戶的數(shù)據(jù)里，這兩個指標都比行業(yè)的平均值要高幾十甚至上百倍,，去支撐大家有一個很穩(wěn)定的業(yè)務的調(diào)用,。

安全，首先從模型本身內(nèi)容的安全性上,，火山在訓練時已經(jīng)做了充分的對齊,，能夠去識別對人類有害的內(nèi)容，然后拒絕回答這些問題,，完全符合國內(nèi)的法律法規(guī)的要求,，不會生成不合時宜、不合規(guī)的言論,。對于使用模型甚至精調(diào)模型的過程,，我們也有非常多的保密機制，保證您的數(shù)據(jù)只為您所見和所用,。

文稿來源 | 2024（第九屆）中國數(shù)字服務產(chǎn)業(yè)發(fā)展年會

分享嘉賓 | 火山引擎豆包大模型產(chǎn)品專家 劉一 

主題分享 | 豆包大模型：AI客服服務升級的關鍵密碼

整理編排 | 如耶 蔡蔡