RouteWeaver는 질의별 실행 방식과 모델 선택을 한 정책으로 학습한다

무엇인가

이 논문은 LLM 라우팅의 기존 전제를 바꾼다. 기존 라우터는 단일 라운드, 다중 라운드, 에이전트형 중 하나의 실행 패러다임을 미리 고정한 뒤 그 안에서 모델만 고른다. 그래서 질의에 따라 모델은 바꿀 수 있어도 모델 호출을 어떻게 조직할지는 바꾸지 못한다. RouteWeaver는 실행 방식 자체를 라우팅 결정으로 취급해, 하나의 LLM 정책이 단일·다중·에이전트 실행 모드 중 무엇을 쓸지와 그 모드 안에서 어떤 워커를 어떻게 호출할지를 함께 학습하게 한다.

어떻게 동작하나

방법의 뼈대는 모드 조건부 궤적이다. 라우터는 질의를 받으면 먼저 single, multi, agentic 중 하나를 샘플링하고, 이후 워커 w와 하위 질의 s를 지정하는 행동을 생성한다. 에이전트형에서는 역할 r과 선행 호출 참조 집합 P까지 지정한다. 단일 라운드는 워커 호출이 정확히 한 번이다. 궤적은 모드, 행동, 관찰, 최종 답으로 구성되고, 보상은 과제 보상과 효율 보상으로 나뉜다. 과제 보상은 정답 1, 오답 0, 종료 불가능 1을 주고, 효율 보상은 정답이고 유효할 때 S_cost = 1/(1+C(τ)/C_ref)를 준다. 오답이면 0, 종료 불가능이면 -1이다.

무엇과 다른가

COMET-GRPO는 보상이 낮을 때 모드 선택이 나빴는지 모드 내 실행이 나빴는지 구분하지 못하는 문제를 다룬다. 표준 GRPO는 궤적 수준 이점을 모드 토큰과 이후 모든 라우터 토큰에 똑같이 준다. COMET-GRPO는 같은 질의의 롤아웃 그룹에서 선택된 모드의 평균 보상과 전체 평균을 비교하는 A_mode와, 같은 모드 안에서 해당 궤적이 모드 평균과 얼마나 다른지를 보는 A_inner를 분리한다. 과제 보상과 효율 보상은 α로 섞고, A_mode는 모드 결정 토큰에만, A_inner는 워커 선택·역할·참조·하위 질의·최종 답 토큰에만 적용한다. 관찰과 주입 내용은 마스킹한다. 모드 토큰 수가 실행 토큰보다 훨씬 적어 묻히지 않도록 두 손실을 각각의 유효 토큰 수로 정규화하는 점도 핵심이다.

어떻게 쓰나

점진적 탐색은 초기 모드 편향을 막기 위한 훈련 절차다. 콜드 스타트 구간에서는 모든 질의에 외부 지정 모드를 강제하고 과제 보상만 쓰는 일반 GRPO로 각 모드 실행법을 먼저 배운다. 전환 구간에서는 강제 질의를 줄이고 자유 질의를 늘리며, 배치 평균 모드 점수가 한 모드로 너무 일찍 쏠리지 않도록 지원 페널티를 준다. 이후 완전 자율 구간에서 COMET-GRPO로 모드 선택과 실행을 함께 최적화한다. 소거 실험에서 점진적 탐색을 빼면 정책이 단일 라운드로 완전히 붕괴해 모드 사용이 1.00/.00/.00이 되고 평균 정확도는 55.6%로 떨어졌다. COMET-GRPO를 빼면 58.8%에 그치고 모드 사용이 .13/.82/.05로 다중 라운드에 쏠렸다. 두 소거 변형도 최강 고정 패러다임 베이스라인 55.3%는 넘었다.

전제와 한계

실험은 수학, 코딩, 지식, 논리 추론, 사실 회상의 다섯 도메인 아홉 벤치마크에서 이뤄졌다. MATH, Omni-MATH, APPS, LiveCodeBench, TACO, SuperGPQA, SATBench, TriviaQA, SimpleQA-Verified가 쓰였다. 라우터는 Qwen3-4B-Instruct-2507을 전체 파인튜닝하고, 워커 풀은 Qwen3-8B, Qwen3-30B-A3B-Instruct-2507, Llama-3.1-8B-Instruct, Llama-3.3-70B-Instruct, Gemma-3-27B-IT, Gemini-2.5-Flash-Lite 여섯 개 동결 모델로 구성했다. 라우터는 모델 이름과 가격을 보지 않고 능력 설명이 붙은 익명 ID만 본다. 단일·다중·에이전트형을 아우르는 열 개 라우터 베이스라인과 비교해 RouteWeaver는 평균 61.4%를 냈고, 최강 베이스라인 Router-R1의 55.3%보다 11.03% 상대 개선했다. 최강 단일·다중·에이전트형 대비 상대 개선은 각각 26.08%, 11.03%, 31.20%였고 다섯 도메인 모두에서 앞섰다. 도메인별 상대 개선은 Recall 5.20%에서 Math 12.52%까지였다.

비용 민감도도 조절 가능하다. α=0.1이면 워커 추론 비용이 23% 줄고 정확도는 1.0포인트만 떨어졌다. α=0.3이면 비용 61% 감소에 정확도 3.1포인트 손실, α=0.5면 비용 86% 감소에 정확도 11.2포인트 손실이다. 미학습 벤치마크인 AIME, GPQA-D, BBH에서는 평균 53.7%로 Router-R1의 45.4%보다 18.28% 상대 개선했고, 각각 11.4, 7.1, 6.4포인트 앞섰다. 라우팅 행동은 도메인에 따라 크게 달랐다. Math는 단일 19%, 다중 50%, 에이전트형 31%였고, Code는 다중 84%, Knowledge는 단일 72%였다. Reason은 99%가 에이전트형, Recall은 96%가 단일 라운드로 갔다. AIME에서는 에이전트형이 75%였지만 BBH에서는 12%에 그쳤다.

개발자에게 이 논문의 의미는 라우팅을 모델 목록 선택으로만 보지 말라는 데 있다. 여러 모델과 워크플로를 운영한다면 질의별로 단일 호출, 반복 호출, 역할·의존성이 있는 에이전트 워크플로 중 무엇이 맞는지를 정책이 고르게 하고, 모드 선택과 실행 품질을 별도 신호로 평가·로깅하는 설계가 유효하다. 비용과 정확도의 운영점을 α 하나로 조절할 수 있다는 점도 실무적이다. 다만 도메인별 모드 선호가 크게 달라서, 배포 전에 자사 트래픽에서 모드 분포와 비용·정확도를 함께 확인해야 한다.

저자들이 밝힌 한계도 분명하다. RouteWeaver는 워커 모델의 편향, 안전하지 않은 출력, 사실 오류를 그대로 물려받고, 여러 모델 호출을 거치며 이런 오류가 전파될 수 있다. 실험은 안전 필수 배포가 아니라 라우팅 방법론 평가를 목적으로 하며, 실제 배포에서는 모델 수준 안전 장치와 기반 모델·데이터셋의 라이선스 및 사용 정책을 지켜야 한다고 명시한다. 결론에서는 더 풍부한 실행 구조와 도구 증강 환경으로 이 통합 관점을 확장하는 일을 향후 과제로 남긴다.