关于AI 少样本提示的几点记录

做文本分类，零样本 prompt 把四类定义写得明明白白，主流样本没问题，一到边界就翻车：「这个功能怎么收费」被判成技术问题，「登录一直转圈」被判成产品咨询。规则写在 prompt 里，模型似乎没真正「见过」长什么样。

加两三个示例之后准确率明显上来，但示例怎么选、放几个、顺序有没有影响，又是一堆坑。这篇从零样本到少样本的试错记录。

零样本的局限

一开始我写的提示是这样的：

你是一个文本分类专家。请将用户输入的文本归类为以下几个类别：
1. 技术问题：与编程、系统配置、工具使用相关的问题
2. 产品咨询：关于产品功能、价格、购买流程的询问
3. 反馈建议：对产品的意见、改进建议或投诉
4. 其他：不属于以上类别的输入

用户输入：{{user_input}}
分类结果：

看着挺清楚的，对吧？但实际跑下来，遇到这种输入就出问题：

• “我的电脑连不上 Wi-Fi” → 模型有时归类为"其他"，有时归类为"技术问题"
• “你们软件怎么收费” → 偶尔被识别为"产品咨询"，偶尔是"反馈建议"
• “能不能加个深色模式” → 有时是"反馈建议"，有时是"产品咨询"

问题在哪里？零样本提示假定模型已经"理解"了你的定义，但模型对"技术问题"和"产品咨询"边界理解，和你想的不一样。

为什么需要示例

少样本提示的逻辑很直白：文字定义是抽象的，示例是具体的。模型从你给的例子里推断分类标准，不完全靠 prompt 里的文字定义。

特别是遇到这些情况，零样本往往会出问题：

1. 边界模糊：类别之间有重叠，像"我的账号登不上了"可以是技术问题也可以是产品咨询
2. 专业术语：行业内的说法模型没见过，比如"CI 管道失败"在通用训练数据里出现不多
3. 特殊约束：你有一些隐含的规则没有写出来，比如"提到价格就归为产品咨询"而不是"反馈建议"

示例的作用，就是把你的隐性知识显性化。

设计好的示例

少样本提示不是随便塞几个例子就行。我试了几轮，发现有几个关键点。

示例数量

开始以为越多越好，塞了十几个示例，结果模型反而"学废"了——它开始在示例里找模式，而不是理解任务。

一般 3–5 个比较合适：

• 太少（1–2 个）模型学不到完整的分布
• 太多（>8 个）模型容易过拟合到示例的表面特征
• 中等数量能让模型学到"本质"又不死记硬背

示例质量

好的示例有几个特征：

代表性：覆盖主要情况，不要全是同一类极端案例

❌ 不好：
输入1：Python 如何安装库？
输入2：JavaScript 怎么调试？
输入3：Java 报错怎么看？
输入4：C++ 编译失败怎么查？
输入5：Go 语言入门怎么学？

所有都是技术问题，且都是编程语言问题

✅ 较好：
输入1：Python 如何安装库？
输入2：你们软件怎么收费？
输入3：能不能加个深色模式？
输入4：我的账号登不上了
输入5：这个功能太复杂了，建议简化

覆盖了不同类别，且涵盖了编程、价格、功能改进、账号使用等多种场景

边界清晰：容易混淆的情况要给示例

✅ 边界示例：
输入：我的账号登不上了
分类：技术问题

输入：有没有企业版账号？
分类：产品咨询

这两个都涉及账号，但分类不同，让模型学会区分

标注一致：同一个类型的输入标注要一致，不要自相矛盾

❌ 不一致：
示例1：
输入：建议增加导出功能
分类：产品咨询

示例2：
输入：希望能加个深色模式
分类：反馈建议

同样是功能建议，标注不一致会让模型困惑

示例位置

我发现示例放在指令和用户输入之间效果最好：

[指令部分]
你是一个文本分类专家...

[示例部分]
示例1：
输入：{{example1_input}}
分类：{{example1_output}}

示例2：
输入：{{example2_input}}
分类：{{example2_output}}

[目标输入]
用户输入：{{user_input}}
分类结果：

这样模型能先理解任务，再从示例学习，最后应用到目标输入。

踩坑记录

坑一：示例泄露了答案

有一段时间分类效果特别好，测试集准确率 98%，但上线后真实数据准确率掉到 70%。

排查后发现，示例里包含了真实数据中常见的关键词：

示例1：
输入：CI 管道失败了怎么排查？
分类：技术问题

示例2：
输入：CDN 回源失败怎么办？
分类：技术问题

真实数据里大量包含"CI 管道"和"CDN 回源"的输入，模型没学会分类，只是记住了"有这些词就是技术问题"。

后来改了策略：示例用简化或抽象的版本，避免关键字泄露。

坑二：示例过时

任务做了一段时间后，用户输入风格变了，新问题类型出现，但示例还是老样子。

比如一开始没有"API 集成"相关的问题，后来这类问题变多了，但示例里没有覆盖，模型要么分类错误，要么强行归到"其他"。

解决办法是定期回顾示例，根据实际数据分布调整。

坑三：示例不平衡

有一段时间用户咨询主要集中在"产品咨询"和"技术问题"，但示例四个类别平均分配，各 1–2 个。

结果模型对"反馈建议"和"其他"过于敏感，遇到不确定的情况倾向于往这两个类别分。

调整示例比例后，模型分类倾向与实际数据分布一致了。

实践效果

从零样本到少样本，我做了个对比测试。

测试集是 200 条真实用户输入，人工标注后用 GPT-4 评估分类准确率：

几个观察：

1. 零样本在边界案例上表现差：简单分类还行，但遇到模糊情况就出错
2. 3 个示例已经有明显提升：从 78% 提到 89%，性价比最高
3. 5 个示例效果最好：再增加反而略降，可能是模型被过多细节干扰

什么时候用少样本

不是所有任务都需要少样本。我总结了一个简单判断：

零样本够用的场景：

• 任务定义清晰，没有歧义
• 模型训练数据里见过类似任务
• 输入比较标准化，没有太多边界情况
• 你对输出格式要求不苛刻

需要少样本的场景：

• 分类标准有主观判断或业务逻辑
• 涉及行业术语或内部概念
• 有隐性约束或偏好没写进提示
• 需要特定的输出格式或风格
• 边界情况多，需要示例澄清

少样本的局限

少样本不是万能药，试下来发现几个问题：

1. 上下文占用：每个示例都消耗 tokens，多了就不够放其他信息
2. 维护成本：任务变化时需要更新示例，不是一次性的
3. 数据依赖：示例需要有代表性，如果你的训练数据不全面，示例也难覆盖
4. 模型差异：不同模型对少样本的敏感度不同，有的模型提升明显，有的没那么大

写在后面

从零样本到少样本，本质是换了一种教模型的方式：少写规则，多给例子。

很多时候分类翻车，prompt 写得再清楚也没用——模型没见过足够多的边界样本。示例也不是越多越好：上下文占 tokens，任务变了还得维护，不同模型对少样本的敏感度也不一样。

任务简单、边界清晰，零样本够用；标准有主观判断、术语多、边界模糊，再加 3–5 个代表性示例，性价比通常最高。再往上走，就该考虑微调了。

少样本是工具，用对了能省很多事，用错了就是给自己加维护负担。关键还是搞清楚你在解决什么问题。

版权声明: 本文首发于 指尖魔法屋-关于AI 少样本提示的几点记录（https://blog.thinkmoon.cn/post/357-ai-few-shot-prompting-zero-example-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！