# \[실험\] 비싼 모델이 앞부분만 하고 로컬 4B 모델에 넘기면? 재무 분석 에이전트로 해 본 AgentBaton 축소 재현 (비공식)

**URL:** <https://discuss.pytorch.kr/t/4b-agentbaton/12464>\
**Category:** 읽을거리&정보공유\
**Created:** [11월 10, 2026, 12:23오전 UTC](https://discuss.pytorch.kr/t/4b-agentbaton/12464 "2026-11-10T00:23:40Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![sinkytiger](https://discuss.pytorch.kr/user_avatar/discuss.pytorch.kr/sinkytiger/32/25615_2.png) [@sinkytiger](https://discuss.pytorch.kr/u/sinkytiger)\
**Post date:** [11월 10, 2026, 12:23오전 UTC](https://discuss.pytorch.kr/t/4b-agentbaton/12464/1 "2026-11-10T00:23:40Z")

</div>

PyTorchKR의 [10/26~11/01 주간 AI/ML 논문 모음](https://discuss.pytorch.kr/t/2026-10-26-11-01-ai-ml/12374)에서 AgentBaton 논문을 골랐습니다. 긴 에이전트 작업을 고성능 모델이 먼저 하다가, 알맞은 때 한 번 저비용 모델에게 넘기는 방법입니다. 논문은 넘길 때를 고르는 2B 판별기로 모델 쌍 11개와 벤치마크 2개에서 API 비용을 평균 65.9% 줄이면서 정확도는 대체로 지켰다고 보고합니다. 넘겨받는 모델은 Qwen3.8-27B(로컬 모델이라 비용 0으로 계산)와 클라우드 모델 GPT-5.6 Luna입니다.

저는 넘겨받는 모델이 훨씬 작을 때 어떻게 되는지 보고 싶었습니다. 노트북 GPU(6GB)에서 도는 qwen3:4b가 넘겨받고, 작업은 여러 단계를 거치는 재무 데이터 분석입니다.

- 저장소: [GitHub - sinkytiger/baton-lite: Can Claude hand a financial-analysis task to a 4B local model? A small AgentBaton check: Sonnet/Haiku 5.5 to qwen3:4b, pre-registered, 30 synthetic tasks · GitHub](https://github.com/sinkytiger/baton-lite) (저장소는 영어로 되어 있습니다)
- 논문: [AgentBaton (arXiv:2610.35959)](https://arxiv.org/abs/2610.35959). 논문과 arXiv 페이지에 공개 코드 링크가 없어(2026-11-09 확인) 논문 설명만 보고 새로 짰습니다.

논문 저자와는 관계없는 비공식 실험입니다. 과제와 모델이 달라서 수치는 논문과 직접 비교할 수 없습니다.

## 실험 설정

- **과제** : 가상의 캐나다 상장사 데이터로 만든 작업공간 30개(템플릿 6종 × 5개)입니다. 마진 연속 개선, 조정 ROE, 매출 성장률 상위 3사, 규모 선별, 배당성향, 액면분할 반영 주당배당금을 계산합니다. 정정 공시, 회사마다 다른 보고 단위, 별도 기준 행, 주석의 전년도 항목, 액면분할 같은 함정을 심었고, 함정마다 정답이 바뀝니다.
- **에이전트** : 한 턴에 파이썬 코드 하나를 실행하고, 답을 `result.json`에 쓴 뒤 SUBMIT합니다. 두 모델을 합쳐 최대 20턴입니다.
- **모델** : 먼저 일하는 쪽은 Claude Sonnet 5.5(주 실험)와 Haiku 5.5, 넘겨받는 쪽은 qwen3:4b(Ollama, temperature 0)입니다. 로컬 모델 비용은 논문처럼 0원으로 셉니다.
- **넘기기** : 고성능 모델의 첫 k턴을 새 작업공간에서 그대로 다시 실행하고, 턴마다 파일 상태를 기록과 대조한 뒤 넘깁니다. 넘겨받는 모델은 앞 기록을 대화에 그대로 받거나(in-context) 로그 파일로 받습니다(논문의 두 방식). in-context는 가능한 모든 k에서, 로그 파일은 다섯 가지 넘기기 규칙(고정 25·50·75%, 두 탐지기)이 고른 k에서만 이어 실행했습니다. 그래서 넘기는 규칙은 결과표에서 찾아보기만 하면 됩니다.
- **넘기는 규칙** : 진행률 25/50/75% 고정, 논문의 준비 신호 세 가지를 파일 기록 기준으로 옮긴 규칙 탐지기, 같은 세 신호를 주고 qwen3:4b에게 매 턴 "넘길 때인가"를 묻는 프롬프트 탐지기입니다. 논문의 학습된 2B 판별기는 만들지 않았습니다.
- **사전 등록** : 가설 4개와 판정 규칙을 테스트 실행 전에 커밋했습니다. 신뢰구간은 과제를 다시 뽑는 짝 부트스트랩(10,000회) 95%이고, McNemar 정확 검정을 함께 봤습니다.

## 결과 (Sonnet 5.5 → qwen3:4b, 테스트 30과제)

| 조건 | 넘기는 방식 | 정답 | 과제당 API 비용 | Sonnet 혼자 대비 비용 | Sonnet 혼자 대비 정확도(p, 95 CI) |
| --- | --- | --- | --- | --- | --- |
| Sonnet 혼자 | - | 30/30 | $0.0220 | - | - |
| qwen3:4b 혼자 | - | 0/30 | 0 | -100% | -100.0 |
| 25% 고정 | in-context | 8/30 | $0.0032 | -85% | -73.3 (-86.7~-56.7) |
| 50% 고정 | in-context | 12/30 | $0.0092 | -58% | -60.0 (-76.7~-43.3) |
| 75% 고정 | in-context | 18/30 | $0.0161 | -27% | -40.0 (-56.7~-23.3) |
| 규칙 탐지기 | in-context | 26/30 | $0.0185 | -16% | -13.3 (-26.7~-3.3) |
| 프롬프트 탐지기 | in-context | 16/30 | $0.0117 | -47% | -46.7 (-63.3~-30.0) |
| 규칙 탐지기 | 로그 파일 | 25/30 | $0.0185 | -16% | -16.7 (-30.0~-3.3) |
| 사후 최적 지점(1과제는 Sonnet 혼자) | in-context | 30/30 | $0.0110 | -50% | 0.0 |
| 반대 방향(qwen → Sonnet, 50%) | in-context | 29/30 | $0.0335 | +52% | -3.3 (-10.0~0.0) |

"사후 최적 지점"은 결과를 보고 고른 것이라 실제로 쓸 수 있는 규칙이 아닙니다. 정답으로 끝난 가장 이른 지점에서 넘긴 경우이고, 어느 지점에서도 정답이 나오지 않은 split\_dps-202만 Sonnet 혼자로 계산했습니다. 한 번씩 뽑은 결과를 보고 고른 값이라 낙관적인 추정입니다.

## 가설 판정

| 가설 | 결과 |
| --- | --- |
| H1. 규칙 탐지기가 비용을 40% 이상 줄이고, 정확도 손실 구간 하한이 -15%p보다 위다 | **기각.** 비용은 16%만 줄었고, 정확도는 -13.3%p(-26.7~-3.3)입니다. |
| H2. 반대 방향(저비용 → 고성능)은 Sonnet 혼자보다 정확도가 낮다 | **확인 못 함.** -3.3%p(-10.0~0.0)로 구간에 0이 들어 있습니다. 놓친 1건은 Sonnet이 이어받다 응답을 거부한 경우입니다. 비용은 52% 늘었습니다. |
| H3. 75%에서 넘기면 25%보다 정확하다 | **성립.** +33.3%p(+13.3~+53.3), McNemar p = 0.006입니다. |
| H4. qwen3:4b 프롬프트 탐지기는 80% 이상의 과제에서 첫 턴에 넘기거나 아예 안 넘긴다 | **기각.** 그런 과제는 0개였습니다. 다만 16/30으로 정확도가 낮았습니다. |

사전 등록 문서에는 H4를 "논문처럼"이라고 적었는데, 제가 논문을 잘못 옮긴 것입니다. 논문은 별도 판정 모델이 아니라 고성능 모델 자신에게 넘기라고 프롬프트했고, Kimi K3는 한 번도, GLM-5.3은 113과제 중 6개에서만 넘겼으며, GPT-5.6 Sol은 모든 과제에서 넘겼습니다. 가설의 기준과 판정은 그대로 두고, 정정 경위를 문서에 남겼습니다.

## 가설 밖에서 보인 것 (탐색)

1. **규칙 탐지기는 답을 다 쓴 뒤에야 켜졌습니다.** 이 과제에서 Sonnet이 만든 파일은 30과제 모두 `result.json` 하나, 곧 답이었습니다. 계산 코드는 바로 실행되고 저장되지 않으니, 파일 기준으로 옮긴 "실질적 산출물이 있다"는 신호가 "답이 있다"와 같은 뜻이 됐습니다. 논문의 신호는 더 넓어서 실행 가능한 시제품도 인정하고, 문제를 드러낸 실패도 피드백으로 칩니다. 규칙 탐지기가 넘긴 시점의 작업공간은 30과제 모두 Sonnet의 최종 작업공간과 같았고, 22과제에서는 SUBMIT만 남아 있었습니다. qwen3:4b에게 남은 일은 제출뿐이었는데, 11과제에서 답을 다시 썼고 그중 4과제는 틀린 답이 됐습니다. 정확도 손실 -13.3%p는 이 4건에서 나왔습니다.
2. **답이 나오기 전에 넘기면 4B 모델은 대개 틀렸습니다.** in-context로 가능한 모든 지점에서 이어 실행한 결과 중, Sonnet이 답을 쓰기 전에 넘긴 경우는 110번 중 30번만 정답으로 끝났습니다. 로그 파일은 다섯 규칙이 고른 지점만 돌렸는데 80번 중 1번이었고, 같은 80개 지점에서 in-context는 26번이었습니다. 답을 쓴 뒤에 넘긴 경우는 in-context 42번 중 38번이 정답을 지켰습니다.
3. **정답으로 끝나는 지점은 있었지만 탐지기가 안정적으로 고르지 못했습니다.** 결과를 보고 고른 가장 이른 정답 지점에서 넘기면 29과제는 넘기고 1과제는 Sonnet 혼자 풀어 30/30에 비용 50% 절감입니다(한 번씩 뽑은 결과를 보고 고른 낙관적인 값). 규칙 탐지기는 늦게 넘겨 26/30에 16% 절감이었고, 프롬프트 탐지기는 평균 시점은 비슷했지만(Sonnet 턴의 58%, 사후 최적은 29과제 기준 55%) 정답으로 끝나는 지점을 16/30만 골랐습니다.
4. **넘겨주는 뒤쪽 턴은 싼 턴입니다.** 규칙 탐지기가 넘긴 뒤 Sonnet이 했을 일은 확인과 제출뿐이라 턴당 약 $0.0025로, 그 전($0.0039)보다 쌉니다. 그래서 넘길 때까지 Sonnet은 턴의 78%를 썼지만 비용은 84%를 썼습니다.
5. **로그 파일로 넘기면 더 나빴습니다.** 50% 고정은 12/30에서 2/30으로, 프롬프트 탐지기는 16/30에서 9/30으로 떨어졌습니다. 다 된 답을 넘기는 규칙 탐지기는 합계로는 26/30과 25/30으로 비슷했지만, 7과제에서 결과가 뒤집혔습니다(3개 정답 전환, 4개 오답 전환). 로그 파일 실행의 대부분(113번 중 82번)은 Sonnet in-context 실행과 다른 Ollama 빌드에서 돌았으니 탐색적 비교로만 봐 주세요.
6. **Haiku 5.5 혼자 푸는 쪽이 훨씬 쌌고 잃은 것도 적었습니다.** Haiku 혼자 29/30, 과제당 $0.0018로 Sonnet 혼자 비용의 약 8%입니다. Sonnet → qwen3:4b 넘기기 규칙 어느 것보다 쌉니다. 규칙 탐지기와의 정확도 차이는 +10.0%p(-3.3~+23.3)로 확정할 수 없습니다. 사전 등록하지 않은 비교입니다.
7. **Haiku 5.5 → qwen3:4b도 같은 모양이었습니다.** 규칙 탐지기는 30과제 모두 SUBMIT만 남은 시점에 넘겼고, 27/30(-6.7%p, -16.7~0.0)에 비용 12% 절감이었습니다. 놓친 3건 중 1건은 Haiku 자신의 오답이고, 2건은 qwen3:4b가 맞는 답을 덮어쓴 경우입니다. Haiku가 답을 쓰기 전에 넘긴 경우는 in-context 110번 중 27번, 로그 파일 90번 중 4번만 정답이었습니다(같은 90개 지점에서 in-context는 23번). 이 쌍은 in-context 실행의 대부분과 로그 파일 실행이 서로 다른 Ollama 설치에서 돌았습니다.

## 한계와 실행 중에 생긴 일

- 합성 데이터, 테스트 30과제, 과제당 실행 한 번입니다. Sonnet이 과제당 4~9턴 만에 끝내는 짧은 작업이라 넘길 지점도 과제당 3~8개뿐입니다.
- 넘겨받는 모델은 4B 로컬 모델 하나이고, 탐지기는 논문의 학습된 판별기가 아니라 손으로 짠 규칙과 프롬프트입니다.
- qwen3:4b는 temperature 0에 시드를 고정해도 늘 같은 답을 내지는 않았습니다. 같은 설치에서 기록된 턴 10개를 다시 물었더니 3개만 같았습니다. 그래서 각 이어 실행은 한 번 뽑은 표본입니다.
- 실행 중에 Ollama 앱의 자동 업데이트로 설치가 두 번 바뀌었고(0.40.14 추정 → 0.40.1 → 0.40.15 일부 설치), Windows가 세 번 꺼졌습니다. 11-09의 0.40.15 설치는 중간에 취소돼, 실행 파일만 0.40.15이고 모델을 돌리는 라이브러리는 이전 것이 남았습니다. 실행 중 llama-server가 네 번 죽었는데, 클라이언트가 조용히 다시 요청해 넘어간 실패는 실행 로그에 남지 않았습니다. 가설 H1~H4에 쓴 실행은 모두 첫 업데이트 전에 끝났고, 나머지는 저장된 결과에서 이어 돌렸습니다. Ollama가 같은 말을 되풀이하는 답을 끊어 한 단계가 멈추기도 했습니다. 그런 답을 형식 오류로 처리하는 규칙을 넣고 이어 돌렸는데, 같은 이어 실행이 이번에는 끊기지 않아 규칙은 실제로 쓰이지 않았습니다. 경위는 모두 docs/hypotheses.md에 날짜와 함께 남겼습니다.
- 이 노트북은 Windows 응용 프로그램 제어 정책 때문에 pandas를 쓸 수 없어, 에이전트는 표준 라이브러리와 numpy만 썼습니다.

API 비용은 개발 과제를 포함해 모두 $2.14(테스트 $1.72)였고, 실행 시간은 거의 다 qwen3:4b가 차지했습니다.

정리하면, 규칙 탐지기로 4B 로컬 모델에게 넘기는 방식은 이번 설정에서 사전 등록한 기준(비용 40% 절감)을 넘지 못했고 정확도도 떨어졌습니다. 더 일찍 넘기는 규칙은 비용을 더 줄였지만 정확도가 크게 떨어졌습니다. 준비 신호를 파일 기준으로 옮긴 규칙은 답을 다 쓴 뒤에야 켜졌고, 그보다 일찍 넘기면 4B 모델은 대개 틀렸습니다. 다음에는 답 이전에 중간 산출물(계산 스크립트, 정리된 표)이 생기는 더 긴 작업에서, 신호가 더 일찍 켜지는지 보고 싶습니다.