跳到主要内容

FinBayes → DH 需求：macro 发布感知（发布日历 + 序列端点）

本文给 DH 负责人 / DH 执行角色 / FinBayes 团队。FinBayes 数据层「实时数据及时性」第 2 刀（macro 发布感知）已定向「优先 DH、不内化 FRED、等 DH R2」，本文把所需的 DH R2 能力整理成可评审输入。请 DH 给 accept / reject + R2 时间预期。

背景：一个正在伤用户的 live 洞​

FinBayes 被问「美国最新核心 PCE 同比多少」时，把一个还没发布的月份当成已公布事实报了（今天若是 6-25、5 月 PCE 约 6-27 才发布，agent 却报「5 月 3.4%」，数来自一次 web_search、无法证伪）。根因在数据能力、不在模型：

  • DH /macro/latest（已上线）给：当期值 + as_of（参考期）。够好，FinBayes 不需内化这块。
  • 但缺两样，正是堵这个洞要的：① 下次发布日期（知道「5 月还没出」）；② 同比（/latest 是点值、读不出同比，要序列）。

本需求当时选择不内化 FRED、给 DH 提需求并等待 R2，原因是 DH 已有相关 FRED 实践、短期重复建设价值不足。该 workload decision 继续有效，但不再继承“DH 是过渡桥”的旧候选口径；未来是否走 DH、FinBayes 内化或双轨，按 ADR-033 的 evidence-driven sourcing 重新判断。

请 DH 落地（R2）​

  1. /calendar + 每指标 nextReleaseDate（头号）：对每个 macro 指标，给出「下次发布日期 / 时间」+「最近一次发布日期」。FinBayes 用它精确告诉用户「<指标> 下次 <日期> 发布、当前最新是 <参考期>」，彻底堵「报未发布数」。（DH 路线图已列 /calendar / /events 在建——本文把它顶成 FinBayes 的硬需求。）
  2. 序列 / 历史端点（供自算同比）：/macro/latest 之外，补一个能拉「单指标近 N 期序列」的端点（或在 latest 里带上一期 / 12 期前值）。FinBayes 据此算同比（现在读不出、只能 web 抓个可能错的数）。
  3. R2 时间预期：给个大致落地窗口，FinBayes 据此决定过渡期撑多久。

FinBayes 这边的过渡（不等 DH、先止血）​

DH R2 落地前，FinBayes 用已有的 as_of（DH /latest 已给）做发布感知：若用户问「刚发布的最新一期」而手里最新 as_of 还停在上一期，就老实说「我这边最新是 <as_of> 那期、更新的还没进源」，绝不报未发布值。这堵住核心洞，但不如 DH 给 nextReleaseDate 精确（过渡期说不出「下次 6-27 发布」）。所以 R2 仍是要的。

边界 / 不变量​

  • FinBayes 判断仍自己出（DH 给数据、不给解读）；出处信封 as_of = 参考期、绝不拿 fetch-time 冒充。
  • 这是对既有 macro 能力 ADR（forecast / nextReleaseDate 已延后）的催落，不改既定分工。
  • forecast / 共识不在本需求内（免费世界无干净源、FinBayes 侧也延后）。

关联​