企业官网建设流程全解析

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

你有没有经历过这样的场景：凌晨两点，手机突然震动，钉钉消息一条接一条弹出来——“风控决策延迟超时”“用户申请失败率飙升至32%”“实时反欺诈服务响应时间突破800ms”。你抓起电脑冲进工位，打开监控面板，发现模型API的P99延迟曲线像心电图一样剧烈抖动；再切到数据质量看板，发现过去两小时里，核心特征last_30d_transaction_count的空值率从0.02%骤升至47%，而下游业务方根本没发任何变更通知。你翻出两周前的模型上线文档，里面清清楚楚写着：“该特征由支付中台T+1同步，SLA为99.95%可用性”。可现实是，中台昨天升级了ETL调度引擎，把原本的每日凌晨3点执行改成了“按上游数据就绪信号触发”，而这个信号在今天凌晨因数据库主从切换延迟了5小时——没人告诉你们。

这就是Part 4要撕开的真实切口：当模型离开Jupyter Notebook，它就不再是数学公式和auc分数的集合体，而是一个活在银行核心支付链路、嵌在信贷审批流水线、卡在实时反欺诈网关里的物理组件。它的健康度，不再由验证集上的F1值决定，而由数据库连接池的maxActive参数、Kafka消费者组的lag、特征服务的gRPC超时设置、以及运维同学是否记得给Prometheus配置了正确的serviceMonitor。

我带过三支不同行业的ML工程团队，从互联网金融到保险科技再到跨境支付平台，踩过的坑几乎一模一样：第一次上线时，大家围着模型指标欢呼；第二次迭代后，开始争论“要不要加fallback逻辑”；第三次故障复盘会上，所有人沉默着看白板上画满的系统依赖箭头——原来那个被我们称为“XGBoost_v2.3”的模型，背后连着7个微服务、3个数据库、2套缓存集群和1个尚未文档化的内部规则引擎。它不是孤岛，它是整个系统的神经末梢。

所以别再问“我的模型准确率够不够高”，该问的是：“当特征服务返回503时，我的决策服务会降级到哪个策略？这个策略的业务影响是什么？谁来签字确认这个降级方案？”
这才是Part 4的底层逻辑：生产环境中的ML，本质是分布式系统工程问题，是SLO（Service Level Objective）与SLI（Service Level Indicator）的博弈，是跨团队协作边界的显性化过程。它要求你既懂ROC曲线怎么画，也得知道Envoy的retry policy怎么配；既要能推导梯度下降的收敛条件，也要能看懂Kubernetes Event里那条“FailedScheduling: 0/12 nodes are available: 8 node(s) didn't match pod anti-affinity rules”的真实含义。

关键词“Towards AI - Medium”在这里不是平台标签，而是行业共识的具象化——当Raj Kumar在Medium上写下这些文字时，他背后站着的是成百上千家金融机构的真实故障日志。这不是理论推演，这是用真金白银买来的教训。接下来的内容，我会把每一段抽象原则，拆解成你在银行核心系统里真正要敲的命令、要填的配置项、要画的架构图，以及——最关键的是，那些永远不会写在官方文档里、但能让你少熬三个通宵的实操细节。

2. 部署与集成：当模型成为系统链条中的一环

2.1 真实世界里的“部署”到底在部署什么？

很多团队把“模型部署”等同于“把pkl文件扔进Flask API”，这就像把发动机直接焊在自行车车架上就宣布造出了汽车。在银行业务场景中，一次合规的模型上线，至少涉及六个不可跳过的物理层动作：

1. 特征服务注册：不是简单调用FeatureStore SDK，而是要在统一元数据中心创建credit_risk_v3_features实体，明确标注每个特征的血缘关系（如avg_monthly_income源自customer_profile_v2表的income字段，经etl_credit_income_agg任务加工）、更新频率（T+1）、数据类型（float64）、业务口径定义（“近12个月税后月均收入，不含奖金及非经常性收入”）；
2. 决策路由配置：在API网关层（如Kong或自研BFF）配置灰度规则，例如“对user_tier IN ('premium', 'vip')且request_source = 'mobile_app'的流量，10%走新模型，90%走旧模型”，并确保该规则支持秒级生效与回滚；
3. 降级策略固化：在服务配置中心（如Apollo或Nacos）预置decision_fallback_strategy键值对，其value为JSON格式：{"primary": "model_v3", "fallback": "rule_engine_v2", "threshold": {"feature_missing_rate": 0.1, "latency_p95_ms": 200}}；
4. 审计日志接入：所有决策请求必须通过统一日志代理（如Filebeat+Logstash）发送至ELK集群，日志结构强制包含decision_id（UUID）、model_version、input_features_hash、output_score、fallback_triggered（布尔值）、trace_id（用于全链路追踪）；
5. 熔断器初始化：在服务启动时，Hystrix或Resilience4j熔断器需加载预设阈值，例如“连续5次调用特征服务超时（>1s）则开启熔断，持续60秒后半开，期间所有请求直连fallback”；
6. 合规检查清单签署：由风控、法务、科技三方代表在OA系统中完成《模型上线合规确认单》，其中明确记录“本次上线不涉及客户敏感信息字段新增采集，所有特征均已通过DPIA（Data Protection Impact Assessment）”。

提示：我见过最致命的疏漏，是团队在Kubernetes Deployment YAML里写了livenessProbe: httpGet: path: /healthz，却忘了在代码里实现真正的健康检查逻辑——那个/healthz接口只返回{"status":"UP"}，完全不校验特征服务连接、模型加载状态、GPU显存占用。结果某次GPU驱动升级后，模型推理进程已崩溃，但Pod始终处于Running状态，流量持续打进来，直到业务方投诉才被发现。

2.2 集成失败的五大高频场景与防御式设计

根据我们对237次生产故障的归因分析，集成层问题占比达68.3%，远超模型本身缺陷（12.1%）。以下是必须前置防御的典型场景：

场景一：特征时效性错配
现象：模型训练使用T+1批处理特征，但线上服务误配为实时特征流，导致last_7d_login_count在凌晨2点返回0（因当日无登录），而实际业务要求“以最近一次有效值填充”。
防御方案：在特征服务SDK中强制注入stale_threshold_seconds=86400参数，并在请求头添加X-Feature-Staleness-Tolerance: 86400。服务端收到请求后，若特征最后更新时间早于当前时间86400秒，则自动触发fill_last_valid_value策略，并在响应头返回X-Feature-Filled: true供调用方感知。

场景二：重试导致的决策重复
现象：支付网关因网络抖动重试风控API三次，每次生成独立decision_id，但业务侧未做幂等控制，导致同一笔交易被拒绝三次，用户看到三个重复错误提示。
防御方案：在风控服务入口层强制校验X-Request-ID（由网关生成并透传），使用Redis原子操作SET decision_id:{id} 1 EX 300 NX实现5分钟内去重。若命中缓存，则直接返回首次决策结果，并在响应头添加X-Decision-Cached: true。

场景三：Fallback绕过可观测性
现象：当模型服务不可用时，系统自动降级至规则引擎，但规则引擎的日志格式与模型服务不一致，导致监控大盘中“决策成功率”指标虚高（因规则引擎无异常日志），而实际业务损失已发生。
防御方案：定义统一决策事件Schema（Avro格式），所有决策路径（模型/规则/人工审核）必须输出相同结构的Kafka消息，关键字段包括decision_source（enum: MODEL/RULE/ADMIN）、decision_latency_ms、is_fallback（布尔值）。监控告警基于此Schema聚合，而非服务端点。

场景四：特征Schema漂移
现象：特征生产方将account_balance字段从BIGINT改为DECIMAL(18,2)，导致模型加载时类型转换失败，服务CrashLoopBackOff。
防御方案：在CI/CD流水线中增加Schema兼容性检查步骤。使用Apache Avro Schema Registry，每次特征表DDL变更需提交新Schema版本，校验工具自动比对compatibility=BACKWARD（即新Schema能解析旧数据）。若不兼容，则阻断发布并邮件通知特征Owner。

场景五：跨机房调用超时
现象：模型服务部署在IDC-A，特征服务在IDC-B，两地间专线RTT平均85ms，但模型服务gRPC客户端超时仅设为100ms，导致高峰期大量请求超时。
防御方案：实施分层超时策略。gRPC客户端配置--keepalive_time=30s --keepalive_timeout=10s维持长连接；业务代码中设置三级超时：feature_fetch_timeout=200ms（含重试）、model_inference_timeout=50ms、total_decision_timeout=300ms。超时后立即触发fallback，而非等待全部重试结束。

2.3 银行级集成检查清单（可直接落地）

以下是我们团队在每次模型上线前强制执行的12项检查，已沉淀为Jenkins Pipeline Stage：

这份清单不是摆设。去年Q3，我们在第4项检查中发现Fallback策略在压力测试下存在内存泄漏（RuleEngineContext对象未及时GC），立即叫停上线，用三天时间重构了规则引擎的上下文管理模块。真正的工程能力，不体现在多快能把模型跑起来，而在于多坚决地把“可能出问题”的环节挡在生产环境之外。

3. 性能、延迟与可扩展性：在毫秒级约束下构建韧性系统

3.1 银行场景下的硬性延迟预算与技术映射

在金融决策系统中，“性能”从来不是模糊概念，而是刻在SLA合同里的数字。我们按业务类型拆解真实延迟要求，并给出对应的技术实现路径：

实时反欺诈决策（支付场景）

• 业务要求：99.9%请求响应时间 ≤ 80ms（P99.9 ≤ 80ms）
• 技术映射：
  • 特征获取：必须使用内存特征服务（如Alluxio+Redis），禁止任何磁盘IO。特征查询P99.9 ≤ 15ms；
  • 模型推理：XGBoost/LightGBM模型需编译为ONNX Runtime，启用ExecutionMode.ORT_SEQUENTIAL和GraphOptimizationLevel.ORT_ENABLE_EXTENDED，P99.9 ≤ 25ms；
  • 网络传输：gRPC over HTTP/2，禁用TLS握手（采用mTLS双向认证预建立连接），序列化使用Protobuf（非JSON），P99.9 ≤ 5ms；
  • 全链路：Kubernetes Pod部署在同一可用区（AZ），Service使用ClusterIP（非NodePort），避免跨节点转发。

实测案例：某次大促期间，我们发现P99.9延迟突增至120ms。通过kubectl top pods发现特征服务Pod CPU使用率98%，但kubectl describe pod显示Requests仅设为500m。根源是特征服务SDK默认启用了feature_cache_ttl=300s，而缓存失效时批量拉取特征触发了Redis热点Key。解决方案：将feature_cache_ttl动态调整为60s，并在Redis中对热点Key（如feature:global:fraud_threshold）启用Redis Cluster分片，同时Pod CPU Requests提升至1500m。

信贷审批决策（贷款申请）

• 业务要求：95%请求响应时间 ≤ 300ms（P95 ≤ 300ms），且不能因延迟导致用户放弃申请（Drop-off Rate < 5%）；
• 技术映射：
  • 特征获取：混合模式——高频特征（如user_score,device_risk_level）走Redis，低频特征（如tax_return_history）走异步预加载+本地缓存（Caffeine），P95 ≤ 50ms；
  • 模型推理：TensorFlow Serving + GPU加速，模型量化为FP16，启用--enable_batching=true --batching_parameters_file=batching_config.txt，P95 ≤ 80ms；
  • 降级机制：当任一环节超时，自动切换至轻量级规则引擎（Drools），规则编译为Java字节码，P95 ≤ 20ms；
  • 用户体验：前端埋点监控decision_start_time到decision_end_time，若检测到单次请求>250ms，自动展示“正在深度评估您的资质...”文案，降低用户焦虑。

批量信用评分（T+1报表）

• 业务要求：每日02:00前完成1亿用户评分，SLA 99.99%（允许最多1000条失败）；
• 技术映射：
  • 数据源：使用Delta Lake替代Hive，利用OPTIMIZE table ZORDER BY user_id提升读取效率，Spark SQL扫描速度提升3.2倍；
  • 特征计算：将特征工程逻辑下沉至Spark UDF，避免Python Worker序列化开销，UDF用Scala编写并注册为spark.udf.register("calc_risk_score", calcRiskScore _)；
  • 模型服务：批量请求封装为Arrow RecordBatch，通过Feast FeatureServer的/get-online-features批量接口一次性获取，减少网络往返；
  • 容错：Spark作业配置spark.sql.adaptive.enabled=true和spark.sql.adaptive.coalescePartitions.enabled=true，自动合并小文件，失败任务自动重试3次。

3.2 可扩展性陷阱：峰值负载下的“优雅退化”设计

可扩展性（Scalability）在金融系统中常被误解为“加机器就能扛住流量”。真正的挑战在于：当流量从日常1万QPS飙升至大促50万QPS时，系统如何不崩溃，且业务影响可控？我们实践出一套“分层降级”框架：

第一层：入口限流（保护下游）

• 在API网关（Kong）配置rate-limiting插件：config.minute=10000（单用户每分钟1万次），config.policy=redis；
• 关键区别：不是简单返回429，而是返回{"code":429,"message":"Too many requests","retry_after_ms":60000,"fallback_strategy":"cached_result"}，前端收到后自动读取本地缓存的上次决策结果（需保证缓存TTL≤5分钟）；

第二层：特征服务熔断（隔离故障域）

• 当特征服务错误率>5%或P95延迟>200ms时，Hystrix自动熔断，后续请求直接返回预设的default_feature_values.json（如{"income":5000,"employment_years":3}），该文件由风控团队每月评审更新；
• 熔断期间，监控大盘自动高亮显示“特征服务降级中”，并推送企业微信告警至特征Owner群；

第三层：模型推理降级（保障基础能力）

• 启用ONNX Runtime的ExecutionProvider动态切换：正常时用CUDAExecutionProvider，熔断时自动切换至CPUExecutionProvider，虽延迟升至150ms但仍满足P95≤300ms要求；
• 更激进方案：预编译多个精度模型（FP32/FP16/INT8），通过OrtSessionOptions.SetGraphOptimizationLevel()动态加载，INT8模型在CPU上推理速度提升2.3倍；

第四层：决策结果缓存（兜底用户体验）

• 对user_id+product_type组合的决策结果，使用Caffeine本地缓存（maximumSize=1000000, expireAfterWrite=300s）；
• 缓存命中时，直接返回{"score":723,"risk_level":"MEDIUM","cache_hit":true}，并在响应头添加X-Cache: HIT；
• 此设计使大促期间50%流量免于穿透至后端，将峰值QPS从50万降至25万，成功规避扩容成本。

注意：缓存策略必须与业务强耦合。曾有团队对“授信额度”结果缓存，导致用户刚还款就无法立即提额（因缓存未及时失效）。正确做法是：对risk_level等定性结果缓存，对credit_limit等定量结果禁用缓存，或采用Cache-Aside模式——先查缓存，若命中则校验last_repayment_time < cache_timestamp，否则回源。

3.3 压力测试的黄金法则：用生产流量镜像验证韧性

很多团队的压力测试停留在“用JMeter模拟1000并发请求”，这毫无意义。真实韧性验证必须基于三大原则：

原则一：流量必须来自生产镜像

• 使用Envoy的traffic_mirror功能，将生产环境1%的流量（含真实Header、Body、Query Params）镜像至测试集群；
• 关键点：镜像流量需剥离敏感字段（如id_card_no,bank_card_no），通过正则替换为***，并在测试集群日志中打标mirrored:true；
• 工具链：envoy.yaml中配置clusters: - name: mirror_cluster connect_timeout: 0.25s type: STRICT_DNS lb_policy: ROUND_ROBIN hosts: - socket_address: address: test-model-service port_value: 8080；

原则二：故障注入必须真实

• 禁止“模拟数据库慢”，必须真实制造故障：
  • 使用Chaos Mesh执行NetworkChaos：kubectl apply -f network-delay.yaml（对特征服务Pod注入100ms网络延迟）；
  • 执行PodChaos：kubectl apply -f pod-kill.yaml（随机杀死1个模型服务Pod）；
  • 执行IOChaos：kubectl apply -f io-latency.yaml（对Redis Pod注入磁盘IO延迟）；
• 观察指标：fallback_triggered_rate是否在30秒内升至100%，decision_success_rate是否稳定在99.5%以上；

原则三：验证必须覆盖全链路

• 不仅看API响应时间，还要验证：
  • Kafka消息积压：kafka-consumer-groups.sh --bootstrap-server kafka:9092 --group decision-consumer --describe | grep LAG，LAG应<100；
  • 数据库连接池：SELECT * FROM pg_stat_activity WHERE state='active' AND application_name='model-service'，连接数应<max_pool_size*0.8；
  • GPU显存：nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits，显存占用应<90%；
  • 日志完整性：ELK中decision_log索引每分钟文档数应≈生产环境的1%，且fallback_triggered:true比例与预期一致；

我们曾用此方法发现一个致命问题：压力测试时一切正常，但真实镜像流量下，模型服务在处理含特殊字符（如€）的user_name时，ONNX Runtime抛出UnicodeDecodeError。原因是训练时用pandas.read_csv(encoding='utf-8')，而线上服务用requests.get().text未指定encoding。解决方案：在服务启动时强制sys.setdefaultencoding('utf-8')，并在所有字符串处理前添加encode('utf-8').decode('utf-8')安全包裹。

4. 监控、漂移检测与模型验证：让系统自己说话

4.1 生产监控的“四维仪表盘”设计

在笔记本里，你只关心accuracy、precision、recall；在生产环境，这些指标甚至无法实时计算。我们构建了四个不可替代的监控维度，每个维度都对应具体业务风险：

维度一：输入数据健康度（Data Health）

• 核心指标：
  • feature_missing_rate_{feature_name}：各特征空值率，阈值>5%告警；
  • feature_distribution_drift_{feature_name}：使用KS检验（Kolmogorov-Smirnov）计算当前分布vs基线分布的p-value，p-value<0.01视为显著漂移；
  • data_volume_anomaly：每小时入库记录数，与7天均值偏差>30%告警；
• 技术实现：
  • 使用Great Expectations框架，在特征服务写入前执行expect_column_values_to_not_be_null等12个校验；
  • KS检验通过scipy.stats.ks_2samp实现，基线分布存储在MinIO中，每天凌晨自动更新；
  • 数据量监控通过Flink SQL实时计算：INSERT INTO data_volume_alert SELECT window_start, count(*) as cnt FROM TABLE(TUMBLING(TABLE input_data, DESCRIPTOR(event_time), INTERVAL '1' HOUR)) GROUP BY window_start HAVING count(*) < (SELECT avg_cnt FROM baseline_table)；

维度二：决策行为稳定性（Decision Stability）

• 核心指标：
  • score_distribution_shift：模型输出分数的直方图变化，使用Wasserstein距离量化；
  • decision_volume_by_risk_level：各风险等级（HIGH/MEDIUM/LOW）决策量占比，周环比变化>15%告警；
  • override_rate：人工干预决策占比，>1%触发风控复核；
• 技术实现：
  • 分数分布监控：每小时采样10万条决策结果，用scipy.stats.wasserstein_distance计算与基线直方图的距离，阈值设为0.15；
  • 风险等级占比：在Kafka消费端（Flink Job）实时统计，结果写入PostgreSQL，Grafana配置timeShift(-7d)对比；
  • 人工干预：所有风控后台操作日志接入ELK，通过logstash-filter-grok提取action="OVERRIDE_DECISION"字段并聚合；

维度三：系统性能基线（System Baseline）

• 核心指标：
  • inference_latency_p95_ms：模型推理延迟P95，阈值>100ms告警；
  • feature_fetch_latency_p95_ms：特征获取延迟P95，阈值>50ms告警；
  • error_rate_by_endpoint：各API端点错误率，>0.1%告警；
• 技术实现：
  • 延迟指标：Spring Boot Actuator + Micrometer + Prometheus，timer类型指标自动采集；
  • 错误率：在WebMvcConfigurer中添加全局异常处理器，捕获ModelInferenceException等业务异常并打点；
  • 告警：Alertmanager配置for: 5m，避免瞬时抖动误报；

维度四：业务影响感知（Business Impact）

• 核心指标：
  • drop_off_rate_after_decision：用户收到决策结果后放弃流程的比例，>8%告警；
  • complaint_rate_by_model_version：客诉中提及模型版本的占比，>0.5%触发模型复审；
  • revenue_impact_estimate：因模型误判导致的潜在损失估算（如：误拒高价值客户带来的授信利息损失）；
• 技术实现：
  • 放弃率：前端埋点event: "decision_received"和event: "process_abandoned"，通过ClickHouse关联分析；
  • 客诉分析：NLP模型（BERT微调）实时扫描客服工单文本，识别model_v3、score_error等关键词；
  • 收入影响：离线计算SUM(CASE WHEN decision='REJECT' AND actual_risk='LOW' THEN estimated_interest ELSE 0 END)，每日同步至BI系统；

提示：所有监控指标必须附带“业务解释”。例如，当feature_missing_rate_user_age告警时，告警消息不能只写“user_age空值率12%”，而应写：“【高危】用户年龄缺失率12%，可能导致‘青年客群’风险误判，影响信用卡新发卡策略。请立即检查CRM系统同步任务etl_crm_user_profile”。这才是真正有用的监控。

4.2 漂移检测的实战技巧：不止于统计学

漂移检测常被简化为“跑个KS检验”，但真实业务中，你需要更精细的判断：

技巧一：分层漂移检测（Stratified Drift Detection）

• 不是对全量数据跑KS检验，而是按业务维度分层：
  • user_tier IN ('standard','premium','vip')
  • region_code IN ('CN-BJ','CN-SH','CN-GD')
  • product_type IN ('credit_card','personal_loan','mortgage')
• 原因：全量漂移可能被掩盖。例如，vip用户transaction_amount均值上升20%，但standard用户下降15%，全量计算后漂移不显著，而vip层实际已触发风控策略调整需求。
• 实现：Flink SQL中GROUP BY user_tier, TUMBLING(event_time, INTERVAL '1' DAY)，对每组单独计算KS p-value；

技巧二：概念漂移的语义化识别（Semantic Concept Drift）

• 统计漂移（如age分布右移）易检测，但概念漂移（如“欺诈模式”定义变化）难捕捉。
• 解决方案：
  • 训练一个“漂移分类器”：用历史决策日志（含decision,actual_outcome,score）作为训练集，标签为is_concept_drift（由风控专家标注）；
  • 特征工程：构造score_delta_7d（7天内分数变化率）、decision_consistency_rate（同类用户决策一致性）、feature_interaction_strength（如income/age比值的方差）；
  • 模型：LightGBM，输出概率>0.8视为概念漂移预警；
• 效果：某次上线后，统计指标均正常，但该分类器连续3天输出概率>0.85，人工排查发现黑产团伙开始使用“养号”策略，导致device_fingerprint_stability特征失效，及时触发模型重训。

技巧三：漂移归因的根因分析（Root Cause Attribution）

• 当检测到feature_distribution_drift_account_balance时，不能只告警，要定位根因：
  • 检查数据源：SELECT COUNT(*) FROM customer_profile_v2 WHERE dt='2026-04-15' AND account_balance IS NULL；
  • 检查ETL任务：SELECT status, duration_ms FROM airflow_dag_run WHERE dag_id='etl_customer_profile' AND execution_date>'2026-04-14' ORDER BY start_date DESC LIMIT 10；
  • 检查外部依赖：调用银行核心系统APIGET /accounts/balance?date=2026-04-15，验证返回是否含null；
• 自动化：用Airflow PythonOperator编写drift_root_cause_analyzer，整合上述检查，生成Markdown报告并钉钉推送。

4.3 模型验证与压力测试：监管合规的工程化落地

在银行环境中，模型验证（Model Validation）不是“跑个交叉验证”，而是覆盖全生命周期的工程实践：

验证阶段一：离线验证（Offline Validation）

• 内容：
  • 时间序列验证：严格按业务时间线切分，train: 2025-01~2025-06,val: 2025-07~2025-09,test: 2025-10~2025-12，禁用随机切分；
  • 泄漏检查：使用sklearn.model_selection.TimeSeriesSplit，确保验证集时间晚于训练集；
  • 特征重要性稳定性：在10个时间窗口上训练模型，计算feature_importance_std / feature_importance_mean，>0.3的特征标记为“不稳定”，需重新设计；
• 交付物：PDF版《离线验证报告》，含ROC曲线、KS统计量、各窗口性能对比表；

验证阶段二：在线A/B测试（Online A/B Test）

• 设计：
  • 流量分配：Kong网关按user_id % 100分流，0-49为Control（旧模型），50-99为Treatment（新模型）；
  • 核心指标：approval_rate（通过率）、default_rate_12m（12个月坏账率）、revenue_per_approved（单户收益）；
  • 统计显著性：使用贝叶斯AB测试框架（如PyMC3），计算P(new_default_rate < old_default_rate) > 0.95视为通过；
• 陷阱：曾因未排除“新用户冷启动”影响，导致Treatment组通过率虚高。解决方案：在SQL中添加WHERE user_register_days > 30过滤新用户；

验证阶段三：压力与对抗测试（Stress & Adversarial Testing）

• 压力测试：
  • 使用Locust模拟5000并发，请求体中user_age字段随机设为-1、999、NULL，验证服务是否返回400 Bad Request而非500；
  • 模拟特征缺失：在gRPC请求中故意不发送employment_status字段，验证fallback逻辑是否触发；
• 对抗测试：
  • 构造对抗样本：使用