導語：大模型技術正以前所未有的速度與各領域融合，為各行各業帶來變革，圍繞快手 B 端商業化的業務場景，本文詳細闡述了構建基于 LLM 的 Agent 技術平臺的策略、挑戰及解決方案，為您帶來寶貴的見解與啟示。

一、大模型應用建設背景

快手商業化業務中臺，作為核心支撐，全面賦能內部的一線銷售、運營團隊，以及外部的代理商和服務商。面對大模型技術的浪潮，我們精準捕捉智能化轉型的先機。面對眾多可選擇的技術路徑，經過我們進行了深入剖析與審慎考量，最終決定將戰略重心聚焦于 RAG 與 Agent 技術的研發與應用。

RAG，作為我們的助手，通過檢索、增強與生成三大環節的緊密協作，精準匹配并高效解決用戶查詢，顯著提升信息處理的效率與質量。而 Agent 技術，則扮演著智能體的角色，它不僅具備高度的自主性與交互能力，還能在復雜多變的業務環境中靈活應對，執行多樣化的任務。

在這一過程中，我們果斷舍棄了與當前業務場景關聯度不高或短期內難以產生顯著效益的技術方向，如 AIGC 的某些特定應用、過于細分的垂直領域探索等，以確保資源能夠集中投入到 RAG 與 Agent 技術的深耕細作之中。通過此次聚焦，我們能夠加速推動快手商業化業務的智能化進程，為一線團隊提供更加智能、高效、便捷的工作體驗，同時也為公司創造更加卓越的商業價值與社會效益。

::: hljs-center

快手商業化 B 端業務場景

:::

二、SalesCopilot 技術平臺的誕生與演進

SalesCopilot 平臺誕生的背景

在當前的商業環境中，銷運團隊作為企業連接市場與客戶的橋梁，面臨著眾多挑戰。然而，隨著業務規模擴大，一系列痛點逐漸顯現，亟待通過產品建設來加以解決。

• 知識碎片化：業務多元化發展，各類重要產品知識、營銷通案、政策、流程文檔等關鍵信息，往往未能有效整合零散地分布在不同的團隊或個人手中，進而導致信息獲取不便利。

• 問題解決慢：在日常工作中，銷運團隊需要與多個部門或團隊進行協作。然而，由于架構和人員的變動，當面臨問題時無法快速定位到對接人，加之人工響應的時效性難以保證，這進一步加劇了問題解決效率。

• 銷運支持資源有限：即便增加人力也無法趕上日益增長的業務需求，且寶貴的經驗與專業知識難以得到有效傳播與深入交流。

針對上述痛點，快手商業化團隊急需開發一款集知識管理、團隊協作與智能答疑于一體的產品。基于此，第一個應用銷幫幫智能客服應運而生。在智能化升級的過程中，我們逐步沉淀打造了 SalesCopilot 技術平臺。在項目的推進過程中，逐漸意識到，通過實踐積累經驗，我們有能力并且有責任構建一個能夠支撐多元化智能應用的技術底座。因此，我們采取了雙軌并行的策略：一方面，持續孵化并優化智能客服等應用，另一方面，則為技術平臺的 SaaS 架構布局打下堅實基礎。

SalesCopilot 系統架構

下圖為 SalesCopilot 系統架構圖，它展現了我們這一愿景的具體實現路徑，其概括為“三橫一縱”。

::: hljs-center

SalesCopilot 技術平臺

:::

在“三橫”結構中，最底層且最為核心的是 AI 引擎層，這一層是技術平臺的智慧大腦，集成了 RAG 等前沿技術，實現了知識的檢索、增強與生成，為上層應用提供了強大的智能支撐。同時，業務意圖（Agent）模塊作為橋梁，精準對接業務需求與底層 AI 能力，確保系統的靈活性與適應性。此外，效果評測中心及語義向量相關組件的加入，進一步提升了 AI 引擎的性能與精確度。

第二層是 ChatHub 層，它專注于智能客服場景，提供了一個可擴展的框架，用于集成并優化多種智能客服能力。這一設計既滿足了當前業務需求，更為未來功能的拓展預留了充足空間。最上層則是業務應用層，它以租戶為核心，實現了數據的個性化隔離與業務的靈活定制。每個租戶都能在此層構建自己的專屬應用，享受定制化的智能服務。而“一縱”則是指貫穿于整個架構的插件框架與多租戶框架。這兩個框架構成了 SalesCopilot 平臺化的基石，它們不僅保障了系統的穩定性與可擴展性，還使得平臺能夠輕松應對多業務、多場景的挑戰，為技術的長遠發展奠定了基礎。

深入淺出 AI 引擎的 RAG 技術

LLM 的局限性

RAG 是在大模型應用后，很快被大家識別和接受的技術范式，其獨特之處在于對大型語言模型局限性的有效彌補，以下是大模型的局限性：

• 幻覺問題：在自由生成文本時，可能產生與現實不符的“幻覺”內容，影響信息的準確性。
• 知識時效性問題：模型訓練成本高昂，且知識庫難以實時更新，導致對新信息的反應滯后。
• 記憶容量局限：無狀態 chat 服務，prompt 長度有限，當前模型難以保留長記憶。
• 數據安全問題：私域數據參與訓練存在不可控安全隱患。

::: hljs-center

大模型的優勢與局限性

:::

RAG 技術鏈路

RAG 技術鏈路分為離線與在線兩大核心部分：

離線鏈路：此部分包括知識構建與知識預處理，而知識構建與運營是 RAG 運轉的基礎。構建技術鏈路只是起點，若缺乏專業團隊對知識庫進行持續運營、質量把控及規模擴張，就如同汽車缺乏燃油難以馳騁。知識預處理則包括切片、Embedding 等常規操作，以及快手特有的知識下鉆能力，該能力能夠深入挖掘知識間的關聯，由于快手大部分知識都是以云文檔的格式存在的，且包括對內、對外兩種形式，彼此引用與擴展。通過快手自研的知識下鉆技術，將原本看似獨立的 200 篇文檔擴展至 1000 余篇，極大地豐富了知識庫的廣度和深度。通過 GraphRAG 本地化實踐，融合 LLM 技術與圖譜技術，提升了跨 chunk 和跨文檔的全局知識問答效果。離線鏈路還包含多路召回（向量檢索、ES 檢索、GraphRAG）的強語義知識索引建構，為在線鏈路的業務效果提供索引數據支撐。

在線鏈路：作為 RAG 技術的核心執行部分，在線鏈路由檢索（R）、向量召回（A）與生成（G）三大環節緊密組成。自多路召回策略上線以來，其效果在向量匹配上已實現了顯著提升，高達 70%的增幅，然而，隨著用戶需求的日益多樣化與復雜化，對 Query 的深入理解與優化成為了新的挑戰。用戶提問的隨意性與不可預測性，倒逼我們不斷調整 Query 解析策略，提升系統對追問、反問等復雜場景的應對能力，而這些能力會慢慢成為引導這個系統進一步發展的關鍵點。

::: hljs-center

RAG 技術鏈路

:::

業務中的實際應用

在實際應用中，銷幫幫智能客服在 12 個直客行業和渠道業務部中，銷售人員覆蓋率達到 42.8%。在知識管理方面，更是實現了質的飛躍。原本由五人維護的 270 余篇知識文檔，在銷幫幫的助力下，下鉆擴展至 1000 余篇，知識庫的豐富度與深度均得到了明顯提升。此外，機器人的攔截率達到 78%左右。多路召回和精排應用實施后，效果提升非常顯著，在評測階段，知識問答平均分百分比提升了 70.68%。

在業務實踐中，不可避免地會遭遇諸多挑戰，這些挑戰可大致歸為以下幾大類：

首先，RAG 系統本身便蘊含著復雜性與深度。用戶的提問往往泛化而不明確，這類提問初看之下或被視為不佳案例（Bad Case），但深入分析后，實則發現了模型需要增加追問和問題分類理解能力。漏召回與回答準確率的不足，則可通過引入多路召回與精排策略得以有效緩解，進而提升系統性能。最后是領域“黑話”帶來的問題，要求我們在垂直領域內深耕細作，積累專業知識。

大模型雖強，卻也并非無所不能。其總結能力的不穩定性便是一大痛點，需通過精細調整 Prompt 來優化。在此過程中，確保擁有可靠的評測工具至關重要，它能確保每次調整都能帶來正面效果，避免在解決一個問題時引入新的問題，導致原本表現良好的案例（Good Case）反遭損害。同時，大模型在處理長上下文時的局限性也需我們關注，嘗試有限多輪對話的優化路徑，以更貼近用戶的真實使用場景。

最后是用戶需求和當前功能的不匹配。我們發現了一個顯著的趨勢：用戶在與客服交互時，越來越多地采用先圖片后提問的方式。這一現象則揭示了用戶對于多模態交互的強烈需求。當前功能的局限性與用戶日益增長的多元化需求之間，形成了一道亟待跨越的鴻溝。這要求我們不斷創新，將圖像識別、語音識別等先進技術融入產品中，以滿足用戶更加豐富的交互需求。

::: hljs-center

業務實踐中的挑戰

:::

Agent 技術的全面解析

Agent 的技術鏈路
在深入探討我們的 Agent 實踐時，我們已超越了簡單的“tool use”范疇，向著更加智能與全面的方向發展。Agent 的核心價值，不僅在于其工具性應用的層面，更在于其作為連接業務與用戶需求的橋梁角色。它能精準回應用戶期待，高效解決用戶問題，這一過程中，Agent 需緊密集成于系統之中，充分利用業務接口、數據模型等核心資源。

為了實現 Agent 的高效運行，我們構建了一套接口與意圖的 schema 體系。在 schema 中，定義了每個業務意圖的名稱、詳盡描述及具體示例（即“shot”），這些信息對于大模型而言，是理解 API 邏輯、把握業務意圖的關鍵鑰匙。在實踐初期，大模型在意圖識別上的表現不盡如人意。一方面我們優化了 Prompt，將若干意圖 shot 融入其中；另一方面我們升級了 LLM，部署了 qwen2-7b，最后由于 Prompt 長度有限，我們對意圖清單做粗排以支持 300+的意圖識別，之后整體的意圖識別效果得到顯著提升。

::: hljs-center

Agent 的技術鏈路

:::

Agent 的意圖執行

意圖的執行策略涵蓋了從簡至繁的多種模式，每種模式都針對特定場景需求而設計。最基本的是單 Plugin 模式，它實現了意圖與 API 的直接映射。在這種模式下，用戶的簡單需求（如搜索網頁、查詢天氣）能夠迅速轉化為 API 調用，直接返回結果。

然而，在復雜多變的業務場景中，這種模式顯得力不從心。面對復雜的業務邏輯，如銷售場景中查詢客戶合同進度，這里可能涉及到這個客戶是不是合法的、簽的是哪個合同、簽了多少錢……，我們需要引入多 Plugin 意圖執行能力。這一能力允許我們將復雜的任務拆解為多個子任務，每個子任務由不同的 Plugin 處理。目前，實現這一能力主要有兩種方式：一種是預定義執行邏輯，即在明確意圖后，通過人工編排大模型的執行路徑；另一種則是大家談得比較多的 ReAct 模式，即讓 AI 在推理過程中動態決定執行步驟。雖然推理+執行這個概念特別性感，但穩定性不佳，比如說 AutoGPT 最好的表現只有 50%左右，直接把這套東西推到線上系統是不可接受的。

::: hljs-center

意圖執行

:::

在業務實踐中，有兩種意圖執行方式。其一，我們采用了自然語言處理技術，直接從用戶的言語中精準捕捉其意圖，并立即啟動相應的執行流程。另一種方式則更為簡潔一些，識別到用戶的意圖后，通過彈出卡片界面的方式進行確認，并快速執行最終任務。

大模型的關鍵設計與效果評測

另外，關于我們大模型設計的核心理念，主要聚焦于以下三點：

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

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

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

::: hljs-center

大模型的應用策略

:::

在探索大模型驅動的應用研發這一領域時，我們深知自己正置身于一個“不確定性”之中。每一環節，一旦與大模型緊密相連，便無可避免地伴隨著效果的波動與不確定性。因此，構建一個高效、精準的評測中心，對于確保系統的可控性與效果的持續提升必不可少。我堅信，評測中心對于大模型驅動的應用研發而言，是不可或缺的基石。它賦予了我們駕馭不確定性的能力，只有如此，我們才能確保系統在不斷迭代中穩步前行，真正實現效果的持續提升。

::: hljs-center

效能評測中心

:::

三、大模型應用研發的思考

在此，我總結了大模型應用研發過程中的四點關鍵思考，希望對大家有所幫助！

第一生產力：智能化技術平權。大模型技術的革新，真正實現了智能化技術的普惠與平權。大模型通過提供先進的算法和龐大的數據處理能力，使得即使是資源較少的小企業或小團隊也能利用頂級的 AI 技術進行產品開發和業務優化。這一轉變，極大地降低了技術門檻，加速了創新項目的孵化，讓智能化不再是大型機構的專屬，而是成為推動各行各業轉型升級的強勁動力。

第二 RAG 效果提升：乘積效應。RAG 效果提升是一個非常系統性的工作，要做到比較好的效果，有非常多的智能化和工程策略的事情要做，沒有銀彈，要抓關鍵細節一個個去做實做深。從 Query 理解到知識維護，再到多路召回策略的優化，每一個環節精細打磨，都是實現效果飛躍的關鍵。當效果達到 70%后，則更需保持耐心與毅力，繼續深挖細節，以精益求精的態度，逐步突破瓶頸，邁向更高的巔峰。

第三路徑選擇：從垂直細分領域開始。在開始研發大模型應用時，我們深思熟慮后決定采取一條從垂直細分領域切入的路徑。這一決策并非偶然，而是基于對當前技術發展階段和市場環境的深刻洞察。大模型技術，盡管已取得顯著進展，但仍處于其發展歷程的初期階段，尚未形成成熟、標準化的應用范式。因此，盲目追求構建一個包羅萬象的通用 Agent 平臺，不僅可能因技術的不成熟而遭遇重重困難，還可能因研發周期的漫長和用戶反饋的滯后，錯失先機。相反，我們選擇從具體、明確的垂直細分領域入手，這些領域往往具有清晰的應用場景和迫切的智能化需求。通過在這些領域內深耕細作，我們能夠快速驗證大模型技術的有效性，并積累寶貴的實踐經驗。同時，階段性地選取具有代表性的標桿應用進行重點開發，樹立行業標桿流。在這一過程中，我們同步進行架構布局，為未來的平臺化發展奠定根基。

第四需求趨勢：多模態。展望未來，多模態交互將成為 Agent 發展的重要趨勢。這一趨勢不僅符合人類自然交互的習慣，更以其信息密集、表達豐富的特點，為用戶帶來更為絕佳的交互體驗。隨著技術的不斷進步與成熟，我們有理由相信，多模態能力將不斷提升，為 Agent 的發展注入新的活力與可能。

【本文正在參與 AI.x社區AIGC創新先鋒者征文大賽】http://www.ekrvqnd.cn/aigc/2223.html