3. 模型服务数据流：在线推理数据流全景
在线推理数据流是模型服务在运行时处理请求的完整链路。理解这条链路是定义数据质量规则的前提——每个环节都可能引入或暴露数据质量问题。本章从请求入站到日志回传，逐层拆解在线推理的五个核心阶段。
3.1 在线推理数据流五阶段总览
一次完整的在线推理请求，依次经过以下五个阶段：
| 阶段 | 英文名称 | 核心职责 | 数据质量关注点 |
|---|---|---|---|
| 1. 请求入站 | Request Ingestion | 接收客户端请求，完成协议解析、鉴权、限流 | 请求格式完整性、字段缺失、非法字符 |
| 2. 特征工程 | Feature Engineering | 从原始请求提取、转换、拼接特征 | 特征缺失、特征值越界、特征分布偏移 |
| 3. 模型推理 | Model Inference | 将特征向量送入模型，执行前向计算 | 输入张量形状异常、NaN/Inf 输出 |
| 4. 结果后处理 | Post-processing | 对模型原始输出做阈值过滤、排序、格式化 | 结果置信度异常、空结果、格式错误 |
| 5. 日志回传 | Log Feedback | 将请求、特征、结果、耗时等写入日志系统 | 日志字段遗漏、时序错乱、采样率异常 |
关键认知：数据质量规则需要在每个阶段设置检查点，而不是仅在模型推理前后做一次校验。灰度部署期间，规则可以分阶段开启，避免一次性引入过多拦截导致服务抖动。
3.2 在线推理数据流架构图
下图展示了在线推理服务中数据流经的完整架构，包含五个阶段及其之间的数据传递关系：
3.3 各阶段数据流详解
3.3.1 请求入站
请求入站是数据流的入口。客户端通过 HTTP/gRPC 协议发送推理请求，服务端完成协议解析、身份鉴权、限流控制后，将原始请求数据传递给下一阶段。
- 常见数据质量问题：请求体 JSON 格式错误、必填字段缺失、字段类型不匹配（如字符串传成数字）、请求体过大超过限制。
- 灰度部署检查点：在入站阶段开启请求格式校验规则，拦截格式异常请求并记录告警，但不阻断正常流量。
3.3.2 特征工程
特征工程是数据质量风险最高的阶段。原始请求数据需要经过特征提取、缺失值填充、归一化/标准化、特征交叉拼接等操作，最终生成模型可接受的固定维度特征向量。
- 常见数据质量问题：特征缺失（如用户画像特征未命中）、特征值越界（如年龄字段出现负数）、特征分布偏移（线上特征分布与训练集不一致）、特征拼接顺序错乱。
- 灰度部署检查点：开启特征完整性规则和特征值域规则，对每个特征做非空、范围、类型校验。
实践建议：特征工程阶段的数据质量规则建议优先灰度部署。因为特征错误会直接导致模型推理结果异常，且错误特征往往难以在后续阶段追溯。先覆盖 Top-10 高频特征，再逐步扩展到全量特征。
3.3.3 模型推理
模型推理阶段将特征向量送入模型执行前向计算。对于深度学习模型，此阶段涉及张量形状对齐、数据类型转换（如 float32/float16）、GPU/CPU 设备分配等操作。
- 常见数据质量问题：输入张量形状与模型期望不匹配（如 batch size 不一致）、输入数据包含 NaN 或 Inf 值、模型输出概率之和不为 1（分类模型）、模型推理超时返回默认值。
- 灰度部署检查点：开启推理输入形状规则和推理输出数值规则，检测 NaN/Inf 输出和异常置信度。
3.3.4 结果后处理
模型原始输出通常需要后处理才能返回给客户端。例如：对分类概率做阈值过滤（只保留置信度 > 0.5 的结果）、对检测框做 NMS 去重、对排序结果截断 Top-K、将内部数据结构序列化为客户端协议格式。
- 常见数据质量问题：后处理逻辑中阈值设置不合理导致空结果、排序算法 bug 导致结果顺序错误、序列化时浮点数精度丢失、返回结果字段名与 API 文档不一致。
- 灰度部署检查点：开启结果完整性规则（确保返回结果不为空且字段齐全）和结果格式规则（校验 JSON 结构是否符合预期）。
3.3.5 日志回传
日志回传是数据流的终点，也是数据质量闭环的关键环节。服务端将请求原文、特征向量、模型输出、后处理结果、各阶段耗时、错误码等信息写入日志系统，用于后续监控、分析和模型迭代。
- 常见数据质量问题：日志字段遗漏（如缺少 request_id 导致无法关联）、日志时序错乱（异步写入导致顺序颠倒）、采样率异常（采样比例过高或过低影响统计准确性）、日志内容包含敏感信息（如用户手机号未脱敏）。
- 灰度部署检查点：开启日志字段完整性规则和日志采样率规则，确保日志数据可用于后续质量分析。
3.4 数据流中的质量规则部署策略
在灰度部署场景下，数据质量规则不是一次性全部开启的，而是按照数据流方向分阶段、分比例逐步生效。下表展示了推荐的灰度部署策略：
| 灰度阶段 | 开启规则范围 | 流量比例 | 预期效果 |
|---|---|---|---|
| Phase 1 | 请求入站 + 日志回传 | 5% | 验证规则框架可用性，不干扰核心推理 |
| Phase 2 | + 特征工程（Top-10 特征） | 20% | 覆盖高频特征质量，发现特征缺失/越界问题 |
| Phase 3 | + 模型推理（输入/输出校验） | 50% | 检测推理阶段数值异常，评估规则误报率 |
| Phase 4 | + 结果后处理 + 全量特征 | 100% | 全链路规则生效，进入常态化监控 |
注意：灰度部署期间，所有数据质量规则默认只记录告警日志，不阻断推理流程。只有在规则经过充分验证（误报率 < 1%、准确率 > 99%）后，才可考虑开启阻断模式。阻断模式应设置熔断机制，防止规则 bug 导致大规模服务中断。
3.5 数据流全景与质量规则的映射关系
下图展示了数据流各阶段与对应数据质量规则之间的映射关系，帮助理解规则应该部署在哪些位置：
3.6 数据流全景的关键设计原则
- 无侵入原则：数据质量检查点不应修改原始数据流，只做观测和记录。灰度部署期间，规则只读不写，避免副作用。
- 可观测原则：每个阶段的质量检查结果需要输出到独立的监控指标（如 Prometheus Counter/Gauge），便于实时查看规则命中率和误报率。
- 渐进原则：规则从低风险阶段（请求入站、日志回传）开始灰度，逐步向高风险阶段（特征工程、模型推理）推进。
- 熔断原则：当规则误报率超过阈值（如 5%）或规则执行耗时超过预期（如 10ms），自动熔断该规则，避免影响主链路性能。