許多AI Agent的出現(xiàn)，確實(shí)成為解決某些特定問題的“特效藥”。但是，作為產(chǎn)品經(jīng)理，我們也需要熟悉“藥性”——他們能解決什么問題，他們可能存在的局限在哪里。

在之前的RAG實(shí)踐篇中，我們就談到了RAG在企業(yè)私有化知識的AI實(shí)踐上的應(yīng)用，可以看得出來，RAG的出現(xiàn)讓GenAI的應(yīng)用不再局限于模型訓(xùn)練數(shù)據(jù)（多使用公共領(lǐng)域的信息/知識），而是可以與私有知識庫結(jié)合，從而擴(kuò)大了其應(yīng)用范圍。讓GenAI的應(yīng)用從企業(yè)的客戶服務(wù)到知識管理等，都能有用武之地。

不過用了這么久，大家也發(fā)現(xiàn)RAG在私有化應(yīng)用中并不是個“一藥解千愁”的Agent，在“如何快速給答案“這件事情上，它有自己的局限性。作為產(chǎn)品經(jīng)理，提前了解這些局限能幫助我們更好地理解RAG的特性。

Scott Barnett等在論文Seven Failure Points When Engineering a Retrieval Augmented Generation System就討論了RAG在應(yīng)用時可能會遇到的七種局限。

局限一：在知識庫中找不到問題，傾向“胡編亂造”

私有知識庫能提供的信息是有限的。所以，使用RAG系統(tǒng)很常見地就是面臨無法從可用文檔中檢索到答案的情況。當(dāng)系統(tǒng)找不到答案時，我們期待它能夠老老實(shí)實(shí)地回答“抱歉，我不知道”。但RAG系統(tǒng)會“自信”地給出不相關(guān)的回答，而不是坦誠地“不知道”。

比如，用戶在客戶服務(wù)系統(tǒng)中詢問某款產(chǎn)品的功能，而這個產(chǎn)品信息在知識庫中并沒有。RAG系統(tǒng)在沒有約束的情況下，會給出模糊或錯誤的答案，而不是明確告知用戶缺乏相關(guān)信息。

局限二：排名不夠高，正確答案被“錯殺”

RAG系統(tǒng)通過檢索技術(shù)對文檔的語義相似度進(jìn)行賦值，將相似度高的文檔進(jìn)行召回，再根據(jù)召回內(nèi)容生成回答，輸出給用戶（詳見RAG實(shí)踐篇（三）：向量檢索的AI應(yīng)用，讓知識“活起來”）。理論上每個文檔都會被賦予一個分?jǐn)?shù)，以便確定它們與查詢的相關(guān)程度。但在實(shí)際操作中，為了平衡響應(yīng)速度，系統(tǒng)通常只會返回排名最高的N個文檔，而不是所有文檔，這就導(dǎo)致一些實(shí)際重要的文檔未被召回，影響最終生成的答案質(zhì)量。

比如，有一位管理者想咨詢“我在面試開始前要做什么準(zhǔn)備”。他的真實(shí)意圖是“我在面試開始前的5-30分鐘內(nèi)，要做點(diǎn)什么（比如看看候選人的簡歷、準(zhǔn)備些問題等等）。而知識庫里有大量與“管理者要在面試之前先提招聘申請”這類知識文檔，就會由于相似度較高（“面試”、“前”）而排位靠前，即使這些知識其實(shí)并不是正確的。而真正與問題相關(guān)的知識文檔，卻有可能由于排名沒有以上文檔高，根本沒有被召回。這樣必然導(dǎo)致回答牛頭不對馬嘴。

局限三：即使被召回，也會因?yàn)椤捌唇印辈划?dāng)而忽略

系統(tǒng)雖然為回答問題找到了相關(guān)的信息模塊（通常是多個），但在將這些塊組合成一個連貫的上下文時又出現(xiàn)了問題，導(dǎo)致LLM無法利用這些信息來生成準(zhǔn)確的回答。

比如，有用戶詢問“如何在短時間內(nèi)提高工作效率？”，系統(tǒng)檢索到多個關(guān)于時間管理和工作效率提升的信息組合，但由于上下文整合不力，系統(tǒng)未能將這些文檔中的精華內(nèi)容提取并整合成一個有價值的答案，最后用戶看到了一個看似七拼八湊，內(nèi)容之間缺乏邏輯的回答。

局限四：正確答案被“噪聲”淹沒

在某些情況下，RAG系統(tǒng)能夠檢索到包含答案的文檔，但未能準(zhǔn)確從中提取出正確的答案。這種情況通常發(fā)生當(dāng)上下文中存在過多的不相關(guān)、冗余甚至矛盾的信息時，LLM可能會迷失方向，無法聚焦于正確的答案。

比如，用戶想問一個關(guān)于“2023年最新勞動法中關(guān)于加班費(fèi)的具體規(guī)定”的問題。RAG系統(tǒng)從公司內(nèi)部的知識庫中檢索到了公司的幾篇政策文檔，其中一篇文檔確實(shí)包含了2023年最新的加班費(fèi)規(guī)定。但是這些文檔中不僅包含了關(guān)于加班費(fèi)的規(guī)定，還包含了其他一些政策，如休假制度、勞動合同解除等。此外，不同文檔對加班費(fèi)的規(guī)定描述還存在差異，甚至有些文檔提到了舊版本的法律規(guī)定。最終系統(tǒng)生成了一個回答，但它并沒有準(zhǔn)確引用2023年最新的加班費(fèi)規(guī)定。反而引用了大堆與加班費(fèi)相關(guān)的泛泛規(guī)則。

局限五：格式錯誤：未按照要求提取特定格式的信息

當(dāng)問題涉及提取特定格式的信息（如表格、列表等），系統(tǒng)可能未能遵守格式要求，從而導(dǎo)致結(jié)果格式不符合用戶期望。

比如，用戶要求系統(tǒng)以表格形式展示不同投資項(xiàng)目的回報(bào)率，然而，系統(tǒng)返回的答案卻是純文本的描述，無法滿足用戶對于格式的具體要求。

局限六：精確度不達(dá)預(yù)期

系統(tǒng)生成的回答在精確度（specificity）上不符合用戶的需求。要么太泛泛，缺乏很多細(xì)節(jié)；要么太具體細(xì)節(jié)，讓人抓不到關(guān)鍵信息。產(chǎn)生這種情況的原因很簡單，是因?yàn)镽AG在生成內(nèi)容時，依賴的是知識庫的內(nèi)容（而非用戶意圖），所以即使用戶意圖比較一致，但只要內(nèi)容在知識庫里的精確度不一樣，可能會獲得不同精確度的回答。

比如，用戶同樣詢問了兩個問題：“如何申請年假”、“如何申請加班費(fèi)”。關(guān)于前者，知識庫中恰好有精確度適當(dāng)?shù)膬?nèi)容，因此系統(tǒng)回答良好；而后者，系統(tǒng)不僅提供申請流程的信息，還提供了大量無關(guān)的規(guī)定、政策等信息，使得用戶不得不花費(fèi)額外的時間找到想要的答案。

局限七：答案不完整

系統(tǒng)生成的答案中給了部分正確信息，但遺漏了一些重要的信息，導(dǎo)致答案不完整。這是因?yàn)橄到y(tǒng)在生成回答時，會優(yōu)先選擇那些看起來合理但實(shí)際上不完整的信息，而由于LLM是基于概率生成文本的，所以它會繼續(xù)那些與上下文更“匹配”但并非最全面的答案。特別是當(dāng)用戶的問題涉及多個文檔時，這種情況會更明顯。

比如，用戶需要從多個部門的文檔中提取出關(guān)鍵信息，包括A文檔中的市場調(diào)研、B文檔中的技術(shù)規(guī)格、C文檔中的競爭對手分析等。向系統(tǒng)提出了以下問題：“請告訴我文檔A、B和C中的關(guān)鍵點(diǎn)。”系統(tǒng)生成了一個回答，提到了文檔A中的市場調(diào)研結(jié)果和文檔B中的技術(shù)規(guī)格，但完全忽略了文檔C中的競爭對手分析。

結(jié)語

看到這里你不難發(fā)現(xiàn)，很多AI Agent的出現(xiàn)，確實(shí)成為解決某些特定問題的“特效藥”。但是，作為產(chǎn)品經(jīng)理，我們也需要熟悉“藥性”——他們能解決什么問題，他們可能存在的局限在哪里。提前理解了這些，才能幫助我們在產(chǎn)品開發(fā)時更高效地找到解決方案，解決這些局限帶來的隱患。