HyPE 预计算提示嵌入实战如何化解 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 系统一上真实用户就露怯用户用口语提问文档却是公文或论文腔调。两种写法在向量空间里距离偏远检索回来的全是沾边但不对的文本块。这就是查询-文档风格失配也是 RAG 效果不达标的常见原因。HyPEHypothetical Prompt Embeddings假设性提示嵌入是开源项目 RAG_Techniques 提供的一种查询增强技术。思路一句话索引阶段用大模型为每个文本块预生成多个假设性问题把这些问题的嵌入写进 FAISS 向量库替代原文入索引。查询时变成问题对问题匹配运行时不再需要额外调用大模型。查询与文档为什么对不上话传统 RAG 的流水线是索引时给文本块做嵌入查询时给问题做嵌入再按向量距离检索。问题在于两种文本风格不同向量距离不一定小。用户问今年空气质量怎么这么差文档写颗粒物浓度上升导致大气污染水平显著提高语义相近、措辞不同嵌入空间的距离未必近。补这个坑的常见做法是查询增强比如 HyDE查询时先调 LLM 生成一段假设性答案再拿它去检索。代价是每次查询都多一次 LLM 调用延迟和成本都上去了。上图展示了这类方案通用的架构思路把昂贵的计算放进离线索引阶段在线侧只留一次相似性搜索。HyPE 把生成假设内容这一步也完全挪到了离线侧。索引流水线三步走把一个块变成多条问题条目HyPE 的索引过程分三步关键实现都在笔记本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 为每个块改写哪些问题被回答后能覆盖这段内容的要点一行一个问题。第三步多向量入库每个问题一个向量都指向同一原文块每个生成的问题单独做嵌入text-embedding-3-small。写入 FAISS 时同一个块被登记多次问题向量就是它的入口。这就是 HyPE 的多向量表示一个块、N 个入口语义覆盖面更大。检索时用户问题只要贴近其中任意一个入口问题就能命中这个块。检索精度到底涨了多少看这几个数字根据官方评估HyPE 预印论文及其基准测试上下文检索精度相对标准 RAG 最高提升 42 个百分点声明召回率相对标准 RAG 最高提升 45 个百分点运行时开销查询阶段零 LLM 调用与标准 RAG 持平用 before → after 对比更直观查询-文档匹配 → 查询-问题匹配每次查询多跑一次 LLMHyDE→ 每次查询零额外 LLM 调用HyPE。注意多向量表示的成本被挪到了索引侧索引条数变成块数 × 每块平均问题数LLM 调用次数同步放大。语料库大时建议先评估一次性索引的成本和耗时。一条命令跑起来最小可运行路径先克隆仓库并在.env里配好 OpenAI API keygit clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques然后直接跑项目自带的可运行脚本它内置了默认 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会触发检索评估精度和召回数据可以直接看到。如果要进生产可以把 FAISS 换成托管向量数据库生产级向量数据库的集群管理界面如上图。换库时只需要替换向量库创建那部分代码每个块多条向量的写入逻辑不变。参数与选型避坑清单块大小可以调大。默认 1000/200 只是起点。一个块有多个问题入口大块导致的精度损失比标准 RAG 小得多建议先试大值再往下调。索引期 LLM 开销要预估。脚本用线程池并发生成问题但总调用次数与块数成正比。大语料库先抽一小批试跑把成本算清楚再全量。检索结果记得去重。同一个块可能被多个问题向量命中官方脚本对 context 做了set()去重自己改造时别漏掉这一步。模型可以换。示例用 OpenAI 的 LLM 和嵌入模型代码里这两处替换成任意兼容实现即可按自己的成本和合规要求选。HyPE 适合你的哪类场景HyPE 适合三类情况需要把检索精度挤到更高企业知识库、客服问答、对查询延迟和成本敏感的生产环境运行时不依赖 LLM、语料规模中等以上且查询风格多样的文档库多向量表示的收益更明显。如果你的语料只有几十页或索引窗口非常紧张HyPE 的一次性成本可能不划算标准 RAG 加重排序的组合足够用。克隆仓库拿你自己的 PDF 跑一遍 HyPE 脚本一次查询就能看出检索差别。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 HyPE 预计算提示嵌入实战：如何化解 RAG 检索失配、提升检索精度
HyPE 预计算提示嵌入实战如何化解 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 系统一上真实用户就露怯用户用口语提问文档却是公文或论文腔调。两种写法在向量空间里距离偏远检索回来的全是沾边但不对的文本块。这就是查询-文档风格失配也是 RAG 效果不达标的常见原因。HyPEHypothetical Prompt Embeddings假设性提示嵌入是开源项目 RAG_Techniques 提供的一种查询增强技术。思路一句话索引阶段用大模型为每个文本块预生成多个假设性问题把这些问题的嵌入写进 FAISS 向量库替代原文入索引。查询时变成问题对问题匹配运行时不再需要额外调用大模型。查询与文档为什么对不上话传统 RAG 的流水线是索引时给文本块做嵌入查询时给问题做嵌入再按向量距离检索。问题在于两种文本风格不同向量距离不一定小。用户问今年空气质量怎么这么差文档写颗粒物浓度上升导致大气污染水平显著提高语义相近、措辞不同嵌入空间的距离未必近。补这个坑的常见做法是查询增强比如 HyDE查询时先调 LLM 生成一段假设性答案再拿它去检索。代价是每次查询都多一次 LLM 调用延迟和成本都上去了。上图展示了这类方案通用的架构思路把昂贵的计算放进离线索引阶段在线侧只留一次相似性搜索。HyPE 把生成假设内容这一步也完全挪到了离线侧。索引流水线三步走把一个块变成多条问题条目HyPE 的索引过程分三步关键实现都在笔记本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 为每个块改写哪些问题被回答后能覆盖这段内容的要点一行一个问题。第三步多向量入库每个问题一个向量都指向同一原文块每个生成的问题单独做嵌入text-embedding-3-small。写入 FAISS 时同一个块被登记多次问题向量就是它的入口。这就是 HyPE 的多向量表示一个块、N 个入口语义覆盖面更大。检索时用户问题只要贴近其中任意一个入口问题就能命中这个块。检索精度到底涨了多少看这几个数字根据官方评估HyPE 预印论文及其基准测试上下文检索精度相对标准 RAG 最高提升 42 个百分点声明召回率相对标准 RAG 最高提升 45 个百分点运行时开销查询阶段零 LLM 调用与标准 RAG 持平用 before → after 对比更直观查询-文档匹配 → 查询-问题匹配每次查询多跑一次 LLMHyDE→ 每次查询零额外 LLM 调用HyPE。注意多向量表示的成本被挪到了索引侧索引条数变成块数 × 每块平均问题数LLM 调用次数同步放大。语料库大时建议先评估一次性索引的成本和耗时。一条命令跑起来最小可运行路径先克隆仓库并在.env里配好 OpenAI API keygit clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques然后直接跑项目自带的可运行脚本它内置了默认 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会触发检索评估精度和召回数据可以直接看到。如果要进生产可以把 FAISS 换成托管向量数据库生产级向量数据库的集群管理界面如上图。换库时只需要替换向量库创建那部分代码每个块多条向量的写入逻辑不变。参数与选型避坑清单块大小可以调大。默认 1000/200 只是起点。一个块有多个问题入口大块导致的精度损失比标准 RAG 小得多建议先试大值再往下调。索引期 LLM 开销要预估。脚本用线程池并发生成问题但总调用次数与块数成正比。大语料库先抽一小批试跑把成本算清楚再全量。检索结果记得去重。同一个块可能被多个问题向量命中官方脚本对 context 做了set()去重自己改造时别漏掉这一步。模型可以换。示例用 OpenAI 的 LLM 和嵌入模型代码里这两处替换成任意兼容实现即可按自己的成本和合规要求选。HyPE 适合你的哪类场景HyPE 适合三类情况需要把检索精度挤到更高企业知识库、客服问答、对查询延迟和成本敏感的生产环境运行时不依赖 LLM、语料规模中等以上且查询风格多样的文档库多向量表示的收益更明显。如果你的语料只有几十页或索引窗口非常紧张HyPE 的一次性成本可能不划算标准 RAG 加重排序的组合足够用。克隆仓库拿你自己的 PDF 跑一遍 HyPE 脚本一次查询就能看出检索差别。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考