机器学习模型上线后的系统性风险与生产治理实战指南

1. 为什么“模型上线”不是终点，而是系统性风险的起点？

你有没有经历过这样的场景：模型在Jupyter Notebook里跑得飞起，AUC 0.92，F1 0.87，业务方拍板签字，庆功会都快安排上了——结果上线第三天，风控团队深夜打电话说“昨天拒掉的57个高风险交易，今天全被人工复核放行了”，IT告警平台弹出37条“/predict 接口超时 > 2s”，而数据平台日志里赫然写着：“feature_user_last_7d_avg_spend: value not found for user_id=U-8842193”。那一刻你突然意识到：模型没坏，但整个决策链路已经无声崩塌。

这不是个别案例，而是我过去八年在三家持牌金融机构、两家大型电商中反复验证的铁律： 92%以上的ML生产事故，根源不在模型本身，而在它与真实世界交互的边界上 。Raj Kumar在Towards AI这篇Part 4里点破的核心，并非技术细节的堆砌，而是一次认知范式的切换——当模型离开Notebook，它就不再是数学对象，而成了分布式系统里的一个有状态服务组件，必须接受工程化、治理化、问责化的三重拷问。

关键词“Towards AI - Medium”背后，是大量一线从业者用血泪换来的共识：真正的ML成熟度，不看论文引用数，而看你的模型能否在支付网关每秒3万笔请求下，把欺诈识别延迟稳定压在85ms以内；不看离线A/B测试的提升率，而看当监管要求追溯某笔贷款决策依据时，你能否在15秒内输出带时间戳、特征快照、阈值依据、人工覆盖记录的完整审计包。这正是本文要拆解的硬核现场——没有PPT式方法论，只有我在某银行反洗钱模型上线首月遭遇的7次熔断、3次误拒、2次数据漂移漏报后，亲手写进SOP的14条生产守则。

你不需要是架构师才能读懂这些内容。如果你正在把第一个模型从实验室推向业务线，或者正为某个“明明指标很好却总被业务质疑”的模型焦头烂额，又或者刚接手一个“祖传模型”却连它的特征来源都查不到——那么接下来的内容，就是你真正需要的生存指南。它不教你如何调参，但会告诉你为什么某个参数在生产环境里必须锁定为常量；它不讲算法原理，但会解释清楚为什么“特征缺失率>0.3%”这个阈值，是我们在某次客户投诉风暴后用27小时回溯分析定下的生死线。

2. 部署与集成：当模型撞上真实世界的“接口契约”

2.1 集成失败的真相：90%的问题源于对“系统假设”的盲目信任

在实验室里，我们习惯把特征工程封装成一个干净的Python函数： def get_features(user_id): return {‘age’: 28, ‘income’: 120000, …} 。但在生产环境中，这个函数背后是6个微服务、3个数据库分片、2个消息队列和1个缓存集群的协同作战。我曾参与过一个信贷评分模型的上线，开发阶段所有特征都来自离线数仓T+1同步，而上线当天才发现：核心特征 user_latest_transaction_amount 实际由实时流处理引擎计算，存在平均12秒延迟，峰值可达47秒。更致命的是，该字段在流处理异常时会返回NULL，而模型代码里没有任何空值处理逻辑——结果就是，当流处理因网络抖动中断17分钟，模型批量返回NaN，下游决策引擎直接触发熔断。

提示：永远不要相信任何特征的“可用性承诺”。在集成前，必须完成三项实测：① 特征端到端延迟分布（P50/P90/P99）；② 异常场景下的降级行为（超时/空值/格式错误）；③ 与业务SLA的匹配度（例如：若业务要求决策在用户提交申请后500ms内返回，则特征获取必须控制在150ms内，留足模型推理与网络传输余量）。

我们后来建立的《特征契约检查表》包含12项必检条目，其中第7条强制要求：“提供特征在连续72小时压力测试下的P99延迟曲线图，并标注与业务SLA的偏差值”。这条规则让后续三个模型的集成周期平均缩短了40%，因为上游数据团队开始主动优化他们的ETL链路。

2.2 模型服务化的三种死亡陷阱与我的避坑方案

模型部署绝非简单地把 .pkl 文件扔进Flask API。根据我在支付、信贷、营销三大场景的踩坑记录，以下是三种最高发的“服务化猝死”模式：

陷阱一：同步阻塞式API的雪崩效应
某营销推荐模型采用Flask + Gunicorn部署，配置了4个工作进程。上线后发现：当并发请求超过200QPS时，平均延迟从80ms飙升至2.3秒，错误率突破15%。根因是Gunicorn工作进程被长耗时的特征计算阻塞（单次特征提取平均耗时320ms），导致请求队列积压。解决方案不是加机器，而是重构为异步流水线：

• 前置Nginx层启用 proxy_buffering off ，避免缓冲放大延迟
• 特征获取层改用Celery + Redis，设置 soft_time_limit=300 强制超时
• 模型推理层使用Triton Inference Server，GPU显存利用率从35%提升至89%
  改造后，同等硬件下支撑QPS提升至1800，P99延迟稳定在110ms。

陷阱二：无状态服务的“状态幻觉”
一个反欺诈模型依赖 user_session_risk_score 特征，该分数由前端埋点实时计算并写入Redis。开发时假设“Redis总是可用”，未设计降级策略。某次Redis集群主从切换耗时23秒，期间所有请求因 redis.ConnectionError 失败。我们的补救方案是引入双写机制：关键特征同时写入Redis和本地内存缓存（LRU淘汰），并设置 stale_while_revalidate=300 ——即当Redis不可用时，允许返回最多5分钟前的缓存值，同时后台异步刷新。这个5分钟窗口，足够覆盖99.7%的基础设施故障。

陷阱三：版本混用引发的“幽灵bug”
最隐蔽的灾难发生在某次灰度发布：v2.1模型已上线，但特征工程代码仍运行v1.9版本，导致 user_age_group 编码规则变更（原[0-18)=0, [18-35)=1，新规则[0-25)=0, [25-40)=1）。线上监控未报警，因为AUC等指标变化微小，但业务侧发现25-35岁客群的通过率异常下降12%。我们最终建立的“版本锁”机制是：在模型服务启动时，强制校验 feature_engineering_version 与 model_version 的哈希签名，不匹配则拒绝启动，并向值班工程师发送企业微信告警。这套机制上线后，版本相关事故归零。

2.3 灰度发布的黄金法则：从“流量切分”到“风险切分”

很多团队把灰度等同于“5%流量给新模型”，这是危险的简化。真正的灰度，必须基于风险维度而非随机流量。我们在某银行信用卡反欺诈模型上线时，制定了四层灰度策略：

关键创新在于Stage 1的“低风险客群”定义——我们不是按用户ID哈希，而是用旧模型的 risk_score 分位数切分，确保首批暴露用户恰好是系统最不容易出错的群体。这种“风险感知灰度”让我们在Stage 1就捕获到一个致命问题：新模型对“学生身份”用户的评分存在系统性低估，原因是训练数据中学生样本不足且标签噪声高。若按随机灰度，这个问题可能在全量后才爆发。

3. 性能、延迟与可扩展性：在毫秒级战场上构建确定性

3.1 延迟预算的残酷现实：为什么“平均延迟”是最大的误导

在金融场景中，谈论“平均延迟”如同讨论“平均体温”来诊断疾病。我亲历过一个典型案例：某实时反欺诈API的监控显示平均延迟为65ms，P90为92ms，完全符合SLA。但业务方投诉不断——原来他们关注的是“用户从点击支付到看到结果页”的端到端体验，而这个流程中，模型调用只是17个环节之一。当我们深入追踪单条请求链路时，发现：

• P50请求：特征获取28ms + 模型推理12ms + 结果组装5ms = 45ms
• P95请求：特征获取187ms（因跨机房数据库查询） + 模型推理15ms + 结果组装8ms = 210ms
• P99请求：特征获取423ms（因缓存穿透） + 模型推理18ms + 结果组装12ms = 453ms

问题根源在于：特征获取层的P99延迟高达423ms，而模型推理层本身非常稳定（P99仅18ms）。这揭示了一个反直觉事实： 在生产ML系统中，特征工程的性能瓶颈通常比模型推理严重5-10倍 。因此，我们的性能优化重心必须前移——不是去折腾TensorRT加速模型，而是重构特征获取链路。

我们最终的解决方案是“三级特征缓存体系”：

1. L1（本地内存） ：高频静态特征（如用户基础属性），TTL=24h，命中率92%
2. L2（Redis集群） ：中频动态特征（如近1小时交易频次），TTL=300s，命中率87%
3. L3（降级兜底） ：当L1/L2均未命中时，启用预计算的“特征快照”（每小时全量生成一次），保证P99延迟≤150ms

这套体系上线后，整体P99延迟从453ms降至138ms，且不再出现尖峰抖动。

3.2 可扩展性的本质：不是“扛住多少QPS”，而是“如何优雅退化”

可扩展性常被误解为水平扩容能力，但在ML生产中，其核心是 确定性退化能力 。2023年某次大促期间，我们遭遇了典型的“黑天鹅”场景：因第三方征信接口故障， credit_bureau_score 特征持续不可用。按原设计，该特征缺失会导致模型拒绝服务。但业务要求“宁可降低精度，也不能中断服务”。

我们为此设计的退化协议包含三个层级：

• Level 1（自动填充） ：当特征缺失时，用该用户历史均值填充（需提前计算并缓存）
• Level 2（规则替代） ：若历史均值不可用，则启用轻量规则引擎（如： if income>50k and employment_years>3 then score=720 else score=650 ）
• Level 3（人工接管） ：当规则引擎也失效时，自动将请求路由至人工审核队列，并标记 priority=high

关键设计点在于：每个层级都有明确的触发条件（如Level 1触发阈值为 missing_rate<5% ），且退化过程全程可审计。这套机制让我们在征信接口中断19小时期间，系统保持100%可用，坏账率仅上升0.3个百分点（低于业务容忍阈值0.5%）。

注意：退化策略必须在模型训练阶段就纳入考量。我们在训练时专门构造了“特征缺失模拟数据集”，强制模型学习在部分特征不可用时的鲁棒决策模式。这使得Level 1填充后的模型性能衰减控制在2.1%以内，远优于直接丢弃缺失样本的方案（衰减达17.4%）。

3.3 压力测试的实战方法论：超越“Hello World”式负载

标准的压力测试工具（如Locust、JMeter）对ML服务往往失效，因为它们无法模拟真实的业务语义。我们开发了一套“语义化压测框架”，其核心是三类真实流量建模：

1. 峰值脉冲流量
模拟大促开场瞬间的流量洪峰。我们采集了历史大促首分钟的真实请求序列，包括：

• 用户ID分布（85%为新客，15%为老客）
• 请求参数组合（如 amount 集中在[0.01, 9999.99]区间，但99%请求落在[1.00, 199.00]）
• 时间间隔（遵循泊松分布，λ=1200，即平均每秒1200请求）

2. 异常混合流量
注入20%的“脏数据”请求，包括：

• 特征值越界（如 age=-5 , income=999999999 ）
• 必填字段缺失（ user_id 为空）
• 格式错误（ timestamp 为非ISO8601字符串）

3. 依赖故障流量
在压测中动态注入故障：

• 每1000次请求，随机使1个特征服务超时（延迟设为5s）
• 每5000次请求，随机使1个特征服务返回错误码503

这套框架让我们在正式上线前，就发现了两个致命缺陷：

• 模型服务在收到 user_id=null 时会抛出未捕获异常，导致工作进程崩溃
• 当 credit_bureau_score 超时时，降级逻辑未清除Redis中的临时键，造成内存泄漏

修复后，系统在真实大促中承受住了峰值12,800 QPS的冲击，P99延迟稳定在142ms。

4. 监控与漂移检测：在数据衰老过程中抢夺预警时间窗

4.1 超越准确率：构建七维生产健康仪表盘

在实验室，我们盯着 accuracy 、 precision 、 recall ；在生产中，这些指标往往滞后数小时甚至数天。真正的实时健康信号来自以下七个维度，我们称之为“ML生命体征”：

关键实践：我们强制要求所有监控指标必须具备“可操作性”。例如，当 KS_statistic(feature_age) >0.15时，监控系统不仅报警，还会自动生成诊断报告：

• 对比训练集与生产集的年龄分布直方图
• 列出年龄分段中KS贡献最大的三个区间（如[18-22), [35-44), [55-64)）
• 关联该时段的业务事件（如“校园贷专项活动上线”、“银发族理财推广”）
• 给出建议动作：“建议在[18-22)区间增加样本权重，或启用年龄分段校准”

这套机制将平均问题定位时间从8.2小时缩短至23分钟。

4.2 漂移检测的落地陷阱：为什么PSI/KS经常失灵？

PSI（Population Stability Index）和KS检验是教科书标配，但在真实场景中，我们发现它们有三大硬伤：

伤一：对稀疏特征失效
user_device_type 特征有127种取值，其中112种出现频率<0.01%。PSI计算时，这些长尾值被合并为“Other”，导致PSI值始终<0.1，但实际业务中， iOS_17.4 设备的欺诈率是 Android_12 的3.2倍。我们的解决方案是：对高基数分类特征，改用 JS散度（Jensen-Shannon Divergence） ，并保留所有原始取值（不合并），同时设置 min_frequency=0.001 过滤噪声。

伤二：对时序依赖特征不敏感
user_7d_transaction_count 是一个强时序特征，但PSI只看分布形状，忽略时间序列的自相关性。我们曾遇到：该特征均值稳定在4.2，但ACF（自相关函数）显示滞后1阶相关性从0.82骤降至0.15，意味着用户交易行为从“惯性驱动”变为“事件驱动”。这预示着模型需要从ARIMA式建模转向事件驱动建模。为此，我们增加了 时序稳定性指标 ： acf_lag1_change , diff_std_ratio （一阶差分标准差/原始标准差）。

伤三：对概念漂移无能为力
当欺诈模式从“盗刷银行卡”转向“薅羊毛虚拟商品”， transaction_amount 分布可能完全不变，但 transaction_merchant_category 与 user_account_age 的联合分布已剧变。这时需要 多变量漂移检测 。我们采用 Maximum Mean Discrepancy (MMD) 算法，对特征组合进行核嵌入比较。虽然计算开销大，但我们只在每日凌晨对关键特征组合（如 [amount, merchant_cat, time_of_day] ）执行，结果写入特征健康报告。

实操心得：不要迷信单一漂移指标。我们建立的“漂移响应矩阵”规定：当任意1个指标超阈值，触发Level 1检查（人工复核）；当2个指标同时超阈值，触发Level 2（自动重训候选）；当3个及以上指标超阈值，触发Level 3（紧急模型冻结，启用备用规则）。

4.3 监控告警的“静默期”设计：避免狼来了效应

在早期，我们的监控系统每天发送200+条告警，运维团队很快进入“告警疲劳”，真正重要的信号被淹没。我们痛定思痛，引入了“三静默”原则：

静默一：基线静默
所有指标首次上线时，不立即启用告警，而是进入7天基线学习期。系统自动计算该指标的P10-P90区间、标准差、趋势斜率，作为动态基线。例如， approval_rate 在工作日基线为68.2%±1.3%，周末为72.5%±0.8%，系统会自动识别并应用不同基线。

静默二：关联静默
当 feature_null_rate 告警时，自动抑制 model_accuracy 告警（因为后者必然受影响），转而激活 data_pipeline_health 检查流。我们用DAG（有向无环图）定义了23个指标间的因果关系，确保告警指向根因而非表象。

静默三：业务静默
在重大营销活动期间（如双11），系统自动加载“活动白名单”，对 manual_review_rate 等指标放宽阈值（如从5%→15%），并关闭与活动强相关的漂移告警（如 new_user_ratio ）。白名单由业务方提前3天在配置中心提交，经风控总监审批后生效。

这套机制使有效告警率从12%提升至89%，平均MTTR（平均修复时间）缩短63%。

5. 模型验证与压力测试：在可控混沌中暴露系统脆弱性

5.1 企业级验证的四大支柱：超越离线指标的可信度建设

在持牌金融机构，模型验证不是技术动作，而是合规刚需。我们构建的验证体系包含四个不可分割的支柱：

支柱一：对抗鲁棒性验证
不是测试“模型在干净数据上的表现”，而是测试“模型在恶意扰动下的表现”。我们采用三类攻击：

• 数值扰动 ：对 income 字段添加±5%噪声，观察 risk_score 变化是否<±3%
• 逻辑扰动 ：将 user_age=25 改为 user_age=250 ，验证模型是否拒绝异常值或优雅降级
• 语义扰动 ：在文本特征中插入对抗样本（如将“信用良好”替换为“信用良*好”），测试NLP模型的抗干扰能力

关键成果：在某次验证中，我们发现模型对 age 的微小扰动极其敏感（0.1%变化导致评分波动12%），这暴露了特征缩放环节的bug——训练时用Min-Max Scaling，生产时误用了Standard Scaling。

支柱二：公平性验证
使用 AIF360 工具包，对 gender 、 ethnicity 、 age_group 三个敏感维度计算：

• statistical_parity_difference （统计均等差异）
• equal_opportunity_difference （机会均等差异）
• disparate_impact_ratio （差异影响比率）

阈值设定： |SPD| < 0.1 , |EOD| < 0.05 , DIR ∈ [0.8, 1.25] 。当某次验证发现 DIR=0.62 （对某少数民族群体过度严苛），我们不是简单调阈值，而是引入 公平性约束的再训练 ：在损失函数中加入 λ * |DIR - 1.0| 惩罚项，λ通过网格搜索确定。

支柱三：可解释性验证
要求SHAP值必须满足：

• 单样本解释中，Top 3特征贡献度之和 ≥ 70%
• 同类用户（如 age=25-30, income=50k-80k ）的Top 3特征高度一致（Jaccard相似度 > 0.8）
• SHAP值与业务直觉吻合（如 high_income 应为正向贡献， high_debt_ratio 应为负向贡献）

我们曾因 high_income 在部分样本中呈现负向贡献，深度排查发现：该特征在训练数据中存在“收入虚高”标签噪声（中介伪造流水），从而修正了数据清洗规则。

支柱四：业务一致性验证
这是最容易被忽视的支柱。我们要求：模型决策必须与业务专家的“隐性知识”一致。做法是：

• 每月抽取100个典型case（含正例/负例/边界case）
• 由3位资深风控专家独立打分（1-5分，5分为完全认同）
• 计算专家间Krippendorff's Alpha系数，要求 > 0.7
• 对分歧case组织研讨会，形成“业务规则-模型逻辑”映射表

这项工作让我们在某次模型迭代中，及时发现新模型对“小微企业主”群体的评分逻辑与专家经验相悖，避免了潜在的监管问询。

5.2 压力测试的“混沌工程”实践：主动制造故障以验证韧性

我们借鉴Netflix Chaos Monkey理念，开发了ML专属的“Chaos Model”框架，其核心是三类可控故障注入：

故障类型一：数据污染

• 时间旅行 ：将生产数据的时间戳随机偏移±72小时，测试模型对时间泄漏的免疫力
• 标签污染 ：在训练数据中按5%比例翻转标签（正例变负例），验证模型鲁棒性
• 特征污染 ：对20%的特征值注入高斯噪声（σ=0.1），观察性能衰减曲线

故障类型二：服务扰动

• 延迟注入 ：对特征服务随机增加200-2000ms延迟，测试降级逻辑有效性
• 错误注入 ：对1%的请求返回HTTP 503，验证熔断器配置
• 容量限制 ：将Redis内存限制为512MB，触发LRU淘汰，观察特征缓存命中率变化

故障类型三：环境变异

• 硬件降级 ：在测试环境将CPU核数限制为2核，内存限制为4GB，模拟低端服务器
• 网络分区 ：切断模型服务与特征服务间的网络，测试本地缓存策略
• 依赖版本漂移 ：将Scikit-learn从1.2.2降级至1.0.2，验证模型兼容性

每次混沌实验后，我们生成《韧性评估报告》，包含：

• 故障注入成功率（应≥95%）
• 系统恢复时间（MTTR）
• 业务指标影响（如 approval_rate 下降幅度）
• 自动化修复动作执行情况（如是否成功触发降级）

这套机制让我们在真实故障发生前，就验证了所有应急预案的有效性。例如，在一次混沌实验中，我们发现当Redis宕机时，本地缓存未能及时更新，导致模型使用了过期特征。这促使我们增加了“缓存新鲜度心跳”机制：每5分钟向Redis写入时间戳，服务启动时校验该时间戳是否<5分钟。

5.3 验证结果的“可审计性”设计：让每一次模型上线都有迹可循

在监管审查中，“我们验证过了”毫无说服力，必须提供可验证的证据链。我们的验证报告包含五个强制模块：

模块一：验证范围声明
明确列出本次验证覆盖的场景（如“仅覆盖实时反欺诈场景，不包含离线批处理”）、数据周期（如“2024-Q3生产数据”）、对比基线（如“对比v2.0模型”）。

模块二：验证方法论
详细说明每个测试的参数：

• 对抗测试：使用FGSM攻击，ε=0.05，迭代次数=10
• 公平性测试：AIF360的 Reweighing 预处理算法
• 压力测试：Locust脚本路径、并发用户数、持续时间

模块三：原始数据快照
提供验证所用数据的SHA256哈希值、样本量、关键统计量（如 mean , std , min , max ），确保可复现。

模块四：结果可视化
所有指标必须以图表形式呈现，且图表包含：

• X轴时间戳（精确到秒）
• Y轴数值及单位
• 阈值线（红色虚线）
• 置信区间（95%）

模块五：结论与行动项
明确写出：

• 是否通过验证（Yes/No）
• 未通过项的具体描述（如“对抗鲁棒性未达标：ε=0.05时准确率下降42% > 15%阈值”）
• 行动项（Action Item）：编号、负责人、截止日期、验收标准

这份报告不仅是内部交付物，更是向监管报送的核心材料。某次监管现场检查中，审查员随机抽取了报告中的一个测试，要求我们当场复现。由于所有参数和数据哈希都公开，我们15分钟内完成了复现，获得高度评价。

6. 治理、审计与合规：让ML系统在规则森林中稳健生长

6.1 治理不是枷锁，而是让复杂系统可演进的基础设施

很多工程师把治理等同于“填表审批”，这是对治理本质的误解。在我经历的多个项目中，治理真正的价值体现在三个关键时刻：

时刻一：模型下线决策
某次，我们发现一个运行了3年的营销模型，其 click_through_rate 预测准确率从82%缓慢降至61%，但业务方仍坚持使用，因为“历史效果好”。治理流程强制要求：当模型核心指标连续30天低于阈值（我们设为75%），必须启动“模型健康评估”。评估组（含数据科学家、业务方、风控、合规）共同决策：是优化、重训还是下线。最终，我们用新模型替代了它，首月ROI提升27%。没有治理流程，这个“僵尸模型”可能继续运行数年。

时刻二：数据源变更审批
上游数据团队计划将 user_transaction_log 表的分区策略从 dt 改为 ds ，看似微小变更。但治理流程要求：必须提交《数据源变更影响分析》，包括：

• 对所有依赖该表的模型的影响（我们有12个模型）
• 特征计算逻辑是否需修改（8个模型需调整SQL）
• 回溯重训所需资源（预计占用GPU 48小时）
• 业务影响窗口（建议在周末维护窗口执行）

这个流程让我们提前两周发现了变更对某实时模型的破坏性影响，避免了生产事故。

时刻三：人工覆盖审计
当业务人员手动覆盖模型决策（如“强制通过某高风险申请”），治理系统自动记录：

• 覆盖人、时间、原因代码（如 REASON_COMPLIANCE ）
• 覆盖时的模型输出（ score=0.87 , threshold=0.75 ）
• 覆盖后的业务结果（ application_status=approved ）
• 72小时内自动触发回访：该申请最终是否产生坏账？

这些数据汇聚成《人工覆盖分析报告》，揭示出模型盲区。例如，我们发现 REASON_FRAUD_SUSPICION 覆盖中，83%的case最终被证实为真实欺诈，这直接推动了模型对新型欺诈模式的学习。

提示：治理流程必须“轻量级”。我们规定：所有审批流必须在4小时内响应，超时自动升级。审批表单字段不超过12个，且70%字段支持自动填充（如从Git提交信息中提取 model_version ）。

6.2 审计就绪的四大设计原则：让每一次检查都成为展示机会

在金融行业，审计不是“应付检查”，而是证明系统可靠性的机会。我们遵循四大设计原则：

原则一：全链路可追溯
从原始数据到最终决策，每个环节必须有唯一ID贯穿：

• 数据源ID（如 DS_CREDIT_BUREAU_V2_2024 ）
• 特征版本ID（如 FV_USER_RISK_SCORE_3.1 ）
• 模型版本ID（如 MV_FRAUD_DETECTOR_2.4.7 ）
• 决策实例ID（如 DEC_20240521_142305_U8842193 ）

当审计员询问“某笔交易为何被拒”，我们能在30秒内输出：

• 该笔交易的全部输入特征值及来源时间戳
• 模型打分过程（含各层神经元激活值）
• 决策阈值及业务规则（如 score>0.85 → reject ）
• 人工覆盖记录（如有）

原则二：变更留痕
所有变更（代码、配置、数据）必须通过Git管理，并关联Jira工单。我们禁用任何直接生产环境修改。某次，一位工程师试图绕过流程直接修改Redis配置，被我们的 git-hook 拦截并告警——该hook检查所有 kubectl exec 命令，若未关联工单号则拒绝执行。

原则三：证据自动化
审计证据不是手工整理，而是由系统自动生成：

• 每日生成《模型健康日报》：含漂移指标、性能指标、人工覆盖统计
• 每周生成《特征质量周报》：含各特征的null率、outlier率、分布变化