RAG 只解决问题的一部分
检索增强生成会在回答前把相关文档交给模型。当知识变化很快，或不适合全部塞进提示词时，它很有帮助。但 RAG 不会自动把文档变成事实，也不会自动防止查询跨越数据边界。真正困难的部分仍然是边界。
先划定四条边界
- 哪些数据可以建立索引，谁可以发现它？
- 一次请求可以使用多少时间和计算资源？
- 证据不足时系统应该如何回答？
- 文档替换或删除后，如何避免旧版本再次出现？
把便宜而可预测的工作放在边缘
边缘 Worker 适合处理可预测步骤：检查请求大小、规范语言、过滤权限、读取缓存并生成追踪编号。模型调用前先完成这些工作，可以减少无效消耗，也能在更换 AI 供应商后保留稳定的观察点。
有意识地保持索引小巧
没有必要第一天就索引所有资料。选择负责人和生命周期清楚的文档，为片段保存生效时间等元数据，再用真实问题测试检索结果。一个持续维护的小语料库，通常比无人负责的大集合更可信。
- 按工作区和访问范围划分文档。
- 每个片段保存来源、版本和生效时间。
- 检查检索结果的权限范围，而不只是相似度。
- 文档替换或删除时提供重新索引的路径。
成本是产品属性
在免费配置中，每次不必要的调用都会减少真实用户的空间。应尽早测量并限制输入长度、检索片段、重试次数和等待时间。超过边界时，界面应引导用户缩小问题，而不是悄悄继续发起请求。
安全的答案可以是“不知道”
如果检索到的段落不够相关，就请求澄清，或明确说明资料库没有答案。回答要附上来源，把推断和引用分开，也不要让模型编造内部链接。适时拒绝是体验的一部分，不是需要掩盖的错误。
可信的 RAG 不承诺回答所有问题；它知道能说什么，也知道何时停止。
结语
合理的边缘优先架构可以从很小开始：在 Worker 中完成授权和校验，在存储层管理文档生命周期，在限制内检索，证据足够时才调用模型。系统扩大后，成本、隐私和供应商选择仍掌握在团队手中。