TFB 完整架构总讲解

Abstract

这篇只做一件事：

把你前面拆开的主线，重新压成 TFB 的完整架构。

1. 第一性

TFB 的第一性不是“实现一个模型”，而是：

把数据、模型、评测策略、结果记录统一组织起来，形成可复用的时间序列 benchmark 框架。

所以 TFB 不是：

• 单个模型库
• 单个训练脚本
• 单次实验代码

而是：

一个统一调度时间序列实验的框架壳。

2. 一张总图

这张图表达的是：

1. run_benchmark.py 不是模型本身
2. pipeline(...) 也不是模型本身
3. 真正模型计算发生在更深层
4. 结果记录和模型实现是解耦的

3. 抽象索引树

这棵树不是执行顺序图。
它是给人脑建立索引用的。

4. 顺序主链

如果只看你现在已经走通的最小 benchmark 主链，它可以压成：

这条链回答的是：

代码实际怎么一步一步往下走。

5. 五层架构

5.1 入口层

文件：

• run_benchmark.py

职责：

• 接收命令行参数
• 读取 config
• 构造：
  • data_config
  • model_config
  • evaluation_config
  • report_config
• 调 pipeline(...)
• 调 report(...)

输入接口：

• 命令行参数 args

输出接口：

• log_file_names
• 报表输出

这一层回答的是：

这次实验要跑什么。

5.2 实验组织层

文件：

• pipeline.py

职责：

• 准备数据侧
• 准备模型工厂
• 调评测任务
• 收集日志文件

输入接口：

• data_config
• model_config
• evaluation_config

输出接口：

• log_file_names

这一层回答的是：

整场 benchmark 怎么被组织起来。

5.3 单任务评测层

文件：

• evaluate_model.py
• forecasting.py
• rolling_forecast.py

职责：

• 把“一个模型 + 一条序列 + 一种 strategy”组织成单任务
• 切 train/test
• 决定何时 fit
• 决定何时 predict
• 决定如何打分

输入接口：

• model_factory
• series_list
• evaluation_config

输出接口：

• EvalResult
• single_series_results

这一层回答的是：

单条时间序列上的实验协议是什么。

5.4 模型接入层

文件：

• model_loader.py
• adapters_for_transformers.py
• deep_forecasting_model_base.py

职责：

• 根据配置找到模型类
• 用 ModelFactory 延迟创建模型对象
• 用 adapter 统一输入输出接口
• 提供：
  • forecast_fit(...)
  • batch_forecast(...)
  • _process(...)

输入接口：

• 模型配置
• 统一四元组 batch

输出接口：

• 底层模型对象
• 标准化训练/预测入口

这一层回答的是：

不同模型怎样被统一接进框架。

5.5 模型实现层

文件：

• DLinear.py
• Informer.py
• time_series_library/models/*.py
• time_series_library/layers/*.py

职责：

• 定义模型结构
• 定义 forward(...)
• 真正进行数值计算

输入接口：

• 统一的模型输入签名

输出接口：

• (B, pred_len, C) 或任务对应输出

这一层回答的是：

模型本身怎么算。

5.6 结果层

文件：

• evaluator.py
• recording / report / leaderboard 相关模块

职责：

• 计算指标
• 收集任务结果
• 写日志
• 出报表

输入接口：

• actual
• predicted
• 任务结果对象

输出接口：

• csv/tar.gz 日志
• leaderboard / report

这一层回答的是：

实验结果怎么被度量和保存。

6. 你现在在这张架构图上的位置

你现在不是停在最外层，也不是只会看单个模型。

你当前的位置更准确地说是：

已经打通了从入口层一直到模型实现层的一条最小主链。

你已经真正走过的节点有：

• run_benchmark.py
• pipeline(...)
• eval_model(...)
• ForecastingStrategy.execute(...)
• RollingForecast._eval_batch(...)
• forecast_fit(...)
• batch_forecast(...)
• _process(...)
• DLinear.forward(...)

你已经开始挂上的第二个模型分支是：

• Informer

7. 这套架构为什么适合当科研脚手架

因为它把几类变化源分开了：

数据变化

• 换数据集
• 换 feature 数
• 换频率

任务协议变化

• rolling_forecast
• fixed_forecast

模型变化

• DLinear
• Informer
• PatchTST

结果度量变化

• metric 组合
• report 形式

也就是说：

你改一个维度时，其他维度尽量不动。

这正是科研脚手架最重要的性质。

8. roadmap 的道理

你前面的 roadmap 本质上是：

1. 先打通一个 1 x 1 最小例子
2. 建立主线和层级
3. 再扩成分支树

这不是绕路，而是为了避免一开始就掉进：

• 单模型细节
• 单函数细节
• 单次实验细节

现在你已经完成了第 1 步和大部分第 2 步。

9. 你接下来该怎么做

按当前 roadmap，下一步最优先的是：

第一步

先稳定这张完整架构图。

目标是你自己能口头说出这五层：

1. 入口层
2. 实验组织层
3. 单任务评测层
4. 模型接入层
5. 模型实现层
6. 结果层

第二步

再做模型分支扩展：

• DLinear -> Informer

而不是先换 strategy。

第三步

等 Informer 也挂到这张架构图上以后，再扩：

• rolling_forecast -> fixed_forecast

10. 最后压成 8 句话

1. TFB 是 benchmark 框架，不是单个模型实现。
2. 它的核心是把数据、模型、评测、结果记录解耦。
3. run_benchmark.py 负责入口和配置。
4. pipeline(...) 负责组织整场实验。
5. eval_model / strategy 负责组织单条序列上的评测任务。
6. ModelFactory / adapter / DeepForecastingModelBase 负责统一接入不同模型。
7. DLinear / Informer / PatchTST 这些模型真正位于最深层的实现层。
8. 你现在已经可以开始从这张架构图出发，扩 Informer 分支了。