企业 RAG 落地：证据、上下文与任务执行的边界

我围绕智慧能源产品与业务资料实现了本地 RAG 应用，用于辅助了解操作流程、业务规则与系统设计：通过 BGE 向量与 BM25 双路召回、CrossEncoder 重排、多轮问题改写和 NDJSON 流式接口组织回答。以下结合实现经历展开设计建议，不表示每一项建议都已上线。我的关注点是让知识检索、答案展示和业务执行之间的责任边界可检查。

文档能检索，也要有资格被检索

推荐先给知识片段保留来源、章节、版本、生效范围与访问权限，再选择检索策略。设备编号、错误码等精确词与自然语言描述可以使用不同的召回方式，合并后去重与排序。权限应在检索服务侧约束，并在材料进入模型前核验，不能只在页面上隐藏引用。否则即使最终没有展示原文，受限信息也可能已进入生成上下文。

压缩上下文时保留适用条件

上下文预算有限，简单截断会把“仅适用于某型号”与操作步骤拆开。我的建议是把证据作为结构化单元：结论、适用条件、出处和原文位置一起保留。发生版本冲突时应展示差异或请求补充条件，材料不足时明确缺口。检索文本中的指令只能作为待分析内容，不能获得调用工具的权限。摘要也需要可回到原文，便于检查压缩是否改变了否定、时间或范围。

把答案错误拆成可定位的问题

评估集应同时覆盖可回答、无答案、版本冲突和权限受限的问题。排查顺序是原文是否存在、是否召回、是否进入上下文、是否被正确引用，最后才是生成措辞。增加召回数量可能找回证据，也可能引入相似却过期的材料；因此要同时观察证据命中与答案忠实度。引用链接存在，并不等于引用支持结论，需要检查具体断言与原文是否对应。

回答建议与执行操作分开验收

“给出巡检建议”和“创建巡检任务”需要两种完成条件。前者检查证据是否充分，后者检查授权范围、参数、工具返回值和业务状态。推荐在执行前形成可检查的操作对象，服务端再次验证资源权限；对写入操作保存业务请求标识。工具超时意味着结果未知，不能直接当作失败再次提交，应先查询任务是否已经创建，避免重复记录。

恢复任务需要状态，也需要副作用记录

多步骤协作可以保存检索结果、待执行动作和已完成步骤。LangGraph 的持久化文档区分了单次任务的检查点与跨任务存储；这对界定记忆范围很有帮助。但检查点不能单独保证外部写入只发生一次，仍需业务系统支持幂等或结果核对。我的建议是先让固定流程可以暂停、恢复、审计，再引入动态规划；每增加一种自由度，都应有相应的失败样例与退出条件。

技术参考：LangGraph 持久化与状态范围；MCP 工具规范与调用控制。文中的检索、评估与执行分层为推荐设计。