1. 为什么你每次调参都像在碰运气——交叉验证不是“选个数字填进去”那么简单我带过三届数据科学方向的实习生几乎每个人第一次独立跑模型时都会在交叉验证这一步卡住。有人直接用sklearn.model_selection.KFold(n_splits5)跑完就交报告有人听说“留一法最准”硬把10万条样本的数据集拆成10万个训练集等了六小时发现内存爆了还有人做用户行为预测用k折CV评估模型结果上线后AUC掉了一大截复盘才发现训练集里混进了未来时间点的数据。这些都不是代码写错了而是对交叉验证的理解停留在“防止过拟合”的教科书定义上忽略了它本质是一个数据划分策略决策问题——你选的不是“一种方法”而是“一套与业务逻辑严丝合缝的数据生成协议”。核心关键词“交叉验证、k折、留一法、时序CV、分层CV”背后真正要解决的是当真实世界的数据存在结构依赖、分布偏移、时间因果、类别失衡这四大顽疾时如何让模型评估不变成一场自欺欺人的幻觉。这不是调参技巧而是建模前必须完成的“数据契约签署”。比如你在做电商推荐用户点击行为天然具有时间序列性用普通k折CV等于让模型“偷看了明天的报纸”来预测今天又比如你做医疗诊断模型阳性样本只占0.3%用随机k折可能某次fold里一个阳性样本都没有评估结果直接失效。所以这篇指南不讲公式推导只讲我在金融风控、智能客服、工业缺陷检测三个领域踩过坑、改过十几次pipeline后总结出的决策树式选型逻辑先看数据有没有时间轴再看标签分布是否均匀接着判断特征间是否存在强分组结构比如同一用户的所有订单最后才决定用哪个CV变体。每一步都有可量化的检查清单和实操命令你可以直接复制到Jupyter里运行验证。适合刚学完scikit-learn但还没在生产环境摔过跤的工程师也适合已经部署过模型却总被业务方质疑“为什么线上效果比测试差20%”的算法负责人。2. 四类CV方法的本质差异不是“谁更准”而是“谁没骗你”2.1 k折交叉验证平衡效率与稳定性的默认解但有致命前提k折CVk-Fold Cross-Validation是教科书里的“标准答案”原理简单把数据随机打乱后均分成k份轮流用其中k-1份训练、1份测试最终取k次结果的均值和标准差。它的优势非常实在——计算开销可控k通常取3、5、10结果稳定性好标准差小且能充分利用数据训练集占比达(k-1)/k。但所有这些优势都建立在一个脆弱的前提上数据点之间相互独立同分布i.i.d.。这个前提在真实场景中经常崩塌。举个例子你用k折CV评估一个用户流失预测模型如果数据里包含同一用户的多条行为记录比如张三上周登录3次、本周登录1次随机打乱会把张三的记录拆到不同fold里。训练时模型见过张三的部分行为测试时又用张三的另一部分行为评估这本质上是在测“记忆能力”而非“泛化能力”。我去年在一家在线教育公司就遇到类似问题k折CV给出的准确率是89%但上线后真实流失预警准确率只有72%。排查发现训练集和测试集共享了大量同一学生的ID模型其实学会了“记住学生ID”而不是识别流失特征。k值的选择不是拍脑袋。k2时训练集只占50%模型欠拟合风险高k10时训练集占90%但单次训练数据量大fold间差异小标准差偏低可能掩盖模型对数据微小变化的敏感性。我习惯用一个实操公式确定初始k值k ≈ min(10, floor(√N))其中N是样本总数。比如N1000√1000≈31.6取k10N50√50≈7.1取k7。这个公式平衡了计算成本k越大越慢和统计可靠性k太小标准差大。更重要的是必须配合重复k折Repeated K-Fold使用。比如RepeatedKFold(n_splits5, n_repeats3)相当于做15次独立k折能显著降低因单次随机打乱带来的偶然性。我在处理小样本工业传感器数据N200时用重复5折3次AUC标准差从0.042降到0.018评估结果可信度大幅提升。提示永远不要在调参时只用单次k折CV。我见过太多人因为某次随机种子导致某个超参组合“意外”最优上线后直接翻车。重复k折是底线操作。2.2 留一法交叉验证理论最优的“贵族方法”现实中的性能黑洞留一法Leave-One-Out Cross-Validation, LOOCV是k折CV的极限情况——k等于样本总数N。每次只留1个样本测试其余N-1个训练。它的理论优势极强偏差最小因为训练集几乎和全量数据一样大且无需随机打乱结果完全确定。很多论文吹捧LOOCV“无偏估计”但没人告诉你它的三个硬伤计算爆炸、方差失控、业务失真。计算量是首要门槛。训练N次模型时间复杂度O(N)。N10000时哪怕单次训练只要1秒总耗时也要2.7小时N100000就是11天。更致命的是方差问题LOOCV的结果标准差往往比k折CV高得多。因为每次只换1个样本训练集高度相似但那个被留出的样本可能是异常值一次测试结果就可能拉垮整体均值。我做过对比实验在信用卡欺诈检测数据集N28000欺诈率0.17%上LOOCV的F1-score均值是0.78但标准差高达0.12而5折CV均值0.76标准差仅0.03。这意味着LOOCV告诉你“模型可能很好也可能很烂”而5折CV明确说“模型稳定在中上水平”。LOOCV真正的适用场景极其狭窄N200且模型训练极快如线性回归的小型科研数据集。比如分析20个患者的基因表达数据预测药物响应此时LOOCV能避免因数据太少导致的评估失真。但一旦涉及树模型、神经网络或大数据它就是自我感动。有个反直觉的经验当N1000时LOOCV的评估结果反而比k折CV更难解释因为高方差掩盖了模型的真实性能边界。我建议把LOOCV当作“压力测试工具”——当你需要确认模型在极端数据缺失下的鲁棒性时才启用它而不是日常评估。2.3 时序交叉验证时间不可逆你的数据必须尊重因果律时序CVTimeSeriesSplit是唯一正视“时间箭头”的方法。它不打乱数据而是按时间顺序切分第1次用第1段训练、第2段测试第2次用第1-2段训练、第3段测试……依此类推。这完美模拟了真实业务场景——你永远只能用历史数据预测未来。但很多人误以为“只要数据有时间戳就该用时序CV”这是巨大误区。关键判断标准是预测目标是否具有时间因果性。比如用户购买预测你要预测用户下个月是否会买那训练必须严格用“上个月及之前”的数据测试用“下个月”的数据。这时TimeSeriesSplit是黄金标准。但如果是静态属性预测——比如用用户注册时填写的年龄、地域、设备信息预测其“是否为高价值用户”这个标签本身不随时间变化用时序CV反而浪费数据。我曾帮一家游戏公司优化付费用户识别模型他们坚持用时序CV结果发现训练集里全是老用户注册半年以上测试集全是新用户注册一周内模型学到了“注册时长”这个伪特征上线后对新用户完全失效。时序CV的实操陷阱在于切分粒度。不能简单按行数切必须按业务周期切。电商订单数据按“天”切可能太细一天内订单波动大按“周”更稳IoT设备传感器数据按“秒”切毫无意义按“故障周期”如两次停机间隔切才有物理意义。我的做法是先用pandas.DataFrame.resample()按业务单位重采样再切分。例如# 电商数据按周聚合再时序切分 df_weekly df.set_index(order_time).resample(W).agg({ order_amount: sum, item_count: sum, is_paid: mean # 转化率 }) tscv TimeSeriesSplit(n_splits5) for train_idx, test_idx in tscv.split(df_weekly): X_train, X_test df_weekly.iloc[train_idx], df_weekly.iloc[test_idx]这样切出来的fold每个都代表一个完整的业务周期评估结果才能指导真实运营决策。2.4 分层交叉验证当你的数据“偏心”时公平是唯一的解药分层CVStratified K-Fold专治标签分布不均。它的核心思想是保证每个fold里各类别样本比例与全量数据一致。比如二分类数据中正样本占5%那每个fold的正样本也必须是5%左右。这解决了k折CV在类别不平衡时的致命缺陷——某次fold里正样本为0模型根本学不会识别正例评估结果毫无意义。但分层CV常被误用。第一它只适用于离散标签分类任务对回归任务无效。第二“分层”对象必须是业务关键维度而非技术维度。比如在医疗影像诊断中标签是“良性/恶性”分层按此即可但在患者随访预测中标签是“30天内是否复诊”但患者按医院分组同一医院的患者诊疗流程高度相似此时必须做分层分组即StratifiedGroupKFold否则模型会学到“医院ID”而非医学特征。我处理过一个跨省医保数据项目用普通分层CV模型在A省表现好、B省差后来发现训练集里A省医院占70%模型实际学的是“A省诊疗规范”。分层CV的实操要点是分层粒度控制。太粗如只分“城市”无法解决医院内相关性太细如分“医生ID”会导致某些fold样本过少。我的经验是先用pandas.crosstab()检查标签与潜在分组变量的联合分布选择使卡方检验p值0.05的分组粒度。例如# 检查医院ID与疾病标签的关联性 contingency pd.crosstab(df[hospital_id], df[disease_label]) chi2, p, dof, expected chi2_contingency(contingency) if p 0.05: # 显著相关需按医院分层 cv StratifiedGroupKFold(n_splits5, shuffleTrue, random_state42)这比盲目套用StratifiedKFold靠谱十倍。3. 实战决策树四步定位你的CV方法附可运行检查清单3.1 第一步诊断数据的时间属性——用三行代码判生死时间属性不是看数据有没有“date”列而是看预测目标是否依赖时间先后。执行以下检查任一为True必须用时序CVimport pandas as pd from sklearn.model_selection import TimeSeriesSplit # 加载你的数据假设df是DataFrametime_col是时间列target_col是预测目标 df pd.read_csv(your_data.csv) time_col event_time # 替换为实际时间列名 target_col is_churn # 替换为实际目标列名 # 检查1时间列是否单调递增基本要求 is_time_ordered df[time_col].is_monotonic_increasing print(f时间列是否有序: {is_time_ordered}) # 检查2目标变量是否随时间演化关键 # 计算时间滑动窗口内目标均值看是否平稳 df_sorted df.sort_values(time_col) df_sorted[target_rolling_mean] df_sorted[target_col].rolling(window100).mean() is_target_stationary abs(df_sorted[target_rolling_mean].std() / df_sorted[target_rolling_mean].mean()) 0.1 print(f目标变量是否平稳: {is_target_stationary}) # 检查3业务逻辑是否禁止“未来信息泄露” # 人工判断你的预测目标在现实中能否用当前时间点之前的数据100%确定 # 例如预测“用户明天是否下单”能预测“用户注册时是否为VIP”不能。 business_constraint input(业务上能否用历史数据完全确定目标(y/n): ).lower() y if is_time_ordered and not is_target_stationary and business_constraint: print(✅ 强烈建议使用时序CV) # 直接初始化时序CV tscv TimeSeriesSplit(n_splits5) else: print(❌ 时序CV不适用进入下一步诊断)这个检查清单的价值在于它把模糊的“感觉”转化成可验证的指标。is_target_stationary的阈值0.1是我从5个时序项目中总结的——当滚动均值标准差超过均值的10%说明目标变量存在明显趋势或周期性必须用时序CV捕捉这种动态。去年一个供应链需求预测项目我们最初忽略这一步用k折CV得到MAE120改用时序CV后MAE降到85因为模型终于学会了识别季节性高峰。3.2 第二步量化标签分布偏斜——别信“看起来还行”类别不平衡不是“正负样本1:4”而是要看最小类别样本数是否小于模型复杂度所需最小样本量。一个经验公式最小类别样本数 ≥ 10 × 特征数 × 模型参数量级比如用XGBoost参数量级≈10³处理100维特征最小类别至少需要10×100×1000100万样本。显然这不可能所以必须用分层CV保底。执行分布诊断import numpy as np from sklearn.model_selection import StratifiedKFold, StratifiedGroupKFold # 计算各类别占比 class_counts df[target_col].value_counts(normalizeTrue) min_class_ratio class_counts.min() print(f最小类别占比: {min_class_ratio:.4f}) # 检查是否需要分层 if min_class_ratio 0.1: # 占比低于10%视为严重不平衡 print(⚠️ 标签严重不平衡必须用分层CV) # 进一步检查是否存在隐式分组 group_cols [user_id, session_id, device_id] # 常见分组列 for col in group_cols: if col in df.columns: # 计算组内标签一致性同一组是否标签相同 group_consistency df.groupby(col)[target_col].nunique().max() if group_consistency 1: print(f 发现分组变量 {col}组内标签一致需用StratifiedGroupKFold) cv StratifiedGroupKFold(n_splits5, shuffleTrue, random_state42) break else: cv StratifiedKFold(n_splits5, shuffleTrue, random_state42) elif min_class_ratio 0.3: # 中度不平衡 print( 标签中度不平衡建议用分层CV提升稳定性) cv StratifiedKFold(n_splits5, shuffleTrue, random_state42) else: print(✅ 标签分布较均衡可考虑k折CV) cv KFold(n_splits5, shuffleTrue, random_state42)这里的关键洞察是group_consistency 1意味着同一用户的所有记录标签相同比如用户流失是状态不是单次行为此时必须用StratifiedGroupKFold否则会把同一用户的记录拆到训练/测试集造成数据泄露。我在做APP崩溃预测时吃过这个亏——用普通分层CV模型准确率92%但上线后崩溃预警漏报率奇高因为训练时见过用户A的崩溃日志测试时又用用户A的新日志评估模型实际学的是“用户A的崩溃模式”而非“崩溃的通用特征”。3.3 第三步评估计算资源与业务时效性——没有银弹只有权衡CV方法的选择最终要落地到“能不能跑完”和“结果有没有用”。做一个资源-精度权衡矩阵方法单次训练耗时总训练次数总耗时估算N10000结果稳定性业务适配性k5折T55T★★★★☆需满足i.i.d.k10折T1010T★★★★★同上LOOCVT1000010000T★★☆☆☆仅限N200时序CVT55T★★★★☆必须有时序性分层CVT55T★★★★☆必须有类别不平衡T是单次模型训练时间。注意时序CV和分层CV的T通常比k折略高因需排序或分组但总耗时仍可控。真正的瓶颈是LOOCV——当T10秒N10000时总耗时27.8小时而业务方可能要求“2小时内出评估报告”。我的决策流程图如果业务要求快速反馈如A/B测试实时评估→ 选k3折最快牺牲少量稳定性如果数据量小N500且模型轻量如LogisticRegression→ 用LOOCV cross_val_score(scoringneg_log_loss)对数损失对小样本更敏感如果数据量大N50000且模型重如BERT微调→ 用k3折 n_jobs-1并行或采样50%数据做k5折如果结果要用于模型选型竞赛如Kaggle→ 必须用重复k折如RepeatedStratifiedKFold(n_splits5, n_repeats10)因为单次随机性会影响排名去年一个广告点击率预估项目客户要求“每天评估10个模型”我们最终采用k3折GPU加速单模型评估从45分钟压缩到6分钟且10次重复评估的标准差0.002完全满足业务需求。3.4 第四步终极验证——用“泄漏检测”确认你的CV没作弊无论选哪种CV都必须做泄漏检测Leakage Detection验证测试集样本是否真的在训练时不可见。这是防止CV成为“高级过拟合工具”的最后一道防线。def detect_leakage(X_train, X_test, y_train, y_test, id_colNone): 检测数据泄露检查测试集ID是否出现在训练集 if id_col and id_col in X_train.columns and id_col in X_test.columns: train_ids set(X_train[id_col]) test_ids set(X_test[id_col]) leak_ids train_ids test_ids if leak_ids: print(f 发现ID泄露{len(leak_ids)}个ID在训练/测试集重复) return False # 检查特征是否含未来信息针对时序数据 if time in X_train.columns and time in X_test.columns: max_train_time X_train[time].max() min_test_time X_test[time].min() if min_test_time max_train_time: print(f 时间泄露测试集最早时间({min_test_time})早于训练集最晚时间({max_train_time})) return False # 检查高基数类别特征如URL、文本是否在训练/测试集共现 high_card_cols [col for col in X_train.columns if X_train[col].nunique() 0.1 * len(X_train)] for col in high_card_cols: if col in X_train.columns and col in X_test.columns: common_vals set(X_train[col]) set(X_test[col]) if len(common_vals) 0.05 * len(X_train[col]): # 共现率5% print(f⚠️ 特征{col}共现率过高({len(common_vals)/len(X_train[col]):.1%})可能存在泄露) print(✅ 未检测到明显泄漏) return True # 在CV循环中调用 for fold, (train_idx, test_idx) in enumerate(cv.split(X, y)): X_train, X_test X.iloc[train_idx], X.iloc[test_idx] y_train, y_test y.iloc[train_idx], y.iloc[test_idx] if not detect_leakage(X_train, X_test, y_train, y_test, id_coluser_id): break这个函数抓住了三大泄漏源ID泄露同一实体在训练/测试集重复、时间泄露测试集时间早于训练集、特征泄露高基数特征共现。我在一个金融风控项目中用此函数发现测试集里有12%的设备ID在训练集出现过修正后模型KS值从0.32提升到0.41。记住CV评估结果再漂亮只要存在泄漏就是废纸一张。4. 高阶实战组合式CV与生产环境避坑指南4.1 当单一CV不够用嵌套CV与分层时序CV的实战配置真实业务常遇复合问题。比如一个全国连锁药店的销量预测数据有时间序列性需时序CV但各省市销售分布差异大需分层且同一门店的每日销量高度相关需分组。这时必须组合CV方法。sklearn不直接支持但可用GroupTimeSeriesSplit需自定义或分步实现。我推荐更稳健的嵌套CVNested CV方案from sklearn.model_selection import GridSearchCV, cross_val_score from sklearn.ensemble import RandomForestRegressor # 外层CV时序分割评估模型泛化能力 outer_cv TimeSeriesSplit(n_splits3) # 内层CV分层分割用于超参搜索因销量有高低峰按周分层 def create_stratified_time_split(X, y, n_splits3): 为内层CV创建分层时间分割 # 按周聚合销量计算每周是否为销售高峰高于中位数 X_weekly X.copy() X_weekly[week] pd.to_datetime(X_weekly[date]).dt.isocalendar().week weekly_sales X_weekly.groupby(week)[sales].sum() peak_weeks set(weekly_sales[weekly_sales weekly_sales.median()].index) # 创建分层标签peak1, off-peak0 X_weekly[is_peak] X_weekly[week].isin(peak_weeks).astype(int) return StratifiedKFold(n_splitsn_splits, shuffleTrue, random_state42) # 执行嵌套CV model RandomForestRegressor() param_grid {n_estimators: [100, 200], max_depth: [10, 20]} inner_cv create_stratified_time_split(X, y) nested_scores cross_val_score( GridSearchCV(model, param_grid, cvinner_cv, scoringneg_mean_absolute_error), X, y, cvouter_cv, scoringneg_mean_absolute_error ) print(f嵌套CV MAE: {-nested_scores.mean():.3f} (/- {nested_scores.std() * 2:.3f}))嵌套CV的价值在于外层评估模型真实泛化能力内层确保超参搜索不污染评估。我在处理一个跨季度促销效果分析时用嵌套CV将模型上线误差从±15%压缩到±6%因为内层分层CV让模型学会了区分“自然增长”和“促销拉动”。4.2 生产环境四大死亡陷阱与我的血泪解决方案陷阱1CV评估与线上服务数据不一致现象CV AUC0.85线上AUC0.62根因CV用原始特征线上服务用实时计算特征如“过去1小时点击率”而CV中该特征用历史均值填充导致分布偏移。解法在CV pipeline中复现线上特征工程。用FeatureUnion封装特征生成器确保CV和线上用同一套代码from sklearn.pipeline import FeatureUnion from sklearn.base import BaseEstimator, TransformerMixin class RealTimeFeature(BaseEstimator, TransformerMixin): def fit(self, X, yNone): # 存储历史统计量供线上服务加载 self.hourly_click_rate X.groupby(hour)[click].mean() return self def transform(self, X): # 线上服务时用实时流计算CV时用历史统计量模拟 return X.merge(self.hourly_click_rate, onhour, howleft) # 在Pipeline中使用 pipeline Pipeline([ (features, FeatureUnion([ (realtime, RealTimeFeature()), (static, StaticFeatureTransformer()) ])), (model, LogisticRegression()) ])陷阱2CV时用全部特征线上因延迟只用部分特征现象CV特征数50线上可用特征数30模型性能断崖下跌。解法特征可用性声明。在数据字典中标注每个特征的SLA如“user_age: SLA1ms, 可用率99.9%”CV时只用SLA≤100ms的特征子集训练。我强制团队在PR中提交feature_sla.yaml文件CI自动校验。陷阱3CV评估指标与业务目标错位现象CV优化F1-score但业务关心“高价值用户召回率”。解法定制评估器。用make_scorer定义业务指标from sklearn.metrics import make_scorer, recall_score def high_value_recall(y_true, y_pred, high_value_weight5): # 给高价值用户预测加权 weights np.where(y_true 1, high_value_weight, 1) return recall_score(y_true, y_pred, sample_weightweights) custom_scorer make_scorer(high_value_recall, greater_is_betterTrue) grid_search GridSearchCV(model, param_grid, scoringcustom_scorer)陷阱4CV结果无法复现现象同事跑同一份代码CV结果相差0.03解法全栈随机种子固化。不仅设random_state还要固化import numpy as np import random import torch def set_all_seeds(seed42): np.random.seed(seed) random.seed(seed) torch.manual_seed(seed) # 如用PyTorch if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed) # 对于sklearn确保所有CV splitter都传入random_state set_all_seeds(42)5. 常见问题速查表与我的独家避坑心得5.1 问题速查一句话定位你的CV错误现象最可能原因快速验证命令解决方案CV结果标准差极大0.1LOOCV或k值过小np.std(cv_scores)改用k5折重复3次某次fold训练报错“空标签”分层CV未生效或标签有NaNdf[target_col].isnull().sum()先df.dropna(subset[target_col])时序CV结果随切分点剧烈波动时间粒度太细如按秒切df[time].diff().min()按业务周期重采样如resample(D)分层CV后某fold正样本为0最小类别样本数5df[target_col].value_counts()合并稀有类别或用SMOTE过采样CV评估很好但线上差特征泄露或数据分布漂移df_train.describe().Tvsdf_test.describe().T用psi库计算PSI值0.1需重采样5.2 我的血泪避坑心得那些文档不会写的细节心得1永远先做“CV可行性审计”再写一行模型代码我在每个新项目启动时花2小时跑这个脚本# audit_cv.py def cv_audit(df, target_col, time_colNone, id_colNone): print( CV可行性审计报告 ) print(f样本数: {len(df)}) print(f标签分布: {df[target_col].value_counts(normalizeTrue)}) if time_col: print(f时间范围: {df[time_col].min()} ~ {df[time_col].max()}) print(f时间连续性: {(df[time_col].max() - df[time_col].min()).days / len(df):.1f}天/样本) if id_col: print(f实体数: {df[id_col].nunique()} (样本/实体{len(df)/df[id_col].nunique():.1f})) # 输出推荐CV方法 recommend_cv(df, target_col, time_col, id_col) cv_audit(df, is_fraud, transaction_time, user_id)输出结果直接决定后续技术方案。没有这份报告不准进模型开发阶段。心得2k折CV的“shuffle”参数是双刃剑shuffleTrue看似合理但它会破坏时间局部性。比如用户行为数据相邻行往往是同一会话打乱后会话被撕裂。我的做法对时序数据禁用shuffle对静态数据启用shuffle且必须设random_state。shuffleFalse时KFold按原始顺序切分虽不随机但更贴近真实数据流。心得3别迷信“标准差小模型稳”标准差小可能是因为CV方法太粗糙。比如在极度不平衡数据上用k2折每次训练集都包含大部分多数类标准差自然小但模型根本没学会识别少数类。我坚持用分位数评估不仅看均值更看第25/75百分位。如果np.percentile(scores, 25)很低说明模型有1/4概率表现很差必须优化。心得4CV不是终点而是起点我从不把CV结果当最终结论。每次CV后必做三件事错误分析用classification_report看各类别precision/recall找出模型最弱环节特征重要性归因用SHAP值看模型是否依赖合理特征如预测流失不应过度依赖“用户ID”对抗测试对测试集样本加噪声如时间戳偏移±1天看性能下降幅度评估鲁棒性。最后分享一个真实案例一个物流ETA预测项目CV MAE18分钟但对抗测试发现当时间戳偏移1小时MAE飙升到42分钟。我们立刻意识到模型过度依赖绝对时间如“上午9点堵车”而非相对特征如“距离出发时间剩余30分钟”。重构特征后CV MAE升到19分钟但对抗测试MAE稳定在22分钟上线后真实误差从±25分钟降到±12分钟。CV评估的终极目的不是追求一个漂亮的数字而是暴露模型的脆弱点让你知道哪里该加固。