先判断 RAG 值不值得做

当回答依赖“此刻应该选中哪份资料”时，检索增强生成才真正有用。如果参考资料很短、长期稳定，或者任务根本不需要外部事实，直接提供材料往往更可靠。

判断重点不是“RAG 是否先进”，而是它能否消除当前工作流里一个已经被证实的资料选择瓶颈。先用真实问题证明瓶颈存在，再决定是否承担索引、权限、评测和更新链路。

先看每次请求之间会改变什么

从五个维度判断：

**变化速度：**关键事实多久更新一次？
**资料规模：**答案可能散落在多少内容里？
**可追溯性：**重要结论是否必须展示出处？
**访问边界：**不同用户能否看到不同文件？
**维护责任：**谁负责新增、下线、标注和测试资料？

变化越快、资料越多、追溯和权限越复杂，RAG 的理由越充分；但前提是团队愿意长期承担维护责任。

先试三个更小的方案

在建立索引之前，依次测试：把当前文件随请求附上、把一份短而经过批准的参考资料直接放入上下文、对结构化字段使用确定性查询。能满足验收契约的最小方案，通常最容易观察和修复。

检索不会自动提高质量。它只是增加了一项新决策：哪些片段有资格进入模型上下文。

用投资门槛作出决定

为下表逐项写证据，而不是凭感觉打分：

判断项	支持建设的证据	暂缓建设的信号
请求时选择	不同问题确实需要不同资料	每次都使用同一份短材料
资料范围	人工无法稳定定位所需段落	文件少且负责人可以直接指定
更新频率	旧内容必须及时退出回答范围	内容固定且可随版本发布
引用要求	决定必须回到原文核验	任务只是改写或格式转换
权限差异	可见资料取决于请求者身份	所有获准用户权限完全相同
运维能力	有人负责摄取、删除、测试和事故	资料无人维护、版本状态不清

只要权限过滤无法在检索前落实，或资料本身没有生效与失效状态，就先暂停。系统找得更快并不能弥补把不该看的内容送进模型这一问题。

在开发前做一次离线检索试验

从真实工作中选一组问题，为每题标记允许资料、必须命中的段落、应排除的近似资料，以及“资料没有答案”这一正确结果。先只测试检索，不让模型生成回答。记录目标段落是否进入候选、排在什么位置、错误资料为何被选中，以及权限过滤是否早于相似度排序。

接着把检索结果交给回答环节，分别检查证据支持、限定条件保留和引用定位。检索命中却回答错误，与检索从未找到正确资料，是两类不同问题。只有两个环节都达到验收条件，完整方案才具备发布依据。

试验结论应该是“建设”“先修资料治理”或“继续使用更小方案”，而不是笼统的“效果不错”。

案例：分地区的制度资料库

一家公司的制度随国家、员工类型和生效日期变化，资料有数百份。回答必须引用提问者有权查看的准确条款。把全部资料塞进上下文不可行，静态摘要又很快过期。

这里的 RAG 有清楚职责：先按权限和地区过滤，再寻找候选条款，并保留可核验引用。评测必须包含旧版本、名称相近的制度，以及权限不同的用户。

反例：稳定的写作规范

一个小团队只有两页写作规范，每半年更新一次，而且每项写作任务都使用同一套规则。增加检索服务会带来索引、监控和失败路径，却几乎没有减少上下文。

更合适的做法是给规范标注版本并直接提供。只有当资料明显增长、权限开始分层，或需要从大型案例库挑选示例时，再重新评估 RAG。

写下系统能够长期兑现的承诺

明确谁负责资料批准、删除、权限变更、时效复核、检索评测和事故处理。只要其中一项无人负责，系统就无法持续承诺“答案有据可查”。

同时画出失败时的用户路径：检索为空时是明确说没有证据、提出澄清问题，还是转给人工；来源冲突时保留哪些差异；索引延迟时能否临时回退到已知版本。把这些行为写进验收案例，而不是上线后再临时决定。

RAG 决策记录模板

一页记录至少包含：目标任务、当前资料选择失败、三种更小方案的试验结果、资料负责人、权限执行点、离线检索案例、回答验收门槛、预期更新频率、停止条件和复评日期。负责人变更或资料结构改变时重新评估，不要把一次立项判断当作永久许可。

常见问题

资料很多就一定要做 RAG 吗？ 不一定。若任务只读取一个由用户明确指定的文件，资料总量再大也不需要跨库检索；文件解析可能才是真问题。

能不能先接向量数据库再评测？ 可以做可丢弃的技术试验，但不能以“已经接好”为发布理由。应先固定真实问题、正确资料和拒答案例，否则无法判断检索是否有用。

RAG 和长上下文怎样选择？ 比较的不是最大容量，而是资料选择、版本更新、权限执行、引用定位和长期维护。对短而稳定的批准材料，直接上下文通常更简单；对请求间变化明显的资料集合，检索才可能创造价值。

不适用边界

RAG 不能让错误资料变成事实，不能自动消解互相矛盾的制度，也不能保证模型正确使用检索片段。它解决的是证据进入上下文的问题；引用审计和回答评测仍是另外两道关口。