RAG 上线后的成本，藏在更新与权限里

「加个 RAG」听起来像下个迭代就能交付的功能：让模型读公司文档，再回答用户的问题。但作者的判断是，RAG 做演示便宜，长期维护昂贵，成本大多藏在演示绕开的地方。

这篇最有用的部分，是把讨论从「向量库怎么选」拉回「答案由谁负责」。对准备接入内部知识库的前端、全栈团队来说，先看清内容更新、权限、评估这些账，再决定要不要搭检索流水线，能少走不少弯路。

为什么一天能做出演示，上线却可能超过一个季度

RAG，也就是检索增强生成，基本流程不复杂：把文档切块，生成嵌入向量，存进向量库；用户提问时找出最相关的几块，放进提示词，让模型据此回答。

作者用一个典型场景说明演示的迷惑性：一天搭好流程，挑五个自己知道答案的问题，答对四个，现场就可能很满意。但真实产品要面对没挑过的问题、没清理过的文档，以及权限各不相同的用户。作者认为，可靠版本可能需要超过一个季度。这里没有项目样本或工期统计，应把它看作经验判断。

真正增加工作量的，首先是文档同步。首次导入只是脚本，持续更新却需要一套系统：页面修改、PDF 替换、wiki 空间归档，都要反映到索引里。更麻烦的是，流水线可能停止更新却没有报错，此时助手仍能流畅地引用去年的政策。

其次是权限。源系统知道谁能读什么，向量库里的文本块却不会自动继承这些规则。团队必须把访问规则带入索引，并在每次查询时过滤。演示通常用一个账号导入全部内容，这个问题很容易被遮住；上线后，一次遗漏就可能让普通用户问出薪资表里的内容。

还有文档冲突。公司同时保留两三个差旅政策版本时，相似度检索并不知道哪个有效。旧草稿可能更贴近用户的措辞，于是排在前面。模型再把不同版本拼成一个自信的答案，结果哪个版本都没忠实反映。

检索能找到相关文字，却不会自动替团队确定哪份文字有效。

评估为什么应该比调提示词更早开始

作者最愿意优先投入的是评估，因为「演示看起来不错」无法回答系统到底有多可靠。

评估需要一组真实问题，以及事先写清楚的正确答案。检查时还要拆成两层：检索有没有找到正确段落，模型有没有忠实使用这些段落。前者出错，调整生成提示词未必有用；后者出错，也不能只怪向量库。

没有这两层检查，修改切块大小、提示词或模型，都容易变成凭感觉试效果。回归问题最后由用户发现，反馈成本更高。

运行成本也会持续发生。按原文描述，每次查询都涉及问题向量化、搜索，以及携带检索文本的模型调用；放进上下文的文本块越多，单次问题的成本也越高。这里指的是加入提示词的内容增加，不能直接理解成知识库每多存一块，所有查询就必然更贵。

更换 embedding 模型时，原文强调要重新计算整个语料库的向量，因为不同模型产生的向量不能直接比较。升级聊天模型也会改变回答行为，评估集需要捕捉这种变化。模型升级因此也是一次需要验证的系统变更。

哪些需求值得用 RAG，哪些可以先省下来

作者认可的 RAG 场景，有几个具体条件：资料多到放不进提示词，更新频繁到不适合靠人工持续整理；用户用自己的语言提问，措辞与文档不同，关键词搜索容易漏掉；用户希望直接得到答案，还能点击来源核查，而不是打开十个链接逐一阅读。

大型且维护良好的内部支持知识库符合这个描述。跨合同、研究论文搜索也可能适合，因为读者既需要答案，也需要核对原句。

但作者建议，搭流水线前先试几种更便宜的办法。

搜索不好用，可以先改标题、补同义词、完善关键词索引。文档内容错了，就先修正文档；删除旧差旅政策，往往比让检索器学会忽略它更直接。如果几十个问题已经覆盖大部分访问量，可以由熟悉业务的人整理 FAQ，并明确维护责任。

还要检查是否真的需要检索。相关资料如果都能放进模型上下文窗口，可以直接放入提示词，再用 Prompt caching 降低重复部分的费用。这样能消除「找错文本块」这一类故障，但资料本身的正确性仍然需要有人负责。

作者给出的开工门槛很具体：写代码之前，先拿到二十个真实问题及其正确答案，再明确一位文档负责人。前者成为评估集，后者负责更新内容、确定有效版本和访问范围。

我的判断

我赞同把评估集和内容负责人放到技术选型前面。内部知识问答的可靠性，确实依赖文档是否可信、权限是否正确；把这些问题留给模型，通常只会让错误更难辨认。

不过，原文没有提供成本账单、准确率对照，也没有比较不同检索方案。「一天演示、超过一个季度上线」以及先做搜索或 FAQ 更划算，都是作者的经验之谈，不能直接当成所有团队的预算依据。

二十道题适合作为启动门槛，却不能证明系统已经可靠。原文没有说明问题如何覆盖权限差异、版本冲突或无答案情况，这些仍需要团队补齐。

直接把资料塞进上下文，也有适用前提：资料装得下，而且当前用户有权查看这些内容。Prompt caching 降低的是重复输入的部分成本，不能代替权限管理。相比之下，关键词搜索和 FAQ 的优势是维护路径直观；RAG 的价值则在于处理更大规模的资料和更自由的提问。应先确认需求落在哪一边。

能拿来做什么

• 给内部文档接 AI 问答之前，先收集二十个真实问题，写出正确答案及对应原文，让它们成为后续修改的检查基准。
• 开发 Node 检索服务时，把文档更新、归档删除和逐次查询的权限过滤列入交付范围，并明确由谁处理同步异常。
• 调整切块大小、提示词或模型时，分别记录是否检索到正确段落、回答是否忠实引用，避免只凭回答读起来是否顺畅判断效果。
• 为前端团队搭知识助手时，先检查搜索、旧文档和高频 FAQ；资料能放进上下文时，再评估直接输入配合 Prompt caching 是否已经够用。