点时数据不是历史快照：用双时间轴避免回测偷看修订值

点时数据不是历史快照：用双时间轴避免回测偷看修订值

量化回测中的未来函数不只来自错误的shift。更隐蔽的情况是：研究者下载了一份今天看来完整、正确的历史表，然后默认这些数值在过去当时也已经可见。财务数据会延迟发布，宏观数据可能修订，指数成分和分类标签也会变化。如果回测直接读取最新版本，模型就会使用决策时点尚未出现的信息。

解决办法不是给文件名加上日期，而是明确区分两个时间：event_time表示数据描述的业务期间，available_at表示系统何时真正获得该版本。回测查询必须同时回答“研究哪个期间”和“在决策时点能看到哪个版本”。这种设计通常称为点时数据或双时间轴模型。

参数和假设说明

• 示例使用人工构造的季度指标，不对应任何公司、证券或真实数据源。
• • period是指标所属期间，available_at是该版本可以进入模型的最早时间。
• • 同一期间允许存在多个版本；查询时选择决策时点以前已经到达的最新版本。
• • 日期只精确到天，并假设数据在available_at当日开盘前可用。真实项目应记录具体时区和发布时间。
• • 缺少可用版本时返回None，策略必须显式处理，不能使用未来版本或默认填零。
• • 示例只演示可见性，不处理币种、单位、合并范围和会计口径变化；这些字段在生产数据中同样需要版本化。

可运行 Python 示例

下面代码只依赖标准库。数据表故意包含一次晚到的初始发布和一次后续修订，用断言证明早期决策看不到修订值。

fromdataclassesimportdataclassfromdatetimeimportdate@dataclass(frozen=True)classFact:period:stravailable_at:date version:intvalue:floatfacts=[Fact("2025Q3",date(2025,10,25),1,98.0),Fact("2025Q4",date(2026,1,28),1,101.0),Fact("2025Q4",date(2026,3,12),2,99.5),# 后续修订Fact("2026Q1",date(2026,4,29),1,103.0),]defvisible_value(rows,period,decision_time):candidates=[rowforrowinrowsifrow.period==periodandrow.available_at<=decision_time]ifnotcandidates:returnNoneselected=max(candidates,key=lambdarow:(row.available_at,row.version))returnselected.value jan_value=visible_value(facts,"2025Q4",date(2026,2,2))apr_value=visible_value(facts,"2025Q4",date(2026,4,1))too_early=visible_value(facts,"2026Q1",date(2026,4,15))assertjan_value==101.0# 当时只能看到初始版本assertapr_value==99.5# 修订发布后才能看到修订值asserttoo_earlyisNone# 不能提前读取尚未发布的季度数据print("2026-02-02 可见值:",jan_value)print("2026-04-01 可见值:",apr_value)print("提前查询结果:",too_early)

为什么普通历史表会产生偏差

假设数据库只保留2025Q4 = 99.5这一最终结果。今天查询没有问题，但在 2026 年 2 月的回测中使用它，就相当于提前知道了 3 月才发布的修订。即使信号代码严格延迟一期，输入本身已经穿越时间，回测仍然失真。

另一种常见错误是把业务期间结束日当成可用日。季度在 12 月结束，并不意味着 12 月 31 日就能得到完整指标。回测需要使用数据源真实发布时间；若只知道日期而不知道盘前或盘后，应采用保守约定，并在成交时再延迟一个交易时段。

数据模型与查询接口

生产表至少应包含业务键、event_time、available_at、版本号、数值、单位、来源和批次哈希。原始版本不能被后续修订覆盖。查询接口应强制要求as_of参数，避免调用者无意中获取最新值；“获取最新数据”和“按历史时点查询”最好使用不同函数名和权限。

数据入库时间也不一定等于公开时间。如果供应商晚到、补发或重新抓取，系统应同时保留来源公布时间和本地接收时间。严格回放可以取两者较晚值，因为模型不可能使用尚未进入自身系统的数据。时区转换必须在入口完成，夏令时和交易日历不能依靠字符串排序猜测。

建议为每个数据源建立版本回放测试：固定一个过去决策日，保存当时应该可见的记录集合和结果哈希；数据管道升级后重新运行，若集合变化就必须解释来源。变化可能来自正确的错误修复，也可能来自供应商静默覆盖。无论原因是什么，都不能只接受新的回测曲线而不追踪差异。对于派生特征，还要保存原始记录标识和计算版本，使一个信号能够反向定位到具体输入，而不是只保留难以审计的最终矩阵。

常见错误

第一，下载最新 CSV 后覆盖旧文件，丢失修订链。第二，用期间结束日代替发布时间。第三，先对全样本填补缺失值，再切分训练和测试，使未来分布反向影响过去。第四，指数回测使用今天的成分列表，忽略过去已退出的资产。第五，基本面字段发生单位或定义变化，却仍当作同一连续序列。

还有一种工程错误是缓存键缺少as_of。第一次查询最新值后，缓存可能把结果错误地返回给历史时点请求。缓存键必须包含业务键、决策时间和数据版本；测试中应覆盖“修订前、修订后、尚未发布”三个边界。

风险控制说明

点时数据错误会系统性放大模型表现，因此应设置硬性质量门：关键字段缺少available_at、版本倒退、发布时间晚于回测决策却被使用，任何一项出现都应停止生成新信号。每次回测保存数据快照哈希和查询参数，确保结果可以重放。

模型上线后还要监控数据延迟、修订频率和缺失率。如果最新批次明显晚于正常时间，不应自动沿用陈旧数据扩大仓位。数据恢复后也不能立即追补历史信号，因为实盘当时并未拥有这些信息；正确做法是从恢复时点继续，并记录缺失期间的影响。

回测与实盘差异

回测可以反复查询历史，而实盘只能沿时间向前。要缩小差异，研究环境应通过同一个点时查询接口获取数据，并在影子运行中逐日记录“当时可见版本”。之后发现供应商修订时，可以比较新旧版本对信号的影响，但不能把修订结果改写成当时已经知道的事实。

点时正确也不代表策略有效。费用、滑点、成交容量、停牌和订单状态仍需独立建模。本文示例仅验证数据可见性，不是实盘成绩，也不提供任何资产选择或仓位建议。

总结

可信回测必须同时管理业务时间和可用时间。保留每个版本、强制as_of查询、对修订前后编写断言，才能阻止最新数据悄悄进入过去。与复杂模型相比，先把信息可见性做对往往更重要：输入时点错误，再精确的计算也只是在放大偏差。

风险提示

本文仅用于量化交易技术研究和编程交流，不构成任何投资建议。历史表现和回测结果不代表未来收益，投资有风险，决策需谨慎。