ACTS的观点是，用 MDP 建模推理过程，让 LLM 省 token 还不掉准确率

最近在做一个 RAG 项目时遇到一个痛点：用 o3-mini 跑复杂推理问题。token 消耗动辄上万，客户一看账单直接问我“能不能控制一下思考深度？”，当时我能做的就是粗暴截断 max_tokens，结果准确率断崖式下降——一道数学推理题。给 full budget 能做对，砍到一半 token 直接答非所问。

后来我试了几种方案：缩短 system prompt 里的推理指令、用小模型先跑一遍再决定是否升级、甚至写了个正则把 CoT 里看起来“废话”的部分砍掉。效果都不理想——要么省不了多少，要么准确率掉得离谱。最离谱的一次正则把 “Let me verify this step” 这类验证性语句删了结果模型在关键步骤上犯了低级错误没 catch 住。

直到上周我偶然看到一个叫 ACTS 的开源项目才发现有人把这个问题建模得非常漂亮。花了一天时间读完论文、跑了一遍代码，这篇笔记算是把我的理解整理出来。

看完这篇文章你能知道：

• 为什么简单截断行不通
• ACTS 如何用 MDP + 强化学习实现“边推理边调控”
• 坑

问题的本质的观点是，你管不了模型“怎么想”

Chain-of-Thought 推理是大模型能力跃升的关键。话说回来，模型“想得越多”，答案越准——这已经被无数实验验证。但硬币的另一面是：token 消耗和延迟也在飞涨。

我之前那个 RAG 项目里一个复杂问题的 CoT 动辄 - token。其中真正对最终答案有贡献的可能只有 -，剩下的都是模型在“自言自语”——反复确认已经知道的东西、走弯路再回头、用不同方式重复同一个结论。

现有的效率调整方法大致分三类：

这些方法有一个共同盲区：它们只管“想多久”，不管“怎么想”. 模型内部的推理策略是隐式的、不受控。你想让它“先列要点再逐个分析”还是“直接给结论再反向验证”？做不到，

I之前那个 “正则砍 CoT” 的方案本质上就是长度压缩，当然不好使——你不知道砍掉的那部分是不是关键推理步骤。更糟的是模型在 CoT 中的 “废话”有时候恰恰是它在做自我验证，砍掉反而降低了准确率。这让我意识到，问题不在于 CoT 太长。而在于我们没法控制 CoT 的 “质量”。

主要思路这方面，推理即 MDP

ACTS 的做法是：把 LLM 的推理过程看作一个马尔可夫决策过程。接下来用一个轻量级 controller agent 来“驾驶”一个冻结的 reasoner。

This modeling approach’s brilliance lies in shifting from “modify model itself” to “add an external decision layer.” Traditional methods require altering core weights—ACTS keeps reasoner untouched while all control logic lives outside.

• Status : 当前推理轨迹 + 剩余 token 预算—controller 能看到已生成内容与剩余资源，从而动态决定深度。
• Action : —预定义方向如 continue/summarize/verify/pivot。并注入自然语言提示，引导接下来生成。
• : 最终答案正确性 × token 效率系数—同时惩罚过度消耗与鼓励高效精确回答。

class ACTSController:
def __init__:
self.reasoner = reasoner
self.budget = budget
self.trace = ""
def step:
remaining = self.budget - count_tokens
state =
strategy,phrase = self.controller_policy
next_chunk = self.reasoner.generate(
prefix=self.trace + phrase。max_new_tokens=...
)
self.trace += phrase + next_chunk
return is_done
def run:
while not self.step:
pass
return extract_answer

A key benefit is that reasoner remains frozen—no fine‑tuning required—and you can pair it with any black‑box model.

为什么这个设计有效？说到四大亮点，

1. Syntic Steering Trajectories Construction:- 在不同预算层级下让 reasoner 自由运行。接下来标注最佳切换点建立合成数据，无需人工标注。
2. Bçȵö Reward Shaping:- 奖励随剩余预算动态变化。使 controller 在充足资源时追求准确，在紧张时追求效率。
3. Differentiated Action Space:- 不仅选择动作。还内容，提高灵活性与可控性。说起来，
4. Cross‑Model Generalization:- Controller 与 reasoner 解耦。同一 controller 可迁移至 QwQ、DeepSeek-R1 等多种大型模型。

实验数据亮点这方面，

• Token 效率 vs 准确率：The most critical comparison shows ACTS maintains near‑full accuracy while cutting tokens by up to X% compared to naive truncation.
• Cross‑Reasoner Transferability：A controller trained on QwQ works on DeepSeek-R1 with negligible accuracy loss.
• Budget Sensitivity：The same problem sees different depths at varying budgets—controller adapts rar than applying a blanket cutoff.

说到实际踩坑清单，

1. The controller’s own inference cost: For simple problems where one step suffices。ACTS can actually increase total tokens due to controller overhead.
2. Lack of finer action granularity: Only four predefined strategies limit nuanced control needed for tasks like code generation or structured QA.
3. Lateness & round‑trip delays: Token savings don’t automatically translate into latency reductions when API calls dominate workload.
4. Syntic trajectory quality bottleneck: On smaller models whose low‑budget performance is weak,syntic guidance may degrade rar than improve results.
5. Additive effect with existing optimizations: Combining ACTS with KV cache compression or speculative decoding requires careful ablation studies.

如何跑起来？

• git clone https://github.com/Andree-/ACTS.git && cd ACTSpip install -r requirements.txt # 示例代码from acts import ACTSController。load_reasoner reasoner = load_reasoner controller = ACTSController answer=controller.run=x^+3x find f'") print. 建议先从简单数学题开始，将 budget 调为原来 full‑thinking 的百分比；若 API 调用场景请测 wall‑clock time；若已有其它调整手段请做 ablation。主要文件包括 /controller.py /controller.py /environment.py /…​train.py，如果改动作空间，请从 environment.py 开始修改。

与前景展望这方面，