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