引言

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

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

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

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

?

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

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

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

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

?

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

?

?

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

2.2 Multi-Agent Online Inference

2.2.1 技術(shù)特色

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

?Master Agent：在領(lǐng)域?qū)用孢M(jìn)行任務(wù)規(guī)劃，將復(fù)雜場(chǎng)景拆解為多個(gè)獨(dú)立子任務(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é)議：

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

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

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

2.2.2 Multi-Agent Online Inference 演示：

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

?H-MAP_4k.mp4?

?

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

特色：

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

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

迭代快：?jiǎn)栴}定位迅速，模型快速迭代

?

待解決：

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

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

?

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

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

?

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

1.Agent全鏈路ReAct效能綜合評(píng)估

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

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

2.多樣化Reward Model

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

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

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

?

Reward Model-平臺(tái)化AI評(píng)估模型案例說(shuō)明：

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

?

?

?

?

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

References

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

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

審核編輯 黃宇