분류 작업에 전통적인 ML 접근 방식 대신 Claude와 같은 LLM을 사용해야 하는 주요 지표는 다음과 같습니다:
자동화하기 전에 기존 티켓 시스템을 이해하는 것이 중요합니다. 지원 팀이 현재 티켓 라우팅을 어떻게 처리하는지 조사하는 것부터 시작하세요.
다음과 같은 질문을 고려해 보세요:
사람이 특정 사례를 어떻게 처리하는지 더 많이 알수록 Claude와 함께 해당 작업을 더 잘 수행할 수 있습니다.
잘 정의된 사용자 의도 카테고리 목록은 Claude를 사용한 정확한 지원 티켓 분류에 매우 중요합니다. 시스템 내에서 티켓을 효과적으로 라우팅하는 Claude의 능력은 시스템의 카테고리가 얼마나 잘 정의되어 있는지에 정비례합니다.
다음은 사용자 의도 카테고리와 하위 카테고리의 몇 가지 예시입니다.
의도 외에도 티켓 라우팅과 우선순위 지정은 긴급도, 고객 유형, SLA 또는 언어와 같은 다른 요소의 영향을 받을 수 있습니다. 자동화된 라우팅 시스템을 구축할 때 다른 라우팅 기준도 반드시 고려하세요.
지원 팀과 협력하여 측정 가능한 벤치마크, 임계값 및 목표를 포함한 명확한 성공 기준을 정의하세요.
다음은 지원 티켓 라우팅에 LLM을 사용할 때의 몇 가지 표준 기준과 벤치마크입니다:
다음은 LLM 사용 여부와 관계없이 유용할 수 있는 몇 가지 일반적인 성공 기준입니다:
모델 선택은 비용, 정확도, 응답 시간 간의 트레이드오프에 따라 달라집니다.
많은 고객이 claude-haiku-4-5-20251001을 티켓 라우팅에 이상적인 모델로 평가했습니다. 이 모델은 Claude 4 제품군에서 가장 빠르고 비용 효율적인 모델이면서도 여전히 우수한 결과를 제공합니다. 분류 문제가 깊은 주제 전문 지식이나 많은 양의 의도 카테고리, 또는 복잡한 추론을 필요로 하는 경우, 더 큰 Sonnet 모델을 선택할 수 있습니다.
티켓 라우팅은 분류 작업의 한 유형입니다. Claude는 지원 티켓의 내용을 분석하고 문제 유형, 긴급도, 필요한 전문 지식 또는 기타 관련 요소를 기반으로 사전 정의된 카테고리로 분류합니다.
티켓 분류 프롬프트를 작성하세요. 초기 프롬프트에는 사용자 요청의 내용이 포함되어야 하며 추론과 의도를 모두 반환해야 합니다.
Claude Cookbook의 메타프롬프트 레시피를 사용하여 Claude가 초안을 작성하도록 해보세요.
다음은 티켓 라우팅 분류 프롬프트의 예시입니다:
def classify_support_request(ticket_contents):
# 분류 작업을 위한 프롬프트 정의
classification_prompt = f"""You will be acting as a customer support ticket classification system. Your task is to analyze customer support requests and output the appropriate classification intent for each request, along with your reasoning.
Here is the customer support request you need to classify:
<request>{ticket_contents}</request>
Please carefully analyze the above request to determine the customer's core intent and needs. Consider what the customer is asking for has concerns about.
First, write out your reasoning and analysis of how to classify this request inside <reasoning> tags.
Then, output the appropriate classification label for the request inside a <intent> tag. The valid intents are:
<intents>
<intent>Support, Feedback, Complaint</intent>
<intent>Order Tracking</intent>
<intent>Refund/Exchange</intent>
</intents>
A request may have ONLY ONE applicable intent. Only include the intent that is most applicable to the request.
As an example, consider the following request:
<request>Hello! I had high-speed fiber internet installed on Saturday and my installer, Kevin, was absolutely fantastic! Where can I send my positive review? Thanks for your help!</request>
Here is an example of how your output should be formatted (for the above example request):
<reasoning>The user seeks information in order to leave positive feedback.</reasoning>
<intent>Support, Feedback, Complaint</intent>
Here are a few more examples:
<examples>
<example 2>
Example 2 Input:
<request>I wanted to write and personally thank you for the compassion you showed towards my family during my father's funeral this past weekend. Your staff was so considerate and helpful throughout this whole process; it really took a load off our shoulders. The visitation brochures were beautiful. We'll never forget the kindness you showed us and we are so appreciative of how smoothly the proceedings went. Thank you, again, Amarantha Hill on behalf of the Hill Family.</request>
Example 2 Output:
<reasoning>User leaves a positive review of their experience.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 2>
<example 3>
...
</example 8>
<example 9>
Example 9 Input:
<request>Your website keeps sending ad-popups that block the entire screen. It took me twenty minutes just to finally find the phone number to call and complain. How can I possibly access my account information with all of these popups? Can you access my account for me, since your website is broken? I need to know what the address is on file.</request>
Example 9 Output:
<reasoning>The user requests help accessing their web account information.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 9>
Remember to always include your classification reasoning before your actual intent output. The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""이 프롬프트의 주요 구성 요소는 다음과 같습니다:
ticket_contents를 <request> 태그에 삽입할 수 있습니다.<reasoning> 태그 안에 제공하고, 그 뒤에 적절한 분류 레이블을 <intent> 태그 안에 제공하도록 합니다.Claude가 응답을 별도의 XML 태그 섹션으로 분할하도록 하면 정규 표현식을 사용하여 출력에서 추론과 의도를 독립적으로 추출할 수 있습니다. 이를 통해 의도만 사용하여 티켓을 어떤 사람에게 라우팅할지 결정하는 것과 같이 티켓 라우팅 워크플로우에서 목표에 맞는 다음 단계를 만들 수 있습니다.
테스트 프로덕션 환경에 배포하고 평가를 실행하지 않고는 프롬프트가 얼마나 잘 작동하는지 알기 어렵습니다.
배포 구조를 구축하세요. Claude 호출을 래핑하기 위한 메서드 시그니처를 정의하는 것부터 시작하세요. 앞서 작성하기 시작한 ticket_contents를 입력으로 받는 메서드를 확장하여 이제 reasoning과 intent의 튜플을 출력으로 반환하도록 하세요. 전통적인 ML을 사용하는 기존 자동화가 있다면 해당 메서드 시그니처를 따르는 것이 좋습니다.
import re
# Claude API 클라이언트 인스턴스를 생성합니다
client = anthropic.Anthropic()
# 기본 모델을 설정합니다
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(ticket_contents):
# 분류 작업을 위한 프롬프트를 정의합니다
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
... The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""
# 지원 요청을 분류하기 위해 프롬프트를 API로 전송합니다.
message = client.messages.create(
model=DEFAULT_MODEL,
max_tokens=500,
temperature=0,
messages=[{"role": "user", "content": classification_prompt}],
stream=False,
)
reasoning_and_intent = message.content[0].text
# Python의 정규 표현식 라이브러리를 사용하여 `reasoning`을 추출합니다.
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 마찬가지로 `intent`도 추출합니다.
intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
intent = intent_match.group(1).strip() if intent_match else ""
return reasoning, intent이 코드는:
ticket_contents 문자열을 받는 classify_support_request 함수를 정의합니다.classification_prompt를 사용하여 분류를 위해 ticket_contents를 Claude에 전송합니다.reasoning과 intent를 반환합니다.전체 추론 및 의도 텍스트가 파싱 전에 생성되어야 하므로, 이 예시는 stream=False(기본값)를 설정합니다.
프롬프팅은 프로덕션 준비가 되기까지 종종 테스트와 최적화가 필요합니다. 솔루션의 준비 상태를 판단하려면 앞서 수립한 성공 기준과 임계값을 기반으로 성능을 평가하세요.
평가를 실행하려면 실행할 테스트 케이스가 필요합니다. 이 가이드의 나머지 부분은 이미 테스트 케이스를 개발했다고 가정합니다.
이 가이드의 예시 평가는 세 가지 주요 지표를 따라 Claude의 성능을 측정합니다:
중요하게 생각하는 요소에 따라 다른 축에서 Claude를 평가해야 할 수도 있습니다.
이를 평가하려면 먼저 스크립트를 수정하여 예측된 의도와 실제 의도를 비교하고 올바른 예측의 비율을 계산하는 함수를 추가하세요. 그런 다음 비용 계산 및 시간 측정 기능을 추가하세요.
import re
# Claude API 클라이언트 인스턴스를 생성합니다
client = anthropic.Anthropic()
# 기본 모델을 설정합니다
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(request, actual_intent):
# 분류 작업을 위한 프롬프트를 정의합니다
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""
message = client.messages.create(
model=DEFAULT_MODEL,
max_tokens=500,
temperature=0,
messages=[{"role": "user", "content": classification_prompt}],
)
usage = message.usage # Get the usage statistics for the API call for how many input and output tokens were used.
reasoning_and_intent = message.content[0].text
# Python의 정규 표현식 라이브러리를 사용하여 `reasoning`을 추출합니다.
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 마찬가지로 `intent`도 추출합니다.
intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
intent = intent_match.group(1).strip() if intent_match else ""
# 모델의 예측이 올바른지 확인합니다.
correct = actual_intent.strip() == intent.strip()
# reasoning, intent, correct, usage를 반환합니다.
return reasoning, intent, correct, usage수정 사항에 대한 설명은 다음과 같습니다:
classify_support_request 메서드는 이제 테스트 케이스에서 actual_intent를 받아 Claude의 의도 분류와 비교하여 일치하는지 평가합니다.적절한 평가에는 좋은 결과가 무엇인지 판단하기 위한 명확한 임계값과 벤치마크가 필요합니다. 앞의 스크립트는 정확도, 응답 시간, 분류당 비용에 대한 런타임 값을 반환하지만, 여전히 명확하게 설정된 임계값이 필요합니다. 예를 들어:
이러한 임계값을 갖추면 대규모로, 그리고 공정한 경험주의를 바탕으로 어떤 방법이 가장 적합한지, 요구 사항에 더 잘 맞추기 위해 어떤 변경이 필요한지 빠르고 쉽게 파악할 수 있습니다.
복잡한 시나리오에서는 표준 프롬프트 엔지니어링 기법 및 가드레일 구현 전략을 넘어 성능을 개선하기 위한 추가 전략을 고려하는 것이 도움이 될 수 있습니다. 다음은 몇 가지 일반적인 시나리오입니다:
클래스 수가 증가함에 따라 필요한 예시의 수도 늘어나 프롬프트가 다루기 어려워질 수 있습니다. 대안으로, 여러 분류기를 혼합하여 계층적 분류 시스템을 구현하는 것을 고려할 수 있습니다.
예를 들어, 티켓을 "기술적 문제", "청구 질문", "일반 문의"로 광범위하게 분류하는 최상위 분류기를 가질 수 있습니다. 이러한 각 카테고리는 분류를 더욱 세분화하기 위한 자체 하위 분류기를 가질 수 있습니다.

장점 - 더 높은 세밀함과 정확도: 각 상위 경로에 대해 서로 다른 프롬프트를 만들 수 있어, 더 목표에 맞고 맥락에 특화된 분류가 가능합니다. 이는 정확도 향상과 고객 요청에 대한 더 세밀한 처리로 이어질 수 있습니다.
단점 - 증가된 latency: 여러 분류기는 latency(지연 시간) 증가로 이어질 수 있으므로, Anthropic은 가장 빠른 모델인 Haiku로 이 접근 방식을 구현할 것을 권장합니다.
예시를 제공하는 것이 성능을 개선하는 가장 효과적인 방법임에도 불구하고, 지원 요청의 변동성이 매우 높은 경우 단일 프롬프트에 충분한 예시를 포함하기 어려울 수 있습니다.
이 시나리오에서는 벡터 데이터베이스를 사용하여 예시 데이터셋에서 유사도 검색을 수행하고 주어진 쿼리에 가장 관련성 높은 예시를 검색할 수 있습니다.
분류 레시피에 자세히 설명된 이 접근 방식은 정확도를 71%에서 93%로 향상시키는 것으로 나타났습니다.
다음은 Claude가 티켓을 잘못 분류할 수 있는 몇 가지 시나리오입니다(상황에 따라 고유한 다른 시나리오가 있을 수 있습니다). 이러한 시나리오에서는 Claude가 엣지 케이스를 어떻게 처리해야 하는지에 대한 명시적인 지침이나 예시를 프롬프트에 제공하는 것을 고려하세요:
적절한 통합을 위해서는 Claude 기반 티켓 라우팅 스크립트가 더 큰 티켓 라우팅 시스템의 아키텍처에 어떻게 맞춰질지에 대한 몇 가지 결정을 내려야 합니다. 이를 수행하는 두 가지 방법이 있습니다:
이러한 접근 방식 중 어느 것을 사용하든 스크립트를 서비스로 래핑해야 합니다. 접근 방식의 선택은 지원 티켓 시스템이 제공하는 API에 따라 달라집니다.
더 많은 예시 코드와 자세한 평가 가이드는 분류 쿡북을 방문하세요.
Claude Console에서 워크플로우 구축 및 평가를 시작하세요.
Was this page helpful?