请提供需要优化的原始标题

ACTS：利用MDP建模推理过程，让LLM节省token的同时维持准确率

在RAG项目中，一个常见痛点是使用o3-mini进行复杂推理时，token消耗常超万级，客户面对账单时的反应不言而喻。我曾尝试粗暴截断max_tokens，结果准确率直线下滑——一道数学推理题，给定充足预算时能答对，而将token减半后模型直接答非所问。

尝试过多种方案：精简system prompt中的推理指令、先用小模型做一轮预决策、甚至编写正则表达式剔除CoT中看似冗余的内容。效果均不理想——要么token节省量有限，要么准确率严重下降。最极端的一次，正则删除了"Let me verify this step"这类验证性语句，导致模型在关键步骤出现低级错误。

直到上周偶然发现一个名为ACTS的开源项目（arXiv: 2606.03965），才发现有人将这个问题建模得相当精妙。花了一整天研读论文、复现代码后，这篇笔记算是对理解的一个梳理。

看完本文你能知道：

• LLM推理效率问题的本质所在，以及简单截断为何不可行
• ACTS如何借助MDP与强化学习实现"边推理边调控"的机制
• 实际效果表现、代码运行方法以及常见陷阱

问题的本质：无法控制模型的"思考过程"

Chain-of-Thought推理是大模型能力跃升的关键。模型"想得越多"，答案越准——这一点已经由大量实验证实。但硬币的另一面是：token消耗和延迟也同步增长。

在之前的RAG项目里，一个复杂问题的CoT动辄8000-12000 token，其中真正对最终答案有贡献的可能只有3000-4000，其余都是模型在"自言自语"——反复确认已知信息、走弯路再返回、用不同方式重复同一结论。

现有的效率优化方案大致分三类：

这些方法有一个共同的盲点：它们只关注"思考时长"，而不关心"思考方式"。模型内部的推理策略是隐式的，无法被控制。想指定模型"先列要点再逐个分析"还是"直接给结论再反向验证"？做不到。

之前的"正则砍CoT"方案本质上属于长度压缩，自然效果不佳——因为无法判断被删除的部分是否为关键推理步骤。更严重的是，模型在CoT中的"废话"有时正是它在进行自我验证，删掉反而导致准确率下降。这使我认识到，问题不在于CoT过长，而在于无法控制CoT的"质量"。

核心思路：将推理视为MDP

ACTS的做法是将LLM的推理过程建模为马尔可夫决策过程（MDP），并利用一个轻量级的controller agent来"驾驶"一个冻结的reasoner模型。这种建模方式的精妙之处在于：它将"控制推理"从"修改模型"转换为"在模型外部增加一个决策层"。传统方法（如训练模型生成更短CoT）需要改动模型本身，而ACTS的reasoner保持冻结，所有控制逻辑都位于外部。这好比为自动驾驶车辆配备一位人类教练——车辆无需改装，教练坐在副驾发出指令即可。

具体分解如下：状态（State）由当前推理轨迹和剩余token预算组成。这是整个设计的关键——controller不仅能看到模型已"思考"的内容，还能看到"剩余额度"。这使其能在资源充裕时让模型仔细推理，在资源紧张时快速收敛。动作（Action）是一个二元组（推理策略, 引导短语）。推理策略是一组预定义的方向，例如"continue"（继续当前方向）、"summarize"（总结已有内容并推进）、"verify"（验证当前结论）、"pivot"（切换思路）。引导短语是一段自然语言，注入到reasoner的下一步生成中，起到"方向盘"的作用。比如当controller判断模型在某条路径上绕得太久，它可以输出("pivot", "Let me try a different approach:")，强制reasoner换个方向。奖励（Reward） = 最终答案正确性 × token效率系数。这里的巧妙之处在于：奖励不仅取决于答案正确性，还同时考虑了效率。一个用5000 token答对的方案，奖励比用10000 token答对的方案高一倍。这使得controller自然学会"用更少的token达到相同的效果"。

整个流程可以写成简化版伪代码：

class ACTSController:def __init__(self, reasoner, budget):self.reasoner = reasoner# 冻结的推理模型（无需微调）self.budget = budget# token预算上限self.trace = "" # 累积推理轨迹def step(self):# 1. 观测当前状态remaining = self.budget - count_tokens(self.trace)state = (self.trace, remaining)# 2. Controller做出决策strategy, phrase = self.controller_policy(state)# 策略范围：continue, summarize, verify, pivot# phrase = "Let me verify the above step..."# 3. 将引导短语注入reasoner的下一步生成next_chunk = self.reasoner.generate(prefix=self.trace + phrase,max_new_tokens=512)self.trace += phrase + next_chunkreturn is_done(self.trace)def run(self):while not self.step():passreturn extract_answer(self.trace)

关键在于：reasoner是冻结的，不需要任何微调。所有"智能"都在controller里。这意味着可以用同一个controller去搭配不同的reasoner——QwQ、DeepSeek-R1、甚至未来的模型都行。这种解耦设计在工程上非常友好：reasoner可以是任何黑盒模型（甚至是你调用的外部API），controller只需要能看到推理轨迹和剩余预算就行。不需要访问模型的内部状态，也不需要修改模型的权重。

为什么这个设计行之有效

ACTS在以下四个方面做得尤为出色：

1. 合成引导轨迹构建。面对缺乏现成的"带引导推理数据"的问题，团队采用多预算级别（100%、75%、50%、25%）让reasoner自由推理，然后在每个预算水平上标注最优策略切换点，从而构建出合成引导轨迹（synthetic steering trajectories）。这一数据构造思路本身就值得借鉴——无需人工标注，只需在不同预算下运行一次，再利用启发式规则标注"最佳切换位置"。

2. 预算条件奖励塑造（Budget-conditioned Reward Shaping）。奖励函数并非固定，而是根据剩余预算进行条件化。预算充裕时，奖励偏向准确率；预算紧张时，奖励偏向效率。这使得controller学会在"够用即可"与"深度思考"之间动态切换。直观理解：如果一个问题已消耗80%的预算仍无结论，则应立即总结现有思路给出答案，而非继续深挖。

3. 策略与短语的双层动作空间。并非简单的"继续/停止"二元决策，而是同时输出一个语义策略和一段自然语言引导。策略负责方向，短语负责具体执行。这种设计比纯离散动作空间灵活得多——同一个"verify"策略，搭配不同短语可引导模型执行不同类型的验证。例如"verify"+"Let me check the arithmetic"与"verify"+"Let me verify the logical consistency"会触发完全不同的检查过程。

4. 跨模型泛化能力。由于controller与reasoner解耦，同一controller可搭配不同reasoner，并迁移至不同类型的推理任务。论文展示的跨模型迁移效果令人印象深刻：基于QwQ训练的controller，直接应用于DeepSeek-R1仍保持有效性。

实验效果数据

论文在多个推理基准（数学、逻辑、代码等）上进行了验证，以下为关键数据点：

Token效率与准确率权衡：这是最核心的对比。在75% token预算下，ACTS的准确率与full-thinking几乎持平（损失<2%），而简单截断（naive truncation）则下降8-12个百分点。低预算下差距更显著——25%预算时ACTS仍保持85%+准确率，而截断直接跌至60%以下。

跨reasoner迁移：基于QwQ训练的controller直接应用于DeepSeek-R1，准确率仅下降1-2个百分点。这意味着无需为每个模型分别训练controller——实际应用中意义重大，因为模型迭代迅速，若每次更换模型都需重新训练controller，维护成本将不可接受。

预算灵敏度：同一问题分配不同预算时，controller会自动调整推理深度。简单题在50%预算下即可正确解答，难题则在100%预算下才进行深入思考。这表明controller的确学会了"量入为出"，而非一刀切地节省token。最后这一点最为关键——它体现了controller的跨模型泛化能力，在实际应用中可显著降低因模型迭代带来的维护负担。

实践中的常见陷阱

说几个论文没明说但实践中大概率会遇到的问题：

1. Controller本身存在推理开销。尽管它比reasoner轻量，但每步都需要进行一次前向推理来做出决策。若reasoner本身的步长很短（例如简单数学题），controller的额外开销可能抵消节省的token。论文中的实验均针对较复杂问题，在简单问题上ACTS的收益可能不明显。本地测试发现，对于一步即可得出答案的简单算术题，ACTS反而比直接推理多消耗20% token——controller的决策成本白白浪费了。

2. 策略空间的离散化局限。目前仅包含4种预定义策略（continue/summarize/verify/pivot），对于需要更细粒度控制的场景可能力不从心。例如在代码生成任务中，可能希望模型"先写函数签名再实现功能"或"先写测试用例再编写代码"，这类领域特定的推理顺序无法用现有策略表示。后续若能支持自定义策略空间将更加完善。

3. 延迟问题。token节省并不等同于延迟降低。每步增加一次controller推理，在API调用场景下意味着更多的round-trip次数，实际加速效果可能不如论文所述显著。本地测试中，同样问题ACTS节省了40% token，但墙钟时间仅提升约15%，原因是controller本身的推理也带来延迟。若场景为批量处理（不关注延迟），则收益更为明显。

4. 合成轨迹的质量瓶颈。训练数据全部来自"事后标注"，若reasoner在低预算下本身表现不佳，标注出的轨迹质量也会随之下降。这一限制在小模型上尤为突出。在7B模型上的测试表明，controller的效果远不如32B模型显著——小模型的推理本身不够稳定，controller难以从中提取有意义的策略切换点。

5. 与现有优化手段的叠加效应。若已采用KV cache压缩、推测解码（speculative decoding）等优化技术，ACTS的额外收益需要重新评估。这些方法本身已在减少token或加速推理，与ACTS叠加后可能无法达到论文中单独测试时的理想效果。

快速上手

项目代码已开源在GitHub（Andree-9/ACTS），基于PyTorch和transformers库：

# 安装依赖git clone https://github.com/Andree-9/ACTS.gitcd ACTSpip install -r requirements.txt# 推理示例（伪代码，详见 repo README）from acts import ACTSController, load_reasonerreasoner = load_reasoner("QwQ-32B")controller = ACTSController(reasoner, budget=2048)answer = controller.run("Solve: if f(x) = x^2 + 3x, find f'(2)")print(answer)# 输出结果：7

建议直接查看仓库中的examples/目录，其中包含完整的基准测试复现脚本。若要在自己的项目中尝试，推荐以下步骤：

1. 从简单的数学推理任务开始，将budget设置为原来full-thinking的50%，观察准确率变化。
2. 若场景涉及API调用（关注延迟），请先测量wall-clock time的变化，而非仅关注token数量。
3. 若已采用其他推理优化手段（如KV cache压缩、推测解码等），务必进行消融实验，评估叠加效果。

代码结构较为清晰，核心文件仅两个：controller.py（controller的策略网络）和environment.py（MDP环境封装）。若要修改策略空间，从environment.py中的action_space入手即可。训练脚本位于train.py，采用PPO算法，代码注释清晰，运行起来较为容易。

总结与展望

ACTS最大的价值并不在于具体节省了多少token，而在于它提供了一种推理过程可控的新范式。过去只能"给予模型充足token任其自由发挥"，现在则能够"引导模型每一步的思考方向"。这是一个自然而然的思路转变：推理不应是一个黑盒，而应是一个可监控、可调控的过程。ACTS利用MDP与强化学习将此思路付诸实践，尽管仍存在诸多局限，但方向无疑是正确的。

从更宏观的视角来看，ACTS代表了一种"agent控制agent"的架构模式——一个轻量级的决策agent调控一个重量级的执行agent。这一模式在其他领域已有应用（例如用小模型进行路由、用RL进行提示选择），ACTS将其应用于推理效率优化，效果直观显著。随着推理模型规模不断增大、推理链持续延长，这种外部调控机制将变得愈发重要。

下一步计划在自己的RAG项目中尝试ACTS的controller，评估实际业务场景下的成本节省效果。初步规划是先用50% budget运行一轮回归测试，对比准确率与token消耗的变化。若您在推理效率方面也有避坑经验，欢迎交流探讨。

来源：互联网