引言

多智能體的架構(gòu)演進(jìn)過程：

第一階段：B商城工單自動回復(fù)，LLM和RAG結(jié)合知識庫應(yīng)答，無法解決工具調(diào)用。

第二階段：京東招商站，單一Agent處理知識庫問答和工具調(diào)用，準(zhǔn)確率低 & LLM模型幻覺，場景區(qū)分度差。

第三階段：京麥智能助手，引入multi-agent架構(gòu)，master + subagents協(xié)同工作模式，把問題分而治之，顯著提升準(zhǔn)確率。

?

商家助手的算法底座是基于大語言模型（LLM）構(gòu)建的Multi-agent系統(tǒng)，模擬的是現(xiàn)實中電商商家團(tuán)隊的經(jīng)營協(xié)作方式。商家只需使用他們最熟悉的自然語言，與京麥平臺上的這個助手進(jìn)行溝通，就可以獲得7*24小時的經(jīng)營代理服務(wù)。本文檔將從模擬的現(xiàn)實商家經(jīng)營空間映射到Multi-agent算法空間，逐步解析電商平臺業(yè)務(wù)場景下商家助手的業(yè)務(wù)動機(jī)、算法技術(shù)架構(gòu)以及關(guān)鍵技術(shù)。

商家助手Multi-agent是一個通用&開放的商家經(jīng)營服務(wù)多種能力（比如銷量預(yù)測，營銷投放，定價，商機(jī)詞推薦等）接入的宿主，可隨著建設(shè)的不同階段友好的面向其他能力提供方的Tools，包括Agent、API等形式。

1.商家經(jīng)營：從多角色現(xiàn)實空間到Multi-Agent算法空間

Multi-Agent系統(tǒng)架構(gòu)的設(shè)計動機(jī)來自于“Agent模擬的是現(xiàn)實世界的人的解決問題過程”的本質(zhì)。首先介紹現(xiàn)實世界商家和他的團(tuán)隊是怎么經(jīng)營的，以及他們和AI世界怎么進(jìn)行角色映射。

?

?QCon_京東商家智能助手.mp4?

?

?

?

2、Multi-Agent Planning關(guān)鍵技術(shù)：

2.1 Agent構(gòu)建技術(shù)：ReAct范式的多模型集成

1. Agent構(gòu)建集成四類模型，實現(xiàn)了Agent大腦的智能化逆向規(guī)劃能力：

?LLM：審題并提煉終極目標(biāo)，為逆向規(guī)劃定向，同時校驗調(diào)用鏈路的合理性。

?Embedding：快速匹配終極節(jié)點工具，避免LLM冗長prompt和選擇工具幻覺問題。

?Tools DAG：進(jìn)行多路徑逆向推理，結(jié)合LLM抽取參數(shù)工具，精確得到調(diào)度策略。

?運(yùn)籌優(yōu)化：理論上可加速解題，提升逆向規(guī)劃效率，待實際測試驗證。

2. ReAct規(guī)劃動態(tài)更新

動態(tài)規(guī)劃更新：在規(guī)劃正向執(zhí)行中，ReAct范式實現(xiàn)每一步根據(jù)執(zhí)行結(jié)果的動態(tài)規(guī)劃更新。

3.技術(shù)挑戰(zhàn)和收益：

?提升規(guī)劃效率，降低推理成本：多個模型編排替代超大模型，顯著提高推理速度與規(guī)劃效率，同時節(jié)約推理成本。

?提升架構(gòu)穩(wěn)定性，效果、風(fēng)險可控：任務(wù)拆分后，小模型處理簡單明確任務(wù)，大模型專注單一復(fù)雜任務(wù)，合理分工使效果與風(fēng)險均可控，減少模型迭代對整體的影響。

?治理LLM幻覺提升規(guī)劃質(zhì)量：Embedding解決LLM帶來的不確定性與幻覺，Tools DAG確保規(guī)劃邏輯性與準(zhǔn)確性，京麥場景工具調(diào)用準(zhǔn)確率提升10%。

?減少LLM樣本工程量：LLM僅處理文本理解，不直接選工具，避免新工具需大量樣本訓(xùn)練的問題，系統(tǒng)擴(kuò)展性與維護(hù)效率提高60%以上。

?實時性和準(zhǔn)確性：通過ReAct動態(tài)規(guī)劃更新，實時調(diào)整策略，優(yōu)化執(zhí)行鏈路。

?

2.2 Multi-Agent Online Inference

2.2.1 技術(shù)特色

1. 任務(wù)分層動態(tài)規(guī)劃與分布式協(xié)作：基于ReAct范式，通過Master Agent和Sub Agents在不同層級進(jìn)行任務(wù)動態(tài)規(guī)劃和動態(tài)調(diào)度，支持分布式協(xié)作。

?Master Agent：在領(lǐng)域?qū)用孢M(jìn)行任務(wù)規(guī)劃，將復(fù)雜場景拆解為多個獨立子任務(wù)調(diào)度sub-Agens協(xié)同工作。

?Sub Agents：在領(lǐng)域內(nèi)執(zhí)行任務(wù)規(guī)劃，負(fù)責(zé)具體的子任務(wù)執(zhí)行，支持分布式調(diào)度和協(xié)同工作。

2. Agent協(xié)作基于標(biāo)準(zhǔn)通信協(xié)議：

通過標(biāo)準(zhǔn)通信協(xié)議確保Muti-agent高效協(xié)同工作，支持多步聯(lián)動和全局思維鏈規(guī)劃。

?Agent標(biāo)準(zhǔn)通訊協(xié)議：確保Muti-agent系統(tǒng)中的各agent高效協(xié)同工作，支持任務(wù)的分層規(guī)劃和執(zhí)行。

?多步聯(lián)動：支持多個相互依賴的任務(wù)，通過ReAct單步執(zhí)行和回調(diào)機(jī)制，完成復(fù)雜任務(wù)。

2.2.2 Multi-Agent Online Inference 演示：

為了展示multi-agent的協(xié)同在線推理流程，錄制了一個視頻。結(jié)合京麥前臺的助手產(chǎn)品形態(tài)，同步展示后臺multi-agent的后臺算法推理服務(wù)，方便大家理解。干貨見以下視頻：

?H-MAP_4k.mp4?

?

2.2.3 架構(gòu)小結(jié)

特色：

推理難度低：將超大模型的全鏈路多步計劃的生成任務(wù)，轉(zhuǎn)化成next task prediction

成本低：多個小型模型的協(xié)同更容易落地，訓(xùn)練、部署成本低

迭代快：問題定位迅速，模型快速迭代

?

待解決：

響應(yīng)時間長：面對復(fù)雜問題，用戶更長的等待耗時，需要在產(chǎn)品上做引導(dǎo)

風(fēng)險積累：多agents鏈?zhǔn)酵评碛绣e誤累計風(fēng)險。 解決方案研究中，如多智能體聯(lián)合學(xué)習(xí)

?

多Agent架構(gòu)與單Agent及LLM-MoE架構(gòu)對比，多Agent架構(gòu)在同等大模型能力下具有更強(qiáng)的穩(wěn)定性，能更好支持復(fù)雜業(yè)務(wù)場景和任務(wù)的協(xié)作與擴(kuò)展，但需要更多的工程開發(fā)量和更復(fù)雜的推理鏈路。

?技術(shù)方案調(diào)研?

?

2.3 Agent全鏈路ReAct評估技術(shù)

1.Agent全鏈路ReAct效能綜合評估

?全鏈路評估：從全局視角出發(fā)，通過任務(wù)拆解和鏈路調(diào)度，對系統(tǒng)中每個Agent進(jìn)行加權(quán)評分，以計算Multi-Agent系統(tǒng)的整體效能。

?局部評估：使用Reward Model對每個Agent的ReAct循環(huán)中存在的thought/action/observation進(jìn)行評估，識別性能瓶頸和低效模型環(huán)節(jié)，提供針對性優(yōu)化建議。

2.多樣化Reward Model

?業(yè)務(wù)自定義：支持業(yè)務(wù)自定義規(guī)則函數(shù)/reward模型，用于靈活適應(yīng)不同業(yè)務(wù)需求的評估。

?現(xiàn)有大模型：利用現(xiàn)有的高階Sota大模型進(jìn)行評估，確保評估的通用性和準(zhǔn)確性。

?訓(xùn)練Reward模型：通過訓(xùn)練專門的模型進(jìn)行評估，提升對特定任務(wù)和場景的適應(yīng)能力。

?

Reward Model-平臺化AI評估模型案例說明：

輸入總結(jié)模型的目標(biāo)是針對用戶歷史的會話記錄與本輪的提問分析其具體意圖，作為Master Agent的思考的核心環(huán)節(jié)，需要對其意圖總結(jié)效果進(jìn)行評價。

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶當(dāng)前輪次提問與歷史的會話記錄，對線上推理的準(zhǔn)確性進(jìn)行評價。
2.自動化評分指令（簡化）：
你是一個擅長問題意圖理解的專家?，F(xiàn)在需要你評估一個電商平臺AI助手對于商家用戶提問的意圖理解質(zhì)量，并要求你從以下維度對回答進(jìn)行評估，評分為0-10分，分?jǐn)?shù)必須是整數(shù):1.正確性:意圖是否正確表達(dá)出用戶當(dāng)前的問題；2.關(guān)聯(lián)性:當(dāng)前問題的意圖可能和歷史對話強(qiáng)關(guān)聯(lián)，也可能無關(guān)，判斷助手理解的意圖是否正確關(guān)聯(lián)歷史對話。
我們會給你提供用戶本輪提問、歷史與AI助手的對話，和需要你評估的AI助手答案。有可能為你提供一個參考答案，當(dāng)給出參考答案時，你需要判斷AI助手總結(jié)的意圖和給出的參考意圖的相似度，該維度名為“和人工理解相似程度”。
按照以下字典格式（包括括號）返回你所有的打分結(jié)果：{{'維度一': 打分, '維度二': 打分, ..., '綜合得分': 打分}}。例如：{{'正確性': 6, '關(guān)聯(lián)性': 9, ..., '綜合得分': 7}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[歷史對話開始]n{history_conv}n[歷史對話結(jié)束]
[參考意圖開始]n{reference}n[參考意圖結(jié)束]n
[助手意圖理解開始]n{intention}n[助手理解意圖結(jié)束]n

2、待評估案例：
假設(shè)用戶本輪提問、歷史對話、助手意圖理解分別如下：
1.用戶本輪提問：
我這個是京東小店的
2.歷史對話：
【顧客】：什么類目的標(biāo)題可以不帶品牌的名字
【客服】：都需要帶上品牌的
3.助手意圖理解：
說明店鋪類型為某平臺小店

3、不同標(biāo)注場景下的打分結(jié)果：
1.存在人工標(biāo)注：此時人工標(biāo)注即為指令中的“參考意圖”
參考意圖：
詢問京東小店的商品標(biāo)題是否需要帶品牌名字
評分結(jié)果：
    1.正確性: 助手理解的意圖并沒有準(zhǔn)確表達(dá)出用戶當(dāng)前的問題。用戶當(dāng)前的問題是詢問京東小店的商品標(biāo)題是否需要帶品牌名字，而助手理解的意圖只是說明了店鋪類型為某平臺小店，未能準(zhǔn)確捕捉用戶的真實意圖。
    2.關(guān)聯(lián)性: 助手理解的意圖與歷史對話沒有正確關(guān)聯(lián)。歷史對話中用戶詢問的是商品標(biāo)題是否需要帶品牌名字，而助手理解的意圖并未涉及這一點。
    3.和人工理解相似程度: 助手理解的意圖與人工意圖有明顯差異。人工意圖準(zhǔn)確捕捉了用戶的問題，而助手理解的意圖只是說明了店鋪類型，未能反映用戶的真實需求。
    綜合評價:助手理解的意圖未能準(zhǔn)確表達(dá)用戶的真實意圖，也未能正確關(guān)聯(lián)歷史對話，與人工意圖差異較大，因此綜合評分較低。
    綜合來說：{{'正確性': 3, '關(guān)聯(lián)性': 2, '和人工理解相似程度':2, '綜合得分':2}}
2.不存在人工標(biāo)注：此時指令中的“參考意圖”為“無”
評分結(jié)果：
    1.正確性: 助手理解的意圖與用戶當(dāng)前提問的主要內(nèi)容不符。用戶想了解的是京東小店的商品標(biāo)題中是否需要說明品牌名稱，助手理解的用戶意圖為說明自身為京東小店，意圖理解錯誤。
    2.關(guān)聯(lián)性: 助手理解的意圖與歷史對話未正確關(guān)聯(lián)。在之前的會話中，用戶詢問的目的是商品標(biāo)題攜帶品牌名的必要性，助手未理解該意圖。
    綜合評價:助手理解的意圖在正確性和關(guān)聯(lián)性上均有不足，因此綜合評分較低。
    綜合來說：{{'正確性': 3, '關(guān)聯(lián)性': 2, '綜合得分':3}}

工具調(diào)度類模型需要針對用戶提問、結(jié)合可用API的具體描述，進(jìn)行API選擇與相關(guān)的參數(shù)解析，因此需要對模型解析出的action code進(jìn)行準(zhǔn)確度評價。

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶提問、API資料庫，對線上推理的準(zhǔn)確性進(jìn)行評價。
2.自動化評分指令（簡化）：
你是一個擅長評價API使用合理性的助手?，F(xiàn)在需要你評估一個電商平臺AI助手要解決商家用戶提問時，所調(diào)用的API是否正確；如果正確選擇了API，需要進(jìn)一步判斷對該API的參數(shù)解析是否正確。請注意：你只需要評價API選擇以及參數(shù)解析的正確與否，不需要生成正確的調(diào)用方法。
我們會給你提供用戶的提問、API，和需要你評估的AI助手答案?？赡転槟闾峁┯脩籼釂柕膶?yīng)參考答案，當(dāng)存在參考答案時，準(zhǔn)確性評價必須與參考答案對比得出；不存在參考答案時，僅需要根據(jù)助手答案自身展開評價。
按照以下字典格式（包括括號）返回你所有的評價結(jié)果：{{'API選擇': 正確或錯誤, '參數(shù)解析': 當(dāng)API選擇錯誤時，結(jié)果為“無”；當(dāng)API選擇正確時，結(jié)果為正確或錯誤}}。例如：{{'API選擇': '錯誤', '參數(shù)解析': '無'}}；{{'API選擇': '正確', '參數(shù)解析': '正確'}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[API信息開始]n{retrivals}n[API信息結(jié)束]n
[參考解析結(jié)果開始]n{reference}n[參考解析結(jié)果結(jié)束]n
[助手解析結(jié)果開始]n{answer}n[助手解析結(jié)果結(jié)束]n 

2、待評估案例：
假設(shè)用戶本輪提問、API信息、助手解析結(jié)果分別如下：
1.用戶本輪提問：
我有多少訂單是王萍萍買的？    
2.API信息：
【1】{
    "name": "check_shop_qualifications",
    "description": "當(dāng)用戶提出有關(guān)經(jīng)營過程中資質(zhì)要求（如上傳材料、營業(yè)執(zhí)照、行業(yè)資質(zhì)等）相關(guān)的問題時，需要調(diào)用此工具查詢具體資質(zhì)要求的相關(guān)信息，然后根據(jù)查詢到的信息回答用戶問題。",
    "parameters": {
        "type": "object",
        "properties": {
            "keyword": {
                "description": "用戶經(jīng)營的主要類目、商品類型或者商品品牌，例如：洋酒、玩具、阿迪達(dá)斯等。如果沒有提供該類信息，必須反問用戶要求其提供"
            },
            "shop_body": {
                "description": "店鋪主體，只能是以下三種：企業(yè)、個人和個體工商。"
            },
            "shop_type": {
                "description": "店鋪類型，只能是以下六種：旗艦店、專賣店、專營店、賣場店、普通企業(yè)店和小店。"
            }
        },
        "required": ["keyword"]
    }
}
【2】{
    "name": "search_order_code",
    "description": "該工具用于根據(jù)用戶提供的信息（如訂單編號、下單時間、下單賬號等）查詢訂單的詳細(xì)信息，包括商品詳情與訂單詳情。",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {
                "description": "訂單編號：12位純數(shù)字，用于記錄訂單的唯一標(biāo)識"
            },
            "consumer_name": {
                "description": "客戶姓名：用戶姓名、買家姓名、收件人、收貨人、顧客、客戶等"
            },
            "user_pin": {
                "description": "下單賬號：下單賬戶、買家pin，買家、顧客、用戶等，通常由客戶姓名+數(shù)字或純英文組成"
            },
            "sku_id": {
                "description": "商品編號：14位純數(shù)字信息，"
            },
            "sku_name": {
                "description": "商品名稱：商品信息的描述，可能攜帶品牌信息或商品具體屬性"
            },
            "consumer_mobile_phone": {
                "description": "客戶電話：用戶手機(jī)號碼，11位純數(shù)字信息，可能會以區(qū)號+86，400等開頭。"
            },
            "search_keys": {
                "description": "用戶希望查詢的目標(biāo)，枚舉值只能從[商品、訂單]中選擇。若用戶希望查詢的是訂單中的商品id、商品名稱、商品詳情等，枚舉值為商品；若用戶希望查詢的目標(biāo)是訂單編號、訂單數(shù)量等，枚舉值為訂單。"
            }
        },
        "required": []
    }
}
3.助手解析結(jié)果：
{
    "action_code": {
        "api_name": "search_order_code",
        "parameter": {
            "consumer_name": [
                "王萍萍"
            ],
            "search_keys": [
                "商品"
            ]
        },
    }
}

3、不同標(biāo)注場景下的打分結(jié)果：
1.存在人工標(biāo)注：此時人工標(biāo)注即為指令中的“參考解析結(jié)果”
參考解析結(jié)果：
{
    "action_code": {
        "api_name": "search_order_code",
        "parameter": {
            "consumer_name": [
                "王萍萍"
            ],
            "search_keys": [
                "訂單"
            ]
        },
    }
}
評分結(jié)果：
    1.API選擇：AI助手的答案中選擇調(diào)用search_order_code，與參考答案一致，API調(diào)用正確。
    2.參數(shù)解析：AI助手的答案中search_keys為商品，但參考答案中search_keys為訂單，因此參數(shù)解析錯誤。
    綜合來說：{{'API選擇': '正確', '參數(shù)解析': '錯誤'}}
2.不存在人工標(biāo)注：此時指令中的“參考答案”為“無”
評分結(jié)果：
    1.API選擇：用戶希望查詢顧客王萍萍的訂單，AI助手的答案中選擇調(diào)用search_order_code，該工具可以進(jìn)行訂單詳情查詢，因此API調(diào)用正確。
    2.參數(shù)解析：API助手解析的參數(shù)中，查詢目標(biāo)為商品，但用戶希望查詢的內(nèi)容是訂單，因此參數(shù)解析結(jié)果與用戶提問意圖不符，解析錯誤。
    綜合來說：{{'API選擇': '正確', '參數(shù)解析': '錯誤'}}

輸出總結(jié)模型需要針對用戶提問與召回的語料進(jìn)行總結(jié)回答，因此需要對模型最終的總結(jié)效果進(jìn)行評價。

1、自動化評價方案：
1.評價方法：以高階模型（例如：GPT-4o）作為裁判模型，結(jié)合用戶提問與召回的語料得到線上推理的回答評分。針對有人工標(biāo)注和無人工標(biāo)注兩種情況，構(gòu)造出一套通用的打分指令，兼容不同場景。
2.自動化評分指令（簡化）：
你是一個擅長評價文本質(zhì)量的助手?，F(xiàn)在需要你評估一個電商平臺AI助手對于商家用戶提問的回答的質(zhì)量，并要求你從以下維度對回答進(jìn)行評估，評分為0-10分，分?jǐn)?shù)必須是整數(shù):1.滿足用戶需求:回答內(nèi)容是否解決用戶提問；2.事實正確性:回答是否從參考語料中得到，不允許過度推斷得到的回答；3.回答完備性:僅針對要回答的問題，是否完整地提取了語料中的全部信息。
我們會給你提供用戶的提問、需參考的核心語料，和需要你評估的AI助手答案?？赡転槟闾峁┯脩籼釂柕膶?yīng)參考答案，當(dāng)存在參考答案時，評分需要對比參考答案得出；不存在參考答案時，僅需要根據(jù)助手答案自身展開評價。
按照以下字典格式（包括括號）返回你所有的打分結(jié)果：{{'維度一': 打分, '維度二': 打分, ..., '綜合得分': 打分}}。例如：{{'滿足用戶需求': 6, '事實正確性': 9, ..., '綜合得分': 7}}。
輸入數(shù)據(jù)格式如下:
用戶本輪提問: {question}n
[核心語料開始]n{retrivals}n[核心語料結(jié)束]n
[參考總結(jié)結(jié)果開始]n{reference}n[參考總結(jié)結(jié)果結(jié)束]n
[助手總結(jié)結(jié)果開始]n{answer}n[助手總結(jié)結(jié)果結(jié)束]n 

2、待評估案例：
假設(shè)用戶本輪提問、核心語料、助手總結(jié)結(jié)果分別如下：
1.用戶本輪提問：
偏遠(yuǎn)地區(qū)發(fā)出了又不要了，運(yùn)費誰承擔(dān)
2.核心語料：
【1】[售后-交易糾紛] 京東開放平臺運(yùn)費問題糾紛處理標(biāo)準(zhǔn)鏈接：https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1
【2】[售后-交易糾紛] 當(dāng)買賣雙方根據(jù)運(yùn)費發(fā)生糾紛時，京東根據(jù)“誰過錯，誰承擔(dān)”的原則處理，但買賣雙方協(xié)商一致的除外。
【3】[售后-交易糾紛] 《運(yùn)費問題的糾紛處理規(guī)則》判定運(yùn)費糾紛責(zé)任：第十條 若買賣雙方就如上運(yùn)費問題產(chǎn)生糾紛，申請京東介入的，京東將根據(jù)本標(biāo)準(zhǔn)內(nèi)容進(jìn)行判定，如商家違反運(yùn)費要求或舉證內(nèi)容無效，將判定商家責(zé)任。
3.助手總結(jié)結(jié)果：
當(dāng)買賣雙方根據(jù)運(yùn)費發(fā)生糾紛時，京東根據(jù)“誰過錯，誰承擔(dān)”的原則處理，但買賣雙方協(xié)商一致的除外。具體處理標(biāo)準(zhǔn)您可參考以下鏈接：[京東開放平臺運(yùn)費問題糾紛處理標(biāo)準(zhǔn)鏈接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)

3、不同標(biāo)注場景下的打分結(jié)果：
1.存在人工標(biāo)注：此時人工標(biāo)注即為指令中的“參考總結(jié)結(jié)果”
參考總結(jié)結(jié)果：
京東根據(jù)“誰過錯，誰承擔(dān)”的原則處理，但買賣雙方協(xié)商一致的除外：若消費者無正當(dāng)理由拒絕簽收，發(fā)貨運(yùn)費由消費者承擔(dān)；消費者有理由拒絕簽收（商品有質(zhì)量問題、少貨等），發(fā)貨運(yùn)費由商家承擔(dān)。n詳細(xì)內(nèi)容請參考[京東開放平臺運(yùn)費問題糾紛處理標(biāo)準(zhǔn)鏈接](https://rule.jd.com/rule/ruleDetail.action?ruleId=3727&type=0&btype=1)
評分結(jié)果：
    1. 滿足用戶需求:AI助手的答案部分解決了用戶的提問，提到了“誰過錯，誰承擔(dān)”的原則，但沒有具體說明在偏遠(yuǎn)地區(qū)發(fā)貨后又不要了的情況下，運(yùn)費由誰承擔(dān)。相比之下，參考答案更詳細(xì)地解釋了不同情況下的運(yùn)費承擔(dān)方。因此，AI助手的回答在滿足用戶需求方面不夠全面。
    2. 事實正確性:AI助手的答案內(nèi)容來自核心語料，引用了“誰過錯，誰承擔(dān)”的原則，并提供了相關(guān)鏈接。這部分內(nèi)容是準(zhǔn)確的。
    3. 回答完備性:AI助手的答案沒有完全提取核心語料中的全部信息，尤其是缺少了關(guān)于消費者無正當(dāng)理由拒絕簽收和有理由拒絕簽收的具體情況的解釋。相比之下，參考答案更為詳細(xì)和完備。
    綜合評價:AI助手的回答在事實正確性方面表現(xiàn)良好，但在滿足用戶需求和回答完備性方面有所欠缺?？傮w來說，回答質(zhì)量中等。
    綜合評分如下：{{'滿足用戶需求': 5, '事實正確性': 10, '回答完備性': 4, '綜合得分': 6}}
2.不存在人工標(biāo)注：此時指令中的“參考答案”為“無”
評分結(jié)果：
    1. 滿足用戶需求:AI助手的答案部分解決了用戶的提問。用戶詢問的是偏遠(yuǎn)地區(qū)發(fā)貨后又取消訂單的情況下運(yùn)費由誰承擔(dān)，AI助手回答了京東處理運(yùn)費糾紛的原則是“誰過錯，誰承擔(dān)”，并提供了一個鏈接供用戶參考。然而，AI助手沒有明確回答在偏遠(yuǎn)地區(qū)發(fā)貨后取消訂單的具體情況，是否由買家或賣家承擔(dān)運(yùn)費。因此，AI助手的回答不完全滿足用戶需求。
    2. 事實正確性:AI助手的答案是從核心語料中提取的，引用了“誰過錯，誰承擔(dān)”的原則，并提供了相關(guān)鏈接。這些信息都準(zhǔn)確無誤，符合核心語料的內(nèi)容。
    3. 回答完備性:AI助手的回答雖然引用了核心語料中的信息，但沒有完全提取所有相關(guān)信息。例如，核心語料中提到的“買賣雙方協(xié)商一致的除外”以及“京東將根據(jù)本標(biāo)準(zhǔn)內(nèi)容進(jìn)行判定，如商家違反運(yùn)費要求或舉證內(nèi)容無效，將判定商家責(zé)任”這些內(nèi)容沒有被提及。這些信息對于用戶理解運(yùn)費糾紛的處理方式是有幫助的。
    綜合評價:AI助手的回答在事實正確性方面表現(xiàn)良好，但在滿足用戶需求和回答完備性方面還有提升空間?？傮w來說，回答質(zhì)量中等。
    綜合評分如下：{{'滿足用戶需求': 6, '事實正確性': 10, '回答完備性': 6, '綜合得分': 7}}

?

2.4 LLM離在線樣本增強(qiáng)技術(shù)

1. 自動化離線樣本生成與擴(kuò)展

?離線接入的標(biāo)準(zhǔn)化語料：通過接入標(biāo)準(zhǔn)化的業(yè)務(wù)數(shù)據(jù)，能夠自動化生成和擴(kuò)展用于LLM訓(xùn)練的樣本，快速適配不同場景訓(xùn)練需求，批量生成高質(zhì)量訓(xùn)練樣本。

2. 自動化在線推理標(biāo)注與樣本積累

?Agent在線推理數(shù)據(jù)：通過多種Reward Model策略，系統(tǒng)能夠?qū)€上推理過程中生成的樣本進(jìn)行持續(xù)的自動化標(biāo)注和積累。這使得樣本庫能夠不斷擴(kuò)展和優(yōu)化，提高模型的在線推理能力。

?

?

?

?

=============

References

?H-MAP planning：Multi-Agent通信協(xié)議?

Step 1. 調(diào)用方發(fā)起調(diào)用請求。Master Agent的調(diào)用方只能是用戶，領(lǐng)域Agent的調(diào)用方可以是Master Agent或其他領(lǐng)域Agent。請求的消息內(nèi)容和格式見4.2中的請求消息體。Step 2. Agent進(jìn)行Planning/Reasoning。Agent應(yīng)用接收到消息請求后,調(diào)用內(nèi)部的Memory管理系統(tǒng)獲取會話歷史信息；Step 3.Reasoning，即生成Thought和Action Code； Thought和Action Code具體含義如下：thought：text. 是指用人類自然語言形式表達(dá)的解題決策過程，即任務(wù)的大目標(biāo)和解決問題需要執(zhí)行的tasks的文字描述。比如：這是一個xxx問題，可以通過先xxx、再xxx來解決。action_code：list of tasks. 是根據(jù)thought生成可供應(yīng)用系統(tǒng)進(jìn)行調(diào)度執(zhí)行的研發(fā)語言，即tasks的結(jié)構(gòu)化描述，支持包含多個tasks的list結(jié)構(gòu)，通常使用采用一個task（即執(zhí)行完一個拿到observation再執(zhí)行下一個）。一個task包含4個核心要素：（1）tool_name: 調(diào)度對象唯一標(biāo)識，領(lǐng)域agent或者待調(diào)用的api的注冊名稱"name"；（2）parameter：工具調(diào)用所需要傳遞的參數(shù)；（3）job_desc：調(diào)用工具的任務(wù)描述，即需要工具來干什么，只對調(diào)用Agent生效，api通常只會使用parameters；（4）trust_mode：對tool調(diào)用完成后，tool輸出observation的處理方式，1代表agent不基于observation進(jìn)行下一輪ReAct、直接進(jìn)入下一個task（通常出現(xiàn)在len(list of tasks) > 1)，0表示需要基于observation更新ReAct。Step 4. Agent執(zhí)行工具調(diào)用Tools call。應(yīng)用解析 Thought和Action code生成請求消息體。如果Action code中包含工具調(diào)用，則執(zhí)行，否則跳過此步。如果要調(diào)用的tool是Agent，調(diào)用時傳遞的請求消息體同上面1；如果要調(diào)用的工具是API，調(diào)用時傳遞的請求消息體見“4.3 API調(diào)用協(xié)議”中的請求消息體。Step 5. 被調(diào)用工具返回結(jié)果。若在上一步?jīng)]有執(zhí)行工具調(diào)用，則跳過此步。工具調(diào)用執(zhí)行完成后，需要把執(zhí)行結(jié)果返回給調(diào)用方。如果被調(diào)用的工具是Agent，那么需要返回的關(guān)鍵信息包含調(diào)用狀態(tài)status和結(jié)果Observation；如果被調(diào)用的工具是API，那么需要返回的關(guān)鍵信息包含調(diào)用狀態(tài)status、observation，具體消息內(nèi)容和格式見“4.3 API調(diào)用協(xié)議”中的響應(yīng)消息體。Step 6. Agent本輪ReAct信息寫入Memory，并同步計入日志系統(tǒng) 。Agent完成一輪ReAct后必須把內(nèi)部reasoning生成的如Thought、Action code、tools call、出入?yún)?、調(diào)用時間等關(guān)鍵信息通過日志接口寫入助手日志系統(tǒng)。見4.4日志系統(tǒng)接口。Step 7. Agent響應(yīng)調(diào)用請求。Agent在完成step 2-6后，根據(jù)step 2生成的trust mode，判定是否向調(diào)用方返回響應(yīng)結(jié)果。若trust mode值為1，則可以把observation返回給調(diào)用方，具體響應(yīng)消息內(nèi)容和格式見4.2的響應(yīng)消息體；若rust mode值為0，則繼續(xù)進(jìn)行下一輪ReAct，重復(fù) step 2-6。

審核編輯 黃宇