Embedding 不够用了？企业知识库为什么需要 RRF

当 RAG 大行其道的时候很多人对企业知识库的理解也逐渐简化成了一条固定流水线文档切块→ 生成 Embedding→ 写入向量数据库→ 相似度搜索现在 AI 真正在各行各业的企业内部落地之后大家发现 Embedding 已经不够用了企业知识并不只存在于文档中它还分散在数据库、Wiki、代码仓库、IM、工单和邮件里。每种数据源也都有自己的结构也有最适合自己的检索方式。也就是说当前真实企业对知识库的诉求已经变成了当来自十几种异构数据源的检索器各自返回一份结果时如何得到一份统一而可靠的答案注这里说的Embedding 不够用了并不是指向量检索失去价值而是指它无法独立承担整个企业知识库的检索任务。一、为什么一个向量数据库不够对于单一文档很多 Hybrid Search 检索策略通常是这样的Query ├── BM25 └── Vector Search ↓ RRF注BM25 是一种概率检索模型关于 BM25的详细介绍请点击放大下图。但是企业知识库真正面对的是异构检索。真实企业里的知识可能分散在不同的存储介质中PPT / Word / PDFExcel / CSV企业 Wiki业务数据库代码仓库企业微信 / Slack / 飞书工单系统邮件会议纪要API 文档监控与日志系统这些数据不仅格式不同连什么叫相关”都不一样。例如用户提问公司退款流程是怎样的最近有没有退款失败的问题这个问题可能同时需要Wiki 中的退款流程文档Word 中的财务制度数据库里的退款订单企业微信里的故障讨论代码库里的退款状态机工单系统中的退款失败案例此时一个向量数据库远远不够了。二、不同数据源需要不同检索策略由于数据源不同查询数据的场景不同检索数据的方法自然不同没有一种万能的检索。不仅如此同一个数据源也可能需要多种检索策略。例如用户查询Redis Cluster 的故障转移机制是什么针对文档库可以同时运行BM25 检索负责匹配 Redis、Cluster、failover、故障转移等特别适合专有名词、产品名、错误码和缩写。Embedding 向量检索负责理解主节点宕机后从节点如何接管即使文档中没有出现故障转移四个字也可能找到对应内容。同时结合元数据进行过滤或排序如 部门 基础架构更新时间 2025-01-01文档状态 已发布。此时BM25、向量检索和标题检索分别输出自己的排名列表再交给 RRF 融合。RRFReciprocal Rank Fusion倒数排名融合下面第四部分将详细介绍算法将这些排名融合给出一个单一的排序值指导排序方向。下面总结了一些企业内部常用的数据源的检索方式数据源典型内容更适合的检索方式Word/PDF/PPT制度、方案、报告、产品文档BM25、Embedding向量检索、标题与章节检索Excel/CSV结构化表格、指标、清单表名/列名检索、字段匹配、SQL、Schema EmbeddingWiki页面、目录、内部链接BM25、语义检索、标题检索、链接关系关系数据库订单、客户、交易、库存Text-to-SQL、字段检索、结构化过滤代码库函数、类、配置、错误码ripgrep、符号搜索、BM25、代码向量检索企业微信/飞书对话、决策、故障讨论关键词检索、语义检索、时间与人员过滤工单系统问题、解决方案、状态记录BM25、标签过滤、语义检索邮件讨论、通知、附件主题/发件人过滤、BM25、语义检索日志系统错误、调用链、状态变化精确匹配、正则、字段查询、时间过滤三、不同检索分数不可直接比较有读者可能会问为什么一定需要RRF来融合这些排名直接比较排名分数就好了。现实情况则是不同检索器产生的分数通常没有可比性。我们来看一个例子。例如一次企业知识库查询返回文档 BM25退款流程.docx 18.7退款异常处理.pdf 13.4 向量检索退款故障复盘 0.87财务退款制度 0.82 代码搜索RefundService.go 245RefundStateMachine.java 198 企业微信搜索退款失败讨论群聊 92.1这里的18. **70.8724592.1**分别来自完全不同的评分体系。它们可能代表BM25 相关性余弦相似度代码搜索启发式得分IM 搜索系统内部得分。直接相加没有明确意义。即使先做归一化也会面临很多问题不同系统分数分布不同某些检索器分数集中在 0.80.9某些检索器范围可能是 01000分数随索引规模和版本变化不同数据源很难统一校准新增一种数据源时需要重新调参。而 RRF 则绕开了这个问题它不比较原始分数只比较每个结果在自己列表中的排名。四、RRF 如何融合多种企业数据源我们先来看下 RRF 算法的数学表达注k 主要用来减弱第一名与后续名次之间的分差避免某个检索器的头部结果对最终排序产生过强影响。RRF 并不是新出现的算法它诞生于 2009 年信息检索领域对多排序器融合的研究由 Gordon Cormack、Charles Clarke 和 Stefan Büttcher 提出。它的核心思想是与其融合不可比较的分数不如融合稳定可靠的排名。这个简单而有效的思路也使它在今天的 Hybrid Search 和 RAG 系统中重新焕发了生命力。关于 RRF 算法更多介绍可以点击下图简单概括来 RRF 的作用是如果一个结果被多个独立检索器共同认为相关通常比只被某一个检索器排在第一更可靠。例如用户查询退款失败后系统如何处理几个独立的检索器返回文档 BM251. **退款异常处理规范2. 财务退款制度3. 支付系统架构**文档向量检索1. **支付系统故障复盘2. 退款异常处理规范3. 退款状态说明**Wiki 检索1. **退款状态机2. 退款异常处理规范3. 支付服务说明**代码搜索1. **RefundStateMachine2. RefundRetryJob3. RefundService**经过 RRF 策略计算后退款异常处理规范虽然不是每个列表的第一名但它在多个列表中都靠前因此最终很可能获得最高分。**五、RRF 在企业知识库中的位置**企业内部知识分散是业务不断迭代以及场景扩张的自然结果真正可用的企业知识库应该允许知识继续在它原有的场景中产生如企业微信、代码仓库、Wiki 、业务数据库等系统负责用统一的数据接口与混合检索把证据组织起来。正如前文分享的一样企业通常很难把所有数据真正统一成一种形态。文档无法完全变成数据库数据库无法完全变成普通文本代码无法完全按自然语言理解IM 对话也不能脱离时间和参与者如果把所有数据源的数据转成文本 Chunk 并写入向量数据库则会损失大量原始结构Excel 的表头、单元格和行列关系* 数据库的 Schema、主外键和精确数值 * 代码的符号、类型和调用关系 * IM 的时间、人物和上下文 * Wiki 的目录与页面链接。 所以对于企业最经济的方式是各数据源尽量保留自身最有价值的结构和检索能力而不是全部强行降维成普通文本查询时输出各自的 Top-K 排名然后通过 RRF 策略进行融合。 企业知识库的底层可以是异构的但面向用户的结果排序必须是统一的而 RRF 便是这个统一层。下面来看一下企业知识库的整体流程图按照上面的知识库架构图企业知识库架构从用户查询到LLM输入需要经过三层处理第一层专用检索层每种数据源使用自己的检索方式检索数据第二层RRF召回融合层把多个异构检索器的排名融合起来第三层Reranker精排层使用 Cross-Encoder 或 LLM Reranker进一步判断结果和问题的真实相关性。注Cross-Encoder属于专用排序模型精确判断 Query 与文档的相关性LLM Reranker是利用大语言模型的理解能力对候选结果进行智能精排。在面向企业知识库的 RAG 系统中一条较完整的多路检索链路通常是Query │ ▼① 多路召回RecallBM25 / Dense / SQL / Code Search 等 │ ▼② RRF融合得到 Top100 │ ▼③ Reranker精排得到 Top10 │ ▼④ LLM生成答案六、企业落地的几个关键问题1 不是所有检索器每次查询都会运行Query Router并不是所有问题都需要搜索所有数据源。也就是说每次查询不是所有检索器都会运行这取决于前面的 Query Understanding 和意图识别模块。例如用户问上个月华东区退款率是多少这个问题则不需要搜索代码库和企业微信意图识别模块可以判断这更像结构化数据问题数据库检索执行Excel 报表执行Wiki 指标定义执行IM不执行代码库不执行对于被选中的检索器系统还可以根据查询意图动态调整其 RRF 权重。Query Router 的作用就是根据用户问题智能选择需要检索的数据源和检索器减少无效搜索提高召回质量和效率。2 基础 RRF 还需要解决数据源权重问题加权 RRF经典 RRF 默认每个列表地位相同但企业场景里不同数据源的可信度可能不同。例如员工报销标准是多少结果来源包括已发布的财务制度三年前的群聊某位员工的个人 Wiki测试环境数据库正式 HR 系统。这些结果不能简单视为同等可信于是引入了 Weighted RRF即加权 RRF其中 Wi 是检索器或数据源的权重。例如正式制度文档1.5官方 Wiki1.3业务数据库1.2企业微信讨论0.8历史邮件0.7注权重最好代表稳定的数据质量和权威性而不是用来弥补检索器本身的糟糕效果。3 跨数据源融合前必须先做实体对齐和去重数据治理同一份知识可能同时存在于Word 附件Wiki 页面企业微信群文件邮件附件PDF 导出版如果直接做 RRF这些重复内容可能占据多个位置。例如1. **退款制度.docx2. 退款制度.pdf3. Wiki退款制度4. 群文件退款制度最终版.docx**表面上看检索结果很多实际上都是一份内容。所以在 RRF 前后需要对数据进行实体对齐和去重方面的治理如下面这些操作都可以根据企业自身情况进行处理文档指纹内容哈希URL 规范化附件来源识别标题与内容相似度判断同一知识实体的版本合并最新版本识别。4 企业知识库里比相关性更重要的其他因素这里也没有银弹。需要注意的是 RRF 也不是万能解药。RRF 解决的是相关性融合但它不能单独解决整个企业搜索问题。最终排序还需要考虑下面这些关键因素权限用户无权访问的结果不能因为排名高就返回。新鲜度三年前的制度即使相关也可能已经失效。权威性正式发布的制度应优先于群聊讨论。数据质量OCR 错误、解析失败、缺少上下文的 Chunk 会影响结果。多样性Top 10 不应该全部来自同一篇文档的相邻 Chunk。业务范围用户问上海区域时不应返回广州规则。注权限通常不是加减分而是必须在召回和返回前进行硬过滤。七、总结企业知识库落地后面对的是文档、Wiki、数据库、代码仓库、IM、工单和日志等多种数据源每种数据源都有更适合自己的检索方式。RRF 的作用就是把这些不同检索器返回的结果统一融合。它不比较原始分数只看结果在各自列表中的排名。当然RRF 只是其中一环。前面还需要 Query Router 选择数据源后面还需要去重、权限校验和 Reranker 精排。最终企业知识库的效果取决于整套检索、融合和排序机制。这里给大家精心整理了一份全面的AI大模型学习资源包括AI大模型全套学习路线图从入门到实战、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等资料免费分享扫码免费领取全部内容1. 成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。这里我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。2. 大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF3. 大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。4. 2026行业报告行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5. 大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。6. 大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。7. 资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容