企业级 RAG 系统为什么不能只做“文档向量化”：从检索、重排到答案可信度优化

1. 文章背景：为什么这个主题重要

很多团队第一次做知识库问答系统时，通常会采用一条非常直接的路线：

• 把 PDF、Word、网页、Markdown 等文档解析出来；
• 按固定长度切成 chunk；
• 调用 Embedding 模型生成向量；
• 存入向量数据库；
• 用户提问时做相似度检索；
• 把 Top-k 文档片段拼进 Prompt；
• 最后让大模型生成答案。

这个流程可以很快做出一个 Demo，也能在一些简单问题上表现不错。但一旦进入企业级场景，就会出现大量问题：

• 用户明明问的是制度细节，但系统召回的是泛泛介绍；
• 向量相似度最高的内容，不一定真正能回答问题；
• 文档版本很多，模型引用了过期制度；
• 检索结果里混入了用户没有权限查看的资料；
• 大模型回答很流畅，但没有明确依据；
• 答案看起来合理，实际和原文不一致；
• Demo 阶段效果不错，上线后业务方不敢用。

这些问题的根源在于：企业级 RAG 系统不能只做“文档向量化”。

文档向量化只是 RAG 的第一步，它解决的是“如何把文本变成可检索的语义表示”。但企业真正需要的是一个完整的知识问答系统，目标不是“搜到相似文本”，而是“基于可信证据生成可靠答案”。

一个可落地的企业级 RAG 系统，至少要回答以下几个问题：

• 文档如何解析，表格、图片、标题层级怎么处理？
• chunk 如何切分，才能兼顾召回率和上下文完整性？
• Embedding 模型怎么选，中文、英文、代码、表格是否都适配？
• 只用向量检索够不够，是否需要 BM25、关键词和结构化检索？
• 检索结果如何重排，如何把真正有用的证据放到前面？
• 大模型回答时如何减少幻觉，如何强制基于证据？
• 答案如何引用来源，如何让业务人员可追溯？
• 系统如何评估，如何知道 RAG 是否真的有效？
• 权限、安全、延迟、成本、可维护性如何处理？

所以，RAG 不是一个简单的“向量数据库项目”，而是一个涉及文档工程、检索系统、排序模型、Prompt 设计、大模型生成、权限控制和评估体系的综合工程。

---

2. 核心问题：实际开发中会遇到什么问题

2.1 只做向量检索，召回不稳定

Embedding 检索的优势是语义匹配。例如用户问“怎么申请报销”，文档里写的是“费用报销流程”，向量检索大概率能找出来。

但企业文档里有很多内容并不适合只靠语义相似度：

• 合同条款编号：3.2.1、4.5.6；
• 产品型号：A100、BMS-2024、X7-Pro；
• 系统错误码：ERR_502、AUTH_403；
• 人名、项目名、客户名；
• 日期、金额、版本号；
• 表格字段；
• 制度条款；
• API 参数名；
• 日志关键词。

这些内容往往需要关键词检索、精确匹配或结构化查询。只依赖向量检索，会导致召回结果看起来相关，但缺少关键证据。

2.2 chunk 相似，不代表 chunk 有用

很多 RAG 系统直接使用向量检索 Top-k 结果。但相似度高，不等于能回答问题。

例如用户问：

离职员工未休年假如何折算？

系统可能召回以下片段：

召回内容	表面相关性	是否真正有用
年假申请流程	高	一般
员工离职流程	高	一般
薪资结算说明	中	有用
未休年假折算规则	中	最有用
考勤管理制度	中	部分有用

从语义上看，“年假申请流程”很相关，但真正回答问题的是“未休年假折算规则”。如果没有 Rerank，最有价值的证据可能排不到前面。

2.3 大模型不是天然的证据判断器

有些开发者会认为，只要把多个 chunk 都塞给大模型，大模型自然会判断哪个重要。实际情况并不稳定。

大模型可能出现以下问题：

• 混合多个文档，生成一个原文中不存在的结论；
• 忽略文档版本和生效时间；
• 把不适用的规则套用到当前问题；
• 在证据不足时仍然给出肯定回答；
• 将检索到的背景知识误当成直接答案；
• 对冲突信息不做提示。

所以企业级 RAG 不能把“证据选择”和“可信度判断”全部交给大模型。检索、重排、证据过滤和答案校验都需要独立设计。

2.4 没有评估体系，系统无法持续优化

很多 RAG 项目上线后，效果只能靠人工感觉判断：

• 业务方说“这个回答不太对”；
• 测试人员随机问几个问题；
• 开发者手动调 Top-k、chunk size、Prompt；
• 改完之后也不知道整体效果提升还是下降。

这会导致系统无法稳定迭代。

企业级 RAG 必须建立评估体系，至少要区分：

• 检索是否召回正确文档；
• 重排是否把正确证据排到前面；
• 生成答案是否忠于原文；
• 答案是否完整；
• 答案是否可追溯；
• 无答案问题是否能拒答；
• 不同版本迭代是否真的提升。

没有评估，就没有工程化。

---

3. 基础概念：用工程视角解释关键概念

3.1 RAG 到底解决什么问题

RAG 的全称是 Retrieval-Augmented Generation，即检索增强生成。它的基本思想是：大模型回答问题前，先从外部知识库检索相关资料，再让模型基于资料回答。

它主要解决三个问题：

• 大模型训练数据不包含企业私有知识；
• 大模型知识可能过期；
• 大模型容易幻觉，需要外部证据约束。

一个简单 RAG 流程如下：

用户问题
  ↓
问题改写 / 查询扩展
  ↓
检索知识库
  ↓
重排候选文档
  ↓
构造 Prompt
  ↓
大模型生成答案
  ↓
答案校验 / 引用来源
  ↓
返回用户

3.2 Embedding：把文本映射到向量空间

Embedding 模型的作用是把文本转成向量，使语义相近的文本在向量空间中距离更近。

例如：

• “如何申请报销”
• “费用报销流程是什么”
• “员工怎么提交报销单”

这些句子表达不同，但语义接近，Embedding 后向量距离应该较近。

但 Embedding 不是万能的。它更擅长语义相似，不一定擅长精确匹配。因此，企业级 RAG 通常不应该只依赖 Embedding。

3.3 向量数据库：负责相似向量检索

向量数据库主要负责存储和检索向量。常见能力包括：

• 向量写入；
• Top-k 相似度检索；
• 元数据过滤；
• 分区索引；
• 混合检索；
• 增量更新；
• 删除和重建索引。

在企业场景中，向量数据库不是只存向量，还要存元数据。例如：

元数据	作用
document_id	关联原始文档
chunk_id	定位文档片段
title	保留标题语义
source_url	支持引用来源
version	区分文档版本
department	支持部门隔离
permission	支持权限过滤
created_at	判断文档新旧
effective_date	判断制度是否生效

没有元数据，后续权限控制、版本管理、引用溯源都会非常困难。

3.4 Rerank：重新排序检索结果

Rerank 的作用是对初步召回的候选文档重新排序。

向量检索负责“尽可能多地找回相关内容”，Rerank 负责“判断哪些内容最能回答当前问题”。

常见流程是：

向量检索 Top 50
  ↓
BM25 检索 Top 50
  ↓
合并去重
  ↓
Rerank 模型打分
  ↓
取 Top 5 给大模型

Rerank 通常比单纯向量相似度更关注“问题和文档片段是否存在直接回答关系”。这对知识库问答质量提升非常明显。

3.5 答案可信度：不是回答得流畅，而是有依据

企业级 RAG 中，答案可信度至少包含四层含义：

• 答案是否基于检索证据；
• 答案是否与原文一致；
• 答案是否引用了来源；
• 证据不足时是否能拒答。

一个可信答案不一定要很长，但必须清楚说明依据。对于制度、合同、技术文档、运维手册等场景，答案最好附带来源文档、章节和片段引用。

---

4. 系统设计：如何搭建完整流程或架构

一个企业级 RAG 系统可以拆成六层：

层级	核心职责
文档处理层	文档解析、清洗、切分、元数据抽取
索引层	Embedding、关键词索引、向量索引、结构化索引
检索层	向量检索、BM25、混合检索、元数据过滤
排序层	Rerank、去重、上下文压缩
生成层	Prompt 构造、答案生成、引用来源
评估与运维层	效果评估、日志分析、权限控制、成本优化

4.1 文档处理层

文档处理是 RAG 的地基。很多系统效果差，不是因为模型差，而是文档处理太粗糙。

常见文档包括：

• PDF；
• Word；
• Excel；
• Markdown；
• HTML；
• Wiki；
• 数据库记录；
• API 文档；
• 代码仓库；
• 工单系统。

文档处理需要关注：

• 标题层级是否保留；
• 页眉页脚是否清理；
• 表格是否结构化；
• 图片和流程图是否需要 OCR；
• 文档版本是否记录；
• 文档来源是否可追溯；
• 权限信息是否同步；
• 是否存在重复文档。

4.2 检索层

检索层不建议只做向量检索，而应采用混合检索。

常见检索方式包括：

检索方式	优点	缺点	适用场景
向量检索	语义召回强	精确匹配弱	FAQ、制度问答、知识解释
BM25	关键词匹配强	语义泛化弱	错误码、条款、型号、字段
结构化查询	精确可靠	需要结构化数据	表格、权限、时间、状态
图谱检索	关系推理强	构建成本高	复杂实体关系

比较稳妥的企业方案是：向量检索 + BM25 + 元数据过滤 + Rerank。

4.3 排序层

初步检索的目标是召回，排序层的目标是精准。

例如可以先召回 50 条候选结果，再通过 Rerank 模型选出最有价值的 5 条。

排序层还需要做：

• 去重；
• 合并相邻 chunk；
• 过滤低分结果；
• 优先选择新版本文档；
• 优先选择用户有权限的文档；
• 对冲突证据进行标记。

4.4 生成层

生成层的核心是让大模型基于证据回答，而不是自由发挥。

Prompt 中应该明确约束：

• 只能根据给定资料回答；
• 找不到答案时必须说明资料不足；
• 不要编造制度、数字、日期；
• 每个关键结论尽量标注引用来源；
• 如果资料冲突，要提示冲突，而不是强行合并。

一个简单 Prompt 模板可以是：

你是企业知识库问答助手。请严格根据【参考资料】回答用户问题。

要求：
1. 只使用参考资料中的信息回答；
2. 如果参考资料不足以回答，请说明“当前资料不足，无法确定”；
3. 不要编造制度、流程、数字、日期；
4. 回答要简洁清晰；
5. 关键结论后标注来源编号。

【用户问题】
{question}

【参考资料】
{contexts}

请输出答案：

---

5. 关键实现：核心模块、技术选型和实现细节

5.1 文档切分策略

chunk 切分直接影响召回和生成质量。

如果 chunk 太小，语义不完整；如果 chunk 太大，检索不精准，还会浪费上下文窗口。

常见切分方式：

切分方式	说明	适用场景
固定长度切分	每 N 个 token 切一次	快速 Demo
按标题切分	根据标题层级切分	制度、手册、文档
语义切分	按语义边界切分	长文档、知识文章
表格行切分	按表格行或业务实体切分	Excel、清单类文档
父子切分	小 chunk 检索，大 chunk 生成	复杂长文档

实际工程中比较推荐“父子切分”：

• 子 chunk 用于向量检索，保证召回精度；
• 父 chunk 用于生成上下文，保证语义完整。

5.2 混合检索示例

下面是一个简化的混合检索伪代码：

def hybrid_retrieve(query, user_id, top_k=5):
    # 1. 权限过滤条件
    filters = build_permission_filter(user_id)

    # 2. 向量检索
    query_vec = embedding_model.encode(query)
    vector_results = vector_db.search(
        vector=query_vec,
        top_k=30,
        filters=filters
    )

    # 3. 关键词检索
    keyword_results = bm25_search(
        query=query,
        top_k=30,
        filters=filters
    )

    # 4. 合并去重
    candidates = merge_and_deduplicate(vector_results, keyword_results)

    # 5. Rerank
    reranked = rerank_model.rank(query, candidates)

    # 6. 取最终结果
    return reranked[:top_k]

这个流程比单纯向量检索更稳，因为它同时利用了语义召回和关键词召回。

5.3 Rerank 的位置

Rerank 不建议替代召回，而应该放在召回之后。

原因是 Rerank 通常计算成本更高，不适合在全库上直接排序。它更适合对候选集进行精排。

推荐流程：

Query
  ↓
向量检索 Top 30
  ↓
BM25 检索 Top 30
  ↓
合并去重得到候选集
  ↓
Rerank 打分
  ↓
Top 5 进入 Prompt

5.4 引用来源设计

企业级 RAG 一定要支持引用来源。答案没有来源，业务方很难信任。

建议每个 chunk 保留以下信息：

{
  "chunk_id": "doc_001_chunk_023",
  "document_title": "员工休假管理制度",
  "section_title": "第五章 未休年假处理",
  "page": 12,
  "version": "2024-05",
  "source_url": "internal://hr/policy/leave",
  "content": "员工离职时，未休年假按照公司相关规定折算..."
}

生成答案时可以返回：

根据《员工休假管理制度》第五章，员工离职时未休年假需要按照公司规定进行折算。[来源1]

这样用户可以点击来源继续查看原文。

5.5 无答案问题处理

RAG 系统必须能拒答。企业场景中，拒答比胡说更重要。

可以设计以下判断：

• 检索最高分低于阈值；
• Rerank 最高分低于阈值；
• Top-k 文档之间相关性都很弱；
• 参考资料没有明确结论；
• 大模型自检认为证据不足。

Prompt 中也要明确要求：

如果参考资料中没有明确答案，请不要推测，请回答：
“当前知识库资料不足，无法确定该问题的答案，建议补充相关文档或联系业务负责人确认。”

---

6. 常见问题：实际落地中的坑和解决方案

6.1 文档解析质量差

问题表现：

• PDF 解析出来顺序错乱；
• 表格变成无意义文本；
• 页眉页脚反复出现；
• 章节标题丢失；
• 图片中的文字没有被提取。

解决方案：

• 对不同文档类型使用不同解析器；
• 表格单独处理，不要简单拼接；
• 保留标题层级；
• 清理页眉页脚和目录；
• 对关键图片使用 OCR；
• 解析后做人工抽样检查。

6.2 chunk 切分不合理

问题表现：

• 检索到的片段只有半句话；
• 答案缺少上下文；
• 一个制度条款被切成多段；
• 大模型无法判断适用范围。

解决方案：

• 不要只用固定长度切分；
• 优先按标题、段落、条款切分；
• 设置合理 overlap；
• 使用父子 chunk；
• 对表格、代码、FAQ 单独切分。

6.3 向量检索召回不到关键词问题

问题表现：

• 用户搜索错误码，召回不到；
• 用户搜索合同条款号，召回不到；
• 用户搜索产品型号，召回错误内容。

解决方案：

• 引入 BM25；
• 对关键字段建立倒排索引；
• 对型号、编号、错误码做正则抽取；
• 使用混合检索；
• 对 query 做关键词增强。

6.4 模型回答没有依据

问题表现：

• 答案写得很完整，但原文没有；
• 多个文档内容被混合；
• 生成了不存在的流程；
• 业务方无法追溯来源。

解决方案：

• Prompt 中强制基于资料回答；
• 输出来源编号；
• 限制无依据扩展；
• 增加答案校验；
• 检索不到时拒答。

6.5 权限控制缺失

问题表现：

• 普通员工问到了管理层文档；
• A 部门用户检索到 B 部门资料；
• 离职员工历史权限没有及时回收。

解决方案：

• 文档入库时写入权限元数据；
• 检索前根据用户身份构造过滤条件；
• 权限过滤必须发生在召回阶段，而不是生成后；
• 同步企业 IAM 或权限系统；
• 记录用户查询日志和访问日志。

---

7. 效果评估：如何判断系统是否有效

企业级 RAG 的评估应该分层进行。

7.1 检索评估

检索评估关注：正确证据有没有被召回。

常见指标：

指标	含义
Recall@k	Top-k 中是否包含正确证据
Hit Rate	是否命中目标文档
MRR	正确结果排名是否靠前
nDCG	排序质量是否合理

例如，如果正确文档经常在 Top 20 里，但不在 Top 5 里，说明召回还可以，但排序需要优化。

7.2 生成评估

生成评估关注：答案是否正确、完整、可信。

可以从以下维度打分：

维度	说明
正确性	答案是否与原文一致
完整性	是否覆盖问题关键点
忠实性	是否基于检索证据
可追溯性	是否提供来源
可读性	表达是否清晰
拒答能力	资料不足时是否拒答

7.3 端到端评估

端到端评估关注用户真实体验。

可以构建一个测试集：

[
  {
    "question": "离职员工未休年假如何折算？",
    "gold_docs": ["员工休假管理制度"],
    "gold_answer": "根据制度中的未休年假处理规则回答",
    "type": "制度问答"
  },
  {
    "question": "ERR_5021 是什么意思？",
    "gold_docs": ["系统错误码手册"],
    "gold_answer": "根据错误码定义回答",
    "type": "错误码查询"
  }
]

每次修改 chunk、Embedding、Rerank 或 Prompt 后，都跑一遍测试集，比较效果变化。

7.4 线上反馈评估

上线后可以收集：

• 用户点赞 / 点踩；
• 是否点击来源；
• 是否追问；
• 是否转人工；
• 问题是否解决；
• 高风险问题是否被正确拒答；
• 检索结果是否被用户打开。

这些反馈可以用于后续优化检索策略和知识库质量。

---

8. 工程优化：性能、成本、稳定性和可维护性

8.1 延迟优化

RAG 链路通常包含多个耗时步骤：

问题改写 → Embedding → 检索 → Rerank → Prompt 构造 → LLM 生成

优化方向：

• Embedding 结果缓存；
• 热门问题缓存；
• 检索和关键词搜索并行执行；
• 控制候选文档数量；
• Rerank 只对候选集执行；
• 使用流式输出；
• 根据问题复杂度选择不同模型。

8.2 成本优化

大模型调用成本通常来自：

• 输入 token；
• 输出 token；
• Rerank 模型；
• Embedding 计算；
• 向量数据库资源；
• 文档重建索引。

优化建议：

• 控制 chunk 数量；
• 对上下文做压缩；
• 对低风险问题使用小模型；
• 高频问题做答案缓存；
• 文档增量更新，避免全量重建；
• 对长文档先摘要再入库，但要保留原文引用。

8.3 稳定性优化

RAG 系统上线后要考虑异常情况：

• 向量数据库不可用；
• Embedding 服务超时；
• Rerank 服务失败；
• 大模型接口超时；
• 文档索引更新失败；
• 权限系统同步延迟。

需要设计降级策略：

• Rerank 失败时退化为混合检索排序；
• 大模型失败时提示稍后重试；
• 检索为空时拒答；
• 索引更新失败时保留旧索引；
• 高风险问题禁止无证据回答。

8.4 可维护性优化

企业知识库会持续变化，因此 RAG 系统必须支持维护。

建议建设：

• 文档版本管理；
• 索引更新任务；
• 文档解析质量检查；
• 低质量问答样本回流；
• Prompt 版本管理；
• 评估集管理；
• 检索日志分析；
• 权限同步机制。

一个不能持续维护的 RAG 系统，初期效果再好，也会随着文档变化逐渐失效。

---

9. 实践建议：给开发者的落地建议

9.1 不要从模型开始，而要从问题集开始

很多团队一开始就纠结用哪个向量数据库、哪个 Embedding 模型、哪个大模型。更合理的做法是先收集真实问题。

例如：

• 用户最常问什么？
• 问题来自哪些部门？
• 哪些问题必须准确回答？
• 哪些问题允许模糊回答？
• 哪些问题必须拒答？
• 哪些问题涉及权限？
• 哪些问题需要引用来源？

有了问题集，才能设计检索策略和评估体系。

9.2 第一版不要追求复杂，先打通闭环

第一版系统可以先做：

• 文档解析；
• 基础切分；
• Embedding 入库；
• 混合检索；
• 简单 Rerank；
• 来源引用；
• 人工评估集。

不要一开始就堆复杂 Agent、多轮规划、知识图谱。先把 RAG 基础链路做稳定，比堆概念更重要。

9.3 对不同类型问题使用不同策略

企业问题不是同一种类型。可以简单分类：

问题类型	推荐策略
制度问答	向量检索 + BM25 + 来源引用
错误码查询	关键词检索 + 精确匹配
表格查询	结构化查询 + LLM 解释
多文档总结	多段召回 + 摘要压缩
权限敏感问题	先权限过滤再检索
无答案问题	阈值判断 + 拒答

不要用同一套 Prompt 和检索策略处理所有问题。

9.4 RAG 输出要服务业务动作

企业级 RAG 的价值不是“回答得像人”，而是帮助业务完成动作。例如：

• 客服能不能根据答案回复用户；
• 运维能不能根据答案定位问题；
• HR 能不能根据答案解释制度；
• 法务能不能根据答案找到合同依据；
• 研发能不能根据答案定位接口文档；
• 管理者能不能根据答案做决策。

所以，答案应该尽量结构化：

结论：
依据：
操作步骤：
注意事项：
来源：

这种结构比一大段自然语言更适合企业场景。

---

10. 总结：提炼核心观点

企业级 RAG 系统不能只做“文档向量化”。文档向量化只是基础能力，它解决的是语义召回问题，但不能单独解决证据可靠性、排序质量、权限控制、答案可信度和效果评估。

一个真正可落地的 RAG 系统，应该至少包含以下能力：

• 高质量文档解析；
• 合理的 chunk 切分；
• Embedding 语义召回；
• BM25 或关键词检索；
• 元数据过滤；
• 权限控制；
• Rerank 精排；
• Prompt 约束生成；
• 来源引用；
• 无答案拒答；
• 离线评估和线上反馈；
• 成本、延迟和稳定性优化。

从工程角度看，RAG 的难点不在于“调用一次向量数据库”，而在于把检索、排序、生成、校验和反馈做成一个稳定闭环。

如果只做文档向量化，系统只能停留在 Demo；如果能把检索、重排、可信生成和评估体系做好，RAG 才有机会真正进入企业生产环境。

我的个人建议是：做企业级 RAG 时，不要一开始就追求复杂框架，而要先抓住三个核心问题：

• 第一，能不能找到正确证据；
• 第二，能不能基于证据可靠回答；
• 第三，能不能评估和持续优化。

只要这三个问题解决得足够扎实，RAG 系统就已经具备了从 Demo 走向生产的基础。