Agent應(yīng)用實戰(zhàn)：從廣告智能助手落地到平臺化賦能

前言

自2022年底ChatGPT發(fā)布以來，大模型成為非?；鸨脑掝}。如何在生活和工作中把大模型用的更好、更具價值，業(yè)界一致認(rèn)為Agent是其中一個重要的方向。下面就分享一下我們京東廣告在Agent應(yīng)用上的一些實踐和經(jīng)驗，希望能給大家?guī)硪欢ǖ膯l(fā)和思考。

?

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

?

1、Agent是什么

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

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

?

2、Agent能做什么

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

?

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

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

?

那么，如果我們希望借助大模型來幫我們提效，計劃通過一句話就實現(xiàn)會議室的預(yù)定：我在12層，幫我找個15-16點的會議室，盡量近一點

?

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

?

如果利用Agent的方式，就可以很好的解決這個問題：

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

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

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

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

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

?

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

?

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

?

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

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

首先，介紹一下Agent在廣告投放中的兩個主要的場景：

?

?

3.1、服務(wù)提效

背景

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

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

痛點

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

方案

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

收益

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

?

3.2 盯盤提效

背景

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

痛點

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

方案

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

收益

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

?

?

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

?

接下來就詳細介紹這兩個能力的技術(shù)實現(xiàn)。

?

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

?

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

?

離線知識構(gòu)建

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

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

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

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

4.將向量存儲至京東Vearch向量庫

?

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

?

在線推理引擎

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

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

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

?

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

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

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

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

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

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

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

?

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

?

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

?

知識召回的問題

?

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

?

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

?

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

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

?

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

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

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

?

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

?

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

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

收到請求后，分別通過向量和ES檢索，最大化提升召回率。

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

?

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

?

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

?

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

?

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

?

?

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

?

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

?

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

?

工具能力注冊

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

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

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

2.后端感知的信息：正常情況下，工具的執(zhí)行其實是調(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":"錯誤信息"},
        {"key":"data","type":"string","description":"返回給前端數(shù)據(jù)"}
    ],
    "error":{"msgType":1,"msgKey":"msg","msgContent":""}
}

?

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

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

{
"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":"計劃名稱","key":"campaignName","width":110},{"title":"產(chǎn)品線","key":"businessTypeStr","width":110},{"title":"時間","key":"date","sort":false},{"title":"展現(xiàn)數(shù)","key":"impressions","sort":true}],
        }],
}

?

在線推理引擎

?

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

?

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

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

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

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

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

用戶問題：查一下賬戶還剩多少錢

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

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

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

最終確保能比較完美的回答用戶問題。

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

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

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

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

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

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

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

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

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

?

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

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

?

對于該問題，我們參考了此前做RAG的思路，做法是將工具的基本描述和示例指令，分別存成向量，請求進來時候，使用向量先進行工具的召回，再進行拼接給到模型。

?

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

?

?

3.5 能力的演變

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

?

?

3.6 京東廣告智能助手

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

體驗地址：https://jzt.jd.com（需要商家賬號）

?

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

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

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

模型通常是有訓(xùn)練日期的，無法正確回答日期問題的，對于這個問題，解決的思路是，每次請求模型時，動態(tài)生成幾組日期的說明，讓模型能正確推理時間。

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

?

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

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

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

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

?

?

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

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

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

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

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

?

1、Agent設(shè)計器

?

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

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

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

?

?

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

?

2、Agent引擎

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

?

?

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

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

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

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

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

本來一行代碼就可以搞定，使用Langchain后需要幾十行代碼才能實現(xiàn)，并且?guī)砹艘欢ǖ男阅軗p耗。

?

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

?

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

?

3、端能力

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

?

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

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

?

1、客訴處理

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

?

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

?

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

?

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

?

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

?

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

?

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

?

方案：

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

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

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

3.1 對于產(chǎn)品及運營問題能利用知識庫解答的問題，會直接發(fā)布工單評論，如解決，只需點擊完成即可。提升解決效率。

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

?

?

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

?

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

?

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

?

?

2、Code Review

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

?

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

?

流程自動化

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

大致流程如下：

1、CR Server提供一個通用接口，需要做CR自動化的項目注冊到webHooks中即可

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

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

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

?

?

工作流搭建

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

?

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

?

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

?

?

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

?

?

四、未來展望

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

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

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

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

?

?

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

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

審核編輯 黃宇