RAG 的核心问题：为什么知识库检索结果不准，从 chunk 策略到 embedding 模型选型
很多团队在建设 RAG 时，最先关注的通常是生成模型：
- 使用哪一个大模型回答
- 在哪个平台中搭建
- 提示词应该如何编写
但在正式运行后，最常见的问题往往不是“模型不会回答”，而是“系统根本没有检索到正确资料”。
换句话说，RAG 的核心问题通常不在生成端，而在检索端。
如果检索结果本身不准，那么后续模型越强，反而越容易在错误上下文之上生成看似合理、实际偏离的问题答案。
本文将围绕这一问题展开：为什么知识库检索结果经常不准，以及从 chunk 策略到 embedding 模型选型，企业在实践中应如何理解与处理。
一、为什么 RAG 经常表现“不准”
RAG 的理想流程通常是：
用户提问
→ 系统从知识库检索最相关内容
→ 模型基于这些内容生成回答
问题主要集中在第二步。现实中，检索不准通常有三种典型表现：
- 资料明明存在，却没有被检索到
- 检索命中了内容，但不是最关键的那一段
- 检索返回了很多片段，但噪音过多，反而降低回答质量
很多团队会把这些问题归因于“大模型不够稳定”，但实际更常见的原因通常包括：
- 文档切分方式不合理
- 数据清洗不足
- 用户提问与文档写法存在明显语义落差
- embedding 模型与业务语料不匹配
- 检索参数没有根据场景进行调优
二、第一层问题：chunk 策略决定检索上限
RAG 的基础动作之一，是将长文档切分为多个 chunk，再对这些 chunk 进行向量化与检索。
问题在于，文档一旦被切开，原本属于完整上下文的语义关系就有可能被破坏。
一个典型例子
原始文档中的句子可能是：
- “员工在入职满六个月后可获得 10 天年假。”
如果在切分后只保留：
- “六个月后可获得 10 天”
这段话虽然还保留了部分信息，但在脱离上下文后，其真实含义已经变得模糊。它究竟是在描述年假、补贴、试用期还是培训安排，系统并不能自然判断。
这就是很多 RAG 系统最常见的第一类问题：信息仍然存在，但切分后语义不再完整。
三、chunk 不是越小越好，也不是越大越好
在很多实践中，团队容易形成一种直觉：把 chunk 切得更小，检索就会更精确。
但实际情况并不是这样简单。
chunk 太小的问题
- 文脉丢失
- 一条完整规则被切成多个碎片
- 检索命中后，模型拿到的是不完整上下文
chunk 太大的问题
- 噪音增加
- 多个主题被混在同一个片段中
- 检索虽然命中，但真正关键的信息被埋没在长段落之中
因此，chunk 策略的本质是在平衡两件事：
- 语义完整度
- 检索聚焦度
更合理的实践方式
不同文档类型，通常应该采用不同切分方式：
- 制度类文档：按条款或章节切分
- FAQ 类文档：按问答对切分
- 合同类文档：按条款切分
- 产品文档：按功能点或主题切分
也就是说，更有效的 chunk 策略通常不是固定字数，而是基于文档语义结构进行切分。
四、第二层问题：提问方式与文档写法之间存在明显落差
RAG 不准的另一个常见原因，是用户问题与知识库文档在表达方式上的差异。
例如用户会直接提问：
- “休假有几天？”
- “这个能报吗？”
- “台风时该注意什么？”
而文档中的表达方式则往往更加正式：
- “年次有给休暇の付与日数”
- “旅費精算規程 第八条”
- “災害時の行動基準”
用户提问通常更口语化、更模糊、更压缩；文档写法则更正式、更完整、更专业。即使语义相关，两者在向量空间中的距离也未必足够接近。
这也是为什么越来越多团队会引入 Query Rewrite、HyDE 等增强策略：
- 先把用户问题改写成更接近制度语言或文档语言的形式
- 再用改写后的查询进入检索
从本质上看，这类方法是在弥合“提问方式”与“文档写法”之间的落差。
五、第三层问题：数据质量通常比模型选择更重要
很多 RAG 系统之所以表现不稳定，并不是因为策略不高级，而是因为底层数据本身就不够干净。
常见问题包括：
- 同一内容上传了多个版本
- 旧版和新版制度混在一起
- PDF 文字提取错误
- OCR 扫描质量不稳定
- 一个文档中混入多个不相关主题
- 页眉页脚、页码、签章等噪音进入正文
在这种情况下，再好的 embedding 模型也只能对低质量数据进行向量化。
因此，一个非常重要的原则是：
RAG 的检索质量，首先取决于数据入口是否足够干净。
上传前的清洗、去重、版本控制与结构整理，往往比后期复杂调优更值得优先投入。
六、为什么 embedding 模型选型非常关键
在很多平台中，embedding 往往被视为一个默认组件，似乎只要有就足够使用。
但实际上，embedding 模型直接决定了系统如何理解“相似”。
因为向量检索的本质，不是关键词匹配，而是 embedding 模型如何把文本映射到语义空间。
这意味着什么
同一句话，在不同 embedding 模型中，可能会形成不同的语义邻近关系。例如：
- 有的模型更擅长英文技术语料
- 有的模型更适合日文或中文业务文本
- 有的模型更适合短句查询
- 有的模型在长文上下文压缩上更稳定
如果企业知识库主要是制度、合同、内部规范等业务语料，却选择了并不适合这类文本结构的 embedding 模型，那么检索不准就是非常自然的结果。
七、embedding 模型应该如何评估
在企业实践中，embedding 模型选型通常至少应考虑四个维度。
1. 语言匹配度
知识库主要是什么语言，用户主要用什么语言提问。
如果知识库与用户查询语言存在差异，就需要重点关注模型在跨语言语义对齐上的表现。
2. 文本类型匹配度
是 FAQ、制度、合同、产品文档还是资讯文本，不同语料类型通常对应不同表现特点。
3. 长度与粒度表现
有的模型更适合短句匹配，有的模型在长段落语义压缩上更稳定。
4. 成本与速度
企业正式上线时，还需要考虑：
- 建库成本
- 重建索引成本
- 检索响应速度
- 是否支持本地或私有化部署
因此，embedding 模型选型不应只看“哪个最先进”，而应重点看“哪个最适合当前业务语料与实际部署条件”。
八、为什么单纯更换大模型通常无法解决 RAG 问题
当团队发现 RAG 表现不佳时，常见第一反应是更换更强的生成模型。
但如果检索拿到的上下文本身就不准确，那么再强的生成模型也无法从根本上解决问题。它能做的通常只有以下几种：
- 基于错误上下文生成错误答案
- 在噪音过多的上下文中生成偏离重点的答案
- 在资料不足时，用常识进行补全
这也是为什么在实际建设中，更推荐按照以下顺序优化：
- 数据清洗
- chunk 设计
- 查询改写或检索增强
- embedding 模型评估
- 最后再优化生成模型与提示词
九、一个更现实的优化顺序
如果企业正在建设内部 RAG 系统，建议优先按以下顺序排查问题。
第一步：检查数据质量
- 是否存在重复文档
- 是否混入旧版资料
- PDF 是否可稳定提取文本
- 内容是否按主题合理拆分
第二步：检查 chunk 策略
- 是否按语义结构而不是纯字数切分
- 是否存在上下文被切断的问题
- 是否出现一个 chunk 覆盖多个主题
第三步：检查查询方式
- 用户问题是否口语化、模糊化
- 是否需要 Query Rewrite 或 HyDE
- 多轮对话中是否需要做指代消解
第四步：检查 embedding 模型
- 是否适合当前语言
- 是否适合当前文档类型
- 是否做过实际对比测试，而不是直接使用默认选项
第五步：检查检索参数
- Top K 是否设置合理
- 是否存在重复片段挤占结果
- 是否需要重排序或附加检索策略
十、RAG 的本质不是“把资料塞进去”
很多人会把 RAG 理解为：
“只要把公司资料上传进去，AI 就会懂。”
但从系统角度看，RAG 更接近一套检索系统，生成模型只是这套系统的最后一层表达能力。
它的关键并不是“记住多少”，而是：
- 在正确的时机
- 从正确的位置
- 找到正确的上下文
- 再交给模型进行组织与输出
因此，RAG 的核心从来不是“有没有知识库”，而是“检索系统是否真正理解你的文档结构和用户问题”。
结语
知识库检索结果不准，通常不是单一问题，而是多个层面叠加的结果：
- chunk 切分方式不合理
- 数据质量不足
- 用户提问与文档表达差距过大
- embedding 模型与语料不匹配
- 检索参数未围绕业务场景调优
所以，RAG 的核心问题并不是“怎么让模型更会回答”，而是：
怎么让系统先找到真正应该被回答的内容。
一旦把这一顺序理清，很多原本看起来像“模型不够聪明”的问题，都会被还原为更具体、也更适合被解决的检索工程问题。