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

분류 작업에 기존 ML 접근법 대신 Claude와 같은 LLM을 사용해야 하는 주요 지표들은 다음과 같습니다:
기존 ML 프로세스는 대규모 레이블 데이터셋이 필요합니다. Claude의 사전 훈련된 모델은 수십 개의 레이블 예제만으로도 티켓을 효과적으로 분류할 수 있어 데이터 준비 시간과 비용을 크게 줄입니다.
기존 ML 접근법이 구축되면 변경하는 것은 노동 집약적이고 데이터 집약적인 작업입니다. 반면 제품이나 고객 요구사항이 진화함에 따라 Claude는 광범위한 훈련 데이터 재레이블링 없이도 클래스 정의 변경이나 새로운 클래스에 쉽게 적응할 수 있습니다.
기존 ML 모델은 종종 구조화되지 않은 데이터로 어려움을 겪으며 광범위한 특성 엔지니어링이 필요합니다. Claude의 고급 언어 이해는 엄격한 온톨로지 구조에 의존하지 않고 내용과 맥락을 기반으로 정확한 분류를 가능하게 합니다.
기존 ML 접근법은 종종 단어 주머니 모델이나 단순한 패턴 매칭에 의존합니다. Claude는 클래스가 예제가 아닌 조건으로 정의될 때 기본 규칙을 이해하고 적용하는 데 뛰어납니다.
많은 기존 ML 모델은 의사결정 과정에 대한 통찰력을 거의 제공하지 않습니다. Claude는 분류 결정에 대한 인간이 읽을 수 있는 설명을 제공하여 자동화 시스템에 대한 신뢰를 구축하고 필요한 경우 쉬운 적응을 촉진합니다.
기존 ML 시스템은 종종 이상치와 모호한 입력으로 어려움을 겪으며, 자주 잘못 분류하거나 포괄적인 카테고리로 기본 설정합니다. Claude의 자연어 처리 능력은 지원 티켓의 맥락과 뉘앙스를 더 잘 해석할 수 있게 하여 수동 개입이 필요한 잘못 라우팅되거나 분류되지 않은 티켓의 수를 잠재적으로 줄입니다.
기존 ML 접근법은 일반적으로 지원되는 각 언어에 대해 별도의 모델이나 광범위한 번역 프로세스가 필요합니다. Claude의 다국어 능력은 별도의 모델이나 광범위한 번역 프로세스 없이도 다양한 언어로 티켓을 분류할 수 있어 글로벌 고객 기반에 대한 지원을 간소화합니다.

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

현재 지원 접근법 이해

자동화에 뛰어들기 전에 기존 티켓팅 시스템을 이해하는 것이 중요합니다. 지원 팀이 현재 티켓 라우팅을 어떻게 처리하는지 조사하는 것부터 시작하세요. 다음과 같은 질문들을 고려해보세요:
  • 어떤 SLA/서비스 제공을 적용할지 결정하는 데 어떤 기준이 사용되나요?
  • 티켓 라우팅이 티켓이 어떤 지원 계층이나 제품 전문가에게 가는지 결정하는 데 사용되나요?
  • 이미 자동화된 규칙이나 워크플로우가 있나요? 어떤 경우에 실패하나요?
  • 엣지 케이스나 모호한 티켓은 어떻게 처리되나요?
  • 팀은 티켓의 우선순위를 어떻게 정하나요?
인간이 특정 케이스를 어떻게 처리하는지 더 많이 알수록 Claude와 함께 작업하여 해당 작업을 수행하는 데 더 나을 것입니다.

사용자 의도 카테고리 정의

잘 정의된 사용자 의도 카테고리 목록은 Claude를 사용한 정확한 지원 티켓 분류에 중요합니다. Claude가 시스템 내에서 티켓을 효과적으로 라우팅하는 능력은 시스템 카테고리가 얼마나 잘 정의되어 있는지에 직접적으로 비례합니다. 다음은 사용자 의도 카테고리와 하위 카테고리의 몇 가지 예입니다.
  • 하드웨어 문제
  • 소프트웨어 버그
  • 호환성 문제
  • 성능 문제
  • 비밀번호 재설정
  • 계정 액세스 문제
  • 청구 문의
  • 구독 변경
  • 기능 문의
  • 제품 호환성 질문
  • 가격 정보
  • 가용성 문의
  • 사용법 질문
  • 기능 사용 지원
  • 모범 사례 조언
  • 문제 해결 안내
  • 버그 보고
  • 기능 요청
  • 일반 피드백 또는 제안
  • 불만사항
  • 주문 상태 문의
  • 배송 정보
  • 반품 및 교환
  • 주문 수정
  • 설치 지원
  • 업그레이드 요청
  • 유지보수 일정
  • 서비스 취소
  • 데이터 개인정보 문의
  • 의심스러운 활동 보고
  • 보안 기능 지원
  • 규제 준수 질문
  • 서비스 약관 문의
  • 법적 문서 요청
  • 중요한 시스템 장애
  • 긴급 보안 문제
  • 시간에 민감한 문제
  • 제품 교육 요청
  • 문서 문의
  • 웨비나 또는 워크샵 정보
  • 통합 지원
  • API 사용 질문
  • 타사 호환성 문의
의도 외에도 티켓 라우팅과 우선순위 지정은 긴급성, 고객 유형, SLA 또는 언어와 같은 다른 요소의 영향을 받을 수도 있습니다. 자동화된 라우팅 시스템을 구축할 때 다른 라우팅 기준도 고려해야 합니다.

성공 기준 설정

지원 팀과 협력하여 측정 가능한 벤치마크, 임계값 및 목표가 있는 명확한 성공 기준을 정의하세요. 다음은 지원 티켓 라우팅에 LLM을 사용할 때의 표준 기준과 벤치마크입니다:
이 지표는 Claude가 시간이 지남에 따라 유사한 티켓을 얼마나 일관되게 분류하는지 평가합니다. 라우팅 신뢰성을 유지하는 데 중요합니다. 표준화된 입력 세트로 모델을 주기적으로 테스트하여 95% 이상의 일관성 비율을 목표로 측정하세요.
이는 Claude가 새로운 카테고리나 변화하는 티켓 패턴에 얼마나 빨리 적응할 수 있는지 측정합니다. 새로운 티켓 유형을 도입하고 모델이 이러한 새로운 카테고리에서 만족스러운 정확도(예: >90%)를 달성하는 데 걸리는 시간을 측정하여 테스트하세요. 50-100개의 샘플 티켓 내에서 적응을 목표로 하세요.
이는 Claude가 여러 언어로 티켓을 정확하게 라우팅하는 능력을 평가합니다. 다양한 언어에서 라우팅 정확도를 측정하여 비주요 언어에서 5-10% 이상의 정확도 저하가 없도록 목표로 하세요.
이는 비정상적이거나 복잡한 티켓에 대한 Claude의 성능을 평가합니다. 엣지 케이스의 테스트 세트를 만들고 라우팅 정확도를 측정하여 이러한 도전적인 입력에서 최소 80%의 정확도를 목표로 하세요.
이는 다양한 고객 인구통계에서 라우팅하는 Claude의 공정성을 측정합니다. 잠재적 편향에 대해 라우팅 결정을 정기적으로 감사하여 모든 고객 그룹에서 일관된 라우팅 정확도(2-3% 이내)를 목표로 하세요.
토큰 수를 최소화하는 것이 중요한 상황에서 이 기준은 Claude가 최소한의 맥락으로 얼마나 잘 수행하는지 평가합니다. 제공되는 맥락의 양을 다양하게 하여 라우팅 정확도를 측정하고, 티켓 제목과 간단한 설명만으로 90% 이상의 정확도를 목표로 하세요.
이는 라우팅 결정에 대한 Claude의 설명의 품질과 관련성을 평가합니다. 인간 평가자가 설명을 척도(예: 1-5)로 점수를 매길 수 있으며, 평균 4점 이상을 달성하는 것을 목표로 합니다.
다음은 LLM 사용 여부와 관계없이 유용할 수 있는 몇 가지 일반적인 성공 기준입니다:
라우팅 정확도는 티켓이 첫 번째 시도에서 적절한 팀이나 개인에게 올바르게 할당되는 빈도를 측정합니다. 이는 일반적으로 전체 티켓 중 올바르게 라우팅된 티켓의 백분율로 측정됩니다. 업계 벤치마크는 종종 90-95%의 정확도를 목표로 하지만, 이는 지원 구조의 복잡성에 따라 달라질 수 있습니다.
이 지표는 티켓이 제출된 후 할당되는 속도를 추적합니다. 더 빠른 할당 시간은 일반적으로 더 빠른 해결과 향상된 고객 만족도로 이어집니다. 최고 수준의 시스템은 종종 평균 할당 시간을 5분 미만으로 달성하며, 많은 시스템이 거의 즉각적인 라우팅(LLM 구현으로 가능)을 목표로 합니다.
재라우팅 비율은 초기 라우팅 후 티켓이 재할당되어야 하는 빈도를 나타냅니다. 낮은 비율은 더 정확한 초기 라우팅을 시사합니다. 10% 미만의 재라우팅 비율을 목표로 하며, 최고 성능 시스템은 5% 이하의 비율을 달성합니다.
이는 고객과의 첫 번째 상호작용에서 해결되는 티켓의 백분율을 측정합니다. 높은 비율은 효율적인 라우팅과 잘 준비된 지원 팀을 나타냅니다. 업계 벤치마크는 일반적으로 70-75% 범위이며, 최고 성과자는 80% 이상의 비율을 달성합니다.
평균 처리 시간은 티켓을 처음부터 끝까지 해결하는 데 걸리는 시간을 측정합니다. 효율적인 라우팅은 이 시간을 크게 줄일 수 있습니다. 벤치마크는 업계와 복잡성에 따라 크게 다르지만, 많은 조직이 중요하지 않은 문제에 대해 평균 처리 시간을 24시간 미만으로 유지하는 것을 목표로 합니다.
종종 상호작용 후 설문조사를 통해 측정되는 이 점수는 지원 프로세스에 대한 전반적인 고객 만족도를 반영합니다. 효과적인 라우팅은 더 높은 만족도에 기여합니다. 90% 이상의 CSAT 점수를 목표로 하며, 최고 성과자는 종종 95% 이상의 만족도를 달성합니다.
이는 티켓이 더 높은 지원 계층으로 에스컬레이션되어야 하는 빈도를 측정합니다. 낮은 에스컬레이션 비율은 종종 더 정확한 초기 라우팅을 나타냅니다. 20% 미만의 에스컬레이션 비율을 목표로 하며, 최고 수준의 시스템은 10% 이하의 비율을 달성합니다.
이 지표는 라우팅 솔루션을 구현한 후 상담원이 얼마나 많은 티켓을 효과적으로 처리할 수 있는지 살펴봅니다. 개선된 라우팅은 생산성을 증가시켜야 합니다. 상담원당 하루 또는 시간당 해결된 티켓을 추적하여 측정하고, 새로운 라우팅 시스템 구현 후 10-20%의 개선을 목표로 하세요.
이는 라우팅 시스템에 들어가기 전에 셀프서비스 옵션을 통해 해결되는 잠재적 티켓의 백분율을 측정합니다. 높은 비율은 효과적인 사전 라우팅 분류를 나타냅니다. 20-30%의 전환율을 목표로 하며, 최고 성과자는 40% 이상의 비율을 달성합니다.
이 지표는 각 지원 티켓을 해결하는 평균 비용을 계산합니다. 효율적인 라우팅은 시간이 지남에 따라 이 비용을 줄이는 데 도움이 되어야 합니다. 벤치마크는 크게 다르지만, 많은 조직이 개선된 라우팅 시스템 구현 후 티켓당 비용을 10-15% 줄이는 것을 목표로 합니다.

적절한 Claude 모델 선택

모델 선택은 비용, 정확도, 응답 시간 간의 트레이드오프에 따라 달라집니다. 많은 고객이 claude-3-5-haiku-20241022를 티켓 라우팅에 이상적인 모델로 발견했습니다. 이는 Claude 3 패밀리에서 가장 빠르고 비용 효율적인 모델이면서도 여전히 뛰어난 결과를 제공하기 때문입니다. 분류 문제가 깊은 주제 전문 지식이나 대량의 의도 카테고리 복잡한 추론을 요구하는 경우, 더 큰 Sonnet 모델을 선택할 수 있습니다.

강력한 프롬프트 구축

티켓 라우팅은 분류 작업의 한 유형입니다. Claude는 지원 티켓의 내용을 분석하고 문제 유형, 긴급성, 필요한 전문 지식 또는 기타 관련 요소를 기반으로 사전 정의된 카테고리로 분류합니다. 티켓 분류 프롬프트를 작성해 보겠습니다. 초기 프롬프트는 사용자 요청의 내용을 포함하고 추론과 의도를 모두 반환해야 합니다.
Claude Console프롬프트 생성기를 사용하여 Claude가 첫 번째 초안을 작성하도록 해보세요.
다음은 티켓 라우팅 분류 프롬프트의 예입니다:
def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""당신은 고객 지원 티켓 분류 시스템 역할을 할 것입니다. 당신의 작업은 고객 지원 요청을 분석하고 각 요청에 대한 적절한 분류 의도와 추론을 출력하는 것입니다.

        다음은 분류해야 할 고객 지원 요청입니다:

        <request>{ticket_contents}</request>

        위 요청을 신중히 분석하여 고객의 핵심 의도와 요구사항을 파악하세요. 고객이 무엇을 요청하고 있는지, 무엇에 대해 우려하고 있는지 고려하세요.

        먼저 이 요청을 분류하는 방법에 대한 추론과 분석을 <reasoning> 태그 안에 작성하세요.

        그런 다음 <intent> 태그 안에 요청에 대한 적절한 분류 레이블을 출력하세요. 유효한 의도는 다음과 같습니다:
        <intents>
        <intent>지원, 피드백, 불만</intent>
        <intent>주문 추적</intent>
        <intent>환불/교환</intent>
        </intents>

        요청은 하나의 적용 가능한 의도만 가질 수 있습니다. 요청에 가장 적용 가능한 의도만 포함하세요.

        예를 들어, 다음 요청을 고려해보세요:
        <request>안녕하세요! 토요일에 고속 광섬유 인터넷을 설치했는데 설치 기사 Kevin이 정말 훌륭했습니다! 긍정적인 리뷰를 어디에 보낼 수 있나요? 도움 주셔서 감사합니다!</request>

        다음은 출력 형식의 예입니다(위 예시 요청에 대한):
        <reasoning>사용자는 긍정적인 피드백을 남기기 위한 정보를 찾고 있습니다.</reasoning>
        <intent>지원, 피드백, 불만</intent>

        다음은 몇 가지 추가 예시입니다:
        <examples>
        <example 2>
        예시 2 입력:
        <request>지난 주말 아버지의 장례식 동안 저희 가족에게 보여주신 연민에 대해 개인적으로 감사의 말씀을 드리고 싶었습니다. 직원분들이 이 전체 과정에서 너무 배려심 있고 도움이 되었습니다. 정말 우리 어깨의 짐을 덜어주었습니다. 조문 브로셔가 아름다웠습니다. 우리는 당신이 보여준 친절함을 결코 잊지 않을 것이며 절차가 얼마나 순조롭게 진행되었는지 정말 감사합니다. Hill 가족을 대표하여 Amarantha Hill이 다시 한 번 감사드립니다.</request>

        예시 2 출력:
        <reasoning>사용자가 자신의 경험에 대한 긍정적인 리뷰를 남깁니다.</reasoning>
        <intent>지원, 피드백, 불만</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        예시 9 입력:
        <request>당신의 웹사이트가 전체 화면을 차단하는 광고 팝업을 계속 보냅니다. 전화번호를 찾아서 불만을 제기하는 데만 20분이 걸렸습니다. 이 모든 팝업으로 어떻게 내 계정 정보에 액세스할 수 있나요? 웹사이트가 고장났으니 제 계정에 액세스해 주실 수 있나요? 파일에 있는 주소가 무엇인지 알아야 합니다.</request>

        예시 9 출력:
        <reasoning>사용자가 웹 계정 정보에 액세스하는 데 도움을 요청합니다.</reasoning>
        <intent>지원, 피드백, 불만</intent>
        </example 9>

        실제 의도 출력 전에 항상 분류 추론을 포함해야 합니다. 추론은 <reasoning> 태그로, 의도는 <intent> 태그로 둘러싸야 합니다. 추론과 의도만 반환하세요.
        """
이 프롬프트의 주요 구성 요소를 분석해 보겠습니다:
  • Python f-string을 사용하여 프롬프트 템플릿을 만들어 ticket_contents<request> 태그에 삽입될 수 있도록 합니다.
  • Claude에게 티켓 내용을 신중히 분석하여 고객의 핵심 의도와 요구사항을 파악하는 분류 시스템으로서 명확하게 정의된 역할을 부여합니다.
  • 적절한 출력 형식에 대해 Claude에게 지시합니다. 이 경우 <reasoning> 태그 안에 추론과 분석을 제공한 다음 <intent> 태그 안에 적절한 분류 레이블을 제공하도록 합니다.
  • 유효한 의도 카테고리를 지정합니다: “지원, 피드백, 불만”, “주문 추적”, “환불/교환”.
  • 출력 형식을 설명하는 몇 가지 예시(즉, 퓨샷 프롬프팅)를 포함하여 정확도와 일관성을 향상시킵니다.
Claude가 응답을 다양한 XML 태그 섹션으로 나누도록 하는 이유는 정규 표현식을 사용하여 출력에서 추론과 의도를 별도로 추출할 수 있기 때문입니다. 이를 통해 티켓을 라우팅할 사람을 결정하기 위해 의도만 사용하는 등 티켓 라우팅 워크플로우에서 대상화된 다음 단계를 만들 수 있습니다.

프롬프트 배포

테스트 프로덕션 환경에서 배포하고 평가를 실행하지 않고는 프롬프트가 얼마나 잘 작동하는지 알기 어렵습니다. 배포 구조를 구축해 보겠습니다. Claude에 대한 호출을 래핑하는 메서드 시그니처를 정의하는 것부터 시작하세요. 이미 작성하기 시작한 메서드를 가져와서 ticket_contents를 입력으로 하고 이제 reasoningintent의 튜플을 출력으로 반환합니다. 기존 ML을 사용하는 기존 자동화가 있는 경우 대신 해당 메서드 시그니처를 따라야 합니다.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""당신은 고객 지원 티켓 분류 시스템 역할을 할 것입니다. 
        ...
        ... 추론은 <reasoning> 태그로, 의도는 <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에 보냅니다.
  • 응답에서 추출된 모델의 reasoningintent를 반환합니다.
파싱하기 전에 전체 추론과 의도 텍스트가 생성될 때까지 기다려야 하므로 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-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    classification_prompt = f"""당신은 고객 지원 티켓 분류 시스템 역할을 할 것입니다. 
        ...
        ...추론은 <reasoning> 태그로, 의도는 <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_intentclassify_support_request 메서드에 추가하고 Claude의 의도 분류가 골든 의도 분류와 일치하는지 평가하기 위한 비교를 설정했습니다.
  • 사용된 입력 및 출력 토큰을 기반으로 비용을 계산하기 위해 API 호출에 대한 사용 통계를 추출했습니다.

평가 실행

적절한 평가에는 좋은 결과가 무엇인지 결정하기 위한 명확한 임계값과 벤치마크가 필요합니다. 위 스크립트는 정확도, 응답 시간, 분류당 비용에 대한 런타임 값을 제공하지만 여전히 명확하게 설정된 임계값이 필요합니다. 예를 들어:
  • 정확도: 95% (100개 테스트 중)
  • 분류당 비용: 현재 라우팅 방법에서 평균 50% 감소 (100개 테스트에서)
이러한 임계값을 갖는 것은 대규모로, 그리고 공정한 경험주의로 어떤 방법이 가장 좋은지, 요구사항에 더 잘 맞추기 위해 어떤 변경이 필요할 수 있는지 빠르고 쉽게 알 수 있게 해줍니다.

성능 향상

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

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

클래스 수가 증가함에 따라 필요한 예제 수도 확장되어 프롬프트가 다루기 어려워질 수 있습니다. 대안으로 분류기의 혼합을 사용하여 계층적 분류 시스템을 구현하는 것을 고려할 수 있습니다.
  1. 의도를 분류학적 트리 구조로 구성합니다.
  2. 트리의 모든 수준에서 일련의 분류기를 만들어 계단식 라우팅 접근법을 가능하게 합니다.
예를 들어, 티켓을 “기술적 문제”, “청구 질문”, “일반 문의”로 광범위하게 분류하는 최상위 분류기가 있을 수 있습니다. 이러한 각 카테고리는 분류를 더욱 세분화하기 위한 자체 하위 분류기를 가질 수 있습니다.
  • 장점 - 더 큰 뉘앙스와 정확도: 각 부모 경로에 대해 다른 프롬프트를 만들 수 있어 더 대상화되고 맥락별 분류가 가능합니다. 이는 향상된 정확도와 고객 요청의 더 세밀한 처리로 이어질 수 있습니다.
  • 단점 - 증가된 지연시간: 여러 분류기가 지연시간 증가로 이어질 수 있으므로 가장 빠른 모델인 Haiku로 이 접근법을 구현하는 것을 권장합니다.

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

예제 제공이 성능을 향상시키는 가장 효과적인 방법임에도 불구하고, 지원 요청이 매우 가변적이라면 단일 프롬프트에 충분한 예제를 포함하기 어려울 수 있습니다. 이 시나리오에서는 벡터 데이터베이스를 사용하여 예제 데이터셋에서 유사성 검색을 수행하고 주어진 쿼리에 대해 가장 관련성이 높은 예제를 검색할 수 있습니다. 분류 레시피에서 자세히 설명된 이 접근법은 성능을 71% 정확도에서 93% 정확도로 향상시키는 것으로 나타났습니다.

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

다음은 Claude가 티켓을 잘못 분류할 수 있는 시나리오입니다(상황에 따라 고유한 다른 시나리오가 있을 수 있음). 이러한 시나리오에서는 Claude가 엣지 케이스를 처리하는 방법에 대한 명시적인 지침이나 예제를 프롬프트에 제공하는 것을 고려하세요:
고객은 종종 간접적으로 요구사항을 표현합니다. 예를 들어, “패키지를 2주 넘게 기다리고 있습니다”는 주문 상태에 대한 간접적인 요청일 수 있습니다.
  • 해결책: Claude에게 이러한 종류의 요청에 대한 실제 고객 예제와 기본 의도가 무엇인지 제공하세요. 특히 미묘한 티켓 의도에 대한 분류 근거를 포함하면 Claude가 다른 티켓에 논리를 더 잘 일반화할 수 있어 더 나은 결과를 얻을 수 있습니다.
고객이 불만을 표현할 때 Claude는 기본 문제를 해결하는 것보다 감정을 다루는 것을 우선시할 수 있습니다.
  • 해결책: 고객 감정을 우선시할 때와 그렇지 않을 때에 대한 지침을 Claude에게 제공하세요. “모든 고객 감정을 무시하세요. 고객 요청의 의도와 고객이 요청할 수 있는 정보를 분석하는 데만 집중하세요.”와 같이 간단할 수 있습니다.
고객이 단일 상호작용에서 여러 문제를 제시할 때 Claude는 주요 관심사를 식별하는 데 어려움을 겪을 수 있습니다.
  • 해결책: Claude가 추출된 의도를 더 잘 순위를 매기고 주요 관심사를 식별할 수 있도록 의도의 우선순위를 명확히 하세요.

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

적절한 통합을 위해서는 Claude 기반 티켓 라우팅 스크립트가 더 큰 티켓 라우팅 시스템의 아키텍처에 어떻게 맞는지에 대한 결정을 내려야 합니다. 이를 수행할 수 있는 두 가지 방법이 있습니다:
  • 푸시 기반: 사용 중인 지원 티켓 시스템(예: Zendesk)이 라우팅 서비스에 웹훅 이벤트를 보내 코드를 트리거하고, 이후 의도를 분류하고 라우팅합니다.
    • 이 접근법은 더 웹 확장 가능하지만 공개 엔드포인트를 노출해야 합니다.
  • 풀 기반: 코드가 주어진 일정에 따라 최신 티켓을 풀하고 풀 시점에 라우팅합니다.
    • 이 접근법은 구현하기 더 쉽지만 풀 빈도가 너무 높을 때 지원 티켓 시스템에 불필요한 호출을 하거나 풀 빈도가 너무 낮을 때 지나치게 느릴 수 있습니다.
이러한 접근법 중 하나에 대해 스크립트를 서비스로 래핑해야 합니다. 접근법의 선택은 지원 티켓팅 시스템이 제공하는 API에 따라 달라집니다.