这一篇原计划再打磨一周才放出来但后台催更的人实在太多索性把核心部分先提上来。系列第一篇讲了面向金融的深度学习整体框架和基础设施搭建这篇我更想聊些纸上谈兵时永远碰不到的东西为什么离线指标那么漂亮实盘却总是被打脸特征工程里那些隐蔽的信息泄漏到底藏在哪里部署之后模型又是怎么一点点“变傻”的。整个项目我习惯用内部代号TS-Risk来称呼。它要解决的核心问题很朴素从行情和盘口数据里判断当前市场处于什么状态然后动态调整风险敞口同时保留完整可复盘依据。整篇文章不会出现任何一行需要特殊部署环境的代码也不依赖任何平台你可以把它当成一套可以迁移的通用方法论来读。1. 从“Demo能跑”到“系统能用”差距多半不在模型本身1.1 一次让我印象深刻的打脸经历我在做TS-Risk时早期花了很多精力优化一个日内状态识别模型。频率是5分钟一根K线目标是把行情切成“进攻状态”和“防守状态”两类。离线测试集上准确率做到76%F1接近0.74当时觉得已经相当能打了。结果丢进模拟盘之后第一周就开始出问题连续几天回撤在风控线附近反复横跳信号切换频繁到像抽风一样止损单连续被打掉之后资金曲线直接进入阴跌状态。排查之后发现三件事每件都不在模型结构上。第一我的评估指标没有扣交易成本。5分钟频率的换手每次信号切换都伴随开平仓手续费和滑点吃掉的利润远远超过模型的预测优势。第二模型识别出的“状态切换”很多只是在捕捉噪声的随机波动根本没有持续性。离线指标再好看也只是说明它在训练数据上拟合得好。第三我把状态阈值定在了0.5附近导致模型一点点微弱倾向都会变成实打实的仓位调整这在真实市场里等于高频瞎折腾。那次经历让我彻底放弃了“只要把模型调好就能赚钱”的幻想。金融场景下的深度学习工程复杂度远高于算法复杂度。模型只负责把条件概率算出来真正决定系统生死的是数据、决策和执行之间的衔接。1.2 我后来把“能用”拆成四个环节为了让团队讨论时不吵架我把整个系统拆成四层每层有独立的验收标准层级核心任务常见陷阱数据与特征层采集、清洗、对齐、特征计算前视偏差、时序错位、重复样本模型推理层多模型并行、置信度输出、状态融合单模型失效、分布漂移、训练泄漏组合决策层仓位计算、风险阈值、资金管理模型输出直接映射仓位、忽略相关度执行与监控层信号新鲜度校验、特征漂移检测、复盘日志时延抖动、静默失效、无法追溯这四层对应的时间占比在真正的项目里大约是数据处理与特征占三到四成模型训练占两成回测与评估占两成部署与监控占两成。模型结构本身反而不是最花时间的地方。这篇文章接下来的内容基本就是围绕这四个环节展开的踩坑记录。每一个坑我都尽量给出当时是怎么定位出来的以及现在回头看更合理的做法是什么。2. 特征与标签的真实工程细节信息泄漏往往藏在你想不到的地方2.1 重叠滑窗里的前视偏差特征工程是最容易出“幽灵信号”的地方而且这类问题隐蔽性极强。我最常见到的错误是对全量序列做标准化之后再切窗口。看下面这段错误示范# 错误示范用全量数据算z-score from sklearn.preprocessing import StandardScaler scaler StandardScaler() df[close_z] scaler.fit_transform(df[[close]]) for i in range(len(df) - window): seq df[close_z].iloc[i : i window] label df[future_return].iloc[i window] train_samples.append((seq, label))问题在于scaler.fit_transform在训练集构造时已经看到了全部数据的均值和标准差。假设序列前段波动小、后段波动大那么后段的统计信息会被“穿越”到前段的特征里。模型在训练阶段很容易学到一个虚假的规律只要某个特征相对全时段偏高就预示未来收益上行。可到了实盘新数据只有当前这一小段可用全时段的均值和标准差根本不存在模型自然立刻失效。正确做法是只使用截至当前时刻的数据计算标准化统计量def compute_rolling_zscore(df, column, lookback): mean df[column].shift(1).rolling(lookback).mean() std df[column].shift(1).rolling(lookback).std() return (df[column] - mean) / std这里加了一个shift(1)意思是t时刻的特征里不包含t时刻自身的信息更不包含t时刻之后的信息。很多朋友在写滚动特征时容易忽略这个细节总觉得自己用的是历史窗口就算安全实际上如果滚动窗口的计算范围包含了当前K线而标签又是当前K线之后产生的收益率两者之间就会形成极其隐蔽的短期重叠。我在TS-Risk里对这件事的执行标准很简单所有特征要么在t时刻收盘后立即计算完毕要么干脆用t时刻之前一根K线收完后的数据。宁可损失一点时效性也不能冒泄漏的风险。2.2 标签到底该怎么打标签设计是另一个容易被低估的环节。分类问题不是“收益率大于0就标1”那么简单的。我梳理了三类常用标签供你根据场景选型标签类型构造方式优点主要坑未来收益率方向sign(future_return)并设定阈值直观、容易解释阈值取0会包含大量噪声样本波动率调整后收益future_return / future_vol再阈值化过滤低波动假信号需要谨慎估计未来波动事件型标签是否突破N日新高、是否触发止损位贴近交易行为事件稀疏类别不均衡严重我个人的经验是收益方向标签必须加一个“有效幅度”的概念比如未来20个周期内收益绝对值超过X倍波动率才算正样本否则一律丢弃或标记为中立样本。图省事的做法是把所有样本硬塞进二分类模型会被大量低波动噪声样本带偏后期再怎么做类别加权都补不回来。事件型标签更适合做触发类风控比如“会不会突破某条均线”“会不会跌破支撑位”。这类标签和交易逻辑贴合度高但正样本占比可能只有5%以下需要配合重点关注损失或采样策略。2.3 特征分组与跨周期错配金融特征五花八门我习惯把它们分成四组趋势类、波动类、资金流类、微观结构类。趋势类包括均线斜率、MACD类指标波动类包括ATR、历史波动率资金流类包括成交量变化、资金净流入估算微观结构类包括买卖盘口失衡、Tick级成交量分布。分组的好处有两个。第一做特征重要性分析时能快速定位是哪一组在驱动决策不至于面对几百个特征无从下手。第二可以强制约束特征之间的时间对齐关系。跨周期错配是最容易忽略的细节。比如你有一个日线级别的成交量特征又有一个分钟级的盘口失衡特征两者直接拼接时务必确保它们都指向同一个时间切片。高频特征不能简单降采样了就丢给低频模型必须定义清楚对齐规则是取区间最后一笔还是取区间平均值。我在项目里统一规定除滚动统计特征外所有特征在同一个时间戳上完成计算不允许出现“用今天收盘的均线去预测今天收盘后的收益”这种结构。3. 多模型并行与训练策略没有一种模型能适应所有市场状态3.1 为什么不是一个模型而是五个很多入门项目喜欢堆一个“究极模型”希望它能看穿所有行情。实际上金融时序的分布变化非常大趋势市、震荡市、高波动切换市、低波动慢速市、极端流动性收缩这五种状态下数据分布几乎可以看作五个完全不同的数据集。我最终在TS-Risk里保留了五个模型而不是一个趋势跟随模型偏好持续性强、单边运行明显的行情震荡回归模型偏好均值回归、区间震荡明显的行情高波动切换模型专门处理暴涨暴跌夹杂的快速切换低波动慢速模型在横盘阶段寻找低幅度稳定规律流动性收缩模型专门识别成交萎缩、滑点扩大的危险期这五套模型共享同一个特征池但训练样本按市场状态做了切分。每个模型输出的不是最终信号而是“它擅长的那类状态发生的概率”。系统再通过一个轻量的状态识别器为各模型动态分配权重。如果你是一个人在做项目我不建议一上来就上五个模型可以先从两个开始一个趋势类、一个回归类。先把两条腿走路跑通再逐步加第三条腿。模型越多权重分配策略就越复杂排查问题的时间也会成倍增加。3.2 训练细节时序数据不是让你把数据shuffle后反复fit金融深度学习模型训练最容易犯的一个错误就是沿用图像和自然语言处理里的做法洗牌、随机切分、反复迭代。这件事在时序任务里是致命的。时间序列数据必须严格按时间顺序分割训练集、验证集和测试集。我一般用“前70%时间训练、后15%验证、最后15%测试”的策略同时要求验证集和测试集之间不重叠。如果样本本身还是重叠滑窗构造的那还要额外保证验证集和训练集之间留出“缓冲地带”比如空出一段不回传的样本区间否则相邻窗口的强相关性会让验证分数虚高。训练细节上我习惯用这么一套配置作为起点学习率先线性warmup 1000步再走余弦退火批次大小根据序列长度调整短序列用256长序列降到64除了最后的分类头所有层都用较低的学习率类别不均衡时用焦点损失或加权交叉熵而不是简单复制样本归一化要特别提一句不要用全序列的统计量。我在2.1里已经强调过这一点训练过程同样适用。每个特征都应该用滚动统计量做标准化推理阶段也要维护同样的滚动统计量否则训练和推断之间的输入分布会不一致。3.3 融合权重与置信度输出多模型并行之后最核心的问题是权重怎么定。我在项目里用了一个比较实用的方案权重由近期验证损失和状态匹配度共同决定。import numpy as np def compute_model_weights(valid_losses, state_alignment, temperature1.0): # valid_losses: 各模型在最近验证窗口的损失 # state_alignment: 各模型与当前状态识别器的匹配度取值0到1 scores -np.log(valid_losses) state_alignment * temperature scores scores - scores.max() # 数值稳定性 exp_scores np.exp(scores) return exp_scores / exp_scores.sum()这里有个容易被忽略的问题损失要用滚动窗口算而不是用全量历史算。市场状态变了一个模型三个月前表现好并不意味着现在依然好。我一般是取最近200个验证样本的损失每天更新一次。置信度输出同样重要。我不建议把softmax概率直接当置信度用因为softmax在分布漂移时会给出过度自信的结果。更好的方法是使用MC Dropout或者深度集成来近似不确定性。MC Dropout实现成本低推理时多跑几次随机失活取预测分布的分位数就能得到一个相对可靠的不确定性区间。当不确定性超过阈值时系统会主动降低仓位而不是盲目跟随信号。4. 回测正确性我建议你把回测当成一篇实证研究来做4.1 三类回测污染前视偏差、幸存者偏差、过度交易偏差回测的正确性比回测结果本身重要得多。一个跑得漂亮的错误回测比一个跑得一般但真实的回测危害更大因为它会给你虚假的信心让你在实盘里用错误的仓位犯下大错。我在项目里维护了一份“回测污染排查清单”每次跑完新策略都要逐条过一遍所有特征是否只用到了t时刻及之前的数据连t时刻的收盘价都要小心实盘里收盘价是收盘后才知道的。资产池是否固定为“现在依然存续的品种”如果做过退市剔除就是幸存者偏差。手续费、滑点、冲击成本是否全部计入连续成交压力测试下实际成交价往往比回测成交价差很多。状态切换是否使用了未来信息例如用全区间的中位数定义“高波动期”这就是典型的未来函数。样本是否重叠重叠滑窗会让有效样本量远小于表面样本量统计检验会被扭曲。这些检查看起来简单但每一条都出过真实的教训。尤其是“用全区间统计量定义样本标签”这种错误往往要等到实盘打脸之后才能察觉。4.2 指标体系的取舍收益垫底过程指标反而重要回测报告里我最不关心“累计收益”这个数字因为它太容易被参数优化美化。我真正关注的是一组过程指标指标计算方式我关注的阈值最大回撤从峰值到谷底的最大跌幅不超过目标回撤线的80%卡玛比率年化收益 / 最大回撤大于1.0才考虑上线换手率平均每日调仓比例过高则收益会被成本吞噬盈亏比平均盈利 / 平均亏损大于1.5覆盖时间比例模型处于激活状态的时间占比太低说明模型长期空转这四个指标组合起来比单纯看夏普比率要可靠得多。夏普比率高不代表回撤可控也不代表成本消耗后还有利润。实际项目里一个夏普只有1.2但换手率极低、回撤小的策略往往比夏普2.0但换手率高得吓人的策略更适合实盘。4.3 压力测试场景怎么构造除了用历史数据回测我还建议做几个“人工压力场景”的测试。最有效的一种是人为放大波动把历史行情中的价格波动乘以2到3倍、成交量减半、买卖价差扩大然后重新生成行情序列灌入策略跑一遍。这种场景不需要很精细重点是看策略在极端环境下的表现是否符合风控预期。另一种是参数退化测试把模型里所有涉及阈值的参数都调成保守值看看策略是否还能活下来。如果策略依赖某个特定阈值组合才能盈利那它在实盘中几乎没有实用价值。实盘环境参数永远不会固定在回测的最优值上模型最好在一个大范围的参数空间里都表现出平稳性。我在TS-Risk里做过一次测试某个常规回测表现优秀的子模型在人为构造的流动性收缩场景中单日回撤直接冲到目标值的三倍。原因就是模型没有设置流动性过滤在成交量骤减时依然按原规模建仓。那次之后我要求所有模型上线前必须通过最低流动性门槛检验。5. 部署阶段真正会咬人的四个暗坑5.1 影子运行先把新模型挂进生产旁路模型训练完成后直接接管实盘仓位是新手最容易犯的错误。稳妥的做法是先做影子运行也就是把新模型的输出和现有生产流程并行运行但不让它真正下单。影子运行的流程我一般这样设计新模型接入实时行情流按生产逻辑计算特征和信号系统记录新模型的每日持仓建议、仓位比例、置信度水平影子信号与实盘信号做对比统计差异率、方向一致率、回撤模拟值连续运行至少两周覆盖至少一个完整的市场状态切换影子运行期间新模型的“虚拟绩效”和数据管道健康度是一起评估的。很多模型离线表现好一进影子运行就暴露出特征漂移问题原因在于离线数据已经经过清洗线上数据则是脏的、乱的、延迟不齐的。如果不走影子运行这些差异很难在切换那一刻之前发现。我遇到过最典型的案例一个新特征在离线数据库里填充率是99%到了线上实时流里填充率只有62%。模型在缺失值处理上与离线完全一致但大量缺失导致推理结果偏向某个特定状态直接让信号失真。影子运行里的数据健康度监控帮我提前发现了这个问题避免了一次真实损失。5.2 特征漂移用PSI盯住线上特征分布上线之后模型并不会保持不变。市场结构在变数据分布也在变待的时间越长特征分布和训练时越不像。我用来监测特征漂移的主要工具是PSI。PSI的计算逻辑是把当前特征分布与训练期基准分布分别分箱然后计算每个箱占比差异的加权值。经验阈值是PSI小于0.1表示稳定0.1到0.25之间需要关注并排查原因大于0.25就必须考虑模型刷新或退回上一版本。特征漂移监控的难点在于“看哪个特征”。特征数量多的时候不可能每天人工盯所有指标我一般会做自动化筛选按特征重要度排序只监控累计重要度超过80%的那批特征。这部分特征数量通常不超过三四十个每天生成一张漂移报表超过阈值自动告警。5.3 时延抖动几十毫秒的延迟会让信号失效金融系统里延迟不只是速度问题更是信号有效性问题。TS-Risk的信号是基于5分钟K线计算的本身对毫秒级延迟并不敏感。真正让信号失效的是“排队抖动”模型推理服务偶尔会不稳定一次推理耗时从正常的90毫秒跳到500毫秒甚至一秒以上。在排队期间最新一根K线已经生成你手里拿到的还是旧K线计算出的信号两者就错位了。为了处理这个问题我在推理链路里加了一个“信号新鲜度校验”。系统在下发交易指令前会检查信号对应的时间戳是否与当前K线一致。如果不一致直接丢弃信号等下一个周期重新计算。这个机制看起来简单却能避免大量因延迟导致的垃圾信号。另外我建议所有模型推理服务都做超时熔断。推理服务响应超过阈值时宁可不出单也不能在没有任何保护的情况下输出一个陈旧的仓位建议。5.4 仓位计算和执行脱节模型输出不等于下单配置最后一个暗坑是把模型输出的概率直接当作仓位比例。我见过不少项目模型输出“上涨概率0.75”仓位就配到75%看起来逻辑自洽实际上完全没有考虑资金管理和风险预算。正确的做法是让仓位计算独立于模型推理。模型只输出两个东西方向预测和置信度。仓位决定由组合决策层完成它要至少考虑三个约束单一品种敞口上限防止黑天鹅组合内相关品种的相关度上限防止“看似分散实则集中”当前波动率水平约束市场波动大时自动降低杠杆我习惯在模型层的输出后面加一个“风险预算转换器”它的输入是模型信号和置信度输出是经过风险约束后的仓位建议。这层转换器只依赖规则不依赖模型出了问题可以单独回滚。有一句话我在团队里反复讲模型负责聪明规则负责保命。6. 最后几条个人经验以及这个系列接下来想写什么做了这个项目之后我最大的体会是金融深度学习真正的门槛不在算法而在“可复现性”和“可追溯性”。第一数据版本管理不能省。行情数据每天都变同样的代码跑两遍可能因为数据源头多了一条新记录而结果完全不同。我在TS-Risk里给每个训练数据集生成了一个内容哈希作为实验记录的一部分。这样做的好处是三个月后发现某个模型有问题你还能靠哈希找回当初训练它时的原始数据而不是对着一个无法复现的结果干瞪眼。第二每次训练运行都存一份完整的实验配置。模型结构、超参数、特征列表、数据哈希、训练时间戳全部写进一个记录文件。听起来麻烦但碰到“这个版本比上周效果差”这种问题的时候你会发现这笔投入非常值。第三不要迷信新模型。每次有号称更先进的结构出现时我的默认动作是先放进影子运行跑够两个星期再说话。金融时序数据里的分布漂移决定了很多新模型在短期实验里表现不错但长期稳定性可能还不如老模型。第四如果有人问我“做金融深度学习最重要的是什么”我的答案不是模型结构也不是特征工程而是能不能建立一套从数据到决策再到复盘的可复现机制。没有这套机制所有收益都像沙子一样风一吹就散了。这个系列如果继续写的话第三篇我想专注于两件事一是自动特征发现现在手工构造特征占了太多时间二是轻量模型蒸馏让部署成本降下来的同时保持信号质量。如果你也在做类似方向欢迎把你的踩坑经历拿出来交流这些真实的教训永远比论文里的基准实验更有参考价值。