AI大模型企業應用實戰(18)-“消滅”LLM幻覺的利器 - RAG介紹

大模型在一定程度上去改變了我們生活生工作的思考的方式，然後也越來越多的個人還有企業在思考如何將大模型去應用到更加實際的呃生產生活中去，希望大語言模型能夠呃有一些更多企業級別生產落地的實踐，然後去幫助我們解決一些業務上的問題。目前

1 LLM的問題

1.1 幻覺

LLM因為是一個預訓練模型，它已有一些知識儲備，我們提的問題跟他的知識儲備不相符時，會產生一些幻覺問題，看上去正確的回答

1.2 新鮮度

LLM預訓練出來之後，不能感知到我們實時更新的工業數據，還有企業內部的一些私域數據

1.3 數據安全

LLM訓練依賴很多訓練數據集，然後為了保證大語言模型的效果更好，訓練集的質量以及數據量越多對於大語言模型的一個訓練。最終的一個效果會更好，但我們又期望LLM想要去幫我們解決一些垂類的問題，然後又是希望在數據安全這兒會有一些防範，就比如說像企業的一些內部的敏感數據以及敏感文檔是一定不能夠暴露出去，讓公有的大語言模型去進行訓練。

2 RAG是啥？

為解決單元模型剛剛提到問題，提出RAG，將企業內部私域數據以及實時更新的一些公域數據，通過一些處理之後，變成可進行相似性搜索的向量數據，然後存儲到向量資料庫。

在我們跟大約模型交互時，用戶提問。首先在我們的相同資料庫中去進行相似性檢索，檢索出與這個提問相關的知識內容，然後檢索後交給LLM，連同用戶的提問一起讓 LLM 去生成回覆。

RAG幫助我們個人及用戶去把企業內部的一些知識數據，很快構建出一個龐大知識庫，然後結合目前已有LLM能力，可快速製作智能問答機器人應用。

為LLM提供來自外部知識源的額外信息的概念。這允許它們生成更準確和有上下文的答案，同時減少幻覺

• 檢索：外部相似搜索
• 增強：提示詞更新
• 生成：更詳細的提示詞輸入LLM

2 rag應用咋構建的？

使用到RAG的這條鏈路之後，用戶會先去構建好的知識庫，也就是我們向量資料庫裡面去進行相似性檢索，然後帶出一部分的知識知識文檔。這部分知識文檔會跟用戶的query結合。

然後我們通過prompt 技術組裝成一個最終完成的一個輸入給到LLM。然後讓LLM生成回覆。

最關鍵一點就是知識庫生成這一步，因為主要涉及把我們的知識文檔去做內容的提取及拆分。還要進行量化，存入資料庫。

2.1 RAG步驟

1. 知識切片成Chunk

2. 向量化Chunk入庫

   前兩步都是去知識庫生成。

3. Query檢索知識Chunk

4. 構建Prompts

5. 調用LLM生成回答

   後三步都是知識庫生成後，在檢索方面需要做的。

2.2基於開源框架構建 RAG 應用

像LangChain快速構建一個RAG應用。Langchain中RAG的實現：

各種文檔 - 各種 loader - 文本切片 - 嵌入向量化 - 向量存儲 - 各種檢索鏈。

思想就是把那五個步驟拆成不同組件，然後由每個不同節點做相應處理。讓用戶去編寫自己的業務邏輯的代碼，然後去把這整個過程串起來。

優點和痛點都非常明顯。

優勢主要是：

• 可以快速構建一個demo起來，幫助我們的開發者去理解RAG應用
• 龐大的一個社區支持，如一些插件或它的一個版本更新迭代都會非常快

痛點也明顯：通過開源框架構建出來的一個RAG應用，其實本質上它的通用性是非常強。為保證強通用性，它在效果層面不一定做到最好，就需要企業或個人投入比較大精力，較多研究去把這一個整體的RAG在召回層面的一個效果給提升到最佳。

3 bad case

介紹一下在整體構建整個RAG應用過程中會遇到的一些問題和解決方案。

3.1 第一個

用戶提問：請問A產品分析報告多久分析一次？

然後我們召回的相關知識是：A產品的分析報告信息近30天的數據分析結果。

原因是我們用戶的問題，在相關知識中沒有明確提到，只是有一定相似度。但跟我們用戶問題不直接相關。這樣的相關知識以及用戶的問題。組裝之後交給LLM回答，本質上是人為搞干擾。

對此，有一個工程化實踐叫拒答。

3.2 第二個

提問的A課程適合多大年齡小孩。

知識庫里會召回來兩條數據，然後其中一條數據是我們期望的一個知識。就在A課程文檔。會有一段話跟提問相關，但還會召回其他的一個干擾知識。如其他文檔里一些內容，像該課程適合3到7歲的小孩，適合6到8歲的女孩。這種知識內容也會被召回。

主要是期望的召回內容攜帶一部分干擾信息，這干擾信息沒有A課程這個關鍵字，然後也不會召回回來。在這兩個知識內容交給大源模型處理，他也無法理解哪個字內容是正確。

我們更希望在召回層面，就能有較好手段處理。工程化的實踐裡面，會對用戶的進行改寫，去增強query的一個效果。

然後也用到類似BM25這種倒排索引，提升關鍵字的權重。比如干擾知識里沒生成這一個關鍵字，那它的相似度分數較低，就召不回來。

3.3 最後一個

可能有用戶的提問是類似：伺服器連接不上，應當如何解決？

現在給知識庫裡面註入的文檔，都是類似連接伺服器應該有哪些步驟。

• 第一個問題其實將這些知識內容召回，然後交給LLM也能引導用戶。但並不能去直切要害，用戶更希望，我現在連接不上了，我有什麼樣的一個排查手段。更好的還是通過提供一些專門QA文檔，去增強整個知識召回內容準確性
• 第二個問題，用戶可能會問一些跟他實例相關的問題。如CPU占用變高或記憶體變高，然後實際響應可能是我們支持文檔裡面的一些處理方案，就是我現在記憶體變更咋處理。但用戶想知道為啥變高。有一個意圖識別模型，判斷我們現在用戶他想要的問題具體是一個什麼類的，需不需要用到RG，也是會去判斷他是不是需要用到診斷引擎。類似問題2，需要用到診斷引擎的那我們會調用其他RCG無關的診斷相關技術為用戶排查問題，並且給用戶反饋一個結果。

4 如何提升RAG應用的效果

整體效果 = 文檔處理效果 * Embedding效果 * Retrieval效果 * LLM效果。

demo易，但上手難的主要原因是因為像LangChain和 LLamIndex這種框架盛行。很快接入就是初級的一個狀態，可能只能做到35%。如提高整體一個準確率，可通過在拆分那兒會拆更合理、提取內容時，把整個內容提取更好。做向量化時，去選擇我們的向量，更好的一個embedding模型。在最終我們去跟LLM交流時，選擇效果更好的LLM，然後把這個效果給提升到更高。但實際上60%的一個準確率還是達不到我們生產環境落地的一個期望值。希望準確率90%，在RAG應用構建的各個階段，我們都會有很多工程化的一些手段實現。

可優化的效果的方式比較多，然後在整個課程裡面我們也會去挑選一些核心關鍵的及怎麼去把這個效果給做的更高。

目前RAG整體應用在界內的比較關註的一個地方就是在召回。因為涉及知識文檔，思考方向：

• 優先保護保證這個召回率
• 優先保證這個精度

RAG召回回來是希望獲得更多的跟用戶提問相關的知識內容，還是說我只需要更關鍵的知識內容排在最頂。騰訊相關資料庫的AI套件是選擇前面這路，期望是召回回來更多跟用戶相關的提問的內容。

精度儘量保證召回內容在top3、top5位置出現，因為召回的一些內容確實會有一部分干擾信息。但目前LLM 能力還可以，對這種干擾性信息的一個排除能力較好。

5 總結

關註我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、數據平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社區頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

• 中央/分銷預訂系統性能優化
• 活動&券等營銷中台建設
• 交易平臺及數據中台等架構和開發設計
• 車聯網核心平臺-物聯網連接平臺、大數據平臺架構設計及優化
• LLM應用開發

目前主攻降低軟體複雜性設計、構建高可用系統方向。

參考：

• 編程嚴選網

本文由博客一文多發平臺 OpenWrite 發佈！