“Think” 툴: Claude가 멈춰서 생각할 수 있도록 하기 | Anthropic

요약: Anthropic이 개발한 “think” 툴은 Claude에게 복잡한 작업 중 구조화된 생각을 위한 전용 공간을 제공합니다. 이 툴은 정책 준수, 일관된 의사결정, 다단계 문제 해결에서 상당한 성능 향상을 가져왔습니다. τ-Bench 벤치마크에서 “think” 툴을 사용했을 때 기본 설정 대비 항공 도메인에서 54%, 리테일 도메인에서 4%의 성능 개선을 달성했습니다. 도메인에 맞는 프롬프트와 결합할 때 최적의 성능을 보이며, 특히 순차적인 툴 호출과 정책 중심 환경에서 효과적입니다.
===BODY_KO## 확장된 사고 기능 업데이트 (2025년 12월 15일)

확장된 사고 기능은 초기 출시 이후 개선되어, 대부분의 경우 전용 think 툴 대신 이 기능을 사용하는 것이 좋습니다. 확장된 사고 기능은 Claude가 복잡한 문제를 추론할 수 있는 공간을 제공하며, 더 나은 통합과 성능을 제공합니다. 구현 세부사항은 확장된 사고 기능 문서를 참조하세요.

—

Claude의 복잡한 문제 해결 능력을 계속 개선하면서, 우리는 특히 효과적인 접근 방식을 발견했습니다: 복잡한 작업 중 구조화된 사고를 위한 전용 공간을 만드는 “think” 툴입니다. 이 간단하지만 강력한 기법은—아래에서 설명하겠지만—Claude의 새로운 “확장된 사고” 기능(확장된 사고 구현 세부사항은 여기를 참조)과는 다른 개념으로, Claude의 에이전트 툴 사용 능력에서 현저한 개선을 가져왔습니다. 여기에는 정책 준수, 일관된 의사결정, 다단계 문제 처리가 포함되며, 최소한의 구현 오버헤드로 가능합니다.

이 포스트에서는 다양한 애플리케이션에서 “think” 툴을 구현하는 방법을 탐구하고, 검증된 벤치마크 결과를 바탕으로 개발자를 위한 실용적인 가이드를 공유합니다.

## “think” 툴이란?

“think” 툴을 통해 최종 답변에 도달하는 과정의 일부로 Claude에게 추가적인 생각 단계—자체 지정된 공간과 함께—를 포함할 수 있는 능력을 제공합니다. 확장된 사고와 비슷하게 들리지만, 다른 개념입니다.

확장된 사고는 Claude가 응답을 생성하기 시작하기 전에 수행하는 작업에 관한 것입니다. 확장된 사고를 사용하면 Claude는 행동하기 전에 계획을 깊이 고려하고 반복합니다. “think” 툴은 Claude가 응답을 생성하기 시작한 후, 앞으로 나아가는 데 필요한 모든 정보가 있는지 멈춰서 생각하기 위해 단계를 추가하는 것입니다.

이는 긴 툴 호출 체인을 수행하거나 사용자와 긴 다단계 대화를 할 때 특히 유용합니다. 이로 인해 “think” 툴은 Claude가 사용자 쿼리만으로 응답을 구성하는 데 필요한 모든 정보를 갖고 있지 않고, 외부 정보(예: 툴 호출 결과의 정보)를 처리해야 하는 경우에 더 적합합니다.

“think” 툴로 Claude가 수행하는 추론은 확장된 사고로 얻을 수 있는 것보다 덜 포괄적이며, 모델이 발견한 새로운 정보에 더 초점을 맞춥니다.

우리는 비순차적 툴 호출이나 단순한 지시사항 따르기와 같은 더 간단한 툴 사용 시나리오에는 확장된 사고 기능을 사용하는 것을 권장합니다. 또한 코딩, 수학, 물리학과 같이 Claude가 툴을 호출할 필요가 없는 유스케이스에도 확장된 사고 기능이 유용합니다.

“think” 툴은 Claude가 복잡한 툴을 호출해야 하고, 긴 툴 호출 체인에서 툴 출력을 주의 깊게 분석해야 하며, 상세한 지침이 있는 정책 중심 환경을 탐색해야 하거나, 각 단계가 이전 단계에 구축되고 실수가 비용이 드는 순차적 의사결정을 해야 할 때 더 적합합니다.

τ-Bench에서 가져온 표준 툴 사양 형식을 사용한 샘플 구현은 다음과 같습니다:

“`json
{
"name": "think",
"description": "무언가에 대해 생각하기 위해 툴을 사용하세요. 새로운 정보를 얻거나 데이터베이스를 변경하지 않고 생각을 로그에 추가합니다. 복잡한 추론이나 일부 캐시 메모리가 필요할 때 사용합니다.",
"input_schema": {
"type": "object",
"properties": {
"thought": {
"type": "string",
"description": "생각할 생각입니다."
}
},
"required": ["thought"]
}
}
“`

## τ-Bench에서의 성능

우리는 τ-bench(tau-bench)를 사용하여 “think” 툴을 평가했는데, 이는 모델이 현실적인 고객 서비스 시나리오에서 툴을 사용하는 능력을 테스트하도록 설계된 포괄적인 벤치마크로, 여기서 “think” 툴은 평가의 표준 환경의 일부입니다.

τ-bench는 Claude의 다음 능력을 평가합니다:
– 시뮬레이션된 사용자와 현실적인 대화 탐색
– 복잡한 고객 서비스 에이전트 정책 지침을 일관되게 따르기
– 환경 데이터베이스에 액세스하고 조작하기 위해 다양한 툴 사용

τ-bench에서 사용하는 주요 평가 지표는 pass^k로, 이는 모든 작업에 걸쳐 평균화된 주어진 작업에 대해 k개의 독립적인 작업 시도가 모두 성공할 확률을 측정합니다. k번 시도 중 하나 이상이 성공하는지 측정하는 다른 LLM 평가에서 일반적인 pass@k 지표와 달리, pass^k는 일관성과 신뢰성을 평가합니다. 이는 정책에 대한 일관된 준수가 필수적인 고객 서비스 애플리케이션에서 중요한 품질입니다.

## 성능 분석

우리의 평가는 다른 여러 구성을 비교했습니다:
– 기본선 (“think” 툴 없음, 확장된 사고 모드 없음)
– 확장된 사고 모드만
– “think” 툴만
– 최적화된 프롬프트와 함께 “think” 툴(항공 도메인용)

결과는 벤치마크의 “항공” 및 “리테일” 고객 서비스 도메인 모두에서 Claude 3.7이 “think” 툴을 효과적으로 사용했을 때 드라마틱한 개선을 보여주었습니다:

**항공 도메인**: 최적화된 프롬프트와 함께 “think” 툴은 pass^1 지표에서 0.570을 달성했으며, 기본선의 0.370 대비 54%의 상대적 개선
**리테일 도메인**: “think” 툴만으로 0.812를 달성했으며, 기본선의 0.783 대비 개선

Claude 3.7 Sonnet의 Tau-Bench 평가 “항공” 도메인에서의 성능, 4가지 다른 구성에서.

Claude 3.7 Sonnet의 Tau-Bench 평가 “항공” 도메인에서의 성능

| 구성 | k=1 | k=2 | k=3 | k=4 | k=5 |
|——|—–|—–|—–|—–|—–|
| “Think” + 프롬프트 | 0.584 | 0.444 | 0.384 | 0.356 | 0.340 |
| “Think” | 0.404 | 0.254 | 0.186 | 0.140 | 0.100 |
| 확장된 사고 | 0.412 | 0.290 | 0.232 | 0.192 | 0.160 |
| 기본선 | 0.332 | 0.206 | 0.148 | 0.116 | 0.100 |

4가지 다른 구성에 대한 평가 결과. 점수는 비율입니다.

항공 도메인에서 최상의 성능은 고객 요청을 분석할 때 사용할 추론 접근 방식의 유형에 대한 예시를 제공하는 최적화된 프롬프트와 “think” 툴을 결합하여 달성되었습니다.

다음은 최적화된 프롬프트의 예시입니다:

### think 툴 사용하기

어떤 행동을 취하거나 툴 결과를 받은 후 사용자에게 응답하기 전에, think 툴을 스크래치패드로 사용하여:
– 현재 요청에 적용되는 특정 규칙 나열
– 필요한 모든 정보가 수집되었는지 확인
– 계획된 행동이 모든 정책을 준수하는지 확인
– 툴 결과를 정확성을 위해 반복 검토

think 툴 내에서 반복 검토할 내용의 예시는 다음과 같습니다:

**예시 1:**
“`
사용자가 ABC123 항공편 취소를 원함
– 확인 필요: 사용자 ID, 예약 ID, 취소 사유
– 취소 규칙 확인:
* 예약 후 24시간 이내인가?
* 아닌 경우, 티켓 클래스와 보험 확인
– 이미 비행했거나 지난 구간이 없는지 확인
– 계획: 누락된 정보 수집, 규칙 확인, 확인받기
“`

**예시 2:**
“`
사용자가 NYC행 티켓 3장을 각 수하물 2개씩 예약을 원함
– 확인할 사용자 ID 필요:
* 수하물 허용량을 위한 멤버십 티어
* 프로필에 존재하는 결제 방법
– 수하물 계산:
* 이코노미 클래스 × 3명 승객
* 일반 회원인 경우: 1개 무료 수하물 각 → 3개 추가 수하물 = $150
* 실버 회원인 경우: 2개 무료 수하물 각 → 0개 추가 수하물 = $0
* 골드 회원인 경우: 3개 무료 수하물 각 → 0개 추가 수하물 = $0
– 확인할 결제 규칙:
* 여행 상품권 최대 1개, 신용카드 1개, 기프트카드 3개
* 모든 결제 방법은 프로필에 있어야 함
* 여행 상품권 잔액은 사라짐
– 계획: 1. 사용자 ID 가져오기 2. 수하물 요금을 위한 멤버십 레벨 확인 3. 프로필에 있는 결제 방법과 조합이 허용되는지 확인 4. 총계 계산: 티켓 가격 + 수하물 요금 5. 예약을 위한 명시적 확인 받기
“`

특히 흥미로운 점은 다른 접근 방식이 어떻게 비교되는지입니다. 최적화된 프롬프트와 함께 “think” 툴을 사용하는 것이 확장된 사고 모드(프롬프트가 없는 “think” 툴과 유사한 성능을 보임)보다 현저히 더 나은 결과를 달성했습니다.

“think” 툴만 사용(프롬프트 없이)하면 기본선 대비 성능이 개선되었지만, 여전히 최적화된 접근 방식에는 미치지 못했습니다. “think” 툴과 최적화된 프롬프트의 조합이 현저한 차이로 가장 강력한 성능을 전달했는데, 이는 아마도 벤치마크의 항공 정책 부분의 높은 복잡성 때문일 가능성이 높으며, 여기서 모델은 “생각”하는 방법에 대한 예시를 제공받는 것에서 가장 큰 이익을 얻었습니다.

리테일 도메인에서도 우리는 각 접근 방식의 구체적인 영향을 이해하기 위해 다양한 구성을 테스트했습니다.

Claude 3.7 Sonnet의 Tau-Bench 평가 “리테일” 도메인에서의 성능, 3가지 다른 구성에서.

Claude 3.7 Sonnet의 Tau-Bench 평가 “리테일” 도메인에서의 성능

| 구성 | k=1 | k=2 | k=3 | k=4 | k=5 |
|——|—–|—–|—–|—–|—–|
| “Think” + 프롬프트 없음 | 0.812 | 0.735 | 0.685 | 0.650 | 0.626 |
| 확장된 사고 | 0.770 | 0.681 | 0.623 | 0.581 | 0.548 |
| 기본선 | 0.783 | 0.695 | 0.643 | 0.607 | 0.583 |

3가지 다른 구성에 대한 평가 결과. 점수는 비율입니다.

“think” 툴은 추가적인 프롬프트 없이도 가장 높은 pass^1 점수인 0.812를 달성했습니다. 리테일 정책은 항공 도메인과 비교하여 탐색하기가 눈에 띄게 쉬웠으며, Claude는 추가적인 지도 없이 생각할 공간만 있으면 개선할 수 있었습니다.

## τ-Bench 분석에서의 핵심 통찰

우리의 상세한 분석은 “think” 툴을 효과적으로 구현하는 데 도움이 되는 여러 패턴을 밝혀냈습니다:

**어려운 도메인에서 프롬프트가 중요합니다.** “think” 툴을 사용할 수 있게 하는 것만으로는 어느 정도 성능이 향상될 수 있지만, 최적화된 프롬프트와 결합하면 어려운 도메인에서 현저히 더 나은 결과를 가져왔습니다. 그러나 더 쉬운 도메인은 “think”에 접근할 수 있는 것만으로도 혜택을 받을 수 있습니다.

**시험에서 개선된 일관성.** “think”를 사용하여 얻은 개선은 k=5까지 pass^k에서 유지되었으며, 이는 툴이 Claude가 엣지 케이스와 비정상적인 시나리오를 더 효과적으로 처리하도록 도왔음을 나타냅니다.

## SWE-Bench에서의 성능

Claude 3.7 Sonnet을 평가할 때 유사한 “think” 툴을 우리의 SWE-bench 설정에 추가했으며, 이는 달성된 최첨단 점수 0.623에 기여했습니다. 적응된 “think” 툴 정의는 다음과 같습니다:

“`json
{
"name": "think",
"description": "무언가에 대해 생각하기 위해 툴을 사용하세요. 새로운 정보를 얻거나 저장소에 변경 사항을 만들지 않고 생각만 기록합니다. 복잡한 추론이나 아이디어 회의가 필요할 때 사용합니다. 예를 들어, 저장소를 탐색하고 버그의 소스를 발견하면 이 툴을 호출하여 버그를 수정하는 여러 고유한 방법을 아이디어 회의하고, 어떤 변경 사항이 가장 간단하고 효과적일지 평가합니다. 또는 일부 테스트 결과를 받으면, 실패한 테스트를 수정하는 방법을 아이디어 회의하기 위해 이 툴을 호출합니다.",
"input_schema": {
"type": "object",
"properties": {
"thought": {
"type": "string",
"description": "당신의 생각입니다."
}
},
"required": ["thought"]
}
}
“`

우리의 실험(“think” 툴로 n=30 샘플, 없이 n=144 샘플)은 이 툴을 포함하는 것의 고립된 효과가 평균 1.6%의 성능 향상을 가져왔음을 보여주었습니다(Welch의 t-검정: t(38.89) = 6.71, p < .001, d = 1.47). ## "think" 툴을 사용할 때 이러한 평가 결과를 바탕으로, 우리는 Claude가 "think" 툴에서 가장 큰 혜택을 받는 특정 시나리오를 식별했습니다: - **툴 출력 분석.** Claude가 행동하기 전에 이전 툴 호출의 출력을 주의 깊게 처리해야 하고 접근 방식을 되돌려야 할 수 있을 때 - **정책 중심 환경.** Claude가 상세한 지침을 따르고 준수 여부를 확인해야 할 때 - **순차적 의사결정.** 각 행동이 이전 행동에 구축되고 실수가 비용이 들 때(종종 다단계 도메인에서 발견됨) ## 구현 모범 사례 Claude와 "think" 툴을 최대한 활용하기 위해, 우리의 τ-bench 실험을 바탕으로 다음 구현 관행을 권장합니다. ### 1. 도메인별 예시와 함께 전략적 프롬프트 가장 효과적인 접근 방식은 τ-bench 항공 도메인에서 사용된 것처럼 "think" 툴을 언제 어떻게 사용할지에 대한 명확한 지침을 제공하는 것입니다. 특정 유스케이스에 맞춰진 예시를 제공하면 모델이 "think" 툴을 얼마나 효과적으로 사용하는지 상당히 개선됩니다: - 추론 과정에서 예상되는 세부 수준 - 복잡한 지침을 실행 가능한 단계로 분해하는 방법 - 일반적인 시나리오를 처리하기 위한 의사결정 트리 - 필요한 모든 정보가 수집되었는지 확인하는 방법 ### 2. 복잡한 안내를 시스템 프롬프트에 배치 우리는 "think" 툴에 대한 지침이 길거나 복잡할 때, 툴 설명 자체에 배치하는 것보다 시스템 프롬프트에 포함하는 것이 더 효과적이라는 것을 발견했습니다. 이 접근 방식은 더 광범위한 컨텍스트를 제공하며 모델이 사고 과정을 전체적인 동작에 더 잘 통합하도록 돕습니다. ## "think" 툴을 사용하지 않을 때 "think" 툴이 상당한 개선을 제공할 수 있지만, 모든 툴 사용 유스케이스에 적용 가능한 것은 아니며, 증가된 프롬프트 길이와 출력 토큰 비용이 발생합니다. 구체적으로, 우리는 "think" 툴이 다음 유스케이스에서 어떠한 개선도 제공하지 않는다는 것을 발견했습니다: - **비순차적 툴 호출.** Claude가 작업을 완료하기 위해 단일 툴 호출 또는 여러 병렬 호출만 하면 되는 경우, "think"를 추가하는 것에서 개선될 가능성이 없습니다. - **단순한 지시사항 따르기.** Claude가 준수해야 할 제약이 많지 않고 기본 동작이 충분히 좋은 경우, 추가적인 "생각"에서 얻을 수 있는 이득이 없을 것입니다. ## 시작하기 "think" 툴은 Claude 구현에 직관적인 추가 사항으로, 단 몇 단계로 의미 있는 개선을 가져올 수 있습니다: 1. **에이전트 툴 사용 시나리오로 테스트.** Claude가 현재 정책 준수나 긴 툴 호출 체인에서 복잡한 추론에 어려움을 겪고 있는 도전적인 유스케이스로 시작하세요. 2. **툴 정의 추가.** 도메인에 맞게 사용자 정의된 "think" 툴을 구현하세요. 최소한의 코드가 필요하지만 더 구조화된 추론을 가능하게 합니다. 또한 시스템 프롬프트에 도메인과 관련된 예시와 함께 언제 어떻게 툴을 사용할지에 대한 지침을 포함하는 것을 고려하세요. 3. **모니터링 및 수정.** 실제로 Claude가 툴을 사용하는 방식을 살펴보고, 더 효과적인 생각 패턴을 장려하도록 프롬프트를 조정하세요. 이 툴을 추가하는 가장 좋은 점은 성능 결과 측면에서 최소한의 단점이 있다는 것입니다. Claude가 사용하기로 결정하지 않는 한 외부 동작을 변경하지 않으며, 기존 툴이나 워크플로를 방해하지 않습니다. ## 결론 우리의 연구는 "think" 툴이 정책 준수와 긴 툴 호출 체인에서의 추론이 필요한 복잡한 작업에서 Claude 3.7 Sonnet의 성능을 상당히 향상시킬 수 있음을 입증했습니다[^1]. "Think"는 만능 해결책은 아니지만 올바른 유스케이스에서 상당한 혜택을 제공하며, 모두 최소한의 구현 복잡도로 가능합니다. Claude와 "think" 툴을 사용하여 더 능력 있고, 신뢰할 수 있으며, 투명한 AI 시스템을 구축하는 방법을 보게 되기를 기대합니다. [^1]: 우리의 τ-Bench 결과는 "think" 툴과 함께 Claude 3.7 Sonnet의 개선에 초점을 맞췄지만, 우리의 실험은 Claude 3.5 Sonnet (New)도 3.7 Sonnet과 동일한 구성으로 성능 향상을 달성할 수 있음을 보여줍니다. 이는 이 개선이 다른 Claude 모델로도 일반화됨을 나타냅니다.

“Think” 툴: Claude가 멈춰서 생각할 수 있도록 하기 | Anthropic

Anthropic이 개발한 “think” 툴은 Claude에게 복잡한 작업 중 구조화된 생각을 위한 전용 공간을 제공합니다. 이 툴은 정책 준수, 일관된 의사결정, 다단계 문제 해결에서 상당한 성능 향상을 가져왔습니다. τ-Bench 벤치마크에서 “think” 툴을 사용했을 때 기본 설정 대비 항공 도메인에서 54%, 리테일 도메인에서 4%의 성능 개선을 달성했습니다. 도메인에 맞는 프롬프트와 결합할 때 최적의 성능을 보이며, 특히 순차적인 툴 호출과 정책 중심 환경에서 효과적입니다.

===BODY_KO## 확장된 사고 기능 업데이트 (2025년 12월 15일)

확장된 사고 기능은 초기 출시 이후 개선되어, 대부분의 경우 전용 think 툴 대신 이 기능을 사용하는 것이 좋습니다. 확장된 사고 기능은 Claude가 복잡한 문제를 추론할 수 있는 공간을 제공하며, 더 나은 통합과 성능을 제공합니다. 구현 세부사항은 확장된 사고 기능 문서를 참조하세요.

---

Claude의 복잡한 문제 해결 능력을 계속 개선하면서, 우리는 특히 효과적인 접근 방식을 발견했습니다: 복잡한 작업 중 구조화된 사고를 위한 전용 공간을 만드는 “think” 툴입니다. 이 간단하지만 강력한 기법은—아래에서 설명하겠지만—Claude의 새로운 “확장된 사고” 기능(확장된 사고 구현 세부사항은 여기를 참조)과는 다른 개념으로, Claude의 에이전트 툴 사용 능력에서 현저한 개선을 가져왔습니다. 여기에는 정책 준수, 일관된 의사결정, 다단계 문제 처리가 포함되며, 최소한의 구현 오버헤드로 가능합니다.

이 포스트에서는 다양한 애플리케이션에서 “think” 툴을 구현하는 방법을 탐구하고, 검증된 벤치마크 결과를 바탕으로 개발자를 위한 실용적인 가이드를 공유합니다.

“think” 툴이란?

“think” 툴을 통해 최종 답변에 도달하는 과정의 일부로 Claude에게 추가적인 생각 단계—자체 지정된 공간과 함께—를 포함할 수 있는 능력을 제공합니다. 확장된 사고와 비슷하게 들리지만, 다른 개념입니다.

확장된 사고는 Claude가 응답을 생성하기 시작하기 전에 수행하는 작업에 관한 것입니다. 확장된 사고를 사용하면 Claude는 행동하기 전에 계획을 깊이 고려하고 반복합니다. “think” 툴은 Claude가 응답을 생성하기 시작한 후, 앞으로 나아가는 데 필요한 모든 정보가 있는지 멈춰서 생각하기 위해 단계를 추가하는 것입니다.

이는 긴 툴 호출 체인을 수행하거나 사용자와 긴 다단계 대화를 할 때 특히 유용합니다. 이로 인해 “think” 툴은 Claude가 사용자 쿼리만으로 응답을 구성하는 데 필요한 모든 정보를 갖고 있지 않고, 외부 정보(예: 툴 호출 결과의 정보)를 처리해야 하는 경우에 더 적합합니다.

“think” 툴로 Claude가 수행하는 추론은 확장된 사고로 얻을 수 있는 것보다 덜 포괄적이며, 모델이 발견한 새로운 정보에 더 초점을 맞춥니다.

우리는 비순차적 툴 호출이나 단순한 지시사항 따르기와 같은 더 간단한 툴 사용 시나리오에는 확장된 사고 기능을 사용하는 것을 권장합니다. 또한 코딩, 수학, 물리학과 같이 Claude가 툴을 호출할 필요가 없는 유스케이스에도 확장된 사고 기능이 유용합니다.

“think” 툴은 Claude가 복잡한 툴을 호출해야 하고, 긴 툴 호출 체인에서 툴 출력을 주의 깊게 분석해야 하며, 상세한 지침이 있는 정책 중심 환경을 탐색해야 하거나, 각 단계가 이전 단계에 구축되고 실수가 비용이 드는 순차적 의사결정을 해야 할 때 더 적합합니다.

τ-Bench에서 가져온 표준 툴 사양 형식을 사용한 샘플 구현은 다음과 같습니다:

“json

{

"name": "think",

"description": "무언가에 대해 생각하기 위해 툴을 사용하세요. 새로운 정보를 얻거나 데이터베이스를 변경하지 않고 생각을 로그에 추가합니다. 복잡한 추론이나 일부 캐시 메모리가 필요할 때 사용합니다.",

"input_schema": {

"type": "object",

"properties": {

"thought": {

"type": "string",

"description": "생각할 생각입니다."

}

},

"required": ["thought"]

}

}

`

τ-Bench에서의 성능

우리는 τ-bench(tau-bench)를 사용하여 "think" 툴을 평가했는데, 이는 모델이 현실적인 고객 서비스 시나리오에서 툴을 사용하는 능력을 테스트하도록 설계된 포괄적인 벤치마크로, 여기서 "think" 툴은 평가의 표준 환경의 일부입니다.

τ-bench는 Claude의 다음 능력을 평가합니다:

• 시뮬레이션된 사용자와 현실적인 대화 탐색
• 복잡한 고객 서비스 에이전트 정책 지침을 일관되게 따르기
• 환경 데이터베이스에 액세스하고 조작하기 위해 다양한 툴 사용

τ-bench에서 사용하는 주요 평가 지표는 pass^k로, 이는 모든 작업에 걸쳐 평균화된 주어진 작업에 대해 k개의 독립적인 작업 시도가 모두 성공할 확률을 측정합니다. k번 시도 중 하나 이상이 성공하는지 측정하는 다른 LLM 평가에서 일반적인 pass@k 지표와 달리, pass^k는 일관성과 신뢰성을 평가합니다. 이는 정책에 대한 일관된 준수가 필수적인 고객 서비스 애플리케이션에서 중요한 품질입니다.

성능 분석

우리의 평가는 다른 여러 구성을 비교했습니다:

• 기본선 ("think" 툴 없음, 확장된 사고 모드 없음)
• 확장된 사고 모드만
• "think" 툴만
• 최적화된 프롬프트와 함께 "think" 툴(항공 도메인용)

결과는 벤치마크의 "항공" 및 "리테일" 고객 서비스 도메인 모두에서 Claude 3.7이 "think" 툴을 효과적으로 사용했을 때 드라마틱한 개선을 보여주었습니다:

항공 도메인: 최적화된 프롬프트와 함께 "think" 툴은 pass^1 지표에서 0.570을 달성했으며, 기본선의 0.370 대비 54%의 상대적 개선

리테일 도메인: "think" 툴만으로 0.812를 달성했으며, 기본선의 0.783 대비 개선

Claude 3.7 Sonnet의 Tau-Bench 평가 "항공" 도메인에서의 성능, 4가지 다른 구성에서.

Claude 3.7 Sonnet의 Tau-Bench 평가 "항공" 도메인에서의 성능

| 구성 | k=1 | k=2 | k=3 | k=4 | k=5 |

|------|-----|-----|-----|-----|-----|

| "Think" + 프롬프트 | 0.584 | 0.444 | 0.384 | 0.356 | 0.340 |

| "Think" | 0.404 | 0.254 | 0.186 | 0.140 | 0.100 |

| 확장된 사고 | 0.412 | 0.290 | 0.232 | 0.192 | 0.160 |

| 기본선 | 0.332 | 0.206 | 0.148 | 0.116 | 0.100 |

4가지 다른 구성에 대한 평가 결과. 점수는 비율입니다.

항공 도메인에서 최상의 성능은 고객 요청을 분석할 때 사용할 추론 접근 방식의 유형에 대한 예시를 제공하는 최적화된 프롬프트와 "think" 툴을 결합하여 달성되었습니다.

다음은 최적화된 프롬프트의 예시입니다:

think 툴 사용하기

어떤 행동을 취하거나 툴 결과를 받은 후 사용자에게 응답하기 전에, think 툴을 스크래치패드로 사용하여:

• 현재 요청에 적용되는 특정 규칙 나열
• 필요한 모든 정보가 수집되었는지 확인
• 계획된 행동이 모든 정책을 준수하는지 확인
• 툴 결과를 정확성을 위해 반복 검토

think 툴 내에서 반복 검토할 내용의 예시는 다음과 같습니다:

예시 1:

`

사용자가 ABC123 항공편 취소를 원함

• 확인 필요: 사용자 ID, 예약 ID, 취소 사유
• 취소 규칙 확인:

• 예약 후 24시간 이내인가?

• 아닌 경우, 티켓 클래스와 보험 확인

• 이미 비행했거나 지난 구간이 없는지 확인
• 계획: 누락된 정보 수집, 규칙 확인, 확인받기

`

예시 2:

`

사용자가 NYC행 티켓 3장을 각 수하물 2개씩 예약을 원함

• 확인할 사용자 ID 필요:

• 수하물 허용량을 위한 멤버십 티어

• 프로필에 존재하는 결제 방법

• 수하물 계산:

• 이코노미 클래스 × 3명 승객

• 일반 회원인 경우: 1개 무료 수하물 각 → 3개 추가 수하물 = $150

• 실버 회원인 경우: 2개 무료 수하물 각 → 0개 추가 수하물 = $0

• 골드 회원인 경우: 3개 무료 수하물 각 → 0개 추가 수하물 = $0

• 확인할 결제 규칙:

• 여행 상품권 최대 1개, 신용카드 1개, 기프트카드 3개

• 모든 결제 방법은 프로필에 있어야 함

• 여행 상품권 잔액은 사라짐

• 계획: 1. 사용자 ID 가져오기 2. 수하물 요금을 위한 멤버십 레벨 확인 3. 프로필에 있는 결제 방법과 조합이 허용되는지 확인 4. 총계 계산: 티켓 가격 + 수하물 요금 5. 예약을 위한 명시적 확인 받기

`

특히 흥미로운 점은 다른 접근 방식이 어떻게 비교되는지입니다. 최적화된 프롬프트와 함께 "think" 툴을 사용하는 것이 확장된 사고 모드(프롬프트가 없는 "think" 툴과 유사한 성능을 보임)보다 현저히 더 나은 결과를 달성했습니다.

"think" 툴만 사용(프롬프트 없이)하면 기본선 대비 성능이 개선되었지만, 여전히 최적화된 접근 방식에는 미치지 못했습니다. "think" 툴과 최적화된 프롬프트의 조합이 현저한 차이로 가장 강력한 성능을 전달했는데, 이는 아마도 벤치마크의 항공 정책 부분의 높은 복잡성 때문일 가능성이 높으며, 여기서 모델은 "생각"하는 방법에 대한 예시를 제공받는 것에서 가장 큰 이익을 얻었습니다.

리테일 도메인에서도 우리는 각 접근 방식의 구체적인 영향을 이해하기 위해 다양한 구성을 테스트했습니다.

Claude 3.7 Sonnet의 Tau-Bench 평가 "리테일" 도메인에서의 성능, 3가지 다른 구성에서.

Claude 3.7 Sonnet의 Tau-Bench 평가 "리테일" 도메인에서의 성능

| 구성 | k=1 | k=2 | k=3 | k=4 | k=5 |

|------|-----|-----|-----|-----|-----|

| "Think" + 프롬프트 없음 | 0.812 | 0.735 | 0.685 | 0.650 | 0.626 |

| 확장된 사고 | 0.770 | 0.681 | 0.623 | 0.581 | 0.548 |

| 기본선 | 0.783 | 0.695 | 0.643 | 0.607 | 0.583 |

3가지 다른 구성에 대한 평가 결과. 점수는 비율입니다.

"think" 툴은 추가적인 프롬프트 없이도 가장 높은 pass^1 점수인 0.812를 달성했습니다. 리테일 정책은 항공 도메인과 비교하여 탐색하기가 눈에 띄게 쉬웠으며, Claude는 추가적인 지도 없이 생각할 공간만 있으면 개선할 수 있었습니다.

τ-Bench 분석에서의 핵심 통찰

우리의 상세한 분석은 "think" 툴을 효과적으로 구현하는 데 도움이 되는 여러 패턴을 밝혀냈습니다:

어려운 도메인에서 프롬프트가 중요합니다. "think" 툴을 사용할 수 있게 하는 것만으로는 어느 정도 성능이 향상될 수 있지만, 최적화된 프롬프트와 결합하면 어려운 도메인에서 현저히 더 나은 결과를 가져왔습니다. 그러나 더 쉬운 도메인은 "think"에 접근할 수 있는 것만으로도 혜택을 받을 수 있습니다.

시험에서 개선된 일관성. "think"를 사용하여 얻은 개선은 k=5까지 pass^k에서 유지되었으며, 이는 툴이 Claude가 엣지 케이스와 비정상적인 시나리오를 더 효과적으로 처리하도록 도왔음을 나타냅니다.

SWE-Bench에서의 성능

Claude 3.7 Sonnet을 평가할 때 유사한 "think" 툴을 우리의 SWE-bench 설정에 추가했으며, 이는 달성된 최첨단 점수 0.623에 기여했습니다. 적응된 "think" 툴 정의는 다음과 같습니다:

`json

{

"name": "think",

"description": "무언가에 대해 생각하기 위해 툴을 사용하세요. 새로운 정보를 얻거나 저장소에 변경 사항을 만들지 않고 생각만 기록합니다. 복잡한 추론이나 아이디어 회의가 필요할 때 사용합니다. 예를 들어, 저장소를 탐색하고 버그의 소스를 발견하면 이 툴을 호출하여 버그를 수정하는 여러 고유한 방법을 아이디어 회의하고, 어떤 변경 사항이 가장 간단하고 효과적일지 평가합니다. 또는 일부 테스트 결과를 받으면, 실패한 테스트를 수정하는 방법을 아이디어 회의하기 위해 이 툴을 호출합니다.",

"input_schema": {

"type": "object",

"properties": {

"thought": {

"type": "string",

"description": "당신의 생각입니다."

}

},

"required": ["thought"]

}

}

“

우리의 실험(“think” 툴로 n=30 샘플, 없이 n=144 샘플)은 이 툴을 포함하는 것의 고립된 효과가 평균 1.6%의 성능 향상을 가져왔음을 보여주었습니다(Welch의 t-검정: t(38.89) = 6.71, p < .001, d = 1.47).

“think” 툴을 사용할 때

이러한 평가 결과를 바탕으로, 우리는 Claude가 “think” 툴에서 가장 큰 혜택을 받는 특정 시나리오를 식별했습니다:

• 툴 출력 분석. Claude가 행동하기 전에 이전 툴 호출의 출력을 주의 깊게 처리해야 하고 접근 방식을 되돌려야 할 수 있을 때
• 정책 중심 환경. Claude가 상세한 지침을 따르고 준수 여부를 확인해야 할 때
• 순차적 의사결정. 각 행동이 이전 행동에 구축되고 실수가 비용이 들 때(종종 다단계 도메인에서 발견됨)

구현 모범 사례

Claude와 “think” 툴을 최대한 활용하기 위해, 우리의 τ-bench 실험을 바탕으로 다음 구현 관행을 권장합니다.

1. 도메인별 예시와 함께 전략적 프롬프트

가장 효과적인 접근 방식은 τ-bench 항공 도메인에서 사용된 것처럼 “think” 툴을 언제 어떻게 사용할지에 대한 명확한 지침을 제공하는 것입니다. 특정 유스케이스에 맞춰진 예시를 제공하면 모델이 “think” 툴을 얼마나 효과적으로 사용하는지 상당히 개선됩니다:

• 추론 과정에서 예상되는 세부 수준
• 복잡한 지침을 실행 가능한 단계로 분해하는 방법
• 일반적인 시나리오를 처리하기 위한 의사결정 트리
• 필요한 모든 정보가 수집되었는지 확인하는 방법

2. 복잡한 안내를 시스템 프롬프트에 배치

우리는 “think” 툴에 대한 지침이 길거나 복잡할 때, 툴 설명 자체에 배치하는 것보다 시스템 프롬프트에 포함하는 것이 더 효과적이라는 것을 발견했습니다. 이 접근 방식은 더 광범위한 컨텍스트를 제공하며 모델이 사고 과정을 전체적인 동작에 더 잘 통합하도록 돕습니다.

“think” 툴을 사용하지 않을 때

“think” 툴이 상당한 개선을 제공할 수 있지만, 모든 툴 사용 유스케이스에 적용 가능한 것은 아니며, 증가된 프롬프트 길이와 출력 토큰 비용이 발생합니다. 구체적으로, 우리는 “think” 툴이 다음 유스케이스에서 어떠한 개선도 제공하지 않는다는 것을 발견했습니다:

• 비순차적 툴 호출. Claude가 작업을 완료하기 위해 단일 툴 호출 또는 여러 병렬 호출만 하면 되는 경우, “think”를 추가하는 것에서 개선될 가능성이 없습니다.
• 단순한 지시사항 따르기. Claude가 준수해야 할 제약이 많지 않고 기본 동작이 충분히 좋은 경우, 추가적인 “생각”에서 얻을 수 있는 이득이 없을 것입니다.

시작하기

“think” 툴은 Claude 구현에 직관적인 추가 사항으로, 단 몇 단계로 의미 있는 개선을 가져올 수 있습니다:

1. 에이전트 툴 사용 시나리오로 테스트. Claude가 현재 정책 준수나 긴 툴 호출 체인에서 복잡한 추론에 어려움을 겪고 있는 도전적인 유스케이스로 시작하세요.

2. 툴 정의 추가. 도메인에 맞게 사용자 정의된 “think” 툴을 구현하세요. 최소한의 코드가 필요하지만 더 구조화된 추론을 가능하게 합니다. 또한 시스템 프롬프트에 도메인과 관련된 예시와 함께 언제 어떻게 툴을 사용할지에 대한 지침을 포함하는 것을 고려하세요.

3. 모니터링 및 수정. 실제로 Claude가 툴을 사용하는 방식을 살펴보고, 더 효과적인 생각 패턴을 장려하도록 프롬프트를 조정하세요.

이 툴을 추가하는 가장 좋은 점은 성능 결과 측면에서 최소한의 단점이 있다는 것입니다. Claude가 사용하기로 결정하지 않는 한 외부 동작을 변경하지 않으며, 기존 툴이나 워크플로를 방해하지 않습니다.

결론

우리의 연구는 “think” 툴이 정책 준수와 긴 툴 호출 체인에서의 추론이 필요한 복잡한 작업에서 Claude 3.7 Sonnet의 성능을 상당히 향상시킬 수 있음을 입증했습니다¹. “Think”는 만능 해결책은 아니지만 올바른 유스케이스에서 상당한 혜택을 제공하며, 모두 최소한의 구현 복잡도로 가능합니다. Claude와 “think” 툴을 사용하여 더 능력 있고, 신뢰할 수 있으며, 투명한 AI 시스템을 구축하는 방법을 보게 되기를 기대합니다.

• “think” 툴은 Claude에게 복잡한 작업 중 구조화된 사고를 위한 전용 공간을 제공하여 정책 준수, 일관된 의사결정, 다단계 문제 해결 능력을 향상시킵니다
• τ-Bench 벤치마크 결과, “think” 툴은 항공 도메인에서 54%, 리테일 도메인에서 4%의 성능 개선을 달성했으며, 도메인에 맞는 최적화된 프롬프트와 결합할 때 가장 효과적입니다
• “think” 툴은 순차적인 툴 호출 체인, 정책 중심 환경, 실수가 비용이 드는 순차적 의사결정 시나리오에서 가장 유용하며, 비순차적 툴 호출이나 단순한 지시사항 따르기에서는 불필요합니다

extended thinking|확장된 사고|Claude가 응답을 생성하기 전에 깊이 고려하고 반복하는 기능

τ-Bench|타우 벤치|모델의 툴 사용 능력을 테스트하기 위한 현실적인 고객 서비스 시나리오 벤치마크

pass^k|패스 케이|k개의 독립적인 시도가 모두 성공할 확률을 측정하는 평가 지표

tool call|툴 호출|Claude가 외부 툴이나 기능을 실행하는 동작

핵심 포인트

• “think” 툴은 Claude에게 복잡한 작업 중 구조화된 사고를 위한 전용 공간을 제공하여 정책 준수, 일관된 의사결정, 다단계 문제 해결 능력을 향상시킵니다
• τ-Bench 벤치마크 결과, “think” 툴은 항공 도메인에서 54%, 리테일 도메인에서 4%의 성능 개선을 달성했으며, 도메인에 맞는 최적화된 프롬프트와 결합할 때 가장 효과적입니다
• “think” 툴은 순차적인 툴 호출 체인, 정책 중심 환경, 실수가 비용이 드는 순차적 의사결정 시나리오에서 가장 유용하며, 비순차적 툴 호출이나 단순한 지시사항 따르기에서는 불필요합니다

---

출처: The "think" tool: Enabling Claude to stop and think \ Anthropic