：如何化解 RAG 檢索失配、提升檢索精度)
HyPE 預計算提示嵌入實戰(zhàn)如何化解 RAG 檢索失配、提升檢索精度【免費下載鏈接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.項目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques你搭好了 RAG 系統(tǒng)一上真實用戶就露怯用戶用口語提問文檔卻是公文或論文腔調(diào)。兩種寫法在向量空間里距離偏遠檢索回來的全是沾邊但不對的文本塊。這就是查詢-文檔風格失配也是 RAG 效果不達標的常見原因。HyPEHypothetical Prompt Embeddings假設性提示嵌入是開源項目 RAG_Techniques 提供的一種查詢增強技術(shù)。思路一句話索引階段用大模型為每個文本塊預生成多個假設性問題把這些問題的嵌入寫進 FAISS 向量庫替代原文入索引。查詢時變成問題對問題匹配運行時不再需要額外調(diào)用大模型。查詢與文檔為什么對不上話傳統(tǒng) RAG 的流水線是索引時給文本塊做嵌入查詢時給問題做嵌入再按向量距離檢索。問題在于兩種文本風格不同向量距離不一定小。用戶問今年空氣質(zhì)量怎么這么差文檔寫顆粒物濃度上升導致大氣污染水平顯著提高語義相近、措辭不同嵌入空間的距離未必近。補這個坑的常見做法是查詢增強比如 HyDE查詢時先調(diào) LLM 生成一段假設性答案再拿它去檢索。代價是每次查詢都多一次 LLM 調(diào)用延遲和成本都上去了。上圖展示了這類方案通用的架構(gòu)思路把昂貴的計算放進離線索引階段在線側(cè)只留一次相似性搜索。HyPE 把生成假設內(nèi)容這一步也完全挪到了離線側(cè)。索引流水線三步走把一個塊變成多條問題條目HyPE 的索引過程分三步關(guān)鍵實現(xiàn)都在筆記本all_rag_techniques/HyPE_Hypothetical_Prompt_Embeddings.ipynb里可直接對照代碼看。第一步切塊每塊 1000 字符、重疊 200腳本默認chunk_size1000、chunk_overlap200重疊防止語義在塊邊界被切斷。第二步假設性問題生成讓 LLM 替用戶出題核心步驟。all_rag_techniques_runnable_scripts/HyPE_Hypothetical_Prompt_Embeddings.py用 gpt-4o-mini 為每個塊改寫哪些問題被回答后能覆蓋這段內(nèi)容的要點一行一個問題。第三步多向量入庫每個問題一個向量都指向同一原文塊每個生成的問題單獨做嵌入text-embedding-3-small。寫入 FAISS 時同一個塊被登記多次問題向量就是它的入口。這就是 HyPE 的多向量表示一個塊、N 個入口語義覆蓋面更大。檢索時用戶問題只要貼近其中任意一個入口問題就能命中這個塊。檢索精度到底漲了多少看這幾個數(shù)字根據(jù)官方評估HyPE 預印論文及其基準測試上下文檢索精度相對標準 RAG 最高提升 42 個百分點聲明召回率相對標準 RAG 最高提升 45 個百分點運行時開銷查詢階段零 LLM 調(diào)用與標準 RAG 持平用 before → after 對比更直觀查詢-文檔匹配 → 查詢-問題匹配每次查詢多跑一次 LLMHyDE→ 每次查詢零額外 LLM 調(diào)用HyPE。注意多向量表示的成本被挪到了索引側(cè)索引條數(shù)變成塊數(shù) × 每塊平均問題數(shù)LLM 調(diào)用次數(shù)同步放大。語料庫大時建議先評估一次性索引的成本和耗時。一條命令跑起來最小可運行路徑先克隆倉庫并在.env里配好 OpenAI API keygit clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques然后直接跑項目自帶的可運行腳本它內(nèi)置了默認 PDF 語料data/Understanding_Climate_Change.pdf和默認測試問題python all_rag_techniques_runnable_scripts/HyPE_Hypothetical_Prompt_Embeddings.py --path data/Understanding_Climate_Change.pdf --query What is the main cause of climate change? --evaluate帶上--evaluate會觸發(fā)檢索評估精度和召回數(shù)據(jù)可以直接看到。如果要進生產(chǎn)可以把 FAISS 換成托管向量數(shù)據(jù)庫生產(chǎn)級向量數(shù)據(jù)庫的集群管理界面如上圖。換庫時只需要替換向量庫創(chuàng)建那部分代碼每個塊多條向量的寫入邏輯不變。參數(shù)與選型避坑清單塊大小可以調(diào)大。默認 1000/200 只是起點。一個塊有多個問題入口大塊導致的精度損失比標準 RAG 小得多建議先試大值再往下調(diào)。索引期 LLM 開銷要預估。腳本用線程池并發(fā)生成問題但總調(diào)用次數(shù)與塊數(shù)成正比。大語料庫先抽一小批試跑把成本算清楚再全量。檢索結(jié)果記得去重。同一個塊可能被多個問題向量命中官方腳本對 context 做了set()去重自己改造時別漏掉這一步。模型可以換。示例用 OpenAI 的 LLM 和嵌入模型代碼里這兩處替換成任意兼容實現(xiàn)即可按自己的成本和合規(guī)要求選。HyPE 適合你的哪類場景HyPE 適合三類情況需要把檢索精度擠到更高企業(yè)知識庫、客服問答、對查詢延遲和成本敏感的生產(chǎn)環(huán)境運行時不依賴 LLM、語料規(guī)模中等以上且查詢風格多樣的文檔庫多向量表示的收益更明顯。如果你的語料只有幾十頁或索引窗口非常緊張HyPE 的一次性成本可能不劃算標準 RAG 加重排序的組合足夠用。克隆倉庫拿你自己的 PDF 跑一遍 HyPE 腳本一次查詢就能看出檢索差別?！久赓M下載鏈接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.項目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 HyPE 預計算提示嵌入實戰(zhàn)：如何化解 RAG 檢索失配、提升檢索精度
HyPE 預計算提示嵌入實戰(zhàn)如何化解 RAG 檢索失配、提升檢索精度【免費下載鏈接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.項目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques你搭好了 RAG 系統(tǒng)一上真實用戶就露怯用戶用口語提問文檔卻是公文或論文腔調(diào)。兩種寫法在向量空間里距離偏遠檢索回來的全是沾邊但不對的文本塊。這就是查詢-文檔風格失配也是 RAG 效果不達標的常見原因。HyPEHypothetical Prompt Embeddings假設性提示嵌入是開源項目 RAG_Techniques 提供的一種查詢增強技術(shù)。思路一句話索引階段用大模型為每個文本塊預生成多個假設性問題把這些問題的嵌入寫進 FAISS 向量庫替代原文入索引。查詢時變成問題對問題匹配運行時不再需要額外調(diào)用大模型。查詢與文檔為什么對不上話傳統(tǒng) RAG 的流水線是索引時給文本塊做嵌入查詢時給問題做嵌入再按向量距離檢索。問題在于兩種文本風格不同向量距離不一定小。用戶問今年空氣質(zhì)量怎么這么差文檔寫顆粒物濃度上升導致大氣污染水平顯著提高語義相近、措辭不同嵌入空間的距離未必近。補這個坑的常見做法是查詢增強比如 HyDE查詢時先調(diào) LLM 生成一段假設性答案再拿它去檢索。代價是每次查詢都多一次 LLM 調(diào)用延遲和成本都上去了。上圖展示了這類方案通用的架構(gòu)思路把昂貴的計算放進離線索引階段在線側(cè)只留一次相似性搜索。HyPE 把生成假設內(nèi)容這一步也完全挪到了離線側(cè)。索引流水線三步走把一個塊變成多條問題條目HyPE 的索引過程分三步關(guān)鍵實現(xiàn)都在筆記本all_rag_techniques/HyPE_Hypothetical_Prompt_Embeddings.ipynb里可直接對照代碼看。第一步切塊每塊 1000 字符、重疊 200腳本默認chunk_size1000、chunk_overlap200重疊防止語義在塊邊界被切斷。第二步假設性問題生成讓 LLM 替用戶出題核心步驟。all_rag_techniques_runnable_scripts/HyPE_Hypothetical_Prompt_Embeddings.py用 gpt-4o-mini 為每個塊改寫哪些問題被回答后能覆蓋這段內(nèi)容的要點一行一個問題。第三步多向量入庫每個問題一個向量都指向同一原文塊每個生成的問題單獨做嵌入text-embedding-3-small。寫入 FAISS 時同一個塊被登記多次問題向量就是它的入口。這就是 HyPE 的多向量表示一個塊、N 個入口語義覆蓋面更大。檢索時用戶問題只要貼近其中任意一個入口問題就能命中這個塊。檢索精度到底漲了多少看這幾個數(shù)字根據(jù)官方評估HyPE 預印論文及其基準測試上下文檢索精度相對標準 RAG 最高提升 42 個百分點聲明召回率相對標準 RAG 最高提升 45 個百分點運行時開銷查詢階段零 LLM 調(diào)用與標準 RAG 持平用 before → after 對比更直觀查詢-文檔匹配 → 查詢-問題匹配每次查詢多跑一次 LLMHyDE→ 每次查詢零額外 LLM 調(diào)用HyPE。注意多向量表示的成本被挪到了索引側(cè)索引條數(shù)變成塊數(shù) × 每塊平均問題數(shù)LLM 調(diào)用次數(shù)同步放大。語料庫大時建議先評估一次性索引的成本和耗時。一條命令跑起來最小可運行路徑先克隆倉庫并在.env里配好 OpenAI API keygit clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques然后直接跑項目自帶的可運行腳本它內(nèi)置了默認 PDF 語料data/Understanding_Climate_Change.pdf和默認測試問題python all_rag_techniques_runnable_scripts/HyPE_Hypothetical_Prompt_Embeddings.py --path data/Understanding_Climate_Change.pdf --query What is the main cause of climate change? --evaluate帶上--evaluate會觸發(fā)檢索評估精度和召回數(shù)據(jù)可以直接看到。如果要進生產(chǎn)可以把 FAISS 換成托管向量數(shù)據(jù)庫生產(chǎn)級向量數(shù)據(jù)庫的集群管理界面如上圖。換庫時只需要替換向量庫創(chuàng)建那部分代碼每個塊多條向量的寫入邏輯不變。參數(shù)與選型避坑清單塊大小可以調(diào)大。默認 1000/200 只是起點。一個塊有多個問題入口大塊導致的精度損失比標準 RAG 小得多建議先試大值再往下調(diào)。索引期 LLM 開銷要預估。腳本用線程池并發(fā)生成問題但總調(diào)用次數(shù)與塊數(shù)成正比。大語料庫先抽一小批試跑把成本算清楚再全量。檢索結(jié)果記得去重。同一個塊可能被多個問題向量命中官方腳本對 context 做了set()去重自己改造時別漏掉這一步。模型可以換。示例用 OpenAI 的 LLM 和嵌入模型代碼里這兩處替換成任意兼容實現(xiàn)即可按自己的成本和合規(guī)要求選。HyPE 適合你的哪類場景HyPE 適合三類情況需要把檢索精度擠到更高企業(yè)知識庫、客服問答、對查詢延遲和成本敏感的生產(chǎn)環(huán)境運行時不依賴 LLM、語料規(guī)模中等以上且查詢風格多樣的文檔庫多向量表示的收益更明顯。如果你的語料只有幾十頁或索引窗口非常緊張HyPE 的一次性成本可能不劃算標準 RAG 加重排序的組合足夠用。克隆倉庫拿你自己的 PDF 跑一遍 HyPE 腳本一次查詢就能看出檢索差別?！久赓M下載鏈接】RAG_TechniquesThis repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. Each technique has a detailed notebook tutorial.項目地址: https://gitcode.com/GitHub_Trending/ra/RAG_Techniques創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考