做时间序列预测，有一种结果特别容易让人高兴过头：模型一跑，Accuracy漂亮得不像话，R²高得像开了挂。先别急着截图发给导师，学姐通常会先问一句：你的模型是不是偷偷看见“未来”了？这就是Time Series里很容易被忽略的Data Leakage。这项研究没有单纯让LLM疯狂生成Features，而是给它加了一条很重要的规矩：预测发生时还不知道的数据，不能直接拿来训练；但这些变量过去已经发生的历史值，可以通过Historical Aggregation重新利用。这个思路看起来只是Feature Engineering里的一个小细节，其实决定了实验结果到底是真本事，还是“提前看了答案”。
Data Leakage到底有多冤？模型可能自己都不知道作弊了
先举论文里的Tesla例子。
假设任务是在当天开盘以后预测Tesla收盘价。此时Open Price已经知道，可以作为输入；但当天的High、Low、Volume和最终Close还没有完整发生。
如果把这些变量直接放进模型，问题就来了：你嘴上说自己在“预测今天收盘”，实际上已经把今天交易结束以后才知道的信息塞给模型。
模型不是突然变聪明了，而是考试之前不小心拿到了答案。
这也是为什么时间序列的Feature Engineering不能只问“这个变量和Target相关吗”，还得再问一句：Prediction Time到了没有？当时真的能看到这个变量吗？
这项研究最聪明的地方：不直接删掉“未来变量”
最简单的防泄漏方法当然是：凡是预测以后才能知道的变量，全部Delete。
安全是安全，就是有点浪费。
这项研究把Features按照Temporal Availability分成三类：
| Feature类型 | 含义 | 能不能直接用 |
|---|---|---|
| Antecedent Features | 预测发生前已经知道 | 可以 |
| Consequent Features | 预测以后才产生 | 当前值不可以 |
| Historical Aggregated Features | 利用严格过去的数据生成 | 可以 |
关键来了。
假设今天的Trading Volume还不知道，不能拿来预测今天；可是过去5天、20天、240天的Volume早就已经发生了。
所以框架没有把Consequent Variable永久扔进垃圾桶，而是让它进入Historical Aggregation Pipeline，用严格早于当前时点的数据计算Rolling Mean、Previous Value、Rolling Min/Max等特征。
于是：
Future Value ✕ → Past Values ✓ → Historical Aggregation ✓
这才是这篇研究真正值得看的创新点。
LLM在这里不是“预测大师”，而是Feature Engineer
很多人看到LLM论文，会下意识以为作者直接问GPT：“明天Tesla涨不涨？”
并不是。
研究中的LLM主要负责理解Dataset Description、Column Semantics、Prediction Task和Temporal Constraints，然后生成结构化的Feature Engineering Configurations。
整个流程可以简单理解成：
Dataset Description → Temporal Rules → LLM生成Feature配置 → Historical Aggregation → Feature Selection → Predictive Model
研究使用GPT-4o生成配置，并把Temperature设置为0.0以减少输出波动。生成过程分成Antecedent、Consequent和Historical Aggregation三个阶段，而且要求返回结构化JSON。
这点对做Machine Learning论文挺有启发：LLM不一定非要当最终预测模型。它也可以负责理解字段语义、辅助构造候选特征，再由XGBoost、Logistic Regression等传统模型完成预测。
Tesla和英超两个实验，结果怎么样？
研究故意选了两个完全不同的任务。
| 实验 | Tesla | English Premier League |
|---|---|---|
| 任务 | Stock Prediction | Match Outcome Prediction |
| 样本 | 3473个交易日 | 4531场比赛 |
| 模型 | XGBoost | Multiclass Logistic Regression |
| 主要指标 | MAE、R² | Accuracy、Precision、Recall、F1 |
Tesla实验一共生成412个候选特征，最后只留下9个。这个结果其实很值得注意：LLM给你400多个Idea，不代表400多个都值得留下。真正靠谱的流程必须经过Validation。
以Percentage Change作为Target再投射回Close Price时，Baseline MAE为5.1261，加入筛选后的LLM特征后下降到4.9963，R²从0.9698提高到0.9709。
EPL实验生成318个候选特征。最终模型Accuracy从Odds-only Baseline的56.45%提高到57.86%，也略高于研究引用的Azure ML结果57.09%。
这些提升没有夸张到“AI重新定义时间序列预测”，反而让我觉得更可信。论文自己也承认：它主要证明的是Leakage-safe Automation Framework有价值，而不是宣布拿到了State-of-the-art。
做Time Series论文，我会先检查这5件事
| 检查项 | 最容易犯的错误 | 更稳妥的做法 |
|---|---|---|
| Prediction Time | 没定义什么时候预测 | 先确定预测时点 |
| Feature Availability | 相关就全部塞进去 | 逐列判断当时是否可获得 |
| Rolling Features | 窗口包含当前或未来数据 | 只使用严格过去Observation |
| Data Split | 随机Train/Test Split | 优先Chronological Split |
| Feature Selection | 反复看Test结果挑Feature | Train/Validation/Test分开 |
还有一个很漂亮的细节：研究自己在Robustness Analysis里承认，随机90%训练数据的Subsampling并没有严格保持Temporal Order，因此可能让未来Observation进入Training Fold。作者没有把这一部分包装成完美验证，而是明确说未来更适合采用Walk-forward Validation。
这种Limitations反而值得学习。Discussion不是替自己的模型写表扬信，主动告诉读者“这里还有什么没解决”，通常比硬吹模型更像一篇成熟研究。
这篇案例真正值得带走的一句话：
时间序列Feature Engineering首先要解决的不是“能生成多少Features”，而是这些Features在预测发生的那一刻是否真的存在。LLM可以帮助理解字段语义和设计复杂转换，但Temporal Availability仍然需要明确约束。一个MAE稍微差一点但没有Data Leakage的模型，往往比一个指标漂亮得离谱、却偷看了未来的模型更有研究价值。
FAQ
Q：Data Leakage是什么意思？
简单说，就是训练或构造Features时使用了真实预测场景下本来无法获得的信息，导致测试结果被虚假抬高。
Q：Time Series为什么特别容易Data Leakage？
因为数据存在明确时间顺序。某个字段本身没有问题，但如果它是在预测事件之后才产生，把当前值作为输入就可能泄漏未来信息。
Q：Consequent Feature是不是必须删除？
不一定。当前值不能直接使用，但过去已经发生的值可以在满足时间约束的情况下用于Lag、Rolling Mean、Rolling Max等Historical Features。
Q：LLM Feature Engineering和传统AutoML有什么区别？
这类方法的优势之一是LLM可以结合Column Semantics和Task Context推理，而传统自动化工具更多依赖预定义Transformation。不过LLM生成的Feature仍然必须经过Validation，不能因为是LLM提出的就默认有效。
Q：为什么时间序列不建议随便Random Split？
因为随机切分可能让较晚的数据进入Training、较早的数据进入Test，破坏真实的时间预测关系。Chronological Split或Walk-forward Validation通常更符合实际预测场景。
Q：LLM生成越多Features越好吗？
不是。这项Tesla实验生成412个候选Feature，最终只保留9个。候选特征数量和最终模型质量完全不是一回事。
本文结合公开发表的Time Series LLM Feature Engineering研究进行方法解析，实验数据用于理解Feature Engineering、Temporal Data Leakage与Historical Aggregation设计。