嘉賓 | 歐迪佐
編輯 | 李美涵
出品 | 51CTO技術棧（微信號：blog51cto）
本文整理自快手高級技術專家歐迪佐在WOT2024大會上的主題分享，更多精彩內容及現(xiàn)場PPT，請關注51CTO技術棧公眾號，發(fā)送【WOT】即可直接領取。
日前，在51CTO主辦的WOT全球技術創(chuàng)新大會上，快手高級技術專家歐迪佐帶來了主題演講《LLM-based Agent在B端商業(yè)化的技術探索與實踐》，圍繞著B端商業(yè)化的業(yè)務場景，詳細介紹了構建Agent技術平臺的實踐經驗與深入思考，為觀眾呈現(xiàn)了全新的視角。
本文將摘選其中精彩內容，統(tǒng)一整理，希望為諸君帶來啟發(fā)。 本文將從以下三個部分展開：
1.大模型應用建設背景
2. SalesCopilot技術平臺
3. 大模型應用研發(fā)的思考
1.大模型應用建設背景
首先是我們的建設背景，快手的商業(yè)化業(yè)務中臺，所服務的對象包括我們公司內部的一線的銷售、運營以及我們的代理商和服務商，業(yè)務涉及數據分析的一系列的場景。
在大模型出來之后，我們意識到很多場景都有機會去做智能化升級。
我們可選擇的技術方向不少，結合自身的場景，最終選擇了做RAG和Agent，前者是知識助手，后者就是智能體。
我們舍棄了其他與自身業(yè)務場景無關的部分，比如說AIGC、垂直領域等，保證我們能夠聚焦于這兩個技術方向上。
2.SalesCopilot技術平臺
在做智能化升級的過程中，我們慢慢沉淀出SalesCopilot技術平臺。
我們做的第一個應用是我們銷幫幫的智能客服。在推進的過程中，我們逐漸意識到我們有機會幫助技術部沉淀一個大模型應用研發(fā)平臺的。因此，我們一邊孵化應用，一邊去為我們整個技術平臺做架構方面的伏筆。
上圖為SalesCopilot的系統(tǒng)架構圖，在大體上分為四個部分，三橫一縱。
三橫部分從下面往上看，最核心的部分就是AI引擎的部分。AI引擎包含前面所提到的RAG，這部分會在后面詳細展開。還有業(yè)務意圖（Agent），它起到承上啟下的作用——上面連接業(yè)務，下面連接各種業(yè)務系統(tǒng)。這里還有一個效果評測中心，再加上語義向量相關的一些組件。以上共同組成了AI引擎。
第二層是Chathub，我們目前主要服務的是面向智能客服的場景，所以我們就抽象出ChatHub這層，基于這個框架去接入多個智能客服的能力。
最上面一層是業(yè)務應用，所謂的業(yè)務應用是以一個租戶的身份接入進來，基于租戶去做數據隔離、業(yè)務個性化等。
一縱，包含兩部分：插件框架、多租戶框架。這就是我們整個平臺化的基礎架構。
下面重點講AI引擎的部分。
第一個部分是RAG。RAG是在大模型應用后，很快被大家識別和接受的技術范式，它在針對大模型的局限性做了有效的補充。這里順便講下大模型的幾個局限，幫助大家理解。
第一，幻覺問題。在RAG的范式下，我們基于召回，給了LLM一個具有高度確定性的上下文，讓它在這個上下文中去組織回答。所以RAG并不能完全消除幻覺，只是極大地緩解幻覺。
第二，大模型的知識時效問題。大模型的訓練成本時間成本和經濟成本非常高，很容易面臨剛訓練完就失效了的狀態(tài)。基于RAG的外掛知識庫，它可以做到知識的實時更新。
第三，大模型的記憶容量有局限。這個問題同樣可以通過召回加精排解決，把與用戶問題最相關的信息提前整理出來，放在一個有限的Prompt里。
第四，數據安全問題。我們在大模型訓練時是絕不可能拿到其他企業(yè)內部數據的，這也有賴于RAG緩解由此帶來的矛盾。
上圖為目前整個RAG的技術鏈路，由四個部分組成。離線鏈路上知識構建和運營的部分，其是整個RAG運轉的重要基礎。這里很容易被忽視，在座的各位都是偏技術的同學，我們通常認為把技術鏈路構建起來，好像就一定能得到一個好的結果，其實不是。如果沒有一個專門的團隊去做知識的運營、知識質量的保障、知識規(guī)模的增長等等，就好比沒有油的車一樣跑不起來。
第二個部分是知識預處理，這部分比較常規(guī)，比如說要做切片、要做Embedding。快手有個比較特殊的情況，我們大部分知識都是以云文檔的格式存在的，有對內、對外兩種形式。而知識之間經常相互引用，所以我們研發(fā)了一個知識下鉆的能力，舉個實際的例子，200篇知識文檔，經過我們的下鉆擴展后，最終庫里達到700篇。
以上是離線鏈路。離線鏈路里會有一個多路召回，這部分呢已經在向量和ES中準備好了。
在線鏈路的核心由三部分組成。
RAG的R是我們常規(guī)的檢索。RAG的A是向量召回的部分，也是三部分中的核心。G就是我們最終構建的RAG Prompt，讓LLM總結的部分。
我們一直在優(yōu)化功能。在最開始上線多路召回以后，我們發(fā)現(xiàn)這個策略能夠在向量上提升70%的效果。隨著發(fā)展，一定會發(fā)現(xiàn)在對Query的理解上需要調整——因為用戶對系統(tǒng)的邊界、定義是沒有感知的，會隨意地提出問題。這里就會倒逼我們調整對整個Query的理解，優(yōu)化應對追問、反問的能力。而這些能力會慢慢成為引導這個系統(tǒng)進一步發(fā)展的關鍵點。
下面來看幾個我們自己的案例。
這是整個我們自己做的第一個應用及其效果。
可以看到，銷幫幫在整個商業(yè)化中覆蓋了30%以上的銷售人員；在維護知識庫方面，五個人的專門團隊維護了200多篇知識，而我們通過銷幫幫擴展到700多篇；此外，機器人的攔截率達到78%左右。
應用核心就是我們上個月做的多路召回+精排，對效果提升非常顯著。建議大家在實際工作中優(yōu)先嘗試。
在做業(yè)務的過程中，我們會遇到很多挑戰(zhàn)，可以分成以下幾類。首先是RAG本身的問題，例如用戶的提問泛化、不明確。這樣的提問很容易被識別為一個Bad Case,但如果我們仔細分析，我們會發(fā)現(xiàn)是模型需要一些追問能、問題分類理解的能力。而漏召回、回答準確率的問題，通過多路召回和精排就可以解決。最后是領域黑話帶來的問題，需要在垂直領域里去做相關的沉淀。
其次是大模型相關的問題。我們有時候會發(fā)現(xiàn)大模型的總結能力特別不靠譜，需要去做相關的Temperature和 Prompt的調整。在調整時，一定要有相對應的評測工具來保障調整后的效果是單調增長的，否則有可能解決了一個問題后，反而使原來好多的Good Case變成了Bad Case。像大模型的上下文長度問題，需要嘗試去做一些有限多輪的調整。
最后是用戶需求和當前功能的不匹配。例如，我們觀測用戶使用過程中發(fā)現(xiàn)，很多用戶與客服的交互是先甩一張圖，然后再進行提問。這說明用戶在實際使用時，對多模態(tài)的需求是非常強烈的。
再講一下我們Agent的實踐。
我們現(xiàn)在當前階段對Agent的理解可能是，比tool use再高級一點。但這不是對Agent的全面的理解，首先，Agent最基本的能力確實有一個tool use的東西，再往上它要連接業(yè)務，從本質來看是在回應用戶的需求、解決用戶任務。所以Agent要下連系統(tǒng)，系統(tǒng)里面有業(yè)務接口、數據模型相關的能力。
在運行態(tài)的時候，這些信息是如何被關聯(lián)起來的？主要是設計了一套關于接口和意圖的schema的東西。這套schema里包含了很多幫助大模型去理解這些API以及業(yè)務意圖的信息。
大家可以看紅字部分，我們在表達一個業(yè)務意圖的時候，會有三個概念：名稱、描述和舉例說明。當你把這些信息組織到Prompt中之后，你會發(fā)現(xiàn)，大模型對指令的服從性會提升。
其實，我們最開始實踐時，并沒有把那個shot（舉例）放在一個特別高的位置上，但是這時發(fā)現(xiàn)大模型做意圖識別時準確度較低。當我們加入了不止一個shot時，意圖識別準確率馬上就提上來了。
整個意圖的執(zhí)行有三種模式。
其中，最簡單的是所謂的單Plugin，單Plugin就是一個意圖直接對應一個API，比如說幫用戶搜一個網頁、查一下天氣，直接把參數拿去執(zhí)行就可以。
但是實際做業(yè)務的時候，不可能這么簡單，比如銷售說幫我查一下某個客戶簽合同的進度，這里面可能涉及到這個客戶是不是合法的、簽的是哪個合同、簽了多少錢，再把進度的比例算出來。
所以，我們需要一個多Plugin意圖執(zhí)行能力。目前有兩種方式，一種是知道這個意圖是什么，提前編排好了大模型的執(zhí)行邏輯；另一種是大家談得比較多的ReAct，AI來做推理+執(zhí)行。不過，我們在實踐中發(fā)現(xiàn)，雖然推理+執(zhí)行這個概念特別性感，但穩(wěn)定性不佳，比如說AutoGPT最好的表現(xiàn)只有50%左右，把這套東西推到線上系統(tǒng)是不可接受的。
這里幾個案例中，我們意圖執(zhí)行的方式有兩種：一種是通過自然語言的方式去提取用戶的意圖，然后執(zhí)行；另一種方式是，識別到用戶意圖后，通過彈出卡片的方式確認，并快速執(zhí)行最終任務。
再講一下，我們關于大模型的關鍵設計，主要是以下三點。
可插拔，能根據需求快速替換或更新模型，支持多模型協(xié)作，讓不同任務調用最適合的模型；
LSP，LLM Specific Prompt/模型專用提示LLM各有調性，皆有適合自己的Prompt風格；
量化LLM，量化大模型通過減少參數精度來降低資源需求，僅少量智能損失可跑高性能跑在CPU上。
這個就是我們的效果評測中心。需要分享的是，我們在做大模型驅動的應用研發(fā)時候，必然面臨著不確定，效果永遠不會達到100%。必須要匹配相應的評測中心，以保證你的系統(tǒng)是可控的、單調的達到效果的提升。
3.大模型應用研發(fā)的思考
最后講四點思考。
第一，生產力：智能化技術平權。大模型技術實現(xiàn)了智能化技術的普及，使得即使是十個人的小團隊也能通過獲取大模型服務，快速實現(xiàn)高質量的基礎效果，做一個大的項目。除非走到非常深水區(qū)的地方，才需要算法的介入。
第二，效果提升：乘積效應(RAG)。RAG通過系統(tǒng)性優(yōu)化，如Query理解、知識維護和多路召回等關鍵環(huán)節(jié)，顯著提升了知識問答的效果。但當效果達到70%后，再往上突破就會有一定難度，需要深入的工作。
第三，路徑選擇：從垂直細分領域開始。我們選擇從垂直細分領域開始應用大模型，階段性地選擇優(yōu)先做標桿應用，同時做架構布局，逐步向成熟的Agent平臺發(fā)展。相反，如果起步時去做通用化大Agent，則面臨研發(fā)周期長、用戶反饋慢的問題。
第四，需求趨勢：多模態(tài)。多模態(tài)交互將成為Agent發(fā)展的趨勢，因其符合人類自然交互體驗且信息密集，預計隨著技術進步，多模態(tài)能力將不斷提升。
