在基础的 RAG 流程中，检索阶段通常只依赖向量相似度得分来决定返回哪些文档片段。这种做法能快速找到语义相近的内容，但在真实业务场景中，“语义相关”并不总是等于“对用户最有用的信息”。一个员工的提问可能会召回多条相关政策，但哪一条是他真正应该看到的？这就需要在检索以后，再根据业务逻辑对结果进行一次重排序。
业务规则加权排序，就是在向量相似度得分的基础上，叠加人为定义的权重和排序逻辑，让检索结果更好地贴合实际应用需求。
1. 为什么需要业务规则干预
纯语义检索在处理以下情况时存在盲区：
- 时效性优先的业务：比如公司的差旅政策刚刚更新，但旧版文档仍与问题高度相关，只凭语义得分很难保证新版排在前面。
- 权限与可见性：某些文档只对特定部门或职级的员工开放，但向量数据库无法自动感知用户身份。
- 资产优先级：操作手册中的“安全警告”应当比“功能说明”更靠前，即便后者的语义相似度更高。
- 业务合规要求：法律或审计规定某些信息必须优先展示，比如合同解除条件、风险提示。
因此，检索后的业务加权排序是将搜索从“技术合理”变为“业务正确”的关键一步。
2. 常见的业务信号与权重
可以在检索环节输出的原始结果上，为每条候选片段附加一个业务评分。常见的信号包括：
| 信号类型 | 说明 | 示例 |
|---------|------|------|
| 文档时效性 | 更近的更新/生效日期得分更高 | 政策文档发布日期的衰减权重 |
| 用户身份 | 根据当前用户的部门、职级、权限加权 | 财务部员工看到财务细则的权重提升 |
| 内容类型 | 不同类型内容有不同基础权重 | 安全告警 > 操作步骤 > 背景介绍 |
| 引用热度 | 被频繁引用或查看的片段应提升权重 | 高频问题 FAQ 加权 |
| 规则匹配 | 硬性匹配特定关键词或标签 | 提问中包含“退款”时，退款政策置顶 |
| 来源权威性 | 正式签发的文档 > 内部讨论记录 | 法务部盖章的合同条款 > 团队备忘录 |
3. 加权排序的计算方式
最简单的做法是线性加权求和。假设向量检索返回每个片段有一个相似度得分 sim_score，以及若干业务维度得分 biz1, biz2，最终得分可以表示为：
final_score = sim_score * w_sim + biz1 * w1 + biz2 * w2 + ...通过调节权重系数，可以控制语义相关性 vs 业务优先级的平衡程度。权重一般需要经过少量实验和实际反馈来调整，不追求一次配准。
更复杂的场景也可以使用乘法加权或分步排序，例如强制保留安全告警在前三名，其余结果再按相似度排序。
4. 一个真实场景示例
某保险公司理赔助手系统，当员工查询“车辆涉水理赔”时，向量检索可能返回：
- 《机动车综合险条款》第12条（相关度 0.92）
- 《常见理赔误区 FAQ》第3问（相关度 0.89）
- 《2022年旧版条款补充说明》（相关度 0.87）
- 《涉水险告知书》（相关度 0.85）
如果仅按相似度排序，条款正文排第一，这本身没问题。但业务上有一条规则：“有告知书时必须优先展示，以提醒业务员先完成告知流程。”通过加权排序，给类型为“告知书”的文档额外 +0.2 权重，《涉水险告知书》的最终得分会显著提升，排到第一或第二。同时，可以对发布超过两年的文档做小幅降权，使旧版补充说明自然下沉。
5. 实施注意事项
- 不要过度设计：从一到两个最明确的业务信号开始（如时效性、文档类型），逐步调整。
- 保持可解释：在日志中记录最终得分的组成，方便排查是哪个环节导致了不理想的排序。
- 结合人工反馈闭环：如果有“这段内容没有帮助”的用户反馈按钮，可以收集数据，反向调整权重甚至信号设计。
- 做好降级方案：当业务规则无法获取必要元数据时（如用户身份信息缺失），应退回到纯语义排序，保证系统可用。
业务规则加权排序让 RAG 系统从单纯的“找相关内容”进化到“找对业务最有用的内容”。在知识库规模不大时，提升可能不明显；但当文档数量积累到成千上万条后，好的排序策略会直接决定用户是“一次找到答案”还是“在结果里翻找半天”。