AdapTime: Enabling Adaptive Temporal Reasoning in Large Language Models¶

会议: ACL 2026
arXiv: 2604.24175
代码: https://github.com/Applied-Machine-Learning-Lab/ACL2026-AdapTime
领域: NLP 理解 / LLM 推理
关键词: 时间推理, 时序问答, 自适应规划, LLM Planner, 无外部工具

一句话总结¶

本文提出 AdapTime，把"时间推理"抽象为 reformulate / rewrite / review 三个可复用的原子动作，由 LLM Planner 根据问题与上下文自适应决定执行哪几步、按什么顺序执行，无需任何外部工具、手工规则或微调即可显著提升 LLM 在时序 QA 上的表现，在 DeepSeek-V3 上把 TimeQA-Easy 推到 85.4 EM。

研究背景与动机¶

领域现状：时序问答（Temporal QA）要求模型从含时间标注的文档中回答时间相关问题，如 "Terence Cooper 在 1966 年 3 月到 1969 年 10 月之间担任什么职位？"。现有方案大致两类——一类靠外部工具（QAaP 用 Python 字典做 check/match、Event-AL 用 Python 求解器、Step-back 用 retriever），另一类靠人工干预（Time-CoT 手工补 timeline、TG-LLM 手动修正难例的 temporal graph、TISER 同样依赖 TG）。

现有痛点：(1) 外部工具与人工规则使方法绑定到特定数据/场景，换 benchmark 就要重写；(2) 现有 pipeline 都是固定流程——对所有问题都按同一套"提取-推理-验证"顺序跑一遍，无视问题难度的差异。结果就是简单题被过度处理（推理冗余、引入错误），复杂题又因步骤不够而推不出来。

核心矛盾：时序问题的复杂度方差极大——"美国总统是谁"这样的简单查询和"在某个时间段内某人担任什么职位"这样的多跳推理本质上应该走不同的推理路径，但传统 fixed pipeline 强行用同一套流程处理所有问题。

本文目标：(1) 抽出一组LLM 自身就能完成的原子时序动作，去掉对外部工具/人工的依赖；(2) 让 LLM 自己根据问题特性决定调用哪些动作、按什么顺序，做到 per-instance 的自适应推理。

切入角度：作者发现现有方法虽然形式各异，本质都在做三件事之一——把复杂问题拆成子问题、把隐式时间表达改写成结构化形式、对答案做事实核验。如果这三件事都能由 LLM 自己 prompt 完成，那么外部工具就成了多余的。

核心 idea：定义 reformulate / rewrite / review 三个动作 + 一个 LLM Planner，让 Planner 根据问题与中间状态在线决定每步是否执行该动作，把"固定 pipeline"升级成"自适应规划"。

方法详解¶

整体框架¶

AdapTime 由 4 个模块组成：3 个原子推理动作（Reformulate / Rewrite / Review）+ 1 个 LLM Planner。给定文档 \(C\) 和时序问题 \(Q\)，Planner 先决定是否要把 \(Q\) 拆解为子问题序列 \(\{q_1,\ldots,q_n\}\)；接着判断是否要把 \(C\) 重写为以时间为锚的结构化表示；然后对每个子问题在重写后的上下文上生成答案 \(A_i\) 并聚合；最后由 Planner 判断对答案信心是否足够，决定是否触发 Review 做事实核验。整套流程不调用任何外部 API、不依赖任何手工规则。

关键设计¶

三个原子时序推理动作：
- 功能：把已有 temporal reasoning 方法的核心操作抽象为 LLM 可自主完成的最小动作集，覆盖"问题分解 / 上下文改写 / 答案核验"三种基本能力。
- 核心思路：(a) Reformulate——prompt LLM 把含复杂时间约束或多跳的问题分解为 \(Q=\{q_1,\ldots,q_n\}\)，每个 \(q_i\) 单点可答，最终答案由子答案聚合得到，例如 "Cooper 在某时间段担任什么职位" 被拆成 "Cooper 担任过哪些职位"+"哪个职位的时间区间覆盖目标时段"；(b) Rewrite——prompt LLM 把"during his presidency""after the war ended"这种隐式时间表达改写成以日历日期为锚的显式时间线（code/timeline/temporal graph 任一形式），下游模块就能直接在时间锚定的事实上推理；(c) Review——prompt LLM 检索能支撑当前答案的原文句子，若证据缺失或冲突则修正答案。
- 设计动机：这三个动作覆盖了 QAaP / Time-CoT / Event-AL / TG-LLM / TISER 的所有关键操作，但每个都纯 prompt 实现，去掉了对 Python interpreter / 手工 timeline / 难例标注的依赖；同时三个动作正交解耦，可任意组合。
LLM Planner 自适应规划：
- 功能：根据问题的语义结构、上下文的时序复杂度、以及模型对中间答案的信心，动态决定执行哪些动作、是否跳过某些步骤。
- 核心思路：Planner 同样是 LLM prompt（与执行用同一个 backbone），在每个潜在动作点都调用一次：先看 \(Q\) 是否含多跳→决定是否 Reformulate；再看 \(C\) 的时间表达是否模糊或分散→决定是否 Rewrite；最后看初始答案的可信度→决定是否 Review。决策以自然语言形式给出（"是 / 否 + 简短理由"），不强制走完所有步骤。算法 1 给出了完整伪代码：每一步都被 Planner 的二元决策 \(d_i\) 门控。
- 设计动机：固定 pipeline 在简单问题上做"过度推理"反而引入噪声，在难题上又力不从心；让 Planner 看一眼问题再决定走多深，能把推理预算花在真正需要的地方。论文统计图 3 显示：TimeQA 上 Reformulate 频率高（多为可拆解的多跳），TempReason-L2/L3 上 Rewrite + Review 频率显著高于 TimeQA（时间线复杂、初始答案可信度低）。
基于内置能力的 zero-tool 推理：
- 功能：所有动作、所有决策都由 LLM 自身能力完成，不调用任何外部工具/retriever/symbolic solver。
- 核心思路：把过去用 Python interpreter 做的"事实匹配"改成 prompt LLM 检索原文支撑句子；把过去用 retriever 做的"长文档压缩"改成 prompt LLM 把相关段落改写为时间线表示；把过去靠人工补的难例标注改成 prompt LLM 重新分解问题。
- 设计动机：依赖外部工具是当前 temporal QA 方法泛化性差的根本原因——一旦换 domain 或换数据源，工具/规则就需要重新搭建。把所有能力收回到 LLM 内部，方法就能 zero-shot 迁移到新场景（论文在 SWE-bench 风格的 ArchivalQA 开放域上 work 也佐证了这一点）。

损失函数 / 训练策略¶

完全免训练，只用 prompt 调度。decoding 用 top-k=10，temperature=0.7，batch_size=1，max_new_tokens=512。论文还尝试用 1000 条 DeepSeek-V3 生成的高质量 plan 蒸馏一个 LLaMA-3-8B 监督 Planner，反而比 prompt-based Planner 差（TimeQA-Easy 31.0 vs 41.5 EM），说明 in-context 规划能力比 fine-tuned 规划器更鲁棒、不易过拟合。

实验关键数据¶

主实验¶

两个 benchmark：TimeQA（easy/hard，显式 vs 隐式时间）+ TempReason（L2 时间-事件对齐 / L3 事件间时序），各采样 1000 题。三个 backbone：LLaMA-3-8B、Qwen-3-8B、DeepSeek-V3。指标：EM + F1。

模型	方法	TimeQA-Easy EM	TimeQA-Hard EM	TempReason-L2 EM	TempReason-L3 EM	Avg EM
GPT-4 (闭源参考)	–	71.6	54.6	45.4	43.1	54.3
TG-LLM (SOTA 参考)	–	66.4	63.1	42.4	35.6	51.9
LLaMA-3-8B	ICL	1.1	1.7	3.8	1.8	2.1
LLaMA-3-8B	CoT	29.7	31.6	18.5	16.5	24.1
LLaMA-3-8B	AdapTime	41.5	33.3	18.7	14.5	27.0 (+24.9)
Qwen-3-8B	CoT	69.4	62.9	22.6	28.8	45.9
Qwen-3-8B	AdapTime	72.7	66.5	29.1	28.8	49.3 (+6.4)
DeepSeek-V3	CoT	85.3	75.6	44.8	47.0	63.2
DeepSeek-V3	Step-back	84.4	76.4	45.8	48.8	63.9
DeepSeek-V3	Self-refinement	77.6	76.4	44.3	41.1	60.1
DeepSeek-V3	AdapTime	85.4	77.7	48.0	49.8	65.1 (+5.5)

消融实验（DeepSeek-V3）¶

配置	TimeQA-Easy EM	TempReason-L3 EM
Full AdapTime	85.4	49.8
w/o Reformulate	85.0	48.9
w/o Rewrite	84.8	47.6
w/o Review	84.8	49.0
w/o LLM Planner（固定执行三步）	85.3	48.9

关键发现¶

Rewrite 贡献最大：单独加 Rewrite 把 ICL baseline 从 80.8 拉到 86.4 EM，去掉 Rewrite 也是掉点最多的——说明"显式时间锚定的上下文表示"对 LLM 的时序推理最关键。
Planner 价值在难数据上凸显：在 TimeQA-Easy 上 w/o Planner 几乎不掉点（强行三步也 work），但在 TempReason-L2/L3 这种需要灵活选择步骤的复杂任务上 Planner 提供稳定的 0.5–1 EM 提升。
token 预算几乎不增：AdapTime 平均 4873 tokens/instance，仅比 ICL（4345）多 12%，远低于 self-refinement 的 >10000 tokens——说明 Planner 的"按需触发"确实节省了开销。
跨规模一致提升：在 1B → 8B → V3 三个量级上都显著超过对应 baseline，且 8B+AdapTime 在 TimeQA 上甚至超过闭源 GPT-4，证明方法 model-agnostic。
不同问题分布的步骤分布显著不同（图 3）：TimeQA 偏向 Reformulate（多跳分解），TempReason-L2/L3 偏向 Rewrite+Review（隐式时间+答案不确定），验证 Planner 确实做出了任务感知的差异化决策。

亮点与洞察¶

把"工具调用"转化为"prompt 调度"：以往 temporal QA 把推理拆给外部 Python/retriever/symbolic solver，AdapTime 证明纯 LLM 也能完成这些子任务，并通过显式 Planner 取代隐式的"thought chain"实现可控自适应。这种"工具内化"思路可直接迁移到其它领域（数学、代码、agentic search）。
Prompt-based Planner > Fine-tuned Planner：实验对比显示蒸馏微调反而损失泛化能力，说明在数据稀缺的规划任务上 in-context 比 SFT 更鲁棒——这是一个对 agentic LLM 设计很有启发的反直觉发现。
"3 个正交动作"的抽象力：作者把 5 篇前作的核心操作压缩成 3 个动作（表 1 对照），同时覆盖既有工作的能力上界。这种"先做 ontology 抽象再做工程"的研究范式非常值得借鉴。
可与 retriever 叠加：4.7 节展示了 BM25+AdapTime 在开放域 ArchivalQA 上仍能提升 2 EM，说明 AdapTime 是个 orthogonal 增强，可叠加到 RAG pipeline 上。

局限与展望¶

LLM Planner 的决策稳定性依赖底层模型——同一个问题在不同 run 之间可能给出不同的执行路径，作者承认在小模型上 Planner 的可靠性会下降。
动作集仅 3 个，对于更复杂的时间推理（如时区转换、相对时间表达计算、跨语言时间）可能需要扩展（如增加 "Calculate" 或 "Convert" 动作）。
方法对长文档的 token 开销仍然主要来自原始上下文，对超长输入（>32k）的性能尚未充分验证；可结合 retriever 但论文只做了 BM25 的初步实验。
未对 Planner 的决策给出可解释性分析或 calibration——Planner 何时会做错决策、错误模式是什么，尚未深究。

评分¶

新颖性: ⭐⭐⭐⭐ 把多个时序方法的核心抽象成 3 个原子动作 + Planner 调度，是一个干净的 redesign。
实验充分度: ⭐⭐⭐⭐ 2 个 benchmark × 3 个 backbone + 充分消融 + 开放域延伸 + 案例对比，覆盖面广。
写作质量: ⭐⭐⭐⭐ 表 1 的对照清晰，算法 1 的伪代码直观，case study 附录有完整示例。
价值: ⭐⭐⭐⭐ 完全免训练、纯 prompt、可直接套到任意 LLM，复现门槛低，对 agentic 推理研究有方法论启示。