RAG 做 Demo 很简单，做垂直应用为什么很难？

我最早接触 RAG 的时候，说实话是有点上头的。

原因很简单，太容易出效果了。拿一份文档，切 chunk，做 embedding，往向量库一扔，再接个大模型，最后在页面上问几个问题，回答居然还挺像那么回事。那种感觉很容易让人误以为，原来“让 AI 学会公司知识”也没那么难。

但我后面越做越觉得，RAG 最容易骗人的地方也在这里。它特别适合做第一眼惊艳的 Demo，但一旦你想把它做成一个垂直应用，难度会突然从“几天能跑起来”跳到“为什么怎么改都不稳定”。

Demo 为什么容易

因为 Demo 的场景太理想了。

你选的基本上都是干净文档，问题也往往是你自己提前设计好的。比如文档里明明写了“报销额度上限是 2000”，你去问“报销额度是多少”，这时候只要检索别太离谱，模型大概率都能答对。

但真实业务不是这种输入。

真实用户会问：

• “我这个情况能不能走特批？”
• “上周开会说那个规则不是改了吗？”
• “上海实习生租房补贴和正式员工一样吗？”

这些问题麻烦的地方，不是模型不会说话，而是它背后对应的知识往往不规整、不完整，甚至互相冲突。你以为你在做问答，实际上你在处理组织内部的信息脏乱差。

真正难的不是检索，是知识本身不稳定

我现在对很多 RAG 项目的一个判断是：问题经常不在“搜不到”，而在“没有一个能稳定被搜到的标准答案”。

比如一个垂直业务里，知识可能同时散落在：

• 产品文档
• 飞书会议纪要
• 历史工单
• 老员工经验
• 群聊里的临时通知

这几种信息的可信度和时效性完全不一样。如果你把它们一股脑塞进知识库，检索阶段看起来很丰富，回答阶段反而更容易乱。

所以很多人以为自己在优化召回，实际上更该先做的是知识分层：

• 哪些是正式制度，优先级最高。
• 哪些是经验性总结，只能当参考。
• 哪些内容过期了，应该下线。
• 哪些信息只能被某类人看到，不能直接喂给所有用户。

这一步不做，后面的 prompt 调得再花，效果也只会忽好忽坏。

垂直场景里，问题通常不是一个问题

还有一个我后来才意识到的点：用户的一句话，往往不对应一次检索，而是对应一个“理解问题”的过程。

比如用户问“这个客户现在能不能续约”，背后可能至少要拆成几件事：

• 这里的“能不能”是在问流程规则，还是在问系统状态。
• “这个客户”需要先解析成具体实体。
• 续约判断是不是依赖最近的行为数据，而不只是文档知识。

这时候单纯的 RAG 已经不够了。你不只是从知识库里找答案，而是在做“检索 + 结构化查询 + 规则判断”的组合。也就是为什么很多看起来在做 RAG 的系统，最后都慢慢长成了 Agent 或工作流系统。

为什么做垂直应用时稳定性总是很差

我自己目前总结下来，主要有四个坑。

第一，检索命中了，不代表答案可用。命中的片段可能只讲了一半，或者缺少上下文限定。

第二，知识更新太快，但索引更新机制很随意。很多团队只管导入，不管版本。最后用户问的是今天的规则，系统答的是上个月的。

第三，业务里存在大量权限边界。一个内部知识助手如果不做权限隔离，短期看是“回答更全”，长期看就是事故预备役。

第四，评估方式太虚。很多 Demo 都是挑几个成功 case 截图，但真正上线需要知道的是：在哪些问题类型上它会错，错得有多稳定，能不能被兜住。

我现在对 RAG 的看法

我不是不看好 RAG，恰恰相反，我觉得它很重要。只是我现在越来越不相信“接个知识库就能解决业务问题”这种说法。

如果是做真实垂直应用，我会更关心下面几件事：

• 知识源有没有分级和清洗。
• 查询是否需要先做意图拆解。
• 回答结果能不能标注出处和版本。
• 错答时有没有保守退化策略。
• 整个链路能不能被评估，而不是靠手感。

说白了，RAG 真正的门槛不在模型，也不在向量库，而在你是否愿意把“知识治理”当成一个正经工程问题来做。

如果面试官问我 RAG 难在哪里

我现在大概会这么回答：

“Demo 阶段的 RAG 难点主要是技术拼装，但垂直应用阶段的难点其实转向了知识治理、查询理解、权限控制和效果评估。很多系统不是不会检索，而是业务知识本身不标准，导致回答很难稳定。真正可用的 RAG，背后往往不是一个检索模块，而是一整套围绕知识生命周期的工程设计。”

这比只说 chunk、embedding、rerank，我觉得更接近真实问题。