译者说明：本文译自 Anthropic 官方 Claude Cookbooks 的分类指南。原文以保险客服工单分类为例，含完整 Python 代码与评估框架；此处翻译全部说明性内容与方法。

原文中的问题定义、数据与标签均为合成生成，用于演示。

用 Claude 做分类

本指南会构建一套高准确率的分类系统，把保险客服工单分到 10 个类别里。你将学到如何把分类准确率从 70% 逐步提升到 95%+，方法是组合提示词工程、检索增强生成（RAG）与思维链推理。

读完之后，你会理解如何设计能处理复杂业务规则、在训练数据有限的情况下工作、并且结果可解释的分类系统。

为什么用大模型做分类

大模型彻底改变了分类这个领域，尤其是在传统机器学习系统吃力的地方。

大模型在两类分类问题上表现突出：

• 业务规则复杂的场景
• 训练数据质量差或数量少的场景

此外，大模型还能用自然语言解释和论证自己的判断，这提升了分类过程的可解释性与透明度。

借助这些能力，我们可以构建超出传统机器学习方法的分类系统——特别是在数据稀缺或业务要求错综复杂时。

四个关键步骤

1. 数据准备：准备训练数据与测试数据。训练数据用来构建分类模型，测试数据用来评估表现。恰当的数据准备对系统有效性至关重要。

2. 提示词工程：设计一个提示词模板，定义分类提示的结构与格式。模板会纳入用户的查询、类别定义，以及来自向量数据库的相关样例。通过精心设计提示词，我们可以引导模型给出准确且贴合上下文的分类。

3. 实现检索增强生成（RAG）：用向量数据库存储训练数据的嵌入并高效检索。向量数据库支持相似度搜索，让我们能为某个查询找到最相关的样例。用检索到的样例增强提示词，可以提供额外上下文并提高分类准确率。

4. 测试与评估：用测试数据严格检验系统表现。遍历测试查询、逐条分类、把预测类别与预期类别对比。通过分析结果，我们可以评估系统有效性并找出改进方向。

先建评估框架

在构建分类器之前，先搭好评估框架。两个关键函数：

一、evaluate(X, y, classifier, batch_size)——在所有测试样例上运行你的分类器（并发执行以提速），计算准确率指标，并生成混淆矩阵。

二、plot_confusion_matrix(cm, labels)——把混淆矩阵可视化，显示哪些类别之间容易混淆，帮你定位分类器在哪里吃力。

这套框架让我们能实证地比较不同方法，理解的不只是总体准确率，还有具体哪几个类别是难点。

基线：随机分类器

为了建立性能基线并验证评估框架本身没问题，先做一个随机分类器——每条工单随机挑一个类别。

这给出了性能的下界：任何真实的分类方法都应当显著优于随机猜测（10 个类别下随机大约是 10% 准确率）。这个基线帮我们量化「上下文工程到底带来了多少价值」。

结果如预期：混淆矩阵上的预测散布在所有类别里，没有任何有意义的模式。对角线（正确预测）每个类别只有 1–4 个，错误随机分布。

第一步：基础分类器（约 70%）

现在用 Claude 构建第一个真正的分类器。这个函数演示了三项关键的提示词工程技巧：

一、结构化的提示词模板

把类别定义和待分类的工单以清晰的 XML 格式提供，让 Claude 易于解析信息。

（用 XML 编码信息是一项通用的提示策略。）

二、用预填控制输出

让 assistant 的回复以 <category> 开头，并把 stop_sequences 设为 ["</category>"]，就能强制 Claude 只输出类别标签——没有解释，没有多余文字。

这让响应解析变得可靠且确定。

三、确定性分类

把 temperature 设为 0.0，确保相同输入得到一致的预测。这对分类任务至关重要。

结果

混淆矩阵出现了明显的对角线，多数类别准确率不错。

约 70% 的总体准确率显著优于随机猜测，但相似类别之间的混淆说明 Claude 需要更多上下文才能做出更细的区分。

第二步：加入 RAG（跃升到 94%）

为了解决混淆问题，我们引入检索增强生成——把训练数据中的相关样例提供给 Claude。

它的工作方式：

1. 嵌入训练样例：把全部 68 条训练工单转成向量嵌入
2. 语义搜索：对每条新工单，基于余弦相似度找出最相似的 5 条训练样例
3. 增强提示词：把这些相似样例放进分类提示词里，引导 Claude

这个方法对分类特别有效，原因有三：

• 相似的历史样例帮助 Claude 区分语义相近的类别
• 少样本学习无需微调即可提升准确率
• 检索是动态的——每个查询都拿到与它最相关的样例

具体做法是：检索出 5 条最相似的样例，用 <query> 和 <label> 标签把它们组织成 XML 格式的少样本示例，注入提示词，再让 Claude 分类新工单。

举个例子：如果测试工单提到「意外扣费」，检索出过去「账单争议」与「账单咨询」的样例，能帮助 Claude 理解两者之间的微妙差别。

结果

RAG 把准确率从约 70% 提升到了 94%。 混淆矩阵的对角线明显更强，多数类别达到了完美或接近完美的准确率。

剩下的少量错误说明：即便有了相关样例，某些边缘情况仍然模糊。这正是思维链能帮上忙的地方。

第三步：RAG + 思维链

思维链（Chain-of-Thought）提示是让 Claude 在做出分类判断之前先「想出声」。

这种显式的推理过程，让它能更仔细地梳理那些细微的区别。

译后附记：这对访谈编码意味着什么

原文讲的是客服工单，但**「把大量文本按一套既定框架归类」正是访谈编码、开放题编码、竞品动态归类的本质**。原文的三步路径可以直接搬过来。

对照着看

三条可直接用的

一、先人工编 20–30 份，那就是你的训练集。 不要一上来就让它编全部——先自己编一批，这批既是质量基准，也是给它看的样例。

二、temperature = 0 和预填输出，在对话框里的等价物是「只输出编码，不要解释」。 输出稳定、可解析，是批量处理的前提。

三、最有价值的产出不是准确率，是混淆矩阵。 它告诉你哪两个类目定义得不够清楚——那往往说明你的编码框架本身需要修，而不是模型的问题。

一个务实的简化版

没有向量数据库也能做。把「检索最相似的 5 条」换成「每次都带上覆盖各个类目的 10 条人工编码样例」——固定的少样本，虽然不如动态检索精准，但实现成本几乎为零，而且已经能拿到基础提示词拿不到的大部分收益。

以下是我们的编码框架：
<framework>
[逐条列出类目及其定义、包含什么、不包含什么]
</framework>

以下是已经人工编码过的样例：
<examples>
<query>[受访者原话]</query><label>[类目]</label>
<query>[受访者原话]</query><label>[类目]</label>
……覆盖每个类目至少一条，相近的类目各给一条
</examples>

请对下面这段发言编码。只输出类目名，不要解释。
无法归入任何类目的输出「未分类」，不要勉强归类。

<query>[待编码的发言]</query>

最后那句「不要勉强归类」很重要。 分类任务里最危险的不是分错，是把本来不属于任何类目的内容硬塞进一个类目——那会让你的分布统计失真，而且事后看不出来。