LM이 도구를 사용하게 된다면? 🔬: Large Language Models as Tool Makers 논문 리뷰

The overview of this paper

 최근의 연구는 LLM의 문제 해결 능력 향상의 잠재성을 보여줬다. 하지만, 이전 연구들은 기존 툴의 가용성에 상당히 의존한다. 이 논문에서는 이러한 의존성을 제거하기 위해 closed-loop 프레임워크인 LLM As Tool Makers(LATM)을 제안하였다. LATM에서 LLM은 문제 해결을 위한 자신만의 재사용 가능한 툴을 생성한다. LATM은 2개의 메인 페이즈로 구성되어 있다: tool making & tool using.

 

 tool making은 LLM이 서로 다른 요청에 적용될 수 있는 tool을 계속적으로 생성할 수 있게 해 줘서 향후 요청은 task를 해결할 때 우익하다고 생각될 때 해당 APT를 불러올 수 있게 해 준다. 이렇게 해서 이 2 페이즈는 생성된 툴과 문제 솔루션의 퀄리티 저하 없이 비용 효율성을 달성할 수 있는 기회를 준다. 논문에서는 GPT-4를 tool maker로, GPT-3.5를 tool user로 사용하였다.

 

 

Table of Contents

1. Introduction

2. LLM as Tool Maker(LATM)

3. Experiments

 

 

1. Introduction

 인간의 진화 역사를 살펴보면 사람들은 발생하는 문제들을 해결하기 위해 이들만의 툴을 만들어서 해결하는 방식으로 진화하였다. 인간의 역사에서 본 tool-making의 중요성에 영감을 받아서 이러한 진화적 개념을 LLM의 영역에 적용하고자 하였다. 이를 위해 논문에서는 closed-loop 프레임워크인 LATM을 제안하였다. 이 method는 LLM이 새로운 task에 도전하기 위해 이들만의 재사용 가능한 tool을 만들 수 있게 해준다. 이 LATM은 다음의 2개의 중요 스테이지로 구성되어 있다:

 

1. Tool Making: tool maker로 알려진 LLM으로 주어진 task에 대한 tool을 디자인함 → 강력한 모델을 필요로 함
2. Tool Using: tool user로 알려진 다른 LLM을 새로운 요청을 처리하기 위해 tool을 적용함 → lightweight 모델을 필요로 함

 

 이러한 2 스테이지는 LATM이 각 스테이지에서 job을 가장 적합한 LLM에게 할당하도록 허락해준다. 이러한 방식은 LLM의 문제 해결 능력을 향상시킬 뿐만 아니라, 문제 해결에 필요한 계산 비용도 상당히 감소시킨다.

 

그림 1. LATM의 closed-loop 프레임워크

 

2. LLM as Tool Maker(LATM)

2-1. Making New Tools and Reuse Them

 

 LATM 패러다임에서 메인 프로세스는 2개의 스테이지로 분할될 수 있다: tool making & tool using. 각 스테이지는 성능과 비용 효율의 밸런스를 맞추기 위해 LLM의 서로 다른 유형을 활용한다.

 

그림 2. LATM의 파이프라인

 

Tool Making.  이 스테이지에서는 강력하지만 비용이 비싼 모델인 GPT-4 같은 모델을 tool maker로 활용한다. 여기서 tool maker의 역할은 task의 적은 설명으로부터 일반적이고 재사용 가능한 tool을 생성하는 것이다. 이 스테이지는 3개의 sub-stage로 나눠질 수 있다:

 

• Tool Proposing: 이 스테이지에서 tool maker는 주어진 task의 설명을 해결하기 위해 Python 함수 생성을 시도한다. 이 프로세스는 여러 설명이 제공되고, 모델을 설명한 특성을 생성하는 프로그램을 작성하도록 요구되는 PbE 패러다임을 따른다. 논문의 실험에서는 이 스테이지에서 3개의 설명이 사용되었다. 만약 제안된 툴이 실행 불가능하거나 에러를 마주치면 tool maker는 히스토리에 에러 메시지를 추가하고 다른 시도도 한다.
• Tool Verification: 이 스테이지에서 validation 샘플을 사용해서 unit test를 생성하고, 제안된 tool에서 테스트를 실행한다. 논문에서는 3개의 validation 샘플을 활용해서 실험을 진행하고, tool이 실패를 하면, tool maker는 히스토리에 에러를 기록하고, unit test에서 문제점을 해결하기 위해 시도한다. 하지만 LATM 파이프라인의 verification stage는 살짝 다르게 사용돼서 다음의 2가지 중요 역할을 만족한다.
  1. 자연어 question을 어떻게 함수 호출로 변환하는지를 설명하는 예시를 제공해줌
  2. tool의 신뢰도를 입증해서, 전체 프로세스가 완전히 자동화되도록 허락해 줌
• Tool Wrapping: tool maker가 tool user를 위한 wrapping up과 task를 어떻게 함수 호출로 변환하는지에 대한 설명을 제공해 준다. 

 

Tool Using.  논문에서는 tool user로 lightweight & 비용 효과적 모델을 사용한다. tool user의 역할은 task의 다양한 인스턴스를 해결하기 위해 인증된 툴을 사용하는 것이다. 이 스테이지에 대한 prompt는 task를 해결하기 위한 함수와 task 쿼리를 어떻게 함수 호출로 변환하기 위한 설명을 포함하는 wrapped tool이다. 설명을 사용하여 tool user는 요구된 함수 호출을 in-context learning으로 생성할 수 있게 해 준다. task 해결을 위해 함수 호출이 실행된다. 그리고 task의 포맷을 맞추기 위해 후처리가 적용된다.

 

 각 task 유형에 대해 tool-making stage는 오직 한 번만 수행되어야 한다. 결과로 나온 tool은 task의 모든 instance에 대해 재사용될 수 있다. 이것은 LATM이 강력한 모델 혼자만 사용하는 것보다 상당히 효율적이고 비용 효과적이게 만든다.

 

 그림 3은 어떻게 tool maker가 tool을 생성함으로써 Big-Bench의 논리적 추론 task를 해결하는지의 예시를 제공해 주고, tool maker가 어떻게 tool을 사용하는지의 예시를 제공해준다. task를 해결하기 위해, tool maker는 question으로부터 제안을 추출함으로써 task를 해결하는 일반적 프로그램을 생성한 다음, 결과에 대한 토큰 순열을 검색한다. tool user는 이 프로그램을 task를 해결하기 위해 사용할 수 있고, task의 자연어 instance로부터 관련 정보를 추출하는 함수 호출을 사용한다.

 

그림 3. Logical Deduction task에 대한 LATM 파이프라인의 Tool Proposing과 Tool Using의 묘사

 

2-2. Handling Streaming Data with Dispatcher

 

 real-world 시나리오에서 task instance는 전형적으로 시퀀스로 도래한다. 이러한 데이터의 흐름을 수용하기 위해 각 incoming task에 대해 tool user와 tool maker를 참여시킬지 말지를 결정하는 3번째 LLM인 dispatcher를 설명한다. 논문의 dispatcher는 기존 툴로 해결될 수 없는 새로운 task를 식별하기 위한 능력으로 뚜렷해지고, 이러한 task에 대한 새로운 tool을 생성하기 위해 tool maker를 참여시킨다.

 

 구체적으로 dispatcher는 tool maker에 의해 생성된 기존 tool의 기록을 유지한다. 새로운 task instance가 들어오면 dispatcher는 task에 대한 적합한 tool이 있는지를 초기에 결정한다. 만약 적절한 tool이 있으면 instance와 해당 툴을 tool user에게 전달한다. 그렇지 않고 만약 적절한 툴이 없으면 tool maker에게 instance를 전달해서 새로운 tool을 만들게 한다. dispatcher의 workflow가 그림 4에 나타나있다. dispatching task의 간단함이 주어지면 dispatcher는 적절한 prompt를 사용하는 lightweight 모델이 될 수도 있다. 

 

그림 4. dispatcher의 예시

 

3. Experiments

3-1. Experimental Setup

 

Datasets.  논문에서는 LATM을 Big-Bench의 5개의 task(Logical Deduction, Tracking Shuffled Objects, Dyck Language, Word Sorting, Chinese Remainder Theorem)에서 평가하였다. 그리고 LATM의 real-world 시나리오 에서의 효과를 설명하기 위해 Scheduling Meeting task를 만들어서 평가하였다.

 

표 1. task를 해결하기 위해 tool maker에 의해 생성된 utility function

 

3-2. Effectiveness of the Tool-Making Stage

 

 tool-making 스테이지에서는 구체적 task 해결을 위한 일반적인 Python 함수를 생성하기 위해 강력하지만 느린 모델을 사용하였다. 이 스텝은 오직 한 번만 수행된다. 논문의 실험에서 GPT-4를 tool maker로 사용하였다. 그리고 LM에게 여러 few-shot 예시를 제공해주고 그림 3처럼 일반적인 Python 프로그램을 생성할 수 있도록 제안하였다.

 

 논문에서는 GPT-4가 tool maker로 사용될 때, 모델은 task를 해결하기 위한 적절한 알고리즘을 자주 고안한다는 것을 발견하였다. 논문의 실험에서 tool-verification 스테이지는 주로 자연어 question을 어떻게 함수 호출로 변환할 수 있는지를 설명하는 예시를 제공하는 데 사용되었다. 그리고 논문에서는 tool maker가 오류 메시지 안내로 실수를 수정할 수 있는 60가지 시도 중 2가지 경우만 관찰하였다. 

 

3-3. LATM Improves the Performance of Lightweight LLMs

 

 표 2에서는 CoT의 성능을 LATM와 비교하였다. GPT-4를 6개의 task에 대한 tool을 생성하기 위한 tool maker로 사용하고 GPT-3.5 Turbo & GPT-4를 tool user로 사용해서 성능을 평가하였다. 결과는 tool의 도움으로 GPT-3.5 Turbo 같은 lightweight 모델은 CoT prompting의 성능을 상당히 능가하고, GPT-4와 동등한 성능을 달성한다는 것을 보여줬다. 반면에 GPT-4에 비해 비용은 상당히 감소하였다. 흥미로웠던 점은 Dyck Language task에서는 GPT-3.5 Turbo가 GPT-4를 능가하는 모습을 보여줬다는 점이다! 실패 사례를 조사한 결과, question을 함수 호출로 변환할 때 GPT-4가 때때로 문제의 일부를 불필요하게 해결하여 잘못된 함수 출력으로 이어지는 것을 발견하였다.

 

표 2. LATM과 CoT 간의 성능 비교

 

3-4. Extending LATM to a Streaming Setting with a Mixture of Tasks

 

 LATM을 streaming 세팅으로 확장 가능한데, 이 경우에는 dispatcher를 따로 필요로 한다. 논문에서는 GPT-3.5 Turbo를 dispatcher로 사용하고 이것의 능력을 다음과 같이 평가하였다:

 

1. 기존 tool incoming instance를 해결 가능한지 판별
2. unseen task의 instance에 대해 tool-making을 필요로 함

 

Identifying existing tools.  논문에서는 주어진 instance에 대해 tool-making을 필요로 하는 dispatcher의 능력을 평가하였다. test set의 각 instance에 대해 dispatcher를 사용해서 기존 tool과 연관된 task 예시를 포함하는 prompt와 함께 적절한 기존 툴을 인식하였다. 알맞은 툴을 결정하는 정확도를 평가한 결과 $94% \pm 2%$의 정확도를 보여줬다.

 

Requesting tool-making.  그다음에 unseen task의 instance를 위한 tool-making을 요청하기 위한 dispatcher의 능력을 평가하였다. test set의 각 instance에 대해 dispatcher을 사용해서 tool-making을 요청해야 할 필요가 있는지 또는 instance가 기존 툴에 의해 해결될 수 있는지 결정한다. 알맞은 요청을 만들어내는 정확도는 $95% \pm 4%$였다.

 

 결과는 dispatcher가 unseen task에 대해 효과적으로 기존 툴을 판별하고 tool-making을 요청한다는 것을 보여줬다. 이것은 LATM이 task의 묶음과 함께 streaming 세팅으로 부드럽게 연장될 수 있다는 것을 제안한다.

 

표 3. GPT-4 vs GPT-3.5 Turbo를 사용한 tool-making 에서 새로운 tool 생성의 성공률

 

 

 

 

출처

https://arxiv.org/abs/2305.17126

Large Language Models as Tool Makers