RAG實踐篇(四):你需要知道的RAG七個局限
許多AI Agent的出現(xiàn),確實成為解決某些特定問題的“特效藥”。但是,作為產(chǎn)品經(jīng)理,我們也需要熟悉“藥性”——他們能解決什么問題,他們可能存在的局限在哪里。
在之前的RAG實踐篇中,我們就談到了RAG在企業(yè)私有化知識的AI實踐上的應(yīng)用,可以看得出來,RAG的出現(xiàn)讓GenAI的應(yīng)用不再局限于模型訓練數(shù)據(jù)(多使用公共領(lǐng)域的信息/知識),而是可以與私有知識庫結(jié)合,從而擴大了其應(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)很常見地就是面臨無法從可用文檔中檢索到答案的情況。當系統(tǒng)找不到答案時,我們期待它能夠老老實實地回答“抱歉,我不知道”。但RAG系統(tǒng)會“自信”地給出不相關(guān)的回答,而不是坦誠地“不知道”。
比如,用戶在客戶服務(wù)系統(tǒng)中詢問某款產(chǎn)品的功能,而這個產(chǎn)品信息在知識庫中并沒有。RAG系統(tǒng)在沒有約束的情況下,會給出模糊或錯誤的答案,而不是明確告知用戶缺乏相關(guān)信息。
局限二:排名不夠高,正確答案被“錯殺”
RAG系統(tǒng)通過檢索技術(shù)對文檔的語義相似度進行賦值,將相似度高的文檔進行召回,再根據(jù)召回內(nèi)容生成回答,輸出給用戶(詳見RAG實踐篇(三):向量檢索的AI應(yīng)用,讓知識“活起來”)。理論上每個文檔都會被賦予一個分數(shù),以便確定它們與查詢的相關(guān)程度。但在實際操作中,為了平衡響應(yīng)速度,系統(tǒng)通常只會返回排名最高的N個文檔,而不是所有文檔,這就導致一些實際重要的文檔未被召回,影響最終生成的答案質(zhì)量。
比如,有一位管理者想咨詢“我在面試開始前要做什么準備”。他的真實意圖是“我在面試開始前的5-30分鐘內(nèi),要做點什么(比如看看候選人的簡歷、準備些問題等等)。而知識庫里有大量與“管理者要在面試之前先提招聘申請”這類知識文檔,就會由于相似度較高(“面試”、“前”)而排位靠前,即使這些知識其實并不是正確的。而真正與問題相關(guān)的知識文檔,卻有可能由于排名沒有以上文檔高,根本沒有被召回。這樣必然導致回答牛頭不對馬嘴。
局限三:即使被召回,也會因為“拼接”不當而忽略
系統(tǒng)雖然為回答問題找到了相關(guān)的信息模塊(通常是多個),但在將這些塊組合成一個連貫的上下文時又出現(xiàn)了問題,導致LLM無法利用這些信息來生成準確的回答。
比如,有用戶詢問“如何在短時間內(nèi)提高工作效率?”,系統(tǒng)檢索到多個關(guān)于時間管理和工作效率提升的信息組合,但由于上下文整合不力,系統(tǒng)未能將這些文檔中的精華內(nèi)容提取并整合成一個有價值的答案,最后用戶看到了一個看似七拼八湊,內(nèi)容之間缺乏邏輯的回答。
局限四:正確答案被“噪聲”淹沒
在某些情況下,RAG系統(tǒng)能夠檢索到包含答案的文檔,但未能準確從中提取出正確的答案。這種情況通常發(fā)生當上下文中存在過多的不相關(guān)、冗余甚至矛盾的信息時,LLM可能會迷失方向,無法聚焦于正確的答案。
比如,用戶想問一個關(guān)于“2023年最新勞動法中關(guān)于加班費的具體規(guī)定”的問題。RAG系統(tǒng)從公司內(nèi)部的知識庫中檢索到了公司的幾篇政策文檔,其中一篇文檔確實包含了2023年最新的加班費規(guī)定。但是這些文檔中不僅包含了關(guān)于加班費的規(guī)定,還包含了其他一些政策,如休假制度、勞動合同解除等。此外,不同文檔對加班費的規(guī)定描述還存在差異,甚至有些文檔提到了舊版本的法律規(guī)定。最終系統(tǒng)生成了一個回答,但它并沒有準確引用2023年最新的加班費規(guī)定。反而引用了大堆與加班費相關(guān)的泛泛規(guī)則。
局限五:格式錯誤:未按照要求提取特定格式的信息
當問題涉及提取特定格式的信息(如表格、列表等),系統(tǒng)可能未能遵守格式要求,從而導致結(jié)果格式不符合用戶期望。
比如,用戶要求系統(tǒng)以表格形式展示不同投資項目的回報率,然而,系統(tǒng)返回的答案卻是純文本的描述,無法滿足用戶對于格式的具體要求。
局限六:精確度不達預(yù)期
系統(tǒng)生成的回答在精確度(specificity)上不符合用戶的需求。要么太泛泛,缺乏很多細節(jié);要么太具體細節(jié),讓人抓不到關(guān)鍵信息。產(chǎn)生這種情況的原因很簡單,是因為RAG在生成內(nèi)容時,依賴的是知識庫的內(nèi)容(而非用戶意圖),所以即使用戶意圖比較一致,但只要內(nèi)容在知識庫里的精確度不一樣,可能會獲得不同精確度的回答。
比如,用戶同樣詢問了兩個問題:“如何申請年假”、“如何申請加班費”。關(guān)于前者,知識庫中恰好有精確度適當?shù)膬?nèi)容,因此系統(tǒng)回答良好;而后者,系統(tǒng)不僅提供申請流程的信息,還提供了大量無關(guān)的規(guī)定、政策等信息,使得用戶不得不花費額外的時間找到想要的答案。
局限七:答案不完整
系統(tǒng)生成的答案中給了部分正確信息,但遺漏了一些重要的信息,導致答案不完整。這是因為系統(tǒng)在生成回答時,會優(yōu)先選擇那些看起來合理但實際上不完整的信息,而由于LLM是基于概率生成文本的,所以它會繼續(xù)那些與上下文更“匹配”但并非最全面的答案。特別是當用戶的問題涉及多個文檔時,這種情況會更明顯。
比如,用戶需要從多個部門的文檔中提取出關(guān)鍵信息,包括A文檔中的市場調(diào)研、B文檔中的技術(shù)規(guī)格、C文檔中的競爭對手分析等。向系統(tǒng)提出了以下問題:“請告訴我文檔A、B和C中的關(guān)鍵點?!毕到y(tǒng)生成了一個回答,提到了文檔A中的市場調(diào)研結(jié)果和文檔B中的技術(shù)規(guī)格,但完全忽略了文檔C中的競爭對手分析。
結(jié)語
看到這里你不難發(fā)現(xiàn),很多AI Agent的出現(xiàn),確實成為解決某些特定問題的“特效藥”。但是,作為產(chǎn)品經(jīng)理,我們也需要熟悉“藥性”——他們能解決什么問題,他們可能存在的局限在哪里。提前理解了這些,才能幫助我們在產(chǎn)品開發(fā)時更高效地找到解決方案,解決這些局限帶來的隱患。
本文由 @AI 實踐干貨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)
- 目前還沒評論,等你發(fā)揮!