大模型面經—RAG工程實踐經驗總結 原創
?RAG工程經驗面經總結。
雖然RAG工程整體有很多論文、算法和方法論，但在實際使用過程中，當數據量大了RAG很容易出現不可控的問題， 本篇就針對實踐過程中遇到的問題總結面經進行分享，看看能不能給大家提供一些幫助。下面是一個快捷目錄。
一. RAG如何去優化索引結構？
二. 當混合檢索以及基于不同大小的chunk去檢索效果都不太好的時候，如何優化？
三. 如何通過rerank去提升RAG效果的，有哪些方案？
下面是答案。
一. RAG如何去優化索引結構？
1. 優化被檢索的embedding
1）微調被檢索的embedding
目的：讓被檢索的內容與query之間的相關性更加緊密
特別是術語更新較快且比較罕見的領域，可以針對性地進行微調。
2）動態embedding
目的：基于上下文動態調整embedding
當然這只是個發論文的思路，工程落地的時候這塊還是有待驗證的。
3）檢索后處理流程優化
目的：直接把所有檢索結果給大模型可能會超出上下文窗口限制，內容過多噪聲也可能比較多。
優化方法：
- ReRank
- Prompt 壓縮
- RAG 管道優化
- 混合搜索
- 遞歸檢索與查詢引擎
- StepBack-prompt 方法
- 子查詢
- HyDE 方法
2. 優化query的chunk大小
chunk大小非常關鍵，決定了從向量存儲中檢索的文檔的長度。小塊可能導致文檔缺失一些關鍵信息，而大塊可能引入無關的噪音。找到最佳塊大小是要找到正確的平衡。
目前來說一般是按不同塊大小劃分驗證集做實驗，直接用驗證集效果說話。
3. 結合不同粒度信息進行混合檢索
雖然向量搜索有助于檢索與給定查詢相關的語義相關塊，但有時在匹配特定關鍵詞方面缺乏精度。根據用例，有時可能需要精確匹配。
混合檢索就是結合embedding搜索和關鍵詞搜索。
二. 當混合檢索以及基于不同大小的chunk去檢索效果都不太好的時候，如何優化？
這種情況就要針對具體的case關注知識庫里是否有答案了。
如果有答案但是沒檢索出來，那么大概率可能答案被錯誤分割開了，那么可以結合一些小模型（BERT等）拿來做上下句預測；
另外也可以分析 query 和 doc 的特點：字相關還是語義相關，一般建議是先用推薦系統經典的ES做召回，然后才用模型做精排
三. 如何通過rerank去提升RAG效果的，有哪些方案？
背景：當檢索時，前K個結果不一定按最相關的方式排序。它們都是相關的， 但在這些相關內容中，最相關的可能并不是第1或第2個，而是排名靠后的。rerank就是將最相關的信息重新定位到排名靠后的檢索結果。
這里推薦一些思路：
Diversity Ranker 根據文檔的多樣性進行重新排序；
LostInTheMiddleRanker 中提出LLM 會著重把注意力放在文本開頭和結尾的位置，那就把最需要讓 LLM 關注的 documents 放在開頭和結尾的位置。
另外還有一些經典的框架LlamaIndex、LangChain 和 HayStack都可以參考和直接用。
其實主要的思路都大同小異，實際工作中還是主要會結合具體的case來優化，大家有更多的問題和經驗也可以一起分享討論。
參考文獻
[1] Retrieval-Augmented Generation for Large Language Models: A Survey(arxiv.org/pdf/2312.10997)
[2] 論文分享|RAG理論-第一篇-概述 - 知乎(https://zhuanlan.zhihu.com/p/678616587)
[3] 提升RAG性能的關鍵技術：從數據清理到混合檢索的全方位討論 - 知乎(https://zhuanlan.zhihu.com/p/676463769)
?
文轉載自公眾號瓦力算法學研所，作者：喜歡瓦力的卷卷
