前言

自2022年底ChatGPT發(fā)布以來(lái)，大模型成為非常火爆的話題。如何在生活和工作中把大模型用的更好、更具價(jià)值，業(yè)界一致認(rèn)為Agent是其中一個(gè)重要的方向。下面就分享一下我們京東廣告在Agent應(yīng)用上的一些實(shí)踐和經(jīng)驗(yàn)，希望能給大家?guī)?lái)一定的啟發(fā)和思考。

?

一、Agent 在京東廣告投放中的應(yīng)用

?

1、Agent是什么

既然是講Agent的應(yīng)用，還是要先來(lái)普及一下基本概念，一句話簡(jiǎn)介：

Agent是以大語(yǔ)言模型為大腦驅(qū)動(dòng)，具有自主理解感知、規(guī)劃、記憶和使用工具的能力，能自動(dòng)化執(zhí)行完成復(fù)雜任務(wù)的系統(tǒng)。

?

2、Agent能做什么

接下來(lái)，用一個(gè)小小的案例來(lái)讓大家更直觀的感受到，Agent和大模型的區(qū)別。

?

舉個(gè)栗子：一個(gè)工作中用到的高頻場(chǎng)景—預(yù)定會(huì)議室，假如今天有個(gè)會(huì)議計(jì)劃在15-16點(diǎn)，需要定個(gè)會(huì)議室。

現(xiàn)有的方式：通常要先打開(kāi)辦公軟件，其次打開(kāi)會(huì)議室預(yù)定應(yīng)用，然后選擇期望的會(huì)議室樓層或區(qū)域、會(huì)議時(shí)間，進(jìn)行篩選，如果找出多個(gè)，再找出離自己最近或者最方便的一個(gè)，進(jìn)行預(yù)定。

?

那么，如果我們希望借助大模型來(lái)幫我們提效，計(jì)劃通過(guò)一句話就實(shí)現(xiàn)會(huì)議室的預(yù)定：我在12層，幫我找個(gè)15-16點(diǎn)的會(huì)議室，盡量近一點(diǎn)

?

如果單純靠大模型是無(wú)法幫我們解決這個(gè)問(wèn)題的，它大概率會(huì)回答：”要找到離你最近的會(huì)議室并了解其可用性，通常需要使用公司內(nèi)部的會(huì)議室預(yù)訂系統(tǒng)或辦公軟件，如Outlook、Google Calendar等。以下是一些建議步驟…“

?

如果利用Agent的方式，就可以很好的解決這個(gè)問(wèn)題：

1、在Agent中，我們有一些工具，其中包括：查找會(huì)議室（可以時(shí)間等條件查詢可用的會(huì)議室）、預(yù)定會(huì)議室（根據(jù)會(huì)議室ID、會(huì)議室時(shí)段等信息預(yù)定會(huì)議室）。

2、當(dāng)Agent收到我們的需求時(shí)，會(huì)先用大腦（大模型）思考，大腦綜合各種信息（歷史的記憶、擁有的工具能力等）進(jìn)行推理并規(guī)劃要做哪些行動(dòng)。

3、大腦告知Agent需要先調(diào)用【查詢會(huì)議室】的工具，并給出調(diào)用參數(shù)（預(yù)定時(shí)段等）。

4、Agent執(zhí)行調(diào)用，完成后將結(jié)果給到大腦繼續(xù)思考。

5、如果有可用的會(huì)議室，大腦會(huì)告知Agent調(diào)用【預(yù)定會(huì)議室】工具，進(jìn)行預(yù)定。否則，會(huì)根據(jù)查詢到的會(huì)議及空閑時(shí)段給出一些可用的建議，如下圖。

?

相信通過(guò)上面這個(gè)案例，大家能更真切的感受到基于大模型的Agent，會(huì)有非常大的想象空間及廣泛的應(yīng)用場(chǎng)景。

?

如果我們將上面的案例再進(jìn)行一些擴(kuò)展，增加會(huì)議邀請(qǐng)的工具，那么就實(shí)現(xiàn)了一個(gè)小型的會(huì)議助手Agent?？梢詭臀覀儗?shí)現(xiàn)幾秒鐘就完成一個(gè)現(xiàn)在大約幾分鐘才能完成的事情。

?

3、Agent 在廣告投放中的應(yīng)用場(chǎng)景

以上，我們對(duì)Agent有了一定的了解，接下來(lái)就介紹一下我們京東廣告投放業(yè)務(wù)在Agent應(yīng)用上的一些實(shí)踐。

首先，介紹一下Agent在廣告投放中的兩個(gè)主要的場(chǎng)景：

?

?

3.1、服務(wù)提效

背景

京準(zhǔn)通作為專業(yè)的廣告投放平臺(tái)，每天有幾十萬(wàn)的京東商家在此進(jìn)行廣告的投放，以獲取更多的C端流量達(dá)成更高的商品銷售量。

如此龐大的商家量級(jí)，在使用過(guò)程中，每天都會(huì)有各類商家的各種各樣的問(wèn)題，之前，所有用戶的問(wèn)題都會(huì)走到人工客服上，人工客服會(huì)根據(jù)產(chǎn)品、運(yùn)營(yíng)提供的一些資料為用戶解答，對(duì)于客服無(wú)法解答的問(wèn)題（如：功能異常、數(shù)據(jù)異常、政策咨詢等），再轉(zhuǎn)給產(chǎn)研側(cè)跟進(jìn)解決。

痛點(diǎn)

這種方式主要的問(wèn)題：1.咨詢高峰，通常需要排隊(duì)等待，問(wèn)題解決效率低，商家體驗(yàn)不好。2.人工客服成本高。

方案

針對(duì)這些問(wèn)題，我們期望利用大模型打造一個(gè)智能客服，由智能客服承接用戶的問(wèn)題，智能客服無(wú)法解答的再轉(zhuǎn)到人工客服，最后對(duì)于棘手的問(wèn)題再轉(zhuǎn)給產(chǎn)研跟進(jìn)。

收益

該方案的主要收益：1.智能客服無(wú)需排隊(duì)，秒級(jí)作答，可明顯提升用戶滿意度。2.可明顯減輕客服壓力，節(jié)省客服成本。

?

3.2 盯盤提效

背景

在廣告投放中，廣告主通常需要?jiǎng)?chuàng)建廣告物料，然后不斷觀察效果數(shù)據(jù)，及時(shí)調(diào)整投放策略，以獲得更好的投放效果，整個(gè)過(guò)程我們稱之為“盯盤”。

痛點(diǎn)

查數(shù)、物料創(chuàng)建、物料編輯是廣告主最高頻的操作，當(dāng)前廣告主進(jìn)行多種操作時(shí)需要跳轉(zhuǎn)多個(gè)產(chǎn)品線進(jìn)行很多步操作才能完成，盯盤效率低。

方案

利用Agent的工具調(diào)用能力，為廣告主提供一些智能指令，比如，一句話查詢自定義數(shù)據(jù)：查詢上個(gè)月各產(chǎn)品線的數(shù)據(jù)。

收益

智能指令的使用將明顯提升廣告主盯盤效率，比如查詢上個(gè)月各產(chǎn)品線的數(shù)據(jù)，在之前，用戶需要跳轉(zhuǎn)多個(gè)界面，進(jìn)行多次操作才能完成，使用智能指令后，僅需一步即可。

?

?

有了大致的思路和方案，基于此前的技術(shù)調(diào)研，我們需要構(gòu)建RAG和Function call能力來(lái)分別支撐智能客服和智能指令。

?

接下來(lái)就詳細(xì)介紹這兩個(gè)能力的技術(shù)實(shí)現(xiàn)。

?

3.3 RAG能力的構(gòu)建

?

RAG模塊主要包含兩部分，分別是：離線知識(shí)構(gòu)建、在線推理引擎。

?

離線知識(shí)構(gòu)建

主要的工作是將知識(shí)轉(zhuǎn)化為向量并存儲(chǔ)。主要幾個(gè)步驟，如下：

1.產(chǎn)品/運(yùn)營(yíng)將相關(guān)業(yè)務(wù)的知識(shí)整理成文檔（Markdown、Excel等）

2.根據(jù)不同格式和切割方式將內(nèi)容切割成若干個(gè)內(nèi)容塊

3.調(diào)用embedding model，進(jìn)行內(nèi)容向量化

4.將向量存儲(chǔ)至京東Vearch向量庫(kù)

?

Embedding模型有很多種，不同模型之間維度不一樣，常見(jiàn)的有1024、1536。向量存儲(chǔ)時(shí)通常要?jiǎng)?chuàng)建表空間，創(chuàng)建時(shí)需要確定維度。所以最好先確定好向量模型再進(jìn)行存儲(chǔ)空間的創(chuàng)建。

?

在線推理引擎

提供實(shí)時(shí)在線服務(wù)，主要作用是檢索相關(guān)知識(shí)并調(diào)用大模型解決問(wèn)題。主要幾個(gè)步驟，如下：

1.收到用戶Query，調(diào)用embedding model，進(jìn)行向量化，獲得向量

假如，用戶的問(wèn)題：搜索快車關(guān)鍵詞設(shè)置

?

2.根據(jù)向量，調(diào)用Vearch接口，進(jìn)行知識(shí)檢索，獲得和Query相關(guān)的知識(shí)

{"docs": [
    {
        "_id": "8684356582637079690", 
        "_score": 0.7526149153709412, 
        "_source": {
            "content": "搜索快車-搜索快車投放要素-定向設(shè)置（關(guān)鍵詞定向、商品定向）-關(guān)鍵詞定向-功能入口 n搜索快車->新增/編輯快車推廣單元->添加關(guān)鍵詞；n- 搜索快車->計(jì)劃->單元->關(guān)鍵詞設(shè)置->添加關(guān)鍵詞。", 
            "status": 1, 
            //更多字段...
        }, 
    }, 
    {
        "_id": "-1119433630625640889", 
        "_score": 0.7362563610076904, 
        "_source": {
            "content": "搜索快車-搜索快車投放要素-定向設(shè)置（關(guān)鍵詞定向、商品定向）-關(guān)鍵詞定向-關(guān)鍵詞投放策略-關(guān)鍵詞批量添加功能（推廣管理模塊）n添加關(guān)鍵詞時(shí)，可在同個(gè)計(jì)劃中選擇不同單元，針對(duì)多個(gè)單元批量添加同批次的關(guān)鍵詞，提升您的買詞效率。", 
            "status": 1, 
            //更多字段...
        }, 
    }, 
    {
        "_id": "-2002741349177277662", 
        "_score": 0.7218812704086304, 
        "_source": {
            "content": "搜索快車-產(chǎn)品操作指南-創(chuàng)建計(jì)劃-普通計(jì)劃-商品推廣-定向設(shè)置-關(guān)鍵詞n添加關(guān)鍵詞：點(diǎn)擊添加關(guān)鍵詞，彈出側(cè)滑框進(jìn)入買詞界面；n- 購(gòu)買關(guān)鍵詞：有以下幾種買詞方式n- 商品推詞：根據(jù)SKU ID，系統(tǒng)自動(dòng)推薦關(guān)鍵詞，可以選擇熱搜詞、潛力詞、撿漏詞；n- 核心拓詞：根據(jù)輸入的關(guān)鍵詞，系統(tǒng)自動(dòng)拓展；n- 手動(dòng)輸入：手動(dòng)一個(gè)個(gè)輸入關(guān)鍵詞；n- 導(dǎo)入關(guān)鍵詞：通過(guò)Excel批量導(dǎo)入；n- 用詞記錄：自動(dòng)識(shí)別單元下歷史購(gòu)買過(guò)的關(guān)鍵詞；", 
            "status": 1, 
            //更多字段...
        }, 
    }
    //更多知識(shí)...
]}

3.拼接提示詞，由于檢索到的結(jié)果是json，要讓模型更方便理解，需要處理成特定的格式

//這里不方便展示業(yè)務(wù)真實(shí)的提示詞，提示詞的書寫格式多種多樣，以下僅提供大致思路

請(qǐng)根據(jù)信息
"""
搜索快車-搜索快車投放要素-定向設(shè)置（關(guān)鍵詞定向、商品定向）-關(guān)鍵詞定向-功能入口
- 搜索快車->新增/編輯快車推廣單元->添加關(guān)鍵詞；
- 搜索快車->計(jì)劃->單元->關(guān)鍵詞設(shè)置->添加關(guān)鍵詞。

搜索快車-搜索快車投放要素-定向設(shè)置（關(guān)鍵詞定向、商品定向）-關(guān)鍵詞定向-關(guān)鍵詞投放策略-關(guān)鍵詞批量添加功能（推廣管理模塊）
添加關(guān)鍵詞時(shí)，可在同個(gè)計(jì)劃中選擇不同單元，針對(duì)多個(gè)單元批量添加同批次的關(guān)鍵詞，提升您的買詞效率。

搜索快車-產(chǎn)品操作指南-創(chuàng)建計(jì)劃-普通計(jì)劃-商品推廣-定向設(shè)置-關(guān)鍵詞
添加關(guān)鍵詞：點(diǎn)擊添加關(guān)鍵詞，彈出側(cè)滑框進(jìn)入買詞界面；
- 購(gòu)買關(guān)鍵詞：有以下幾種買詞方式
- 商品推詞：根據(jù)SKU ID，系統(tǒng)自動(dòng)推薦關(guān)鍵詞，可以選擇熱搜詞、潛力詞、撿漏詞；
- 核心拓詞：根據(jù)輸入的關(guān)鍵詞，系統(tǒng)自動(dòng)拓展；
- 手動(dòng)輸入：手動(dòng)一個(gè)個(gè)輸入關(guān)鍵詞；
- 導(dǎo)入關(guān)鍵詞：通過(guò)Excel批量導(dǎo)入；
- 用詞記錄：自動(dòng)識(shí)別單元下歷史購(gòu)買過(guò)的關(guān)鍵詞；
"""
回答問(wèn)題
"""
搜索快車關(guān)鍵詞設(shè)置
"""

?

4.調(diào)用大模型接口，傳入拼接好的提示詞，獲取結(jié)果返回給用戶。

?

{"output": "在搜索快車中進(jìn)行關(guān)鍵詞設(shè)置的步驟如下：nn1. **添加關(guān)鍵詞**：n   - 進(jìn)入搜索快車 -> 新增/編輯快車推廣單元 -> 添加關(guān)鍵詞；n   - 或者進(jìn)入搜索快車 -> 計(jì)劃 -> 單元 -> 關(guān)鍵詞設(shè)置 -> 添加關(guān)鍵詞。nn2. **購(gòu)買關(guān)鍵詞**：n   - 點(diǎn)擊添加關(guān)鍵詞，彈出側(cè)滑框進(jìn)入買詞界面；n   - 有以下幾種買詞方式：n     - 商品推詞：根據(jù)SKU ID，系統(tǒng)自動(dòng)推薦關(guān)鍵詞，可以選擇熱搜詞、潛力詞、撿漏詞；n     - 核心拓詞：根據(jù)輸入的關(guān)鍵詞，系統(tǒng)自動(dòng)拓展；n     - 手動(dòng)輸入：手動(dòng)一個(gè)個(gè)輸入關(guān)鍵詞；n     - 導(dǎo)入關(guān)鍵詞：通過(guò)Excel批量導(dǎo)入；n     - 用詞記錄：自動(dòng)識(shí)別單元下歷史購(gòu)買過(guò)的關(guān)鍵詞。nn3. **關(guān)鍵詞批量添加**：n   - 在同個(gè)計(jì)劃中選擇不同單元，針對(duì)多個(gè)單元批量添加同批次的關(guān)鍵詞，提升買詞效率。..."}

?

知識(shí)召回的問(wèn)題

?

第一版的RAG能力在實(shí)際應(yīng)用中，遇到兩類問(wèn)題：

?

一、我們認(rèn)為更相關(guān)的知識(shí)未召回

?

對(duì)于【京準(zhǔn)通切詞匹配】這個(gè)Query，我們認(rèn)為更相關(guān)的內(nèi)容（搜索快車切詞匹配 n當(dāng)用戶發(fā)起搜索時(shí)，根據(jù)不同的匹配模式可能展現(xiàn)不同的xxx），相關(guān)性不夠無(wú)法召回。

向量召回的分?jǐn)?shù)與相關(guān)內(nèi)容密度強(qiáng)相關(guān)，理論上密度越高，相關(guān)分值越高，下面有個(gè)示例更直觀的說(shuō)明一下。

?

以上的例子只是為了讓大家更直觀了解向量檢索，實(shí)際中，模型可能并不會(huì)認(rèn)為【京準(zhǔn)通】是獨(dú)立詞。同樣，影響結(jié)果的因素有很多（向量維度、切詞、向量矩陣轉(zhuǎn)換算法、分值算法等），如果要改變模型對(duì)某些特定內(nèi)容的行為，常見(jiàn)的做法是微調(diào)。（后續(xù)再學(xué)習(xí)探討）

通過(guò)以上例子可以看到，提升相關(guān)內(nèi)容密度，也是提升知識(shí)召回率的一種手段，且門檻和實(shí)現(xiàn)成本較低。

我們的方案是：將同一塊知識(shí)，按照【概述+內(nèi)容】分別存兩份向量，在召回階段，按照概述和內(nèi)容分別進(jìn)行召回，然后去重。其中概述內(nèi)容較短，也就意味著密度較高，更容易獲得高的相關(guān)性。

?

還有一種場(chǎng)景，在對(duì)用戶問(wèn)題分析中，發(fā)現(xiàn)有一部分廣告主提出一些【智能計(jì)劃】相關(guān)的問(wèn)題（對(duì)于搜索快車或推薦廣告的智能出價(jià)的計(jì)劃的習(xí)慣性簡(jiǎn)稱），由于廣告投放產(chǎn)品中有一個(gè)叫做智能投放的產(chǎn)品，在知識(shí)召回的時(shí)候大部分召回了智能投放相關(guān)的知識(shí)，導(dǎo)致無(wú)法正確回答此類問(wèn)題。

?

我們方案是新增一路ES檢索，ES分詞時(shí)設(shè)置特定的同義詞、專用詞、否定詞。比如：

同義詞：智能計(jì)劃 => 智能出價(jià)計(jì)劃（解決用戶習(xí)慣的問(wèn)題）、 購(gòu)物觸點(diǎn) => 推薦廣告 京挑客 => 京東聯(lián)盟 （解決產(chǎn)品線升級(jí)改名的問(wèn)題）

收到請(qǐng)求后，分別通過(guò)向量和ES檢索，最大化提升召回率。

更多ES檢索技術(shù)實(shí)現(xiàn)細(xì)節(jié)，請(qǐng)看： 《廣告智能助手Agent混合檢索技術(shù)實(shí)踐》

?

二、召回部分無(wú)關(guān)知識(shí)影響模型作答效果

?

通過(guò)以上一些手段，有效提升了知識(shí)召回率，但是引發(fā)了另一個(gè)問(wèn)題，部分知識(shí)不相關(guān)，會(huì)誤導(dǎo)模型，影響模型作答效果。

?

這里方案是引入ReRank模型，在知識(shí)召回后，調(diào)用算法側(cè)部署的ReRank服務(wù)，對(duì)知識(shí)進(jìn)行重排序，過(guò)濾無(wú)關(guān)知識(shí)。

?

通過(guò)以上多種能力的引入，RAG的能力也逐漸演變?yōu)橄聢D：

?

?

3.4 Function Call 能力的構(gòu)建

?

Function Call的能力主要是為了服務(wù)智能指令，比如：提供一個(gè)計(jì)劃數(shù)據(jù)查詢的工具，當(dāng)用戶發(fā)送【查詢今天ROI > 10 的計(jì)劃】，模型會(huì)返回Function Call標(biāo)識(shí)，包括function name 及 arguments，調(diào)用成功后，用對(duì)應(yīng)的組件渲染出來(lái)報(bào)表。

?

同樣包含兩部分，分別是：工具能力注冊(cè)、在線推理引擎。

?

工具能力注冊(cè)

該模塊主要工作是將工具的信息管理起來(lái)，主要包含三部分信息，分別是：

1.模型感知的信息：主要作用是給模型做推理，名稱、參數(shù)、描述，為了讓模型推理更準(zhǔn)確，描述的內(nèi)容我們做了拆分，由基本描述、擴(kuò)展描述、示例指令幾部分組成，下面是一個(gè)工具給模型的信息示例：

{
    "type": "function", 
    "function": {
        "name": "query_xxxx_data" //名稱
        "description": 
            "根據(jù)ROI、時(shí)間....查詢廣告計(jì)劃數(shù)據(jù)" + //基本描述
            "這是一個(gè)查詢計(jì)劃數(shù)據(jù)的工具，可以根據(jù)..." + //擴(kuò)展描述
            "示例指令：n- 查詢今天ROI > 10的計(jì)劃數(shù)據(jù)n -查詢上周..." //示例指令
        "parameters": { //參數(shù)
            "type":"object",
            "properties":{
                "startTime":{
                    "type":"string",
                    "description":"開(kāi)始時(shí)間，格式y(tǒng)yyy-mm-dd"
                },
                "endTime":{
                    "type":"string",
                    "description":"結(jié)束時(shí)間，格式y(tǒng)yyy-mm-dd"
                },
                "roi":{
                    "type":"string",
                    "description":"ROI（投產(chǎn)比）查詢條件，如：“ge|3”代表大于等于3。gt-大于，lt-小于，eq-等于，ge-大于等于，le-小于等于"
                },
                "cost":{
                    "type":"string",
                    "description":"消耗（花費(fèi)）查詢條件，如："lt|500"代表小于500。gt-大于，lt-小于，eq-等于，ge-大于等于，le-小于等于"
                }
            }
        }
    }
}

2.后端感知的信息：正常情況下，工具的執(zhí)行其實(shí)是調(diào)用了后端的接口，那么就需要接口地址、接口入?yún)?、接口出參、成功條件等信息。其中接口的入?yún)⒑湍Ｐ透兄畔⒅械膮?shù)是同一份數(shù)據(jù)。

{
    "url": "http://xxx.jd.local/xxx", //接口地址
    "success":{//成功條件
        "condition":{
            "from":"code",
            "operator":1,
            "target":1
        },
        "data":"data"
    },
    "params":[//出參
        {"key":"code","type":"integer","description":"code碼"},
        {"key":"msg","type":"string","description":"錯(cuò)誤信息"},
        {"key":"data","type":"string","description":"返回給前端數(shù)據(jù)"}
    ],
    "error":{"msgType":1,"msgKey":"msg","msgContent":""}
}

?

3.前端感知的信息：工具調(diào)用成功后，通常有多種處理方式：1.把結(jié)果直接返回給用戶。2.把結(jié)果給到模型，模型繼續(xù)做推理，同時(shí)可以再定義Prompt。3.將結(jié)果使用組件渲染給用戶。

我們?yōu)閺V告主提供的工具大部分都要用組件進(jìn)行渲染，比如數(shù)據(jù)報(bào)表。當(dāng)工具需要和組件結(jié)合的時(shí)候，需要考慮組件的配置化和復(fù)用率，這里我們打通了既有的低代碼平臺(tái)，會(huì)將組件的信息保存下來(lái)。

{
"pageData":[
    {
        "name":"數(shù)據(jù)表格",
        "componentName":"jad_ReportTable",
        "jsUrl":"jadfe/xxx/ReportTable.6a3493f4.js", //組件CDN地址
        "options":[//組件配置
            {
                "key":"columns",
                "type":"list",
                "name":"列設(shè)置",
                "options":[{"key":"title","name":"列名稱","type":"input"},{"key":"key","name":"字段key","type":"input"},{"key":"width","name":"寬度","type":"inputNumber"},{"key":"sort","name":"排序","type":"switch"}],
                "value":[{"title":"計(jì)劃名稱","key":"campaignName","width":110},{"title":"產(chǎn)品線","key":"businessTypeStr","width":110},{"title":"時(shí)間","key":"date","sort":false},{"title":"展現(xiàn)數(shù)","key":"impressions","sort":true}],
        }],
}

?

在線推理引擎

?

提供實(shí)時(shí)在線服務(wù)，主要作用是組裝工具信息調(diào)用大模型進(jìn)行推理。主要幾個(gè)步驟，如下：

?

1.收到用戶Query，從數(shù)據(jù)庫(kù)讀取工具信息

2.將工具組裝成模型需要的格式，組裝Prompt，調(diào)用模型

3.如果模型返回Function Call標(biāo)識(shí)，通過(guò)標(biāo)識(shí)中的 function name 找出對(duì)應(yīng)的工具，調(diào)用該工具的接口

4.根據(jù)結(jié)果的展示行為，有以下幾種處理方式：

4.1給到模型繼續(xù)作答，同時(shí)可自定義Prompt，適用的場(chǎng)景如下

用戶問(wèn)題：查一下賬戶還剩多少錢

接口結(jié)果：{"data": {award: 20, cash: 100}, msg: ""}

顯然，直接把json中data的結(jié)果給到用戶，是不合理的。
這個(gè)時(shí)候就適合給到模型去作答，但是模型不理解award和cash在系統(tǒng)中表達(dá)的意思，會(huì)按照自己的理解去作答，如下：
賬戶中有兩種形式的余額：獎(jiǎng)勵(lì)余額：20  現(xiàn)金余額：100

但實(shí)際award在系統(tǒng)可能意思是紅包余額，這個(gè)時(shí)候就需要額外定義Prompt：
award代表：紅包余額，cash代表：現(xiàn)金余額，單位：元

最終確保能比較完美的回答用戶問(wèn)題。

4.2直接返回結(jié)果，適用的場(chǎng)景如下

用戶問(wèn)題：這個(gè)優(yōu)惠券：742382343 為什么不生效，SKU 123456789

接口結(jié)果：{"data": "未生效的原因是xxx"}

這種情況下，適合直接將data字段反給用戶。

4.3返回結(jié)果并需要用前端組件渲染，適用的場(chǎng)景如下

用戶問(wèn)題：查詢今天ROI > 10的計(jì)劃數(shù)據(jù)

接口結(jié)果：{"data": [{"id": 123, "campaignName": "計(jì)劃-A", "ROI": 12.85},{"id": 456, "campaignName": "計(jì)劃-B", "ROI": 10.25}]}

這種情況，適合用一個(gè)表格去更直觀的呈現(xiàn)數(shù)據(jù)，這就需要返回接口結(jié)果同時(shí)還要返回相關(guān)的組件數(shù)據(jù)。

5.前端將返回的內(nèi)容展示給用戶，如需要組件，動(dòng)態(tài)加載組件的CDN地址，完成渲染。

?

工具調(diào)用的問(wèn)題

廣告投放業(yè)務(wù)場(chǎng)景多，如果要給用戶提供完整或精細(xì)化的盯盤能力，勢(shì)必需要提供多種多樣的工具，那基于以上的工作流程，會(huì)有個(gè)問(wèn)題：每次請(qǐng)求都把所有工具給模型，當(dāng)工具比較多時(shí)，可能會(huì)超出模型Token限制，其次，如果是收費(fèi)的商業(yè)模型還會(huì)造成一定的費(fèi)用的浪費(fèi)。

?

對(duì)于該問(wèn)題，我們參考了此前做RAG的思路，做法是將工具的基本描述和示例指令，分別存成向量，請(qǐng)求進(jìn)來(lái)時(shí)候，使用向量先進(jìn)行工具的召回，再進(jìn)行拼接給到模型。

?

這樣能明顯減少給模型無(wú)效工具的輸入，節(jié)省了Token和費(fèi)用，也可以有效減少模型的幻覺(jué)幾率。

?

?

3.5 能力的演變

將以上各種能力整合，最終能力演變?yōu)橄聢D。這一版底層我們采用了Langchain框架。

?

?

3.6 京東廣告智能助手

基于以上的能力，構(gòu)建了京東廣告智能助手。包含了問(wèn)題解答、數(shù)據(jù)查詢、物料創(chuàng)建、物料編輯等場(chǎng)景。

體驗(yàn)地址：https://jzt.jd.com（需要商家賬號(hào)）

?

在支撐廣告智能助手落地中，除了以上一些核心能力的構(gòu)建，也有很多細(xì)節(jié)的優(yōu)化，比如：

指令中日期的準(zhǔn)確性優(yōu)化

查數(shù)指令中常見(jiàn)的一些日期，如：今天、昨天、上個(gè)月、本月、近七天等，需要推理出正確的日期范圍，才能確保數(shù)據(jù)的準(zhǔn)確。

模型通常是有訓(xùn)練日期的，無(wú)法正確回答日期問(wèn)題的，對(duì)于這個(gè)問(wèn)題，解決的思路是，每次請(qǐng)求模型時(shí)，動(dòng)態(tài)生成幾組日期的說(shuō)明，讓模型能正確推理時(shí)間。

如：今天是2024-11-xx，近七天的日期范圍是2024-11-xx~2024-11-xx...

?

二、基于業(yè)務(wù)沉淀Agent搭建平臺(tái)

以上就是廣告智能助手業(yè)務(wù)從0到1的過(guò)程，可見(jiàn)一個(gè)大模型應(yīng)用真正應(yīng)用到生產(chǎn)環(huán)境中，是比較復(fù)雜且有非常大的工作量的，我們?cè)谒伎?，如果廣告內(nèi)有其他的業(yè)務(wù)場(chǎng)景，是否能實(shí)現(xiàn)一些能力的快速?gòu)?fù)用？

與此同時(shí)，隨著業(yè)務(wù)效果的優(yōu)化進(jìn)入深水區(qū)，我們需要通過(guò)對(duì)工作流程更精細(xì)化的編排來(lái)進(jìn)行效果的優(yōu)化。

綜合以上考慮，我們決定將已有的能力增強(qiáng)并沉淀一個(gè)Agent搭建平臺(tái)，以下是整體架構(gòu)。

?

?

基建：主要是公司的基建，提供一些基礎(chǔ)能力，如：向量庫(kù)、ES、OSS、Mysql、CDN等等

Agent設(shè)計(jì)器：主要是提供Agent可視化的設(shè)計(jì)能力，包括智能體、知識(shí)庫(kù)、工具庫(kù)、記憶庫(kù)、工作流等核心功能。

Agent引擎：主要是根據(jù)設(shè)計(jì)器產(chǎn)生的配置，動(dòng)態(tài)運(yùn)行工作流程，如：知識(shí)的召回、提示詞的加工、模型的推理、工具的調(diào)用、代碼的執(zhí)行等等。

端能力：主要是面向用戶的對(duì)話式組件，這里我們沉淀了一套AI組件庫(kù)，可快速組裝出兼容PC、H5的對(duì)話框。與此同時(shí)，針對(duì)內(nèi)部的京ME辦公場(chǎng)景，對(duì)外如微信中的場(chǎng)景，我們也通過(guò)API調(diào)用的方式進(jìn)行了支持。

應(yīng)用場(chǎng)景：有這些能力，就可以輕松的利用平臺(tái)支撐起各種Agent應(yīng)用，包括我們的廣告智能助手。同時(shí)除了業(yè)務(wù)之外，還可以做內(nèi)部提效的Agent應(yīng)用。

?

1、Agent設(shè)計(jì)器

?

團(tuán)隊(duì)空間為了方便協(xié)作和做業(yè)務(wù)隔離，團(tuán)隊(duì)空間下，可以進(jìn)行智能體的搭建、知識(shí)庫(kù)的管理、工具庫(kù)的管理、工作流的編排等等。

知識(shí)庫(kù)中，可以選擇不同的向量模型，方便做召回優(yōu)化的實(shí)驗(yàn)。

工具中，可以設(shè)置模型感知信息、接口、參數(shù)、組件等。

?

?

工作流中，可以隨意拖拽編排工作流程，比如：召回節(jié)點(diǎn)可以設(shè)置召回策略、召回?cái)?shù)量、最低分值等；大模型節(jié)點(diǎn)可以設(shè)置System、User提示詞、歷史會(huì)話輪數(shù)等。

?

2、Agent引擎

Agent引擎負(fù)責(zé)和模型交互，是影響效果和性能的核心模塊。我們做了重點(diǎn)的設(shè)計(jì)和重構(gòu)。在設(shè)計(jì)階段，我們考慮的首要問(wèn)題是：Langchain的取舍。

?

?

相信做過(guò)大模型應(yīng)用開(kāi)發(fā)的同學(xué)，都聽(tīng)說(shuō)或者使用過(guò)Langchain。

Langchain框架提出了LCEL語(yǔ)法，將Prompt、LLM、Tool等概念進(jìn)行了抽象并高度封裝，能快速上手并實(shí)現(xiàn)一些Demo，對(duì)新手比較友好。

然而，隨著業(yè)務(wù)的復(fù)雜度不斷增加，以及對(duì)模型的了解不斷深入，會(huì)發(fā)現(xiàn)，Langchain的過(guò)度封裝，把很多簡(jiǎn)單的事情變的更復(fù)雜了，明顯影響了業(yè)務(wù)自由度及開(kāi)發(fā)效率，同時(shí)也帶來(lái)了一定的性能損耗。舉個(gè)例子：

工具調(diào)用中，模型接受的參數(shù)是一個(gè)JSON Schema，我們只要將工具參數(shù)存成一個(gè)json用的時(shí)候就會(huì)非常方便。

然而，如果使用Langchain，就需要先將json轉(zhuǎn)成一個(gè)pydantic類，再使用Tool類進(jìn)行工具的注冊(cè)，在調(diào)用模型時(shí)，Langchain又會(huì)轉(zhuǎn)換成json。

本來(lái)一行代碼就可以搞定，使用Langchain后需要幾十行代碼才能實(shí)現(xiàn)，并且?guī)?lái)了一定的性能損耗。

?

最終，我們決定移除Langchain框架，直接用原生python實(shí)現(xiàn)，僅保留個(gè)別用起來(lái)比較方便的工具，如：文檔切割。

?

整體上，設(shè)計(jì)了一套工作流調(diào)度器，并將所有節(jié)點(diǎn)實(shí)現(xiàn)了組件化。收到請(qǐng)求后會(huì)初始化一個(gè)工作流調(diào)度器，調(diào)度器根據(jù)時(shí)機(jī)來(lái)操作每個(gè)節(jié)點(diǎn)的執(zhí)行。工作流詳細(xì)實(shí)現(xiàn)： Agent Workflow技術(shù)實(shí)現(xiàn)揭秘

?

3、端能力

端能力主要是沉淀了一套AI組件，包括：內(nèi)容輸入、指令聯(lián)想、輸出卡片等組件?？煽焖贅?gòu)建多端兼容的對(duì)話式應(yīng)用。

?

三、Agent平臺(tái)賦能研發(fā)提效

有了Agent搭建平臺(tái)，可以分鐘級(jí)搭建大模型應(yīng)用，同時(shí)，工作流的能力也大幅加速了策略迭代速度。在廣告智能助手業(yè)務(wù)中，也進(jìn)行了多項(xiàng)策略的優(yōu)化并應(yīng)用在大促中，帶來(lái)了不錯(cuò)的效果提升。同時(shí)，我們也基于Agent平臺(tái)做了一些研發(fā)提效的實(shí)踐。

?

1、客訴處理

前面提到，在京準(zhǔn)通中商家的部分問(wèn)題接入人工客服后，客服側(cè)無(wú)法解答的問(wèn)題會(huì)流轉(zhuǎn)給產(chǎn)運(yùn)研來(lái)跟進(jìn)。

?

客訴的處理時(shí)效會(huì)直接影響客戶滿意度，也會(huì)間接影響商家在投放廣告時(shí)各平臺(tái)間的預(yù)算分配，至關(guān)重要。因此，對(duì)于客訴的處理需要響應(yīng)及時(shí)、快速解決。

?

現(xiàn)狀：當(dāng)前，為了盡量提升處理時(shí)效，產(chǎn)運(yùn)研和客服在一個(gè)約400人的咚咚群里，客服發(fā)出問(wèn)題后，產(chǎn)運(yùn)研團(tuán)隊(duì)看是誰(shuí)的問(wèn)題，分別進(jìn)行跟進(jìn)。

?

痛點(diǎn)：所有人需要花較大精力聚焦于客訴群，只要有消息就要點(diǎn)進(jìn)去看一眼，是不是自己的問(wèn)題，要不要跟進(jìn)。研發(fā)變相成了客服的客服，工作體驗(yàn)較差，明顯影響工作效率。

?

理想的情況是人工客服收到客訴后，提工單給產(chǎn)運(yùn)研，產(chǎn)運(yùn)研進(jìn)行流轉(zhuǎn)跟進(jìn)。但是為什么會(huì)演變?yōu)楝F(xiàn)狀？

?

根本原因：提工單，對(duì)客服團(tuán)隊(duì)會(huì)有一定的負(fù)擔(dān)，首先，客服提工單，需要了解每個(gè)問(wèn)題屬于哪類問(wèn)題，每類問(wèn)題應(yīng)該提給誰(shuí)，加上客服團(tuán)隊(duì)人員變更，新人來(lái)了，都要學(xué)習(xí)一套提工單的流程，還是有不小的成本的。其次，對(duì)于客服團(tuán)隊(duì)來(lái)說(shuō)，有時(shí)候溝通一個(gè)工單的提交過(guò)程就需要花一定的時(shí)間，會(huì)直接影響客訴處理時(shí)長(zhǎng)。

?

目標(biāo)：在不增加客服團(tuán)隊(duì)負(fù)擔(dān)的情況下，提升產(chǎn)運(yùn)研工作效率和工作體驗(yàn)，同時(shí)提升客訴解決效率。

?

方案：

1、客服只需發(fā)送客訴內(nèi)容給客訴處理Agent，減少客服負(fù)擔(dān)。

2、Agent通過(guò)大模型分析，自動(dòng)提交工單給相應(yīng)同學(xué)，大幅提升工單流轉(zhuǎn)效率。

3、Agent通過(guò)對(duì)客訴分析，部分客訴實(shí)現(xiàn)自動(dòng)化解決，提升解決效率，減少研發(fā)投入。

3.1 對(duì)于產(chǎn)品及運(yùn)營(yíng)問(wèn)題能利用知識(shí)庫(kù)解答的問(wèn)題，會(huì)直接發(fā)布工單評(píng)論，如解決，只需點(diǎn)擊完成即可。提升解決效率。

3.2 對(duì)于研發(fā)問(wèn)題，會(huì)識(shí)別是否可以用自動(dòng)化排查工具，可以的話執(zhí)行自動(dòng)化排查并給出答案，發(fā)布工單評(píng)論，如解決，只需點(diǎn)擊完成即可。否則研發(fā)介入排查。

?

?

有了方案，我們借助Agent平臺(tái)能力搭建了客訴處理Agent，以下是主要的工作流程

?

核心節(jié)點(diǎn)-客訴分析	核心節(jié)點(diǎn)-工單提交

?

成果：通過(guò)搭建的客訴處理Agent，目前已經(jīng)可以實(shí)現(xiàn)根據(jù)客訴內(nèi)容自動(dòng)化提交工單。自動(dòng)化解決方面在逐步完善知識(shí)庫(kù)、排查工具的建設(shè)，后續(xù)將帶來(lái)更明顯的收益。

?

?

2、Code Review

Code Review在業(yè)界已經(jīng)有了比較多的實(shí)踐，不過(guò)，如何把投產(chǎn)比做到符合預(yù)期，同時(shí)確保代碼的安全，是需要重點(diǎn)關(guān)注的。

?

考慮到資源成本，人工復(fù)審成本等因素，我們的目標(biāo)是：流程自動(dòng)化、采納率優(yōu)先。

?

流程自動(dòng)化

主要是借助Git的webHooks及接口實(shí)現(xiàn)全流程的自動(dòng)化。

大致流程如下：

1、CR Server提供一個(gè)通用接口，需要做CR自動(dòng)化的項(xiàng)目注冊(cè)到webHooks中即可

2、當(dāng)發(fā)起merge的時(shí)候，會(huì)調(diào)用CR Server接口，CR Server收到請(qǐng)求后，調(diào)用Git接口獲取diff

3、處理diff，調(diào)用Agent接口，執(zhí)行Agent平臺(tái)搭建的工作流，進(jìn)行CR

4、處理返回結(jié)果，調(diào)用Git評(píng)論接口，完成CR流程。

?

?

工作流搭建

工作流搭建的過(guò)程中，我們也進(jìn)行了一些提示詞優(yōu)化的過(guò)程，通過(guò)在提示詞中增加few shot的方式，可明顯提升結(jié)果的可用率。

?

其中，few shot的內(nèi)容是我們通過(guò)日常review積累的一些案例，這些案例包含了9種類型，共40+個(gè)，如果都輸入給模型，會(huì)帶來(lái)其他問(wèn)題：1、提示詞內(nèi)容過(guò)長(zhǎng)，模型容易產(chǎn)生幻覺(jué)。 2、內(nèi)容過(guò)長(zhǎng)，可能會(huì)觸發(fā)輸入輸出限制。

?

針對(duì)這個(gè)問(wèn)題，我們的思路是按照類型拆分，每個(gè)模型節(jié)點(diǎn)只負(fù)責(zé)一種錯(cuò)誤類型的查找。

?

?

通過(guò)以上的方式，可以最大限度的減少請(qǐng)求失敗的概率，同時(shí)由于讓模型做的事情更聚焦，能產(chǎn)出更有價(jià)值的結(jié)果。

?

?

四、未來(lái)展望

1、大模型推動(dòng)行業(yè)壁壘逐步降低

大模型將推動(dòng)更多的方法論實(shí)現(xiàn)產(chǎn)品化，通過(guò)產(chǎn)品化的形式，將極大提高生產(chǎn)力，降低行業(yè)門檻。

比如，拿程序員這個(gè)行業(yè)來(lái)說(shuō)，之前或者現(xiàn)在的門檻還是比較高的，未來(lái)，隨著代碼模型微調(diào)、無(wú)代碼設(shè)計(jì)等方法論的沉淀，可能會(huì)出現(xiàn)一種非常容易上手的產(chǎn)品，只需要導(dǎo)入代碼庫(kù)、設(shè)計(jì)文檔等內(nèi)容，就能開(kāi)始通過(guò)對(duì)話式的方式完成功能的開(kāi)發(fā)。極大降低了軟件開(kāi)發(fā)的門檻，這樣，只要會(huì)使用AI的人就能輕松達(dá)到熟練級(jí)別。

同時(shí)，有了大模型的加持，可以讓部分人進(jìn)入到精通或者專家的行列中。

?

?

當(dāng)然，短時(shí)間內(nèi)大模型并不會(huì)替代程序員，但在實(shí)際工作中，善于使用大模型的同學(xué)在效率上已經(jīng)有明顯的提升表現(xiàn)。未來(lái)一定是更會(huì)利用AI的人，更具有先發(fā)優(yōu)勢(shì)。

同時(shí)，通過(guò)以上的思考，后續(xù)我們也會(huì)在Agent平臺(tái)中將更多的方法論進(jìn)行沉淀。下一步，我們會(huì)嘗試如何將模型的微調(diào)，形成產(chǎn)品化，讓更多非算法人員也能輕松的調(diào)教自己的模型，當(dāng)然這其中有很多的困難需要克服，總之，道阻且長(zhǎng)，行則將至！

審核編輯 黃宇