嘉賓 | 歐迪佐

編輯 | 李美涵

出品 | 51CTO技術棧（微信號：blog51cto）

本文整理自快手高級技術專家歐迪佐在WOT2024大會上的主題分享，更多精彩內容及現場PPT，請關注51CTO技術棧公眾號，發送【WOT】即可直接領取。

日前，在51CTO主辦的WOT全球技術創新大會上，快手高級技術專家歐迪佐帶來了主題演講《LLM-based Agent在B端商業化的技術探索與實踐》，圍繞著B端商業化的業務場景，詳細介紹了構建Agent技術平臺的實踐經驗與深入思考，為觀眾呈現了全新的視角。

本文將摘選其中精彩內容，統一整理，希望為諸君帶來啟發。 本文將從以下三個部分展開：

1.大模型應用建設背景

2. SalesCopilot技術平臺

3. 大模型應用研發的思考

1.大模型應用建設背景

圖片

首先是我們的建設背景，快手的商業化業務中臺，所服務的對象包括我們公司內部的一線的銷售、運營以及我們的代理商和服務商，業務涉及數據分析的一系列的場景。

圖片

在大模型出來之后，我們意識到很多場景都有機會去做智能化升級。

我們可選擇的技術方向不少，結合自身的場景，最終選擇了做RAG和Agent，前者是知識助手，后者就是智能體。

圖片

我們舍棄了其他與自身業務場景無關的部分，比如說AIGC、垂直領域等，保證我們能夠聚焦于這兩個技術方向上。

2.SalesCopilot技術平臺

在做智能化升級的過程中，我們慢慢沉淀出SalesCopilot技術平臺。

我們做的第一個應用是我們銷幫幫的智能客服。在推進的過程中，我們逐漸意識到我們有機會幫助技術部沉淀一個大模型應用研發平臺的。因此，我們一邊孵化應用，一邊去為我們整個技術平臺做架構方面的伏筆。

圖片

上圖為SalesCopilot的系統架構圖，在大體上分為四個部分，三橫一縱。

三橫部分從下面往上看，最核心的部分就是AI引擎的部分。AI引擎包含前面所提到的RAG，這部分會在后面詳細展開。還有業務意圖（Agent），它起到承上啟下的作用——上面連接業務，下面連接各種業務系統。這里還有一個效果評測中心，再加上語義向量相關的一些組件。以上共同組成了AI引擎。

第二層是Chathub，我們目前主要服務的是面向智能客服的場景，所以我們就抽象出ChatHub這層，基于這個框架去接入多個智能客服的能力。

最上面一層是業務應用，所謂的業務應用是以一個租戶的身份接入進來，基于租戶去做數據隔離、業務個性化等。

一縱，包含兩部分：插件框架、多租戶框架。這就是我們整個平臺化的基礎架構。

下面重點講AI引擎的部分。

圖片

第一個部分是RAG。RAG是在大模型應用后，很快被大家識別和接受的技術范式，它在針對大模型的局限性做了有效的補充。這里順便講下大模型的幾個局限，幫助大家理解。

圖片

第一，幻覺問題。在RAG的范式下，我們基于召回，給了LLM一個具有高度確定性的上下文，讓它在這個上下文中去組織回答。所以RAG并不能完全消除幻覺，只是極大地緩解幻覺。

第二，大模型的知識時效問題。大模型的訓練成本時間成本和經濟成本非常高，很容易面臨剛訓練完就失效了的狀態。基于RAG的外掛知識庫，它可以做到知識的實時更新。

第三，大模型的記憶容量有局限。這個問題同樣可以通過召回加精排解決，把與用戶問題最相關的信息提前整理出來，放在一個有限的Prompt里。

第四，數據安全問題。我們在大模型訓練時是絕不可能拿到其他企業內部數據的，這也有賴于RAG緩解由此帶來的矛盾。

圖片

上圖為目前整個RAG的技術鏈路，由四個部分組成。離線鏈路上知識構建和運營的部分，其是整個RAG運轉的重要基礎。這里很容易被忽視，在座的各位都是偏技術的同學，我們通常認為把技術鏈路構建起來，好像就一定能得到一個好的結果，其實不是。如果沒有一個專門的團隊去做知識的運營、知識質量的保障、知識規模的增長等等，就好比沒有油的車一樣跑不起來。

第二個部分是知識預處理，這部分比較常規，比如說要做切片、要做Embedding。快手有個比較特殊的情況，我們大部分知識都是以云文檔的格式存在的，有對內、對外兩種形式。而知識之間經常相互引用，所以我們研發了一個知識下鉆的能力，舉個實際的例子，200篇知識文檔，經過我們的下鉆擴展后，最終庫里達到700篇。

以上是離線鏈路。離線鏈路里會有一個多路召回，這部分呢已經在向量和ES中準備好了。

在線鏈路的核心由三部分組成。

RAG的R是我們常規的檢索。RAG的A是向量召回的部分，也是三部分中的核心。G就是我們最終構建的RAG Prompt，讓LLM總結的部分。

我們一直在優化功能。在最開始上線多路召回以后，我們發現這個策略能夠在向量上提升70%的效果。隨著發展，一定會發現在對Query的理解上需要調整——因為用戶對系統的邊界、定義是沒有感知的，會隨意地提出問題。這里就會倒逼我們調整對整個Query的理解，優化應對追問、反問的能力。而這些能力會慢慢成為引導這個系統進一步發展的關鍵點。

下面來看幾個我們自己的案例。

圖片

這是整個我們自己做的第一個應用及其效果。

圖片

可以看到，銷幫幫在整個商業化中覆蓋了30%以上的銷售人員；在維護知識庫方面，五個人的專門團隊維護了200多篇知識，而我們通過銷幫幫擴展到700多篇；此外，機器人的攔截率達到78%左右。

應用核心就是我們上個月做的多路召回+精排，對效果提升非常顯著。建議大家在實際工作中優先嘗試。

圖片

在做業務的過程中，我們會遇到很多挑戰，可以分成以下幾類。首先是RAG本身的問題，例如用戶的提問泛化、不明確。這樣的提問很容易被識別為一個Bad Case,但如果我們仔細分析，我們會發現是模型需要一些追問能、問題分類理解的能力。而漏召回、回答準確率的問題，通過多路召回和精排就可以解決。最后是領域黑話帶來的問題，需要在垂直領域里去做相關的沉淀。

其次是大模型相關的問題。我們有時候會發現大模型的總結能力特別不靠譜，需要去做相關的Temperature和 Prompt的調整。在調整時，一定要有相對應的評測工具來保障調整后的效果是單調增長的，否則有可能解決了一個問題后，反而使原來好多的Good Case變成了Bad Case。像大模型的上下文長度問題，需要嘗試去做一些有限多輪的調整。

最后是用戶需求和當前功能的不匹配。例如，我們觀測用戶使用過程中發現，很多用戶與客服的交互是先甩一張圖，然后再進行提問。這說明用戶在實際使用時，對多模態的需求是非常強烈的。

圖片

再講一下我們Agent的實踐。

圖片

我們現在當前階段對Agent的理解可能是，比tool use再高級一點。但這不是對Agent的全面的理解，首先，Agent最基本的能力確實有一個tool use的東西，再往上它要連接業務，從本質來看是在回應用戶的需求、解決用戶任務。所以Agent要下連系統，系統里面有業務接口、數據模型相關的能力。

在運行態的時候，這些信息是如何被關聯起來的？主要是設計了一套關于接口和意圖的schema的東西。這套schema里包含了很多幫助大模型去理解這些API以及業務意圖的信息。

圖片

大家可以看紅字部分，我們在表達一個業務意圖的時候，會有三個概念：名稱、描述和舉例說明。當你把這些信息組織到Prompt中之后，你會發現，大模型對指令的服從性會提升。

其實，我們最開始實踐時，并沒有把那個shot（舉例）放在一個特別高的位置上，但是這時發現大模型做意圖識別時準確度較低。當我們加入了不止一個shot時，意圖識別準確率馬上就提上來了。

整個意圖的執行有三種模式。

圖片

其中，最簡單的是所謂的單Plugin，單Plugin就是一個意圖直接對應一個API，比如說幫用戶搜一個網頁、查一下天氣，直接把參數拿去執行就可以。

但是實際做業務的時候，不可能這么簡單，比如銷售說幫我查一下某個客戶簽合同的進度，這里面可能涉及到這個客戶是不是合法的、簽的是哪個合同、簽了多少錢，再把進度的比例算出來。

所以，我們需要一個多Plugin意圖執行能力。目前有兩種方式，一種是知道這個意圖是什么，提前編排好了大模型的執行邏輯；另一種是大家談得比較多的ReAct，AI來做推理+執行。不過，我們在實踐中發現，雖然推理+執行這個概念特別性感，但穩定性不佳，比如說AutoGPT最好的表現只有50%左右，把這套東西推到線上系統是不可接受的。

圖片

這里幾個案例中，我們意圖執行的方式有兩種：一種是通過自然語言的方式去提取用戶的意圖，然后執行；另一種方式是，識別到用戶意圖后，通過彈出卡片的方式確認，并快速執行最終任務。

圖片

再講一下，我們關于大模型的關鍵設計，主要是以下三點。

可插拔，能根據需求快速替換或更新模型，支持多模型協作，讓不同任務調用最適合的模型；

LSP，LLM Specific Prompt/模型專用提示LLM各有調性，皆有適合自己的Prompt風格；

量化LLM，量化大模型通過減少參數精度來降低資源需求，僅少量智能損失可跑高性能跑在CPU上。

圖片

這個就是我們的效果評測中心。需要分享的是，我們在做大模型驅動的應用研發時候，必然面臨著不確定，效果永遠不會達到100%。必須要匹配相應的評測中心，以保證你的系統是可控的、單調的達到效果的提升。

3.大模型應用研發的思考

最后講四點思考。

第一，生產力：智能化技術平權。大模型技術實現了智能化技術的普及，使得即使是十個人的小團隊也能通過獲取大模型服務，快速實現高質量的基礎效果，做一個大的項目。除非走到非常深水區的地方，才需要算法的介入。

第二，效果提升:乘積效應(RAG)。RAG通過系統性優化，如Query理解、知識維護和多路召回等關鍵環節，顯著提升了知識問答的效果。但當效果達到70%后，再往上突破就會有一定難度，需要深入的工作。

第三，路徑選擇:從垂直細分領域開始。我們選擇從垂直細分領域開始應用大模型，階段性地選擇優先做標桿應用，同時做架構布局，逐步向成熟的Agent平臺發展。相反，如果起步時去做通用化大Agent，則面臨研發周期長、用戶反饋慢的問題。

第四，需求趨勢:多模態。多模態交互將成為Agent發展的趨勢，因其符合人類自然交互體驗且信息密集，預計隨著技術進步，多模態能力將不斷提升。

本文轉載自??51CTO技術棧??