결론 먼저
에이전트가 도구를 부를지 말지는 프롬프트나 파인튜닝 없이, 모델 내부 표현에 방향 벡터 하나를 더하는 걸로 추론 시점에 조절됩니다.
이걸 실제로 보여준 논문이 Tunable Tool-Call Rates in LLM Agents via Representation Steering (arXiv:2608.25198, UC Santa Cruz + UC Berkeley, 2026-08-25) 구요, 핵심 숫자는 이겁니다.
| 항목 | 값 |
|---|---|
| 개입 방식 | 잔여 스트림에 α·v 가산 (학습 0, 프롬프트 변경 0) |
| 호출률 범위 | α=−2에서 0%, α=+2에서 90% 이상 |
| PopQA 정확도 | 0.29 → 0.56 (검색 약 1.1회/질문) |
| 검증 모델 | Qwen3-4B/8B/30B-A3B(MoE), Gemma-4-E4B, gpt-oss-20b |
| 코드 | github.com/YuqiChen4188/Steering-Tool-Use-Propensity |
핵심은 이겁니다. “도구를 부른다/안 부른다”라는 이진 결정이 모델 내부에서 선형 방향 하나로 읽히고, 그 방향을 더하거나 빼는 것만으로 연속적으로 조절된다는 관찰입니다.
무엇이 문제였나
도구 호출은 비쌉니다. 안 해도 되는 호출은 지연과 비용을 늘리고, 되돌릴 수 없는 부작용(이메일 발송, 코드 실행)을 일으킬 수 있구요. 반대로 안 부르면 모델이 자기 지식으로는 못 푸는 문제를 자신만만하게 틀립니다.
실제 측정을 보면 양쪽 실패가 다 있습니다. PopQA에서 스티어링 전 모델은 29%만 맞히면서도 검색을 거의 부르지 않습니다. 반면 어떤 모델은 기본 호출률이 0.83이라 과다 호출 쪽입니다.
기존 해법은 파인튜닝이나 프롬프트 수정인데, 비싸고 추론 시점에 조정하기 어렵습니다.
방법 세 단계
- 성향 프록시: 모델 고유의 도구 호출 오프닝 토큰(예:
<tool_call>)의 첫 토큰 로그확률s(q)를 측정합니다. 생성 없이 forward pass 한 번이면 됩니다. - 방향 추출:
s(q)상하위 10% 쿼리들로 잔여 스트림 평균의 차(difference-of-means)를 구합니다. 라벨, 그래디언트, SAE 전부 불필요하고 몇천 개 쿼리면 충분합니다. - 추론 시 가산:
h' = h + αv를 지정 레이어에 더합니다. α=0이면 원래 모델, 음수는 호출 억제, 양수는 호출 유도구요.
작동 레이어는 중후반(실험 모델 기준 L21–24, 운영 레이어 L22)입니다. 초반 레이어는 거의 무반응이고, 마지막 레이어는 효과는 커도 단조성이 깨집니다.
결과 정리
호출률은 다이얼처럼 움직입니다
α를 −2에서 +3까지 올리면 호출률이 거의 0에서 0.79–1.00까지 단조 증가하구요, 호출 포맷도 잘 유지됩니다. α=+3에서는 malformed 콜이 나오기 시작해 이게 운용 범위의 끝이라고 저자는 표시해둡니다.
새로 생긴 호출은 정확히 모르는 문제에 착지합니다
여기가 결과 중 제일 눈에 띄는 부분인데, α를 올려서 새로 생긴 호출은 모델이 파라미터 지식으로 못 푸는 롱테일 질문 쪽에 집중됩니다. 인기 많은 상식 문제에는 그대로 안 둡니다. PopQA 인기도 하위 십분위 쪽으로 쏠리구요.
실검색에서 정확도가 2배 가까이 오릅니다
실제 검색 API를 붙이고 α를 스윕하면 비용-정확도 파레토 프론티어가 그려집니다. 검색 0회면 0.29이던 정확도가 질문당 약 1.1회 검색에서 0.56까지 오르구요, 검색 장려 프롬프트와 조합하면 0.58까지 갑니다. 프롬프트 엔지니어링과 충돌하지 않고 합성됩니다.
모델 5종에 다 통합니다
Qwen3 4B/8B/30B-A3B(MoE), Gemma-4-E4B(멀티모달), gpt-oss-20b 전부에서 같은 레시피가 먹혔습니다. 기본 호출률은 0.07(과소)에서 0.83(과다)까지 갈렸는데, α=−2면 전부 0.00으로 억제되고 α=+2면 5개 중 4개가 1.00, Qwen3-4B는 0.82까지 올라갑니다. 실검색 실험에서도 무검색 정확도 대비 1.5–2.5배 게인이 다섯 모델 전부에서 확인됐습니다.
도구를 고르는 행동은 건드리지 않습니다
스티어링은 “부를지 말지”만 바꾸고 “어떤 도구를 부를지” 라우팅은 모델 고유 패턴을 유지합니다. Qwen은 α=+2에서 검색/계산기/Python에 골고루 분배하고, Gemma와 gpt-oss는 Python을 거의 안 고르는 원래 성향 그대로구요.
본 적 없는 도구에도 이전됩니다
추출에 안 쓴 6개 홀드아웃 도구(번역, 날씨, 단위변환, 이메일, SQL, 주가 조회)에 같은 벡터를 그대로 적용해도 억제 효과가 각 도구별로 따로 뽑은 벡터와 비슷하거나 더 셉니다. 6개 중 5개에서 멀티툴 벡터가 더 강하고, SQL만 12% 이내 차이입니다. “부를지 말지” 방향이 도구 공통 성분을 담고 있다는 증거구요.
해석과 한계
원문 근거와 제 해석을 나눠서 적자면, 원문이 밝힌 한계는 두 가지입니다. 도구를 부르기로 한 뒤의 실행 품질은 통제하지 못한다, 그리고 reasoning-first 모델은 결정이 읽히기 전에 추론 구간을 우회해야 한다.
제 해석을 덧붙이면, 이건 배포 시점 비용 다이얼로 쓸 수 있는 결과입니다. 트래픽이 몰릴 때 α를 내려 호출 비용을 줄이고, 정확도가 중요한 시점엔 올리는 식으로요. 클램핑 실험(Qwen3-4B에서 호출률 0.01→0.16에 그침)까지 보면 가산 스티어링이 아니면 전체 조절 범위가 안 나온다는 것도 실무 포인트입니다.
더 실습해보고 싶은 분들께
자주 묻는 질문
Q. 프롬프트를 바꾸는 것보다 나은 점이 뭔가요? 프롬프트 없이, 그리고 추론 시점에 연속적으로 조절됩니다. 검색 장려 프롬프트와 조합도 되고요. 다만 별도 레이어 접근 코드가 필요하니 적용 비용은 있습니다.
Q. 호출률 100%로 밀면 무조건 좋아지나요? 그렇지 않습니다. 정확도는 검색 약 1회/질문에서 정점을 찍고 그 뒤로는 비용만 늘어납니다. α=+3부터는 포맷이 깨진 호출도 나옵니다.
Q. 어떤 모델에서 써볼 수 있나요? 논문은 Qwen3 4B/8B/30B-A3B, Gemma-4-E4B, gpt-oss-20b에서 검증했고, 코드가 공개돼 있습니다. 오픈 웨이트 모델 기준으로 잔여 스트림 접근이 가능한 경우 전부 대상입니다.
출처
- 논문: arXiv:2608.25198 / HTML 전문 / DOI: 10.48550/arXiv.2608.25198
- 코드: github.com/YuqiChen4188/Steering-Tool-Use-Propensity
- 기준일: 2026-08-29 기준, v1(2026-08-25 제출) 기준 정리입니다.
