★ FEATURED ARTICLE 文本分类这件事做了这些年我最大的感受是真正卡住大多数人的从来不是模型选型而是标注数据。你手上有一堆文本要分门别类业务方催着要结果但标注团队排期要两周等标注完黄花菜都凉了。这种场景下Zero-Shot 分类就像一根救命稻草——不用训练直接拿大语言模型来分类听起来简直完美。但实际用下来你会发现它既有让人惊艳的时刻也有让你想砸键盘的瞬间。这篇文章就来聊聊 Zero-Shot 文本分类到底怎么玩、什么场景下能打、什么场景下会翻车以及怎么把它用得优雅一点。如果你正在做文本分类相关的项目不管你是刚接触大语言模型的新手还是已经用过一段时间的从业者这里面的踩坑经验和实操细节应该都能帮到你。1. 为什么 Zero-Shot 分类值得认真对待1.1 标注数据才是真正的瓶颈做过文本分类项目的人都清楚模型架构、超参数调优这些事说实话门槛已经越来越低了。开源模型一大把微调脚本网上一搜到处都是真正让你项目推不动的是标注数据。我拿一个实际场景举例。假设你要做一个工单自动分类系统需要把用户提交的工单分成账号问题支付问题功能异常咨询建议四大类。听起来很简单对吧但你真去标注的时候就会发现有些工单既涉及支付又涉及账号边界模糊有些工单写了一大段话核心诉求藏在第三句还有些工单本身就是情绪宣泄根本没法归类。标注一个人可能要花两三分钟一千条就是三四十个小时的工作量而且标注一致性还得另算。传统做法是先标注个几百条做训练集然后迭代优化。但问题是很多业务场景根本等不起这个周期。老板今天说要做分类明天就想看到效果你告诉他等我标两周数据这不现实。Zero-Shot 分类解决的正是这个冷启动问题。不需要任何标注数据直接给大语言模型一个分类指令它就能给你分出来。虽然效果不一定比微调模型好但它能让你在几个小时内就有一个可用的基线这个价值是巨大的。1.2 Zero-Shot 不是万能药但它是好的起点我得先把话说清楚Zero-Shot 分类不是要替代微调模型它更像是你项目初期的探路工具。它的核心价值体现在几个方面。第一快速验证可行性。你可以在半天之内跑通一个分类流程看看大语言模型对你这个领域的文本有没有基本的理解能力。如果 Zero-Shot 效果还行说明这个分类任务本身是合理的后续微调大概率能做得更好如果 Zero-Shot 完全不行那你得反思一下分类体系是不是有问题。第二帮你发现分类体系的设计缺陷。很多时候你以为自己想清楚了类别定义但让模型去分的时候你会发现大量样本卡在边界上。这些边界案例恰恰是你需要重点关注的它们会倒逼你去优化分类标准。第三在标注数据积累起来之前Zero-Shot 可以作为一个临时方案先上线虽然准确率可能只有百分之七八十但总比没有强。等标注数据够了再切换到微调模型。1.3 大语言模型带来的范式变化Zero-Shot 分类这个概念其实不新在 BERT 时代就有人尝试过用 NLI自然语言推理的方式做零样本分类。但那时候的效果说实话很一般基本只能做做 demo上不了生产。大语言模型改变了这个局面。原因很简单模型规模上去了预训练数据更丰富了指令跟随能力也更强了。你给 GPT 系列或者开源的大模型写一段分类指令它能理解你的意图并且按照你要求的格式输出结果。这在 BERT 时代是不可想象的。具体来说大语言模型做 Zero-Shot 分类有几个天然优势。一是对类别描述的理解能力更强你可以用自然语言详细描述每个类别的含义模型能抓住关键点。二是处理长文本的能力更好很多传统方法对长文本分类效果很差但大语言模型可以处理几千个 token 的输入。三是输出格式灵活你可以要求它输出 JSON、输出类别编号、输出置信度甚至让它解释分类理由。但优势归优势陷阱也不少。接下来的内容会逐一拆解。2. Zero-Shot 分类的核心思路与方案选型2.1 三种主流技术路线对比用大语言模型做 Zero-Shot 文本分类目前主要有三条技术路线各有各的适用场景。路线一直接提示分类Direct Prompting这是最直观的方式。你把待分类的文本和类别定义一起塞进提示词里让模型直接输出类别标签。比如请将以下文本分类到给定类别中。 类别说明 - 账号问题涉及登录、注册、密码重置、账号安全等 - 支付问题涉及付款、退款、账单、发票等 - 功能异常涉及产品功能报错、崩溃、无法使用等 - 咨询建议涉及产品咨询、功能建议、投诉反馈等 文本{待分类文本} 请直接输出类别名称这种方式实现简单适合类别数量少通常不超过 10 个、类别定义清晰的场景。缺点是模型可能输出不在你定义范围内的类别需要做后处理。路线二基于相似度的分类Embedding-based思路是把类别描述和待分类文本都转成向量然后计算相似度取相似度最高的类别。这种方式的优势是你不需要模型理解分类任务只需要它能把语义相近的文本映射到相近的向量空间。具体操作是先把每个类别的描述文本比如用户无法登录账号的问题通过 Embedding 模型转成向量再把待分类文本也转成向量然后算余弦相似度。这种方式对模型的要求低一些甚至不需要大语言模型用普通的句向量模型就能做。但它的局限也很明显类别描述的质量直接决定分类效果而且对于语义复杂的文本简单的向量相似度可能抓不住关键信息。路线三自然语言推理式分类NLI-based这种方式把分类问题转化成推理问题。对于每个类别构造一个假设句比如这段文本描述的是账号问题然后让模型判断给定文本是否能推出这个假设。取推理概率最高的类别作为结果。这种方式在 BERT 时代比较流行因为 NLI 任务和分类任务在形式上比较接近。但在大语言模型时代直接用提示词分类的效果往往更好所以 NLI 式分类用得少了。我把三种路线的关键指标整理成了一张表方便你对比选择对比维度直接提示分类基于相似度分类NLI式分类实现难度低中中高类别数量适应性适合少量类别适合中等类别适合中等类别对模型要求需要指令跟随能力只需Embedding能力需要NLI能力分类精度较高中等中等推理速度较慢快中等可解释性强可要求解释弱中等适合场景快速验证、类别少大规模、类别固定研究探索2.2 为什么我推荐从直接提示分类入手三条路线里我最推荐的起步方式是直接提示分类。原因有三。第一它最接近人类的分类思维。你想想自己是怎么分类的看到一段文本对照类别定义判断它属于哪一类。直接提示分类就是把这个过程交给了模型逻辑上最自然。第二调试方便。分类效果不好的时候你可以直接修改提示词增加类别描述的细节调整输出格式马上就能看到效果变化。相比之下Embedding 方式调起来就麻烦得多你得反复调整类别描述的措辞而且效果变化不那么直观。第三大语言模型的指令跟随能力已经足够强了。只要你的类别定义不是特别模糊模型基本能理解你的意图。我试过用直接提示分类处理十几个类别的场景效果也能接受。当然直接提示分类也有它的代价每次分类都要调用一次大语言模型成本比 Embedding 方式高不少。如果你的数据量很大比如每天几十万条那 Embedding 方式可能更划算。但对于大多数中小规模场景直接提示分类的性价比是最高的。2.3 提示词设计的核心要素直接提示分类的效果八成取决于提示词写得好不好。我总结了一个好的分类提示词应该包含的五个要素。要素一明确的角色设定。告诉模型它是什么角色比如你是一个专业的客服工单分类助手。角色设定能帮助模型进入状态输出更符合预期的结果。要素二清晰的类别定义。每个类别都要有名称和描述描述要具体最好包含正例和反例。比如账号问题涉及登录失败、注册异常、密码重置、账号被盗等。注意如果问题同时涉及账号和支付优先归为支付问题。要素三边界处理规则。这是最容易被忽略但最重要的部分。多分类任务一定有边界模糊的情况你需要在提示词里明确告诉模型怎么处理。比如如果文本涉及多个类别选择最主要的那一个如果无法确定类别输出其他。要素四输出格式约束。明确告诉模型输出什么格式。最简单的就是只输出类别名称复杂一点可以要求输出 JSON包含类别和置信度。格式约束越明确后处理越简单。要素五少样本示例可选但推荐。虽然叫 Zero-Shot但加一两个示例往往能显著提升效果。这严格来说算 Few-Shot但在实际工程中只要标注成本低加几个示例是很划算的。3. 实操过程与核心环节实现3.1 环境准备与基础调用先说一下基础环境。我用的是 Python需要安装大语言模型的 SDK。这里以 OpenAI 风格的接口为例如果你用的是其他模型服务接口大同小异。pip install openai基础调用代码大概长这样from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-base-url ) def zero_shot_classify(text, categories): category_desc \n.join([ f- {name}{desc} for name, desc in categories.items() ]) prompt f你是一个专业的文本分类助手。请将以下文本分类到给定类别中。 类别说明 {category_desc} 文本 {text} 要求 1. 只输出类别名称不要输出其他内容 2. 如果无法确定类别输出其他 类别名称 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: prompt} ], temperature0 ) return response.choices[0].message.content.strip()这段代码有几个关键点需要说明。temperature0是必须的。分类任务需要确定性输出温度调高会让模型产生随机性同一段文本可能分到不同类别。设成 0 能让输出尽可能稳定。提示词的最后一句类别名称很重要。它相当于给模型一个填空的暗示引导它直接输出类别名而不是输出一段解释。我试过不加这句模型有时候会输出这段文本属于账号问题类别这样的完整句子后处理还得额外做提取。类别描述用字典传入方便后续维护。每个类别的描述要尽量具体不要只写类别名。比如不要只写账号问题要写账号问题涉及登录、注册、密码、账号安全等相关问题。3.2 提示词模板的迭代优化上面那个基础版本能跑但效果不一定好。我拿一个实际案例来演示提示词是怎么一步步优化的。假设我们要分类电商平台的用户评论类别有物流相关、商品质量、客服服务、价格相关。第一版提示词最简版请将以下评论分类到物流相关、商品质量、客服服务、价格相关。 评论{text} 类别跑下来发现几个问题。一是快递太慢了但是东西还不错这种评论模型有时候分到物流有时候分到商品质量不稳定。二是有些评论模型会输出物流相关和商品质量都涉及不符合格式要求。三是性价比很高这种评论模型有时候分到价格相关有时候分到商品质量。第二版提示词增加类别描述和边界规则你是一个电商评论分类助手。请将用户评论分类到以下类别之一。 类别说明 - 物流相关涉及快递速度、配送服务、包装完好度等 - 商品质量涉及商品本身的品质、材质、做工、与描述是否相符等 - 客服服务涉及客服态度、响应速度、售后处理等 - 价格相关涉及价格高低、性价比、优惠活动等 分类规则 1. 只选择一个最主要的类别 2. 如果评论同时涉及多个方面选择用户情绪最强烈的那个 3. 如果无法判断选择其他 评论{text} 类别名称这一版效果明显好了。边界规则起了很大作用模型知道怎么处理多类别混杂的情况了。但还有一个问题有些评论非常短比如还行模型会输出其他但实际上这种评论可能确实没有明确类别输出其他是合理的。第三版提示词增加少样本示例你是一个电商评论分类助手。请将用户评论分类到以下类别之一。 类别说明 - 物流相关涉及快递速度、配送服务、包装完好度等 - 商品质量涉及商品本身的品质、材质、做工、与描述是否相符等 - 客服服务涉及客服态度、响应速度、售后处理等 - 价格相关涉及价格高低、性价比、优惠活动等 分类规则 1. 只选择一个最主要的类别 2. 如果评论同时涉及多个方面选择用户情绪最强烈的那个 3. 如果无法判断选择其他 示例 评论快递太慢了等了一个星期才到 类别物流相关 评论衣服面料很舒服但是色差有点大 类别商品质量 评论客服态度很好问题很快就解决了 类别客服服务 评论{text} 类别名称加了三个示例之后效果又上了一个台阶。特别是对于边界模糊的评论示例给了模型很好的参照。这里要注意示例要覆盖容易混淆的情况不要只放简单明了的例子。3.3 批量分类的工程化处理单条分类跑通了接下来要解决批量处理的问题。实际项目中你不可能一条一条调 API需要做工程化封装。并发控制。大语言模型 API 通常有速率限制不能无限制并发。我一般用concurrent.futures做并发控制同时限制最大并发数。from concurrent.futures import ThreadPoolExecutor, as_completed import time def batch_classify(texts, categories, max_workers5, retry3): results [] def classify_with_retry(text): for i in range(retry): try: return zero_shot_classify(text, categories) except Exception as e: if i retry - 1: return 分类失败 time.sleep(2 ** i) with ThreadPoolExecutor(max_workersmax_workers) as executor: futures { executor.submit(classify_with_retry, text): idx for idx, text in enumerate(texts) } temp_results [None] * len(texts) for future in as_completed(futures): idx futures[future] temp_results[idx] future.result() results temp_results return results这段代码有几个细节值得说。max_workers5是我一般用的起始值具体设多少要看你的 API 速率限制。设太高容易触发限流设太低效率上不去。重试机制用了指数退避第一次失败等 1 秒第二次等 2 秒第三次等 4 秒。这个策略在 API 偶发故障时很管用。结果校验。模型输出不一定完全符合预期需要做校验。比如模型可能输出物流相关。多了个句号或者输出物流少了相关甚至输出一个不在类别列表里的词。def validate_result(result, valid_categories): result result.strip().rstrip(。.) if result in valid_categories: return result for cat in valid_categories: if cat in result or result in cat: return cat return 其他这个校验函数先做精确匹配再做包含匹配最后兜底到其他。实际用下来大部分输出问题都能被这个函数处理掉。缓存机制。如果你的数据里有大量重复文本加个缓存能省不少钱。用文本的哈希值做 key分类结果做 value存到本地或者 Redis 里。import hashlib import json def get_cache_key(text, categories): content text json.dumps(categories, sort_keysTrue) return hashlib.md5(content.encode()).hexdigest()3.4 效果评估与迭代Zero-Shot 分类做完之后你必须评估效果。没有评估就没有优化方向。评估需要标注数据但不需要太多。我一般会人工标注 100 到 200 条作为测试集计算准确率、召回率和 F1。如果类别不均衡还要看每个类别的单独指标。from sklearn.metrics import classification_report def evaluate(predictions, ground_truth): print(classification_report( ground_truth, predictions, digits4 ))拿到评估结果后重点看两类问题。一是哪些类别容易被混淆比如物流相关和客服服务经常分错那说明这两个类别的边界需要重新定义。二是看错误样本的具体内容找出规律。我遇到过一种情况模型对包含否定词的文本分类效果很差比如不是物流慢是商品质量差模型容易分到物流。后来在提示词里加了一条注意否定词以用户最终表达的核心问题为准效果就好了很多。4. 常见问题与排查技巧实录4.1 模型输出不稳定怎么办这是 Zero-Shot 分类最常见的问题。同一段文本今天分到 A 类明天分到 B 类。原因通常有三个。原因一temperature 没设成 0。这是最容易被忽略的。很多人用默认的 temperature通常是 1.0模型输出自然不稳定。改成 0 之后大部分不稳定问题都能解决。原因二类别定义有歧义。如果两个类别的描述有重叠模型就会摇摆。比如账号问题和登录问题如果登录问题单独作为一个类别那账号问题里就不应该再包含登录相关的描述。类别之间必须是互斥的。原因三提示词里的示例有矛盾。如果你给的示例中相似的文本分到了不同类别模型就会困惑。检查示例确保相似的文本分到相同的类别。排查方法很简单把同一段文本连续跑 10 次看结果是否一致。如果不一致按上面的顺序逐一排查。4.2 类别不均衡导致的偏差大语言模型在 Zero-Shot 场景下也会有类别偏好。我遇到过一种情况四个类别里其他类别的占比特别高模型倾向于把不确定的文本都扔到其他里。解决思路有两个。一是调整提示词明确告诉模型只有在完全无法判断时才输出其他并且给出其他类别的具体描述。二是如果其他类别确实不应该那么多可以在提示词里减少其他的权重比如把其他放到类别列表的最后或者干脆不设其他类别强制模型在给定类别中选择。还有一种情况是某些类别样本特别少模型对这些类别的识别能力弱。这时候可以在提示词里增加这些类别的示例或者把类别描述写得更详细。4.3 长文本分类的截断问题大语言模型有上下文长度限制虽然现在动辄 128K 甚至更长但长文本分类仍然是个问题。不是模型处理不了而是长文本里的信息太多模型可能抓不住重点。我的处理策略是如果文本超过一定长度比如 2000 字先做摘要再分类。摘要可以用大语言模型来做提示词写请用一句话概括以下文本的核心诉求。然后再把摘要拿去分类。另一种策略是分段分类再投票。把长文本切成几段每段单独分类然后取多数结果。这种方式适合文本内部主题一致的情况如果文本内部主题跳跃效果反而不好。4.4 成本控制的实战经验Zero-Shot 分类用大语言模型成本是绕不开的话题。我分享几个实际用下来有效的省钱技巧。技巧一用便宜的小模型做初筛。先用小模型比如 GPT-4o-mini 或者更小的开源模型做一遍分类对于置信度高的结果直接采纳置信度低的再用大模型重新分类。这样能省不少钱。技巧二精简提示词。提示词越长消耗的 token 越多。在保证效果的前提下尽量精简。比如类别描述不要写太长示例不要放太多。我一般控制在 500 token 以内。技巧三批量处理。如果 API 支持批量请求尽量批量提交。有些模型服务对批量请求有折扣。技巧四缓存重复文本。前面提过了这里再强调一下。实际数据里重复文本的比例可能比你想象的高缓存能省不少钱。4.5 常见问题速查表问题现象可能原因排查方法解决方案输出不稳定temperature 非 0检查 API 参数设 temperature0输出不稳定类别定义重叠检查类别描述确保类别互斥输出格式错误提示词约束不明确检查输出要求增加格式约束和示例某类别识别差类别描述太简略检查类别描述补充正例反例其他占比过高模型过于保守统计其他比例调整提示词或去掉其他长文本分类差信息过载检查文本长度先摘要再分类成本过高提示词太长统计 token 消耗精简提示词、用缓存并发限流max_workers 太高查看 API 报错降低并发数、加重试5. Zero-Shot 的边界与微调时机5.1 什么情况下 Zero-Shot 够用Zero-Shot 分类不是万能的但在某些场景下它确实够用。场景一类别少且定义清晰。比如情感分类正面/负面/中性、意图识别咨询/投诉/建议这些任务类别边界清晰Zero-Shot 效果通常不错。场景二数据量小且变化快。如果你的分类需求是临时的或者类别经常变那 Zero-Shot 的灵活性就很有价值。微调模型每次类别变化都要重新训练成本太高。场景三对准确率要求不是极致高。如果 80% 的准确率就能满足业务需求Zero-Shot 完全够用。但如果要求 95% 以上那还是得微调。场景四作为人工审核的辅助。让模型先分类人工只审核模型不确定的部分这样能大幅提升人工效率。5.2 什么时候该切换到微调Zero-Shot 效果遇到瓶颈的时候就是该考虑微调的时候。具体来说有几个信号。信号一准确率卡在某个水平上不去。你反复优化提示词准确率从 70% 提到 75%但再往上就很难了。这说明模型对这个领域的理解已经到了上限需要领域数据来进一步提升。信号二标注数据已经积累够了。如果你已经标注了几百上千条数据那不用白不用。微调一个小模型效果大概率比 Zero-Shot 好而且推理成本低得多。信号三对推理速度有要求。大语言模型的推理速度比小模型慢很多。如果你的场景要求毫秒级响应那必须用微调的小模型。信号四成本压力大。如果每天要分类几十万条数据用大语言模型的成本会很高。微调一个小模型一次训练成本可能几百块但后续推理几乎零成本。5.3 从 Zero-Shot 到微调的平滑过渡从 Zero-Shot 切换到微调不是非此即彼的。我推荐一个渐进式的方案。第一阶段纯 Zero-Shot。快速上线验证可行性同时积累标注数据。第二阶段Zero-Shot 人工审核。模型分类人工审核并修正修正后的数据作为标注数据积累起来。第三阶段微调模型 Zero-Shot 兜底。用积累的数据微调一个小模型大部分请求走微调模型微调模型置信度低的请求走 Zero-Shot。第四阶段纯微调模型。当微调模型的效果稳定超过 Zero-Shot并且标注数据覆盖了足够多的场景就可以完全切换到微调模型了。这个过渡方案的好处是每一步都有兜底不会因为切换导致效果断崖式下降。6. 几个容易被忽略的实操细节6.1 类别名称的措辞很关键类别名称怎么写对 Zero-Shot 效果影响很大。我做过一个对比实验同样的分类任务类别名称用物流相关和用配送服务效果差了将近 5 个百分点。原因是配送服务这个词在预训练数据里出现的频率更高模型对这个词的理解更准确。物流相关虽然意思差不多但相关这个词太模糊模型不好把握边界。所以类别名称要尽量用具体、常见的词避免用相关问题其他这种模糊的词。如果非要用也要在描述里说清楚。6.2 提示词里的顺序有讲究类别在提示词里的顺序也会影响效果。我观察到模型对排在前面的类别有一定的偏好可能是因为注意力机制的原因。如果你的类别有优先级把重要的类别放在前面。如果没有优先级可以把容易混淆的类别分开排列不要挨在一起。6.3 处理特殊字符和格式实际数据里经常有各种特殊字符、HTML 标签、乱码。这些内容会干扰模型分类。我一般会先做清洗去掉 HTML 标签、多余的空格和换行、特殊符号。但要注意有些特殊字符是有意义的比如表情符号可能表达情感不要一刀切全删了。6.4 多语言场景的处理如果你的数据是多语言的Zero-Shot 分类也能做但要注意几点。一是提示词最好用英文写因为大语言模型对英文指令的理解通常更好。二是类别描述也要用英文保持语言一致。三是如果某种语言的样本特别少模型可能分类效果差可以考虑先翻译成英文再分类。6.5 定期评估和更新Zero-Shot 分类不是一劳永逸的。数据分布会变化模型的版本会更新你的分类体系也可能调整。我建议至少每个月做一次评估看看准确率有没有下降有没有新的边界问题出现。评估的时候不要只看总体准确率要看每个类别的指标。有时候总体准确率没变但某个类别的召回率大幅下降这可能是数据分布变化的信号。7. 一个完整的实战案例拆解7.1 需求背景与数据情况假设我们要做一个用户反馈自动分类系统。数据是某产品的用户反馈文本需要分成五类功能异常、体验问题、内容相关、账号相关、其他。数据量大概每天 2000 条历史积累了 5000 条未标注数据。业务方要求一周内上线准确率至少 80%。7.2 方案设计与提示词实现时间紧标注数据不够Zero-Shot 是唯一选择。我设计的方案是先用 Zero-Shot 跑一遍全量数据然后人工抽检 200 条评估效果根据评估结果优化提示词再跑一遍。提示词最终版本如下你是一个用户反馈分类助手。请将以下用户反馈分类到给定类别之一。 类别说明 - 功能异常产品功能无法正常使用、报错、崩溃、卡顿等 - 体验问题界面不美观、操作不流畅、交互设计不合理等 - 内容相关内容质量差、内容缺失、内容错误、内容推荐不准确等 - 账号相关登录、注册、密码、账号安全、权限等 - 其他不属于以上任何类别的反馈 分类规则 1. 只选择一个最主要的类别 2. 如果反馈涉及多个方面选择用户最关注的那个 3. 如果无法判断选择其他 示例 反馈打开APP就闪退根本用不了 类别功能异常 反馈这个页面设计得太乱了找个功能要找半天 类别体验问题 反馈推荐的内容都不是我感兴趣的 类别内容相关 反馈{text} 类别名称7.3 效果评估与优化过程第一轮跑下来准确率 76%没达到 80% 的目标。分析错误样本发现两个主要问题。问题一内容相关和体验问题容易混淆。比如推荐的内容加载很慢模型有时候分到内容相关有时候分到体验问题。后来在类别描述里明确内容相关关注内容本身的质量和准确性体验问题关注使用过程中的感受。问题二短文本分类效果差。比如不好用这种反馈模型经常分到其他。后来加了一条规则如果反馈很短但能判断大致方向选择最接近的类别。优化后第二轮跑准确率提升到 83%达标了。7.4 上线后的持续迭代上线后我们每天人工抽检 50 条把分类错误的样本收集起来。积累了一个月有了大概 300 条标注数据。然后用这些数据微调了一个小模型准确率提升到 89%而且推理成本降低了很多。现在系统是微调模型为主Zero-Shot 作为兜底。微调模型置信度低于阈值的请求会转给 Zero-Shot 重新分类如果 Zero-Shot 也置信度低就转人工审核。这套组合拳打下来整体准确率稳定在 90% 以上人工审核量减少了 80%。8. 写在最后的一些个人体会Zero-Shot 分类这件事我最大的体会是它降低了文本分类的门槛但没有降低做好分类的难度。工具变简单了但分类体系的设计、边界案例的处理、效果的持续优化这些还是需要人来判断。我见过太多人把 Zero-Shot 当成银弹随便写个提示词就跑效果不好就怪模型不行。实际上提示词的优化空间非常大同样的模型好的提示词和差的提示词效果可能差 20 个百分点。另一个体会是不要追求一步到位。Zero-Shot 的价值在于快速启动让你在短时间内有一个可用的基线。有了基线之后再通过数据积累和模型迭代逐步提升。这个过程是渐进的不要指望 Zero-Shot 一开始就能达到生产级的效果。最后分享一个我常用的技巧把每次分类错误的样本存下来定期分析。这些错误样本是最宝贵的优化素材它们会告诉你分类体系的漏洞在哪里提示词的盲区在哪里。我很多提示词的优化灵感都来自于对错误样本的分析。这个系列下一篇会聊 Few-Shot 分类也就是在提示词里加示例的做法。Few-Shot 比 Zero-Shot 效果好不少但也有一些自己的坑到时候再细聊。
阅读完成 · 觉得有帮助？
