AI校验系统架构:五层模型怎么落地?

说实话,我第一次接触AI药物批次校验的时候,脑子里也是一团乱麻。数据怎么来?模型怎么跑?结果怎么给审计看?这些问题如果不从架构层面想清楚,后面全是坑。

我2019年参与第一个AI药品检验项目的时候,团队就犯过这个错 — 代码先写起来了,架构回头再补。结果呢?数据采集接口换了三版,模型部署路径改了五次,合规文档直接重写。从那以后,我养成了一个习惯:不管项目多急,先把架构层画清楚。

今天我就把这套五层架构掰开讲给你听。

架构总览:一个串起来的管道

AI校验系统不是单点工具,它是一整条链路。我习惯把它分成五层:

  • 数据采集层 — 从设备和系统里把原始数据捞出来
  • 处理层 — 把脏数据洗干净,变成模型能吃的特征
  • 模型层 — 运行校验算法,给出推荐结论
  • 应用层 — 把模型结果包装成业务人员能用的功能
  • 合规层 — 保证每一步都有据可查,经得起审计

你想想看,这就像一条生产线。原料进来,经过五道工序,最后出来的是合格品。哪一道出问题,整批都得废。

AI 批次校验系统五层架构 合规层 应用层 模型层 处理层 数据采集层 数据流向 采集 → 处理 → 模型 → 应用 合规贯穿全局 每一层都有 日志和审计接口

数据采集层:源头决定质量

这一层就干一件事 — 把设备、LIMS系统、ERP系统里的原始数据搬到校验系统里来。听起来简单?实际操作起来全是细节。

我在项目中遇到过一种情况:某台液相色谱仪输出的CSV文件居然不带时间戳。你想想看,批次校验里时间戳是命根子,没有它你根本没法追溯。后来我强制要求所有数据源必须提供 采集时间、设备ID、批次号 三个字段,缺一不可。

采集方式一般有三种:

方式 适用场景 注意事项
文件监听 设备输出CSV/XML文件 要处理文件锁和重复读取
数据库直连 对接LIMS/ERP 注意查询频率,别压垮生产库
API调用 云平台或第三方接口 做好幂等和重试机制
我的小习惯: 数据采集一定要加一个「采样策略」配置。比如每30秒拉一次API,或者每次文件创建事件触发采集。不要写死,因为不同数据源的实时性要求差太多了。

处理层:原始数据到可用特征

原始数据大多是脏的。空值、乱码、格式不统一、单位错误 — 我见过一张表里同时出现 "mg/mL" 和 "g/L",还没做备注。处理层的任务就是把这些乱七八糟的东西变成标准化的特征向量。

我的做法是三步走:

  • 清洗 — 去重、补缺失值、剔除异常值。异常值怎么判?业内常用3σ规则或者IQR方法
  • 转换 — 单位统一、时间戳格式化、文本归一化。我习惯把所有时间统一转成UTC
  • 特征工程 — 从原始字段里衍生出业务特征。比如从「检测时间」和「批号」算出「批次日产量」
我曾经踩过的坑: 在清洗阶段直接用平均值填充缺失值。药企数据不一样 — 有些缺失值是设备故障导致的,用平均值填充会把故障信号抹掉。正确的做法是先判断缺失原因,再选填充策略。

处理层的输出是一张特征宽表,每一行对应一次检测,每一列是一个标准化特征。模型层直接拿这张表干活。

模型层:推荐与决策

模型层运行的是已经训练好的校验模型。我这里说的「模型」不一定是深度学习 — 随机森林、XGBoost、甚至简单的规则引擎都有可能,关键看业务场景。

模型层要做的事情包括:

  • 加载模型文件(ONNX、PMML 或者直接用 pickle 存)
  • 对输入特征做推理
  • 输出校验结果 — 通过/不通过 + 置信度
  • 如果置信度低于阈值,标记为「人工复核」

我建议模型层的输入输出都用 JSON 格式,方便上下游对接。举个例子:

{
  "batch_id": "BATCH-202504-001",
  "features": {
    "assay_pct": 98.7,
    "impurity_ppm": 12.3,
    "dissolution_rate": 85.2
  },
  "model_output": {
    "prediction": "PASS",
    "confidence": 0.94,
    "threshold": 0.85
  }
}

应用层:连接算法与业务

模型层输出的是技术结果,应用层要把它翻译成业务人员能理解的东西。说白了,就是做界面、做报警、做报告。

我在项目中习惯把应用层拆成三个模块:

  • 结果看板 — 展示批次校验状态、合格率趋势、异常批次清单
  • 复核工作台 — 给质检人员用的,展示模型结论和原始数据,支持人工修改
  • 报表生成 — 按批次或按时间段生成PDF/Excel报告,格式要符合GMP要求

这里有个细节:应用层不能直接改模型层的输出。如果质检员人工复核后判定不一样,应用层要开一条「复核记录」,而不是覆盖原结果。合规层就靠这个。

合规层:让审计安心

这一层是AI校验系统区别于普通ML系统的地方。没有合规层,模型再准也没人敢用。

合规层做的事情很「重」:

  • 全链路审计日志 — 谁在什么时间改了哪个批次的数据?模型版本是多少?全得记下来
  • 模型版本管理 — 每个批次用哪个模型版本校验的,必须能追溯。我建议用Git LFS存模型文件,每次部署打tag
  • 电子签名 — 关键操作(比如人工复核改结论)必须走电子签名流程,符合21 CFR Part 11
  • 数据完整性检查 — 定期算校验和,保证数据在存储和传输中没有被篡改

合规的底线: 一条审计日志都不能丢。我见过一个团队把日志写入同一个数据库表,结果表锁了,全部日志写不进去。之后我改了架构 — 日志走独立的消息队列,先落盘再入库,保证不丢一条。

合规层不是后加的装饰,它必须贯穿整个架构。我习惯在每一层的接口设计时就留好 trace_id 和 operator 字段,后面补的话代价太大。

小总结:这五层怎么跑起来?

一张图讲清楚整个流程:

  1. 数据从采集层进来,带上批次号和采集元数据
  2. 处理层清洗转换,生成特征宽表,同时写一条「处理完成」审计日志
  3. 模型层读取特征,跑推理,输出结果,再写一条「推理完成」日志
  4. 应用层展示结果,如果人工复核了,再写一条「复核记录」
  5. 合规层随时可以查任意批次的完整链路 — 从原始数据到最终结论,一个不漏

我的建议: 第一次搭架构的时候别贪多。先把采集层 + 处理层 + 模型层跑通,再慢慢加应用层和合规层。但合规的日志接口设计,从第一天就要放进去 — 不然后面改不动。