检索工程
“ 前置过滤 → 多路召回 → 结果融合 → Rerank 重排 → 阈值截断 → 上下文组装 → 拒答机制。
很多人一聊企业知识库 RAG，第一反应就是：把文档切块、做 Embedding、存进向量库，然后按相似度检索。
这个思路做 Demo 没问题，但真放到生产环境，基本不够用。
因为生产级 RAG 最怕的不是“完全搜不到”，而是下面几种情况：
搜到了，但不是用户真正要的内容
编号、型号、合同条款这种精确信息被漏掉
老文档压过新文档
用户检索到了不该看的内部资料
相关性很弱，但 LLM 还是硬编了一个答案
所以，生产环境里的 RAG 检索，绝对不能只靠单一向量相似度。
更可靠的做法是下面这条链路，逐层拆解。
01 · 先过滤：别一上来就全库搜索
生产级 RAG 的第一步，不是召回，而是缩小检索范围。
很多检索质量问题，其实不是模型不行，而是搜索范围太乱。
比如用户问一个产品手册里的问题，系统却把历史聊天记录、过期公告、其他部门文档都拿出来一起比相似度，最后当然容易答偏。
所以检索前必须做前置过滤。
常见过滤维度包括：
文档部门
文档类型
发布时间
版本号
权限角色
产品型号
地域
标签
文档 ID
这里面最重要的是两类。
第一，权限过滤。用户只能检索自己有权限看的内容。这个不是效果优化，而是安全底线。
第二，时效过滤。政策、活动、公告、产品版本说明这类内容，必须优先使用新文档。老文档要么降权，要么直接排除。
此外，还可以加入文档质量权重。
比如：
官方 SOP > 正式制度文档 > 培训材料 > 员工笔记 > 聊天记录
不同来源的可信度不一样，不能一视同仁。
02 · 召回不能只靠向量，要做混合检索
很多 RAG 项目效果差，最大的问题就是只做了向量检索。
向量检索擅长理解语义，比如用户口语化提问、同义表达、模糊描述，它都能处理得不错。
比如用户问：
离职之后社保怎么处理？
向量检索可能能找到：
员工离职后的社保停缴流程。
这就是语义召回的价值。
但向量检索也有明显短板。
它对下面这些内容经常不稳定：
产品型号
合同编号
订单号
法条编号
专业术语
人名
代码
精确关键词
比如用户问：
K5-230A 这个型号支持哪种滤芯？
如果只靠向量检索，它未必能稳定命中“K5-230A”这个精确型号。
这时候就需要关键词检索，也就是稀疏检索。
生产环境里最常见的是 BM25。
它不理解语义，但特别擅长字面匹配，尤其适合编号、术语、型号、专有名词。
所以企业 RAG 的标准搭配应该是：
向量召回 + BM25 召回。 一个负责语义理解，一个负责精确匹配。
这比单一路径稳定得多。
03 · 多路召回之后，要做结果融合
如果同时用了向量召回和 BM25 召回，就会得到两批候选结果。
问题来了：怎么合并？
最常用、也最稳的方案是RRF，叫 Reciprocal Rank Fusion，中文可以理解为“倒数排名融合”。
不用纠结公式，本质就是：
一个片段在多条召回路径里排名越靠前，它最终得分越高。
RRF 的好处是不用复杂调参。
向量检索觉得它重要，BM25 也觉得它重要，那它大概率真的重要。
相比人为设置“向量 0.6、关键词 0.4”这种权重，RRF 通常更稳，也更适合大多数企业 RAG 场景。
如果业务更复杂，还可以在融合时加入元数据权重：
新文档加分
官方文档加分
用户所在部门文档加分
低质量来源降分
这样召回结果就不只是“相似”，而是更接近“可信、可用、适合当前用户”。
04 · Rerank 是生产 RAG 里最不能省的一步
很多系统会犯一个错误：
向量库 Top5 直接塞给 LLM。
这样做很容易答非所问。
因为向量相似度只是粗排，它并不真正理解“这个 chunk 能不能回答用户问题”。
更稳的做法是：
先用多路召回拿到 Top20 到 Top50 个候选片段，再交给 Rerank 模型重排，最后只选 Top3 到 Top5 给大模型。
Rerank 常用的是 Cross-Encoder 交叉编码器。
它不是分别算 Query 和 Chunk 的向量距离，而是把：
用户问题 + 候选片段，成对输入模型，让模型直接判断相关性。
这一步通常能显著提升 RAG 效果。
常见选择包括：
BGE-Reranker
Jina Reranker
Cohere Rerank
轻量本地重排模型
如果是高隐私场景，也可以用小参数 LLM 做相关性判断。
比如让模型逐条判断：
这段内容是否能回答用户问题？
是否包含核心实体？
是否属于当前权限范围？
是否已经过期？
Rerank 之后，再做一次规则过滤，效果会更稳。
05 · 必须设置阈值，否则 RAG 会变成“有问必编”
生产级 RAG 还有一个核心机制：拒答。
很多系统只关注“怎么答”，但真正可靠的系统必须知道“什么时候不该答”。
如果重排之后，最高相关性得分仍然很低，就应该直接返回：
知识库暂无相关信息。
而不是把低相关片段塞给 LLM，让它硬拼一个答案。
这一步是控制幻觉的关键。
不同业务阈值也不一样。
合同、财务、法务、人事制度类：阈值应该更高，宁可少答，也不能乱答。
客服咨询、产品介绍类：可以适度放宽，让系统更积极地回答。
此外还可以设置最小召回数量。
如果有效片段少于 2 条，就要谨慎回答，甚至拒答。
这不是保守，而是生产系统必须有的安全边界。
06 · 复杂场景下，还要做 Query 增强
用户真实提问往往不标准。
比如他说：
怎么退会员？
但知识库里的表达可能是：
会员退费流程
会员取消规则
会员退款条件
会员服务终止说明
如果只拿原始 Query 去搜，可能召回不全。
所以中大型知识库里，经常会用 Query Expansion，也就是查询扩展。
做法是先让模型把用户问题改写成多条检索 Query：
原问题： 怎么退会员？
改写后： 会员退费流程、会员取消规则、会员退款条件、会员服务终止说明。
然后多 Query 并行检索，再合并结果。
这一步特别适合：
用户口语化表达多
知识库术语比较正式
同一个问题有多种叫法
需要跨多个文档找答案
还有一种更高级的方式叫 Self-Query Retrieval。
它会让 LLM 从用户问题里自动提取过滤条件。
比如用户问：
2025 年的报销规则是什么？
系统自动识别：时间：2025 年；文档类型：报销制度；主题：报销规则。然后自动加到 metadata 过滤条件里。
这对制度库、手册库、政策库非常有用。
07 · 长文档最好用父子 Chunk 召回
企业文档经常很长。
如果 chunk 切得太大，检索不精准；如果 chunk 切得太小，上下文又容易断。
解决办法是父子 Chunk。
简单说：
子 Chunk 负责检索
父 Chunk 负责提供上下文
比如：
父 Chunk 是一整个小节
子 Chunk 是小节里面 200 token 左右的小片段
检索时先用子 Chunk 精准命中问题点，再把对应父 Chunk 拿出来给 LLM。
这样既能保证召回精准，又不会丢上下文。
特别适合：
产品手册
技术文档
操作 SOP
制度文件
法务条款
08 · 复杂问答需要多跳检索
有些问题不是一个片段能回答的。
比如：
新员工入职后，什么时候可以申请转正，转正后薪资怎么算？
这个问题可能涉及：
入职制度
试用期规则
转正流程
薪资制度
这就需要 Multi-hop Retrieval，多跳检索。
第一轮先查入职和转正条件，拿到关键信息后，再生成第二轮 Query 去查薪资规则。
多跳检索适合复杂制度、技术排障、法律问答、医疗知识等场景。
但它也有成本，不建议一开始就做得太复杂。
先把基础检索链路做好，再按业务复杂度逐步加。
09 · Graph RAG 不是万能升级，而是特定场景的增强
现在很多人一聊高级 RAG，就会提 Graph RAG。
它确实有价值，但不是所有知识库都需要。
Graph RAG 适合知识之间强关联的场景，比如：
医疗知识
设备故障排查
金融风控
法律条款关系
大型企业组织知识
复杂产品系统
它的核心不是只搜文本，而是把实体和关系也建起来。
比如：
设备 A 关联故障 B，故障 B 关联部件 C，部件 C 关联维修流程 D。
这样系统可以顺着知识关系继续召回相关内容。
但 Graph RAG 建设成本更高，需要实体抽取、关系构建、图谱维护，不适合作为所有企业 RAG 的第一步。
我的建议是：
先把混合召回、Rerank、权限过滤、拒答机制做好，再考虑 Graph RAG。
不要一上来就为了“高级”而高级。
10 · 生产级 RAG 的最小可用架构
如果企业要搭一个真正可用的 RAG 系统，我建议最小版本至少包括这几层：
01 Metadata 前置过滤
解决权限、时效、文档范围问题。
02 向量 + BM25 混合召回
同时兼顾语义理解和精确匹配。
03 RRF 结果融合
把多路召回结果稳定合并。
04 Cross-Encoder Rerank
对候选片段做二次精排。
05 相似度阈值与拒答机制
相关性不足时不让模型硬编。
06 父子 Chunk 或章节级上下文组装
避免答案因为切块太碎而断裂。
这套架构已经能覆盖大多数企业知识库场景。
更高级的 Query 改写、多跳检索、Graph RAG，可以作为后续增强项。
11 · 落地选型速查表
| 策略层级 | 是否生产必选 | 适用规模 | 核心收益 |
|---|---|---|---|
| 元数据前置过滤 | 必选 | 所有规模 | 权限隔离、降噪、提速 |
| 向量 + BM25 混合召回 | 必选 | 所有规模 | 兼顾语义理解和精确匹配 |
| RRF 结果融合 | 必选 | 所有规模 | 无需复杂调参，融合稳定 |
| Cross-Encoder Rerank | 必选 | 所有规模 | 大幅提升召回质量 |
| Query 改写扩展 | 推荐 | 中大型知识库 | 解决口语化、模糊提问 |
| Self-Query 自查询 | 推荐 | 制度库、手册库 | 自动提取过滤条件 |
| 父子分层 Chunk 召回 | 推荐 | 长文档较多 | 解决切块碎片化 |
| Multi-hop 多跳检索 | 按需开启 | 复杂问答场景 | 处理跨文档复杂问题 |
| Graph RAG 图检索 | 按需开启 | 强关联知识领域 | 挖掘隐性关联知识 |
12 · 生产 RAG 最常见的几个坑
最后，把生产环境里最容易踩的坑单独拎出来。
01 只做向量检索，不加 BM25
结果就是型号、编号、合同条款、专业术语经常漏召回。
02 跳过 Rerank，直接把 Top5 丢给 LLM
向量相似度只是粗排，不代表片段真的能回答问题。
03 没有相似度阈值
只要用户问，系统就强行回答，最后幻觉越来越严重。
04 入库和查询 Embedding 版本不一致
这是很隐蔽但很致命的问题。Embedding 模型一换，向量空间就可能偏移，检索效果会断崖式下降。
05 未做权限过滤
这不是效果问题，而是安全事故。企业知识库必须先解决“谁能看什么”。
06 固定切块，不考虑父子结构
关键信息被切断，上下文缺失，最后 LLM 只能靠猜。
/// · 最后说一句
RAG 真正难的地方，不是把文档塞进向量库。
真正难的是：
在正确的范围里，找到足够相关、足够可信、足够新的内容，并且在证据不足时敢于拒答。
所以，生产级 RAG 一定不是单点技术，而是一整套检索工程。
如果只做向量相似度，Demo 可能看起来不错；但只要进入真实业务环境，问题很快就会暴露：
编号搜不到
老文档乱入
权限隔离缺失
Top5 结果不相关
LLM 拿着弱证据开始编
真正可靠的企业知识库 RAG 系统，应该从第一天就按这条链路设计：
过滤 → 召回 → 融合 → 重排 → 截断 → 组装 → 拒答。
这才是企业知识库从 Demo 走向生产的关键。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～