Facilitating Multi-Turn Function Calling for LLMs via Compositional Instruction Tuning

Meta info.

• Authors: Mingyang Chen, sunhaoze, Tianpeng Li, Fan Yang, Hao Liang, KeerLu, Bin CUI, Wentao Zhang, Zenan Zhou, weipeng chen
• Paper: https://openreview.net/forum?id=owP2mymrTD
• Affiliation: Baichuan Inc., Peking Univ
• Published: January 23, 2024
• Code: https://github.com/PKU-Baichuan-MLSystemLab/BUTTON

TL; DR

Task - Function으로 연결하는 Planning 기반의 multi-turn* Function Calling 프레임워크 BUTTON 제안

Background

• LLM의 API (external tool) call이 기본 지원
• 최신 연구에서는 what (어떤 함수를 호출해야 하는가 + 그 함수 augments는?)에 집중
• 현실에서는 user request 한 번에 다회(multi-turn) call 발생
  • e.g. 런던에서 에든버러로 가는 오늘의 첫 번째 비행편을 예약하고, 도착했을 때 날씨도 알고 싶어: search_flights > get_weather > book_ticket
• multi-turn: 한 번에 user 요청을 해결하기 위해 모델이 여러개의 function call 단계를 sequential하게 혹은 parallel하게 계획 및 실행. (user-agent가 아님)
  • 본 논문에서는 user에게는 보여지지 않는 tool과 assistant 사이 주고받는 것으로 turn으로 정의

Problem States

multi-turn function calling 데이터 구축

• 그런 데이터도 없고
• 그런 데이터 구축하기도 어려움: 데이터 설계 3가지 어려움
  • compositionality : 단순 slot filling이상으로 sub-task로 분리
  • compatibility : 구축한 Instruction이 실제 function 정의와 맞아야
  • trajectory 품질 : multi-turn function call이 자연스럽게 연결
• 단순 접근으로는 한계
  • (LLM한테) 그냥 함수 모아놓고 합쳐봐라 = 실제로 못푸는 문제 생성
  • (LLM한테) trajectory를 알아서 만들어라 = 앞뒤가 안맞고 실패율도 높음

Suggestions

BUTTON Fig 1

• Button Up: task > function
  • atomic task 구성: 현실 시나리오 수집 > 1회 호출로 풀 수 있을만한 간단하고 명료하고 self-contained하고 함수를 고려하지 않는 task 생성
  • compositional task 구성: 앞선 결과를 뒤에서 받아야하거나(sequential), 독립적인 두 task 를 가각 풀고 그 결과를 합쳐서 다음으로 넘기도록(parallel-then-sequential) 구성
    • atomic task로 실제 완결이 가능한 경우만 남김
  • function 구성: Descriptive(이름/설명/입출력 명료), General(특정 도시에 고정 X), Consistency(연쇄 호출 시 출력>다음 입력이 물리도록)
    • 스키마: {name, description, parameters, responses, required}
    • 사용 가능 함수 목록은 최종적으로 system prompt로 입력
• Top Down:
  • multi-agent 구성:
    • user: 질문
    • assistant: 분해 > 계획 > 호출
    • tool: 함수 시뮬레이터로 동작해서 정의 보고 그럴듯한 결과 뱉도록
  • trajectory 수집:
    • assistant는 생각(react 스타일)+ function call을 출력하는데, tool 결과를 받아서 다음 call을 이어나감
    • 최종 답인 것 같으면 최종 응답용 함수 호출하도록 설계
• 실제 수집
  • GPT-4o로 돌려서 최종적으로 8,000개의 BUTTONInstruct 수집
  • 병렬호출 만든 방법: 여러 함수가 서로 독립이면 병렬 호출이 가능하다고 가정, 프롬프트로 제어.
    • 병럴 허용: 가능하면 서로 독립 함수는 병렬 호출이 된다
    • 병렬 금지: 한번에 하나의 함수만 호출하고 응답을 기다린 후 다음 함수 호출
    • 병렬 가능 task(혹은 그 반대여도) 50%확률로 금지 프롬프트를 섞었다고 (맥락보고 알아서 쓰도록 유도하기 위한 구성)

Effects

• Experiment setup:
  • training: SFT로 open source LLM 학습
    • input: instruction + function def. + context
    • output: 함수 호출 + 응답
    • 데이터: BUTTONInstruct 8k + OpenHermes 100k (일반 추론능력 유지 목적)
  • benchmark: Tool-Query, GTA(Generated Tool-using Agent)
  • metrics:
    • GA(grounding Accuracy): argument 잘 채우는지
    • Process Rate: 계획된 호출을 끝까지 잘 수행했는지 (도중 탈락 없이)
    • Success Rate: 최종 성공률
• Main Results:
  • vanilla LLM은 hard (Tool Query) 성공률 5~10% 수준
  • BUTTON 튜닝하면 30~60%까지 상승
    • 큰모델은 더 잘 개선
    • GPT-4o 에도 근접
  • 데이터 구축에서 buttom up만 하거나 top down만 한 경우 성능 급락 → 둘 다 고려하는게 필요했다고 역설 Fig 3

Personal note. 전달하는 메세지는 function calling에도 planning이 필요하다 이긴 한데, 실제 저자들이 연구한 내용을 납작하게 해석하면 instruction-tuning용 synthetic data를 만들었다 정도로 요약할 수 있고, 논문에서 제안도 SFT해라 수준에 머무릅니다. 그럼에도 불구하고 ICLR에 accept(5,8,8,5)된 특별한 점이 있는지 살피고 싶어서 확인는데 글이 꽤 명료하다는 인상은 확실하지만 그 밖에 내용은 아직도 잘 모르겠습니다 🤔 개인적으로는 첫번째 리뷰어가 지적했던 task의 논리적 합성 품질에 대한 의문, 실제 함수 호출은 아닌 점 (이 역시 합성 수준이었던 점) 데이터 품질에 대한 문의에 공감이 더 갑니다. 저자는 반박 하긴 했는데 사전에 생성전략부터 잘만들도록 구성했기 때문에 사후에 별도 복잡한 필터링 등 검증이 필요없다는 주장이 먹혀서 점수가 오른 것도 신기하네요. (물론 그 반박만 있던 점은 아니지만, 이 리뷰어는 최종 5점으로 마무리했습니다.)