Toolformer: 도구 사용을 스스로 학습하는 모델
Toolformer가 소수의 API 예시만으로 도구 호출 데이터를 스스로 만들고, 예측에 도움이 된 호출만 골라 학습하는 방법을 정리합니다.
Contents
사람이 도구 사용 규칙을 일일이 짜는 대신, 모델이 도움이 된 호출만 스스로 골라 학습합니다.
언어 모델이 도구를 못 쓰던 문제
대규모 언어 모델(Large Language Model, LLM)은 다음 토큰을 예측하는 방식으로 글을 만듭니다. 이 구조는 문장 생성에는 강하지만 정확한 계산이나 최신 사실 조회에는 약합니다. 곱셈 한 번, 오늘 날짜 한 번이 틀려도 그럴듯한 문장은 그대로 나옵니다.
해결책으로 계산기나 검색 같은 외부 도구를 붙이는 방법이 있습니다. 문제는 도구를 언제 부를지, 어떤 인자를 넘길지를 사람이 규칙으로 정해 줘야 한다는 점입니다. 도구가 늘수록 규칙도 늘고, 손으로 짠 규칙은 새로운 문맥에서 쉽게 깨집니다.
Toolformer가 바꾼 관점
Toolformer는 2023년 2월 공개된 논문 'Language Models Can Teach Themselves to Use Tools'에서 제안됐습니다. 출처는 arXiv:2302.04761입니다. 모델이 외부 도구를 언제 호출할지, 어떤 인자를 넘길지, 결과를 다음 예측에 어떻게 반영할지를 스스로 학습하게 만듭니다.
핵심은 학습 데이터를 사람이 직접 라벨링하지 않는다는 점입니다. 소수의 애플리케이션 프로그래밍 인터페이스(API) 사용 예시만 주면, 모델이 자기지도(self-supervised) 방식으로 도구 호출 데이터를 스스로 만들어 냅니다. 자기지도란 정답 라벨 없이 데이터 안의 신호만으로 학습 목표를 세우는 방식을 말합니다.
도구를 프롬프트에 끼워 두는 방법과는 출발점이 다릅니다. Toolformer는 도구 사용 능력을 모델 가중치 안에 학습시킵니다. 도구 사용을 추론 시점의 임시 기법이 아니라 모델 능력의 일부로 다루는 셈입니다.
도구 호출 데이터를 스스로 만드는 과정
Toolformer의 데이터 생성은 다섯 단계로 이뤄집니다. 사람은 시범 예시만 주고, 어떤 호출을 남길지는 모델과 손실 값이 정합니다.
위 그림은 시범 예시에서 시작해 추가 학습까지 이어지는 데이터 생성 흐름을 보여줍니다. 단계별 내용은 다음과 같습니다.
- 소수의 API 사용 예시를 모델에 줍니다.
- 모델이 문맥 중간에 들어갈 후보 호출을 위치마다 여러 개 만듭니다.
- 각 후보 호출을 실제로 실행해 결과를 받습니다.
- 그 결과가 다음 토큰 예측 손실을 줄이는 호출만 남깁니다.
- 선별된 호출을 본문에 끼워 넣어 모델을 추가 학습합니다.
후보를 만드는 방식은 두 축으로 나뉩니다. 모델은 먼저 도구 호출이 들어가기 좋은 위치를 텍스트 안에서 여러 곳 고릅니다. 그다음 각 위치마다 인자가 다른 호출을 여러 개 만들어 실행 후보로 둡니다. 위치와 인자를 모두 모델이 제안하므로, 사람이 호출 규칙을 직접 설계할 필요가 없습니다.
이 과정의 산출물은 도구 사용 자체를 학습한 모델입니다. 호출 위치, 인자, 결과 반영 방식이 모두 학습 데이터 안에 녹아 들어가기 때문입니다.
호출은 본문 안에 표기 형태로 들어갑니다. 원 논문은 대괄호 안에 호출과 결과를 함께 적는 표기를 씁니다.
원문: 3 곱하기 14 = 42 입니다.
삽입: 3 곱하기 14 = [Calculator(3 * 14) -> 42] 42 입니다.대괄호 안이 도구 호출과 그 결과입니다. 학습이 끝나면 모델은 비슷한 위치에서 이런 호출을 스스로 만들어 냅니다. 표기 예시의 계산값 42는 3 곱하기 14의 결과로, 누구나 확인할 수 있는 값입니다.
유용성 필터
4단계가 Toolformer의 중심입니다. 후보 호출을 많이 만들어도 대부분은 쓸모가 없으므로, 도움이 된 호출만 걸러 내야 학습 데이터가 깨끗해집니다.
필터는 같은 위치에서 두 가지 손실을 비교합니다. 하나는 도구 결과를 넣었을 때의 다음 토큰 예측 손실이고, 다른 하나는 결과를 넣지 않았을 때의 손실입니다. 도구 결과가 손실을 임계값 이상으로 줄이면 그 호출을 유용하다고 보고 남깁니다.
이 기준 덕분에 모델은 도움이 되지 않는 호출을 스스로 버립니다. 계산이 필요 없는 문장에 계산기를 부르면 손실이 줄지 않으므로 걸러집니다. 결과적으로 남는 데이터는 도구가 실제로 예측을 도운 사례만 모인 형태가 됩니다.
이 선별에는 비용이 따릅니다. 위치마다 후보를 만들고 모두 실행해 손실을 재야 하기 때문입니다. 도구가 늘면 실행 횟수도 늘어, 데이터 생성 비용이 빠르게 커집니다.
논문이 사용한 도구는 좁은 범위로 묶입니다. 계산기, 질의응답 시스템, 검색 엔진, 번역기, 캘린더가 대상이었습니다. 모두 입력과 출력이 분명해 결과의 유용성을 손실로 재기 쉬운 도구입니다.
ReAct와의 차이
도구 사용을 다루는 또 다른 대표 패턴으로 ReAct가 있습니다. ReAct는 추론(Reasoning)과 행동(Acting)을 번갈아 적는 프롬프트 패턴으로, 추론 시점에 도구를 부르는 방식입니다. 두 방식은 도구를 다루는 시점부터 다릅니다.
| 항목 | Toolformer | ReAct |
|---|---|---|
| 초점 | 도구 사용 능력 자체를 학습 | 추론과 행동을 프롬프트 수준에서 결합 |
| 시점 | 주로 학습 단계 | 주로 추론 단계 |
| 장점 | 모델 내부에 도구 사용 성향을 심을 수 있음 | 구현이 단순하고 범용성이 높음 |
| 한계 | 학습 비용과 데이터 생성 비용이 큼 | 프롬프트 품질과 루프 설계에 민감 |
실무에서는 ReAct 계열이 훨씬 널리 쓰입니다. 모델을 다시 학습하지 않고 프롬프트만으로 도구를 붙일 수 있기 때문입니다. 그래도 Toolformer는 도구 사용을 학습 가능한 문제로 바꿨다는 점에서 의미가 큽니다.
환경 스킬 학습과의 경계
Toolformer가 다루는 범위는 API 호출에 한정됩니다. 환경 안에서 행동을 배우는 문제는 다른 접근이 필요합니다. 그 경계는 Self-Driven Grounding과 비교하면 분명해집니다. Self-Driven Grounding은 소목표 가설을 세우고 환경으로 검증해 재사용 가능한 스킬을 학습하는 방식입니다.
| 항목 | Toolformer | Self-Driven Grounding |
|---|---|---|
| 문제 | API/도구 사용 학습 | 환경 속 스킬 학습 |
| 핵심 메커니즘 | 자기지도 도구 호출 데이터 생성 | 소목표 가설과 환경 검증 |
| 결과물 | 도구 사용 능력 | 재사용 가능한 스킬 |
| 적용 맥락 | API 호출 중심 | 환경 상호작용/행동 학습 중심 |
두 방식은 학습 신호를 얻는 곳이 다릅니다. Toolformer는 다음 토큰 예측 손실에서 신호를 얻고, Self-Driven Grounding은 환경과의 상호작용 결과에서 신호를 얻습니다. 도구를 부르는 문제와 환경에서 행동하는 문제를 같은 틀로 풀기 어렵다는 점이 여기서 드러납니다.
한계와 남긴 영향
Toolformer는 연구 프레임워크 성격이 강해, 그대로 프로덕션에 쓰기에는 제약이 있습니다. 주요 한계는 다음과 같습니다.
- API 형식과 도구 종류가 비교적 고정적입니다.
- 후보 호출 생성과 선별에 드는 비용이 큽니다.
- 오늘날의 범용 도구 호출 API 생태계와 비교하면 유연성이 떨어집니다.
- 프로덕션 오케스트레이션보다는 연구 프레임워크에 가깝습니다.
한계가 분명한데도 이후 연구에 남긴 흔적은 뚜렷합니다. 도구 사용을 모델 능력의 일부로 본 관점은 이후 function calling과 tool-augmented agent 연구에서 다시 나타났습니다. 모델이 도구를 스스로 고른다는 생각은 오늘날 에이전트 설계의 바탕에 깔려 있습니다.
정리
Toolformer는 도구 사용 규칙을 사람이 짜는 대신, 모델이 도움이 된 호출만 골라 학습하도록 만든 프레임워크입니다. 후보 호출을 만들고 실행한 뒤, 다음 토큰 예측 손실을 줄이는 호출만 남기는 유용성 필터가 그 중심에 있습니다. 도구 종류가 고정적이고 데이터 생성 비용이 크다는 한계는 분명하지만, 도구 사용을 학습 가능한 문제로 바꾼 점이 이후 에이전트 연구로 이어졌습니다. 지금 널리 쓰이는 방식은 ReAct 계열이지만, 그 발상의 뿌리를 이해하려면 Toolformer를 먼저 보는 편이 좋습니다.