한줄 요약: 소수의 도구 사용 예시에서 출발해 LLM이 스스로 대량의 도구 호출 학습 데이터를 생성(self-supervised)하여, 언제 어떤 도구를 호출할지 자율적으로 학습했다.
| 항목 | 내용 |
|---|---|
| 저자 | Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom |
| 소속 | Meta AI Research |
| 발표 | NeurIPS 2023 |
| 링크 | arxiv.org/abs/2302.04761 |
| 키워드 | Tool Use, Self-Supervised, API Call, Augmented LM |
1. 문제 정의
LLM의 본질적 약점:
1. 산술: 7자리 곱셈을 자주 틀림
2. 최신 정보: 학습 데이터 이후 사실을 모름
3. 다국어 번역: 저자원 언어 쌍에서 품질 저하
이를 외부 도구(계산기, 검색엔진, 번역기 등)로 보완할 수 있지만, 기존 접근은:
- 대량의 도구 사용 데이터를 사람이 라벨링하거나 (비용 문제)
- Few-shot 프롬프팅으로 도구를 호출 (불안정 + 도구 선택 제한)
핵심 질문:
LLM이 스스로 "언제, 어떤 도구를, 어떤 인자로 호출할지"를
자기 지도 학습(self-supervised)으로 배울 수 있는가?2. 제안 방법
지원 도구 (5종)
| 도구 | API 형식 | 용도 |
|---|---|---|
| Calculator | [Calculator(3+5*2)] | 산술 연산 |
| Q&A System | [QA("population of France")] | 사실 질문 |
| Wikipedia | [WikiSearch("Albert Einstein")] | 백과사전 검색 |
| Machine Translation | [MT("Bonjour", en)] | 번역 |
| Calendar | [Calendar()] | 현재 날짜 |
자기 지도 학습 파이프라인 (3단계)
Stage 1: 도구 호출 후보 생성
원본 텍스트: "The population of France is about 67 million."
LLM에게 few-shot 예시 제공 후, 각 위치에 도구 호출 삽입 가능성 탐색:
→ "The population of France is about [QA("population of France")] 67 million."
Stage 2: 도구 호출 실행 + 결과 삽입
API 실행: QA("population of France") → "67.39 million"
→ "The population of France is about [QA("population of France") → 67.39 million] 67 million."
Stage 3: 유용성 필터링
비교:
L₊ = loss("67 million" | 앞 문맥 + API 결과) ← 도구 결과 포함
L₋ = loss("67 million" | 앞 문맥만) ← 도구 결과 미포함
필터링 기준: L₋ - L₊ > τ (임계값)
→ 도구 호출이 다음 토큰 예측을 개선하면 보존 ✓
→ 개선하지 않으면 제거 ✗
핵심: "도구를 호출한 것이 언어 모델링 loss를 줄이는가?"학습
필터링된 데이터로 LLM을 파인튜닝:
입력: "The Eiffel Tower was built in [WikiSearch("Eiffel Tower construction year") → 1889] 1889."
LLM은 학습을 통해:
1. 언제 도구가 필요한지 (어떤 위치에서 [API...] 토큰을 생성할지)
2. 어떤 도구를 쓸지 (Calculator vs QA vs Wiki...)
3. 어떤 인자를 전달할지 ("Eiffel Tower construction year")
를 동시에 학습
추론 시:
LLM이 "[" 토큰 생성 → 도구 호출 감지 → API 실행 → 결과를 컨텍스트에 삽입 → 이어서 생성3. 실험 결과
3.1 기본 모델: GPT-J 6.7B
| 태스크 | GPT-J | GPT-J + few-shot 도구 | Toolformer | OPT 66B |
|---|---|---|---|---|
| 수학 (GSM8K 부분) | 8.3% | 12.1% | 29.4% | 10.2% |
| QA (Web Questions) | 17.8% | 19.5% | 29.3% | 18.6% |
| 다국어 QA (MLQA) | 24.1% | 25.8% | 33.7% | 26.3% |
| 시간 추론 (TempQuestions) | 17.2% | 19.1% | 38.2% | 18.9% |
→ 6.7B Toolformer가 66B OPT를 대부분 태스크에서 초과 — 도구가 모델 크기를 보상
3.2 도구별 기여
| 태스크 | 주로 호출되는 도구 | 도구 없이 | 도구 있을 때 |
|---|---|---|---|
| 산술 | Calculator | 8.3% | 29.4% |
| 최신 정보 | WikiSearch | 17.8% | 29.3% |
| 날짜 추론 | Calendar | 17.2% | 38.2% |
→ 각 태스크에 적절한 도구를 자동으로 선택
3.3 도구 사용 빈도 분석
전체 텍스트 대비 도구 호출 삽입 비율: ~2-5%
→ LLM이 대부분의 경우 도구 없이 생성하고,
필요한 순간에만 선택적으로 호출
잘못된 도구 호출 (불필요하거나 잘못된 인자): ~12%
→ 완벽하지는 않지만, 대부분 올바른 판단3.4 언어 모델링 성능 유지
| 평가 | GPT-J | Toolformer |
|---|---|---|
| Perplexity (WikiText) | 12.0 | 11.8 |
| 일반 NLP (LAMBADA) | 68.3% | 68.1% |
→ 도구 학습이 일반 언어 모델링 성능을 저하시키지 않음
4. 한계점
- 도구 체이닝 불가: 하나의 도구 결과를 다른 도구의 입력으로 사용하는 다단계 호출 미지원 (예: 검색 → 계산)
- 도구 집합 고정: 5개 도구가 사전 정의 — 새 도구 추가 시 재학습 필요
- 인터랙티브 도구 미지원: 한 번 호출하고 결과를 받는 것만 가능, 대화형 도구 사용 불가
- 6.7B 모델 한정: 더 큰 모델에서 효과가 증가하는지 감소하는지 미검증 — GPT-4급 모델은 이미 산술을 잘 하므로 이점이 줄어들 수 있음
- 환각 도구 호출: 간혹 존재하지 않는 API를 호출하거나, 잘못된 인자를 전달하는 경우
- 필터링 임계값(τ) 민감도: 너무 낮으면 불필요한 호출 포함, 너무 높으면 유용한 호출도 제거
5. 의의와 영향
- 자기 지도 도구 학습의 첫 대규모 시연: 사람 라벨 없이 LLM이 스스로 도구 사용법을 학습
- "언제 도구를 쓸지"의 자율 판단: 무조건적 도구 사용이 아닌 선택적 사용 → Self-RAG의 [Retrieve] 토큰과 유사한 철학
- 후속 연구 Gorilla, ToolLLM, API-Bank 등의 직접적 기반
- Augmented LM 패러다임 확립: LLM + 외부 도구 = 더 강력한 시스템
- 2023년 이후 ChatGPT Plugin, Function Calling 등 상용 도구 사용의 학문적 기초
6. 💬 리뷰어 코멘트
Toolformer의 가장 우아한 점은 "도구 호출이 언어 모델링 loss를 줄이는지"라는 단순한 기준으로 학습 데이터를 필터링한 것이다. 이 기준은 추가 라벨 없이도 "이 도구 호출이 유용한가?"를 판단하는 프록시로 작동한다. Self-play나 RLHF 같은 복잡한 학습 없이, 기존 언어 모델링 목적함수 안에서 도구 사용을 자연스럽게 학습시킨 것이 핵심 기여다.
현재 관점에서 보면 Toolformer의 접근은 Function Calling에 의해 실용적으로 대체되었다. GPT-4, Claude 등은 시스템 프롬프트에 도구 정의를 넣으면 별도 파인튜닝 없이 도구를 호출한다. 하지만 Toolformer의 "LLM이 스스로 도구 사용을 학습할 수 있다"는 증명은 학문적으로 여전히 중요하다.
가장 아쉬운 점은 도구 체이닝의 부재다. "파리의 인구를 검색하고, 서울의 인구와 비교하여 비율을 계산"하는 것은 Toolformer로 불가능하다. 이 한계가 Gorilla, ToolLLM 같은 후속 연구의 동기가 되었다.
관련 논문: Gorilla, ToolLLM, API-Bank, ART, HuggingGPT
