知识库治理：从来源到答案的完整闭环
RAG 的可靠性不只由召回模型决定。以一份虚构的产品导出说明为例，讲清来源责任、对象身份、结构保真、制品发布、当前授权、版本回滚与使用反馈怎样形成一条可验证的链。
把判断过程，
也写下来。
围绕 AI 应用工程，记录方案背后的选择、证据与取舍。
RAG 治理 · 深入三篇
先让知识可管理，再让工具有边界，最后让召回形成可支持回答的证据。三篇可以连读，也可以从你正在遇到的问题开始。
阅读手记
Agent 的工具如何治理：从能力目录到一次可靠执行
工具多了以后，问题不只是模型会不会选错。能力声明、本轮暴露、输入输出契约、读写边界、执行预算和观测证据必须连接起来，才能知道一次调用为何发生、是否允许、结果能说明什么，以及何时应该停止。
召回策略怎么设计：从问题约束到答案证据
用一个跨版本、跨地域的构造产品支持问题，讲清查询改写、多路召回、候选预算、父子片段和最终引用怎样遵守同一份证据契约。每个阶段都需要明确自己能选择什么、必须保留什么，以及不能据此承诺什么。
继续读：排障、评估与架构
先跑通闭环，再决定要不要拆服务
单进程能减少部署成本，却不会自动带来可靠性。这篇从任务不变量、事务与租约、通知故障窗口一路推演到恢复和扩展，说明一个闭环怎样在进程退出、重复消息和外部结果未知时仍然可解释。
RAG 答错了，怎样找到第一次偏离
用一个带版本、角色和数量限制的产品问答，沿改写、检索、重排、上下文和生成走一遍。每一步都看实际产物，再用最小探针区分缺证据、传递丢失和答案越界。
评估器执行成功，为什么不代表结果达标
从一条结果记录讲到整份报告：拆开执行状态、类型化指标与业务判定，说明统计口径、裁判校准、Agent 行为证据，以及一次变更怎样得到可信的评审结论。
写下结论，也写下它的适用边界。
回到笔记角落