3.2 少样本提示

虽然大型语言模型展示了惊人的零样本能力,但在使用零样本设置时,它们在更复杂的任务上仍然表现不佳。少样本提示可以作为一种技术,以启用上下文学习,我们在提示中提供演示以引导模型实现更好的性能。演示作为后续示例的条件,我们希望模型生成响应。

根据 Touvron et al. 2023 等人的在 2023 年的论文,当模型规模足够大时,小样本提示特性开始出现 (Kaplan et al., 2020)

让我们通过Brown等人2020年提出的一个例子来演示少样本提示。在这个例子中,任务是在句子中正确使用一个新词。

提示:

“whatpu”是坦桑尼亚的一种小型毛茸茸的动物。一个使用whatpu这个词的句子的例子是:我们在非洲旅行时看到了这些非常可爱的whatpus。“farduddle”是指快速跳上跳下。一个使用farduddle这个词的句子的例子是:

输出:

当我们赢得比赛时,我们都开始庆祝跳跃。

我们可以观察到,模型通过提供一个示例(即1-shot)已经学会了如何执行任务。对于更困难的任务,我们可以尝试增加演示(例如3-shot、5-shot、10-shot等)。

根据Min等人(2022)的研究结果,以下是在进行少样本学习时关于演示/范例的一些额外提示:

  • “标签空间和演示指定的输入文本的分布都很重要(无论标签是否对单个输入正确)”
  • 使用的格式也对性能起着关键作用,即使只是使用随机标签,这也比没有标签好得多。
  • 其他结果表明,从真实标签分布(而不是均匀分布)中选择随机标签也有帮助。

让我们尝试一些例子。让我们首先尝试一个随机标签的例子(意味着将标签Negative和Positive随机分配给输入):

提示:

这太棒了!// Negative
这太糟糕了!// Positive
哇,那部电影太棒了!// Positive
多么可怕的节目!//

输出:

Negative

即使标签已经随机化,我们仍然得到了正确的答案。请注意,我们还保留了格式,这也有助于。实际上,通过进一步的实验,我们发现我们正在尝试的新GPT模型甚至对随机格式也变得更加稳健。例如:

提示:

Positive This is awesome! 
This is bad! Negative
Wow that movie was rad!
Positive
What a horrible show! --

输出:

Negative

上面的格式不一致,但模型仍然预测了正确的标签。我们必须进行更彻底的分析,以确认这是否适用于不同和更复杂的任务,包括提示的不同变体。

少样本提示的限制

标准的少样本提示对许多任务都有效,但仍然不是一种完美的技术,特别是在处理更复杂的推理任务时。让我们演示为什么会这样。您是否还记得之前提供的任务:

这组数字中的奇数加起来是一个偶数:15、32、5、13、82、7、1。
A:

如果我们再试一次,模型输出如下:

是的,这组数字中的奇数加起来是107,是一个偶数。

这不是正确的答案,这不仅突显了这些系统的局限性,而且需要更高级的提示工程。

让我们尝试添加一些示例,看看少样本提示是否可以改善结果。

提示:

这组数字中的奇数加起来是一个偶数:4、8、9、15、12、2、1。
A:答案是False。
这组数字中的奇数加起来是一个偶数:17、10、19、4、8、12、24。
A:答案是True。
这组数字中的奇数加起来是一个偶数:16、11、14、4、8、13、24。
A:答案是True。
这组数字中的奇数加起来是一个偶数:17、9、10、12、13、4、2。
A:答案是False。
这组数字中的奇数加起来是一个偶数:15、32、5、13、82、7、1。
A:

输出:

答案是True。

这没用。似乎少样本提示不足以获得这种类型的推理问题的可靠响应。上面的示例提供了任务的基本信息。如果您仔细观察,我们引入的任务类型涉及几个更多的推理步骤。换句话说,如果我们将问题分解成步骤并向模型演示,这可能会有所帮助。最近,思维链(CoT)提示已经流行起来,以解决更复杂的算术、常识和符号推理任务。

总的来说,提供示例对解决某些任务很有用。当零样本提示和少样本提示不足时,这可能意味着模型学到的东西不足以在任务上表现良好。从这里开始,建议开始考虑微调您的模型或尝试更高级的提示技术。接下来,我们将讨论一种流行的提示技术,称为思维链提示,它已经获得了很多关注。

提示词工程指南 文章被收录于专栏

本专栏是 https://github.com/dair-ai/Prompt-Engineering-Guide 部分中文翻译。

全部评论

相关推荐

说一说之前很火的提示词吧,但是随着AI能力的提升,提示词越来越不重要了。对初级需求,提示词确实越来越 “轻量化”,随便一句 “用 Java 写个简单的用户登录接口”,AI 就能给出能用的代码;但对复杂场景、高要求的 AI Coding 任务,提示词非但没失效,反而升级成了 “精准指令工程”,是拉开效率差距的关键。可一旦碰到复杂业务逻辑、性能优化、架构设计这类硬核需求,就会发现 “会写提示词” 和 “不会写提示词” 的天壤之别。比如同样是让 AI 优化 MySQL 慢查询,普通提示词是 “帮我优化这段 SQL”,AI 可能只会给出加索引的建议;但精准的指令是 “我有一个电商订单查询 SQL,数据量 100 万 +,现在执行时间 2 秒,要求优化到 500ms 内,限制只能调整索引和 SQL 结构,不能改表结构,还要考虑分库分表的兼容性”—— 这种带约束条件、业务背景、性能指标的提示词,才能让 AI 输出真正落地的方案。更重要的是,AI Coding 的核心需求正在从 “生成代码” 转向 “解决问题”。比如你让 AI 排查一个 Spring Boot 接口的超时问题,只说 “接口超时了,帮我看看”,AI 大概率会罗列一堆通用原因;但如果你在提示词里加上 “接口调用了第三方支付 API,超时发生在高峰期,日志显示有大量数据库锁等待”,AI 就能直接定位到 “第三方 API 熔断机制缺失”“数据库事务过长” 等具体问题,甚至给出代码级的解决方案。还有一个容易被忽略的点:提示词是帮你 “驯服 AI 幻觉” 的关键。AI Coding 最头疼的就是生成 “看起来对但实际跑不通” 的代码,比如引用不存在的类、用错框架 API。这时候,在提示词里加上 “代码必须符合 Spring Boot 2.7 版本规范,禁止使用废弃 API,给出完整的依赖配置和测试用例”,就能大幅降低幻觉概率 —— 这种 “精准约束”,本质就是高级提示词技巧。说到底,AI 能力提升后,提示词的 “复杂度” 降低了,但 “精准度” 要求更高了 。它不再需要华丽的模板,却需要你把业务需求、技术约束、性能指标讲清楚。对初级开发者来说,随便写写就能用;但对想靠 AI 提升核心工作效率的工程师,“写好提示词” 依然是 AI Coding 的核心实战技巧。
AI Coding实战技...
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务