RAG 几乎已经成了 AI 产品里的标准动作。只要团队担心幻觉，第一反应往往就是“加检索”。这个方向本身没有问题，但问题在于，很多系统并没有认真判断当前问题到底适不适合 RAG，结果把它变成了一种默认解法。
一旦默认，成本、复杂度和稳定性问题就会一起出现。因为 RAG 不是免费能力，它意味着索引构建、召回、排序、上下文拼接、版本同步和线上观测。只有在它真的能显著改善结果时，这套复杂度才值得付出。
更深一层的问题是，很多团队把“模型不知道答案”和“系统应该引入 RAG”直接画上等号。事实上，这中间还差了好几步判断。因为一个问题之所以答不好，可能是知识缺失，也可能是任务本身更适合流程化执行、结构化查询或者规则判断。把所有“不确定性”都导向 RAG，只会让系统越来越重，但不一定越来越好。
适合 RAG 的问题长什么样
RAG 真正擅长的是“知识依赖强，但答案组织仍需要模型参与”的问题。比如：
- 企业内部文档问答。
- 需要结合最新政策或产品文档的解释类问题。
- 需要从多份资料中抽取并归纳答案的任务。
- 客服、销售、支持等依赖动态知识库的场景。
这些任务的共同点是，模型本身不知道答案，或者知道得不够新、不够准，但它仍然需要理解问题、筛选证据并组织输出。
这类问题通常还有几个明显特征：资料来源较多、知识更新频繁、答案不是机械复制而是需要结合上下文重组，并且用户能接受一定程度的自然语言表达波动。在这些条件下，RAG 的确可以显著提升结果的新鲜度和事实支撑度。
不适合 RAG 的场景，往往被低估
也有很多问题，表面上看似“需要更多知识”，实际上不该用 RAG。比如：
- 明确的规则判断，应该交给规则引擎或代码逻辑。
- 固定字段转换，应该交给结构化映射或模板。
- 多步骤审批和执行，应该交给工作流系统。
- 对结果可追责要求极高的任务，应该优先用确定性系统。
如果这些任务都被塞进检索增强链路，系统不仅不会更稳，反而会把原本清晰的问题搞得更模糊。
很多企业场景里的真实问题，其实并不是“缺少文档支持”，而是“缺少确定性的业务边界”。例如一个费用报销流程是否合规、一个订单能否退款、某个客户是否有权限访问某项数据，这些都更适合由明确规则、数据库查询或状态机判断。你当然可以让模型检索文档后给出解释，但如果系统最终还要依赖确定性判断，那么把核心决策交给 RAG 只是增加复杂度。
RAG 最大的问题，不是召回，而是边界模糊
很多团队把主要精力放在召回率和 rerank 上，这当然重要，但真正难的往往是“什么时候应该让模型引用检索结果，什么时候不应该”。如果边界不清楚，系统很容易出现两类问题：
- 明明应该按规则执行，却被模型“自由发挥”。
- 明明证据不足，却仍然生成看似合理的答案。
这类问题不是单纯调召回就能解决的，它更像是产品边界和系统责任划分没有想清楚。
而且边界一旦模糊，系统还会出现另一个副作用：排障难度急剧上升。回答变差时，你很难知道问题出在召回、排序、文档质量、Prompt 拼接、模型理解还是产品定义本身。很多团队最后把大量时间花在调召回参数上，实际上他们真正缺的是任务拆分，而不是更复杂的检索链路。
RAG 的真实成本经常被低估
很多人讨论 RAG 时，主要看的是调用效果，却忽略了它在运行层面的持续成本。一个稍微严肃点的 RAG 系统，通常至少包含以下部分：
- 文档采集和清洗。
- 切分策略和索引构建。
- 元数据管理和权限过滤。
- 召回、排序和上下文拼装。
- 文档更新后的再索引与版本同步。
- 召回质量和引用准确性的线上观测。
这些能力不是一次性投入，而是长期维护成本。资料格式变了、知识库更新了、权限模型调整了，整个 RAG 链路都可能受影响。所以在决定是否上 RAG 时，团队不该只问“它能不能让答案更好”，还应该问“这个问题值不值得长期背上这一整套复杂度”。
先问三个问题，再决定要不要上 RAG
在平台实践里，我们通常会先问三个问题：
- 这个任务的关键信息是否真的来自外部知识，而不是业务规则。
- 这个任务是否需要模型对检索结果进行理解和重组。
- 如果检索失败，系统有没有更安全的降级方式。
如果这三个问题里有两个答不清楚，那么大概率说明现在还不该上 RAG。
在这三个问题之外，我们还会再问两个补充问题：
- 如果完全不用 RAG，是否已经有更简单的确定性方案。
- 用户是否真的需要“自然语言生成后的答案”，还是只需要准确拿到某条结构化信息。
这两个问题经常能帮助团队绕开过度设计。因为很多看似复杂的知识问题，最后其实只需要更好的检索 UI、更明确的规则引擎或者一张状态表，而不需要完整的检索增强链路。
更值得优先考虑的替代方案
当一个问题不适合 RAG 时，通常还有几类更合适的方案：
- 规则和状态机，适合边界清晰、可追责要求高的决策。
- 数据库查询，适合明确字段读取和条件筛选。
- 工作流编排，适合多步骤执行和审批。
- 模板加结构化填充，适合固定格式输出。
- 简单搜索界面，适合用户自己确认来源而不是让模型代答。
这些方案不一定像 RAG 那样“显得智能”，但往往更便宜、更稳定、更容易治理。
权限和知识边界，也是 RAG 的隐形难题
很多团队低估 RAG，还有一个原因是只看“能不能检索到”，没看“谁有权检索到”。一旦系统进入多租户、企业或部门隔离场景，知识边界会立刻变复杂。某些文档只能被某些团队访问，某些片段需要脱敏，某些检索结果在不同组织下含义还不一样。如果权限模型没有进入检索层，那么 RAG 就很容易在看似正常的回答里泄露不该出现的信息。
这也是为什么很多企业场景下，RAG 的真正难点不只是召回率，而是权限过滤、来源追踪和文档生命周期管理。你不是在给模型塞更多资料，而是在建设一套带访问边界的知识分发系统。对很多团队来说，这部分复杂度远比想象中高。
资料更新频率越高，RAG 维护成本越高
表面上看，RAG 好像只是在模型前面多了一层检索，但只要知识源持续变化，维护成本就会成倍增加。文档新增了，要重新索引；文档删除了，要保证结果不再出现；旧文档作废了，要处理历史缓存；同一主题多版本并存时，还要决定应该优先哪份内容。
如果这些机制不完善，系统很容易出现一种很糟糕的状态：检索确实命中了资料，但命中的是过期资料、边缘资料或未经审核的资料。此时用户看到的并不是“模型幻觉”，而是“系统用真实但错误的来源支持了错误答案”。这类问题通常更难被察觉，也更难解释。
RAG 不应该替代产品信息架构
很多团队在内部文档体系混乱、产品帮助中心结构模糊、规则归档不清晰的情况下，试图用 RAG 一次性解决信息问题。这其实是在让模型替代原本应该由产品和知识管理完成的工作。结果常常是，系统越做越复杂，但知识源本身依然混乱。
更现实的顺序往往应该是：先把核心知识按业务边界整理清楚，明确哪些内容适合检索、哪些内容必须结构化、哪些内容需要人工审批，然后再决定是否把其中一部分接进 RAG。否则 RAG 只是在接管混乱，而不是消除混乱。
真正成熟的系统，通常是混合设计
强调“有些场景不该上 RAG”，并不意味着 RAG 没有价值。更现实的方向往往是混合系统：把需要知识整合和自然语言解释的部分交给 RAG，把确定性执行和强边界判断交给规则、数据库和工作流。这样系统既能发挥模型的表达优势，又不会把所有责任都推给一条检索增强链路。
成熟平台最终追求的，不是“尽可能多地使用 RAG”，而是“只在真正有价值的地方使用 RAG”。这两个目标看起来很像，实际带来的复杂度完全不同。
判断是否该上 RAG，最好先做一个小型试验
在实践里，如果团队对某个场景是否值得上 RAG 仍然拿不准，一个很实用的方法是先做小型试验，而不是直接上完整工程化方案。比如先用一小批高质量知识源、有限范围用户和明确评测集，观察三件事：
- 检索后的准确性是否真的明显提升。
- 用户是否真的需要“带解释的生成式答案”。
- 为了维持这套链路，团队需要付出多大维护成本。
如果试验阶段就发现收益并不稳定，或者问题更多地出在知识源本身而不是生成能力上，那么继续重投入建设 RAG 往往不是最优选择。小试验的价值，正在于帮助团队把“架构冲动”变成“基于证据的判断”。
别把所有知识问题都包成一个检索入口
很多系统做着做着，会把不同类型的知识都堆进同一个检索入口里：制度、FAQ、公告、产品说明、配置文档、工单记录全都放在一起。表面上看，这样最统一；实际效果却常常很差。因为这些内容的时效性、可信度、表达风格和适用边界完全不同，最终只会增加召回噪音。
更成熟的做法往往是先按知识类型分层，再决定哪些层适合进入 RAG，哪些层更适合保留为结构化查询或人工确认入口。知识先被治理，RAG 才有机会变成增益，而不是噪声放大器。
结语
检索增强很有用，但它不是默认正确答案。真正成熟的系统，不是尽可能把所有问题都变成“检索+生成”，而是清楚知道哪些问题值得用 RAG，哪些问题应该继续交给更确定的系统。
边界一旦清楚，产品架构会更轻，排障会更容易，治理成本会更低，用户也会更容易建立信任。对很多团队来说，这比盲目把更多场景塞进 RAG，更接近长期正确的路线。
检索增强很有用，但它不是默认正确答案。真正成熟的系统，不是尽可能把所有问题都变成“检索+生成”，而是清楚知道哪些问题值得用 RAG，哪些问题应该继续交给更确定的系统。边界一旦清楚，AI 反而会变得更可靠。