京東商家智能助手:Multi-Agents 在電商垂域的探索與創新

電商助手是一款集合了多種電商經營決策功能的工具軟件,旨在幫助電商從業者完成從商品發佈到訂單管理、客服溝通、數據分析等一系列電商運營任務。

京東零售基於 Multi-Agents 理念搭建了商家助手大模型在線推理服務架構,這一系統的核心是算法層基於 ReAct 範式定製多個 LLM AI Agents,每個 Agent 都有專門業務角色和服務功能,可以調用不同的工具或多 Agent 協同工作來解決相應的問題。

以下是京東零售全渠道生態部關於《京東商家智能助手:AI 多智能體系統在電商垂域的探索與創新》的探索實踐,包括Multi-Agents 如何模擬真實的商家經營、ReAct 範式的 Multi-Agent 在線推理架構,以及Agent 落地垂域的樣本、訓練與評估監控的方法。歡迎大家一起交流

 

現實中,商家如何進行經營決策

 

Agent 需要模擬人類的決策過程,因此需要先了解現實中的經營是如何進行的。

通常,平臺向商家傳遞各種各樣的信息,包括新的玩法、新的規則條款,以及可能的懲罰通知等。面對平臺的各種消息和隨之而來的疑問,商家需要一個經營助手協助,他通常扮演着一個專門提供平臺知識百科的諮詢顧問角色。

當商家提出賠付、運費等與業務相關的複雜問題,需要先理解需求,然後從長篇的業務文本中抽取出問題解決的大方向或目標。定位問題後,形成逐步的解題思路,再靈活調用各種資源和工具來解決問題,其中包括調用知識庫、進行搜索和檢索,以及使用人腦進行總結和篩選重點內容。經過這一系列操作後將問題的最終答案返還給商家。

那麼如何將現實空間的平臺諮詢顧問映射到 Agent?顧問這個角色是我抽象出來的,京東實際上並沒有這樣的角色。對於商家來說,每天提供專屬服務的實際上是我的許多同事,包括在線客服、業務運營人員以及產品經理,他們解答各種問題。那是否需要爲每個崗位角色構建一個 Agent?解決這個問題時,我們還要回到應用場景,從商家的需求出發:無論誰在回答問題,對商家來說都只有一個人幫助他們解答問題。因此,構建一個 Agent 即可,它映射到爲商家提供專屬諮詢服務的多個業務崗位的人。 構建這樣一個 AI 版的 Agent 對商家和平臺都有好處。對商家而言,他們將體驗到一個永遠在線的百科全書,能夠突破時間、體力和知識掌握的極限。對平臺來說,可以降低成本。

除了上面單一的 agent 提供專屬服務的情況,當我們討論到多領域助手與商家的經營協作時,整個團隊是如何協作經營的呢?比如,商家提出了一個問題:“最近我的店鋪經營得怎麼樣?”這個問題看似簡單,但實際上是商家每天在處理完各種信息後首先會思考的。

對於現代電商商家來說,瞭解經營狀況通常從查看數據開始,然後才能評估經營狀況。他不會直接去系統讀取數據或編寫數據庫查詢語言,而是直接“調度”數據分析師這一角色,因爲商家清楚自己的目標是數據相關的服務。於是,他將任務分配給團隊中的數據分析專家,這位專家經過一系列操作後,會返回給商家一份數據報告。接下來,商家需要閱讀並理解這份數據報告,他可能會發現新用戶的留存率不佳的問題。這時,商家會根據新發現的問題更新決策。

商家的上述過程是 agent ReAct 範式的一個典型例子,即基於觀察(observation)來更新整個推理(reasoning)過程。 在解決問題的思路上,人類和 Agent 非常相似。

接下來,更新的決策就是商家重新選擇一個角色,比如用戶研究專家,來分析新用戶的偏好,解決新用戶的留存率不佳的問題。這樣的“拿到結果更新決策 - 調度新的專業角色 - 輸出結果”會不斷循環往復。

一個經營診斷與優化的問題,電商商家團隊的成員要懂得數據分析、平臺知識、用戶研究、商品選品、定價、營銷投放,還需要有人掌握製作圖片和音視頻素材的技能,以及完成所有操作和客戶售後運營。而商家自己,需要清楚地瞭解每個團隊成員的專長(profile),以便在更新決策時知道如何調度這些資源。此外,商家還需要能夠理解每個專家返回的結果,這對商家來說也不是件容易的事情。

當商家發展到一定階段,他們通常會聘請一個“最強大腦”來代理所有這些調度工作。這個“最強大腦”可以被理解爲一個“總管”。有了總管,所有的調度工作都由總管代理完成,而商家只需要與總管溝通即可。這樣的協作模式可以極大地提高商家的經營效率。商家想要完成一個經營診斷,他只需向總管提出:“幫我看看最近經營得怎麼樣?”然後他就可以耐心等待。總管在接到任務後,會進行一系列的操作,最終給出結論:“你最近新客戶的留存情況不太好,我這裏有一些商品營銷創意的建議,你看看是否採納。”相關的專家們的輸出材料會作爲附件提供給商家。

從單一個體到各個專業領域的專家團隊,再到基礎的執行工具,共同幫助商家完成了一個決策過程。在當前的團隊配置中,可以關注三類主要角色:

  1. 領域專家:以諮詢顧問爲代表,這類角色不僅具備決策能力,還能夠調度工具。在 AI 空間中,他映射我們的 Agent。
  2. 工具:這類角色不具備決策能力,只能執行任務。在 AI 世界中,映射爲軟件系統中已有的多種原子服務能力接口 API。
  3. 總管:作爲整個決策發起的引擎,總管不需要在某一領域深耕,但必須具備通用的電商知識,瞭解如何經營業務。在面對問題時,總管能知道如何發起調度,負責整體的專業服務流程編排,在 AI 空間中,他映射我們最強的 Agent。

 

構建 AI 版的商家經營團隊

 

商家經營團隊的運作模式爲我們提供了 AI Agent 的現實版樣例。現在來到 AI 空間,請出我們的商家智能助手,我們暫且稱呼它爲 Mario X。將現實空間的團隊映射到 AI 空間,我們用大量 Transformers 和研發代碼構建了一個 AI 版的商家經營團隊:一個由 Master Agent(主代理)領導的多領域 Agents 團隊,團隊同時掌控着一系列原子能力工具 API。

這樣的 AI 團隊帶來了多方面的好處:

1. 體驗提升:商家可以享受到 7*24 小時的在線服務。

2. 效率提高:商家不再需要學習使用各種工具和專業知識,只需用他們最熟悉的經營語言與 Master Agent 溝通,即可直接享受系統提供的各種服務。

3. 決策質量提升:由於有大量的備選方案可供選擇,商家的決策效率和質量自然會提高。

4. 成本節約:商家可以減少人力和時間的投入,平臺也可以減少不必要的運營開支,讓我們的業務人員從繁瑣的問答中解放出來。

 

 ReAct Agent 構建

 

構建 ReAct Agent 時,每個 Agent 會經歷一個 inner loop,這個內部循環稱爲 reasoning(推理),它對應於我們之前討論的思維過程,即生成解題思路和大目標的步驟。reasoning 過程包含兩個主要部分:

  1. Thought(思考) :我將其定義爲用人類自然語言描述的解題決策思路。但是,爲了調度系統工具,LLM 需要發出指令,因此需要將這種人類語言翻譯成系統能解析的研發語言(即下面的 action code)。
  2. 生成 Action Code(動作代碼) :基於生成的 Thought,Agent 會繼續生成 Action Code。這個 Code 不直接執行 Action,而是執行 action 的指令。Action Code 是基於 Thought 解析出來的,因爲 Thought 是拆分多步驟的解題思路,所以 Action Code 是對應的一系列任務。每個任務的定義可能非常複雜,提取 JSON 中的一些簡單字段來說明:
    1. 調度對象:告訴系統你要調度的工具是誰,比如 Master Agent 可能會調度其他 Agents 或 API。

    2. 輸入信息:提供給調度對象的信息,即函數的輸入參數。

    3. Job Description:如果調度的是 Agent,需要讓 Agent 明白分配給它的任務是什麼,類似於工作描述。

    4. Trust_Mode:這是考慮性能和 Agent 質量的一個字段,它決定了 Agent 在接收到工具返回的 observation(觀察結果)後,是再次進行 reasoning 還是直接輸出結果。

      Action Code 是服務端可解析的代碼,它會與環境中廣義的 Agents API 和 Tools 進行交互並執行代碼。當這些工具完成工作並將 observation 返回給 Agent 時,Agent 將進行下一輪的 reasoning。這個過程會一直持續,直到 Agent 生成了一個 Trust_Mode 變爲 1 的輸出,這意味着 Agent 認爲所有的推理和調度都已完成,可以將結果推送給用戶。

 

 Multi-Agent 的工作流程

 

打開 Mario X 首先會與商家打招呼。第一輪商家提問:“在京東開店需要交多少保證金?”時,用戶和 Master Agent 之間建立了聯繫,它會再從 Memory 中獲取與用戶相關的近期和遠期特徵。

接下來,Master agent 開始內部推理。在這個階段,Master agent 的 LLM 理解商家提出的問題,但意識到缺少必要的條件,因此無法直接派發任務。LLM 需要向商家追問一個條件,因爲保證金與商家經營的類目密切相關。這時,它會調用一個名爲 Echo 的工具,Echo 的作用僅僅是將信息傳遞給用戶,不做任何處理。此時 Master agent 將 Trust_Mode 設置爲 1,因爲 Echo 的任務是單向傳遞信息,不需要再返回給 LLM 進行推理。Action Code 開始執行,Echo API 被喚起,將問題傳回給用戶,同時將上下文信息推送給 Memory。

第二輪,商家回答說他賣花,這時用戶的信息再次流向 Agent,LLM 根據商家提供的信息和 Memory,生成解答思路在 Thought 中。LLM 知道現在需要調度的對象是 Consulting Advisor,即前面提到的平臺諮詢顧問 Agent 版。LLM 向 Advisor 傳遞了一個 Job Description,因爲 Advisor 是一個 Agent,需要與之溝通並分配任務。Agent 之間的通信協議也是基於 Action Code,告知 Advisor 商家需要查詢的類目對應的入住保證金費用。此時 Trust_Mode 設置爲 1,意味着 Advisor 完成任務後不需要再返回給 LLM,因爲 LLM 信任 Advisor 專門執行此類諮詢任務。這是出於性能考慮,避免讓用戶等待過久。隨後,Advisor Agent 執行任務並返回輸出,同時更新 Memory。最終,Master agent 回答用戶的問題。

第三輪,當客戶提出爲花店起名時, Master Agent 的 LLM 識別出這是一個明確的問題。爲了解決這個問題,將會進行 3 輪 ReAct。第一輪:不需要調用其他 Agents,而是直接調用一個特定的 API 會更加高效。它調用的是一個名爲“Shop Name Generator”的 API,這是一個基於大語言模型的起名工具,它需要接收的輸入參數是店鋪的類目信息。他從 Memory 中提取了之前 Advisor Agent 提供的信息,即商家經營的是“生活鮮花”,並將這個信息作爲參數傳遞給 Shop Name Generator。在這一步,Trust_Mode 爲 0,這意味着 API 生成的店鋪名字將返回給 Master Agent 做其他的推理,而不是直接輸出給用戶。我們回到了 ReAct 流程中,API 輸出了一系列的店鋪名字,但用戶此時還不會看到任何輸出的結果。

所有這些步驟完成後,相關信息都會被推入 Memory,這就是 Multi-Agent 工作架構的一個例子。對於普通的 Agent 與 Master Agent 的區別在於,Master Agent 直接與用戶交互,而普通 Agent 則接收來自 Master Agent 的 Action Code,這些 Action Code 轉化爲服務層協議,作爲它們的輸入參數。

 

 分層次架構

 

Multi-agent 架構採用分層次的方法,將一個大模型的複雜生成任務,拆解成了多個層級化的下一步文本預測。這樣,每個模型需要處理的推理難度就相對較小,因此模型的規模不需要很大,從而減少了訓練和部署的計算資源消耗,並且可以快速迭代。同時,也可方便靈活地接入各種資源方,比如營銷的 Agent,我們可以迅速地將其整合進我們的系統中。

這種架構也有一些潛在問題。首先,可能導致風險的累積。如果 Master Agent 出錯,那麼整個任務的結果可能就會受到影響。因此,我們實施了全鏈路監控,以確保系統的穩定性和可靠性。此外,由於可能需要經過多個 LLM 生成步驟,響應時間有時可能會較長。此外,商家面臨的問題通常涉及工具操作,這些問題都需要結合具體的業務情境來解決。因此,對於我們的 Agent 來說,它們也需要“死記硬背”所有 Tools 的能力。目前,我們正在進行的工作包括在整個推理流程的多個環節中整合 Retrieval(檢索)過程。例如在生成 Thought 之後,Agent 可以暫停並調用檢索工具或 Agent,等待 Observation 返回後再明確調用哪個 Tools,然後生成 Action Code。這意味着 Thought 和 Action 可以分兩輪生成,這是我們正在努力實現的一些改進。

 

商家智能助手:關鍵落地技術

 

今年 2 月份,我們推出了一個專門處理招商入駐問題的 Agent,並將其部署在京東的招商站點上。這個 Agent 幫助許多商家解答了他們關於入駐的相關問題和操作步驟。目前,這個全新的 muiti-Agent 架構助手產品已經在京東商家端進行灰度測試階段。

技術上,我們目前的系統能夠解決商家經營場景中的一些確定性輸出問題。所謂確定性輸出,是指商家面臨的一些答案明確的問題,比如關於平臺規則的疑問或具體的操作步驟等,這些問題相對基礎,並不包括那些開放式的問題,比如“告訴我如何做好生意”。

我們在建設一個能夠真正幫助商家做生意的靠譜助手,搭建完整 AI agent 經營團隊。這個系統將涉及非常廣泛的知識領域,處理的問題也不會有確定的答案,可能需要引入強化學習等更先進的技術來解決。

 ReAct SFT:垂域樣本構建

在解決相對確定性輸出的問題時,我們的核心工作在於構建垂直領域的知識。這意味着將人類專家的知識傳授給系統,特別是針對商家領域的知識。對於這類問題,通常使用標準的 SFT 加上一些預訓練模型基本上就足夠了。

如何構建樣本?鑑於我們先解決比較確定性的問題,我們可以從在線客服、運營和產品的回覆,以及商家滿意度收集的接口等獲得真實的數據,然後對這些數據進行清洗。接着,研發團隊會根據系統的調用路徑構建一個全面的路徑樹。最後,業務人員將構造一些劇本,描述可能的問答場景。

將這兩部分結合起來,我們就得到 SFT 樣本 的基礎池。接下來,對基礎池進行豐富度擴充。其中最主要的是對問題(Q)的擴充。有了問題和答案(A),以及調用路徑,我們接下來需要生成中間的標籤(label)即 thought 和 action code,這就需要依賴先驗的知識庫。此外,還需要研發的配合,他們需要按照標準來註冊 API。因爲工具的調用靠註冊信息的質量,如果兩個不同的工具,它們的描述寫成一樣的,那麼我們的大模型也無能爲力,因爲它只能通過工具的自我介紹來選擇工具來執行任務。因此,知識的準確性非常重要。

 複雜輸入下的 Thought 生成

複雜輸入的問題,不像簡單輸入那樣直接。解決這類問題,關鍵在於遵循 Agent 推理的流程:先生成 Thought,再解析 Action Code。因此,生成一個強大的 Thought 變得非常重要。下面看一個複雜輸入下,確定性輸出的例子,我們來對比單純用 RAG 和用 LLM agent 解題的效果,比較一下有和沒有好的 Thought 的區別。

(1)RAG 解題

例如,用戶提出了一個問題:“在京東賣紅酒要多少錢?”如果直接使用 Retrieval(檢索增強)來解決問題,按照經典的方式,先進行 Query(查詢)並計算 Similarity(相似度),然後召回一些文本。在召回的文本中,可能會看到白酒、黃酒等,但實際上並沒有答案,因爲紅酒這個類目在我們的知識庫中並不存在,它不是開店保證金的一個選項。基於錯誤的信息片段,再加上用戶模糊的問題,即使是非常強大的 Summary Model(總結模型)也無法給出正確的答案。

要解決這個問題,我們需要讓模型理解紅酒實際上與哪些類目是有關聯的。這就需要模型不僅要有檢索能力,還要有推理和關聯的能力,以便正確地將問題與相關的知識庫內容關聯起來,從而提供準確的答案。

(2) LLM Agent 解題

助手中的 Advisor 在經過訓練後,會以特定的方式解題。還是開始於 Master Agent 與用戶的對話。Master Agent 並不直接理解這個問題,而是將用戶的詢問,例如“京東紅酒入住資費是多少?”通過 Action Code 傳遞給 Advisor。Action Code 中的 Job Description 是“請回答京東紅酒入住資費”。

Advisor 在處理這個查詢時,首先理解紅酒實際上屬於葡萄酒這一類別。因此,Advisor 的 Thought 中生成出應該查詢的是葡萄酒類目的入住資費,並確定了使用哪些關鍵詞來傳給調度的檢索 API 做關鍵入參。在生成 Action Code 時,Advisor 會傳遞給檢索 API 這個關鍵入參,即 Search Query“葡萄酒保證金“。這個參數不再是用戶的原始問題,而是根據 Advisor 的推理進行了調整。API 本身沒有決策能力,但由於 Agent 具有推理能力,它能確保傳遞給工具的輸入是正確的,從而用正確的參數喚起正確的工具。

在第二個任務中,Summary API 接收到一個關鍵的輸入參數,稱爲 Thought for Answer,即回答思路。這個思路是 Advisor 在推理過程中在 thought 生成的關於紅酒與葡萄酒類目關係的理解。Advisor 告訴用戶紅酒和葡萄酒之間的關係,並按照葡萄酒類目的答案來回答用戶的問題。

接下來,advisor 繼續遵循經典的 RAG 流程。此時,Search Query 變爲“葡萄酒保證金”。雖然召回的葡萄酒與原始問題的“紅酒”相似性不高,但由於顧問使用了“葡萄酒”和“保證金”作爲搜索關鍵詞,並將回答問題的思路作爲 Prompt 的一部分傳遞給總結 API,API 就能夠根據 Advisor 提供的推理思路,正確地回答關於紅酒保證金的問題,即通過查看葡萄酒的保證金來得知紅酒的保證金情況。

 複雜輸入下的 Thought 訓練

在複雜輸入的情況下,訓練出能夠準確生成 Thought 的模型是關鍵。由於這類問題的答案並不直接存儲在知識庫中,我們需要從算法層面進行構建。我們的方法是分析 Bad case(不良案例),從中發現問題並拓展解題思路。

當遇到一個新案例時,我們會與業務團隊溝通,以獲取新的知識點,並按照既定的模式進行預先處理。理解不同類目之間的關係是解決相關問題的關鍵。因此,我們爲模型提供了大量類似的文本進行預訓練(pretrain)。

在自監督學習階段,模型學習了與業務相關的各種關鍵詞、相似詞以及它們與類目的關係。這樣,當模型遇到葡萄酒相關的問題時,它已經通過預訓練了解了如何處理這類問題。隨後,我們對模型進行標準的 SFT,在這個階段,模型會學習到具體的知識點,比如葡萄酒的相關信息。模型已經知道如何回答關於葡萄酒的問題,並且通過訓練了解了葡萄酒與其他類目的關係。當用戶詢問關於紅酒保證金的問題時,模型能夠通過分析和推理,提供準確的答案。

通過這種方式,我們可以訓練出能夠處理複雜輸入並生成有效 Thought 的模型,這些模型能夠更好地理解和解決商家面臨的實際問題。

 全鏈路 ReAct 監控

爲了定位 Bad Case,我們實施了全鏈路 ReAct 監控。具體來說,我們會收集在線推理生成的 Thought、Action Code 和 Observation,然後通過人工打標 + 大模型來進行評估。

評估函數會將人工打標的輸出與 Agent 生成的輸出進行比較,以確定兩者之間的差異。這個評估與 Agent 的具體定義緊密相關,因爲不同的 Agent 可能有不同的評估標準。評估主要基於三個結果:Thought、Action Code 和 Observation。值得注意的是,Observation 雖然是作爲下一輪推理的輸入,但它本身並不是由 LLM 生成的,它的質量會影響下一輪的 Thought 生成。

對於 Observation 的評估可能包括預測銷量的準確性或用戶對生成圖像的滿意度等,這些指標並不完全由 LLM 控制,因此 Observation 的評估也與服務的業務指標相關。

基於這些評估結果,我們會有一個流程來決定 Agent 的表現。如果 Agent 在第一輪的 ReAct 得分很低,我們會繼續累積這個分數,但如果得分低於某個閾值,我們將停止後續的推理,並且該 Agent 將不再參與後續得分的累加,意味着它已經退出了推理過程。如果 Agent 的得分符合要求,我們會檢查是否爲最後一輪推理。如果不是最後一輪,Agent 將更新後進入下一輪評估。如果是最後一輪,將觸發結束流程。

在多輪推理和評估後,當觸發結束評估時,我們會得到一個全鏈路累積的 ReAct 得分。這個推理過程是鏈式的,涉及到遞減的折扣因子γ和η,這些因子會影響 Agent 的 ReAct 得分和整體得分。我們的評價核心在於能夠快速定位問題節點,這是由我們的架構決定的,必須通過這種方式來儘早發現並解決問題,防止問題在推理過程中蔓延。

 

展    望

 

我們需要幫助商家更好地經營生意。儘管在平臺上有許多類似參謀的工具,比如供應鏈管理、選品、定價等,但目前還沒有一種方式能夠讓商家根據自己的業務思路,按照黃金流程組合使用這些工具。無論是問答數據、溝通數據還是交互數據,這些都需要我們去收集和整合。

我們需要將人們做生意的思維方式從人腦中提取出來,這包括訓練大型模型來尋找和學習人類專家的知識。此外,我們還需要引入強化學習。 因爲對於商家提出的複雜問題,如“我的生意做得怎麼樣?”可能存在多種解決方案,每個團隊的解法可能都不同。要判斷哪一個更好,可能需要每個做生意的人根據自己的打分邏輯來評估,同時還需要在市場反饋中驗證。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章