Skip to content
←

Split View: 스텝마다 얼마나 생각할지 고르기 — Ares의 적응형 추론 노력 라우팅

|

스텝마다 얼마나 생각할지 고르기 — Ares의 적응형 추론 노력 라우팅

들어가며 — 추론 노력이라는 비용 레버

생각하는 LLM(thinking LLM)으로 만든 에이전트는 긴 사고 사슬(chain-of-thought)로 높은 정확도를 얻지만, 그 대가로 추론 비용이 크게 붙습니다. 요즘 모델 상당수는 추론 레벨을 high·medium·low처럼 설정할 수 있게 열어 두었는데, 진짜 문제는 이 레버를 어떻게 당길지입니다.

Ares 논문(2026년 3월 프리프린트)의 관찰은 단순하지만 설득력 있습니다. 고정 전략은 잘 안 통한다는 것. 모든 스텝을 low로 돌리면 성능이 눈에 띄게 떨어지고, 레벨을 무작위로 섞으면 정확도도 못 지키고 비용도 의미 있게 못 줄입니다. 더 정확한 그림은 이렇습니다 — 복잡한 웹사이트 구조를 헤쳐 나가는 스텝에는 높은 노력이 필요하지만, 목표 URL을 여는 것 같은 단순한 스텝은 낮은 노력으로 충분합니다. 즉 노력은 태스크 단위가 아니라 스텝 단위로 배분되어야 합니다.

스텝마다 노력을 고르는 라우터

Ares(Adaptive Reasoning Effort Selection)의 핵심은 가벼운 라우터 하나입니다. 매 스텝마다, 지금까지의 상호작용 이력을 보고 그 스텝에 필요한 가장 낮은 적절한 추론 레벨을 예측합니다. 요지는 "이 스텝이 어려운가?"를 미리 값싸게 판단해, 어려울 때만 비싼 사고를 켜는 것입니다.

라우터는 어떻게 학습시키나. 논문은 데이터 생성 파이프라인으로 각 스텝이 성공하는 데 필요한 최소 추론 노력을 찾아내고, 그 라벨로 라우터를 파인튜닝합니다. 결과물은 특정 모델에 종속되지 않는 플러그앤플레이 방식이라, 기존 LLM 앞단에 끼워 넣는 형태로 설계됐습니다.

동작을 개념적으로 그리면 이렇습니다.

매 LLM 호출 직전에:
  1. 지금까지의 상호작용 이력을 라우터에 넘긴다
  2. 라우터가 이 스텝의 최소 추론 레벨을 예측한다   (high / medium / low)
  3. 예측된 레벨로 본체 모델을 호출한다
  4. 도구 결과를 이력에 더하고 다음 스텝으로

포인트는 라우터가 본체 모델보다 훨씬 싸고, 판단이 스텝 단위라는 점입니다. 한 태스크 안에서도 스텝마다 노력이 오르내립니다.

숫자, 그리고 그 숫자를 읽는 법

논문이 보고하는 수치부터. 세 벤치마크 — 도구 사용 에이전트용 TAU-Bench, 딥리서치 에이전트용 BrowseComp-Plus, 웹 에이전트용 WebArena — 에서, 항상 high로 돌리는 고정 전략 대비 추론 토큰을 최대 52.7%까지 줄였다고 합니다. 그러면서 태스크 성공률 저하는 미미했다고 보고합니다.

읽는 법. 두 가지를 분명히 해 둡니다. 첫째, 이건 저자들이 보고한 프리프린트 수치이며 독립적으로 검증되지 않았습니다. 둘째, "최대(up to)"는 상한값입니다 — 벤치마크마다 다를 수 있고, 모든 상황의 평균이 아니라 가장 잘 나온 조건의 수치로 읽는 편이 안전합니다. 그래도 방향성은 분명합니다. 대부분의 에이전트 스텝은 최대 사고를 필요로 하지 않는다는 것.

솔직한 트레이드오프 — 라우터 오버헤드와 과소 사고

공짜 점심은 없습니다. 이 접근의 대가를 정직하게 적습니다.

  • 라우터 자체가 비용이다. 라우터는 매 스텝 돕니다. 절약분을 갉아먹지 않을 만큼 충분히 가벼워야 합니다. 아낀 사고 토큰보다 라우터 호출이 비싸면 의미가 없습니다.
  • 과소 사고(under-thinking) 리스크. 라우터가 어려운 스텝을 쉽다고 오판해 너무 낮은 레벨을 고르면 그 스텝은 실패합니다. 그리고 에이전트에서 한 스텝의 실패는 종종 전체 궤적을 망치거나 재시도를 부릅니다 — 아낀 사고보다 더 비싼 값을 치를 수 있습니다. 그래서 실무에서는 라우터를 "많이 생각하는 쪽"으로 살짝 편향시키는 보정이 대체로 안전합니다.
  • 분포 이동(distribution shift). 라우터는 특정 에이전트·태스크 분포에서 학습됩니다. 다른 도메인의 에이전트에 그대로 옮기면 판단이 어긋날 수 있습니다. 옮길 때마다 다시 재보는 게 맞습니다.
  • 정확도-비용 곡선을 직접 재라. "최대 52.7%"가 당신 워크로드에서 재현된다는 보장은 없습니다. 당신의 태스크에서 성공률과 토큰을 함께 측정해, 절약이 정확도 손실을 정당화하는지 스스로 확인해야 합니다.

마치며 — 오늘 쓸 수 있는 아이디어

Ares가 매력적인 이유는 특정 라우터 구현이 아니라 원리입니다. 추론 노력을 태스크 전체에 균일하게 걸지 말고, 스텝 단위로 필요한 만큼만 배분하라는 것. 이 아이디어는 완성된 라우터 가중치가 없어도 오늘 당장 근사할 수 있습니다 — 스텝 종류(단순 조회 대 복잡한 계획)에 따라 휴리스틱으로 레벨을 정하거나, 실패했을 때만 노력을 올리는 폴백을 두는 식으로요.

물론 이건 아직 프리프린트이고, 수치는 저자 보고치입니다. 하지만 "모든 스텝을 최대로 생각하게 하는 것은 낭비"라는 명제는 직관적으로도, 비용 청구서로도 맞는 말입니다. 에이전트를 운영하는 사람이라면 추론 노력을 하나의 튜닝 가능한 레버로 보기 시작할 이유가 충분합니다.

참고 자료

Choosing How Much to Think Per Step: Ares and Adaptive Reasoning-Effort Routing

Introduction — Reasoning Effort as a Cost Lever

Agents built on thinking LLMs reach high accuracy through long chain-of-thought reasoning, but they pay for it in inference cost. Many current models expose the reasoning level as a setting — high, medium, low — and the real question is how to pull that lever.

The observation in the Ares paper (a March 2026 preprint) is simple but sturdy: static strategies do not work well. Running every step at low degrades performance noticeably, and choosing levels at random preserves neither accuracy nor a meaningful cost cut. The truer picture: some steps — navigating a complex website structure — genuinely need high effort, while simpler ones — opening a target URL — are fine at low effort. Effort should be allocated per step, not per task.

A Router That Picks the Effort for Each Step

The core of Ares (Adaptive Reasoning Effort Selection) is a single lightweight router. At every step, it looks at the interaction history so far and predicts the lowest appropriate reasoning level for that step. The idea is to answer "is this step hard?" cheaply, up front, and turn on expensive thinking only when it is.

How is the router trained? The paper uses a data-generation pipeline to identify the minimum reasoning effort each step needs to succeed, then fine-tunes the router on those labels. The result is designed to be plug-and-play — not tied to one model, but dropped in front of an existing LLM.

Sketched conceptually, it runs like this.

Right before each LLM call:
  1. Pass the interaction history so far to the router
  2. The router predicts the minimum reasoning level for this step   (high / medium / low)
  3. Call the main model at that level
  4. Append the tool result to the history and move to the next step

The point is that the router is much cheaper than the main model, and the decision is per step — effort rises and falls within a single task.

The Numbers, and How to Read Them

Start with what the paper reports. Across three benchmarks — TAU-Bench for tool-use agents, BrowseComp-Plus for deep-research agents, and WebArena for web agents — it cuts reasoning tokens by up to 52.7% versus always running at high, while reporting only minimal degradation in task success rate.

How to read that. Two caveats up front. First, these are author-reported numbers from a preprint, not independently verified. Second, "up to" is a ceiling: it varies by benchmark, and it is safer to read it as a best case than as an average across all conditions. Still, the direction is clear — most agent steps do not need maximum thinking.

The Honest Tradeoffs — Router Overhead and Under-Thinking

There is no free lunch. The honest costs of this approach:

  • The router itself costs something. It runs on every step, so it has to be light enough not to eat the savings. If the router call costs more than the thinking tokens it saved, there is no point.
  • Under-thinking risk. If the router misjudges a hard step as easy and picks too low a level, that step fails. And in an agent, one failed step often derails the whole trajectory or forces a retry — which can cost more than the thinking you saved. In practice, biasing the router slightly toward more thinking is usually the safer calibration.
  • Distribution shift. The router is trained on a particular distribution of agents and tasks. Move it to an agent in a different domain and its judgments may drift. Re-measure whenever you transplant it.
  • Measure the accuracy-cost curve yourself. There is no guarantee that "up to 52.7%" reproduces on your workload. Measure success rate and tokens together on your own tasks, and confirm for yourself that the savings justify any accuracy loss.

Closing — A Deployable Idea Today

What makes Ares appealing is not a specific router implementation but the principle: do not spend reasoning effort uniformly across a whole task; allocate it per step, only as much as each step needs. You can approximate this idea today without any trained router weights — set the level by step type (a simple lookup versus complex planning) with a heuristic, or add a fallback that only raises effort after a failure.

This is still a preprint, and the numbers are the authors' own. But the claim that making every step think at maximum is wasteful holds up both intuitively and on the invoice. If you run agents in production, that is reason enough to start treating reasoning effort as one more tunable lever.

References