DeepSeek重塑银行存款产品定价：从FTP到结构优化的完整方案-开发者社区

简介：这是一份聚焦银行业存款产品定价与结构优化的DeepSeek技术方案文档，适合银行零售/资产负债管理、金融数据分析及AI应用人员。PDF版全文503页，共61个大章节，支持目录章节跳转与书签大纲，便于按需翻阅。资源仅1个PDF文件，压缩包约15.98MB，内容完整，文字、图表、目录均正常显示。已有98人浏览学习。文档从客户需求响应分析出发，系统讲解数据采集体系、非结构化特征工程、文本分词与语义标注、标签体系构建；同时覆盖市场竞争态势感知中的数据源接入、竞品信息结构化提取、利率时序特征与情感倾向分析；资金流动分析部分阐述时序模式识别、异常值检测与趋势预测特征构建；期限偏好部分则包含业务特征映射、数据集划分验证与客户画像关联挖掘。整体上是一套覆盖数据分析全流程的参考方案，可辅助读者搭建类似预测技术框架。

1. 现在讨论度很高的DeepSeek银行存款产品定价与存款结构优化方案，解决的核心问题可以浓缩成一句话：存款利率不是拍出来的，而是从客户、对手和资金流三层信息里算出来的。这个领域过去太依赖经验，分支行把竞品报价拍个照、问个话，总行参照着加几个基点就下发，一旦利率频繁波动和存款搬家，这套打法就失灵：有人报整年挂牌价，有人把礼品折成收益率，口径不统一；更麻烦的是没人能回答“这个价格到底吸来多少存款、会不会拉长期限、付息率扛不扛得住”。这套503页的方案把客户需求响应、市场竞争态势感知、资金流动分析和期限偏好预测串成一个每周可更新的闭环，DeepSeek在这里不是替代定价模型，而是把非结构化的市场信息、客户反馈变成模型能直接消费的参数。适合正在做负债端精细化定价、被付息率和流动性考核压着的团队，也适合想让大模型落在核心经营指标而不是当问答助手的算法工程师。

2. 拆开存款产品定价：从FTP到结构优化，方案里的模型到底怎么运转

2.1 定价公式的底子：FTP、挂牌价和付息率三者为什么总打架

银行的钱从负债端进来，到资产端出去，中间有个内部资金转移定价，也就是FTP。存款产品的对外挂牌价、行内资金买断价、账上实际支付的付息率，这三层经常不在一个节拍上。我见过最典型的场景：FTP给一年期2.0%，挂牌价1.95%，客户经理发现做一年期的价差最肥，于是拼命推一年期，活期沉淀被一点点搬到定期，半年后付息率曲线抬升，流动性报表却越来越短。单看任何一个口径，都觉得价格是合理的，合在一起就互相打架。

所以存款结构优化的第一个任务不是把某款产品利率定高或定低，而是把三层口径对齐。方案里通常的做法是划一个利率走廊：FTP作为内部基准，对外挂牌价只能在走廊内浮动，付息率作为最终检验指标。走廊的上下限不是拍出来的，而是由客户需求响应弹性、市场竞争分位数和资金流动性三组数据算出来的。这也是为什么技术方案要从三个维度做数据输入，而不是单独做一张定价表。

有人会问，FTP是资产负债部定的，挂牌价是产品部定的，为什么要放在存款结构优化方案里一起谈？因为结构问题的本质是各期限、各产品之间在抢客户。FTP如果对长期产品的补贴过重，产品部就有动力多发长期存单，客户也会被教育成“等利率高的时候再锁定”，久而久之活期占比塌方，存款结构的流动性指标变差。定价方案如果只管挂牌价，不管FTP和期限结构，最后就会陷入“所有产品都在降价、付息率还在涨”的怪圈。实际操作中，我一般会要求先做一张“三层差异表”，按产品、期限、客群列出FTP价、挂牌价、实际付息率，差异超过20bp的列入重点治理。这张表跑出来以后，很多团队第一反应是“我们居然有这么多产品在倒挂”，定价方案里说倒挂不是小问题，它意味着每做一笔都在消耗资本金。

2.2 模型路径：从价格弹性测算到结构成本的传导链条

定价模型的核心是一个被反复讨论的需求函数：利率变化了，客户愿意存进来的钱会变化多少。教科书会说价格弹性，实务里没那么优雅，真实业务里利率每上浮10个基点，存款增量可能是50万也可能是500万，差别取决于客群、渠道、竞品距离和季节性。传统做法是拿历史量价数据做回归，但历史的“价”是当时的挂牌价，记在台账里，“量”却受到非常多同时变动的因素干扰，回归出来经常是个不显著的系数。

新的方案路径会在传统回归前面加一层“感知层”：把客户经理反馈、竞品宣传、投诉工单这些非结构化文本，用DeepSeek快速提取成结构化标签。比如“某网点周边代发工资客群反馈五年期利率不如另一家”，这条信息以前只会沉淀在周报里，现在可以变成客群标签“代发客户利率敏感度偏高”，再作为弹性模型的分组因子。这样一来，价格弹性不是全行一个数，而是按客群、按区域、按渠道拆成一组系数，定价的颗粒度就下来了，结构优化也有了可计算的抓手。

要特别说明，大模型不参与最终的数值回归，它做的是把文本信息转成离散特征。拿到的标签要经过标准化定义，比如客群标签要有明确的取值列表，而不是让模型自由发挥。否则同一个意思一周叫“代发客群”，下一周叫“工资户”，特征表就废了。这一层治理工作是整个方案里最磨人但也最值得投入的部分，它决定了后面所有模型的输入质量。

2.3 一个能跑起来的最小定价模拟：用Python扫出最优挂牌价

先把概念落成代码。这里用了最简单的网格搜索，模拟单款定期存款产品在不同挂牌利率下的月新增量和毛利，目的是直观看到定价的“甜蜜点”。实际生产环境会更复杂，但这个代码已经足够打开思路。

import numpy as np import pandas as pd # 单款存款产品的基础参数 base_rate = 2.10 # 当前市场基准利率（%） cost_rate = 1.85 # 该产品对应的FTP资金成本（%） alpha = 800 # 基准需求量：当前利率水平下的月均新增（万元） beta = 0.35 # 利率敏感系数：每上浮0.1个百分点，月新增减少的量（万元） def predicted_demand(rate): # 线性需求：利率越高，吸引力越低 diff = (rate - base_rate) * 10 # 转为0.1个百分点为单位 if diff > 0: return alpha - beta * diff else: # 降息侧的需求放大：低价会吸引原本不存钱的闲散资金 return alpha + 0.20 * alpha / 10 * (-diff) def profit_total(rate): demand = predicted_demand(rate) unit_profit = rate - cost_rate return demand * unit_profit rates = np.arange(1.70, 2.40, 0.05) results = [ (round(r, 2), round(predicted_demand(r)), round(profit_total(r), 2)) for r in rates ] df = pd.DataFrame(results, columns=["挂牌利率", "月新增量(万元)", "毛利(万元)"]) print(df) best_rate = rates[np.argmax([profit_total(r) for r in rates])] print(f"网格搜索得到最优定价: {best_rate:.2f}%")

这段逻辑不复杂，但有一个容易被忽略的点：当利率往下调的时候，需求的增长不是线性的，因为低价会吸引本来不想存钱的闲散资金。代码里把降息侧的增长系数设得比升息侧的流失系数更陡，这是从实际数据里看出来的经验，不是理论推导。beta的取值可以看历史量价数据：拿过去十二个月的实际挂牌利率和当月新增量做线性回归，斜率就是一个粗略估计。alpha同理，取当前利率下的历史均值。

跑完这个网格，你会发现毛利最优点并不是利率最低点，也不是最高点，而是一个中间值。利率太低虽然成本低，但吸不到量；利率太高吸量多，但每笔的利差薄。这个“中间值”就是定价模型要回答的问题。不要直接取这个最高点，把它当成上限参考，留出客户经理议价空间和竞品反应余地，通常会在最优利率附近往下留10到20个基点作为保守位。

注意：利率最低点不是最优定价点，它只是成本最低点。

这个最小模拟里没有考虑存量到期转存、没有考虑客户经理定价权、没有考虑竞品动态跟调，所以只能帮你建立直觉，不能直接当业务结论。在生产环境，我一般会在这个网格的基础上加三层约束：利率不低于FTP成本加风险成本、不高于同区域竞品报价的75分位、单周调价幅度不超过10bp。这样算出来的不是一个点，而是一个可执行的利率区间。定价模型真正的产出也应该是区间，不是点值。

3. 客户需求响应与市场竞争态势感知：把看不见的情报变成定价参数

3.1 把竞品利率情报转成结构化JSON：一次DeepSeek调用拆解

客户需求响应和市场态势感知，第一步都是收集对手信息。这个环节在过去极度依赖人工：专人打电话、拍照、录进Excel，再挑出几个“感觉重要”的报上去。录入过程丢失信息，格式五花八门，而且永远滞后一周。现在常见做法是把信息收集交给一线网点，把信息结构化交给DeepSeek这类大模型。我一般会先设计一个固定schema的抽取prompt，再让模型抽取。字段定义很关键，直接决定后面建模能不能用。

下面是一个最小可用的抽取脚本，模型服务地址换成你机构统一接入的网关即可：

import os import requests import json # 机构内部大模型服务接口 LLM_URL = os.environ.get("LLM_URL", "http://your-llm-gateway/v1/chat/completions") LLM_TOKEN = os.environ.get("LLM_TOKEN") def extract_rate_info(raw_text: str) -> dict: prompt = """ 你是银行负债端市场情报抽取助手。从下面的竞品描述中提取存款产品报价。 严格输出JSON，字段: institution_type(股份制/国有/城商/农商/村镇), product_name, product_term(月数), min_amount, listed_rate, extra_note(如礼品、赠送积分等折算收益说明)。 无法确定的字段填null。 竞品描述: {text} 直接输出JSON，不要输出解释。 """ payload = { "model": "deepseek-llm", "messages": [ {"role": "system", "content": "你是一个严格按schema抽取信息的工具，只输出合法JSON。"}, {"role": "user", "content": prompt.format(text=raw_text)} ], "temperature": 0.0 } headers = {"Authorization": f"Bearer {LLM_TOKEN}"} resp = requests.post(LLM_URL, json=payload, headers=headers, timeout=20) content = resp.json()["choices"][0]["message"]["content"] return json.loads(content) sample_text = ( "本周走访：A银行三年期大额存单20万起，利率2.75%，可预约排队；" "B农商行一年期整存整取2.0%，新开户送积分，折合年化约2.15%。" ) print(json.dumps(extract_rate_info(sample_text), ensure_ascii=False, indent=2))

这段代码里有三个要点。temperature必须设成0.0，否则同一个文本反复抽取会得到不一样的结果，后面做周度对比就没法看。schema里的extra_note字段不能省，它是后续校验口径最重要的依据。第三个要点是模型输出必须走json.loads做一次硬解析，解析失败的样本进人工复核队列，不要默默跳过，否则脏数据会一路污染到定价建议。生产环境还要加状态码检查和重试机制，示例里从略。

样本输出会变成类似“A银行三年期大额存单，term=36，listed_rate=2.75”；“B农商行一年期，term=12，listed_rate=2.0，extra_note=送积分折合2.15%”。两条数据在结构上对齐，才能进入汇总统计。很多团队在这个环节翻车，是因为只把大模型当成“打字机”来摘抄关键词，而不是当成结构化抽取器来用。

3.2 客户需求响应矩阵：客群、区域、渠道三层映射

拿到竞品结构化数据后，下一步是把它接到客户需求响应上。我的做法是先做一张需求响应矩阵，把客群分成几类，再给每类客群标出影响选择的关键维度。下表是常见分类，具体参数每家行不同，但维度基本一致：

这张表的用途是给后面的定价模拟加分组约束。比如代发客群对到账时间敏感，那对这部分人群的定期产品利率可以稍微保守一点，因为钱到账后的惯性留存本身就在起作用；高净值客群要的是流动性，三年期利率给得再高也不如支持转让有用。DeepSeek在这层的作用是把客户经理反馈里那些自然语言描述的“xx客群最近很在意xx”批量转成矩阵里的标签。

实操节奏上，一个月更新一次矩阵就够了。两边数据要能对上：一边是客群经理的定性反馈，一边是行内存款台账的定量留存率。看到矩阵里某个客群的观测指标连续两个月下滑，再把对应的客群标签拉出来重算价格弹性，而不是全行一刀切调价。矩阵的产出就是一张客群报价映射表，它不直接给利率，给的是每个客群相对基准价的加减点建议。

3.3 市场竞争态势感知的更新节奏：从月度报告到周度校正

市场态势感知最忌讳做成“月报”，因为竞品调价往往在月初生效、月中就能看出效果，等到下个月报告出来，对手又调第二轮了。方案里我建议按周跑。每周一上午做这几步：汇总上周所有网点提交的竞品情报；用DeepSeek的抽取结果做同区域、同产品、同期限的汇总；计算本行报价在所在区域分位；把连续两周偏离均值超过20bp的产品列入调价候选池。

提示：偏离要连续两周成立才值得讨论，单周异动大概率是极值样本。

候选池不等于调整清单。20bp只是提醒，还要看偏离是否连续、当期资金流入是否正常、是否存在考核时点扰动。经验是偏离要连续两周成立才值得讨论，单周异动大概率是极值样本。这层过滤，本质上是在对抗市场感知模型最常见的过拟合：对手偶发的高价促销，不代表趋势。最终每周产出的是一张市场报价汇总表，包含本行产品在区域内的价格分位、竞品连续两周的最低/最高价、以及需要关注的异常样本。这张表同时作为第4章资金流动分析里rate_diff_gap_1w特征的输入。市场感知的价值不是说“谁家便宜我们跟上”，而是持续回答“我们的价格在客户的选择集里处于什么位置”。

4. 资金流动分析与期限偏好预测：从流水表到期限模型的完整特征链

4.1 资金流动特征：重定价日历、大额异动与季节项

资金流动分析的目标不是预测明天的活期余额，而是找出“哪些钱在未来哪个时间点会重新选择产品”。现金流台账里最有用的四类特征：到期重定价日历、大额异动记录、活期沉淀规律、季节性事件。先建一张特征表，字段最少要有这些：

CREATE TABLE deposit_flow_features ( cust_id VARCHAR(32), as_of_date DATE, days_to_maturity INT, -- 距定期到期还有多少天 maturity_amount DECIMAL(16,2), -- 到期本息合计 deposit_term_level INT, -- 当前期限档位：3/6/12/24/36/60 amount_level INT, -- 金额档位：1=5万以下，2=5万-20万... cust_level INT, -- 行内客户等级 auto_rollover_last TINYINT, -- 上期是否自动转存 channel_app TINYINT, -- 是否偏好手机银行 is_season_end TINYINT, -- 是否在季末考核窗口到期 rate_diff_gap_1w DECIMAL(8,4) -- 本行报价与区域均价的周度差值 );

这张表的数据来源很杂，定期台账能给出前四列，客户等级和渠道偏好取自主数据，最后一列要由第3章的市场感知周报回填。days_to_maturity这列非常关键，它把静态余额表变成了事件流，所有期限偏好模型都会用到期枚举来构造样本。季末字段也建议单独建，别用日期函数现场算，因为考核窗口的规则经常变，独立成列方便统一调整。如果连这张表都建设不起来，后面的预测模型等于在沙子上盖楼。

大额异动的识别单独说两句。我的习惯是先按“单日单账户净流出超过账户日均余额三倍且金额大于50万”作为规则，筛出样本后再用Z-score排序复核。不要一上来就用孤立森林之类的无监督模型，否则客户经理没法跟你解释为什么这笔是异动，那笔不是。规则先跑，模型再做辅助排序，落地方便得多。活期沉淀规律可以按月切片看，重点观察季末前后活期转定期的比例变化，这直接关系到结构优化里的流动性约束。

4.2 期限偏好预测：用XGBoost做六档多分类

期限偏好模型的核心问题：一笔定期到期后，客户会选哪个期限档位。这个问题可以用多分类来做，训练样本用历史到期再投资记录，特征就是4.1那张表里的列加一些衍生字段。下面是能直接跑的基线配置：

import pandas as pd from sklearn.model_selection import train_test_split from xgboost import XGBClassifier from sklearn.metrics import classification_report df = pd.read_csv("term_pref_train.csv") feature_cols = [ "amount_level", "cust_level", "days_to_maturity", "rate_diff_gap_1w", "auto_rollover_last", "channel_app", "is_season_end", "deposit_term_level" ] X = df[feature_cols] y = df["target_term"].astype(int) # 到期后最终选择期限：3/6/12/24/36/60 X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y) model = XGBClassifier( n_estimators=300, max_depth=5, learning_rate=0.06, subsample=0.8, colsample_bytree=0.8, eval_metric="mlogloss", tree_method="hist", early_stopping_rounds=20, random_state=42 ) model.fit( X_train, y_train, eval_set=[(X_test, y_test)], verbose=False ) print(classification_report(y_test, model.predict(X_test)))

参数上给几个经验值：n_estimators给到300配合early_stopping就够，树太深容易记住客户编号和月份的噪声，max_depth=5在结构化银行数据上基本够用；learning_rate调低到0.06，收敛慢一点但稳定；colsample_bytree=0.8可以削弱特征之间的共线性。重点提醒：days_to_maturity、rate_diff_gap_1w、is_season_end这三个特征的贡献度通常排在前五，如果模型报告里它们不靠前，先检查是不是特征构造出了问题，不要急着堆更多变量。deposit_term_level 和 target_term 虽然天然相关，但不是泄漏，因为预测时这笔存单当前期限是已知的。

模型预测出来的是六个概率，不是单点。跑完后我习惯先打混淆矩阵看，最常出现的错误是相邻期限互相混淆，比如预测3年结果选了2年，或者24期和36期分不清。这种混淆不可怕，说明客户本来就临近；真正要警惕的是预测1年但客户选了5年的大跨度跳跃，那通常意味着当期有特殊产品促销，特征里没有捕捉到，需要回查当时的利率环境。如果你没有历史到期再投资明细，另一个替代方案是拿定期存款到期清单和续存记录做近似，虽然会损失一部分换了产品形态的客户，但样本量够大时依然可用。

4.3 从预测结果到定价参数：期限偏好矩阵怎么用

模型跑完不要只输出一张准确率报表。我一般会把所有客户的预测概率按客群和现有产品汇总成一张期限偏好矩阵，行是客群，列是六个期限档位的预测占比。这张矩阵可以直接给定价会议用：如果代发客群偏好集中在1年和2年，而当前主推5年期，说明产品供给和需求结构错位，要么调整产品额度，要么调整期限溢价。

更细一步，矩阵可以换算成“转化弹性”：预测1年期的客户中，把利率上调20bp后有多少比例会转向2年期。这个数字来自竞品利差特征的敏感性试验，做法是把rate_diff_gap_1w人工加上20bp，重新预测，看概率分布变化。有了这个转化弹性，定价时给不同期限的加点幅度就不再是拍脑袋，而是按“多付多少利息才能换来多少结构优化”来算。这类敏感性试验有局限，它假设客户的反应是静态的，实际竞品会跟调，所以只能当参考，不能直接进损益账。

5. 存款结构优化落地的避坑清单：五个高频翻车现场

这一章列的是做这类项目过程中真实遇到过的问题，每条都说清楚现象、原因和解决办法，以后你在方案推进时能少走弯路。

5.1 模型预测客户偏好三年期，柜面却全卖成三个月

现象：期限偏好模型显示某客群对三年期需求很强，实际销售数据出来，三个月、六个月的短期产品占比反而抬升。原因：客户经理的推荐引导力远大于客户的自发选择。模型只学了“客户会选什么”，忽略了一家支行“愿意卖什么”，考核计价倾向直接把客户意愿压下去。解决：把推荐倾向作为一个特征放回模型，做法是从客户经理工号与成交记录里做交叉统计，得到每个经理的期限偏好指数。上线时更稳妥的做法是模型只提供客群级建议，交给支行分几轮测试，而不是直接改全行计价规则。

5.2 竞品出现极端价格，竞品跟踪模型差点带崩全行定价

现象：某村镇银行对一款产品报出明显低于市场的价格，市场感知模型按这个最低价作为基准，建议全行挂牌价同步下调。原因：用最值做基准，而没用分位数；单票样本没有被过滤。解决：基准改成同区域内价格的中位数，同时加一个去极值规则——只有连续两周都出现的价格才进入基准计算。这样可以让突发促销、临时走量报价留在表面，不进入定价推荐。

5.3 季末考核冲量，资金流动预测全线失真

现象：6月和12月的模型预测偏差达到30%以上，比平时高了近一倍，模型像突然失明一样。原因：考核时点前的突击拉存让数据分布完全变形，平时学到的资金流动规律在冲量面前不成立。解决：两套口径并行。常态口径用日常特征；考核期口径单独建一个模型，并把“距离季末考核天数”作为一个显式特征。预测结果上明确标注“考核期预测”字样，避免被拿去做常态决策。转存和到期事件也要按考核窗口前后错位切分。

5.4 同样是“2.8%”，一个能进模型，另一个会带偏整个定价

现象：DeepSeek抽取出两条定价信息都写着2.8%，一条是纯挂牌利率，另一条是折算礼品后的综合收益，汇总进定价模型后，市场均价被抬高了。原因：prompt里只有字段名，没有定义口径的判定规则。模型不知道“送积分”“折合约”这类词意味着什么。解决：在prompt里增加判定词表，凡出现“折合”“赠送”“积分”等词，把listed_price标为待复核。后置再加一条一致性校验，extra_note非空的样本默认不进基准计算，最多进备注池供人工判断。

5.5 回测很漂亮，一上真实定价就发现模型不再灵

现象：回测里调价方案让付息率下降、存款量稳定，实际跑一个月，两款产品量价同时下滑。原因：回测假设竞品不动，自己调完价市场份额自然就来了。真实市场里竞品会跟调，甚至调得更狠，模型吃掉了自己调价后的反馈闭环。解决：改用“决策点滞后”回测框架。把模型的默认输出当成t周的建议，去和t+2周真实的存款变动做对照，而不是和t周的历史数据做拟合。对照组用当期实际决策结果，如果模型建议和实际决策一致，这条样本的信息量就稀释掉了，要额外标注。

6. 把定价和结构优化变成常规系统：模拟退火调结构、滚动回测验方案

6.1 用模拟退火搜索最优存款结构：付息成本与流动性约束双目标

期限偏好预测给了客群意愿，资金流动给了现金流量，接下来要把这些信息压成一个可执行的结构目标。结构优化是一个带约束的搜索问题：各期限产品占比之和等于1，短期产品不低于某个比例，加权付息率尽量低。组合规模不大，但约束是非线性的，我常用模拟退火来搜。代码可以很薄：

import random import math import numpy as np terms = [3, 6, 12, 24, 36, 60] # 期限档位（月） term_cost = [1.55, 1.75, 2.05, 2.40, 2.80, 3.10] # 各档付息成本（%） def total_cost(w): return float(np.dot(w, term_cost)) def liquidity_ok(w): # 6个月以内占比不低于20% return w[0] + w[1] >= 0.20 def penalty(w): p = 0.0 if not liquidity_ok(w): p += 5.0 p += max(0.0, total_cost(w) - 2.55) * 10.0 return p def neighbor(w): w = w.copy() i, j = random.sample(range(6), 2) move = random.uniform(0, 0.02) w[i] -= move w[j] += move w = np.clip(w, 0, 1) # 简洁起见，占比和为1交给罚函数控制 return w w = np.array([0.20, 0.10, 0.30, 0.15, 0.15, 0.10]) temp = 1.0 random.seed(42) for _ in range(2000): nw = neighbor(w) old_c = total_cost(w) + penalty(w) new_c = total_cost(nw) + penalty(nw) if new_c < old_c or random.random() < math.exp((old_c - new_c) / temp): w = nw temp *= 0.998 print("优化后各期限占比:", np.round(w, 3)) print("加权付息成本:", round(total_cost(w), 4))

模拟退火对这个规模的小问题完全够用，枚举组合也可以，但后面要加更多产品、更细的约束，退火算法的扩展性更好。惩罚项的系数要远大于正常变化量，这里取5和10，否则约束就是软性的，解出来会悄悄违反流动性线。温度下降系数0.998，迭代2000轮，能稳定收敛到一个不坏的局部最优。

6.2 滚动回测：验证方案到底有没有价值

模型落地前要做一轮滚动回测，框架其实很朴素：截取过去24周，每一周用截止当时的数据训练模型、给出建议，记录五列：模型建议、实际上调、四周后存款变动、四周后付息率变化、竞品是否跟调。跑满24行你就能看出，模型建议长期跑赢实际上调的周数比例是多少。如果胜率连60%都没有，别急着上线，先回去看特征，问题多半出在第5章那些坑里。

| 周次 | 模型建议 | 实际决策 | 四周后日均存款变化 | 付息率变化 | 竞品是否跟调 | | 第1周 | 3年期下调10bp | 未调 | +0.2% | 0 | 否 | | 第2周 | 3年期下调10bp | 下调10bp | -0.1% | -2bp | 是 |

这个回测的对手不是别的模型，而是行里原来的决策。对照表每周填一次，不需要复杂统计，直接看胜率和平均收益差异就足够。回测里我习惯把模型建议和实际决策一致的周数标出来，这些样本既不能证明模型有效，也不能证明无效，权当噪声处理。

6.3 我的一点习惯：先跑通周度流程再谈模型调优

我最早做这类方案时犯过一个错：在模拟数据上反复调参，把模型复杂度堆到很高，上线时却发现分支行根本不用，因为客户经理手里有一套自己的“老经验”，他们不相信一个黑匣子比自己更懂客户。后来我把模型的输出从“一个建议利率”改成“一张加减点建议表加一句理由说明”，再配上每周固定时点的复核节奏，模型才真正被用起来。现在回头看，这套方案里最值钱的不是某条算法，而是把客户需求响应、市场竞争态势、资金流动、期限偏好串成了一个周度可复核的闭环；结构优化技术是锦上添花，流程跑通才是雪中送炭。希望帮到你。

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