Claude 일반 사용 사례 가이드: 작업 지시서 할당

이 가이드에서는 Claude의 고급 자연어 이해 기능을 활용하여 고객의 의도, 긴급성, 우선순위, 고객 프로필 등의 요소를 기반으로 고객 지원 작업 주문을 대규모로 분류하는 방법에 대해 설명합니다.

작업 지시 할당에 Claude를 사용할지 여부를 정의하세요.

다음은 분류 작업에 기존 머신 러닝 방법 대신 클로드와 같은 LLM(대규모 언어 모델)을 사용해야 함을 나타내는 몇 가지 주요 지표입니다:

사용 가능한 주석 학습 데이터가 제한되어 있습니다.

기존의 머신러닝 프로세스에는 대규모 주석이 달린 데이터 세트가 필요하지만, Claude의 사전 학습된 모델은 수십 개의 주석이 달린 예제만으로 작업 주문을 효율적으로 분류하여 데이터 준비에 드는 시간과 비용을 크게 줄일 수 있습니다.

분류 카테고리는 시간이 지남에 따라 변경되거나 발전할 수 있습니다.

기존의 머신러닝 방법은 한 번 설정되면 수정하는 데 많은 시간과 데이터가 소요될 수 있습니다. 반면, Claude는 제품이나 고객의 요구 사항이 변경되면 학습 데이터의 라벨을 광범위하게 다시 지정하지 않고도 카테고리 정의의 변경이나 새로운 카테고리에 쉽게 적응할 수 있습니다.

복잡한 비정형 텍스트 입력을 처리해야 하는 경우

기존의 머신 러닝 모델은 종종 비정형 데이터에 어려움을 겪고 광범위한 기능 엔지니어링이 필요하지만, Claude의 고급 언어 이해는 엄격한 온톨로지 구조에 의존하지 않고도 콘텐츠와 컨텍스트를 기반으로 정확한 분류를 가능하게 합니다.

분류 규칙은 의미론적 이해를 기반으로 합니다.

기존의 머신러닝 방식은 단어 집합 모델이나 단순한 패턴 매칭에 의존하는 경우가 많습니다. 예제가 아닌 조건으로 카테고리를 정의하는 경우, Claude는 이러한 기본 규칙을 이해하고 적용하는 데 탁월한 능력을 발휘합니다.

범주형 결정을 위해서는 해석 가능한 추론이 필요합니다.

기존의 많은 머신러닝 모델은 의사 결정 과정에 대한 인사이트를 거의 또는 전혀 제공하지 못하지만, claude는 분류 결정에 대해 사람이 읽을 수 있는 설명을 제공함으로써 자동화된 시스템에 대한 신뢰를 높이고 필요할 때 쉽게 적응할 수 있도록 합니다.

엣지 케이스와 모호한 작업 지시를 보다 효과적으로 처리하고 싶은 경우

기존의 머신러닝 시스템은 일반적으로 이상 징후와 모호한 입력을 처리할 때 성능이 저하되어 잘못 분류하거나 '포괄적' 범주에 할당하는 경우가 많습니다. Claude의 자연어 처리 기능을 사용하면 작업 지시 지원에서 문맥과 뉘앙스를 더 잘 해석하여 사람의 개입이 필요한 오분류 또는 미분류 작업 지시의 수를 잠재적으로 줄일 수 있습니다. 수동 개입이 필요한 잘못 분류되거나 분류되지 않은 작업 지시서의 수를 줄일 수 있습니다.

여러 모델을 유지 관리하지 않고도 다국어 지원을 제공해야 하는 경우

기존의 머신러닝 접근 방식은 일반적으로 지원되는 각 언어에 대해 별도의 모델을 유지하거나 광범위한 번역 프로세스를 수행해야 하지만, Claude의 다국어 기능을 사용하면 별도의 모델이나 광범위한 번역 프로세스 없이도 다양한 언어로 작업 주문을 분류할 수 있으므로 글로벌 고객 지원을 간소화할 수 있습니다.

워크플로우 지원을 위한 빅 언어 모델 구축 및 배포

현재 지원 방법 파악하기

자동화에 대해 자세히 알아보기 전에 먼저 기존 작업 지시 시스템을 이해하는 것이 중요합니다. 지원팀이 현재 작업 주문 라우팅을 어떻게 처리하고 있는지 조사하는 것부터 시작하세요.

다음과 같은 질문을 고려할 수 있습니다:

• 적용 가능한 SLA/서비스 플랜을 결정하는 데 어떤 기준이 사용되나요?
• 작업 주문 라우팅을 사용하여 작업 주문이 어떤 지원 수준 또는 제품 전문가에게 전달되어야 하는지 결정하나요?
• 자동화된 규칙이나 워크플로우가 이미 마련되어 있나요? 어떤 상황에서 실패하는가?
• 에지 케이스 또는 모호한 작업 지시는 어떻게 처리되나요?
• 팀은 작업 지시의 우선순위를 어떻게 정하나요?

사람들이 주어진 상황에 어떻게 대처하는지에 대해 더 많이 알수록, 더 잘 소통할 수 있습니다. Claude 작업 공동 작업.

사용자 의도 카테고리 정의

잘 정의된 사용자 의도 카테고리 목록은 Claude를 사용하여 지원 작업 주문을 정확하게 분류하는 데 매우 중요하며, 시스템 내에서 작업 주문을 효과적으로 라우팅하는 Claude의 기능은 시스템 내 카테고리 정의의 명확성과 직접적으로 관련이 있습니다.

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

기술적 문제

• 하드웨어 문제
• 소프트웨어 취약성
• 호환성 문제
• 성능 문제

계정 관리

• 비밀번호 재설정
• 계정 액세스 문제
• 청구 문의
• 구독 변경

제품 정보

• 기능 문의
• 제품 호환성 문제
• 가격 정보
• 가용성 쿼리

사용자 가이드

• 운영 가이드
• 기능 도움말
• 모범 사례 권장 사항
• 문제 해결 가이드

정보 다시 보내기

• 취약점 보고
• 기능 요청
• 일반적인 피드백 또는 제안
• 불평하다 .

주문 관련

• 주문 상태 조회
• 물류 정보
• 다른 품목을 위해 제품 반품
• 주문 수정

서비스 요청

• 설치 지원
• 에스컬레이션 요청
• 유지 관리 프로그램
• 서비스 취소

보안 문제

• 데이터 개인 정보 보호 문의
• 의심스러운 활동 보고서
• 안전 기능 도움말

규정 준수 및 법률

• 규정 준수 문제
• 서비스 약관 문의
• 법률 문서 요청

긴급 지원

• 중요 시스템 장애
• 긴급 보안 문제
• 시간에 민감한 문제

교육 및 훈련

• 제품 교육 요청
• 문서 검색
• 웨비나 또는 워크샵 정보

통합 및 API

• 통합 지원
• API 사용 문제
• 타사 호환성 확인

사용자 의도 외에도 긴급성, 고객 유형, SLA 또는 언어 등의 다른 요인에 의해 작업 주문 라우팅 및 우선 순위가 영향을 받을 수 있습니다. 자동 라우팅 시스템을 구축할 때는 다른 라우팅 기준도 반드시 고려하세요.

성공 기준 설정

지원팀과 협력하여 측정 가능한 벤치마크, 임계값 및 목표를 사용하세요.명확한 성공 기준 정의.

다음은 작업 지시 할당에 LLM(대규모 언어 모델)을 사용할 때의 일반적인 표준 및 벤치마크입니다:

분류 일관성

이 메트릭은 시간 경과에 따른 Claude의 유사한 작업 주문 분류의 일관성을 평가합니다. 이는 작업 할당에 대한 신뢰성을 유지하는 데 매우 중요합니다. 표준화된 입력 테스트 모델 세트를 정기적으로 사용하여 95% 이상의 일관성을 목표로 합니다.

적응 속도

이 메트릭은 Claude가 새로운 카테고리나 변화하는 작업 지시 패턴에 얼마나 빨리 적응하는지를 측정합니다. 이는 새로운 작업 지시 유형을 도입하고 모델이 이러한 새로운 범주에서 만족할 만한 정확도(예: 90% 이상)를 달성하는 데 걸리는 시간을 측정하여 수행됩니다. 목표는 50~100개의 샘플 작업 지시서 내에서 적응을 달성하는 것입니다.

다국어 처리

이 메트릭은 다국어 작업 지시를 정확하게 할당하는 Claude의 능력을 평가합니다. 비주류 언어에서 정확도가 5-10% 이상 떨어지지 않는 것을 목표로 다양한 언어의 할당 정확도를 측정합니다.

엣지 케이스 처리

이 메트릭은 흔하지 않거나 복잡한 작업 주문을 처리할 때 Claude의 성능을 평가합니다. 이러한 복잡한 입력에 대해 최소 801 TP3T의 할당 정확도를 달성하는 것을 목표로 에지 케이스의 테스트 세트가 생성됩니다.

편향성 약화

이 지표는 다양한 고객 그룹에 대한 Claude의 할당 공정성을 측정합니다. 할당 결정은 모든 고객 그룹에 걸쳐 일관된 할당 정확도(2~3% 이내)를 목표로 잠재적인 편향성을 정기적으로 검토합니다.

큐 효율성

이 기준은 적은 수의 토큰이 필요한 최소한의 컨텍스트 조건에서 클로드의 성능을 평가합니다. 작업 지시 제목과 간단한 설명만 제공될 때 90% 이상의 정확도를 달성하는 것을 목표로 다양한 양의 컨텍스트가 제공될 때 과제의 정확도를 측정합니다.

해석 가능성 점수

이 지표는 할당 결정에 대한 클로드의 설명의 품질과 관련성을 평가합니다. 인간 평가자는 평균 평점 4점 이상을 목표로 설명에 점수를 매길 수 있습니다(예: 1~5점).

다음은 대규모 언어 모델을 사용하는지 여부에 관계없이 공통적으로 적용되는 몇 가지 일반적인 성공 기준입니다:

배포 정확도

할당 정확도는 작업 주문이 처음에 올바른 팀이나 개인에게 올바르게 할당되었는지 여부를 측정합니다. 일반적으로 올바르게 할당된 전체 작업 주문의 백분율로 측정됩니다. 업계 벤치마크는 일반적으로 90-95%의 정확도를 목표로 하지만 이는 지원 구조의 복잡성에 따라 달라집니다.

슬롯

이 메트릭은 작업 주문이 제출된 후 얼마나 빨리 할당되는지를 추적합니다. 할당 시간이 빠르면 일반적으로 더 빠른 해결과 더 높은 고객 만족도로 이어집니다. 최적의 시스템의 평균 할당 시간은 일반적으로 5분 미만이며, 많은 시스템이 거의 즉각적인 할당을 목표로 하고 있습니다(LLM 사용 시 가능).

재배포율

재할당률은 작업 오더가 최초 할당된 후 얼마나 자주 재할당되어야 하는지를 나타냅니다. 재할당률이 낮을수록 초기 할당이 더 정확하다는 것을 의미합니다. 목표는 재할당률을 101 TP3T 이하로 유지하는 것이며, 최고 성능의 시스템은 51 TP3T 이하를 달성합니다.

첫 번째 연락처 해결률

이 메트릭은 첫 번째 고객 상호작용에서 해결된 작업 주문의 비율을 측정합니다. 첫 번째 해결 비율이 높을수록 효율적인 업무 할당과 잘 준비된 지원 팀을 의미합니다. 업계 벤치마크는 일반적으로 70~751 TP3T이며, 최고 성과를 내는 팀은 801 TP3T 이상의 첫 번째 해결률을 달성합니다.

평균 처리 시간

평균 처리 시간은 작업 주문을 처음부터 끝까지 해결하는 데 걸리는 시간을 측정합니다. 효과적인 할당으로 이 시간을 크게 줄일 수 있습니다. 벤치마크는 업종과 복잡성에 따라 다르지만 많은 조직에서 긴급하지 않은 이슈의 평균 처리 시간을 24시간 미만으로 유지하는 것을 목표로 합니다.

고객 만족도 평가

종종 사후 상호작용 설문조사를 통해 측정되는 이러한 평가는 지원 프로세스에 대한 고객의 전반적인 만족도를 반영합니다. 효과적인 배포가 만족도에 기여합니다. 목표는 고객 만족도 평점(CSAT) 901점 이상을 달성하는 것이며, 가장 우수한 성과를 내는 팀은 951점 이상의 만족도를 달성합니다.

프로모션 비율

이 지표는 작업 지시를 더 높은 수준의 지원팀으로 에스컬레이션해야 하는 빈도를 측정합니다. 에스컬레이션 비율이 낮을수록 일반적으로 초기 배정이 더 정확하다는 것을 나타냅니다. 에스컬레이션 비율을 20% 이하로 유지하는 것이 목표이며, 최적의 시스템은 10% 이하의 에스컬레이션 비율을 달성하는 것입니다.

직원 생산성

이 지표는 배포 솔루션을 구현한 후 지원 담당자가 효율적으로 처리할 수 있는 작업 주문의 수를 측정합니다. 배포가 개선되면 생산성이 향상됩니다. 직원당 하루 또는 시간당 해결된 작업 주문 수를 추적하여 측정하며, 새로운 배포 시스템을 구현한 후 생산성을 10~20% 향상하는 것을 목표로 합니다.

셀프 서비스 분류 비율

이 메트릭은 배포 시스템에 들어가기 전에 셀프 서비스 옵션을 통해 해결된 잠재적 작업 주문의 비율을 측정합니다. 분류율이 높을수록 효과적인 사전 배정 분류가 이루어지고 있음을 나타냅니다. 목표는 20-301 TP3T의 분류율을 달성하는 것이며, 가장 우수한 성과를 내는 팀은 401 TP3T 이상을 달성합니다.

작업 주문당 비용

이 메트릭은 각 지원 작업 주문을 해결하는 데 드는 평균 비용을 계산합니다. 효율적인 배포는 시간이 지남에 따라 비용을 절감하는 데 도움이 됩니다. 벤치마크는 매우 다양하지만 많은 조직이 개선된 배포 시스템을 구현한 후 작업 주문당 비용을 10~151 TP3T 절감하는 것을 목표로 합니다.

적합한 Claude 모델 선택

모델 선택은 비용, 정확성, 응답 시간 간의 균형에 따라 달라집니다.

많은 고객이 claude-3-haiku-20240307 Claude 3 제품군 중 가장 빠르고 비용 효율적이면서도 뛰어난 결과를 제공하는 모델이기 때문에 작업 주문 라우팅 처리에 이상적입니다. 분류 문제에 고도의 전문 지식이 필요하거나 복잡한 의도적 범주 추론이 필요한 경우에는 더 큰 소네트 모델.

강력한 팁 구축

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

작업 주문 분류를 위한 프롬프트를 작성해 보겠습니다. 초기 프롬프트에는 사용자 요청의 내용이 포함되어야 하며 추론 과정과 의도를 반환해야 합니다.

다음을 시도해 볼 수 있습니다. 인간형 콘솔 업링크 팁 생성기 클로드가 첫 번째 버전의 프롬프트를 작성하도록 합니다.

다음은 작업 주문 라우팅 분류 프롬프트의 예입니다:

def classify_support_request(ticket_contents):
    # 为分类任务定义提示
    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>我想写信感谢你们在上周末我父亲的葬礼上对我家人的关怀。你们的员工非常体贴和乐于助人，这让我们肩上的负担减轻了不少。悼念手册非常漂亮。我们永远不会忘记你们对我们的关爱，我们非常感激整个过程的顺利进行。再次感谢你们，Amarantha Hill 代表 Hill 家庭。</request>

        示例 2 输出：
        <reasoning>用户留下了他们对体验的正面评价。</reasoning>
        <intent>支持、反馈、投诉</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        示例 9 输入：
        <request>你们的网站一直弹出广告窗口，挡住了整个屏幕。我花了二十分钟才找到电话投诉的号码。我怎么可能在这些弹出窗口的干扰下访问我的账户信息？你能帮我访问我的账户吗，因为你们的网站有问题？我需要知道在档的地址。</request>

        示例 9 输出：
        <reasoning>用户请求帮助以访问其网络账户信息。</reasoning>
        <intent>支持、反馈、投诉</intent>
        </example 9>

        请记住，始终在实际意图输出之前包括分类推理。推理应包含在 <reasoning> 标签内，意图应包含在 <intent> 标签内。仅返回推理和意图。
        """

이 팁의 핵심 부분을 자세히 살펴보겠습니다:

• Python의 f- 문자열을 사용하여 다음을 포함할 수 있는 힌트 템플릿을 만듭니다. ticket_contents 에 삽입 <request> 태그가 지정되었습니다.
• 우리는 작업 지시서의 내용을 면밀히 분석하여 고객의 핵심 의도와 요구 사항을 파악하는 분류 시스템으로 Claude의 역할을 명확히 정의했습니다.
• Claude에게 올바른 출력 형식에 대해 안내했습니다. <reasoning> 추론 및 분석은 태그 내에서 제공되고 이후에는 <intent> 태그 내에 적절한 카테고리 태그를 출력합니다.
• "지원, 피드백, 불만", "주문 추적", "환불/교환" 등 유효한 의도 카테고리가 지정되어 있습니다.
• 정확성과 일관성을 향상시키는 데 도움이 되는 출력 형식 지정 방법을 설명하기 위해 몇 가지 예시(예: 몇 가지 촬영 팁)가 제공됩니다.

정규식을 사용하여 추론과 의도를 개별적으로 추출할 수 있도록 Claude가 응답을 별도의 XML 태그 섹션으로 분할하기를 원합니다. 이렇게 하면 작업 지시 라우팅 워크플로우에서 작업 지시 라우팅 대상자를 결정하는 의도만 사용하여 타겟팅된 후속 단계를 만들 수 있습니다(예: 작업 지시 라우팅 대상자 결정).

단서 단어 배포

테스트 프로덕션 환경에 배포되지 않았고 운영 평가를 사용하면 큐워드가 얼마나 효과적인지 알기 어렵습니다.

배포 구조를 구축해 보겠습니다. 먼저 Claude에 대한 호출을 래핑할 메서드 서명을 정의합니다. 이미 작성하기 시작한 메서드를 사용하겠습니다. ticket_contents 를 입력으로 반환하고, 이제 reasoning 노래로 응답 intent 튜플을 출력으로 사용합니다. 기존 머신 러닝을 사용하는 자동화 방법이 이미 있는 경우 해당 방법의 시그니처를 따르는 것이 좋습니다.

import anthropic
import re

# 创建一个 Anthropic API 客户端实例
client = anthropic.Anthropic()

# 设置默认模型
DEFAULT_MODEL="claude-3-haiku-20240307"

def classify_support_request(ticket_contents):
    # 为分类任务定义提示词
    classification_prompt = f"""你将作为客户支持工单的分类系统。
        ...
        ... 推理结果应包含在 <reasoning> 标签中，意图应包含在 <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

이 코드:

• Anthropic 라이브러리를 가져오고 API 키를 사용하여 클라이언트 인스턴스를 생성했습니다.
• 를 정의합니다. classify_support_request 함수를 취하는 ticket_contents 문자열.
• 활용 classification_prompt 최고 사령관(군) ticket_contents 분류를 위해 클로드에게 보냅니다.
• 의 응답에서 추출한 모델을 반환합니다. reasoning 노래로 응답 intent.

구문 분석 전에 전체 추론과 인텐트 텍스트 생성을 기다려야 하므로 다음과 같습니다. stream=False 기본값으로 설정합니다.

팁 평가하기

큐 단어를 사용하려면 일반적으로 프로덕션 준비 상태에 도달하기 위해 테스트와 최적화가 필요합니다. 솔루션이 준비되었는지 확인하려면 이전에 설정한 성공 기준과 임계값에 따라 성능을 평가하세요.

평가를 실행하려면 평가를 실행할 테스트 케이스가 있어야 합니다. 이 문서에서는 다음이 있다고 가정합니다.테스트 사례 개발.

평가 함수 구축하기

이 가이드의 샘플 평가에서는 세 가지 주요 지표를 통해 Claude의 성과를 측정합니다:

• 정확성
• 분류당 비용

중요한 것이 무엇인지에 따라 다른 차원에서 클로드에 대한 평가가 필요할 수도 있습니다.

평가를 수행하기 위해서는 먼저 예측된 의도와 실제 의도를 비교하여 정확한 예측 비율을 계산하는 함수를 추가하여 이전 스크립트를 수정해야 합니다. 또한 비용 및 시간 측정 함수도 추가해야 합니다.

import anthropic
import re

# 创建 Anthropic API 客户端的实例
client = anthropic.Anthropic()

# 设置默认模型
DEFAULT_MODEL="claude-3-haiku-20240307"

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  # 获取 API 调用的使用统计信息，包括输入和输出 Token 数量。
    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()

    # 返回推理结果、意图、正确性和使用情况。
    return reasoning, intent, correct, usage

코드에 적용된 변경 사항은 다음과 같습니다:

• 우리는 할 것입니다 actual_intent 테스트 케이스에서 classify_support_request 방법론과 비교 메커니즘을 설정하여 클로드의 의도 분류가 우리의 황금 의도 분류와 일치하는지 평가했습니다.
• 입력 및 출력 토큰 사용량을 기반으로 비용을 계산하기 위해 API 호출에 대한 사용 통계를 추출했습니다.

평가 실행

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

• 정확성: 95%(100회 테스트)
• 분류당 비용: 기존 라우팅 방법 대비 평균 50%(100회 테스트) 감소

이러한 임계값을 설정하면 어떤 접근 방식이 가장 적합한지 규모에 따라 빠르고 쉽게 판단할 수 있으며, 편견 없는 경험적 데이터를 통해 요구 사항을 더 잘 충족하기 위해 어떤 개선이 필요한지 명확히 알 수 있습니다.

성능 향상

복잡한 시나리오에서는 표준을 넘어서는 방법을 고려하세요. 신속한 엔지니어링 기술 노래로 응답 가드레일 구현 전략 의 추가 전략이 도움이 될 수 있습니다. 다음은 몇 가지 일반적인 시나리오입니다:

20개 이상의 인텐트 카테고리의 경우 분류 계층 구조를 사용합니다.

카테고리의 수가 늘어나면 필요한 예시 수도 늘어나 프롬프트가 다루기 힘들어질 수 있습니다. 대안으로 하이브리드 분류기를 사용하여 계층적 분류 시스템을 구현하는 것을 고려해 볼 수 있습니다.

1. 의도를 분류 트리 구조로 정리하세요.
2. 트리의 각 레벨에 일련의 분류자를 생성하여 캐스케이드 라우팅 방법을 활성화합니다.

예를 들어 작업 주문을 '기술 문제', '청구 문제' 및 '일반 문의'로 크게 분류하는 최상위 분류자가 있을 수 있습니다. 이러한 각 카테고리에는 분류를 더욱 세분화하기 위해 자체 하위 분류자가 있을 수 있습니다.

• 장점 - 뉘앙스와 정확성이 향상됩니다: 각 상위 경로에 대해 서로 다른 프롬프트를 생성하여 보다 타겟팅되고 상황에 맞는 분류를 할 수 있습니다. 이를 통해 정확도가 향상되고 고객 요청을 보다 세밀하게 처리할 수 있습니다.
• 단점 - 지연 시간 증가: 분류기를 여러 개 사용하면 지연 시간이 늘어날 수 있으므로 가장 빠른 모델인 하이쿠를 사용할 때 이 방법을 구현하는 것이 좋습니다.

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

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

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

이 방법론은 분류 레시피 의 정확도가 71%에서 93%로 향상되는 것으로 나타났습니다.

예상되는 엣지 케이스에 대한 특별 고려 사항

다음은 Claude가 작업 주문을 잘못 분류할 수 있는 몇 가지 시나리오입니다(상황에 따라 다른 상황이 있을 수 있음). 이러한 시나리오에서는 클로드가 에지 케이스를 처리하는 방법에 대한 명확한 지침이나 예시를 프롬프트에 제공하는 것이 좋습니다:

클라이언트의 암시적 요청

고객은 종종 간접적으로 요구 사항을 표현합니다. 예를 들어 "2주 이상 소포를 기다리고 있습니다"는 주문 상태에 대한 간접적인 요청일 수 있습니다.

• 솔루션: Claude에게 그러한 요청의 실제 고객 사례와 그 근본적인 의도를 제공하세요. 작업 지시 의도에 대한 미묘한 분류 근거를 포함하면 더 나은 결과를 얻을 수 있으므로 Claude가 다른 작업 지시에도 이 논리를 더 잘 일반화할 수 있습니다.

의도보다 감정을 우선시하는 클로드

고객이 불만을 표출하면 Claude는 근본적인 문제를 해결하기보다는 그 감정을 우선적으로 처리할 수 있습니다.

• 솔루션: 클로드에게 언제 고객 감정의 우선순위를 정할지 알려주세요. 예를 들어 "모든 고객 감정은 무시하세요. 고객 요청의 의도와 고객이 요청할 수 있는 정보를 분석하는 데만 집중하세요."와 같이 간단할 수도 있습니다.

여러 이슈로 인해 이슈 우선 순위 지정에 혼란을 초래하는 경우

고객이 한 번의 상호작용에서 여러 가지 질문을 할 때 Claude는 주요 관심사를 파악하는 데 어려움을 겪을 수 있습니다.

• 솔루션: 의도의 우선순위를 명확히 하여 Claude가 추출된 의도의 우선순위를 더 잘 정하고 주요 관심사를 식별할 수 있도록 합니다.

클라우드를 대규모 지원 워크플로우에 통합하기

적절한 통합을 위해서는 클로드 기반 작업 지시 라우팅 스크립트를 더 큰 작업 지시 라우팅 시스템 아키텍처에 어떻게 적용할지 몇 가지 결정을 내려야 합니다. 두 가지 방법 중 하나로 이 작업을 수행할 수 있습니다:

• 푸시 기반: 사용하는 지원 작업 주문 시스템(예: Zendesk)은 라우팅 서비스에 웹훅 이벤트를 전송하여 코드를 트리거한 다음 의도를 분류하고 라우팅합니다.
  • 이 접근 방식은 네트워크 확장성이 더 뛰어나지만 엔드포인트를 노출해야 합니다.
• 풀 기반: 코드는 주어진 일정에 따라 최신 작업 주문을 가져와서 가져오는 대로 라우팅합니다.
  • 이 방식은 구현하기는 쉽지만 너무 자주 가져올 경우 지원 작업 지시 시스템에 불필요한 호출이 발생하거나 너무 자주 가져올 경우 속도가 너무 느려질 수 있습니다.

두 방법 모두 스크립트를 서비스로 래핑해야 합니다. 어떤 방법을 선택할지는 지원 작업 주문 시스템이 어떤 API를 제공하는지에 따라 달라집니다.