“ 增強生成的處理會直接影響到模型生成質量，如果做不好，哪怕你文檔處理的再好，召回的質量再高，也沒什么用。”

最近也寫了很多關于RAG系統的內容，大部分都是在講述文檔處理和文檔檢索兩部分內容；而RAG既然被稱為檢索增強，那么我們今天就從增強的角度講一下怎么進行增強，有哪些注意點和問題。

在RAG中大部分人的關注點可能都在文檔處理和文檔召回上，也會用大量的時間來優化這兩部分內容；因此，往往忽視了增強這一塊功能。

RAG全稱是——檢索增強生成，檢索在前，增強生成在后；因此，RAG的原理其實很簡單，檢索到問題相關文檔，然后把這部分文檔交給大模型進行生成。

所以，前面講的文檔處理和文檔檢索就屬于RAG的檢索部分，文檔處理的質量會影響到文檔檢索的效果；而增強生成部分就是怎么把召回的文檔丟給大模型，使用什么格式，存在哪些問題。

RAG增強生成

可能在很多人看來，把檢索到的內容直接拼接到提示詞中，然后丟給模型就可以了；但事實上這一步并沒有大家想象中的那么簡單，其存在好幾個注意點。

首先一點，提示詞作為用戶與大模型交互的一個唯一途徑，其是有上下文窗口限制的；因此，如果你召回的內容太長有可能會超出提示詞窗口限制，導致數據丟失，因而影響到最終內容生成。

特別是在前期文檔處理和召回做的不好的情況下，會導致文檔太長相關度低，存在大量噪音；最后再加上超長引起的數據丟失，那生成效果就不能保證了。

其次，在提示詞中召回的文檔只占提示詞的一部分；其中還要有系統提示詞，角色提示詞，以及歷史記錄；特別是歷史記錄會占很大一部分提示詞的空間；而這些內容都會直接或間接的影響模型最終的生成效果。

再有，有些在召回文檔之后，就直接把檢索到的文檔列表丟給模型，而不會去做任何處理；但類似于我們請教別人問題，是別人直接把一堆亂七八糟的資料丟給你讓你自己研究好呢，還是別人把資料分門別類做好標注再給你比較好呢？我想肯定是后者。

那么面對以上的問題，我們都應該怎么解決呢？

首先一點就是為了保證模型的生成質量，我們丟給模型的文檔一定是高度相關的，并且要控制文檔的數量，防止超長。

其次，在歷史記錄中我們也要控制歷史記錄的數量或長度；比如只記錄十輪對話，或者對歷史記錄進行壓縮。比如說，我們一般情況下會把歷史對話的所有內容全都記錄下來，但事實上在歷史記錄中我們只需要記錄大概對話內容即可；并不一定要把完整對話記錄下來；因為歷史記錄的目的是為了實現記憶功能，而記憶功能只需要知道大概發生了什么即可；而不是把發生的事情記錄得一清二楚。這樣也可以減少記憶的超度，提升質量。

最后，我們在把文檔丟給大模型之前，最好能把文檔進行一些格式化處理；比如說告訴模型我這里有個參考文檔列表，然后這是第一段，第二段，第三段等等；這樣也有助于提升模型的生成質量。

總之，增強生成雖然理論上很簡單，但事實上會存在很多坑和優化點，只不過我們很多人很難注意到它們。其次，以上只是一些通用的優化手段，在真實的業務場景中需要根據不同的情況進行多輪測試才能達到最好的效果。

比如說，使用不同的模型由于其能力不同，窗口大小不同，對提示詞長度的要求也不同；因此，如果我們要想做到高質量的生成，就需要去不斷地測試和優化才能達到最優的參數值。

本文轉載自??AI探索時代?? 作者：DFires