1. 为什么“模型上线”不是终点而是系统性风险的起点你有没有经历过这样的场景模型在Jupyter Notebook里跑得飞起AUC 0.92F1 0.87业务方拍板签字庆功宴都订好了结果上线第三天风控团队深夜打电话说“昨天拒掉的500个高分客户里有37个当天就完成了高风险转账”运维告警平台开始刷屏日志里全是feature_timeout和fallback_triggered再查监控特征服务P99延迟从12ms飙到480ms而模型API的错误率从0.03%跳到了11.6%——但模型本身的预测逻辑一行代码都没动过。这就是Part 4要直面的真相机器学习项目真正的死亡之谷不在数据清洗不在超参调优而在模型离开笔记本、第一次被真实流量击中的那一刻。这不是一个“技术实现问题”而是一个“系统生存问题”。它不考验你对XGBoost损失函数的理解深度而是拷问你当支付网关每秒涌来8000笔请求、其中12%携带异常设备指纹、而你的特征缓存刚好因网络抖动丢失了3秒时整个决策链路会不会像多米诺骨牌一样坍塌你的fallback机制是优雅降级还是直接把用户推给人工审核队列导致客诉量翻倍我亲身参与过三家银行的反欺诈模型落地最深的教训是所有在离线环境中被忽略的“小假设”都会在生产环境里变成压垮系统的最后一根稻草。比如我们曾默认“用户设备ID字段永远存在且格式合规”结果某安卓厂商新系统升级后该字段在特定机型上返回空字符串——这个在训练集里从未出现过的case让模型输入张量维度错乱触发了未捕获的异常整个服务实例直接OOM崩溃。而修复方案不是重写模型而是加了一行防御性校验一个带熔断的降级开关。所以当你看到“From Notebook to Production”这个标题时请立刻把脑子里的“部署打包成Docker镜像扔到K8s”的画面擦掉。真正的生产就绪Production-Ready意味着你必须用系统工程师的思维去解剖每一个环节数据管道是否具备幂等性特征计算是否满足实时性SLA模型服务是否支持灰度发布与秒级回滚决策日志能否支撑审计追溯甚至当模型输出一个“拒绝”结果时业务系统是否有明确的申诉入口和人工复核SOP这正是Raj Kumar在Towards AI系列中反复强调的核心——ML在生产中失败90%以上的原因与算法本身无关。它失败于数据漂移未被感知失败于集成接口契约失效失败于缺乏压力下的优雅退化能力失败于责任边界模糊导致故障响应迟滞。因此本篇不会教你如何调参而是带你亲手搭建一套能扛住真实世界冲击的ML系统骨架。接下来的内容全部来自我在金融、电商、物流领域落地23个高可用ML服务的真实经验每一个建议背后都对应着至少一次凌晨三点的故障复盘会议。2. 部署与集成把模型嵌进业务血脉而不是插在API网关上2.1 集成失败才是常态模型失败只是表象很多团队把“模型上线”理解为一个单点动作训练完模型→导出为ONNX/Triton格式→部署到推理服务→配置API路由→通知前端调用。这套流程在Demo阶段完美无瑕但在真实企业级系统中它脆弱得像一张薄纸。原因很简单企业IT架构不是为ML设计的而是为交易、结算、报表这些确定性任务构建的。ML模型作为一个“概率性黑盒”天然与传统系统的强一致性、事务完整性、可预测延迟格格不入。我见过最典型的集成灾难发生在一家股份制银行的信贷审批系统。他们的新模型需要接入核心信贷引擎该引擎要求所有外部服务调用必须在200ms内返回超时则自动走兜底规则即人工审核。模型团队自信满满地承诺“P95延迟150ms”结果上线首日当市场突发流动性紧张大量客户集中申请贷款特征服务因依赖的Redis集群负载过高P99延迟飙升至320ms。信贷引擎瞬间将数千笔请求导向人工队列客服中心电话被打爆管理层紧急叫停上线。事后复盘发现问题根源根本不在模型推理层——模型服务本身P95只有89ms瓶颈完全卡在上游特征计算环节。而特征服务团队和模型团队此前从未共享过SLA文档更没做过联合压测。因此“部署”在生产语境下本质是一场跨团队的契约协商与系统对齐。你需要回答的不是“模型能不能跑”而是数据契约Data Contract特征服务保证在T0.5秒内返回哪些字段字段类型、空值率、取值范围的SLA是多少如果某字段延迟是否提供历史均值/上期值作为替代接口契约API Contract模型服务的QPS容量、P99延迟、错误码定义、重试策略、熔断阈值分别是什么下游系统如何识别“临时不可用”与“永久性故障”行为契约Behavior Contract当特征缺失率超过15%时模型是否自动切换至简化版逻辑简化逻辑的准确率下限是多少决策结果是否强制打标“降级模式”供后续分析治理契约Governance Contract模型版本变更需提前多少小时通知集成方灰度发布比例如何控制回滚操作的RTO恢复时间目标和RPO恢复点目标分别是多少提示不要依赖口头约定或邮件确认。我坚持的做法是用OpenAPI 3.0规范编写一份《模型集成契约说明书》包含所有上述条款并由数据平台、模型团队、业务系统三方负责人电子签章。这份文档会成为后续所有故障追责与优化的唯一依据。2.2 构建韧性集成从“硬连接”到“软耦合”的四步实践面对复杂的企业系统强行让模型服务与业务系统“紧耦合”是自取灭亡。我的经验是必须通过四层抽象把集成关系从“硬连接”转化为“软耦合”第一步引入异步事件总线解耦实时性压力绝不允许业务系统如支付网关直接同步调用模型API。正确做法是业务系统将决策请求含必要上下文发布到Kafka/Pulsar主题模型服务作为消费者异步拉取、处理、写回结果主题。这样做的好处是业务系统完全不受模型服务延迟影响自身RT保持稳定模型服务可通过调整消费者并发数、批量大小平滑应对流量峰谷当模型服务宕机时消息堆积在Broker中故障恢复后可自动重放避免请求丢失便于实施影子流量Shadow Traffic将生产流量复制一份发往新模型对比结果差异零风险验证。我曾在某电商平台的实时推荐系统中应用此方案。原架构是APP端直接调用推荐API大促期间因模型服务GC停顿导致APP首页白屏率飙升。改造后APP只向Kafka发送用户行为事件推荐服务异步生成结果并推送到RedisAPP端从Redis读取。改造后APP首屏加载稳定性从92%提升至99.97%模型服务的P99延迟容忍度也从50ms放宽到500ms。第二步设计分级Fallback机制确保“最差情况”仍可控生产环境没有“永远在线”只有“优雅降级”。一个健壮的Fallback体系必须包含三级L1模型内部降级毫秒级当关键特征缺失时自动启用预置的简化特征集如仅用用户基础属性或返回缓存的历史预测分带时间衰减因子L2服务级降级秒级当模型服务整体不可用时调用轻量级规则引擎如Drools执行兜底策略如“新用户一律通过老用户按历史逾期率排序”L3业务级降级分钟级当规则引擎也失效时触发业务SOP如转人工审核、延长审批时限、或向用户推送“系统维护中”提示。关键细节每一级Fallback都必须记录明确的fallback_reason标签并将结果写入统一决策日志。这不仅是故障排查依据更是后续模型迭代的黄金数据——比如当L1降级触发率持续高于5%说明特征管道存在系统性缺陷必须优先修复。第三步实施契约式测试Contract Testing而非仅做端到端测试团队常犯的错误是只在上线前做一次全链路压测却忽略日常开发中的契约漂移。正确做法是为每个集成点如特征服务API、模型服务API编写独立的契约测试套件由CI流水线自动执行。例如针对特征服务测试用例应包括当传入user_idinvalid时是否返回HTTP 400及标准错误结构当timestamp参数超出72小时范围时是否返回空特征集而非报错对同一user_id连续请求10次返回的device_risk_score标准差是否0.001确保无随机性这些测试不验证业务逻辑只验证接口契约。一旦契约被破坏如新增必填字段、修改返回格式CI立即失败阻断发布。我们在某保险公司的核保模型项目中推行此法后集成相关故障率下降76%。第四步建立双向可观测性让“黑盒”变“玻璃盒”模型服务不能是孤岛。必须将其指标延迟、错误率、GPU利用率与上下游系统指标Kafka消费延迟、Redis命中率、业务系统TPS打通在同一个Grafana看板中关联展示。更重要的是要注入业务语义标签比如将模型服务的error_count指标按business_scenario如“贷款申请”、“信用卡提额”、risk_level高/中/低进行多维拆解。这样当错误率突增时你能立刻判断是“所有场景都出问题”模型服务故障还是“仅高风险场景出问题”可能触发了特定风控规则。注意可观测性不是堆砌监控图表而是构建“问题定位路径”。我要求每个关键指标旁必须标注“下一步排查动作”例如feature_cache_miss_rate 15%→ “检查Redis集群内存使用率 特征预热Job执行日志”。3. 性能、延迟与可扩展性在业务脉搏上跳舞的工程艺术3.1 延迟不是技术指标而是业务成本的具象化在生产环境中谈论“延迟”绝不能只盯着P95、P99这些数字。你必须把它翻译成业务语言每一次毫秒级的延迟增加对应着多少真实的金钱损失或用户体验恶化这是区分“实验型ML”和“生产型ML”的分水岭。以我参与的某头部券商的实时反洗钱AML系统为例。其核心模型需在用户发起转账的300ms内返回风险评分否则交易会被拦截。表面看这是个严苛的技术SLA但背后是赤裸裸的商业逻辑若拦截率过高客户流失若拦截率过低监管罚款。我们曾测算P99延迟每增加10ms会导致0.8%的客户放弃交易实测APP端埋点数据单日交易额减少约230万元按日均12万笔交易估算监管问询概率提升17%基于历史处罚案例统计。因此“优化延迟”不是工程师的自我挑战而是对业务底线的守护。而真正的优化始于对延迟构成的庖丁解牛式拆解。延迟的四大来源与实操对策延迟来源典型耗时参考根本原因我的实操对策网络传输延迟5~50ms跨机房调用、DNS解析慢、TLS握手- 强制同机房部署模型服务与特征服务在同一K8s集群- 使用gRPC替代REST启用HTTP/2多路复用- 预热TLS会话缓存禁用OCSP Stapling特征计算延迟10~200ms复杂SQL聚合、实时流处理窗口、外部API调用- 将高频特征预计算并缓存如用户近7天交易频次- 对低频特征采用“懒加载”仅当模型判定为高风险时才触发实时计算- 用Flink CEP替代Kafka Streams处理复杂事件模式模型推理延迟1~50ms模型过大、框架开销、GPU显存不足- 使用Triton Inference Server统一管理支持动态批处理Dynamic Batching- 对树模型XGBoost/LightGBM导出为Treelite格式C原生推理提速3倍- GPU推理时强制设置CUDA_VISIBLE_DEVICES隔离显存避免多模型争抢序列化/反序列化2~20msJSON解析慢、Protobuf未启用压缩- 输入输出统一采用Protocol Buffers v3启用Zstandard压缩压缩比3:1CPU开销5%- 禁用Pythonjson库改用ujson或orjson关键洞察延迟优化的ROI投资回报率遵循二八定律——80%的收益来自20%的关键路径优化。不要一上来就重构整个特征管道先用py-spy或perf工具精准定位热点函数。在某基金公司的智能投顾项目中我们发现90%的延迟集中在特征服务的pandas.merge()操作上。将两个DataFrame的merge改为join利用索引延迟直接从180ms降至22ms远超重写整个ETL的收益。3.2 可扩展性 可预测性拒绝“平均表现好峰值就崩盘”很多团队对“可扩展性”的理解停留在“加机器就能扛住流量”。这是危险的幻觉。真正的可扩展性是系统在任意负载下尤其是非稳态峰值的行为可预测、可解释、可控制。它要求你回答当QPS从5000骤增至15000时延迟是线性增长、指数增长还是出现拐点式崩溃错误率是缓慢爬升还是突然跃迁资源消耗CPU、内存、网络IO是否与负载严格成正比我在某物流公司的路径规划模型落地时深刻体会到这一点。该模型需为每单快递实时计算最优配送路线日均调用量2000万次但大促期间峰值QPS可达平时的8倍。初期架构采用“单体服务垂直扩容”测试时一切正常。上线后当流量达到峰值的70%时服务开始出现偶发性503错误且错误率随流量增长呈非线性飙升。深入排查发现问题出在Python GIL全局解释器锁当并发请求激增时大量线程在等待GIL释放导致CPU利用率虚高90%但实际有效工作线程不足。此时加CPU核数毫无意义因为GIL成了单点瓶颈。解决方案不是换语言而是架构层面的解耦与异步化将耗时的路径计算涉及图算法剥离为独立Worker服务用Celery Redis Broker管理任务队列API服务只负责接收请求、生成任务ID、返回202 Accepted由前端轮询结果Worker服务用Cython重写核心图算法彻底绕过GIL为Worker设置动态扩缩容策略当队列积压1000时自动启动新Worker实例K8s HPA基于redis_queue_length指标。改造后系统在峰值QPS 12000时P99延迟稳定在380msSLA为500ms错误率0.01%。更重要的是其扩展曲线变得高度线性QPS每增加1000延迟仅增加约3ms运维人员可以精准预测任何流量规模下的表现。可扩展性设计的三条铁律无状态优先所有服务必须设计为无状态Stateless。会话、缓存、中间结果全部外置到Redis/Memcached。这不仅是为K8s扩缩容铺路更是为了故障隔离——单个实例宕机不影响全局。背压Backpressure必须可见且可控当下游如数据库、特征服务处理不过来时上游不能盲目重试或丢弃请求而应通过信号如Kafka消费延迟、HTTP 429状态码感知并主动减速。我们在某银行的贷中监控系统中为特征服务设置了“熔断-半开-关闭”三态机制当错误率30%持续30秒自动熔断熔断后每60秒尝试1次探针请求成功则进入半开态允许10%流量全部成功才恢复全量。资源消耗必须与业务负载强相关杜绝“常驻高负载”服务。例如模型服务在夜间低峰期应自动缩容至1个副本CPU限制设为100m高峰前1小时根据历史流量预测模型提前扩容至预设上限。我们用Prometheus custom metrics adapter K8s VPAVertical Pod Autoscaler实现了这一目标资源成本降低42%而SLA达标率反升至99.99%。4. 监控、漂移检测与模型验证在变化的世界里守护决策的确定性4.1 监控不是看大盘而是构建决策健康度的“心电图”把Grafana里几个红绿线条当成“监控到位”是生产ML系统最大的认知陷阱。真正的监控必须能回答一个终极问题当前的模型决策是否还在业务可接受的风险范围内这要求监控体系超越技术指标深入业务语义层形成一张覆盖“输入-处理-输出-影响”的全链路健康度心电图。我设计的监控体系分为四个层级每一层都对应不同的预警阈值和处置流程L1基础设施层Infrastructure Health关注点服务器CPU/内存/磁盘IO、K8s Pod重启率、网络丢包率预警阈值Pod重启3次/小时或CPU持续90%达5分钟处置自动触发告警通知SRE团队不涉及模型团队L2服务层Service Health关注点模型API P99延迟、HTTP错误率4xx/5xx、特征服务调用成功率、Kafka消费延迟预警阈值P99延迟SLA的120%或5xx错误率0.5%持续2分钟处置自动触发Fallback机制同时告警模型与平台团队联合排查L3数据层Data Health——这才是ML监控的核心战场关注点输入数据漂移Input Drift实时计算特征分布与基线训练集/上周的KS检验值、PSIPopulation Stability Index特征质量Feature Quality各特征空值率、异常值率如age120、取值范围越界率标签新鲜度Label Freshness关键业务标签如“是否逾期”的延迟小时数预警阈值PSI 0.25中度漂移0.5严重漂移user_income空值率5%基线为0.1%逾期标签延迟48小时处置自动触发数据诊断报告并通知数据工程师若漂移持续24小时未修复则标记模型为“观察中”限制其在高风险场景的调用权重。L4决策层Decision Health——直指业务价值关注点决策分布偏移Decision Drift模型输出分数的分布如0.0~1.0区间与基线的KL散度业务指标联动模型决策与下游业务结果的关联性如“模型预测高风险”用户中实际发生欺诈的比例Precision人工干预率Override Rate业务人员手动修改模型决策的比例预警阈值Precision下降15%相比基线Override Rate 8%基线为2%处置立即冻结模型在新客审批场景的使用启动模型复训流程并向业务方发出正式风险通告。实操心得L3和L4的监控必须“自动化到极致”。我们用Airflow调度每日任务自动计算PSI/KL散度生成PDF诊断报告含漂移特征TOP5、可视化分布对比图、根因推测并通过企业微信机器人推送给数据、模型、业务三方负责人。报告不是“发现问题”而是“给出行动项”例如“device_fingerprint_entropy特征PSI0.42主因是新安卓14系统导致熵值普遍升高建议更新特征计算逻辑或加入系统版本校正因子”。4.2 漂移检测不是“有没有漂移”而是“漂移是否影响决策”数据漂移Data Drift常被妖魔化为“模型失效的前兆”但这是一种误解。漂移本身是中性的它是现实世界变化的客观反映。真正危险的是“未被察觉的、影响决策质量的漂移”。我的经验是必须建立“漂移影响评估矩阵”对每次检测到的漂移进行分级响应。漂移影响评估四维模型维度评估方法高风险信号示例应对策略业务敏感度该特征在模型中的SHAP值绝对值排名、或特征重要性得分transaction_velocity_1hSHAP值Top3PSI0.35立即复训模型加入新特征交互项漂移幅度PSI/KL散度数值、或分布偏移的统计显著性p-value 0.01user_age分布右移PSI0.18但p-value0.23观察暂不干预漂移速度连续监测的PSI变化斜率如过去3天PSI从0.05→0.12→0.25app_version特征PSI 24小时内从0.01飙升至0.61紧急发布特征适配补丁业务后果关联分析漂移发生后下游业务指标如欺诈率、逾期率是否同步恶化device_risk_score漂移后高分段欺诈率从12%升至28%启动紧急模型回滚并调查数据源变更这个矩阵让我们摆脱了“一刀切”的漂移响应。例如在某电商的实时价格推荐模型中我们检测到user_session_duration特征PSI达到0.31中度漂移。但评估发现该特征SHAP值仅排第17位且漂移是因APP新版本增加了“沉浸式浏览”功能导致会话时长自然延长更重要的是漂移后模型推荐的高价商品点击率反而提升了9%。结论这是良性漂移无需干预反而应将新会话模式纳入下一轮训练。漂移检测的实操工具链实时计算用Flink SQL实时计算每个特征的滑动窗口统计量均值、方差、分位数并与基线快照比对离线诊断用Evidently AI库每日生成漂移报告它能自动识别漂移特征、可视化分布、并给出可解释性分析如“income漂移主要由高收入群体样本增加导致”根因追踪在特征管道中埋点记录每个特征的原始数据源、加工逻辑、血缘关系。当漂移发生时一键追溯到上游ETL Job或数据源变更。4.3 模型验证与压力测试用“找茬”代替“自证清白”在金融、医疗等强监管领域“模型效果好”不等于“可以投产”。监管机构如银保监会、FDA要求的是可验证的鲁棒性Verifiable Robustness。这意味着你不能只说“我的模型在测试集上AUC0.89”而必须证明“当输入数据被刻意扰动、缺失、或处于极端分布时模型的决策依然符合业务安全边界”。我的压力测试框架包含三个必做模块模块一对抗性鲁棒性测试Adversarial Robustness工具使用TextAttackNLP或ART通用库对输入特征施加微小扰动如将user_income从50000改为50001观察模型输出分数变化是否超过阈值如Δscore 0.05场景重点测试对业务决策影响最大的特征。例如在信贷模型中对credit_utilization_ratio信用额度使用率进行扰动验证其对“是否批准”决策的敏感度结果生成“鲁棒性热力图”标出模型最脆弱的特征组合。模块二极端场景压力测试Extreme Scenario Stress Test构建10个业务定义的“地狱场景”Scenario_FraudWave模拟黑产团伙使用同一设备、同一IP、不同账号发起密集申请Scenario_MarketCrash将所有资产类特征股票、基金、房产估值按历史最大跌幅如-40%批量修正Scenario_DataOutage随机屏蔽30%的特征测试L1降级逻辑的有效性执行在隔离环境运行全量测试集记录每个场景下的决策准确率Accuracy关键业务指标如欺诈漏判率、误拒率Fallback触发率与耗时输出《压力测试报告》必须包含“场景-指标-根因-修复建议”四栏表格例如场景欺诈漏判率根因建议Scenario_FraudWave22.3%device_fingerprint特征在高并发下计算超时返回空值为该特征增加本地缓存超时熔断模块三时间一致性验证Temporal Consistency方法将模型部署后每天的预测结果与一个“静态快照模型”即上线当日冻结的模型的预测结果进行比对关键指标consistency_rate相同输入下两模型输出决策一致的比例drift_magnitude分数差异的均值与标准差意义如果consistency_rate在一周内从99.9%骤降至92%说明模型服务或特征管道发生了未预期的变更如框架升级、依赖库更新必须立即回溯。注意所有压力测试必须在与生产环境1:1的镜像环境中执行包括相同的硬件配置、网络拓扑、中间件版本。我曾见过团队在本地MacBook上测试通过上线后因Linux内核TCP栈参数差异导致连接池耗尽——这种“环境债”必须在测试阶段就还清。5. 治理、审计与合规让信任可追溯让责任可落实5.1 治理不是枷锁而是规模化协作的交通规则在敏捷开发盛行的今天“治理”常被贴上“官僚主义”、“拖慢交付”的标签。但我的亲身经历告诉我缺乏治理的ML项目就像没有红绿灯的十字路口——短期看畅通无阻长期必然酿成惨烈事故。治理的本质是为跨职能团队数据、算法、工程、业务、风控、合规建立一套清晰、可执行、可审计的协作规则让“谁在什么条件下对什么结果负责”这件事不再依赖个人记忆或口头承诺。我主导设计的ML治理框架核心是“三权分立”模型- 数据所有权Data Ownership每个数据资产如customer_transaction_log表必须指定唯一的数据所有者Data Owner通常是业务部门的资深专家。其职责包括定义数据的业务含义、质量标准如transaction_amount必须0、生命周期审批对该数据的任何访问请求特别是用于模型训练的脱敏规则在数据源变更如字段下线、逻辑重构时主动通知所有下游模型团队。实操案例某银行信用卡中心的数据Owner在发现card_type字段将从枚举值Gold,Platinum改为编码值01,02时提前30天发出变更通告并提供了映射字典。这避免了5个在训模型因字段解析错误而产出无效特征。- 模型治理权Model Governance由跨部门组成的模型治理委员会MGC行使成员包括首席数据官CDO、风控总监、AI伦理官、模型负责人。其核心权力是准入审批任何模型上线前必须通过MGC的“五问”审查训练数据是否获得用户明确授权特征工程是否引入了受保护的属性如种族、性别模型决策是否可解释对高风险决策提供Top3影响因子是否完成全链路压力测试并提交报告是否定义了明确的Fallback与回滚SOP生命周期管理为每个模型分配唯一ID、版本号、有效期如12个月到期前自动触发复审流程。- 运行监督权Operational Oversight由独立的AI运营中心AIOC承担其职责是“不碰代码只盯结果”每日生成《模型健康日报》包含L3/L4监控指标、人工Override详情、客户投诉中提及模型的案例对连续3天Override Rate5%的模型自动发起“模型效能复盘会”邀请业务方、模型方、数据方共同分析每季度发布《模型治理透明度报告》向全公司公示各模型的准确率、公平性指标如不同年龄段用户的误拒率差异、改进计划。这套框架看似繁琐但它带来的效率提升是惊人的。在某保险集团推行后模型从开发到上线的平均周期从原来的14周缩短至8周。原因在于清晰的权责划分消除了“踢皮球”环节。当数据质量出问题直接找Data Owner当模型效果下滑MGC强制启动复训当业务方质疑决策AIOC提供完整日志溯源。所有人的时间都花在解决问题上而不是争论“这该谁管”。5.2 审计就绪让每一次检查都成为展示专业性的机会在金融、医疗等行业“审计”不是负担而是证明你专业性的舞台。一个审计就绪Audit-Ready的ML系统其核心特征是所有关键决策都能在5分钟内从原始数据追溯到最终输出并附带完整的上下文解释。这要求你在系统设计之初就将“可追溯性”作为第一性原理。我的审计就绪清单包含七个必须落地的要素1. 全链路血缘End-to-End Lineage工具使用Marquez或OpenLineage自动采集从原始数据库表→ETL Job→特征表→模型训练→模型服务→API调用的完整血缘关键血缘图中必须标注每个节点的时间戳、操作人、代码Commit ID、配置参数。例如某次模型训练的血缘节点应显示“2026-04-10 14:22:03by data_engineer_zhangcommita1b2c3d参数--max_depth6 --learning_rate0.1”。2. 决策日志Decision Logging每一次模型调用必须记录输入完整的原始特征向量JSON格式含字段名与值输出预测分数、决策标签、fallback_reason如feature_missing、model_version上下文request_id、business_scenario、user_id_hash脱敏、timestamp存储日志必须写入独立、不可篡改的存储如AWS S3 WORM策略保留期≥7年。3. 模型卡片Model Card每个模型必须有一份公开的HTML卡片包含用途解决什么业务问题目标用户是谁性能在哪些数据集上测试各项指标Accuracy,