Toolformer: 스스로 도구 쓰는 법을 배우는 언어 모델

Toolformer: 스스로 도구 쓰는 법을 배우는 언어 모델

언어 모델이 계산기 · 검색 · 질의응답 · 번역 · 달력 같은 API를 언제, 어떻게 부를지 스스로 배우게 한 Meta AI의 논문입니다. 사람이 도구 사용 예시를 대량으로 표시하지 않고, 모델이 직접 넣어 본 API 호출 중 '다음 글자 예측을 실제로 쉽게 만든 것'만 남겨 다시 학습합니다. 67억 파라미터 GPT-J 기반 Toolformer가 여러 과제에서 훨씬 큰 GPT-3(1,750억)를 앞섰습니다.

들어가기 전에

이 해설은 아래 내용을 안다고 보고 씁니다. 처음이라면 먼저 읽고 오면 수식과 손계산을 훨씬 쉽게 따라올 수 있습니다.

• ReAct: 추론과 행동을 함께 — 생각·행동·관찰을 번갈아 쓰게 해 추론과 도구 사용을 결합한 LLM 에이전트 프롬프트
• 언어 모델은 비지도 멀티태스크 학습자다 (GPT-2) — 15억 파라미터 언어 모델이 미세조정 없이 프롬프트만으로 여러 과제를 푼다는 것을 보인 GPT-2

한눈에 보기

• 큰 언어 모델이 왜 계산 · 최신 정보 · 날짜 같은 '기본기'에 약한지, 도구가 이를 어떻게 메우는지 알게 됩니다.
• 샘플링 → 실행 → 걸러 내기 → 미세조정 4단계로 도구 사용 데이터를 스스로 만드는 과정을 이해합니다.
• "이 API 호출이 도움이 됐나?"를 판정하는 손실 비교 기준 을 손계산으로 확인합니다.
• 도구 사용 능력이 어느 모델 크기부터 생기는지, 그리고 이 방식의 한계(도구 연쇄 불가 등)를 압니다.

초록 (번역)

언어 모델(LM)은 몇 개의 예시나 글로 된 지시만으로 새 과제를 푸는 놀라운 능력을 보이며, 특히 규모가 클 때 그렇습니다. 그런데 역설적으로, 훨씬 단순하고 작은 모델이 잘하는 산술이나 사실 조회 같은 기본 기능에는 어려움을 겪습니다. 이 논문에서는 언어 모델이 간단한 API를 통해 외부 도구를 쓰는 법을 스스로 배워, 두 세계의 장점을 모두 얻을 수 있음을 보입니다. 우리는 어떤 API를 부를지, 언제 부를지, 어떤 인자를 넘길지, 결과를 이후 토큰 예측에 어떻게 가장 잘 녹일지를 결정하도록 학습된 모델 Toolformer를 소개합니다. 이 학습은 자기 지도 방식으로 이루어지며, API마다 몇 개의 시연만 있으면 됩니다. 계산기, 질의응답 시스템, 서로 다른 두 검색 엔진, 번역 시스템, 달력 등 다양한 도구를 포함했습니다. Toolformer는 핵심 언어 모델링 능력을 희생하지 않으면서 다양한 하위 과제에서 제로샷 성능을 크게 높였으며, 훨씬 큰 모델과 견줄 만한 경우가 많았습니다.

무엇을 풀었나

대형 언어 모델은 많은 과제를 잘하지만, 규모를 키워도 완전히 고쳐지지 않는 한계가 있다고 논문은 정리합니다.

• 최근 사건 같은 최신 정보 에 접근하지 못하고, 그래서 사실을 지어내는 경향
• 자원이 적은 언어 를 이해하기 어려움
• 정확한 계산 능력 부족
• 시간의 흐름 을 모름(오늘이 며칠인지 모름)

해법은 단순합니다. 검색 엔진 · 계산기 · 달력 같은 외부 도구 를 쓰게 하면 됩니다. 그런데 기존 방법은 ① 사람이 도구 사용을 대량으로 표시해야 하거나, ② 특정 과제에서만 도구를 쓰게 했습니다.

Toolformer가 노린 조건은 두 가지입니다.

1. 자기 지도로 배울 것. 대량의 사람 주석 없이. 논문은 비용 문제뿐 아니라 "사람이 유용하다고 보는 것과 모델이 유용하다고 보는 것이 다를 수 있다"는 점도 이유로 듭니다.
2. 일반성을 잃지 않을 것. 특정 과제에 묶이지 않고, 언제 어떤 도구를 쓸지 모델이 스스로 정하게.

핵심 아이디어

1234567flowchart LR
  C[일반 텍스트 데이터 CCNet] --> S[1. 샘플링: 프롬프트로 API 호출 후보 삽입]
  S --> E[2. 실행: 계산기 · 검색 · QA · 번역 · 달력 호출]
  E --> F["3. 걸러 내기: 다음 토큰 손실을 τf 이상 줄인 호출만"]
  F --> D[(API 호출이 끼워진 데이터 C*)]
  D --> T[4. GPT-J 미세조정]
  T --> I["추론: '→' 나오면 API 실행 · 결과 삽입 후 이어서 생성"]

1. API 호출을 '텍스트'로 표현하기

직관. 글을 쓰다가 괄호를 열고 "[계산기(400/1400)]"라고 적으면 옆 사람이 답 "0.29"를 적어 주는 것과 같습니다. 모델은 괄호를 언제 열지, 안에 무엇을 적을지만 배우면 됩니다.

단계별 설명.

1. API 호출 하나를 이름과 입력의 쌍 $c = (a_c, i_c)$로 나타냅니다.
2. 결과가 $r$이면, 호출을 다음처럼 텍스트로 펼칩니다.
3. 실제로는 특수 토큰 대신 "[", "]", "->" 문자열을 써서 기존 어휘를 바꾸지 않습니다.

수식.

논문의 예. "1,400명의 참가자 중 400명(또는 [Calculator(400 / 1400) → 0.29] 29%)이 합격했다." / "브라운 법은 [WikiSearch("Brown Act") → 랄프 M. 브라운 법은 …] 캘리포니아 법으로, 시의회 같은 입법 기관이 회의를 공개하도록 요구한다."

2. 1단계 샘플링: 어디에, 어떤 호출을 넣을까

직관. 모델에게 "이 글에 질문 API를 넣을 만한 곳에 넣어 봐"라는 지시와 예시 몇 개를 보여 주고, 후보를 많이 뽑게 합니다.

단계별 설명.

1. API마다 '이 글에 API 호출을 추가하라'는 지시와 몇 개의 예시로 된 프롬프트 $P(x)$를 씁니다.
2. 글의 각 위치 $i$에서 모델이 그 자리에 <API>를 시작할 확률 $p_i$를 계산합니다.
3. $p_i$가 임곗값 $\tau_s$보다 큰 위치만 남기고, 많으면 상위 $k$개만 남깁니다.
4. 남은 위치마다 호출 후보를 최대 $m$개 샘플링합니다.

수식.

3. 2~3단계 실행과 걸러 내기: 정말 도움이 됐나

직관. 학생이 문제를 풀다 계산기를 두드렸다면, 그 결과 덕분에 뒷부분을 더 잘 쓰게 됐는지 로 계산기 사용이 의미 있었는지 판단합니다. 결과를 안 봤을 때나, 버튼만 누르고 결과를 안 봤을 때보다 나아야 합니다.

단계별 설명.

1. 뽑은 호출을 실제로 실행해 결과 $r_i$를 얻습니다.
2. 호출 위치 이후 토큰들 $x_i, \dots, x_n$에 대한 가중 교차 엔트로피 손실 을 세 경우로 계산합니다.
   • 호출 + 결과를 앞에 붙였을 때
   • 호출을 아예 안 했을 때
   • 호출은 했지만 결과를 안 줬을 때
3. "호출 + 결과"의 손실이 나머지 둘 중 작은 쪽보다 $\tau_f$ 이상 작으면 그 호출을 남깁니다.

수식.

숫자로 해 보기 (설명용 예시, 논문 수치 아님). 가중치는 $\tilde{w} = (1, 0.8, 0.6, 0.4, 0.2, 0, \dots)$이고 합이 3이므로 $w = (0.33, 0.27, 0.2, 0.13, 0.07)$입니다. 호출 바로 뒤 토큰이 가장 중요합니다.

• 호출 없음: $L(\varepsilon) = 2.4$
• 결과 없는 호출: $L(e(c, \varepsilon)) = 2.3$ → $L^{-} = 2.3$
• 호출 + 결과: $L^{+} = 1.1$
• 차이 $2.3 - 1.1 = 1.2$. $\tau_f = 1.0$이면 남기고, $\tau_f = 2.0$이면 버립니다.

왜 '결과 없는 호출'과도 비교하나. 호출 문장 자체(예: "QA(코카콜라를 만드는 회사는?)")가 힌트가 되어 손실이 줄 수도 있기 때문입니다. 결과 가 실제로 도움을 줬을 때만 남기려는 장치입니다.

4. 4단계 미세조정과 추론

• 남은 호출을 원래 글의 해당 위치에 끼워 넣어 데이터 $C^*$를 만듭니다. 호출을 빼면 원래 글과 똑같으므로, 같은 내용으로 학습하면서 도구 사용만 추가로 배웁니다. 그래서 언어 모델 능력을 잃지 않습니다.
• 이 데이터로 일반 언어 모델 목표로 미세조정합니다(배치 128, 학습률 $1 \times 10^{-5}$, 처음 10% 선형 워밍업).
• 추론 때는 평소처럼 생성하다가 "→" 토큰이 나오면 멈추고 API를 실행해 결과와 </API>를 넣은 뒤 이어서 생성합니다.
• 평가 때는 <API>가 상위 $k = 10$ 후보 안에 들기만 해도 호출을 시작하게 해 도구 사용을 늘리고, 입력마다 최대 한 번만 호출하게 했습니다.

5. 도구 다섯 가지

학습 데이터는 CCNet 일부로, 계산기는 숫자가 3개 이상 든 글만 쓰는 등 도구별 휴리스틱으로 후보를 줄였습니다. 걸러 내기 임곗값 $\tau_f = 1.0$일 때 남은 예시 수는 QA 18,526개, 위키 검색 60,974개, 계산기 994개, 달력 20,587개, 번역 1,034개였습니다.

결과

사실 빈칸 채우기 (LAMA, 제로샷)

수학 서술형 (제로샷)

질의응답 (제로샷): WebQS 26.3, NQ 17.7, TriviaQA 48.8로 같은 크기 모델은 넘었지만 GPT-3(29.0 · 22.6 · 65.9)에는 못 미쳤습니다.

시간 관련 (TEMPLAMA / DATESET): Toolformer 16.3 / 27.3, GPT-3 15.5 / 0.8. DATESET 향상은 전적으로 달력 도구 덕분으로, 예시의 54.8%에서 달력을 불렀습니다.

언어 모델 능력 유지 (퍼플렉서티): API 호출 없이 평가하면 WikiText에서 GPT-J 9.9, 일반 CCNet로 미세조정한 GPT-J 10.3, Toolformer(도구 끔) 10.3으로, 도구 학습이 언어 모델링 능력을 해치지 않았습니다.

모델 크기: GPT-2 계열(1억 2,400만 ~ 16억)로 실험하니 도구를 잘 쓰는 능력은 약 7억 7,500만 파라미터 부근에서야 나타났습니다. 더 작은 모델은 도구가 있으나 없으나 비슷했습니다(쓰기 쉬운 위키 검색은 예외).

왜 중요한가 · 이후 영향

• "모델이 도구 호출을 직접 생성한다" 는 발상을 대중화했습니다. 오늘날 LLM의 함수 호출(function calling) · 도구 사용 기능과 같은 방향의 연구입니다.
• 자기 지도 데이터 생성 의 좋은 예입니다. 사람이 '정답 도구 사용'을 다 표시하지 않고, '다음 글 예측에 도움이 됐는가'라는 모델 자신의 기준으로 데이터를 걸러 냈습니다.
• 작은 모델 + 도구 > 큰 모델 이라는 결과(67억 대 1,750억)는 업무 자동화에서 계산 · 조회는 도구에 맡기는 설계의 근거가 됩니다.

한계 · 주의할 점

• 도구를 연쇄로 쓰지 못합니다. 한 도구의 결과를 다른 도구의 입력으로 쓰는 예시가 학습 데이터에 없기 때문입니다(호출을 도구별로 따로 샘플링). 예를 들어 '달력으로 오늘 날짜 확인 → 그 날짜로 질의응답'이 필요한 TEMPLAMA에서 이득이 작았습니다.
• 상호작용형 사용을 못 합니다. 검색 결과 수백 개를 훑어보거나 검색어를 고쳐 다시 찾는 식의 사용은 지원하지 않습니다.
• 입력 문구에 민감합니다. API를 부를지 말지가 입력의 정확한 표현에 따라 쉽게 바뀐다고 논문이 밝힙니다.
• 표본 효율이 낮은 도구가 있습니다. 계산기처럼 쓸모 있는 호출을 몇 개 얻으려면 매우 많은 문서를 처리해야 합니다.
• 비용을 고려하지 않습니다. 도구 호출에 드는 시간 · 비용을 판단에 넣지 않습니다.

스스로 점검

1. 어떤 API 호출을 학습 데이터에 남기는 기준은?

   호출과 결과를 함께 줬을 때의 손실 $L^{+}$가, 호출을 안 했을 때와 결과 없이 호출만 했을 때 중 더 작은 손실 $L^{-}$보다 $\tau_f$ 이상 작을 때만 남깁니다.

2. $L(\varepsilon) = 3.0$, $L(e(c, \varepsilon)) = 2.6$, $L^{+} = 2.0$, $\tau_f = 1.0$이면 남기나요?

   $L^{-} = \min(3.0, 2.6) = 2.6$, 차이 $2.6 - 2.0 = 0.6 < 1.0$이므로 버립니다.

3. 도구를 학습해도 언어 모델 능력이 줄지 않는 이유는?

   호출을 끼운 데이터가 호출 부분을 빼면 원래 사전학습 데이터와 똑같은 글이라, 같은 내용으로 학습하면서 도구 사용만 추가로 배우기 때문입니다. 퍼플렉서티도 거의 그대로였습니다.

용어 정리

이어서 읽을 것

• 앞: ReAct · 검색 증강 생성 (RAG)
• 뒤: Reflexion · Self-RAG · MemGPT · SWE-bench

다음에 볼 것

이 글을 이해했다면 이어서 보면 좋은 항목입니다.

• 에이전트 설계: 루프 · 워크플로 · 메모리 · 멀티에이전트 · MCP — 도구를 쓰는 모델을 실제 에이전트로 설계하는 법
• SWE-bench: 실제 깃허브 이슈를 풀 수 있는가 — 실제 깃허브 이슈 2,294개를 실제 테스트로 채점하는 저장소 단위 코딩 벤치마크

출처

• 원문: arxiv.org/abs/2302.04761 (2023 · Timo Schick 외)