RAG系统看似简单，实则暗藏诸多陷阱。从文档清洗的OCR乱码到检索算法的混合策略，从Prompt设计的约束细节到效果评估的量化框架，每一步都可能让AI问答系统沦为摆设。本文揭秘内部知识库搭建过程中那些开发不会告诉你的关键决策点，以及如何用三个月时间从答非所问到精准回复的实战迭代路径。

我做过一个给内部销售团队用的知识库问答系统。需求很简单：销售问产品政策，AI直接回答，不用再翻文档。

第一版上线三天，销售就不用了。原因是AI经常答非所问，或者给的答案比翻文档还绕。

问题不在大模型。大模型没有你公司的任何信息，你要先把公司文档塞给它，它才能回答内部问题。RAG做的就是这件事：用户提问时，先去文档库检索相关段落，把段落和问题一起交给大模型，让它照着回答。

听起来简单。但每一步都有坑，而且很多坑开发不会主动告诉你。

文档清洗：脏活在最前面

很多产品经理以为把100个PDF扔进系统就完事了。我们当时也这么想，结果AI答了一堆内容找不到出处，后来查才发现源头文档本身有问题——有的是扫描件没做OCR，有的表格解析成了乱码，有的是三年前的旧版本，政策早改了。

文档入库前得先清洗。

清洗完还要切片。大模型的输入有长度限制，整份文档塞不进去，必须切成小块（Chunking）。切法有讲究：按字数硬切，一句话可能被截断，前半句在A块、后半句在B块，大模型读了也懵；按段落和标题切，语义完整，效果好很多。让相邻的块有一点重叠也有帮助，比如每块保留前后各50字，上下文衔接更稳。

表格和图片是另一个麻烦。我们文档里有大量价格表和流程图，普通切片直接变乱码，最后专门安排人工把表格转成Markdown格式。这部分工作量比预估的多了不止一倍。

没有捷径。文档清洗是整个RAG项目里最费时间、最难标准化的一步，也是最容易被低估的一步。

检索：找得准才能答得对

文档处理完，技术会用Embedding模型把每个文本块变成向量，存进向量数据库。你不需要懂向量是什么，只需要知道：这个过程把文字的语义变成可以计算距离的东西，意思相近的内容会被检索到一起。”西红柿”和”番茄”字面不同，但查同一个词能把两者都找出来。

但向量检索对精确词不敏感。用户查一个型号、工单编号、合同条款编号，纯向量检索经常找不到。解法是混合检索——向量和关键词两套同时跑，结果合并排序，互补。

还有召回量的问题。粗检索可能捞出二三十个段落，全塞给大模型既贵又慢，还容易干扰答案质量。通常的做法是加一层重排模型，把二三十个段落精选成三到五个，再往下传。

另一类问题是用户提问太口语化，比如”那个优惠怎么算”，系统根本不知道”那个”指什么。我们后来加了一步查询改写，让大模型先把问题规范化，再去检索。加上之后，召回准确率明显提升了。

Prompt：这是产品经理真正要动手的地方

检索结果准备好之后，怎么交给大模型，产品经理要自己写。

一个基本的RAG提示词结构大概是这样：

你是一个专业的客服助手。请根据以下【已知信息】回答用户问题。

【已知信息】：${检索出的段落}

【用户问题】：${用户提问}

规则：只根据已知信息回答。如果已知信息里没有相关内容，直接回复”暂时无法回答这个问题”，不要猜测。

约束要写具体。”不要胡编”这类说法大模型执行起来很随意，”如果已知信息里没有，直接说暂时无法回答”效果明显好一些。我们在这里试了好几个版本，最终定下来的规则比第一版多了三条，都是踩坑之后加的。

Prompt不是写完就不动的东西。用户反馈上来，发现哪类问题答得不好，就回来改规则。这个过程不会结束。

上线之后怎么判断做得好不好

系统跑起来之后，要有办法量化效果，不然改了参数好没好不知道，跟老板也说不清楚。

业界常用的评估框架叫RAG Triad，三个维度：

1. 上下文相关性：检索出来的段落，和用户的问题相关吗？找了一堆废话，大模型也回答不好。
2. 忠实度：大模型的回答有没有超出检索到的内容，有没有自己加了不存在的信息？
3. 回答相关性：大模型有没有正面回答用户的问题，还是绕了一圈没说到点上？

做法是准备一百个左右的测试问题，覆盖常见查询类型。每次改了系统参数，跑一遍，看三个维度的分数涨了还是跌了。没有这个，调参就是盲调。

先跑通，再抠细节

第一版我们用了几十篇核心文档、一个开源大模型、最简单的架构，两周跑通MVP，让销售先用起来。

之后三个月，混合检索、重排、查询改写，一个一个加进去。每加一个，先在测试集上验证，再上线。

混合检索和重排最先加，因为用户反馈最集中的问题是”问了精确的东西找不到”。查询改写是后来加的，因为观察下来有一大类问题是指代不清的口语提问。

加的顺序是问题驱动的，不是技术路线决定的。这一点在项目初期容易想错。