본문 바로가기
AI 생성 글 정리/agent

Toolformer 논문 핵심 정리

by Honbul 2026. 4. 1.

Language Models Can Teach Themselves to Use Tools

Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom
Meta AI Research / Universitat Pompeu Fabra
정리 기준: 업로드된 arXiv v1 PDF (2023-02-09)

논문 한 줄 요약

Toolformer는 언어모델이 계산기, 검색기, 번역기, 캘린더 같은 외부 도구를 “언제 호출할지, 무엇을 물을지, 결과를 어떻게 쓸지”를 스스로 학습하게 만든 논문이다.
핵심은 사람이 대규모 정답 라벨을 주지 않아도, “이 API 호출이 미래 토큰 예측 손실을 실제로 줄여주는가?” 만으로 유용한 도구 사용 예시를 골라내고, 그 예시들로 모델을 다시 학습시키는 데 있다.

먼저 잡아야 할 핵심 포인트 5가지

  1. 도구 사용을 task-specific prompt engineering이 아니라 pretraining/finetuning 수준에서 학습시킨다.
  2. 학습 신호가 사람 라벨이 아니라 “미래 토큰 예측 손실 감소”다.
  3. 원래의 언어모델 데이터에 API 호출만 끼워 넣기 때문에 일반 언어모델 능력을 크게 해치지 않는다.
  4. 수학·사실성·시간 정보·다국어 처리처럼 LM의 약한 부분을 외부 도구로 보완한다.
  5. 작은 모델에서는 잘 안 되지만, 일정 규모 이상에서는 tool use가 뚜렷하게 나타난다.

왜 이 논문이 중요한가

대규모 언어모델은 자연어 생성과 일반화에는 강하지만, 다음과 같은 약점이 있다.

  • 정확한 계산에 약하다.
  • 최신 정보나 외부 지식 접근이 어렵다.
  • 환각(hallucination) 문제가 있다.
  • 시간의 흐름을 직접 인식하지 못한다.
  • 저자원 언어 / 다국어 이해가 불안정하다.

이 문제를 해결하는 단순한 방법은 모델 밖의 도구를 쓰게 하는 것이다.
하지만 기존 접근은 대체로 두 갈래였다.

  • 사람이 직접 “여기서는 검색하고, 여기서는 계산해”라고 많이 가르치거나
  • 특정 태스크에서만 통하는 few-shot prompting에 의존한다.

Toolformer의 포인트는 여기서 한 단계 더 나아간다.
도구 사용 자체를 언어모델이 자가학습(self-supervised)하도록 만들었다는 점이 이 논문의 핵심이다.

Figure 1: Toolformer가 실제로 무엇을 하는지

 

 

Figure 1. 논문 Figure 1 (p.1). 모델이 문장 안에 QA, Calculator, MT, WikiSearch 호출을 자연스럽게 삽입하는 예시.

이 그림은 Toolformer의 직관을 가장 잘 보여준다.

  • 문장을 생성하다가
  • 필요한 시점에
  • 적절한 도구를 골라
  • API 호출을 텍스트 형태로 삽입하고
  • 결과를 받아 이어서 문장을 완성한다.

즉, Toolformer는 “도구를 붙인 모델”이라기보다,
도구를 문장 생성 과정 안으로 끌어들인 모델에 가깝다.

블로그에서 이 그림을 설명할 때 강조할 포인트는 다음 두 가지다.

  • 도구 선택이 고정 규칙이 아니라 모델의 선택이라는 점
  • 도구 결과가 다시 다음 토큰 예측에 직접 반영된다는 점

핵심 아이디어 한 문장

유용한 API 호출만 남기는 데이터 증강 → 그 데이터로 다시 언어모델을 학습 → 추론 시 실제 API를 호출

이 논문은 본질적으로 “LM이 스스로 만든 tool-use training data로 다시 LM을 학습시키는 구조”다.

방법론: Toolformer는 어떻게 학습되는가

1) API 호출을 텍스트로 표현한다

논문은 API 호출을 일반 텍스트 안에 끼워 넣을 수 있도록 선형화(linearization)한다.

  • API 호출만 있을 때:
    <API> a_c(i_c) </API>
  • API 응답까지 포함할 때:
    <API> a_c(i_c) → r </API>

논문에서는 실제로 기존 vocabulary를 바꾸지 않기 위해 [ ] -> 같은 토큰 시퀀스를 사용한다.
핵심은 API 입출력을 모두 텍스트 시퀀스로 다룬다는 점이다.

Figure 2: 전체 학습 파이프라인

 

 

Figure 2. 논문 Figure 2 (p.2). Sample API Calls → Execute API Calls → Filter API Calls → LM dataset with API calls.

이 그림이 Toolformer 전체를 가장 정확히 요약한다.
파이프라인은 크게 3단계다.

2) 후보 API 호출을 샘플링한다

각 API마다 간단한 시연 예시가 들어간 프롬프트 (P(x))를 만든다.
그 다음 언어모델이 어느 위치에서 <API> 토큰을 시작할 가능성이 높은지 본다.

  • 특정 위치 (i)에서 API 호출을 시작할 확률이 높으면
  • 그 위치를 후보로 잡고
  • 해당 위치에서 여러 개의 API 호출 후보를 샘플링한다.

즉, 모델 스스로 “여기서 뭔가 물어보는 게 도움이 될 것 같다”라고 판단한 지점을 찾는다.

3) 샘플링된 API 호출을 실제로 실행한다

여기서는 도구마다 방식이 다르다.

  • QA: Atlas
  • Calculator: 간단한 파이썬 계산기
  • WikiSearch: Wikipedia BM25 검색
  • MT: NLLB 기반 번역
  • Calendar: 현재 날짜 반환

중요한 점은 호출 결과도 텍스트로 돌아온다는 점이다.

4) 유용한 API 호출만 남긴다

이 단계가 Toolformer의 핵심이다.
논문은 다음 질문을 묻는다.

“이 API 호출과 응답을 모델에게 보여주면, 이후 토큰을 더 잘 맞히는가?”

이를 위해 미래 토큰 구간의 weighted cross entropy loss를 비교한다.

$$
L_i(z) = -\sum_{j=i}^{n} w_{j-i}\log p_M(x_j \mid z, x_{1:j-1})
$$

그리고 두 경우를 비교한다.

  • (L_i^+): API 호출과 응답을 모두 prefix로 준 경우
  • (L_i^-):
    • 아무 API 호출도 안 한 경우
    • API 호출은 했지만 응답은 안 준 경우
      둘 중 더 좋은(낮은 loss) 쪽

최종적으로 아래 조건을 만족하는 호출만 남긴다.

$$
L_i^- - L_i^+ \ge \tau_f
$$

직관적으로 말하면:

  • 응답까지 받은 API 호출이
  • 아무 것도 안 하거나, 질문만 하고 답을 못 받은 경우보다
  • 다음 토큰 예측을 더 쉽게 해주면
  • 그 호출을 “유용한 도구 사용 예시”로 인정한다.

이 부분이 이 논문의 가장 아름다운 포인트다.
사람이 “좋은 호출”을 라벨링하지 않아도, 언어모델 자신의 예측 손실이 좋은 호출을 골라내는 기준이 된다.

5) 이렇게 걸러진 호출들을 원래 텍스트에 삽입해 다시 학습한다

필터링을 통과한 API 호출들은 원래 말뭉치 텍스트 사이에 삽입된다.
그렇게 만들어진 새 데이터셋 (C^*)로 모델을 finetuning한다.

이 설계가 중요한 이유는 다음과 같다.

  • 원래 텍스트는 유지된다.
  • 거기에 유용한 API 호출만 추가된다.
  • 그래서 도구 사용 능력은 늘리고, 원래의 LM 능력은 최대한 보존할 수 있다.

6) 추론 시에는 실제 API를 호출한다

finetuning이 끝난 뒤에는 일반적인 디코딩을 하다가, 모델이 API 호출을 생성하면 해당 API를 실제로 실행하고 응답을 다시 텍스트에 삽입한 뒤 생성을 이어간다.

즉, 학습 때 본 패턴을 추론 때 실제 런타임 도구 사용으로 연결한다.

Figure 3: 프롬프트 몇 개만으로 도구 사용 데이터를 만든다

 

Figure 3. 논문 Figure 3 (p.3). Question Answering API를 위한 예시 프롬프트.

이 그림은 Toolformer가 얼마나 단순한 인터페이스 위에 서 있는지를 보여준다.

  • 각 API마다
  • 사람은 몇 개의 예시(prompt demonstrations)만 적어준다.
  • 그러면 모델이 그 패턴을 따라 대량의 API 호출 후보를 스스로 생성한다.

즉, Toolformer의 강점은
“복잡한 supervised annotation 파이프라인 없이, API 사용 예시 몇 개만으로 학습 데이터를 만든다”는 점이다.

블로그에서는 이 Figure를 두고
“프롬프트가 API 스펙이자 시드 데이터 역할을 한다”고 설명하면 이해가 빠르다.

Toolformer가 사용한 5가지 도구

도구 역할 논문에서 사용한 구현
Question Answering 사실형 질문 응답 Atlas (Natural Questions 기반)
Calculator 사칙연산 단순 파이썬 계산기
Wikipedia Search 위키 검색 스니펫 반환 BM25 Retriever
Machine Translation 비영어 텍스트를 영어로 번역 NLLB 600M + fastText language ID
Calendar 현재 날짜 제공 입력 없이 현재 날짜 반환

이 구성을 보면 Toolformer가 겨냥하는 약점이 분명하다.

  • 지식 조회
  • 정밀 계산
  • 다국어 해석
  • 시간 정보 인식

즉, “LLM이 잘 못하는 것”을 정면으로 찌르는 도구들이다.

실험 설정에서 꼭 알아둘 점

논문 결과를 읽을 때는 다음을 함께 봐야 한다.

  1. Zero-shot 평가다.
    태스크별 in-context 예시를 별도로 주지 않는다.
  2. Toolformer는 추론 시 API 호출을 더 잘 하도록 약간 수정된 decoding 전략을 쓴다.
    <API>가 꼭 1등 토큰이 아니어도 상위 (k)개 안에 들면 호출을 시작할 수 있게 한다.
    논문 본 실험에서는 주로 (k=10)을 사용한다.
  3. 한 입력당 최대 1회의 API 호출만 허용한다.
    이 제약은 뒤에서 나오는 한계와도 연결된다.
  4. 일부 벤치마크는 완전한 exact match가 아니라 완화된 평가 기준을 쓴다.
    예를 들어 정답이 생성 초반부에 포함되는지 등을 본다.
    이는 zero-shot 생성 설정 때문이며, 결과 해석 시 감안해야 한다.

실험 결과 요약

한눈에 보는 대표 결과

영역 대표 데이터셋 Toolformer 비교 기준
사실성 / 지식 회수 T-REx 53.5 GPT-J+CC 33.2 / GPT-3 39.8
수학 추론 MAWPS 44.0 GPT-J+CC 9.3 / GPT-3 19.8
오픈도메인 QA WebQS 26.3 GPT-J+CC 18.4 / GPT-3 29.0
시간 추론 DATESET 27.3 GPT-J 3.9 / GPT-3 0.8
언어모델 성능 보존 CCNet PPL 10.5 GPT-J+CC 10.5
언어모델 성능 보존 WikiText PPL 10.3 GPT-J+CC 10.3

이 표에서 바로 읽히는 메시지는 간단하다.

  • Tool use가 필요한 영역에서는 개선 폭이 매우 크다.
  • 특히 계산, 시간, 사실 조회에서 강하다.
  • 동시에 언어모델 perplexity는 거의 유지된다.

1. LAMA: 사실성 / 지식 회수

LAMA의 대표 결과는 다음과 같다.

  • SQuAD subset: 33.8
  • Google-RE: 11.5
  • T-REx: 53.5

같은 크기 계열의 GPT-J 기반 모델보다 명확히 높고, 일부는 GPT-3 (175B)보다도 낫다.

여기서 포인트는 Toolformer가 대부분의 사례에서 Question Answering tool을 호출한다는 점이다.
논문에 따르면 LAMA 계열에서 QA tool 사용 비율은 98.1%다.

해석

이 결과는 “모델 내부에 모든 지식을 저장하는 것”보다
필요할 때 외부에서 정확한 사실을 가져오는 쪽이 더 효율적일 수 있다는 점을 보여준다.

2. Math Benchmarks: 계산 능력은 도구가 압도적으로 유리하다

수학 벤치마크 결과는 논문의 메시지가 가장 선명하게 드러나는 부분이다.

모델 ASDiv SVAMP MAWPS
GPT-J 7.5 5.2 9.9
GPT-J + CC 9.6 5.0 9.3
Toolformer (disabled) 14.8 6.3 15.0
Toolformer 40.4 29.4 44.0
GPT-3 (175B) 14.0 10.0 19.8

여기서 두 가지를 동시에 읽어야 한다.

포인트 A. 실제 calculator 호출이 엄청난 차이를 만든다

Toolformer는 수학 태스크의 97.9%에서 계산기를 호출한다.
그리고 그 효과가 숫자로 바로 드러난다.

포인트 B. 호출을 막아도 약간 좋아진다

Toolformer (disabled)도 GPT-J보다 낫다.
즉, 모델은 tool-use 데이터로 학습하면서 어느 정도 계산 패턴 자체도 흡수했다.

하지만 결정적 점프는 여전히 실제 도구 실행에서 나온다.
이 논문이 “모델 내부 reasoning만 키우면 된다”가 아니라
“외부 도구를 제대로 쓰는 편이 더 낫다”는 주장을 뒷받침하는 대목이다.

3. Open-domain QA: 개선되지만 GPT-3를 완전히 넘지는 못한다

WebQS, Natural Questions, TriviaQA에서도 Toolformer는 GPT-J 계열 기준으로 성능이 오른다.

  • WebQS: 26.3
  • NQ: 17.7
  • TriviaQA: 48.8

논문은 이 실험에서 Question Answering tool은 아예 비활성화한다.
그 도구를 켜 두면 사실상 태스크가 너무 쉬워지기 때문이다.
대신 Toolformer는 주로 Wikipedia Search를 사용한다.

논문에 따르면 이때 WikiSearch 사용 비율은 99.3%다.

왜 GPT-3를 확실히 넘지 못했을까

저자들의 해석은 설득력 있다.

  • 검색기가 단순 BM25 기반이라 질이 제한적이고
  • 한 번 검색해서 나온 결과만 쓰며
  • 검색어를 다시 고치거나 결과를 여러 번 탐색하는 interactive retrieval이 없다.

즉, Toolformer는 “검색을 할 줄 아는 모델”이지만
아직 “웹을 탐색하는 에이전트”는 아니다.

4. Multilingual QA: 번역 도구는 도움되지만 항상 이기지는 않는다

MLQA에서는 스페인어, 독일어, 힌디어, 베트남어, 중국어, 아랍어 질문을 다룬다.
여기서 Toolformer는 번역 도구를 활용해 질문을 영어로 옮기고 문제를 풀 수 있다.

이 실험의 메시지는 조금 더 섬세하다.

  • API 사용 자체는 대부분의 언어에서 도움이 된다.
  • 하지만 CCNet으로 추가 finetuning한 영향 때문에 일부 언어에서는 vanilla GPT-J 대비 일관된 우위를 보이지는 않는다.

즉, 이 논문은 multilingual setting에서도 잠재력을 보여주지만,
가장 깔끔한 승리는 사실성과 계산 영역에서 나온다.

5. Temporal Datasets: Calendar tool의 효과와 한계

시간 관련 데이터셋은 두 종류다.

  • TEMPLAMA
  • DATESET (논문이 새로 만든 데이터셋)

결과는 다음 메시지를 준다.

DATESET에서는 Calendar가 확실히 먹힌다

DATESET에서 Toolformer는 27.3으로 크게 향상되며,
Calendar tool 사용 비율도 54.8%다.

즉, “오늘이 언제인지”를 알아야 하는 질문에서는
외부 캘린더 API가 직접적인 해답이 된다.

하지만 TEMPLAMA에서는 Calendar가 거의 안 쓰인다

TEMPLAMA 개선은 있긴 하지만, 그 주원인은 Calendar보다 QA / WikiSearch다.
왜냐하면 이 태스크는 종종 현재 날짜를 안다고 끝나는 문제가 아니라,
날짜를 바탕으로 다시 다른 사실을 검색해야 하기 때문이다.

여기서 논문의 한계가 드러난다.

  • 한 번에 최대 1회 API 호출만 허용하고
  • tool chaining 학습도 하지 않기 때문에
  • Calendar → QA처럼 이어지는 사용을 잘 못한다.

6. Language Modeling 성능은 유지된다

이 논문의 강점은 단순히 벤치마크 점수 상승이 아니다.
저자들은 Toolformer가 언어모델로서 기본 능력을 해치지 않는지도 확인한다.

모델 WikiText PPL CCNet PPL
GPT-J 9.9 10.6
GPT-J + CC 10.3 10.5
Toolformer (disabled) 10.3 10.5

중요한 해석은 다음이다.

  • API 호출을 넣은 데이터로 학습했다고 해서, API를 쓰지 않는 일반 LM 성능이 더 나빠지지 않았다.
  • 즉, Toolformer는 도구 사용 능력을 추가하면서도 기본 언어모델 성질을 유지한다.

이 결과가 중요한 이유는 Toolformer의 설계 철학과 연결된다.
학습 데이터 (C^)는 완전히 새로운 데이터가 아니라,
*원래 텍스트 (C)에 유용한 API 호출만 덧붙인 형태**이기 때문이다.

Figure 4: Tool use는 일정 규모 이상에서 본격적으로 나타난다

 

Figure 4. 논문 Figure 4 (p.9). 작은 모델에서는 도구 사용 이득이 작고, 약 7.75억 파라미터 부근부터 효과가 뚜렷해진다.

이 그림은 Toolformer를 단순 기능 추가가 아니라 emergent behavior 관점에서 보게 만든다.

저자들은 GPT-2 계열의 작은 모델부터 GPT-J까지 비교했는데, 결론은 다음과 같다.

  • 매우 작은 모델에서는 tool use 효과가 제한적이다.
  • 대략 775M 파라미터 근처부터 도구 활용 능력이 분명해진다.
  • 모델이 커질수록
    • 도구 없이도 기본 성능이 올라가고
    • 도구를 쓸 때의 추가 이득도 함께 커진다.

블로그에서 꼭 강조할 문장

“도구를 붙인다고 바로 다 잘하는 것이 아니라, 도구를 ‘언제’ 써야 할지 판단하는 능력도 어느 정도 규모에서야 emergent하게 나타난다.”

논문에서 특히 좋았던 지점

1. supervised label 대신 LM loss를 사용한다

이 논문의 미학은 여기에 있다.
좋은 API 호출인지 아닌지를 사람이 판단하지 않는다.
“그 호출이 이후 예측을 쉽게 해주는가”라는 언어모델 본연의 목표로 판단한다.

2. tool use를 특정 태스크에 묶지 않는다

기존의 많은 도구 사용 연구는 태스크별 prompt나 workflow에 강하게 묶여 있었다.
Toolformer는 일반 언어모델 데이터셋 자체에 tool use를 주입한다.

3. 성능 향상 방식이 해석 가능하다

어떤 태스크에서 어떤 도구를 얼마나 썼는지가 비교적 명확하다.

  • LAMA: QA
  • Math: Calculator
  • QA: WikiSearch
  • DATESET: Calendar

즉, “왜 점수가 올랐는지”를 납득하기 쉽다.

4. Toolformer (disabled) 비교가 좋다

이 비교 덕분에 다음을 분리해서 볼 수 있다.

  • 도구 호출을 학습하면서 모델 내부 능력이 조금 향상된 효과
  • 실제 런타임 도구 실행이 만든 효과

이건 실험 설계 면에서 꽤 깔끔하다.

읽을 때 놓치기 쉬운 디테일

1. 결과의 상당 부분은 decoding 전략에 의존한다

논문은 <API>가 꼭 argmax가 아니어도 top-k 안에 들면 호출하게 만든다.
즉, 실제 성능은 “모델이 API를 생각해냈는가”뿐 아니라
“그 API 호출을 실행까지 연결해 주는 디코딩 정책”에도 영향을 받는다.

2. 한 번만 호출하게 한 제약은 실용적이지만 강한 제한이다

무한 루프를 막기 위한 선택이지만,
현실적인 문제 해결에서는 여러 번의 검색/계산/질문이 필요할 수 있다.

3. search tool은 생각보다 약하다

오늘날 관점에서 보면 WikiSearch는 매우 단순하다.
그래서 Toolformer의 아이디어는 강하지만, 실험에서 사용한 retrieval stack은 아직 초보적이다.

한계

논문이 직접 밝히는 한계도 명확하다.

  1. Tool chaining이 안 된다
    한 도구의 출력을 다른 도구 입력으로 이어 쓰는 패턴을 학습하지 못한다.
  2. Interactive tool use가 어렵다
    검색 결과를 다시 보고 질의를 수정하거나 여러 결과를 탐색하지 못한다.
  3. 입력 wording에 민감하다
    어떤 표현에서는 API를 잘 호출하고, 어떤 표현에서는 놓칠 수 있다.
  4. 도구별 데이터 효율이 낮다
    특히 calculator처럼 유용한 예시가 드문 도구는 대량 문서를 처리해도 예시가 많이 나오지 않는다.
  5. 도구 사용 비용을 고려하지 않는다
    어떤 API는 비쌀 수 있지만, Toolformer는 현재 그 비용을 의사결정에 넣지 않는다.

이 논문을 한 문장으로 평가하면

Toolformer는 “LLM이 외부 도구를 쓰게 하자”가 아니라, “LLM이 도구 사용 자체를 자신의 언어모델링 목표로부터 배우게 하자”는 제안을 성공적으로 보여준 초기의 중요한 논문이다.

특히 다음 점에서 의미가 크다.

  • 에이전트형 LLM 이전 단계에서
  • 이미 “도구 사용을 학습 가능한 행동”으로 다뤘고
  • 그 판단 기준을 LM loss로 연결했다는 점

오늘날의 function calling, tool-augmented agents, retrieval-augmented systems를 볼 때도
Toolformer는 여전히 개념적으로 매우 깔끔한 출발점이다.

강조 문장 7개

  1. Toolformer의 진짜 핵심은 tool augmentation이 아니라 tool selection을 self-supervised하게 학습시킨다는 점이다.
  2. 이 논문에서 “좋은 API 호출”의 정의는 사람이 아니라 미래 토큰 예측 손실이 정한다.
  3. 모델이 도구를 쓰는 이유가 설명 가능하다: 어떤 태스크에서 어떤 도구를 얼마나 썼는지가 비교적 명확하다.
  4. 계산 같은 영역에서는 모델을 더 키우는 것보다 계산기를 연결해 쓰는 편이 훨씬 직접적이다.
  5. Toolformer는 모델 내부 파라미터에 모든 능력을 집어넣기보다, 외부 도구를 적절히 호출하는 방향을 제시한다.
  6. 작은 모델은 도구를 잘 활용하지 못하지만, 일정 규모 이상부터 tool use가 emergent하게 나타난다.
  7. 오늘날의 agent/tool calling 흐름을 이해하려면 Toolformer는 한 번은 짚고 가야 할 논문이다.

참고: 논문에서 직접 보면 좋은 페이지

  • p.1: Figure 1 — Toolformer가 실제로 어떻게 문장 안에서 API를 호출하는지 직관적으로 보여준다.
  • p.2: Figure 2 — 전체 학습 파이프라인의 핵심.
  • p.3: Figure 3 — few-shot prompt가 어떻게 API 사용 예시를 만드는지 보여준다.
  • p.5–8: 주요 실험 결과 표.
  • p.8: perplexity 결과.
  • p.9: Figure 4 — scaling law와 decoding 분석.

원문 정보

  • 논문명: Toolformer: Language Models Can Teach Themselves to Use Tools
  • 저자: Timo Schick et al.
  • 형태: arXiv preprint, 2023
  • 정리 기준 문서: 업로드된 2302.04761v1.pdf

'AI 생성 글 정리 > agent' 카테고리의 다른 글

Graph of Thoughts 논문 정리  (0) 2026.04.02
MedGemma Technical Report 핵심 정리  (0) 2026.04.01
Deep Research Agents: Major Breakthrough or Incremental Progress for Medical AI? 정리  (0) 2026.04.01
Capabilities of Gemini Models in Medicine 논문 정리  (0) 2026.04.01
VOYAGER 논문 핵심 정리  (0) 2026.04.01

관련글

티스토리툴바