08.1
接入层保存原始资源与版本
本章给出可实施的参考架构，属于本报告的设计综合，不声称已经在某个企业部署。接入层接收文字、页面图像、表格和业务记录，首先建立资源清单，而不是立即抽取知识。每个资源需要稳定标识、内容校验值、来源、采集时间、适用时间、权限和处理状态。同一网址内容改变时，应形成新版本；同一文件被重复上传时，应能识别重复但保留上传事件。这些基础信息决定后面能否定位证据、修复错误和删除派生数据。
解析过程应保留原始资源与标准化结果的映射。PDF页码、图片坐标、表格单元格和视频时间戳可以采用不同定位方式，但需要一致的证据接口。解析失败时不要悄悄跳过；应记录失败类型和受影响范围，并允许部分成功。对于扫描文档，OCR文字只是一个派生观察，原始页面仍然是核验依据。对于不断变化的业务系统，还应区分接收时间与事实生效时间，避免把晚到的数据误认为新发生的事件。接入质量是整个系统的上限之一：后续模型再强，也无法恢复已在入口丢失的页面、单位或版本条件。
08.2
观察层与实体层分开维护
抽取层应输出带类型的观察，而不是直接覆盖实体属性。一个观察至少包含主语候选、关系或属性、取值、限定条件、证据定位、抽取方法及审核状态。实体层负责稳定对象和身份解析，观察层负责不同来源说了什么。两层分开后，一个对象可以有相互支持或冲突的多个观察，而不必在写入时强行选出唯一真值。面向应用的确定属性，可以由经过审核的观察生成，并保留其支持集合。
本体与抽取器之间需要版本契约。假如本体将烹饪方法拆分成预处理与加热方式，旧模型输出不能自动解释为新结构。应保存本体版本、模型版本和映射规则，并对受影响数据进行重算或显式兼容。实体消歧也不宜依赖一次不可逆批处理：先生成候选，再记录合并决定与依据，最后更新查询视图。错误被发现时，应能撤销某一次合并而不丢失原始观察。这个设计增加一些存储与管理工作，但换来的是可修复性。没有修复通道的自动构图，往往会让早期错误在后续社区摘要与回答中持续扩大。
08.3
图索引向量索引和资源库协同
统一架构不要求把所有数据塞进同一种数据库。资源库存放原始文件与图像，图存储表达实体、事件和证据关系，向量索引用于相似候选，关键词索引用于精确名称与编号。它们通过稳定标识连接。图数据库适合关系约束与邻域访问，向量索引适合近似相似搜索；两者解决的问题不同。部署可以从简单组合开始，只有当查询延迟、规模或运维要求实际出现时，再引入更复杂的分片和专用服务。
关键工程难点是不同索引之间的一致性。资源被撤回后，如果图边已删除而向量仍可召回旧片段，系统仍可能泄露或引用失效内容。建议以资源版本为单位维护索引状态，使用待构建、可查询、失效和重建中的明确状态，并在查询时检查证据版本。更新过程可以先生成新索引，再通过版本指针切换，避免读到半成品。对删除请求则应先阻止检索，再异步清理各派生存储，并记录清理完成证据。所谓统一，主要是身份、版本和证据契约统一，而不是存储技术统一。这个认识有助于保持架构清晰，也便于替换单个组件。
08.4
查询规划形成可检查的证据包
查询服务先识别问题中的对象、时间、范围和回答类型，再选择检索动作。明确编号可以先走精确查找，关系问题可以扩展受限邻域，主题问题可以查询社区报告，视觉问题可以调取区域或页面。路由不是不可解释的魔法分类器：系统应记录触发了什么条件，以及在不确定时采用何种回退。对于涉及多个子问题的请求，可以显式生成查询计划，逐项说明需要哪些证据，而不是让模型一次性猜出全部答案。
交给生成器的证据包应包含原文片段、来源定位、关系路径、时间条件、权限检查结果和冲突提示。原文与摘要要有不同标签，事实与推断也要区分。生成后再做陈述级核验，检查每句话是否有足够证据，引用是否指向真正支持它的内容。如果只能支持部分问题，应回答已支持的部分，并说明剩余缺口。证据包可以作为独立接口，供不同语言模型使用，也可以直接展示给人工审核员。这样系统的核心资产不只是某一次流畅回答，而是一个可复查、可比较、可重新生成的证据集合。生成模型升级时，也更容易判断变化来自表达还是来自检索。
本报告原创设计
08.5
增量更新摘要失效与回滚
原始文档更新并不只影响一个片段。它可能改变实体身份、关系权重、社区归属和多个摘要，进而影响先前缓存的回答。建议把派生关系也记录成依赖图：某个摘要由哪些观察生成，某个观察来自哪些资源，某个查询缓存使用了哪些摘要。发生变化时，沿依赖关系找到需要失效的对象，而不是盲目重建全部数据或只更新最底层文件。社区重算可能产生较大范围变化，因此需要区分局部索引更新与结构性重分区。
回滚也应作为正常能力设计。模型升级后，如果抽取数量突然翻倍，可能是召回提高，也可能是把否定和假设当成事实。上线前应在固定样本上比较差异，检查高影响变化，再逐步切换。每次发布保存配置、版本、输入清单与质量摘要，使系统能够返回上一可用状态。对已经生成的答案，可以保留当时的证据快照，以解释历史输出；同时明确它是否仍代表当前知识。持续更新系统中的正确性是带时间的属性，不能靠某次离线测试永久证明。可靠运营需要让新知识进入、旧知识失效以及错误被撤销都成为可管理流程。
本报告原创设计
08.6
从原型到服务的最小交付契约
一个可演示原型可能只需要上传文档并返回回答，一个可用服务还需要明确失败行为。输入格式不支持、权限不足、没有证据、证据冲突和模型暂时不可用，应给出不同状态，而不是统一返回空白或编造答案。接口还应提供请求标识、知识版本、引用列表和可观察的处理阶段。这样使用者能判断是稍后重试、补充材料还是提交人工核验。内部日志可以更详细，但面向用户的说明应围绕任务，不必暴露无助于决策的底层实现名词。
验收时建议使用端到端用例，覆盖一条正常查询、一条无答案查询、一条跨版本冲突、一条权限隔离和一次资源删除。每条用例都检查用户最终看到什么，而不只检查某个模块返回成功。运维指标包括错误类型、证据覆盖、处理延迟和成本，但不能用平均延迟掩盖少量极慢请求。服务契约还要规定谁负责源数据、谁审核实体合并、谁处理用户纠错。技术架构只有与这些责任关系结合，才可能持续运行。本报告的架构图因此同时展示数据流和反馈回路：系统不仅从文档生成答案，也从被发现的问题返回源数据与知识维护流程。