Loading...
    • 개발자 가이드
    • API 참조
    • MCP
    • 리소스
    • 릴리스 노트
    Search...
    ⌘K
    리소스
    개요용어집시스템 프롬프트
    개요티켓 라우팅고객 지원 에이전트콘텐츠 조정법률 요약
    Console
    Log in
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...

    Solutions

    • AI agents
    • Code modernization
    • Coding
    • Customer support
    • Education
    • Financial services
    • Government
    • Life sciences

    Partners

    • Amazon Bedrock
    • Google Cloud's Vertex AI

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Company

    • Anthropic
    • Careers
    • Economic Futures
    • Research
    • News
    • Responsible Scaling Policy
    • Security and compliance
    • Transparency

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Help and security

    • Availability
    • Status
    • Support
    • Discord

    Terms and policies

    • Privacy policy
    • Responsible disclosure policy
    • Terms of service: Commercial
    • Terms of service: Consumer
    • Usage policy
    사용 사례

    티켓 라우팅

    이 가이드는 Claude의 고급 자연어 이해 기능을 활용하여 고객 의도, 긴급도, 우선순위, 고객 프로필 등을 기반으로 대규모 고객 지원 티켓을 분류하는 방법을 설명합니다.
    • Claude를 티켓 라우팅에 사용할지 여부 결정
    • LLM 지원 워크플로우 구축 및 배포
    • 올바른 Claude 모델 선택
    • 20개 이상의 의도 카테고리가 있는 경우 분류 계층 구조 사용
    • Claude를 더 큰 지원 워크플로우에 통합

    Claude를 티켓 라우팅에 사용할지 여부 결정

    다음은 기존 ML 접근 방식 대신 Claude와 같은 LLM을 분류 작업에 사용해야 하는 주요 지표입니다:


    LLM 지원 워크플로우 구축 및 배포

    현재 지원 접근 방식 이해

    자동화로 뛰어들기 전에 기존 티켓팅 시스템을 이해하는 것이 중요합니다. 지원 팀이 현재 티켓 라우팅을 어떻게 처리하는지 조사하여 시작하세요.

    다음과 같은 질문을 고려하세요:

    • SLA/서비스 제공이 적용되는지 결정하는 데 어떤 기준이 사용됩니까?
    • 티켓 라우팅은 어느 수준의 지원이나 제품 전문가에게 티켓이 가는지 결정하는 데 사용됩니까?
    • 이미 자동화된 규칙이나 워크플로우가 있습니까? 어떤 경우에 실패합니까?
    • 엣지 케이스나 모호한 티켓은 어떻게 처리됩니까?
    • 팀은 티켓을 어떻게 우선순위를 정합니까?

    인간이 특정 사례를 처리하는 방법을 더 많이 알수록 Claude와 함께 작업하여 작업을 더 잘 수행할 수 있습니다.

    사용자 의도 카테고리 정의

    잘 정의된 사용자 의도 카테고리 목록은 Claude를 사용한 정확한 지원 티켓 분류에 중요합니다. Claude가 시스템 내에서 티켓을 효과적으로 라우팅하는 능력은 시스템의 카테고리가 얼마나 잘 정의되어 있는지에 정확히 비례합니다.

    다음은 사용자 의도 카테고리 및 하위 카테고리의 몇 가지 예입니다.

    의도 외에도 티켓 라우팅 및 우선순위 지정은 긴급도, 고객 유형, SLA 또는 언어와 같은 다른 요소의 영향을 받을 수 있습니다. 자동화된 라우팅 시스템을 구축할 때 다른 라우팅 기준도 고려해야 합니다.

    성공 기준 수립

    지원 팀과 함께 명확한 성공 기준을 정의하고 측정 가능한 벤치마크, 임계값 및 목표를 설정하세요.

    다음은 LLM을 지원 티켓 라우팅에 사용할 때의 표준 기준 및 벤치마크입니다:

    다음은 LLM 사용 여부와 관계없이 유용할 수 있는 일반적인 성공 기준입니다:

    올바른 Claude 모델 선택

    모델의 선택은 비용, 정확도 및 응답 시간 간의 트레이드오프에 따라 달라집니다.

    많은 고객이 claude-haiku-4-5-20251001을 티켓 라우팅에 이상적인 모델로 찾았습니다. 이는 Claude 4 제품군에서 가장 빠르고 비용 효율적인 모델이면서도 여전히 우수한 결과를 제공합니다. 분류 문제가 깊은 주제 전문 지식이나 많은 양의 의도 카테고리 복잡한 추론이 필요한 경우 더 큰 Sonnet 모델을 선택할 수 있습니다.

    강력한 프롬프트 구축

    티켓 라우팅은 분류 작업의 한 유형입니다. Claude는 지원 티켓의 내용을 분석하고 문제 유형, 긴급도, 필요한 전문 지식 또는 기타 관련 요소를 기반으로 미리 정의된 카테고리로 분류합니다.

    티켓 분류 프롬프트를 작성해봅시다. 초기 프롬프트는 사용자 요청의 내용을 포함하고 추론과 의도를 모두 반환해야 합니다.

    Claude 콘솔의 프롬프트 생성기를 시도하여 Claude가 초안을 작성하도록 하세요.

    다음은 티켓 라우팅 분류 프롬프트의 예입니다:

    def classify_support_request(ticket_contents):
        # Define the prompt for the classification task
        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.
            """

    이 프롬프트의 주요 구성 요소를 분석해봅시다:

    • Python f-문자열을 사용하여 프롬프트 템플릿을 만들어 ticket_contents를 <request> 태그에 삽입할 수 있습니다.
    • Claude에게 티켓 내용을 신중하게 분석하여 고객의 핵심 의도와 요구 사항을 결정하는 분류 시스템으로서의 명확한 역할을 부여합니다.
    • Claude에게 적절한 출력 형식을 지시합니다. 이 경우 <reasoning> 태그 내에 추론과 분석을 제공한 후 <intent> 태그 내에 적절한 분류 레이블을 제공합니다.
    • 유효한 의도 카테고리를 지정합니다: "Support, Feedback, Complaint", "Order Tracking", "Refund/Exchange".
    • 몇 가지 예제(일명 few-shot 프롬프팅)를 포함하여 출력 형식을 설명하면 정확도와 일관성이 향상됩니다.

    Claude의 응답을 다양한 XML 태그 섹션으로 분할하려는 이유는 정규식을 사용하여 출력에서 추론과 의도를 별도로 추출할 수 있기 때문입니다. 이를 통해 티켓이 라우팅되는 사람을 결정하기 위해 의도만 사용하는 것과 같은 티켓 라우팅 워크플로우에서 대상이 지정된 다음 단계를 만들 수 있습니다.

    프롬프트 배포

    프롬프트가 테스트 프로덕션 설정에서 얼마나 잘 작동하는지 알기 어렵고 평가를 실행하지 않으면 알 수 없습니다.

    배포 구조를 구축해봅시다. Claude에 대한 호출을 래핑하는 메서드 서명을 정의하여 시작하세요. 이미 작성하기 시작한 메서드를 사용하며, ticket_contents를 입력으로 하고 이제 reasoning과 intent의 튜플을 출력으로 반환합니다. 기존 자동화가 기존 ML을 사용하는 경우 대신 해당 메서드 서명을 따르고 싶을 것입니다.

    import anthropic
    import re
    
    # Create an instance of the Claude API client
    client = anthropic.Anthropic()
    
    # Set the default model
    DEFAULT_MODEL="claude-haiku-4-5-20251001"
    
    def classify_support_request(ticket_contents):
        # Define the prompt for the classification task
        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.
            """
        # Send the prompt to the API to classify the support request.
        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
    
        # Use Python's regular expressions library to extract `reasoning`.
        reasoning_match = re.search(
            r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
        )
        reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
    
        # Similarly, also extract the `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

    이 코드는:

    • Anthropic 라이브러리를 가져오고 API 키를 사용하여 클라이언트 인스턴스를 만듭니다.
    • ticket_contents 문자열을 사용하는 classify_support_request 함수를 정의합니다.
    • classification_prompt를 사용하여 ticket_contents를 Claude로 보냅니다.
    • 응답에서 추출한 모델의 reasoning과 intent를 반환합니다.

    전체 추론과 의도 텍스트가 생성될 때까지 기다린 후 구문 분석해야 하므로 stream=False(기본값)를 설정합니다.


    프롬프트 평가

    프롬프팅은 프로덕션 준비가 되려면 테스트와 최적화가 필요한 경우가 많습니다. 솔루션의 준비 상태를 결정하려면 이전에 설정한 성공 기준과 임계값을 기반으로 성능을 평가하세요.

    평가를 실행하려면 실행할 테스트 케이스가 필요합니다. 이 가이드의 나머지 부분은 이미 테스트 케이스를 개발했다고 가정합니다.

    평가 함수 구축

    이 가이드의 예제 평가는 세 가지 주요 메트릭에 따라 Claude의 성능을 측정합니다:

    • 정확도
    • 분류당 비용

    Claude를 평가해야 할 다른 축이 있을 수 있습니다. 이는 당신에게 중요한 요소에 따라 달라집니다.

    이를 평가하려면 먼저 작성한 스크립트를 수정하고 예측된 의도를 실제 의도와 비교하고 올바른 예측의 백분율을 계산하는 함수를 추가해야 합니다. 또한 비용 계산 및 시간 측정 기능을 추가해야 합니다.

    import anthropic
    import re
    
    # Create an instance of the Claude API client
    client = anthropic.Anthropic()
    
    # Set the default model
    DEFAULT_MODEL="claude-haiku-4-5-20251001"
    
    def classify_support_request(request, actual_intent):
        # Define the prompt for the classification task
        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
    
        # Use Python's regular expressions library to extract `reasoning`.
        reasoning_match = re.search(
            r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
        )
        reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
    
        # Similarly, also extract the `intent`.
        intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
        intent = intent_match.group(1).strip() if intent_match else ""
    
          # Check if the model's prediction is correct.
        correct = actual_intent.strip() == intent.strip()
    
        # Return the reasoning, intent, correct, and usage.
        return reasoning, intent, correct, usage

    우리가 한 편집을 분석해봅시다:

    • 테스트 케이스에서 actual_intent를 classify_support_request 메서드에 추가하고 Claude의 의도 분류가 우리의 황금 의도 분류와 일치하는지 평가하기 위한 비교를 설정했습니다.
    • API 호출에 사용된 입력 및 출력 토큰 수를 기반으로 비용을 계산하기 위해 API 호출의 사용 통계를 추출했습니다.

    평가 실행

    적절한 평가는 어떤 결과가 좋은 결과인지 결정하기 위한 명확한 임계값과 벤치마크가 필요합니다. 위의 스크립트는 정확도, 응답 시간 및 분류당 비용에 대한 런타임 값을 제공하지만 명확하게 설정된 임계값이 여전히 필요합니다. 예를 들어:

    • 정확도: 95% (100개 테스트 중)
    • 분류당 비용: 현재 라우팅 방법에서 평균 50% 감소 (100개 테스트 전체)

    이러한 임계값을 설정하면 규모에 따라 어떤 방법이 당신에게 가장 좋은지, 그리고 요구 사항에 더 잘 맞추기 위해 어떤 변경이 필요할 수 있는지 빠르고 쉽게 그리고 공정한 경험주의로 알 수 있습니다.


    성능 개선

    복잡한 시나리오에서는 표준 프롬프트 엔지니어링 기법 & 가드레일 구현 전략 이상으로 성능을 개선하기 위한 추가 전략을 고려하는 것이 도움이 될 수 있습니다. 다음은 몇 가지 일반적인 시나리오입니다:

    20개 이상의 의도 카테고리가 있는 경우 분류 계층 구조 사용

    클래스 수가 증가함에 따라 필요한 예제의 수도 확장되어 프롬프트가 다루기 어려워질 수 있습니다. 대안으로 분류자의 혼합을 사용하여 계층적 분류 시스템을 구현하는 것을 고려할 수 있습니다.

    1. 의도를 분류 트리 구조로 구성하세요.
    2. 트리의 모든 수준에서 분류자 시리즈를 만들어 계단식 라우팅 접근 방식을 활성화하세요.

    예를 들어, "기술적 문제", "청구 질문", "일반 문의"로 티켓을 광범위하게 분류하는 최상위 분류자가 있을 수 있습니다. 이러한 각 카테고리는 분류를 더 세분화하기 위해 자체 하위 분류자를 가질 수 있습니다.

    • 장점 - 더 큰 뉘앙스와 정확도: 각 상위 경로에 대해 다양한 프롬프트를 만들 수 있어 더 대상이 지정되고 컨텍스트에 맞는 분류가 가능합니다. 이는 향상된 정확도와 고객 요청의 더 미묘한 처리로 이어질 수 있습니다.

    • 단점 - 증가된 지연 시간: 여러 분류자는 지연 시간 증가로 이어질 수 있으며, 우리는 가장 빠른 모델인 Haiku를 사용하여 이 접근 방식을 구현할 것을 권장합니다.

    벡터 데이터베이스 및 유사성 검색 검색을 사용하여 매우 가변적인 티켓 처리

    예제 제공이 성능을 개선하는 가장 효과적인 방법이지만, 지원 요청이 매우 가변적인 경우 단일 프롬프트에 충분한 예제를 포함하기 어려울 수 있습니다.

    이 시나리오에서는 벡터 데이터베이스를 사용하여 예제 데이터 세트에서 유사성 검색을 수행하고 주어진 쿼리에 대해 가장 관련성 높은 예제를 검색할 수 있습니다.

    이 접근 방식은 분류 레시피에서 자세히 설명되어 있으며 성능을 71% 정확도에서 93% 정확도로 개선하는 것으로 나타났습니다.

    예상되는 엣지 케이스를 구체적으로 고려

    다음은 Claude가 티켓을 잘못 분류할 수 있는 몇 가지 시나리오입니다(당신의 상황에 고유한 다른 시나리오가 있을 수 있습니다). 이러한 시나리오에서는 Claude가 엣지 케이스를 처리하는 방법에 대한 명시적 지침이나 예제를 프롬프트에 제공하는 것을 고려하세요:


    Claude를 더 큰 지원 워크플로우에 통합

    적절한 통합을 위해서는 Claude 기반 티켓 라우팅 스크립트가 더 큰 티켓 라우팅 시스템의 아키텍처에 어떻게 맞는지에 대한 몇 가지 결정을 내려야 합니다. 두 가지 방법이 있습니다:

    • 푸시 기반: 사용 중인 지원 티켓 시스템(예: Zendesk)이 웹훅 이벤트를 라우팅 서비스로 보내 의도를 분류하고 라우팅합니다.
      • 이 접근 방식은 더 웹 확장 가능하지만 공개 엔드포인트를 노출해야 합니다.
    • 풀 기반: 코드가 주어진 일정에 따라 최신 티켓을 가져오고 풀 시간에 라우팅합니다.
      • 이 접근 방식은 구현하기 더 쉽지만 풀 빈도가 너무 높으면 지원 티켓 시스템에 불필요한 호출을 할 수 있거나 풀 빈도가 너무 낮으면 지나치게 느릴 수 있습니다.

    이러한 접근 방식 중 하나에 대해 스크립트를 서비스로 래핑해야 합니다. 선택하는 접근 방식은 지원 티켓팅 시스템이 제공하는 API에 따라 달라집니다.


    분류 요리책

    더 많은 예제 코드와 자세한 평가 지침을 보려면 분류 요리책을 방문하세요.

    Claude 콘솔

    Claude 콘솔에서 워크플로우 구축 및 평가를 시작하세요.