HyPE 假设提示嵌入实践指南：RAG 检索精度最高提升 42 个百分点

HyPE 假设提示嵌入实践指南RAG 检索精度最高提升 42 个百分点【免费下载链接】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 系统喂了一本讲气候变化的 PDF用户问气候变化的主因是什么但原文写的是温室气体累积是驱动气候系统变化的核心机制。向量检索靠语义相似度可这种表述差异足以让本该命中的段落掉出 top 3生成环节再强也救不回来。HyPEHypothetical Prompt Embeddings就是针对这类检索失配做的优化它属于 RAG 检索优化的一个方向核心手段是在索引阶段预生成一批假设性问题把问题嵌入向量入库查询时做问题对问题的匹配。RAG_Techniques 仓库里的 HyPE Notebook 把完整流程做成了可运行的教程本文基于它展开。为什么向量检索会听不懂你的问题标准 RAG 的检索逻辑很直白把原文切成小块、各自嵌入成向量存进向量库用户提问后再嵌入一次取余弦相似度最高的 top k 个块。问题出在两侧文风不同——原文偏陈述性用户的查询偏疑问式同一个概念在向量空间里未必靠得近。常见的补救思路是 HyDE 这类查询扩展技术查询时先用 LLM 现场生成一段假设性回答拿它去做相似度匹配。效果是有的但每次提问都多一次 LLM 调用延迟和费用都上去了。HyPE 的思路是把这件事挪到另一边不扩查询而是扩文档——离线阶段就替每个文本块想好读者可能会怎么问。HyPE 的机制用预计算问题向量替代原文向量上图展示了典型的 RAG 两阶段结构离线做索引加载在线只做检索和生成。HyPE 正是把全部生成工作压进离线一侧索引阶段离线PDF 用 PyPDFLoader 读入经 RecursiveCharacterTextSplitter 按大小加重叠切块随后 LLM 为每个块生成若干代理问题这些问题再经嵌入模型教程默认 text-embedding-3-small向量化写入 FAISS。一个文本块对应多条向量相当于被多次索引覆盖面更广。查询阶段在线用户问题嵌入后与库里的预计算问题向量做最近邻匹配命中向量后沿元数据取回所属的原文块交给 LLM 作答。匹配对象从问题 vs 段落变成了问题 vs 问题两侧风格天然一致对齐度改善来自这里同时查询侧不产生任何 LLM 调用。最小实现从零搭建 HyPE 向量检索流程git clone https://gitcode.com/GitHub_Trending/ra/RAG_Techniques依赖安装只需一条命令pip install faiss-cpu futures langchain-community python-dotenv tqdm教程的关键参数集中在 HyPE Notebook 的常量区语言模型默认 gpt-4o-mini嵌入模型默认 text-embedding-3-small分块 CHUNK_SIZE1000、重叠 CHUNK_OVERLAP200跑之前需要在 .env 里配置 OpenAI 密钥。核心管线分四步encode_pdf(path, chunk_size, chunk_overlap)读 PDF、切块、清洗得到待处理文本块列表。generate_hypothetical_prompt_embeddings(chunk)LLM 按固定提示词生成问题清单嵌入模型对整批问题向量化。prepare_vector_store(chunks)线程池并行处理各块用 L2 内积索引构建 FAISS 向量库每个问题向量都绑回所属原文块。检索器设置as_retriever(search_kwargs{k: 3})取 top 3 结果并对命中的同一文本块去重。仓库的 all_rag_techniques_runnable_scripts/HyPE_Hypothetical_Prompt_Embeddings.py 是同一套逻辑的脚本版方便脱离 Notebook 环境调试。HyPE 效果数据42 与 45 两个关键数字多组数据集上的评测显示HyPE 相比标准 RAG上下文检索精度最高提升 42 个百分点声明召回率最高提升 45 个百分点而查询端因为不再依赖 LLM 现场生成耗时与普通向量检索基本持平。需要留意的是最高二字——实际收益随语料类型和查询风格分布波动建议先在自己的测试集上量一遍。调优技巧分块大小、问题数量与向量库选型分块可以更大既然一个块挂多个问题向量块内信息更多不会像标准 RAG 那样显著稀释向量方向。教程默认 1000 token 起步可按文档信息密度上调但单块内主题过杂会拉低生成问题的质量这是上限所在。问题数量跟着密度走段落信息密度低就少生成几条避免空泛问题稀释语义覆盖密度高则多生成。解析要防脏输出教程默认 gpt-4o-mini 输出较规整直接按换行拆分即可换用 Ollama 等本地小模型时问题列表常带项目符号或编号建议加一层正则清洗。向量库选型FAISS 轻量、本地即可跑通语料上百万条或有过滤、多节点需求时再考虑 Milvus 这类服务化方案。适用边界HyPE 什么时候值得上代价集中在索引侧每个文本块都要一次 LLM 调用文档量大时这一步的花费和耗时最值得关注查询侧则完全零 LLM 调用检索速度与标准 RAG 持平。因此它最适合语料相对固定、问题句式可预测的场景比如产品知识库、教材问答语料频繁变动且索引预算有限时要权衡重建索引的频率。HyPE 也不是独占策略可与重排序、查询变换等手法叠加。这个仓库汇总了 42 个以上可运行的 RAG 技巧教程HyPE 只是其中之一同仓库还有 HyDE、重排序、命题分块等可对照实验的 notebook便于做 A/B 验证。落地的合理路径先跑通 HyPE 的 notebook再准备 20 条以上来自真实用户的问题做基准对比标准 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考