企业官网建设流程全解析

简介：这份文档面向银行从业者、金融科技研究者及数字化转型负责人，系统梳理AI在银行业务中的落地路径与实践经验。内容围绕风险管理、客户服务、信贷管理与运营效率四大场景展开，涵盖大数据风控、智能客服、机器学习信贷审批等具体应用，并收录智能客服系统、信贷管理系统优化、运营效率提升三类典型实践案例，同时讨论数据安全、技术成熟度与人才培养等现实挑战及未来趋势。资源包内含1个docx文档，约59KB，目录结构完整，从技术概述、应用场景、实践案例到挑战对策与展望逐层展开，便于按模块查阅与引用。目前已有161人学习，适合需要了解AI赋能银行业务全貌、撰写方案或开展相关研究的读者参考借鉴。

1. 银行 AI 落地：从一份“随笔”里拆出的三条真实工程路径

一份名为“AI在银行业务中的应用与实践案例分享_随笔.docx”的文档，光看标题很容易被当成务虚的行业综述。但真正在一线做过银行 AI 项目的人会知道，这类随笔里藏着的往往是踩过坑之后才敢写的判断——哪些场景能上、哪些场景是伪需求、哪些模型上线三个月就被业务方弃用。银行 AI 的核心矛盾从来不是“模型不够强”，而是合规约束下的效果确定性：一笔信贷审批的误判可能带来监管问责，一次客服对话的答非所问可能触发客户投诉，这跟互联网场景里“先上线再迭代”的打法完全不同。这篇文章面向的是正在或准备把 AI 落到银行具体业务里的工程师和产品同学，我会按“场景选型 → 数据与特征 → 模型落地 → 避坑 → 进阶验证”的顺序，把智能客服、信贷风控、反欺诈这三个最常见方向的可复现路径讲清楚，参数怎么设、日志怎么看、翻车点在哪，都落到操作层面。

2. 银行 AI 场景选型：哪些业务值得先上模型

2.1 三类高价值场景的判定标准

银行里能塞 AI 的业务少说有几十个，但真正值得优先投入的，得同时满足三个条件：数据可获取且标注成本可控、错误代价可兜底、业务方有明确的效率痛点。按这个标准筛下来，智能客服工单分类、信贷申请的反欺诈评分、对公客户的流失预警是最先能跑出正向收益的。

智能客服工单分类的数据来自历史工单系统，标注就是工单的既有分类字段，几乎零额外标注成本；错误代价低，分错了人工坐席可以转派。信贷反欺诈评分的数据来自申请表单和征信报告，标注来自历史违约标签，错误代价中等但可以通过人工复核兜底。对公客户流失预警的数据来自交易流水和客户经理拜访记录，标注需要业务方配合打标，成本偏高，适合作为第二梯队。

相比之下，像“智能投顾推荐”这类场景，虽然技术上有意思，但合规审查周期长、错误代价极高（涉及投资建议责任），不适合作为银行 AI 的第一批落地项目。我一般会建议团队先用一个季度把工单分类跑通，拿到业务方的信任之后再往风控方向扩。

2.2 从业务指标反推技术指标

银行 AI 项目最容易翻车的地方是技术指标和业务指标脱节。模型 AUC 做到 0.92，业务方却觉得“没什么用”，因为业务方关心的是误杀率和漏杀率的平衡，而不是排序质量。

以信贷反欺诈为例，业务方的真实诉求通常是：在保持现有通过率不变的前提下，把坏账率降低 X 个基点。这就意味着技术指标要翻译成：在某个阈值下，召回率不低于多少、精确率不低于多少。实操中我会先跟业务方确认三个数：当前通过率、当前坏账率、可接受的最大通过率下降幅度。然后反推模型在对应阈值下的表现要求。

# 从业务约束反推模型阈值的技术指标要求 # 假设当前通过率 85%，坏账率 2.1%，可接受通过率最低 82% current_pass_rate = 0.85 current_bad_rate = 0.021 min_pass_rate = 0.82 # 反推：在通过率降到 82% 时，被拒绝的 3% 申请中需要捕获多少坏客户 # 才能让剩余通过客户的坏账率降到目标值 target_bad_rate = 0.018 # 目标坏账率 total_applicants = 100000 current_bad_count = total_applicants * current_bad_rate # 通过率 82% 时，通过客户数 new_pass_count = total_applicants * min_pass_rate # 要让坏账率降到 1.8%，允许的坏客户数 allowed_bad = new_pass_count * target_bad_rate # 需要拒绝掉的坏客户数 need_reject_bad = current_bad_count - allowed_bad # 被拒绝的总人数 rejected_total = total_applicants * (current_pass_rate - min_pass_rate) # 需要的召回率 required_recall = need_reject_bad / (total_applicants * current_bad_rate) print(f"需要召回率不低于: {required_recall:.2%}") print(f"被拒绝人群中坏客户占比需达到: {need_reject_bad/rejected_total:.2%}")

这段代码的逻辑是把业务方的通过率和坏账率约束翻译成模型在特定阈值下的召回率和精确率要求。参数说明：current_pass_rate和current_bad_rate从业务报表取，min_pass_rate是业务方能接受的最低通过率，target_bad_rate是风控部门给的目标值。跑出来如果 required_recall 超过 0.6，说明这个目标在当前数据条件下可能不现实，需要跟业务方重新对齐预期，而不是硬调模型。

2.3 场景优先级排序的实操表格

把候选场景按四个维度打分，每个维度 1-5 分，加权求和后排序。权重根据银行当前的战略重点调整，比如零售转型期会把“业务价值”权重调高。

这张表的用法是：先各自打分，再算加权分，优先做 3.5 分以上的场景。工单分类得分最高不是因为技术含量高，而是因为它的数据就绪度和错误代价两个维度几乎满分，能快速跑出结果建立信任。反欺诈评分业务价值最高但合规复杂度拉低了总分，适合作为第二个项目。

3. 数据准备与特征工程：银行数据的三个特殊处理

3.1 银行数据的脱敏与可用性平衡

银行数据不能直接拿来训练模型，这是常识。但实操中的难点在于：脱敏太狠会导致特征失效，脱敏太松又过不了合规审查。我见过一个团队把客户身份证号做了哈希，结果哈希后的值作为特征输入模型，模型直接学到了“哈希值尾号为 7 的客户违约率高”这种毫无业务意义的伪相关。

正确的做法是分层脱敏：标识类字段（姓名、身份证、手机号）直接移除或替换为不可逆的代理键，只用于关联不同表；数值类字段（年龄、收入、交易金额）保留原始值但做分箱处理；类别类字段（职业、地区）做粗粒度归并，比如把具体职业归并到“金融业”“制造业”等大类。

import pandas as pd import numpy as np from sklearn.preprocessing import KBinsDiscretizer def desensitize_bank_data(df): """ 银行数据分层脱敏 - 标识类：直接删除或替换为代理键 - 数值类：保留原始值，额外生成分箱特征 - 类别类：粗粒度归并 """ # 标识类字段直接删除（实际项目中应替换为代理键用于关联） id_cols = ['name', 'id_card', 'phone', 'address'] df = df.drop(columns=[c for c in id_cols if c in df.columns]) # 数值类字段：保留原始值，生成分箱特征 num_cols = ['age', 'income', 'loan_amount', 'transaction_amt'] for col in num_cols: if col in df.columns: # 等频分箱，箱数根据数据量调整，一般 5-10 箱 df[f'{col}_bin'] = pd.qcut(df[col], q=5, labels=False, duplicates='drop') # 类别类字段：粗粒度归并 if 'occupation' in df.columns: # 把具体职业归并到大类 occ_map = { '教师': '公共服务', '医生': '公共服务', '公务员': '公共服务', '工程师': '技术', '程序员': '技术', '设计师': '技术', '销售': '商业', '经理': '商业', '个体户': '商业' } df['occupation_group'] = df['occupation'].map(occ_map).fillna('其他') df = df.drop(columns=['occupation']) return df

这段代码的核心逻辑是分层处理：标识类字段直接删除，数值类字段保留原始值但额外生成分箱特征供模型选择，类别类字段做粗粒度归并。参数说明：q=5是分箱数量，数据量大时可以调到 10，数据量小就降到 3；duplicates='drop'处理分箱边界重复值的情况，银行数据里收入字段经常有大量重复值，不加这个参数会报错。注意分箱后的特征和原始特征同时保留，让模型自己选择用哪个，不要手动替模型做决定。

3.2 时序特征在信贷风控中的构造方法

信贷风控模型和普通分类模型最大的区别是：时序特征的质量直接决定模型上限。一个客户过去 6 个月的还款行为、额度使用率变化、查询次数趋势，比任何静态特征都更有预测力。

构造时序特征时，我一般会按三个时间窗口做聚合：近 1 个月、近 3 个月、近 6 个月。每个窗口内计算均值、最大值、标准差、趋势斜率。趋势斜率用线性回归的系数表示，反映指标是在恶化还是在改善。

def build_time_series_features(df, id_col, date_col, value_cols): """ 构造信贷时序特征 df: 包含客户ID、日期、数值列的明细数据 返回：每个客户一行，包含多窗口聚合特征 """ df[date_col] = pd.to_datetime(df[date_col]) max_date = df[date_col].max() windows = {'1m': 30, '3m': 90, '6m': 180} result = [] for cid, group in df.groupby(id_col): group = group.sort_values(date_col) row = {id_col: cid} for wname, days in windows.items(): cutoff = max_date - pd.Timedelta(days=days) sub = group[group[date_col] >= cutoff] for col in value_cols: if len(sub) == 0: row[f'{col}_{wname}_mean'] = np.nan row[f'{col}_{wname}_max'] = np.nan row[f'{col}_{wname}_std'] = np.nan row[f'{col}_{wname}_slope'] = np.nan continue vals = sub[col].values row[f'{col}_{wname}_mean'] = np.mean(vals) row[f'{col}_{wname}_max'] = np.max(vals) row[f'{col}_{wname}_std'] = np.std(vals) if len(vals) > 1 else 0 # 趋势斜率：用简单线性回归的系数 if len(vals) >= 3: x = np.arange(len(vals)) slope = np.polyfit(x, vals, 1)[0] row[f'{col}_{wname}_slope'] = slope else: row[f'{col}_{wname}_slope'] = 0 result.append(row) return pd.DataFrame(result)

逻辑说明：对每个客户，按 1 个月、3 个月、6 个月三个窗口分别计算均值、最大值、标准差和趋势斜率。参数说明：windows字典里的天数可以根据业务周期调整，信用卡场景可以用 30/60/90 天，房贷场景可以拉长到 90/180/360 天；slope用np.polyfit计算，数据点少于 3 个时置为 0，避免噪声。注意这段代码是逐客户循环的，数据量大时（百万级以上）需要改成向量化实现或 Spark 版本，否则跑一次要几个小时。

3.3 样本不平衡的处理：不要一上来就 SMOTE

信贷反欺诈场景里坏样本占比通常不到 1%，很多人第一反应是上 SMOTE 做过采样。但银行数据有个特点：坏样本之间的相似度很高，SMOTE 生成的合成样本很容易和真实坏样本几乎一样，导致模型过拟合。

我一般会按这个顺序试：先调 class_weight 让模型自己处理不平衡，如果效果不够再试欠采样（把好样本随机抽到坏样本的 3-5 倍），最后才考虑 SMOTE。而且用 SMOTE 的时候一定要在训练集上做，验证集和测试集保持原始分布，否则评估指标会严重虚高。

from imblearn.over_sampling import SMOTE from sklearn.model_selection import train_test_split from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_auc_score, average_precision_score # 假设 X, y 是特征和标签，y=1 表示坏客户 X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.3, stratify=y, random_state=42 ) # 方案一：class_weight 自动处理 model_1 = LogisticRegression(class_weight='balanced', max_iter=1000) model_1.fit(X_train, y_train) proba_1 = model_1.predict_proba(X_test)[:, 1] # 方案二：欠采样 from imblearn.under_sampling import RandomUnderSampler rus = RandomUnderSampler(sampling_strategy=0.25, random_state=42) X_under, y_under = rus.fit_resample(X_train, y_train) model_2 = LogisticRegression(max_iter=1000) model_2.fit(X_under, y_under) proba_2 = model_2.predict_proba(X_test)[:, 1] # 方案三：SMOTE（仅在训练集上） smote = SMOTE(sampling_strategy=0.3, random_state=42) X_smote, y_smote = smote.fit_resample(X_train, y_train) model_3 = LogisticRegression(max_iter=1000) model_3.fit(X_smote, y_smote) proba_3 = model_3.predict_proba(X_test)[:, 1] # 评估：AUC 和 AP（平均精确率） for name, proba in [('class_weight', proba_1), ('under', proba_2), ('smote', proba_3)]: auc = roc_auc_score(y_test, proba) ap = average_precision_score(y_test, proba) print(f"{name}: AUC={auc:.4f}, AP={ap:.4f}")

逻辑说明：三种方案在同一份训练集上对比，用 AUC 和 AP 两个指标评估。参数说明：sampling_strategy=0.25表示欠采样后坏样本与好样本的比例为 1:4，这个值一般设在 0.1 到 0.5 之间；SMOTE 的sampling_strategy=0.3同理。注意评估时一定要看 AP（平均精确率），因为 AUC 在不平衡数据上容易虚高，AP 更能反映模型在坏样本上的真实表现。如果 SMOTE 的 AP 明显低于 class_weight，说明合成样本引入了噪声，应该放弃 SMOTE。

4. 模型落地：从离线训练到线上推理的工程链路

4.1 模型选型：为什么银行场景偏爱逻辑回归和树模型

银行 AI 项目里，深度学习模型的使用比例远低于互联网公司。原因不是银行技术能力差，而是可解释性要求：监管机构要求银行能解释每一笔拒绝贷款的决策依据，一个 50 层的神经网络很难给出让人信服的解释。

实操中我一般会先用逻辑回归做基线，因为它的系数可以直接翻译成“收入每增加 1 万，违约概率下降 X%”这样的业务语言。然后用 XGBoost 或 LightGBM 做提升，这两个模型有成熟的 SHAP 值解释工具，能给出每个特征对单笔预测的贡献度。深度学习模型只在客服对话、文档识别这类非结构化场景里用。

import xgboost as xgb from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_auc_score import shap # 逻辑回归基线 lr = LogisticRegression(class_weight='balanced', max_iter=1000, C=0.1) lr.fit(X_train, y_train) lr_proba = lr.predict_proba(X_test)[:, 1] print(f"LR AUC: {roc_auc_score(y_test, lr_proba):.4f}") # XGBoost 提升 xgb_model = xgb.XGBClassifier( n_estimators=300, max_depth=5, learning_rate=0.05, subsample=0.8, colsample_bytree=0.8, scale_pos_weight=len(y_train[y_train==0]) / len(y_train[y_train==1]), eval_metric='auc', random_state=42 ) xgb_model.fit(X_train, y_train, eval_set=[(X_test, y_test)], verbose=False) xgb_proba = xgb_model.predict_proba(X_test)[:, 1] print(f"XGB AUC: {roc_auc_score(y_test, xgb_proba):.4f}") # SHAP 解释：看全局特征重要性和单笔预测解释 explainer = shap.TreeExplainer(xgb_model) shap_values = explainer.shap_values(X_test[:1000]) # 全局重要性 shap.summary_plot(shap_values, X_test[:1000], plot_type="bar") # 单笔解释（第 0 个样本） shap.force_plot(explainer.expected_value, shap_values[0], X_test.iloc[0])

逻辑说明：先跑逻辑回归基线，再用 XGBoost 提升，最后用 SHAP 做解释。参数说明：max_depth=5是银行风控场景的常用值，树太深容易过拟合且解释性变差；scale_pos_weight自动处理样本不平衡，值等于好样本数除以坏样本数；learning_rate=0.05配合n_estimators=300是比较稳的组合，学习率再低需要更多树，训练时间会拉长。注意 SHAP 计算在特征多的时候很慢，生产环境一般只对需要解释的样本（比如被拒绝的申请）做单笔解释，不做全量。

4.2 模型部署：批量和实时的两条路径

银行 AI 模型的部署方式取决于业务场景的时效要求。信贷审批的评分卡通常是批量部署：每天凌晨跑一次，把当天所有申请打分，第二天人工复核。反欺诈评分则需要实时部署：客户提交申请后 3 秒内返回结果，否则客户体验会崩。

批量部署用 Airflow 或类似的调度工具，把特征计算和模型推理串成 DAG，每天定时跑。实时部署用 Flask 或 FastAPI 包一个推理服务，前面挂 Redis 缓存特征，模型文件用 joblib 或 ONNX 加载。

# 实时推理服务示例（FastAPI） from fastapi import FastAPI from pydantic import BaseModel import joblib import numpy as np app = FastAPI() model = joblib.load('fraud_model.pkl') feature_names = joblib.load('feature_names.pkl') class Application(BaseModel): age: int income: float loan_amount: float transaction_amt_1m_mean: float transaction_amt_3m_slope: float # ... 其他特征 @app.post("/score") def score(app_data: Application): # 按训练时的特征顺序组装输入 features = np.array([[getattr(app_data, f) for f in feature_names]]) proba = model.predict_proba(features)[0, 1] # 按阈值返回决策 if proba > 0.8: decision = "reject" elif proba > 0.5: decision = "review" else: decision = "approve" return { "score": round(float(proba), 4), "decision": decision, "model_version": "v1.2" }

逻辑说明：FastAPI 服务加载模型和特征名列表，接收申请数据后组装成模型输入，返回评分和决策。参数说明：proba > 0.8拒绝、0.5-0.8转人工、< 0.5通过，这三个阈值需要根据业务方的通过率和坏账率约束来调，不是固定的。注意特征顺序必须和训练时完全一致，所以要把feature_names一起保存和加载，否则会出现“训练时用收入特征、推理时用年龄特征”这种低级错误。

4.3 模型监控：上线后看什么指标

模型上线不是终点，而是起点。银行场景里模型效果衰减的速度比互联网场景快，因为客群结构和宏观经济环境在变。我一般会监控三类指标：数据漂移、模型性能、业务指标。

数据漂移用 PSI（群体稳定性指数）监控，每个特征每周算一次，PSI 超过 0.2 就告警。模型性能用滚动窗口的 AUC 和 KS 监控，如果连续两周下降超过 5% 就要排查。业务指标看通过率、坏账率、人工复核率，这些指标的变化往往比模型指标更早反映问题。

def calculate_psi(expected, actual, buckets=10): """ 计算群体稳定性指数 PSI expected: 训练集上的特征分布 actual: 线上最近一周的特征分布 """ def scale_range(data, buckets): # 按分位数分桶 breakpoints = np.percentile(data, np.arange(0, 100, 100/buckets)) breakpoints = np.unique(breakpoints) return breakpoints breakpoints = scale_range(expected, buckets) expected_counts = np.histogram(expected, bins=breakpoints)[0] / len(expected) actual_counts = np.histogram(actual, bins=breakpoints)[0] / len(actual) # 避免除零 expected_counts = np.where(expected_counts == 0, 0.0001, expected_counts) actual_counts = np.where(actual_counts == 0, 0.0001, actual_counts) psi = np.sum((actual_counts - expected_counts) * np.log(actual_counts / expected_counts)) return psi # 对每个特征计算 PSI for col in feature_names: psi = calculate_psi(train_data[col].values, online_data[col].values) if psi > 0.2: print(f"警告：特征 {col} PSI={psi:.4f}，超过阈值")

逻辑说明：PSI 衡量训练集和线上数据的分布差异，值越大说明漂移越严重。参数说明：buckets=10是常用分桶数，数据量小的时候降到 5；PSI 阈值一般设 0.1 为轻微漂移、0.2 为显著漂移、0.5 为严重漂移。注意 PSI 对连续变量和类别变量都适用，但类别变量要先做编码。如果某个特征 PSI 持续偏高，说明这个特征的线上分布和训练时差异大，需要重新训练模型或调整特征处理逻辑。

5. 避坑指南：银行 AI 项目里最常见的五个翻车点

5.1 用未来数据训练模型导致离线指标虚高

现象：离线 AUC 做到 0.95，上线后实际效果只有 0.7 左右，业务方觉得被忽悠了。

原因：特征计算时用了未来信息。比如计算“客户近 6 个月平均交易额”时，把申请日之后的数据也算进去了。这种错误在离线评估时发现不了，因为训练集和测试集都有同样的泄漏。

解决：所有时序特征必须严格按“申请日之前”的时间窗口计算。实操中我会在特征计算代码里强制加一个as_of_date参数，所有聚合都只取date < as_of_date的数据。另外做一次时间穿越测试：用 2023 年 1 月的数据训练，预测 2023 年 6 月的申请，如果 AUC 比随机猜好不了多少，说明特征泄漏严重。

5.2 模型阈值直接沿用训练时的默认值

现象：模型输出的概率分布和训练时不一致，导致按 0.5 阈值做决策时通过率暴跌。

原因：训练时的正负样本比例和线上真实比例不同。训练时可能做了欠采样，坏样本占比 20%，线上坏样本只有 1%，模型输出的概率整体偏高。

解决：上线前必须做概率校准。常用方法是 Platt Scaling 或 Isotonic Regression，用一份未采样的验证集拟合校准参数。校准后再按业务约束选阈值，而不是拍脑袋定 0.5。

from sklearn.calibration import CalibratedClassifierCV # 用未采样的验证集做概率校准 calibrated_model = CalibratedClassifierCV( xgb_model, method='isotonic', cv='prefit' ) calibrated_model.fit(X_calib, y_calib) # X_calib 是未采样的验证集 # 校准后的概率 calibrated_proba = calibrated_model.predict_proba(X_test)[:, 1]

逻辑说明：CalibratedClassifierCV用保序回归（isotonic）拟合原始概率到真实概率的映射。参数说明：cv='prefit'表示模型已经训练好，只做校准；X_calib必须是从未参与训练且未做采样的数据，否则校准会失效。注意校准后的概率才是真实的违约概率，可以直接用于业务决策。

5.3 特征上线时顺序错乱导致推理结果异常

现象：模型在测试环境表现正常，上线后所有申请的评分都集中在 0.5 附近，区分度几乎为零。

原因：训练时特征顺序是[age, income, loan_amount, ...]，推理时组装成了[income, age, loan_amount, ...]，模型把年龄当收入算，结果全乱套。

解决：把特征名列表和模型一起保存，推理时按名字取值而不是按位置。另外在推理服务里加一个断言，检查输入特征的数量和顺序是否和训练时一致。

5.4 忽略监管对可解释性的要求导致项目被叫停

现象：模型效果很好，但合规部门要求解释每一笔拒绝决策的依据，团队拿不出来，项目被暂停。

原因：用了黑盒模型且没有做解释性分析。银行监管要求“对客户不利的决策必须可解释”，这是硬性要求。

解决：优先选逻辑回归或树模型，如果必须用复杂模型，一定要配套 SHAP 或 LIME 解释工具。而且解释结果要能翻译成业务语言，不能只给特征贡献度数值。实操中我会让风控业务方参与解释模板的设计，确保“收入偏低导致评分下降”这种表述符合他们的沟通习惯。

5.5 模型更新频率跟不上业务变化

现象：模型上线三个月后效果明显下降，但重新训练的流程要走两周，业务方等不及。

原因：没有建立自动化的模型重训和部署流水线，每次更新都靠人工操作。

解决：把特征计算、模型训练、评估、部署串成自动化流水线。触发条件可以是定时的（每周一次），也可以是事件驱动的（PSI 超过阈值自动触发）。重训后的模型先跑一段时间的影子模式，和线上模型并行打分，对比效果后再切换。

6. 进阶验证：用影子模式和 A/B 测试确认模型真实价值

模型上线前的离线指标再好看，也不能完全代表线上效果。银行场景里我一般会用影子模式做第一轮验证：新模型和线上模型并行跑，新模型的打分只记录不生效，跑两周后对比两个模型的评分差异和实际业务表现。影子模式的好处是零风险，坏处是只能验证评分质量，不能验证业务影响。

影子模式通过后再上 A/B 测试：把流量随机分成两组，一组用老模型，一组用新模型，对比通过率、坏账率、人工复核率等业务指标。A/B 测试的样本量要算够，银行信贷场景里坏样本少，通常需要跑一个月以上才能拿到统计显著的结果。

# A/B 测试样本量计算 from statsmodels.stats.power import zt_ind_solve_power from statsmodels.stats.proportion import proportion_effectsize # 假设老模型坏账率 2.1%，新模型预期降到 1.8% # 显著性水平 0.05，统计功效 0.8 p1 = 0.021 p2 = 0.018 effect_size = proportion_effectsize(p1, p2) # 计算每组需要的样本量 sample_size = zt_ind_solve_power( effect_size=effect_size, alpha=0.05, power=0.8, ratio=1.0, alternative='two-sided' ) print(f"每组需要样本量: {int(sample_size)}") # 按日均申请量反推需要跑多少天 daily_applications = 5000 days_needed = sample_size * 2 / daily_applications print(f"需要跑 {days_needed:.1f} 天")

逻辑说明：用统计功效分析计算 A/B 测试所需的最小样本量。参数说明：p1和p2是预期的新老模型坏账率，alpha=0.05是显著性水平，power=0.8是统计功效。注意这个计算假设坏账率是独立同分布的，实际中客户之间可能有相关性，需要的样本量会更大。如果算出来需要跑 60 天以上，说明这个业务指标的提升幅度太小，不值得做 A/B 测试，应该先优化模型或换一个提升空间更大的场景。

我自己的习惯是：任何模型上线前，先跑两周影子模式，再跑一个月 A/B 测试，两个都通过了才全量。这个过程很慢，但银行场景里“慢就是快”，一次翻车可能让整个 AI 团队失去业务方的信任，后面再想推新项目就难了。希望帮到你。

本文还有配套的精品资源，点击获取