參考1.從零拆解一個 RAG 系統(tǒng)純 API 調用、無需 GPU基于 LangChain Chroma DeepSeek 的學習筆記_通過api調用rag-CSDN博客一、RAG 到底在解決什么問題大模型有兩個硬傷訓練數(shù)據(jù)有截止日期不知道最新的信息不知道你的私有數(shù)據(jù)比如公司內部文檔、產品手冊3.3.2 文本切分兩種策略這是 RAG 中非常關鍵的一步。為什么要切分因為一篇文檔可能幾千上萬字整篇做向量化精度會很差檢索時需要定位到具體段落而不是返回整篇文檔大模型的上下文窗口有限塞太多內容反而影響效果recursive幾乎是所有場景的首選。它的separators列表定義了切分優(yōu)先級——先嘗試按雙換行段落切切不動就按單換行切再切不動就按句號切……這樣能最大程度保持語義完整性。chunk_overlap是重疊區(qū)域比如設成 50相鄰兩個塊會有 50 個字符的重疊防止關鍵信息剛好被切在邊界上丟失。3.3.4 三種檢索模式純向量檢索把問題轉成向量在向量庫里找最相似的文本塊。擅長語義匹配比如怎么讓模型不瞎編能匹配到減少幻覺。BM25 檢索傳統(tǒng)的關鍵詞搜索算法基于詞頻和逆文檔頻率。擅長精確匹配比如搜Milvus就是要找包含這個詞的內容?；旌蠙z索向量 BM25 一起用通過EnsembleRetriever做 RRFReciprocal Rank Fusion融合。為什么權重是 6:4向量檢索 在大多數(shù)場景下效果更好能理解語義但關鍵詞檢索在精確匹配場景不可替代所以給向量更高權重同時保留 BM25 的補充能力。3.3.5 Query 變換兩種策略用戶的提問往往不是最適合檢索的形式Query 變換就是在檢索前優(yōu)化問題。比如用戶問RAG 咋用啊改寫后可能變成RAG 的使用方法和核心流程更適合檢索。HyDE假設性文檔嵌入這個思路很巧妙不用問題去搜而是先讓 LLM 猜一個答案用這個答案去搜。為什么因為答案和知識庫里的內容在表述上更接近都是陳述句向量相似度會更高。3.3.6 RAG 主鏈路Query 變換只影響檢索用的 query最終給 LLM 的還是用戶原始問題。這很重要因為改寫/HyDE 是為了提高檢索精度但回答應該針對用戶的原始意圖。兩個關鍵指令沒有相關信息要誠實說明減少幻覺、標注信息來源增強可信度4.3 Langfuse可觀測性Langfuse 可以追蹤每次 RAG 查詢的完整鏈路用了哪個檢索器、檢索到了什么、LLM 的輸入輸出、耗時多少。對于調優(yōu) RAG 效果非常有用。