9 处理、存储与数据服务

本章产出： 一套从原始数据到 Agent 消费端口的处理与服务分层，以及按访问模式选择存储和计算的决策方法。

当数据完成采集，接下来的问题不是“全部放进哪里”，而是“它将以什么方式被使用”。分析师扫描一年订单，现场助手查询一台设备，检索系统召回五段手册，训练任务读取千万样本，Agent 调用库存工具，这些访问模式在延迟、并发、一致性、数据形态和成本上完全不同。用一个数据库或一个“企业知识库”承载所有需求，看似简化，实际会把职责和服务等级混在一起。

面向 AI Ready 的处理架构，应保留可重放的事实，形成一致的实体与语义，针对不同消费方式发布稳定端口，并让来源、转换、质量和权限贯穿全链路。分层的目的不是制造更多技术名词，而是把变化隔离：源系统变化不应直接击穿 Agent，检索索引重建不应改变权威事实，模型升级也不应迫使企业重新治理全部数据。

9.1 从访问模式倒推架构

设计之前先列出消费者的读写形态：

访问模式	特征	适合的服务形态
分析与指标	大范围扫描、秒到分钟级	湖仓、查询引擎、语义指标层
单实体事实查询	小结果、低延迟、较强一致	API、键值/关系服务、缓存
文本与多模态检索	Top-K 召回、相关性排序	搜索与向量索引
关系探索	多跳连接、路径解释	关系查询、图服务
批量训练与评测	大吞吐、可复现版本	对象存储、湖仓快照、特征数据
实时上下文	连续更新、时间窗口	事件流、流处理、状态存储
Agent 行动	业务语义、鉴权、幂等	受控工具/API，而非直连表

山城精工的助手需要同时使用多种端口：从检索服务寻找适用手册和历史案例，从设备上下文 API 获取结构化配置，从库存业务 API 查询当前状态，从指标层观察区域维修趋势。强行把这些都转换成文本并向量化，会丢失精确数值、时效和事务语义；让 Agent 自由生成 SQL 直连生产库，又会放大安全和稳定性风险。

9.2 五层处理与服务模型

可以将数据链路分为原始证据、标准化事实、领域语义、消费产品和运行反馈五层。层数不是必须创建五套物理系统，而是明确五种责任。

9.2.1 原始证据层

原始层保存从源端获得的记录、文件或事件，并附带来源、采集时间、模式版本和校验信息。它服务于审计、重放和重新处理，而非直接向所有用户开放。原始并不等于毫无治理：敏感信息仍需加密、隔离和保留控制，恶意文件仍需检测。

对数据库变化可以保存带操作类型和事件时间的不可变日志；对文档保存原文件摘要、版本和发布元数据；对外部 API 保存必要的响应版本或可重现标识。若解析规则或实体匹配算法改善，团队可以从受控原始证据重建派生结果。

9.2.2 标准化事实层

这一层处理类型、单位、时区、编码、去重和基本质量，使同类记录具有一致技术结构。它还建立稳定的业务标识和来源映射。例如，把不同系统中的设备号映射到企业设备标识，把温度统一为同一单位，把客户区域代码转换为受控枚举。

标准化不能静默“修正”无法判断的冲突。应保留原值、转换规则、置信度和异常状态。一个设备对应两个客户时，系统可以把它标记为待确认，而不是任意选择。对 Agent 来说，明确的不确定比错误的确定更安全。

9.2.3 领域语义层

领域层将事实组织为业务能够理解的实体、关系、指标和规则。设备、客户、合同、工单、零件、手册及其关系在这里形成统一语义；“可承诺库存”“首次修复”“有效保修”等概念拥有定义、负责人和时间范围。

语义层不是只为 BI 服务。Agent 要理解某字段代表什么、单位是什么、哪些关系允许连接、规则何时生效，同样依赖语义。结构化语义可以通过指标服务、实体 API 或查询模型提供；业务词汇、描述和关联还可以进入上下文层，帮助检索和工具选择。

9.2.4 消费产品层

消费层围绕任务发布数据产品。它隐藏内部处理复杂性，以稳定端口提供明确承诺。一个产品可以组合结构化事实、文档检索和业务规则，却不应让消费者了解所有内部表。

山城精工的“设备售后上下文产品”可以输出设备概览 API、适用资料检索、相似案例检索和备件查询工具。每个端口有独立 SLO 和权限，内部可以使用湖仓、搜索索引、缓存等不同技术。产品层负责把它们组合成面向任务的一致体验。

9.2.5 运行反馈层

AI 数据链路本身也产生数据：查询、召回、证据引用、工具调用、响应时间、成本、用户修订、业务结果和安全事件。这些信息进入受控反馈层，用于评测、运营和改进。反馈数据可能包含用户输入和敏感内容，不能因为用于“优化模型”就绕过隐私与保留要求。

反馈要关联数据、规则、索引和模型版本，使一次错误可以重放。经过审核的高价值修订才能成为新的案例、规则或训练样本，避免错误自我强化。

9.3 存储选择：一种事实，多种表示

湖仓适合保存大规模历史和可重现快照，关系或键值服务适合低延迟实体查询，搜索引擎适合关键词与过滤，向量索引适合语义近邻，图存储适合复杂关系遍历，流状态适合窗口和当前聚合。企业无需为每一类都引入独立产品，但要承认访问模式不同。

关键原则是区分权威事实与派生表示。向量不是原文的权威副本，搜索索引不是库存事实来源，缓存也不是最终交易状态。每个派生表示应记录源标识、源版本、生成规则、生成时间和索引版本；源数据变更或撤回时，能够找到并更新所有派生物。

“一种事实，多种表示”也意味着一致性有成本。不是所有派生系统都需要强一致，但消费者必须知道允许延迟。手册索引可以采用最终一致，并在结果中展示版本；库存建议则应在行动前调用权威服务确认。架构质量不在于所有系统永远同步，而在于一致性选择与任务风险相匹配。

9.4 结构化数据处理

结构化处理通常包括清洗、主键解析、去重、关联、维度历史、指标计算和质量检查。面向 Agent 还需额外关注：

保留事件时间和有效时间，回答“当时是什么”与“现在是什么”；
对实体匹配给出置信度和人工确认状态；
为枚举、单位和代码提供可读语义，而非让模型猜测；
对派生指标保存定义、粒度、窗口和计算版本；
对缺失和异常明确表达，不用默认值伪装事实；
将行列权限和目的限制带到消费端。

例如设备当前配置由出厂记录和现场变更合成。处理逻辑要保留每次变更的有效期，避免用今天的配置解释两年前的故障。若现场换件缺少确认，输出应标记“待核实”，并触发 Agent 向工程师澄清。

9.5 文档与多模态处理

文档处理不是简单提取纯文本。企业手册中，标题层级、表格、警告框、图注、页码和适用型号都可能决定含义。处理链通常包括文件验证、版面解析、OCR、结构恢复、语言识别、表格抽取、图片描述、分块、元数据关联和质量评估。

分块应尽量保持语义单元完整。固定字符切分可能把一条安全警告与操作步骤分开，也可能让表头和数据行失联。更稳妥的方式是结合章节、段落、表格和业务对象，并保留父子关系。每个块应带文档标识、版本、章节、页码、适用范围、权限和内容摘要，以便引用和撤回。

OCR 置信度、解析失败和缺页要进入质量信号。低质量扫描件不应与正式数字手册同等排序。图像或录音需要明确是否允许调用外部模型处理，以及处理后的派生文本能否保留。

9.6 批处理、流处理与即时计算

批处理吞吐高、易于重算，适合历史整理和稳定指标；流处理延迟低，适合告警、状态和连续规则；即时计算在请求时调用权威服务，适合价格、权限、库存和高变化事实。一个成熟方案常常组合三者。

山城精工可以每日批处理已结案工单并生成审核案例，通过流处理维护设备最近告警窗口，在用户请求时即时查询库存和权限。若把所有数据都做成实时流，成本和运维复杂度不必要地增加；若全部每日批处理，现场状态又失去价值。

流处理设计要说明事件时间、窗口、水位、状态保留、迟到更正和幂等输出。批处理要说明快照、分区、回补和重跑。即时调用要说明超时、缓存、熔断和降级。三种结果汇合时，还要定义冲突优先级。

9.7 缓存不是透明加速器

缓存可以降低延迟和模型工具调用成本，但会引入陈旧、权限和失效问题。缓存键必须包含影响结果的身份、区域、版本和目的，避免用户之间串数据。敏感返回不应进入共享缓存，权限变化要能触发失效。

不同内容设置不同有效期：稳定的术语解释可较长，设备状态较短，库存只能短暂缓存并标明查询时间。对于高风险动作，即使命中缓存也可在执行前再次确认。缓存命中率不是唯一目标，错误使用陈旧信息的风险同样应被监测。

9.8 数据服务的契约

向消费者发布的每个端口都应具备：

任务级命名与描述，而非暴露内部技术表；
输入输出模式、必填项、单位、枚举和错误码；
身份认证、授权、范围和目的限制；
数据新鲜度、质量、可用性、延迟和限流承诺；
版本兼容、弃用窗口和变更通知；
来源、更新时间、置信或质量信号；
监控、支持、审计和成本归属。

Agent 工具尤其要返回紧凑而明确的结构。不要把整张数据库记录塞入上下文，也不要只返回一段无法校验的文本。返回值可以同时包含机器字段、人类说明和证据标识，让模型能够组织回答，下游程序能够确定性校验。

9.9 可观测性贯穿数据与服务

基础设施“绿色”不代表数据正确。可观测需要覆盖四类信号：管道是否运行，数据是否健康，服务是否满足 SLO，任务是否产生正确结果。一次回答变差可能源于源数据停止、解析质量下降、索引未更新、缓存陈旧或服务超时，必须能够跨层定位。

血缘应连接源记录、转换任务、数据产品、索引与 Agent 端口；版本应连接数据快照、语义定义、评测集和模型。告警要路由给能行动的所有者，并附影响消费者和处理手册。没有影响分析的告警洪水，只会让团队习惯忽视。

9.10 成本与性能的联合设计

性能目标要按任务分解。用户可接受的总响应时间，需要分配给身份检查、上下文查询、检索、模型生成和工具调用。若检索召回过多，既增加模型成本又可能降低准确性；若所有事实都即时查询，服务依赖会增加；若预计算过多，又产生存储和更新成本。

可采用分层模型路由、查询缓存、冷热索引、批量嵌入、按需加载和结果压缩，但任何优化都不能破坏来源和权限。成本应按“成功完成的业务任务”核算，并与质量护栏一起观察。便宜但错误的回答没有经济性。

9.11 山城精工的服务分层

首期目标架构可以这样组织：

原始区保存数据库变化、手册版本、工单快照和告警事件；
标准化层统一设备、客户、零件标识与时间单位；
领域层形成设备配置历史、保修语义、故障分类和维修指标；
产品层发布设备上下文 API、适用文档检索、相似案例检索和库存查询工具；
反馈层记录引用、修订、最终故障原因、实际备件与结案结果。

结构化事实和文档证据通过统一设备标识连接，但物理存储可以不同。Agent 编排层只面向产品端口，不直连原始区。上下文服务返回来源和时间，库存工具在执行前重新确认，所有写入保持人工审批。

9.12 本章交付物：处理与服务蓝图

架构评审时应提交一张蓝图，标注数据从源端到消费端的每次重要转换和表示，并回答：

权威事实在哪里，哪些是派生索引或缓存；
如何保存原始证据并支持重放；
实体、语义、有效时间和质量如何形成；
批、流、即时计算各自承担什么；
不同访问模式使用什么服务端口；
版本、血缘、权限和删除如何贯穿；
每个端口的 SLO、负责人、降级与成本是什么；
Agent 反馈如何关联业务结果并经审核回流。

好的分层不会让数据离业务更远，而是让每层责任更清晰。源变化可以被吸收，语义可以被复用，索引可以被重建，服务可以被度量，Agent 可以在不理解底层复杂性的情况下获得可信上下文。企业由此拥有的不是一堆存储技术，而是一条可解释、可演进的数据供应链。