作者:京東物流 趙勇萍
前言
最近隨著manus的火爆, 其實(shí)大家更關(guān)注AI-Agent的開發(fā)技術(shù)了.畢竟大模型是大腦, 而Ai-Agent才是給最強(qiáng)大腦重塑真身的那個(gè)蓮藕. 而我也這多半年的時(shí)間里, 研究了很多AI-Agent框架. 而在AI-Agent開發(fā)中, 其實(shí)也發(fā)現(xiàn)了一些技巧,思路和架構(gòu)思考. 比如, 我們?nèi)绾胃玫母鶯LM進(jìn)行交流? 如何可以更好的優(yōu)化我們的prompt和token數(shù)量? 如何能讓LLM更快的返回我們想要的思考結(jié)果? 基于這些問題,我們一點(diǎn)點(diǎn)的展開討論。
?
一. 不要讓“大塊頭”嚇倒你:拆分才是王道
還記得我們第一次寫代碼的情景嗎?那時(shí)候,我們可能會(huì)寫出一個(gè)上百行的main方法,恨不得把所有邏輯都塞進(jìn)去。結(jié)果調(diào)試起來頭昏腦漲,連自己都看不懂寫的是什么。從那時(shí)起,我們就明白了一個(gè)道理:復(fù)雜的邏輯需要拆分成更小的部分。將代碼分成多個(gè)方法、類和模塊,不僅讓代碼更易讀、易維護(hù),也更容易調(diào)試和測(cè)試。
其實(shí),在AI-Agent的開發(fā)中,這個(gè)原則同樣適用,甚至更加重要。因?yàn)榇竽P偷哪芰﹄m然強(qiáng)大,但如果我們不加以限制和合理利用,反而會(huì)適得其反。
很多人覺得,既然LLM(大型語(yǔ)言模型)這么智能,那我就把所有可能的指令都塞進(jìn)系統(tǒng)提示詞里(System Prompt),讓它自己處理所有情況。結(jié)果呢?模型懵了,該執(zhí)行的不執(zhí)行,不該執(zhí)行的到處亂跑,輸出的結(jié)果讓人哭笑不得.
?
為什么會(huì)這樣?
當(dāng)我們?cè)谙到y(tǒng)提示詞中堆砌太多內(nèi)容時(shí),會(huì)出現(xiàn)以下問題:
1.信息過載:模型需要處理的信息量過大,可能會(huì)忽略其中一些指令。
2.指令沖突:不同指令之間可能存在矛盾,導(dǎo)致模型無法判斷優(yōu)先級(jí)。
3.上下文混亂:提示詞過長(zhǎng),模型可能會(huì)混淆指令之間的關(guān)系,理解出現(xiàn)偏差。
4.令牌限制:過長(zhǎng)的提示詞會(huì)占用大量的令牌(Tokens),增加成本和響應(yīng)時(shí)間。
想象一下,你在超市里拿著一長(zhǎng)串購(gòu)物清單,上面還有各種刪改和備注,例如:
?牛奶(脫脂,如果沒有就買全脂)
?雞蛋(有機(jī)的,12個(gè)裝,如果有促銷買24個(gè))
?面包(全麥,不要買白面包,除非打折)
是不是覺得頭暈眼花?一不小心就可能買錯(cuò)。
模型也是一樣的,當(dāng)提示詞過于繁雜時(shí),它可能會(huì):
?忽略重要指令:只關(guān)注最顯眼或最前面的指令,忽略后面的。
?誤解指令:因?yàn)樾畔⒘刻螅瑢?dǎo)致對(duì)指令的理解出現(xiàn)偏差。
?產(chǎn)生沖突行為:不知道該遵循哪個(gè)指令,導(dǎo)致輸出混亂。
?
舉個(gè)栗子
下面我可能舉個(gè)實(shí)際例子會(huì)更好理解一下:
場(chǎng)景
一位開發(fā)者希望構(gòu)建一個(gè)智能客服機(jī)器人,能夠處理各種用戶需求。他在系統(tǒng)提示詞中加入了大量的指令"
你是一個(gè)客服機(jī)器人,需要以友好和專業(yè)的態(tài)度與用戶交流。首先,向用戶問好。如果用戶提出技術(shù)問題,提供詳細(xì)的解決方案。 如果用戶抱怨,請(qǐng)安撫他們的情緒,并提供折扣券。如果用戶詢問商品信息,提供最新的商品詳情和價(jià)格。 如果用戶要求與人工客服對(duì)話,禮貌地詢問他們的具體需求,并嘗試解決問題。 所有回應(yīng)必須簡(jiǎn)潔明了,同時(shí)體現(xiàn)個(gè)性化和溫暖。
問題
這個(gè)提示詞看似全面,但實(shí)際上過于復(fù)雜,可能導(dǎo)致模型無法正確執(zhí)行。例如:
?模型可能無法識(shí)別用戶是抱怨還是詢問產(chǎn)品,導(dǎo)致回應(yīng)不準(zhǔn)確。
?由于指令太多,模型可能忽略了關(guān)鍵的服務(wù)流程。
解決方案
首先, 需要簡(jiǎn)系統(tǒng)提示詞, 只需要將模型的基本角色和行為描述清楚即可, 避免過多的細(xì)節(jié).例如:
你是一個(gè)客服機(jī)器人,負(fù)責(zé)幫助用戶解決問題,以專業(yè)和友好的態(tài)度與用戶交流。
其次, 需要上下文的動(dòng)態(tài)添加指令.我們以langchain4J的框架為例, 可以將這些指令通過封裝多個(gè)AI Service實(shí)現(xiàn), 然后串并聯(lián)這些模塊,實(shí)現(xiàn)整體的業(yè)務(wù)需求, 這里一般引入一個(gè)業(yè)務(wù)編排框架會(huì)使得架構(gòu)更清晰, 比如liteflow這種.
然后回歸這個(gè)案例, 我們可以如下拆分指令:
? 如果檢測(cè)到用戶在抱怨或情緒激動(dòng),添加安撫情緒的指令。
?如果用戶提出技術(shù)問題,添加提供解決方案的指令。
?如果用戶詢問商品信息,添加提供商品詳情的指令。
最后, 在這種業(yè)務(wù)場(chǎng)景下,我們可以引入一個(gè)中間層(如意圖識(shí)別模塊),先對(duì)用戶的輸入進(jìn)行分析,然后根據(jù)分析結(jié)果決定模型需要執(zhí)行的操作。
比如如下代碼: 我們封裝一個(gè)用戶意圖識(shí)別的AI Service, 先讓大模型判斷客戶的意圖, 然后決定下里該執(zhí)行哪個(gè)指令.
public enum UserIntentEnum { @Description("問候語(yǔ), 例如:你好|您好|嗨|早上好|晚上好") GREETING, @Description("技術(shù)問題, 例如:技術(shù)問題|無法使用|出錯(cuò)|故障") TECHNICAL_ISSUE, @Description("客戶抱怨評(píng)價(jià), 例如:差評(píng)|不好用|生氣|投訴|抱怨") COMPLAINT, @Description("客戶商品咨詢, 例如:價(jià)格|多少錢|商品信息|詳情") PRODUCT_INQUIRY, @Description("客戶想轉(zhuǎn)人工, 例如:人工客服|真人") REQUEST_HUMAN } interface UserIntent { @UserMessage("Analyze the priority of the following issue? Text: {{it}}") UserIntentEnum analyzeUserIntent(String text); }
基于以上的不同場(chǎng)景, 封裝對(duì)應(yīng)的AI-Service, 然后通過liteflow這種業(yè)務(wù)編排工具串聯(lián)起來即可.
其實(shí)大家有沒有發(fā)現(xiàn), 這種實(shí)現(xiàn)方式,就是prompt開發(fā)中, 大家經(jīng)常提到的思維鏈/思維樹架構(gòu)模式.
?
二. 工具和上下文,不是越多越好
在構(gòu)建智能對(duì)話系統(tǒng)時(shí),開發(fā)者常常希望模型能夠具備盡可能多的功能和信息。他們可能會(huì)認(rèn)為,為模型提供更多的工具和更豐富的上下文,模型就能表現(xiàn)得更出色。然而,事實(shí)并非如此。過多的工具和上下文不僅不會(huì)提升模型性能,反而可能導(dǎo)致一系列問題,如成本飆升、響應(yīng)速度變慢,甚至模型產(chǎn)生幻覺(hallucination)。因此,我們需要理性地看待工具和上下文的使用,避免陷入“越多越好”的誤區(qū).
Fuction Call工具, 避免模型“消化不良”
現(xiàn)代大型語(yǔ)言模型(LLM)的**函數(shù)調(diào)用(Function Call)**功能,為我們?cè)诹奶鞕C(jī)器人中集成各種工具提供了可能。通過這種功能,模型可以調(diào)用外部API、數(shù)據(jù)庫(kù)查詢、計(jì)算器等,實(shí)現(xiàn)復(fù)雜的任務(wù)處理。這聽起來令人興奮,許多開發(fā)者也因此產(chǎn)生了“我有這么多工具,干脆都給模型用吧!”的想法。
然而,這種貪多求全的做法可能會(huì)導(dǎo)致模型的“消化不良”。具體來說,過多的工具會(huì)引發(fā)以下問題:
1.成本飆升:每增加一個(gè)工具,都會(huì)增加對(duì)話的復(fù)雜性。模型需要在生成回復(fù)時(shí)考慮更多的可能性,這會(huì)消耗更多的計(jì)算資源和令牌(tokens),直接導(dǎo)致使用成本的增加。
2.模型產(chǎn)生幻覺(Hallucination):當(dāng)模型被賦予過多的工具時(shí),它可能無法正確識(shí)別何時(shí)調(diào)用哪些工具,進(jìn)而在不適當(dāng)?shù)那闆r下調(diào)用錯(cuò)誤的工具。
3.用戶體驗(yàn)受損:模型的不當(dāng)行為會(huì)讓用戶感到困惑或不滿,影響對(duì)產(chǎn)品的整體評(píng)價(jià)。
案例分析:
想象一下,用戶簡(jiǎn)單地對(duì)聊天機(jī)器人說了一句:“你好。”本來機(jī)器人只需要回一句問候即可。然而,由于模型被賦予了過多的工具,它可能會(huì)過度解讀用戶意圖,結(jié)果調(diào)用了數(shù)據(jù)庫(kù)查詢、訪問外部API,甚至替用戶訂了一份外賣。這樣的響應(yīng)顯然是令人費(fèi)解的。
這種情況不僅浪費(fèi)了系統(tǒng)資源,還可能造成用戶數(shù)據(jù)的泄露或引發(fā)其他安全問題。
解決方案:
?精選工具:只為模型提供在當(dāng)前場(chǎng)景下必要的工具。通過對(duì)用戶需求的分析,明確哪些工具是真正需要的。
?意圖識(shí)別:在模型調(diào)用工具之前,先進(jìn)行用戶意圖識(shí)別,確保只有在確實(shí)需要的情況下才調(diào)用相關(guān)工具。
?設(shè)置調(diào)用條件:為工具的調(diào)用設(shè)置嚴(yán)格的條件和限制,防止模型在不適當(dāng)?shù)那闆r下使用工具.
?
RAG, 上下文避免成本高昂
RAG技術(shù)使得模型可以根據(jù)提供的上下文生成更準(zhǔn)確的回答。這對(duì)于需要提供具體信息、背景知識(shí)的場(chǎng)景非常有用。然而,過度提供上下文同樣會(huì)帶來負(fù)面影響。
問題分析:
1.令牌消耗巨大:大量的上下文意味著更多的令牌消耗。模型的成本通常與令牌數(shù)量直接相關(guān),過多的上下文會(huì)顯著提高使用成本。
2.響應(yīng)時(shí)間延長(zhǎng):模型需要處理更多的信息,導(dǎo)致響應(yīng)速度變慢,用戶需要等待更長(zhǎng)的時(shí)間才能得到回復(fù)。
3.注意力分散:過多的上下文可能使模型無法專注于最相關(guān)的信息,反而降低了回答的準(zhǔn)確性。
4.增加錯(cuò)誤風(fēng)險(xiǎn):上下文信息越多,模型可能在不相關(guān)的信息中“迷路”,生成與用戶需求不符的回答。
舉例說明:
如果用戶問:“你能告訴我今天的天氣嗎?”模型只需要提供當(dāng)前的天氣信息即可。但如果為模型提供了大量的氣象數(shù)據(jù)、歷史天氣記錄等上下文,不僅增加了無謂的成本,還可能讓模型給出冗長(zhǎng)的回答,影響用戶體驗(yàn)。
優(yōu)化策略:
?動(dòng)態(tài)上下文管理:根據(jù)用戶的具體需求,動(dòng)態(tài)地提供最相關(guān)的上下文信息,而不是一股腦地全部塞給模型。
?上下文精簡(jiǎn):對(duì)提供的上下文進(jìn)行篩選,只保留與當(dāng)前對(duì)話高度相關(guān)的部分。
?上下文緩存:對(duì)于多輪對(duì)話,合理地緩存上下文,但避免上下文長(zhǎng)度無限增長(zhǎng)。
?用戶引導(dǎo):設(shè)計(jì)對(duì)話流程,引導(dǎo)用戶提供更精確的信息,減少對(duì)大段上下文的依賴。
??
思考一下
在使用工具和上下文時(shí),關(guān)鍵在于適度和相關(guān)性。過多的工具和上下文不僅不會(huì)提升模型的表現(xiàn),反而可能適得其反。我們應(yīng)該以用戶需求為核心,合理配置模型的能力,既滿足功能要求,又控制成本.
所以啊,下次再想給模型塞一大堆工具和上下文的時(shí)候,不妨先問問你的錢包:“還能撐得住嗎?”畢竟,模型“消化不良”可不是鬧著玩的,錢包“消瘦”了,也別怪它不給你打聲招呼。總而言之,在構(gòu)建智能對(duì)話系統(tǒng)時(shí),我們需要堅(jiān)持“適度”原則。工具和上下文的使用,應(yīng)當(dāng)服務(wù)于模型性能的提升和用戶體驗(yàn)的優(yōu)化,而不是一味地追求數(shù)量。只有精心設(shè)計(jì)和合理配置,我們才能打造出高效、可靠、令人滿意的聊天機(jī)器人.
?
三. 總結(jié)
在大型模型AI-Agent的開發(fā)中,我們需要像傳統(tǒng)軟件開發(fā)一樣,遵循模塊化、可測(cè)試、易維護(hù)的原則。不要迷信模型的強(qiáng)大能力,而忽視了架構(gòu)設(shè)計(jì)的重要性。
通過將復(fù)雜的邏輯拆解成更小的組件,我們可以:
?降低成本:避免不必要的模型調(diào)用,節(jié)省令牌消耗。
?提高性能:減少響應(yīng)時(shí)間,提升用戶體驗(yàn)。
?提高可靠性:模塊化的設(shè)計(jì)更容易測(cè)試和維護(hù),減少錯(cuò)誤。
最后,希望大家在AI-Agent的開發(fā)中,既能發(fā)揮模型的強(qiáng)大能力,又能保持對(duì)架構(gòu)的掌控。這樣,我們就不會(huì)被“大塊頭”嚇倒,而是能駕馭它,為我們所用。
俗話說得好,“不要試圖一口吃成個(gè)胖子”,即使是AI-Agent,也是需要慢慢“調(diào)教”的。祝大家在AI的浪潮中,乘風(fēng)破浪,勇往直前!
審核編輯 黃宇
-
AI
+關(guān)注
關(guān)注
87文章
34294瀏覽量
275480 -
Agent
+關(guān)注
關(guān)注
0文章
128瀏覽量
27575 -
大模型
+關(guān)注
關(guān)注
2文章
3033瀏覽量
3837
發(fā)布評(píng)論請(qǐng)先 登錄
評(píng)論