用 WorkBuddy 落地生产级 RAG：混合检索 + 重排序 + 查询改写的完整工作流

摘要

RAG（检索增强生成）是当下最落地的 AI 应用形态——让大模型先查资料再回答，从根本上减少胡说。但「Demo 级 RAG」和「生产级 RAG」之间隔着一条鸿沟：Demo 用向量相似度搜一下就完事，真实业务里用户问得含糊、文档长得离谱、答案要精确到条款。本文用 WorkBuddy 作为编排端与智能预处理层，系统性拆解把 RAG 从「能跑」做到「好用」的三板斧——混合检索、重排序、查询改写，并补充评测方法、成本延迟权衡、部署架构与完整提示词模板。读完你能搭出一个检索准、答得稳、敢上生产的 RAG 系统，而不是又一个只能跑 hello world 的玩具。

一、为什么 Demo 级 RAG 一到生产就翻车

先泼盆冷水。很多教程教你这条最短路径：文档切片 → 向量化 → 存库 → 用户提问 → 相似度搜 top-k → 塞给模型。跑通 hello world 很爽，但一上真实数据就露馅。下面三类失败是最常见的：

• 语义近但答非所问：用户问「上个月华南区退货率怎么算的？」，你的向量库只存了「退货率计算公式」那一段，搜出来的却是「华南区销售总结」里的无关句子——意思沾边，但给模型的就是错的。
• 专有名词召回暴跌：文档里大量产品代号、内部缩写、标准编号（比如某监控标准「GB/T 28181」），通用向量模型没见过，相似度算出来一片糊。
• 口语对不齐书面语：用户问得很长很口语，和文档里规整的书面表达对不上，相似度很低，直接搜不到。

这些不是模型不行，是检索环节太单薄。生产级 RAG 的核心认知只有一句：生成质量的上限，由检索质量决定。检索拉胯，模型再强也救不回来。下面三板斧就是冲着检索质量去的。

二、第一板斧：混合检索（Hybrid Search）

纯向量检索（dense retrieval）擅长语义匹配，但有个致命弱点：对精确关键词不敏感。比如用户搜「GB/T 28181 协议」，向量模型可能把它当成普通文本，召回一堆讲「视频监控标准」的泛泛内容，却漏掉正好写着「GB/T 28181」那一页。

解决方法：向量检索 + 关键词检索（BM25 这类稀疏检索）双路并行，再融合。

• 向量检索：抓语义，「意思相近」就能召回，适合长句、模糊表达。
• BM25 关键词检索：抓字面，「这个词出现就相关」，对专有名词、编号、型号、日期极其精准。

两者取并集或加权融合，既不让关键词漏检，也不让语义误判。实战中，混合检索相比纯向量，召回率（Recall@10）通常能提升 15%~30%，具体幅度视数据而定。

融合算法选 RRF 最稳。RRF（Reciprocal Rank Fusion，倒数排名融合）不依赖两个检索器的分数量纲是否一致，只认排名：

融合公式（示意）： 最终得分(doc) = Σ 1 / (k + rank_i(doc)) 其中 rank_i 是第 i 路检索里该文档的排名，k 通常取 60。 两路都排第一的文档得分最高，只在一路出现的也能凭排名拿到分。

用 WorkBuddy 怎么落地这一步：让 WorkBuddy 帮你生成一段把两路结果做 RRF 融合的脚本骨架，思路是「给我一个函数，输入是向量检索的排名列表和 BM25 的排名列表，用 RRF 公式融合排序，返回 top-k 文档 id」。WorkBuddy 会产出可直接用的代码骨架，你再接自己的检索后端。如果两路分数需要做加权（而非纯排名融合），也可以让 WorkBuddy 帮你写带权重的线性融合版本。

三、第二板斧：重排序（Re-ranking）

混合检索后你拿到 top-20 甚至 top-50 的候选。但生成时只喂 top-3 或 top-5 给模型最稳——塞太多噪声反而让模型答偏。问题来了：top-20 里谁最相关？这时候用「粗排 + 精排」两阶段：

• 粗排：向量 + BM25，快，召回面大，但精度一般，负责「别漏」。
• 精排：用专门的 Cross-Encoder 重排序模型，把「用户问题 + 每个候选文档」拼一起做深度相关性打分。它比双塔向量模型看得更细，能判断「问题里每个词是否真的被文档回答」。

精排模型通常比向量模型慢，所以只对粗排后的几十条做，成本可控。这一步能把最终 top-5 的相关性再提一大截。

没部署重排模型时的临时方案：用 WorkBuddy 自身做「轻量重排」——把候选文档和原问题一起发给它，让它按相关性打分并排序。完整提示词模板：

你是一个检索相关性裁判。下面有用户问题和若干候选文档片段。 请逐条评估每个片段对回答用户问题有多大帮助， 给出 0-10 的相关性分数，并说明依据，最后按分数从高到低排列文档编号。 只做排序，不要回答问题本身。

用户问题：<粘贴问题> 候选文档： <片段1>... <片段2>...

返回的结果你取前几名喂给最终生成。效果已经比纯向量好很多。正式生产建议还是接一个 Cross-Encoder，稳定性和延迟都更可控。

四、第三板斧：查询改写（Query Rewriting）

很多检索失败，根源在用户问得不好。用户问「那个退货的怎么弄」，文档里写的是「无理由退换货流程」。字面完全对不上。查询改写就是在大检索之前，先让模型把用户问题「翻译」成更适合检索的版本：补全指代、展开缩写、拆成多个子查询。

三种改写策略：

1. 指代消解与补全：把「那个」「它」替换成上下文里的真实实体。
2. 多查询展开（Multi-Query）：把一个复杂问题拆成 3~5 个子问题，分别检索，合并结果。比如「华南区退货率怎么算」拆成「退货率定义」「华南区数据范围」「计算公式」。
3. 假设性文档生成（HyDE）：让模型先「编」一个假设性答案，再用这个假答案去检索——因为假答案里的用词更接近真实文档分布，反而能召回更准。这是个反直觉但有效的技巧，适合文档表达和提问表达差异大的场景。

用 WorkBuddy 落地查询改写：把这一步做成固定预处理提示词，每次用户提问先过一遍。完整模板：

你是检索系统的查询优化器。请把用户的原始问题改写成 3 个独立、具体、便于向量检索的子查询。 要求：补全所有指代和缩写，保留关键实体名词， 不要回答原问题，只输出 3 个子查询，每行一个。

原始问题：<用户问题>

改写后的多个子查询分别走混合检索，结果合并去重，再精排。这一套下来，含糊提问的召回质量会肉眼可见地变好。

五、把它们串成一条工作流（含端到端案例）

生产级 RAG 的检索链路长这样：

1. 查询改写：原始问题 → 3 个子查询（WorkBuddy 提示词预处理）
2. 混合检索：每个子查询同时走向量 + BM25，RRF 融合
3. 候选合并：多路结果去重，取 top-30
4. 重排序：Cross-Encoder 或 WorkBuddy 轻量精排，取 top-5
5. 生成：top-5 片段 + 原问题 → 大模型作答，并要求「只依据给定片段，无依据就明说」

一个端到端案例（示意，非真实数据）：某企业内部制度问答，用户问「试用期员工提前三天辞职要赔钱吗？」

• 改写层把它拆成：「试用期辞退赔偿规定」「员工主动离职通知期」「试用期离职违约金条款」三个子查询。
• 混合检索在制度库里同时命中「劳动合同法摘录」和写着「试用期」字样的条款页。
• 重排后最相关的是「试用期解除情形与补偿」那一段。
• 生成层只依据该片段作答，明确给出「依据第 X 条……」，没有依据的部分主动说「材料未提及」。

对比纯向量直接搜「辞职赔钱」，原方案大概率召回一堆讲「正式员工离职补偿」的泛内容，答偏。这就是三板斧串起来的价值。

每一步都可用 WorkBuddy 编排：改写和轻量重排直接用提示词，检索和精排接你自己的服务。WorkBuddy 在这里扮演「胶水 + 智能预处理」的角色，把零散组件串成流水线。

六、被忽视的工程细节

1. 切片策略别一刀切：固定 500 字切，很可能把一张表或一个步骤拆两半。按标题层级或语义边界切更稳。可以让 WorkBuddy 帮你设计切片规则文档，明确「遇到表格整体保留」「代码块不拆」等约束。
2. 元数据过滤比检索更准：如果用户限定「只看 2026 年的合同」，先用元数据（年份字段）过滤再检索，比让向量模型自己判断年份靠谱得多。元数据过滤是检索前的第一道闸。
3. 嵌入模型要选对：中文场景优先选在中文语料上训过的嵌入模型；领域术语多的，考虑用领域数据微调嵌入模型，召回率提升明显。
4. 要求模型「无依据就明说」：生成提示词里强制加一句「如果给定材料不足以回答，请明确告知用户，不要编造」。这是防幻觉的底线，没有商量余地。
5. 别迷信向量库默认参数：HNSW 的 efSearch、IVF 的 nprobe 这些参数直接决定召回率和延迟，要按数据量调，不能拿默认值上生产。

七、怎么评测 RAG 到底好不好

没有评测的 RAG 优化就是瞎调。生产前必须建一套评测：

• 建评测集：准备 50~100 条真实问答（问题来自真实用户日志，答案由人工标注「该用哪些片段、正确结论是什么」）。
• 看检索指标：Recall@K（前 K 条里有没有包含正确答案的片段）、MRR（正确答案排第几）。三板斧主要改善这两项。
• 看生成指标：答案准确率、是否有幻觉、是否引用了正确片段。可以再用一个强模型做「评审员」自动打分。
• 每次改动都跑一遍：改了切片大小、换了嵌入模型、调了重排阈值，都重跑评测集对比，用数据说话而不是拍脑袋。

自动评测也可以用 WorkBuddy 跑：把「标准答案片段」和「模型实际引用片段」发给它，让它判断覆盖度；把「模型回答」和「人工标准答案」发给它，让它打分并说明扣分项。

八、成本与延迟的权衡

三板斧不是免费午餐，每加一层都有代价。典型权衡：

• 查询改写：多一次模型调用，延迟 +0.5~1 秒，但召回质量提升显著，值得。
• 混合检索：BM25 几乎零成本，向量检索看库大小，整体可控。
• 重排序：Cross-Encoder 是最贵的环节，只对粗排后几十条做，避免对全库跑。

经验法则：先上「混合检索 + 查询改写」，这两层性价比最高；重排序等召回率达标但有噪声时再上。WorkBuddy 的轻量重排适合早期验证，量上来后换专用模型。

九、常见踩坑与排错

• 召回全是无关内容：先查切片——是不是把段落切得太碎，语义不完整；再查嵌入模型是否适配你的语言/领域。
• 改写后反而搜不到：可能是子查询拆太细或引入了文档里没有的词。限制子查询数量（3 个左右），并要求「保留关键实体名词」。
• 重排后 top-1 变错：检查精排模型输入格式，确认「问题+片段」拼接正确、没有截断。
• 答案编造：九成是生成提示词没加「无依据就明说」，或喂给模型的片段本身就不够。
• 延迟太高：优先砍重排序范围（top-50 降到 top-20），其次把改写改成异步或缓存。

十、总结

RAG 从 Demo 到生产，差距全在检索。三板斧记牢：

• 混合检索解决「语义对但关键词漏」；
• 重排序解决「候选多但最相关的排不上」；
• 查询改写解决「用户问得烂导致搜不到」。

用 WorkBuddy 串起这条流水线，你得到的不是玩具，而是一个检索准、答得稳、敢上生产的 RAG 系统。下一步可以往「多模态 RAG（图文混合）」「Agentic RAG（模型自主决定查几次）」演进，那是下一个阶段的玩法。本文给出的提示词模板和评测思路，足以支撑你把第一版生产级 RAG 跑起来。