不要只是搭建：RAG 不是上传文档然后问答那么简单

1

前言

最近因为一些业务需要，需要快速进入一个新领域，然后就会涉及到调研某项技术，理解一批法律文档，希望在短时间内阅读大量资料并形成判断。总结下来这类事情有一个共同特点，那就是需要参考的文档很多，而且信息之间存在层级、版本、上下文和相互印证的关系。

那具体怎么操作呢，下意识的想到现在不有 AI 吗，不是有工具吗，不就是 AI chatbox 类产品（ChatGPT、Claude、豆包、kimi 等）或直接标榜的知识库类产品（NotebookLM 等）应该能解决的问题吗？

但是具体用下来，发现都有各种问题，有些工具对上传文件数量、文件大小有限制；有些回答看起来流畅，但细看发现没有真正命中文档；有些会漏掉关键材料；有些会把不同文档里的信息混在一起；有些甚至在证据不足时仍然给出很肯定的答案。

即使某些产品升级后标榜"无限文件"、"超长上下文"、"大容量知识库"，从技术经验上看，我也很难相信真的存在没有限制的系统，资源一定是有限的。

所谓无限，通常只是产品层面的表达。底层一定还会有取舍：解析策略、索引策略、召回策略、上下文压缩、排序、截断、缓存、成本控制。

也正是因为这些实际痛点，我又重新去了解了一些 RAG。

之前我大概知道 RAG 是什么：检索增强生成，把外部知识检索出来，再喂给大模型回答。但真正深入看一些教程、demo 和工程讨论后，要做好，是件特别难的事，当然，这里好的定义，就不过多辩论了。

2

大部分 RAG 教程只是教你搭起来

现在 RAG 的教程大多数都是一个共同的套路：

1pip install安装或者dify，coze等
2上传加载文档
3切chunk
4生成embedding
5写入向量库
6top-k检索
7拼prompt
8调用大模型
9回答出来了
10完事
11

这个流程当然有价值，至少能让人知道 RAG 的基本链路。但问题是，很多文章就停在这里了，真正再深入的文章鲜有人讲。

文档怎么切；chunk 大小为什么这样设；embedding 模型怎么选；只用向量检索够不够，BM25 和 embedding 怎么融合，top-k 为什么是 5，要不要 rerank，用户问题要不要改写，多文档冲突怎么办，查不到时模型怎么拒答，怎么评测 RAG 好坏，这些都是问题。

最后系统是运行起来了，但从业务反馈结果来说，真正能不能用，效果好不好，都不得而知了，所谓结果冷暖自知。

把 RAG 拆开看，其实不是简单一个“上传文档然后问答”的动作，而是包含多个步骤的工程链路：

3

模型太强，反而掩盖了检索系统的问题

现在模型本身太强了，即使检索系统做得很一般，模型也能凭自己的预训练知识猜出一个看起来不错的答案。

于是就容易产生错觉：

我这个 RAG 好像效果还不错。

但实际情况可能是：检索没起什么作用，模型自己在答。你把检索结果删掉，模型依然能回答八九不离十。

4

会用工具，不等于解决问题

现在很多讨论还停留在“知不知道这个工具、会不会把它跑起来”的阶段。 会不会用工具，确实已经拉开了一层 gap。 但这个工具到底适不适合你的问题、能不能稳定解决业务问题、值不值得投入成本，那是另一层能力。

退一步说，可能很多企业根本不是“需要 RAG”，而是“看到别人都在做 AI，所以我也得有一个知识库助手”。 但是我想说， RAG 不是银弹，AI 也不是银弹。

因为企业的问题往往不是缺一个聊天框，而是：业务流程没梳理清楚，知识文档没人维护，数据口径不统一，权限体系不完整，责任边界不清晰，核心指标没人定义。

这种情况下，上 RAG 只是在混乱之上再套一层智能外壳。看起来接入了 AI，接入了新技术，有一个很好的故事，实际只是把问题包装得更难排查。

想到了一句老话：

用战术的勤奋，掩盖战略的懒惰。

真正的能力应该是： 定义问题，拆解问题，判断这个问题值不值得用 AI，判断 RAG 是不是合适路径，然后再设计技术方案。

担心的是了解得不够全面的前提下，刚跨过第一个会用工具的阶段，就以为已经到终点了。

5

第一层难点：数据进入知识库之前

5.1

数据清洗和文档切分

RAG 的第一步往往是清洗数据，但清洗只是开始。 多少类型的文档能够支持，pdf，docx，txt，html 之类，每个文档都有自己的格式，另外要不要 OCR，有表格，公式怎么办？

然后再是文档切分。

块要不要切？怎么切？按字符数切，按段落切，按标题层级切，还是按语义结构切？

如果 chunk 太大，检索会不精准；如果 chunk 太小，语义会断裂。

上下 chunk 要不要关联？

不关联，可能丢掉关键信息。

关联了，又可能把噪声带回来，让切分失去意义。

如果文档里有表格、代码、公式、法律条款、脚注、跨页内容，问题会更复杂。

5.2

原始文件存储选型

本地，分布式存储，还是某个数据库，还是做到 es，主要是方便快速的能够回查校正和测试。

5.3

metadata 设计

很多教程只把文本内容塞进向量库，但真实系统里 metadata 同样很重要。

比如：

• 文档类型
• 来源系统
• 时间版本
• 版本号
• 业务线
• 作者
• 权限等级

这些字段后面都可能参与：过滤、路由、排序、去冲突。

没有 metadata 的知识库，很容易变成全库乱搜。

尤其在法律、制度、合同、产品文档这类场景里，时间、版本和来源优先级可能比文本相似度还重要。

6

第二层难点：召回并不只是向量搜索

6.1

向量模型选型

文档是中文多还是英文多，还是多语种，用开源自建还是用在线的，成本如何考虑。embedding 模型要不要微调，微调数据怎么准备，让 LLM 自己生成，还是自己标注，怎么校验。

6.2

多路召回

有些问题适合语义相似度，有些问题则更依赖关键词。

比如错误码、合同编号、产品型号、法律条款编号、专利号、人名、公司名、术语缩写。这类问题用 BM25 或全文检索可能更稳定。

所以更实际的方案通常是多路召回：

• BM25 / 全文检索
• embedding 向量检索
• metadata filter
• 规则召回
• 结构化数据库查询
• 知识图谱或实体关系召回

然后再做融合排序。

那么随之的问题也来了：

• 每一路召回多少个 chunk？
• 每一路内部怎么排序？
• 多路召回怎么去重？
• 分数怎么归一化？
• 最终保留多少结果进入 rerank？
• 不同业务场景是否需要不同召回策略？

这才是做了会遇到的真正的问题。

6.3

rerank 同样需要考虑

初始召回负责尽量把相关内容捞出来，rerank 负责把真正有用的内容排到前面。

如果没有 rerank，系统很容易把"看起来相似但实际无关"的 chunk 塞进上下文。

模型看到一堆材料后，会很努力地组织答案。但如果材料本身就不干净，回答自然会飘。

以上这些都不是默认参数能解决的。

7

第三层难点：用户的问题并不适合直接检索

7.1

query rewrite 和问题理解

用户的 query 进来，肯定不会很完整并且契合系统的要求，系统需要做标准化的处理，比如

1这个怎么处理？
2有没有风险？
3之前那个方案还能不能用？
4和旧版本有什么区别？
5

如果不结合上下文，系统根本不知道"这个"指什么。

所以在 query 前通常需要问题理解：

• query 是否完整？
• 是否需要结合历史对话？
• 是否需要改写？
• 是否需要拆成多个子问题？
• 是否需要 HyDE 生成假设答案来增强召回？
• 是否需要先反问用户补充条件？
• 是否和知识库无关？无关时是拒答，还是进入闲聊模式？

多轮对话里更复杂。

是不是每一轮都要查知识库？历史对话太长怎么办？用户改了限定条件怎么办？

这些问题，教程里基本不会出现，但一深入使用和优化后就会遇见。

8

第四层难点：知识库越大，问题越复杂

如果知识库只有几十篇文档，问题还不明显。

但如果有 10 万篇、100 万篇文档，全库向量检索就会开始暴露各种问题。

8.1

路由和分桶

• 先判断问题属于哪个业务域
• 再选择对应知识库或索引
• 再做召回
• 最后再融合和生成

问题是，桶怎么分？

人工分类，还是模型分类？

标签体系怎么设计？

新文档进来不属于已有类别怎么办？

分类基准和标签基准怎么维护？

这已经不是简单的 RAG 问题，而是知识组织问题。

8.2

多文档融合和知识冲突

真实知识库里经常有冲突。

A 文档说一个流程，B 文档说另一个流程。

旧版本说一种，新版本说另一种。

总部制度说一种，区域政策又有例外。

公开材料说一种，内部材料说另一种。

全部召回时，模型该信谁？

只召回一个时，如果刚好召回错了怎么办？

所以 RAG 系统不能只考虑相关性，还要考虑可信度、时效性、优先级、权限、版本和适用范围。否则模型不是在做严谨回答，而是在帮你把冲突信息揉成一段看起来通顺的话。

9

第五层难点：评测体系

RAG 最容易被忽略的一块，是 evaluation。想起现在的 Agent 发展，似乎也是在往 eval 阶段发展了。

专业的评测不是说问几个问题，看回答还行，就觉得可以了。参考一些资料来看，真正常用的指标可以先抓几类，不用一上来把所有名词都堆满。

9.1

召回有没有命中

检索阶段最重要的问题是：正确材料有没有被捞出来。

这里两个指标需要关注 Recall@K（前 K 个结果里是否包含正确 chunk，衡量召回能力） 或者 Hit Rate@K（前 K 个结果里有没有命中正确材料）。

如果要看排序，再补一个 MRR 或 nDCG@K。前者看第一个正确结果排第几，后者看相关内容是不是整体排得靠前。

9.2

答案有没有依据

生成阶段主要关注以下指标，比如：

• Faithfulness / Groundedness：答案是不是被检索到的内容支撑。
• Answer Correctness：答案本身是否正确。
• Abstention Accuracy：查不到或者证据不足时，系统能不能拒答或反问。

需要注意的是：答案看起来顺，不一定代表它有依据；答案本身正确，也不一定代表是 RAG 起了作用。

9.3

业务上有没有价值

真正上线时，还得看业务指标。

比如用户问题解决率、人工转接率、首次回答可用率、用户追问次数、平均响应延迟、单次成本，以及错误答案带来的业务风险。

这些指标不一定每个场景都要上，但至少要选几个和业务目标直接相关的。技术指标只是中间指标，业务有没有改善，才是最终要回答的问题。

10

第六层难点：观测能力

上线之后，要定位问题，需要知道整个链路，并且每个环节都要做好日志留存，需要知道但不限于：

• 用户问了什么
• Query 被改写成了什么
• 召回了哪些 Chunk
• Chunk 排序如何
• 最终上下文是什么
• 模型引用了哪些内容

所以，结合上面的内容，专业的 RAG 评测流程，至少应该包含：

• 构建 golden dataset：真实问题、标准答案、正确文档、正确 chunk。
• 相应的也要有 bad case 集：模糊问题、无答案问题、冲突文档、旧版本文档、跨文档问题、权限边界等。
• 检索策略对比：只用 BM25、只用 embedding、hybrid、rerank 前后分别对比。
• 分层评测：检索、排序、生成、引用、拒答、业务测真实性。
• 线上观测：记录 query、召回 chunk、排序分数、最终 prompt、答案、用户反馈。
• 定期回归：每次改 chunk、embedding、top-k、rerank、prompt，都跑同一套评测集。

没有观测能力的 RAG，就是出了问题也不知道问题在哪。

11

chatbox 和知识库产品，本质也绕不开这些问题

现在很多 AI chatbox，包括 ChatGPT、Claude、豆包、Kimi 等，都在强化文件理解、长上下文、多文档分析能力。NotebookLM 这类产品，则更明确地把自己放在"和资料对话"这个场景里。

它们看起来像是在解决一个共同问题：

如何让模型使用超出自身参数记忆之外的信息。

这背后可能是长上下文，可能是 RAG，可能是搜索，可能是某种混合方案。具体实现我们不知道，因为具体产品实现是并没有对外公开的。

如果假设它使用了 RAG 或类似机制，那不管怎么做，前面讲的那些底层问题并不会消失，只是被产品体验隐藏起来了。

12

最后

说了这么多，以上文章所有部分，没有给出那些问题的答案，我想也没有标准的答案，仍然需要花时间去查去找去映射各自的实际场景，但我想，它们是一种思考的角度。

也许在某些场景下，长上下文直接塞全文可能更好；某些场景下，结构化数据库 + 工具调用更好；某些场景下，知识图谱更好；某些场景下，微调或领域模型更好；某些场景下，根本不需要 AI，优化搜索和文档规范就够了。

这个领域可能或者说应该是定制化的，非常依赖业务场景。不同业务、不同文档、不同风险、不同成本约束，最后都会存在不同的方案。

因此，我现在最想看的，不是又一篇"从零快速搭建 RAG"，而是一个真实的 RAG 系统到底怎么被调到能用。

想知道到底用 RAG 解决了什么问题，踩过什么坑，评测怎么做，最后发现 RAG 是答案，还是发现问题根本不在 RAG。

从长远来看，本身 RAG 替代的就是大模型长上下文有限而产生的解决方案，但随着大模型能力越来越强，Agent 能力越来越强，RAG 这件事的定位在哪里，它的未来形态究竟会变成什么还是会消失，我同样很好奇。

喜欢就“点个赞”↓