4、系统架构总览：数据采集层、数据处理层、模型推理层、应用服务层的整体设计

宠物智能辅助诊断系统并非单一算法或单一设备的堆叠，而是一个从物理世界采集信号到最终输出诊断建议的完整数据闭环。理解系统架构，是落地部署、性能调优与故障排查的前提。本章将系统拆解为四个核心层次：数据采集层（感知物理世界）、数据处理层（清洗与特征工程）、模型推理层（算法决策核心）与应用服务层（人机交互与业务闭环），并深入剖析各层之间的接口约束与工程落地要点。

上图展示了四层架构的完整数据通路。值得注意的是，反馈回路（图中虚线）是系统持续进化的关键——应用服务层产生的兽医标注结果、用户反馈数据，会回流至数据处理层作为新的训练样本，驱动模型迭代。下面逐层展开设计要点。

4.1 数据采集层：感知的完整性与可靠性

核心原理

数据采集层是系统的“感官”。其核心任务并非简单记录数据，而是在宠物自然生活状态下，无创、连续、低干扰地获取高质量生理与行为信号。常见信号源包括：

• 可穿戴设备：项圈（活动量、叫声）、体温贴片（核心体温）、心率/血氧爪套。
• 环境感知设备：智能摄像头（姿态、行为）、智能喂食器（进食量、饮水频次）、猫砂盆（排泄频次）。
• 手动输入：主人观察日志、兽医体检数据（血液生化、影像）。

判断方法与操作流程

在选型与部署时，需按以下流程评估采集层质量：

1. 采样率与精度匹配：体温监测 0.1Hz 足够，心音/呼吸音需 200Hz 以上，行为识别视频需 ≥15fps。
2. 时间同步机制：所有设备需统一时钟源（NTP 或 BLE 同步），多模态融合时时间戳误差应 <50ms。
3. 抗运动伪影：宠物活动时传感器易产生噪声，需在硬件端加入加速度计辅助判断信号有效性。
4. 功耗与续航：连续监测设备续航应 ≥7 天，否则用户依从性差。

案例拆解：多设备协同采集的工程实践

某宠物医院部署远程术后监护系统，目标是对 20 只术后猫进行 72 小时连续监测。初始方案仅使用体温贴片，但发现单独体温数据无法判断“应激性发热”与“感染性发热”。关键改进：增加项圈加速度计与摄像头行为识别，形成“体温+活动量+姿态”三模态数据。部署中遇到 BLE 信号在宠物医院金属笼舍环境中衰减严重，导致丢包率高达 15%。解决方案：在每排笼舍加装 BLE 网关，并将采集端改为“本地缓存+批量上报”模式，最终丢包率降至 0.5% 以下。该案例表明，采集层设计必须考虑物理环境约束，而非仅关注设备参数。

常见误区与复盘

• 误区一：认为数据越多越好。实际上，无效噪声数据会占用带宽并干扰模型训练，应设置“有效数据筛选”逻辑。
• 误区二：忽略设备固件升级通道。采集层设备分散在用户家中，需设计 OTA 远程升级能力，否则算法优化后无法部署到端侧。
• 复盘要点：每次采集方案变更后，应重新评估数据质量指标（完整率、准确率、时效性），并建立数据质量看板。

4.2 数据处理层：从原始信号到可用特征

核心原理

数据处理层承担“翻译”职责，将采集层产生的原始时间序列、图像帧、日志记录，转换为模型可消费的标准化特征张量。该层设计直接决定模型上限——垃圾进，垃圾出。核心处理单元包括：

• 数据清洗：剔除生理不可能值（如体温 25℃）、插值填补短暂缺失。
• 信号滤波：针对可穿戴设备，使用带通滤波去除运动伪影（0.5-10Hz 带通常用于心率和呼吸）。
• 时间窗切片：将连续信号切分为 5-30 秒的窗口，并提取统计特征（均值、方差、峰值）、频域特征（FFT 主频）、熵特征。
• 多模态对齐：将不同采样率的数据统一到同一时间轴。

技术选型与流程

实战场景：特征漂移的监控

某系统上线后，模型准确率从 85% 降至 70%。排查发现，并非模型退化，而是特征分布漂移——夏季宠物活动量普遍增加，导致“平均活动量”特征分布整体右移。处理方式：建立特征分布监控看板，每日计算 PSI（群体稳定性指数），当 PSI > 0.2 时触发告警，提示重新训练或特征标准化。该案例说明，数据处理层需包含特征质量监控模块，而非仅做一次性转换。

常见误区

• 误区一：过度清洗导致信息丢失。例如，将心率变异性（HRV）中的异常搏动全部剔除，反而丢失了心律失常的关键信息。
• 误区二：忽视数据版本管理。特征定义变更后，历史数据需重新处理，否则训练集与线上数据不一致。建议使用特征存储（Feature Store）管理版本。

4.3 模型推理层：算法决策的引擎

核心原理

模型推理层是系统的“大脑”。该层负责加载训练好的模型，对处理后的特征进行预测，输出如“皮肤炎疑似概率 0.82”“癫痫发作前兆”等结构化结果。设计重点在于推理性能、模型版本管理与多模型路由。

判断方法与部署策略

1. 推理框架选型：TensorFlow Serving 适合 TF 模型；Triton Inference Server 支持多框架（PyTorch/ONNX/TF）且支持动态批处理；边缘端可选 TensorRT 或 TFLite。
2. 延迟与吞吐权衡：在线诊断要求 P95 延迟 <300ms；离线批量分析可放宽至秒级。使用 GPU 加速时需考虑显存占用与冷启动时间。
3. 模型路由策略：根据输入类型路由——简单规则模型（如体温阈值）优先，复杂模型兜底；或按病种路由至专科模型。
4. 灰度发布：新模型先切 5% 流量，对比新旧模型输出差异与业务指标，再逐步放量。

案例拆解：多模型融合的推理链路

某智能猫砂盆系统需判断“泌尿系统异常”。单一模型（仅分析排泄频次）误报率高。改进方案：构建三模型融合链路——模型 A（排泄频次异常检测，基于 LSTM）、模型 B（尿液颜色识别，基于 CNN）、模型 C（活动量下降趋势，基于 Transformer）。推理层通过加权投票机制融合结果：仅当 A 与 B 同时阳性，或 A 与 C 同时阳性时，才触发告警。实际运行中，误报率从 40% 降至 8%。该案例表明，推理层不仅是模型容器，更是决策编排的场所。

常见误区与复盘

• 误区一：忽视推理日志记录。每次推理的输入特征、模型版本、输出概率、耗时都应记录，否则无法回溯误判原因。
• 误区二：模型热更新机制缺失。宠物品种差异大，新收集的特定品种数据需快速微调模型，推理层应支持热加载新模型版本而不中断服务。
• 复盘要点：建立推理质量看板，监控各模型分桶的准确率、覆盖率、平均置信度，及时发现数据漂移或模型退化。

4.4 应用服务层：业务闭环与用户体验

核心原理

应用服务层是系统的“脸面”，直接面向兽医与宠物主人。其核心任务是将模型输出的“概率”转化为可执行的行动建议，并形成业务闭环。该层包含：

• 兽医工作台：展示多维度监测数据、模型诊断建议、历史趋势对比，支持标注与反馈。
• 主人端 App：接收异常告警、查看健康报告、预约问诊。
• 告警通知中心：基于规则引擎（如“体温 >39.5℃ 持续 30 分钟”）触发分级告警（App 推送/短信/电话）。
• 诊断报告生成器：将模型输出、关键证据链（异常波形图、行为片段）整合为可读报告。

关键设计原则

实战场景：告警风暴的治理

系统上线初期，告警频率过高（每天 30+ 条/宠物），导致主人“告警疲劳”并关闭通知。根因分析：单一指标触发即告警，且阈值过于敏感。优化措施：① 引入“组合条件触发”——需同时满足体温异常与活动量下降才告警；② 增加“静默期”——同一宠物 4 小时内相同告警只推送一次；③ 引入“严重程度分级”——黄色（观察）、橙色（建议咨询）、红色（立即就医）。优化后，有效告警率提升 60%，用户留存率显著改善。该案例说明，应用服务层的业务规则设计与算法模型同等重要。

常见误区与总结

• 误区一：将模型输出直接作为最终诊断展示给主人，引发恐慌或误导。应增加“建议就医”等中性引导话术。
• 误区二：忽略离线场景。主人可能在网络不佳时查看报告，App 需支持关键数据本地缓存。
• 总结：应用服务层是系统价值的最终体现。架构设计时应预留 A/B 测试能力，便于验证不同交互策略对用户行为的影响。

四层架构并非孤立存在，而是通过数据流与反馈流紧密耦合。在实际落地中，建议采用“小步快跑”策略：先以最小可用架构（单机版采集+规则引擎）跑通业务，再逐步引入流处理与复杂模型。架构设计应保持灵活性，避免过度设计——对于单诊所场景，Kafka+Flink 可能过于沉重，轻量级 Redis+Python 脚本或许更合适。最终，架构的优劣以诊断准确率、系统稳定性、用户满意度三项核心指标为评判标准。