[PAPER] Toolformer: Language Models Can Teach Themselves to Use Tools
Toolformer: 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 · NeurIPS 2023
| Title | Toolformer: Language Models Can Teach Themselves to Use Tools |
| Authors | Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom Meta AI (전원) |
| Venue | NeurIPS 2023 · arXiv 제출: 2023년 2월 9일 |
| 모델 | GPT-J (6.7B) → Toolformer (파인튜닝) · GPT-3 (175B) 성능 초과 달성 |
| Tools | Calculator · Wikipedia Search · Calendar · Translation API · QA System — 5종 도구 |
| 인용 수 | 2,000+ (2024년 기준) — Tool Use 자기지도 학습의 핵심 참조 논문 |
| Source | arXiv:2302.04761 ↗ · Meta AI GitHub ↗ |
ReAct가 "어떻게 추론하며 행동하는가"를 다뤘다면, Toolformer는 그 이전 단계를 묻습니다 — "어떻게 도구를 쓸 줄 아는 AI를 만드는가?" 놀라운 점은 Toolformer가 스스로 자신의 학습 데이터를 생성한다는 것입니다. 6.7B 파라미터 모델이 175B GPT-3을 이기는 비결이 여기 있습니다.
- 이 논문이 해결하는 문제
- 기존 접근 방식의 한계 — 수작업 annotation의 한계
- Toolformer 핵심 아이디어 — 자기지도 도구 학습
- 5가지 도구와 학습 데이터 생성 방식
- 실험 결과 — 6.7B vs 175B
- 논문 평가 — 강점과 한계
- 해양 산업 시사점
- Captain Paul의 결론 — ReAct와의 비교
📌 (1) 이 논문이 해결하는 문제
LLM은 "계산기가 없는 수학자"입니다. 덧셈, 나눗셈, 현재 날짜, 실시간 검색 — 이런 단순한 작업에서도 LLM은 실수를 합니다. 해법은 명확합니다: 외부 도구(APIs)를 사용하게 하면 됩니다. 그런데 어떻게?
사람이 직접 수천 건의 "언제 어떤 도구를 써야 하는지" 예시를 작성(annotation). 비용이 막대하고 새 도구마다 반복 필요.
LLM 스스로 학습 데이터를 생성. "도구를 호출하는 게 예측 정확도를 높이면 유지, 아니면 버림." 사람의 개입 최소화.
🔍 (2) 기존 접근 방식의 한계
주석
GPT-4의 Function Calling이나 초기 CoT 연구들은 모두 "좋은 예시"를 사람이 직접 설계했습니다. 도구가 5개에서 50개로 늘어나면? 각 도구 조합마다? 비용은 선형이 아니라 지수적으로 증가합니다. 새 도구 추가 = 새 어노테이션 작업 = 높은 비용.
도구
이전 연구들은 "계산기를 쓰는 모델", "검색을 쓰는 모델"처럼 도구별로 따로 학습했습니다. 하나의 모델이 맥락에 따라 적절한 도구를 자율 선택하는 능력은 부재했습니다. 단일 통합 도구 사용 = 미해결 문제.
퍼플렉시티(Perplexity) 필터링을 사용합니다. "도구를 호출한 버전"이 "도구를 호출하지 않은 버전"보다 이후 텍스트를 더 잘 예측하면(= 낮은 perplexity) → 해당 도구 호출을 학습 데이터로 유지. 그렇지 않으면 삭제. LLM 자신이 심판이 됩니다.
⚙️ (3) Toolformer 핵심 아이디어 — 자기지도 도구 학습
Toolformer의 학습 파이프라인은 4단계로 구성됩니다. 중요한 것은 이 전 과정에서 사람의 어노테이션이 필요 없다는 점입니다. 초기 few-shot 예시(~5개)만으로 파이프라인이 작동합니다.
기존 LLM에 few-shot 예시를 제공해 텍스트 코퍼스의 각 위치에서 "도구 호출이 유용할 것 같은 자리"에 API 호출을 삽입하도록 요청합니다. 예: "오늘 날짜는 [Calendar()|June 13] 입니다."
샘플링된 모든 API 호출을 실제로 실행합니다. 계산기는 수식을 계산하고, 검색 API는 Wikipedia 스니펫을 반환합니다. 결과가 텍스트에 삽입됩니다.
각 API 호출에 대해 세 가지 버전의 perplexity를 비교합니다: ① 원본(도구 없음), ② 도구 호출+결과 포함, ③ 빈 결과. 버전 ②가 ①, ③보다 낮은 perplexity = 이후 텍스트를 더 잘 예측 → 학습 데이터로 채택. 그렇지 않으면 삭제.
필터링을 통과한 고품질 API-포함 텍스트로 LLM(GPT-J 6.7B)을 파인튜닝합니다. 결과물이 Toolformer입니다. 이제 모델은 자연스럽게 텍스트 생성 중 도구가 필요한 순간에 API 호출을 생성합니다.
입력: "Alan Turing was born in 1912. He would now be" Toolformer: "Alan Turing was born in 1912. He would now be [Calculator(2024-1912)|112] years old." 입력: "The Eiffel Tower is located in" Toolformer: "The Eiffel Tower is located in [Wikipedia(Eiffel Tower location)|Paris, France, on the Champ de Mars] Paris."
🛠 (4) 5가지 도구와 학습 데이터 생성
Toolformer는 5가지 다른 성격의 도구를 통해 범용성을 증명합니다. 중요한 것은 각 도구마다 약 5개의 few-shot 예시만으로 수십만 건의 학습 데이터를 자동 생성한다는 점입니다.
수식 계산 API. LLM이 틀리기 쉬운 사칙연산·백분율·날짜 계산. 예: [Calculator(2+3*4)|14]
BM25 기반 Wikipedia 검색. 사실 기반 질문 응답에서 환각 억제. 가장 광범위하게 사용.
현재 날짜 조회 API. LLM은 학습 데이터 이후의 날짜를 알 수 없음 — 이 도구로 해결.
기계번역 API. 다국어 텍스트에서 특정 언어로 번역이 필요할 때 자동 호출.
Atlas QA 시스템. 사실적 QA에서 전문 검색 모델을 하위 도구로 활용.
[ToolName(input)|output] 형태로 텍스트에 자연스럽게 삽입됩니다. 추론 시에는 모델이 [을 생성하면 중단하고 실제 API를 호출한 후 결과를 삽입하여 계속 생성합니다.
📊 (5) 실험 결과 — 6.7B vs 175B
Toolformer의 핵심 주장: 6.7B Toolformer가 도구 사용이 필요한 태스크에서 175B GPT-3을 능가합니다. 파라미터 수 기준 26배 작은 모델입니다.
✅ (6) 논문 평가 — 강점과 한계
사람의 어노테이션 없이 수십만 건 학습 데이터 자동 생성. 새 도구 추가도 few-shot 예시 몇 개로 확장 가능. 현실적 확장성.
6.7B Toolformer가 175B GPT-3을 다수 태스크에서 능가. "크기 = 성능"이라는 통념에 도전. 비용 효율적 AI 개발의 가능성 제시.
도구 호출이 텍스트 생성 흐름 안에 자연스럽게 통합. 별도 오케스트레이션 레이어 없이 LLM 자체가 도구 사용 타이밍을 판단.
하나의 텍스트 위치에서 한 번에 하나의 도구만 호출 가능. 도구 체이닝(A 결과를 B에 입력) 미지원. ReAct처럼 반복 루프가 없음.
도구 실행 결과가 예상과 다를 때 재시도나 전략 수정이 불가. Observation → 새 Thought로 이어지는 ReAct의 반응적 루프가 없음.
학습 시 정의된 도구만 사용 가능. 새 도구를 런타임에 자동 발견하거나 적응하는 능력은 없음. MCP 같은 표준 프로토콜의 필요성을 역설적으로 보여줌.
⚓ (7) 해양 산업 시사점
Toolformer의 자기지도 도구 학습 원리는 해양 AI 시스템 설계에 중요한 시사점을 줍니다. 특히 "어떤 데이터베이스·시스템을 언제 조회해야 하는지"를 AI가 스스로 학습하게 할 수 있다는 가능성이 핵심입니다.
ECDIS 데이터 조회, AIS 이상 탐지 API, CVE 취약점 DB 검색, IMO 규정 문서 조회 — 이 모든 시스템을 하나의 AI가 "언제 어떤 시스템을 조회해야 하는지" 학습하게 하는 것이 Toolformer의 원리입니다. 해양 특화 약 5개 예시만으로 자동 학습 데이터를 생성하고 파인튜닝하면 해양 도구 전문 AI가 됩니다.
"IACS UR E26 Rev.3 기준 리스크 점수" 계산, 항해 가능 시간 계산, 연료 소비율 계산 — 정확한 수치가 필요한 해양 업무에서 Toolformer의 Calculator 도구 통합 원리가 직접 적용됩니다. 숫자가 틀린 AI의 안전 보고서는 무용합니다.
국제 선박 운항에서는 러시아어 항만 규정, 중국어 검사 보고서, 아라비아어 계약서를 동시에 처리해야 합니다. Toolformer의 번역 도구 자동 호출 원리를 해양 문서 AI에 적용하면 다국어 장벽이 낮아집니다.
🎯 (8) Captain Paul의 결론 — ReAct와의 비교
ReAct와 Toolformer는 경쟁 관계가 아니라 상호 보완 관계입니다. Toolformer가 "어떻게 도구를 쓸 줄 아는 LLM을 만드는가"를 해결했다면, ReAct는 "그 도구를 사용하며 어떻게 다단계 추론을 수행하는가"를 해결했습니다. 오늘날 GPT-4의 Function Calling, Anthropic의 Tool Use, MCP 생태계는 Toolformer의 아이디어(도구 통합)와 ReAct의 패턴(추론-행동 루프)을 동시에 계승합니다.
Toolformer는 "AI가 스스로 배운다"는 개념을 도구 사용에 적용한 최초의 실증 논문입니다. 이 논문 이후 AI 개발의 방향은 "얼마나 큰 모델"에서 "얼마나 좋은 도구를 얼마나 잘 통합하는가"로 전환되었습니다.
— Captain Paul -
Comments
Post a Comment