도구 사용 판단(Tool Judgment): AI는 언제 도구를 사용하지 말아야 하는지 아는가?

_This is a submission for the Kaggle Benchmarking Challenge

이것은 Kaggle Benchmarking Challenge에 제출하는 내용입니다.
도구 사용 판단(TOOL JUDGMENT): AI는 언제 도구를 사용하지 말아야 하는지 아는가?
우리는 AI 에이전트에게 도구를 사용할 수 있는지 계속해서 묻습니다. 모델이 검색 API를 호출할 수 있는가? Python을 호출할 수 있는가? 데이터베이스 레코드를 조회할 수 있는가? 올바른 함수를 호출할 수 있는가? 하지만 우리가 충분히 묻지 않는 질문이 하나 있습니다: 모델이 언제 도구를 사용하지 말아야 하는지 아는가?
유능한 에이전트는 도구 호출을 최대화해서는 안 됩니다. 유용한 결과를 최대화해야 합니다.

그래서 저는 도구 사용 제약(tool-use restraint), 도구 선택, 충돌 처리, 그리고 잘못된 도구 결과로부터의 복구를 측정하도록 설계된 벤치마크인 TOOL JUDGMENT를 만들었습니다.

제가 벤치마킹한 내용
저는 모델이 여러 결정론적 도구에 접근할 수 있는 현실적인 에이전트 시나리오 모음을 만들었습니다. 중요한 부분은 올바른 행동이 항상 '도구를 호출하는 것'이 아니라는 점입니다. 일부 작업에는 도구가 필요합니다. 일부 작업은 대화에서 직접 답변될 수 있습니다. 일부는 매력적이지만 관련 없는 도구를 노출시킵니다. 다른 작업들은 모델에게 이미 제공된 정보와 도구에 의해 반환되는 정보 사이에 의도적으로 충돌을 만듭니다. 따라서 모델은 성공하기 전에 결정을 내려야 합니다: 아예 도구를 사용해야 할까?

벤치마크는 네 가지 범주로 구성되어 있습니다:

• Tool Required (도구 필수): 답변을 얻기 위해 모델이 특정 도구를 사용해야 합니다.
• Tool Unnecessary (도구 불필요): 이미 답변이 존재하므로, 도구를 호출하는 것은 시간 낭비입니다.
• Tool Conflict (도구 충돌): 여러 정보 출처가 의견을 달리하며, 모델은 어떤 출처에 권한이 있는지 식별해야 합니다.
• Tool Failure/Recovery (도구 실패/복구): 도구가 오류, 오래된 결과 또는 사용 불가능한 응답을 반환하면, 모델은 적절하게 복구해야 합니다.

저는 의도적으로 이 벤치마크를 잡학 질문 모음으로 만드는 것을 피했습니다. 목표는 LLM이 단순히 챗봇이 아니라 에이전트가 될 때 중요한 행동을 테스트하는 것입니다.

벤치마크의 배경 질문

10개의 API에 접근할 수 있는 비서(assistant)를 상상해 보세요. 단순한 평가는

테스트하는 것입니다.

벤치마크의 배경 질문

10개의 API에 접근할 수 있는 비서(assistant)를 상상해 보세요. 단순한 평가는

모델 테스트 대상 (Models Tested)
제가 테스트한 모델:
[MODEL 1]
[MODEL 2]
[MODEL 3]
[MODEL 4]
[MODEL 5]
[MODEL 6]
[MODEL 7]
저는 가장 큰 모델들만 테스트하는 대신, 추론 중심(reasoning-focused), 범용(general-purpose), 빠르며(fast), 크기가 작은 모델들을 혼합하여 의도적으로 선택했습니다. 흥미로운 비교는 단순히 '누가 이기는가?'에 있는 것이 아닙니다. 모델의 크기, 추론 능력, 또는 속도가 도구 사용 판단을 예측하는지 여부입니다.

실험 (The Experiment)
저는 세 가지 조건 하에서 벤치마크를 실행했습니다.

• 무제한 도구(Unlimited tools): 모델이 명시적인 예산 없이도 도구를 호출할 수 있었습니다.
• 제한된 도구(Limited tools): 모델에게 작은 도구 호출 예산이 주어졌습니다.
• 비용이 발생하는 도구(Costly tools): 서로 다른 도구에 시뮬레이션 비용이 할당되었습니다. 이를 통해 불필요한 행동이 비용이 발생했을 때 모델의 행동 변화를 측정할 수 있었습니다. 가설은 간단했습니다. 만약 모델이 정말로 작업을 이해한다면, 도구 비용을 늘리는 것이 작업 성공률을 극적으로 떨어뜨리지 않으면서도 더 선택적이게 만들어야 한다는 것입니다.

발견 (Findings)
여기서 실험이 흥미로워졌습니다.

1. 순수 정확도가 전부는 아니었습니다
   가장 높은 작업 정확도를 가진 모델이 반드시 가장 낮은 도구 후회(Tool Regret)를 가진 모델은 아니었습니다. 이 구분이 중요합니다. 모델은 너무 많은 불필요한 결정을 내리면서도 잘못된 결정에서 회복하는 데 매우 뛰어날 수 있습니다.

2. 도구 가용성이 모델 행동을 변화시킵니다
   도구가 자유롭게 사용 가능했을 때, 어떤 모델들은 답변이 이미 컨텍스트에 존재하는 경우에도 도구를 호출하려는 의지가 훨씬 커 보였습니다. 이는 흥미로운 실패 모드(failure mode)를 시사합니다. 즉, 도구 자체가 방해가 될 수 있다는 것입니다.

3. 도구 충돌은 다른 약점을 드러냈습니다
   가장 어려운 사례들은 반드시 가장 많은 추론을 요구하는 경우만은 아니었습니다. 그것들은 모델이 어떤 정보에 신뢰를 부여해야 할지 결정해야 하는 경우였습니다. 도구에서 나왔다는 이유만으로 도구 결과가 자동으로 권위 있는 것은 아닙니다.

효율성과 지능은 동일하지 않습니다.

이것이 제가 가장 관심 가졌던 결과였습니다. 10번의 도구 호출로 작업의 95%를 해결하는 모델보다, 두 번의 호출로 92%를 해결하는 모델이 에이전트 시스템에게는 덜 매력적일 수 있습니다. 기존 리더보드는 이러한 차이를 숨길 수 있습니다.

무엇에 놀랐는지
벤치마크를 실행하기 전에, 저는 어려운 케이스가 모델이 여러 도구를 연결하여 사용해야 하는 경우일 것이라고 예상했습니다. 하지만 오히려 반대 케이스에 더 흥미를 느꼈습니다. 즉, 모델이 불필요한 행동을 하지 않을 수 있는가? 이는 인간의 전문 지식이 작동하는 방식과 놀라울 정도로 가깝게 느껴집니다. 숙련된 엔지니어는 알고 있는 모든 진단을 실행하지 않습니다. 숙련된 개발자는 모든 데이터베이스를 쿼리하지 않습니다. 숙련된 비서는 사용 가능하다는 이유만으로 여섯 개의 애플리케이션을 열지 않습니다. 때로는 지능적인 행동이 바로 '아무것도 추가로 하지 않는 것'입니다.

다음으로 측정하고 싶은 것들
현재의 벤치마크는 의도적으로 결정론적(deterministic) 도구를 사용합니다. 다음 버전에서는 다음과 같은 것을 도입해야 합니다:

• 지연된 도구 응답 (delayed tool responses)
• 오래된 정보 (stale information)
• 확률적 도구 신뢰성 (probabilistic tool reliability)
• 실제 금전적 비용이 드는 도구 (tools with real monetary costs)
• 되돌릴 수 없는 행동 (irreversible actions)
• 권한 실패 (permission failures)
• 시간이 지남에 따라 올바른 도구가 바뀌는 긴 다중 턴 작업
  또한 모델들이 이전 행동의 비용에 대한 피드백을 본 후에 도구 선택 능력이 향상되는지 테스트하고 싶습니다. 그렇게 하면 TOOL JUDGMENT가 정적인 평가에서 에이전트 학습 벤치마크로 바뀔 것입니다.

나의 벤치마크
여기서 벤치마크와 리더보드를 확인할 수 있습니다: [링크]
이 벤치마크는 재현 가능하고, 검사할 수 있으며, 새로운 도구 및 시나리오로 확장하기 쉽도록 설계되었습니다.

마지막 생각
우리는 모델들에게 도구를 사용하는 방법을 가르치는 데 많은 시간을 할애했습니다. 하지만 다음 질문은 이것이어야 한다고 생각합니다. '언제 도구를 그대로 둘지'를 가르칠 수 있을까? 왜냐하면 가장 똑똑한 에이전트가 가장 많은 행동을 취하는 에이전트는 아닐 수도 있기 때문입니다. 정확히 어떤 행동을 할 가치가 있는지 아는 에이전트일 것입니다.