1. 回测有信号、上线没信号问题到底出在哪一层如果你做过量化策略的实盘部署大概率遇到过这个场景回测报告里模型每天都能稳定输出预测值信号曲线密密麻麻收益曲线也漂亮得让人想立刻上实盘。结果代码一部署到生产环境日志里干干净净一条信号都没有。第一反应通常是模型是不是过拟合了要不要重新训练一版然后花两三天重新跑训练、调参、换特征上线之后发现——还是没信号。我踩过这个坑不止一次后来复盘发现绝大多数回测有预测、部署没信号的情况根因根本不在模型本身而在数据链路、时间对齐、特征工程和运行环境这四个环节。模型只是最终输出预测的那一环它前面有一整条流水线任何一环在生产环境里和回测环境不一致都会导致信号凭空消失。这篇文章就是把这个排查链路完整拆开讲清楚。适合两类人看一类是刚把策略从 notebook 搬到服务器、正在被没信号折磨的工程师另一类是做过一些回测但还没真正上过生产、想提前知道坑在哪的量化爱好者。我会按先定位问题在哪一层再逐层排查的顺序来讲每一层都给出具体的检查方法和判断依据而不是泛泛地说检查数据。先给一个核心结论后面所有内容都围绕它展开回测和部署之间最大的差异不是模型而是数据到达的时间顺序和运行时的时间语义。回测里你是上帝视角所有数据都已经躺在文件里你想怎么对齐就怎么对齐部署后数据是一条一条流进来的时间戳、时区、缺失值、字段类型、依赖版本任何一个细节和回测不一致模型就可能输出空值或者被过滤掉。所以正确的排查顺序不是重训模型而是先确认模型在生产环境到底有没有被调用、有没有输出再确认输入模型的特征向量和回测时是否一致然后确认数据从源头到模型之间的链路是否完整最后才考虑模型本身是否需要调整。下面逐层展开。2. 先分清没信号是哪一种没信号没信号这个描述太笼统了不同的人说这句话指的可能是完全不同的东西。排查的第一步是把没信号这个模糊现象拆成可观测的具体状态。我一般会把它分成四类每一类对应的根因方向完全不同。2.1 四类没信号的具体表现和对应根因现象日志表现最可能的根因方向模型压根没被调用没有任何推理日志定时任务没触发调度配置、进程存活、依赖注入模型被调用了但输出为空有推理日志输出 None / NaN / 空数组特征缺失、类型错误、模型加载失败模型有输出但被过滤掉有预测值但信号表里没有记录阈值过滤、风控拦截、去重逻辑有信号但下游没收到信号表有记录交易/通知没动作消息队列、下游消费、权限这四类的排查路径完全不一样。很多人一上来就重训模型其实连模型有没有被调用都没确认过。我建议你在生产代码里在模型推理的前后各打一条日志推理前打印输入特征的 shape 和关键字段值推理后打印输出的原始值。这两条日志能瞬间把问题范围缩小一半。2.2 用一条探针日志定位断点具体做法很简单在推理函数入口和出口各加一行结构化日志import logging logger logging.getLogger(inference) def predict(features): logger.info(inference_input shape%s keys%s, getattr(features, shape, None), list(features.keys()) if hasattr(features, keys) else None) result model.predict(features) logger.info(inference_output value%s is_nan%s, result, _is_nan(result)) return result部署后观察日志如果连inference_input都没打出来说明调度或进程有问题跟模型无关如果打出来了但inference_output是 NaN说明特征或模型加载有问题如果两条都正常但信号表没记录说明是过滤或下游的问题。提示探针日志一定要用结构化格式keyvalue不要用纯字符串拼接否则日志量一大就没法用 grep 精确定位。这一步看起来简单但我见过太多团队跳过它直接进入重训环节结果浪费了大量算力还没解决问题。先定位断点再谈修复这是排查任何回测正常、上线异常问题的第一原则。3. 数据链路回测是批处理部署是流式这是万恶之源定位到断点在数据侧之后接下来要理解一个根本性的差异回测和部署的数据处理范式是不一样的。回测通常是批处理——你有一个完整的 DataFrame所有历史数据都在里面特征工程是对整个表做一次 transform部署是流式——数据一条一条来特征工程必须对单条或小窗口数据做增量计算。这两种范式之间的鸿沟是没信号问题最主要的来源。3.1 批处理特征和流式特征最容易对不上的三个点第一个点是滑动窗口。回测里算 20 日均线你直接df[ma20] df[close].rolling(20).mean()一行搞定。部署后数据是流式的你必须自己维护一个长度为 20 的缓冲区每来一条新数据就 push 进去、pop 掉最老的再算均值。如果缓冲区没维护好或者冷启动阶段窗口没填满算出来的值就和回测对不上。更隐蔽的是回测里rolling(20)默认是包含当前点的而很多人在流式实现时用的是不包含当前点的窗口这一个点的差异就足以让模型输出完全不同的结果。第二个点是缺失值处理。回测里遇到缺失值你可能直接df.dropna()或者df.fillna(methodffill)整个表处理完再喂给模型。部署后单条数据来了如果某个字段缺失你是跳过这条、用上一条填充、还是用默认值这三种选择在回测里可能看不出差别但在生产环境会导致特征分布偏移。我遇到过最坑的情况是回测里fillna(0)部署时因为字段缺失直接抛异常被上层 catch 掉结果整条信号被静默丢弃。第三个点是时间对齐。回测里所有数据的时间戳都是对齐好的你 merge 一下就完事。部署后不同数据源到达的时间可能差几秒甚至几分钟如果你用当前时间去 join 特征很可能 join 不到还没到达的数据导致特征全空。3.2 用影子回放验证流式特征是否等价要验证流式特征和批处理特征是否等价最有效的办法是影子回放把回测用的历史数据按时间顺序一条一条喂给你的流式特征计算模块把每一步的输出和批处理版本的输出逐行对比。# 批处理版本 batch_features compute_features_batch(historical_df) # 流式版本逐条回放 stream_features [] buffer FeatureBuffer(window20) for _, row in historical_df.iterrows(): feat buffer.update(row) stream_features.append(feat) # 逐行对比 diff compare(batch_features, stream_features) assert diff.max_abs_error 1e-6, f特征不一致最大误差 {diff.max_abs_error}这个对比一定要做而且要在上线前做。我自己的经验是第一次做影子回放几乎不可能一次通过总会发现几个字段对不上。常见的不一致包括rolling 窗口是否包含当前点、fillna 的策略、时间戳的时区、浮点精度累积误差。把这些都对齐之后流式特征才算真正可信。注意影子回放要覆盖冷启动阶段。很多 bug 只在缓冲区没填满的前 N 条数据里出现如果你从中间开始回放就永远发现不了。3.3 时区和时间戳一个被严重低估的坑时区问题值得单独拎出来说。回测数据通常是从数据库或 CSV 读的时间戳可能是 UTC也可能是本地时间取决于数据源。部署后服务器时区、数据库时区、数据源时区三者可能都不一样。如果你的特征计算里涉及当天本周上一交易日这类逻辑时区差几个小时就可能导致整个交易日错位。我的做法是全链路统一用 UTC 存储和计算只在最终展示和交易日判断时转换成本地时区。并且在数据入口处强制校验时间戳的时区信息如果发现是 naive datetime没有时区信息直接报错而不是默默按本地时间处理。这个习惯帮我避免过至少两次信号日期整体偏移一天的严重问题。4. 特征一致性模型看到的输入和回测时是不是同一个东西数据链路打通之后下一个要确认的是模型在生产环境收到的特征向量和回测时训练/推理用的特征向量是不是同一个东西。这个问题听起来很基础但实际排查中特征不一致是导致没信号的高频原因而且往往很隐蔽。4.1 特征顺序、字段名、数据类型一个都不能错模型对特征的顺序是敏感的。回测时你可能是按[ma5, ma20, rsi, volume]的顺序构造特征矩阵部署后如果代码里字段顺序变成了[volume, ma5, rsi, ma20]模型收到的就是完全错乱的数据输出自然不可信。更麻烦的是如果模型是树模型比如 LightGBM特征顺序错了它不会报错只会默默输出一个看起来正常但实际错误的值。字段名的问题类似。回测时特征列叫ma_20部署后数据源给的字段叫ma20如果你用字典取值而不是按位置取就会 KeyError如果用get带默认值就会静默拿到 None 或 0特征直接失真。数据类型也要注意。回测时volume是 int64部署后从 JSON 解析出来可能变成 float 或者 string。树模型对类型相对宽容但神经网络和线性模型对类型非常敏感string 类型的数值特征会直接导致推理失败或输出 NaN。我的建议是在推理入口处加一个特征 schema 校验把期望的字段名、顺序、类型、取值范围都定义成一份配置每次推理前校验一遍不通过就报警而不是继续推理。FEATURE_SCHEMA [ (ma5, float, (0, 1e6)), (ma20, float, (0, 1e6)), (rsi, float, (0, 100)), (volume, float, (0, 1e12)), ] def validate_features(feat_dict): for name, dtype, (lo, hi) in FEATURE_SCHEMA: if name not in feat_dict: raise ValueError(fmissing feature: {name}) val feat_dict[name] if not isinstance(val, dtype): raise TypeError(f{name} type mismatch: {type(val)}) if not (lo val hi): raise ValueError(f{name} out of range: {val})这份 schema 看起来啰嗦但它能在问题发生的第一时间把原因暴露出来而不是让你在没信号的迷雾里瞎猜。4.2 归一化和标准化训练时的 scaler 有没有被正确加载如果模型用了归一化或标准化那么部署时必须加载训练时拟合的那个 scaler而不是重新 fit 一个。我见过有团队在部署代码里写scaler StandardScaler()然后直接 transform忘了 load 训练时的参数结果特征被错误缩放模型输出全部偏向某一侧信号要么全是一类要么被阈值过滤光。正确的做法是把 scaler 和模型一起序列化保存部署时一起加载import joblib # 训练时 joblib.dump({model: model, scaler: scaler, feature_names: feature_names}, artifact.pkl) # 部署时 artifact joblib.load(artifact.pkl) model artifact[model] scaler artifact[scaler] assert feature_names artifact[feature_names], 特征顺序不一致把模型、scaler、特征名打包成一个 artifact是保证训练和推理一致性的最省心方式。任何单独保存、单独加载的做法都容易在版本迭代中出错。4.3 用特征快照对比锁定不一致如果怀疑特征不一致最直接的验证方法是特征快照对比在回测环境里对某个特定时间点把喂给模型的特征向量 dump 出来在生产环境里对同一个时间点如果数据可复现也 dump 一份然后逐字段对比。# 回测环境 snapshot_backtest { timestamp: 2024-01-15 09:30:00, features: {ma5: 12.34, ma20: 12.10, rsi: 55.2, volume: 1.2e6} } # 生产环境用相同的历史数据回放 snapshot_prod get_feature_snapshot(2024-01-15 09:30:00) for k in snapshot_backtest[features]: b, p snapshot_backtest[features][k], snapshot_prod[features][k] if abs(b - p) 1e-6: print(f不一致: {k} 回测{b} 生产{p})这个对比能精确定位到是哪个字段、差多少。我一般会挑几个关键时间点开盘、收盘、大幅波动日各做一次对比基本能覆盖大部分问题。5. 运行环境依赖版本、并发和资源限制的隐形影响特征对齐了模型也正常加载了但信号还是出不来这时候要把注意力转向运行环境。生产环境和回测环境在依赖版本、并发模型、资源限制上的差异同样会导致回测正常、上线异常。5.1 依赖版本漂移一个 numpy 小版本就能让你怀疑人生回测环境通常是你在本地或 notebook 里搭的依赖版本比较随意生产环境可能是容器化的依赖是锁定的。如果两边的 numpy、pandas、scikit-learn 版本不一致可能出现的问题包括浮点计算结果有微小差异、某些 API 行为变更、序列化格式不兼容。最典型的是模型序列化。用 joblib 或 pickle 保存的模型如果加载环境的库版本和保存环境不一致可能加载失败或者加载后行为异常。我遇到过 scikit-learn 0.24 保存的模型在 1.0 环境加载后 predict 输出全 NaN 的情况排查了大半天才发现是版本问题。解决办法很简单但必须执行用 lock 文件锁定依赖版本回测和部署用同一份 lock。Python 生态里pip-compile、poetry lock、conda env export都能做到。别嫌麻烦这一步能省掉后面无数个小时的排查。5.2 并发和状态多进程下的缓冲区共享问题如果你的流式特征计算用了缓冲区比如滑动窗口而部署时开了多进程或多线程那么每个进程会有自己独立的缓冲区导致窗口数据不完整。比如你开了 4 个 worker每个 worker 只收到 1/4 的数据滑动窗口永远填不满算出来的特征全是 NaN。这个问题的表现很迷惑单进程测试一切正常一上生产多 worker就没信号。排查方法是在特征计算函数里打印当前进程 ID 和缓冲区长度如果发现多个 PID 且缓冲区长度都很小基本就能确认是并发导致的状态隔离问题。解决方案有两种一是把特征计算收敛到单进程用消息队列串行化二是把缓冲区状态外置到 Redis 之类的共享存储。前者简单但吞吐受限后者复杂但可扩展。选哪种取决于你的数据频率低频场景分钟级、日级用单进程完全够用。5.3 资源限制内存、超时和静默失败生产环境通常有资源限制比如容器内存上限、推理超时时间。如果特征计算或模型推理超时很多框架会静默返回空结果而不是抛异常。这种情况下日志里可能只有一条 timeout 警告很容易被忽略。我的做法是给推理设置明确的超时并且超时后必须记录 ERROR 级别日志和告警绝不能静默返回空。同时监控推理耗时如果 P99 耗时接近超时阈值就要提前优化而不是等它真的超时。import signal class TimeoutError(Exception): pass def _timeout_handler(signum, frame): raise TimeoutError(inference timeout) signal.signal(signal.SIGALRM, _timeout_handler) signal.alarm(5) # 5秒超时 try: result model.predict(features) finally: signal.alarm(0)提示超时时间要根据回测时的推理耗时来定一般设为回测 P99 耗时的 3 到 5 倍既留足余量又能在真正卡死时及时暴露。6. 排查清单从没信号到定位根因的完整路径前面几章分别讲了数据链路、特征一致性、运行环境三个方向。这一章把它们整合成一份可执行的排查清单你可以在遇到回测有预测、部署没信号时按顺序走一遍。这份清单是我自己踩坑总结出来的按它走基本能在半小时内定位到根因。6.1 按优先级排序的排查步骤第一步确认模型是否被调用。看推理入口日志有没有打出来。没有就是调度/进程问题有就进入第二步。第二步确认模型输出是否为空。看推理出口日志输出是 NaN/None 还是正常值。为空就查特征和模型加载正常就进入第三步。第三步确认特征是否和回测一致。用特征快照对比逐字段核对。不一致就修特征计算一致就进入第四步。第四步确认信号是否被过滤。看信号生成逻辑里的阈值、风控、去重条件。被过滤就调整过滤逻辑或阈值没被过滤就进入第五步。第五步确认下游是否收到。看消息队列、数据库写入、下游消费日志。没收到就查下游链路。这个顺序的核心逻辑是从上游到下游、从模型到数据每一步都把问题范围缩小一半。千万不要跳步尤其是不要跳过第一步直接重训模型。6.2 常见根因和对应修复速查表根因典型表现修复方式调度未触发无推理日志检查 cron/定时任务配置模型加载失败推理日志有但输出 NaN检查 artifact 路径和依赖版本特征顺序错输出值异常但不报错加 schema 校验锁定特征顺序滑动窗口未填满冷启动阶段无信号预热缓冲区或跳过冷启动时区错位信号日期整体偏移全链路统一 UTC多进程状态隔离单进程正常多进程异常收敛到单进程或外置状态超时静默失败偶发无信号有 timeout 日志超时告警优化推理耗时阈值过滤过严有预测值但无信号调整阈值加过滤日志这张表建议收藏遇到问题先对照一遍能快速排除大部分常见原因。6.3 建立上线前一致性检查的工程习惯与其每次出问题再排查不如把排查前移建立一套上线前一致性检查流程。我的做法是影子回放用历史数据逐条喂流式特征模块和批处理结果对比误差必须小于阈值特征快照对比挑若干关键时间点对比回测和生产的特征向量依赖锁定回测和部署用同一份 lock 文件探针日志推理前后各一条结构化日志永久保留schema 校验推理入口强制校验特征字段、顺序、类型、范围。这五条做下来上线后没信号的概率会大幅下降。即使真的出了问题也能在几分钟内定位到具体环节而不是盲目重训模型。7. 关于要不要重训这件事我的实际经验回到标题那句话——先别急着重训。我不是说模型永远不需要重训而是说在没搞清楚没信号的根因之前重训是纯粹的浪费。模型重训解决的是模型预测能力不足的问题而回测有预测、部署没信号绝大多数情况下根本不是预测能力问题而是工程链路问题。你重训一百遍链路不通信号照样出不来。我自己有个判断标准如果回测里模型输出正常、指标正常那模型本身大概率没问题问题在工程侧。这时候应该把精力全部放在数据链路、特征一致性、运行环境上而不是回头去调模型超参。反过来如果回测里模型输出就不稳定、指标忽高忽低那才需要考虑模型本身的问题。还有一个经验是把回测环境和生产环境的差异当成一等公民来管理。每次上线前明确列出两边在数据源、依赖版本、时间处理、并发模型上的所有差异逐条确认影响。这个习惯养成之后你会发现回测正常、上线异常的问题越来越少因为大部分坑在差异清单里就已经被提前识别了。最后分享一个小技巧在生产环境保留一个回放模式可以用历史数据完整跑一遍推理链路输出和回测对比。这个模式平时不用但一旦出问题能让你在几分钟内复现并定位比在生产环境里大海捞针高效得多。我现在的每个策略上线时都会带上这个回放开关已经成了标配。