4. Point-in-Time核心概念
在另类数据进入量化研究流程之后，最先被低估、也最容易造成灾难性后果的问题，往往不是数据本身的质量，而是数据在时间维度上的对齐方式。Point-in-Time（PIT，时点对齐）正是解决这一问题的核心方法论。它要求我们在任何一个历史时刻做决策时，只能使用那个时刻真实可获得的信息，而不能使用后来才被披露、修订或补录的信息。
一、PIT数据的定义
PIT数据，指的是按照信息在真实世界中“首次可被获取”的时间戳进行组织的数据。它记录的不只是“数值是多少”，还包括“这个数值在什么时候第一次出现、什么时候被修订、修订前后的版本分别是什么”。
一个典型的PIT数据记录通常包含以下字段：
{
"entity_id": "AAPL",
"field": "monthly_active_users",
"value": 102.3,
"period": "2023-06",
"knowledge_date": "2023-08-14", // 该数值首次可被外部获取的日期
"effective_date": "2023-06-30", // 数值所描述的业务期末
"revision_id": 1,
"source": "app_analytics_v2"
}其中最关键的是 knowledge_date（知识日期），它决定了这条数据在回测中最早可以被使用的时点。与之相对的 effective_date（生效日期）描述的是业务事实发生的时间，两者之间的差距就是所谓的信息滞后。
二、为什么需要PIT
另类数据的一个显著特征是：它的披露时间与业务发生时间往往存在明显错位。卫星图像、App下载量、信用卡消费、招聘岗位数等数据，通常需要经过采集、清洗、聚合、供应商加工等多个环节，才能最终到达研究者的数据库。如果忽略这一过程，直接按业务期末对齐，就会在回测中引入未来信息。
需要PIT的根本原因可以归纳为三点：
- 披露滞后：数据从产生到可用存在天然延迟，且延迟长度不稳定。
- 历史修订：供应商会回溯修正历史值，导致同一业务期在不同时间点看到不同数值。
- 实体变更：股票代码、公司结构、行业分类会随时间变化，必须按当时状态匹配。
三、PIT与历史快照的区别
很多人会把PIT数据与历史快照（snapshot）混为一谈。两者确实相关，但关注点不同。历史快照强调的是“在某个时间点，数据库里存了什么”；PIT强调的是“在某个时间点，外部世界真实可获取什么”。快照是存储实现手段，PIT是语义约束。
| 对比维度 | 历史快照 | Point-in-Time数据 |
|---|---|---|
| 核心问题 | 某时刻数据库存了什么 | 某时刻外部真实可获得什么 |
| 时间戳依据 | 入库时间 / 快照时间 | 知识日期（首次可获取时间） |
| 是否处理修订 | 通常只保留最新版本 | 保留多版本及修订链 |
| 回测安全性 | 依赖快照频率，可能仍有泄漏 | 按知识日期过滤，泄漏风险可控 |
| 典型实现 | 每日全量dump | 双时间轴（生效时间+知识时间） |
换句话说，历史快照是“我们曾经看到过什么”，而PIT是“我们在当时被允许看到什么”。前者是工程记录，后者是研究纪律。
四、PIT在回测与实盘中的重要性
PIT的价值在回测与实盘两个环节中体现得最为直接。回测中，如果使用了未来才披露的数据，策略表现会被系统性高估，形成“纸面Alpha”。实盘中，如果训练与推理的信息集不一致，模型会在上线后迅速失效。
一个常见的错误做法是：用月度业务期末直接对齐交易信号。例如用2023年6月的App活跃用户数，在2023年7月1日就生成买入信号。但该数据可能直到8月中旬才被供应商发布，这意味着回测中使用了约六周的未来信息。
正确的PIT流程通常包括以下步骤：
- 为每条数据记录标注知识日期，并保留修订版本链。
- 在回测引擎中，按“当前模拟时间 >= 知识日期”过滤可用数据。
- 对实体映射（股票代码、行业分类）同样使用PIT版本。
- 在实盘推理时，复用同一套知识日期过滤逻辑，确保训练与推理一致。
- 定期做泄漏审计，对比PIT与非PIT回测的差异，量化泄漏影响。
五、常见误区与复盘
在实际项目中，PIT落地最常见的误区有三个。第一，把“数据入库时间”当作知识日期，但入库时间往往晚于供应商实际发布时间，导致过度保守；第二，只对价格数据做PIT，却忽略了基本面、另类数据和实体映射；第三，认为日频快照就等于PIT，但快照本身可能已经覆盖了修订后的值。
复盘时可以用一个简单的问题检验：“如果我在那个历史时刻真实地运行这套策略，我能否拿到这条数据？” 如果答案不确定，就说明PIT对齐还不够严格。PIT不是一次性的数据工程任务，而是贯穿研究、回测、上线全流程的纪律约束。