前言

自2022年底ChatGPT發布以來，大模型成為非?；鸨?a href="http://m.xsypw.cn/v/tag/" target="_blank">話題。如何在生活和工作中把大模型用的更好、更具價值，業界一致認為Agent是其中一個重要的方向。下面就分享一下我們京東廣告在Agent應用上的一些實踐和經驗，希望能給大家帶來一定的啟發和思考。

?

一、Agent 在京東廣告投放中的應用

?

1、Agent是什么

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

Agent是以大語言模型為大腦驅動，具有自主理解感知、規劃、記憶和使用工具的能力，能自動化執行完成復雜任務的系統。

?

2、Agent能做什么

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

?

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

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

?

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

?

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

?

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

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

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

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

4、Agent執行調用，完成后將結果給到大腦繼續思考。

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

?

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

?

如果我們將上面的案例再進行一些擴展，增加會議邀請的工具，那么就實現了一個小型的會議助手Agent。可以幫我們實現幾秒鐘就完成一個現在大約幾分鐘才能完成的事情。

?

3、Agent 在廣告投放中的應用場景

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

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

?

?

3.1、服務提效

背景

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

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

痛點

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

方案

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

收益

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

?

3.2 盯盤提效

背景

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

痛點

查數、物料創建、物料編輯是廣告主最高頻的操作，當前廣告主進行多種操作時需要跳轉多個產品線進行很多步操作才能完成，盯盤效率低。

方案

利用Agent的工具調用能力，為廣告主提供一些智能指令，比如，一句話查詢自定義數據：查詢上個月各產品線的數據。

收益

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

?

?

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

?

接下來就詳細介紹這兩個能力的技術實現。

?

3.3 RAG能力的構建

?

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

?

離線知識構建

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

1.產品/運營將相關業務的知識整理成文檔（Markdown、Excel等）

2.根據不同格式和切割方式將內容切割成若干個內容塊

3.調用embedding model，進行內容向量化

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

?

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

?

在線推理引擎

提供實時在線服務，主要作用是檢索相關知識并調用大模型解決問題。主要幾個步驟，如下：

1.收到用戶Query，調用embedding model，進行向量化，獲得向量

假如，用戶的問題：搜索快車關鍵詞設置

?

2.根據向量，調用Vearch接口，進行知識檢索，獲得和Query相關的知識

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

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

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

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

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

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

?

4.調用大模型接口，傳入拼接好的提示詞，獲取結果返回給用戶。

?

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

?

知識召回的問題

?

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

?

一、我們認為更相關的知識未召回

?

對于【京準通切詞匹配】這個Query，我們認為更相關的內容（搜索快車切詞匹配 n當用戶發起搜索時，根據不同的匹配模式可能展現不同的xxx），相關性不夠無法召回。

向量召回的分數與相關內容密度強相關，理論上密度越高，相關分值越高，下面有個示例更直觀的說明一下。

?

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

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

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

?

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

?

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

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

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

更多ES檢索技術實現細節，請看： 《廣告智能助手Agent混合檢索技術實踐》

?

二、召回部分無關知識影響模型作答效果

?

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

?

這里方案是引入ReRank模型，在知識召回后，調用算法側部署的ReRank服務，對知識進行重排序，過濾無關知識。

?

通過以上多種能力的引入，RAG的能力也逐漸演變為下圖：

?

?

3.4 Function Call 能力的構建

?

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

?

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

?

工具能力注冊

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

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

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

2.后端感知的信息：正常情況下，工具的執行其實是調用了后端的接口，那么就需要接口地址、接口入參、接口出參、成功條件等信息。其中接口的入參和模型感知信息中的參數是同一份數據。

{
    "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":"返回給前端數據"}
    ],
    "error":{"msgType":1,"msgKey":"msg","msgContent":""}
}

?

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

我們為廣告主提供的工具大部分都要用組件進行渲染，比如數據報表。當工具需要和組件結合的時候，需要考慮組件的配置化和復用率，這里我們打通了既有的低代碼平臺，會將組件的信息保存下來。

{
"pageData":[
    {
        "name":"數據表格",
        "componentName":"jad_ReportTable",
        "jsUrl":"jadfe/xxx/ReportTable.6a3493f4.js", //組件CDN地址
        "options":[//組件配置
            {
                "key":"columns",
                "type":"list",
                "name":"列設置",
                "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":"產品線","key":"businessTypeStr","width":110},{"title":"時間","key":"date","sort":false},{"title":"展現數","key":"impressions","sort":true}],
        }],
}

?

在線推理引擎

?

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

?

1.收到用戶Query，從數據庫讀取工具信息

2.將工具組裝成模型需要的格式，組裝Prompt，調用模型

3.如果模型返回Function Call標識，通過標識中的 function name 找出對應的工具，調用該工具的接口

4.根據結果的展示行為，有以下幾種處理方式：

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

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

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

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

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

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

4.2直接返回結果，適用的場景如下

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

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

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

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

用戶問題：查詢今天ROI > 10的計劃數據

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

這種情況，適合用一個表格去更直觀的呈現數據，這就需要返回接口結果同時還要返回相關的組件數據。

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

?

工具調用的問題

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

?

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

?

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

?

?

3.5 能力的演變

將以上各種能力整合，最終能力演變為下圖。這一版底層我們采用了Langchain框架。

?

?

3.6 京東廣告智能助手

基于以上的能力，構建了京東廣告智能助手。包含了問題解答、數據查詢、物料創建、物料編輯等場景。

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

?

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

指令中日期的準確性優化

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

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

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

?

二、基于業務沉淀Agent搭建平臺

以上就是廣告智能助手業務從0到1的過程，可見一個大模型應用真正應用到生產環境中，是比較復雜且有非常大的工作量的，我們在思考，如果廣告內有其他的業務場景，是否能實現一些能力的快速復用？

與此同時，隨著業務效果的優化進入深水區，我們需要通過對工作流程更精細化的編排來進行效果的優化。

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

?

?

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

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

Agent引擎：主要是根據設計器產生的配置，動態運行工作流程，如：知識的召回、提示詞的加工、模型的推理、工具的調用、代碼的執行等等。

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

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

?

1、Agent設計器

?

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

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

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

?

?

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

?

2、Agent引擎

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

?

?

相信做過大模型應用開發的同學，都聽說或者使用過Langchain。

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

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

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

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

本來一行代碼就可以搞定，使用Langchain后需要幾十行代碼才能實現，并且帶來了一定的性能損耗。

?

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

?

整體上，設計了一套工作流調度器，并將所有節點實現了組件化。收到請求后會初始化一個工作流調度器，調度器根據時機來操作每個節點的執行。工作流詳細實現： Agent Workflow技術實現揭秘

?

3、端能力

端能力主要是沉淀了一套AI組件，包括：內容輸入、指令聯想、輸出卡片等組件?？煽焖贅嫿ǘ喽思嫒莸膶υ捠綉?。

?

三、Agent平臺賦能研發提效

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

?

1、客訴處理

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

?

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

?

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

?

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

?

理想的情況是人工客服收到客訴后，提工單給產運研，產運研進行流轉跟進。但是為什么會演變為現狀？

?

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

?

目標：在不增加客服團隊負擔的情況下，提升產運研工作效率和工作體驗，同時提升客訴解決效率。

?

方案：

1、客服只需發送客訴內容給客訴處理Agent，減少客服負擔。

2、Agent通過大模型分析，自動提交工單給相應同學，大幅提升工單流轉效率。

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

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

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

?

?

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

?

核心節點-客訴分析	核心節點-工單提交

?

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

?

?

2、Code Review

Code Review在業界已經有了比較多的實踐，不過，如何把投產比做到符合預期，同時確保代碼的安全，是需要重點關注的。

?

考慮到資源成本，人工復審成本等因素，我們的目標是：流程自動化、采納率優先。

?

流程自動化

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

大致流程如下：

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

2、當發起merge的時候，會調用CR Server接口，CR Server收到請求后，調用Git接口獲取diff

3、處理diff，調用Agent接口，執行Agent平臺搭建的工作流，進行CR

4、處理返回結果，調用Git評論接口，完成CR流程。

?

?

工作流搭建

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

?

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

?

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

?

?

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

?

?

四、未來展望

1、大模型推動行業壁壘逐步降低

大模型將推動更多的方法論實現產品化，通過產品化的形式，將極大提高生產力，降低行業門檻。

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

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

?

?

當然，短時間內大模型并不會替代程序員，但在實際工作中，善于使用大模型的同學在效率上已經有明顯的提升表現。未來一定是更會利用AI的人，更具有先發優勢。

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

審核編輯 黃宇