本指南介绍了如何利用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在处理不常见或复杂工单时的表现。创建一组边缘案例的测试集,目标是在这些复杂输入中达到至少80%的分配准确率。
偏见减弱
该指标衡量Claude在不同客户群体中分配的公平性。定期审核分配决策是否存在潜在偏见,目标是在所有客户群体中保持一致的分配准确率(误差在2-3%以内)。
提示效率
在需要减少Token数量的情况下,该标准评估Claude在最少上下文条件下的表现。测量在提供不同量级上下文时的分配准确率,目标是在仅提供工单标题和简短描述的情况下达到90%以上的准确率。
可解释性评分
该指标评估Claude对其分配决策的解释质量和相关性。人工评分员可以对解释进行打分(例如,1-5分),目标是实现平均评分4分或以上。
以下是一些无论是否使用大语言模型都常见的成功标准:
分配准确率
分配准确率衡量工单第一次是否被正确分配到合适的团队或个人。通常以正确分配工单占总工单的百分比来衡量。行业基准通常目标为90-95%的准确率,但这取决于支持结构的复杂性。
分配时间
该指标跟踪工单提交后被分配的速度。更快的分配时间通常会导致更快的解决和更高的客户满意度。最优系统的平均分配时间通常在5分钟以内,许多系统的目标是接近即时分配(使用LLM时是可能的)。
重分配率
重分配率表示工单初次分配后需要重新分配的频率。较低的重分配率表明初次分配更准确。目标是将重分配率控制在10%以下,表现最好的系统可达到5%或更低。
首次联系解决率
该指标衡量在首次与客户交互时解决工单的百分比。较高的首次解决率表明分配效率高,支持团队准备充分。行业基准通常为70-75%,表现最佳的团队能达到80%以上的首次解决率。
平均处理时间
平均处理时间衡量从开始到结束解决工单所需的时间。有效的分配可以显著减少此时间。基准因行业和复杂性而异,但许多组织的目标是将非紧急问题的平均处理时间控制在24小时以内。
客户满意度评分
通常通过交互后的调查来衡量,这些评分反映客户对支持过程的整体满意度。有效的分配有助于提高满意度。目标是客户满意度(CSAT)达到90%以上,表现最好的团队能实现95%以上的满意率。
升级率
该指标衡量需要将工单升级到更高支持层次的频率。较低的升级率通常表明初次分配更准确。目标是将升级率控制在20%以下,最优系统的升级率可达到10%或更低。
员工生产力
该指标衡量在实施分配解决方案后,支持人员能够有效处理的工单数量。改进的分配应能提高生产力。通过跟踪每名员工每天或每小时解决的工单数量来衡量,目标是在实施新分配系统后提升10-20%的生产力。
自助服务分流率
该指标衡量通过自助服务选项在进入分配系统之前解决的潜在工单的百分比。较高的分流率表明预分配分流有效。目标是分流率达到20-30%,表现最好的团队能达到40%以上。
每工单成本
该指标计算解决每个支持工单的平均成本。高效的分配应有助于随着时间推移降低成本。尽管基准差异很大,但许多组织的目标是在实施改进后的分配系统后降低每工单成本10-15%。
选择合适的 Claude 模型
模型的选择取决于成本、准确性和响应时间之间的权衡。
许多客户发现 claude-3-haiku-20240307
是处理工单路由的理想模型,因为它是 Claude 3 系列中速度最快且性价比最高的模型,同时还能提供出色的结果。如果您的分类问题需要深度的专业知识或大量复杂的意图类别推理,您可以选择 更大的 Sonnet 模型。
构建一个强大的提示
工单路由是一种分类任务。Claude 分析支持工单的内容,并根据问题类型、紧急程度、所需专业知识或其他相关因素将其分类到预定义的类别中。
让我们来编写一个工单分类的提示。初始提示应包含用户请求的内容,并返回推理过程和意图。
您可以尝试在 Anthropic 控制台 上使用 提示生成器 来让 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-string 创建提示模板,允许将
ticket_contents
插入到<request>
标签中。 - 我们明确给 Claude 定义了一个角色,即作为一个分类系统,仔细分析工单内容以确定客户的核心意图和需求。
- 我们指导 Claude 正确的输出格式,在
<reasoning>
标签内提供推理和分析,随后在<intent>
标签内输出适当的分类标签。 - 我们指定了有效的意图类别:“支持、反馈、投诉”、“订单追踪”和“退款/换货”。
- 我们提供了一些示例(即 few-shot 提示)以说明输出应如何格式化,这有助于提高准确性和一致性。
我们希望 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
发送到 Claude 进行分类。 - 返回从响应中提取的模型的
reasoning
和intent
。
由于我们需要在解析之前等待完整的推理和意图文本生成,因此将 stream=False
设置为默认值。
评估你的提示
提示词的使用通常需要测试和优化,才能达到生产就绪状态。要判断你的解决方案是否准备就绪,需基于之前设定的成功标准和阈值来评估其表现。
要运行评估,你需要有测试用例来执行评估。本文假设你已经开发了你的测试用例。
构建评估函数
本指南的示例评估通过三个关键指标来衡量 Claude 的性能:
- 准确性
- 每次分类的成本
根据对你而言重要的因素,可能需要从其他维度评估 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
方法中,并设置了比较机制,以评估 Claude 的意图分类是否与我们的黄金意图分类一致。 - 我们提取了 API 调用的使用统计信息,以基于输入和输出的 Token 使用情况计算成本。
运行你的评估
一个完善的评估需要明确的阈值和基准来确定什么是好的结果。上面的脚本会为我们提供准确性、响应时间和每次分类成本的运行时值,但我们仍然需要清晰设定的阈值。例如:
- 准确性: 95%(100 次测试)
- 每次分类的成本: 平均降低 50%(100 次测试)相较于当前的路由方法
设定这些阈值让你能够快速且轻松地大规模判断哪个方法最适合你,并通过公正的实证数据,明确需要进行哪些改进以更好地满足你的要求。
提高性能
在复杂场景中,考虑超越标准的 prompt engineering techniques 和 guardrail implementation strategies 的额外策略可能会有所帮助。以下是一些常见场景:
对于有 20+ 个意图类别的情况,使用分类层级结构
随着类别数量的增加,所需示例的数量也会增加,这可能使得提示变得笨重。作为替代方案,您可以考虑使用混合分类器实现层次分类系统。
- 将您的意图组织成分类树结构。
- 在树的每个层级创建一系列分类器,启用级联路由方法。
例如,您可能有一个顶层分类器,将工单大致分类为“技术问题”、“账单问题”和“一般咨询”。这些类别每个都可以有自己的子分类器,以进一步细化分类。
- 优点 - 更大的细微差别和准确性: 您可以为每个父路径创建不同的提示,允许更有针对性和上下文特定的分类。这可以提高准确性并更细致地处理客户请求。
- 缺点 - 延迟增加: 请注意,多个分类器可能导致延迟增加,因此我们建议在使用我们最快的模型 Haiku 时实施此方法。
使用向量数据库和相似性搜索检索来处理高度可变的工单
尽管提供示例是提高性能的最有效方法,但如果支持请求高度可变,可能很难在单个提示中包含足够的示例。
在这种情况下,您可以利用向量数据库从示例数据集中进行相似性搜索,并检索与给定查询最相关的示例。
这一方法在我们的 classification recipe 中详细阐述,已被证明可以将性能从 71% 的准确率提高到 93% 的准确率。
特别考虑预期的边缘案例
以下是一些 Claude 可能错误分类工单的场景(可能还有其他情况是独特于您的情况)。在这些场景中,考虑在提示中提供明确的指示或示例,说明 Claude 应该如何处理边缘案例:
客户做出隐性请求
客户经常间接表达需求。例如,“我已经等了我的包裹超过两周了”可能是对订单状态的间接请求。
- 解决方案: 为 Claude 提供一些实际客户示例,说明这类请求及其潜在意图。如果您包括特别细致的工单意图的分类理由,您可以获得更好的结果,以便 Claude 更好地将逻辑推广到其他工单。
Claude 将情感优先于意图
当客户表达不满时,Claude 可能会优先处理情感而不是解决潜在问题。
- 解决方案: 为 Claude 提供关于何时优先考虑客户情绪的指示。这可以是一些简单的内容,例如“忽略所有客户情绪。仅关注分析客户请求的意图和客户可能在询问的信息。”
多个问题导致问题优先级混淆
当客户在一次互动中提出多个问题时,Claude 可能会难以识别主要关切。
- 解决方案: 明确意图的优先级,以便 Claude 能更好地对提取的意图进行排序,并识别主要关切。
将 Claude 集成到您的更大支持工作流程中
正确的集成要求您对基于 Claude 的工单路由脚本如何融入更大的工单路由系统架构做出一些决策。您可以采用以下两种方式:
- 推送式 (Push-based): 您使用的支持工单系统(例如 Zendesk)通过向您的路由服务发送 webhook 事件来触发您的代码,然后对意图进行分类并进行路由。
- 这种方法更具网络可扩展性,但需要您公开一个端点。
- 拉取式 (Pull-Based): 您的代码根据给定的时间表拉取最新的工单并在拉取时进行路由。
- 这种方法更容易实现,但如果拉取频率过高,可能会对支持工单系统发出不必要的调用;如果拉取频率过低,则可能会过于缓慢。
对于这两种方法,您都需要将您的脚本包装在一个服务中。选择哪种方法取决于您的支持工单系统提供哪些 API。