为什么很多 RAG Demo 看起来很好，上线后不好用

先说结论。

RAG Demo 容易成功，因为它使用少量干净文档、明确问题和单一用户。上线后不好用，通常不是向量数据库突然失效，而是文档治理、权限、评估和更新没有成为系统的一部分。

真正要生产化的不是问答页面，而是一条可持续的知识流程。

发生了什么，可以概括为一句话：系统从“在固定样本上返回答案”，进入“在变化文档、不同权限和真实故障下承担回答责任”。真正变化是主要成本从模型调用扩展到内容、评估、权限和运营。

证据说明：哪些是事实，哪些是工程推论

本文不引用未经公开的客户指标，也没有把假设案例写成线上实测。后文判断使用三类证据标签：

• 工程约束：权限必须在检索前生效、业务状态需要持久化等可由系统设计直接检查的条件；
• 可复现实验：用固定文档、问题和故障注入，在本地或测试环境重复执行；
• 工程推论：根据前两类证据推导上线风险，仍需在具体项目中验证。

例如“旧版与新版同时进入候选会增加错误引用风险”是工程推论；“检索结果是否同时包含两个版本”则是可复现实验。

Demo 只证明主链路能够连通

一个典型 Demo 包含上传文档、切片、Embedding、检索和模型回答。它能验证技术链路，也适合解释概念。

但它没有证明文档是否权威、引用是否最新、用户是否有权访问、回答失败后谁处理。这些都在真实使用中决定信任。

所以 Demo 通过应被视为第一个技术检查点，不是业务验收。

文档治理决定系统在回答什么

生产知识库会同时存在草稿、旧版、重复和冲突文档。把它们全部索引，模型会从错误前提生成流畅回答。

每份文档需要负责人、版本、生效日期、权限和复核日期。新版本发布时撤回旧索引，失败要可见。

具体场景是售后政策更新。旧版和新版同时命中时，重排再准也无法替业务决定哪份有效。

切片和检索必须按文档类型验证

FAQ、合同、手册和表格的结构不同，不应使用同一切片策略。标题层级、章节引用和表格行关系需要保留。

检索测试要包含同义表达、模糊问题、无答案和跨章节问题。只用从文档标题改写的问题，会高估效果。

判断标准是正确证据是否进入候选，而不只是最终答案看起来合理。

权限必须在检索前生效

前端隐藏文档不等于权限控制。检索时要根据用户、租户、部门或项目过滤，生成阶段也要防止跨权限上下文混入。

缓存、日志和评估数据同样可能泄露内容。权限测试应包含用户无权访问但语义高度相关的文档。

如果权限无法可靠映射，先缩小知识范围，不要靠 Prompt 要求模型保密。

没有评估集，优化只能靠印象

至少准备一批来自真实用户的问题，包含期望证据、可接受答案、必须拒答和权限条件。按业务类型分层，不只求一个总分。

每次更换模型、切片、检索或 Prompt 后跑回归。线上未命中和差评继续补入评估集。

没有真实问题时，可以先做小规模访谈和日志整理，不应编造“准确率”。

引用来源是信任和调试入口

回答应展示可访问的原文、版本和更新时间。用户可以核对，开发者也能区分检索错误和生成错误。

引用不是装饰。若链接跳不到具体位置、用户无权打开或版本已过期，引用机制并未成立。

高风险问题还应优先返回原文与人工入口，而不是追求更长回答。

上线后需要运营未命中和差评

记录问题、回答、引用、用户角色、系统版本和反馈原因。把问题分类为无知识、检索失败、内容冲突、权限、生成偏差或超出范围。

每类对应不同负责人。知识缺口交给业务 owner，解析和检索交给技术，范围外问题保持拒答。

没有运营队列，系统会重复犯同一类错误。

常见失败：继续调 Prompt 掩盖数据问题

Prompt 可以改善表达和引用要求，不能让过期文档变正确，也不能修复权限映射。

另一个失败是追求回答率。为了少拒答而放宽检索，会让系统在没有证据时编造。高风险场景中，可靠拒答是有效能力。

还有一种误区是一次上线全部内部文档。范围越大，治理和权限问题越难定位。

一个可复现的 Demo 到上线推演

下面是假设型工程推演，用于复现生产化差距，不代表真实客户结果。

场景限定为一家虚构软件公司的“退款政策问答”。测试集只放三份 Markdown：refund-v1.md、refund-v2.md、vip-exception.md。v2 标记当前生效，v1 标记失效；VIP 例外只允许 support_lead 角色访问。准备 12 个问题：4 个普通退款、3 个过期规则、2 个 VIP 权限、2 个无答案、1 个跨章节。

第一轮 Demo 只索引 v2，用标题改写问题，页面显示答案和文件名。它大概率容易表现良好，但只证明主链路。第二轮把 v1 和 VIP 文档加入索引，增加普通客服与主管两个身份，并要求引用到具体段落。此时开始记录候选片段、版本、权限过滤和拒答原因。

第三轮模拟上线变更：把 v2 替换为 v3，故意让索引任务失败一次；再让模型调用超时，让权限服务返回空结果。验收不是系统仍然回答，而是页面能否显示“知识更新失败”“暂时无法核验权限”，并保持拒答或转人工。

| 推演检查 | 证据类型 | 通过条件 | | --- | --- | --- | | 旧版是否从候选撤回 | 可复现实验 | v1 片段不再出现在检索与引用中 | | 普通客服是否看不到 VIP 文档 | 工程约束 + 可复现实验 | 权限过滤发生在检索前，缓存和引用也不可达 | | 索引失败时是否继续展示旧状态 | 工程约束 | UI 显示失败，知识版本不被误标为最新 | | 无答案问题是否拒答 | 可复现实验 | 不使用模型常识补写政策，提供人工入口 | | 扩大文档范围是否增加运营成本 | 工程推论 | 先记录冲突、未命中和复核工时，再决定是否成立 |

这套推演可以用任意向量库和模型完成，重点是数据、权限和变更状态可观察，而不是比较组件跑分。

反例：窄范围、稳定文档的 RAG 可以直接成立

不是所有 RAG 都要先建设完整企业知识平台。如果知识域只有一套公开、版本稳定的产品手册，用户权限一致，问题主要是定位章节，更新频率又低，那么“解析、检索、引用、拒答”四步就可能足够。

例如给开源 CLI 的公开手册做问答，不涉及客户数据和内部权限；每次 release 后全量重建索引，并让回答始终附原文链接。这里可以先用小系统上线，不必提前建设复杂审批和多租户治理。

边界是这些前提必须真的成立。一旦加入内部例外政策、多个版本或不同角色，反例就不再适用。这个判断属于工程推论，应通过文档清单和权限矩阵核验。

一套上线前操作清单

• 每份文档有负责人、版本、生效和复核信息；
• 不同文档类型有解析与切片抽查；
• 权限在检索、缓存、日志和引用中一致；
• 评估集含真实、无答案、冲突和越权问题；
• 回答引用可达原文并显示版本；
• 未命中、差评和低置信进入运营队列；
• 系统有拒答、转人工和回滚路径。

生产验证要包含变更和故障

静态评估集只能覆盖已知问题。上线前还应演练文档更新、解析失败、索引延迟、模型超时和权限变更。

例如发布一份新版文档后，检查旧片段是否撤回、新引用是否可达、缓存是否失效。故意让索引任务失败，确认页面不会显示“已更新”。

还要测试知识库不可用时的降级：明确提示、返回原始搜索或转人工。悄悄用模型常识补答，会把基础设施故障变成业务错误。

这些演练不需要等到全量上线。小范围试点就能提前暴露状态和回滚设计。

成本与延迟也要按完整链路计算

生产 RAG 的时间不只来自一次模型调用，还包括权限查询、检索、重排、引用组装、内容安全和日志。某个组件单独很快，不代表用户请求稳定。

成本也包括文档解析、索引更新、评估和人工运营。不要用 Demo 的单次调用费用推算完整系统。

验收时分别记录正常、复杂和降级请求的耗时区间，并确认超时后用户看到什么。为了追求更低延迟而取消权限或引用，不是有效优化。

我的判断：先缩范围做闭环

我的判断是，一个小而有 owner 的知识域，比一个覆盖全公司的文档池更容易产生持续价值。

下一步选一种文档、一个用户组和五十个真实问题，跑通发布、权限、评估和反馈。闭环稳定后再扩文档类型，而不是先扩大索引规模。

接下来观察四个信号

• 观察信号一：新版文档发布后，旧片段是否能按预期撤回；
• 观察信号二：不同角色提问时，越权内容是否在检索前被过滤；
• 观察信号三：未命中和人工修改是否能归到明确负责人；
• 观察信号四：更换模型或切片策略后，固定评估集是否能发现回归。

这四个信号都能从日志、版本和测试结果中核验。若团队只能展示几条成功回答，却无法回答这四个问题，项目仍停留在 Demo 阶段。