# Prompt工程实战：如何用Few-Shot Learning提升LLM输出质量
调用大语言模型时，你遇到过这种情况吗？不管怎么调整提示词，输出格式总是差强人意。每次都要写大段说明，模型才能勉强理解你的需求。如果是这样，Few-Shot Learning可能正是你需要的技术。
Few-Shot Learning，翻译过来就是少样本学习，是Prompt工程中最核心的技术之一。简单来说，就是在提示词里放几个具体例子，让模型自己推断出你想要什么样的输出。这篇文章会带你从零开始，掌握这项技术的实际用法。
## 为什么Few-Shot Learning有效
大语言模型在预训练阶段学习了海量文本，掌握了丰富的知识和语言模式。但模型并不知道你具体想要什么格式。它可能返回一段话、一个列表，甚至一张表格。这种不确定性导致你需要反复调整提示词才能得到满意的结果。
但如果你给出具体示例呢？
“`
请整理以下会议的要点：
会议内容：本周三团队讨论了Q2季度的产品规划，确定了三个重点功能的上线时间。
输出格式：
– 时间：本周三
– 参与人员：产品团队、技术团队
– 决议：确定Q2季度三个重点功能的上线时间
“`
加上示例后，模型立刻就能理解你要的格式。这就是Few-Shot Learning的核心：通过具体例子，让模型推断你的意图。
## 基础用法：格式控制
从最简单的例子开始：控制输出格式。
假设你有一个文章列表，想让模型提取标题和摘要。只说”提取标题和摘要”，模型可能返回各种奇怪格式。加上示例，效果完全不一样。
两个提示词对比：
第一个没有示例：
“`
从以下文章中提取标题和摘要：
文章1：Python 3.12 带来了多项性能优化…
文章2：Go语言的并发编程一直是其核心优势…
“`
可能返回这样的结果：
“`
文章1：
标题：Python 3.12 性能优化
摘要：Python 3.12带来了…
文章2：
标题：Go语言并发编程
摘要：Go语言的并发…
“`
第二个版本加入Few-Shot示例：
“`
从以下文章中提取标题和摘要，使用以下格式：
文章1：Python 3.12 带来了多项性能优化，包括解释器的重构和JIT编译器的改进。根据官方测试，新版本的性能提升了25%。
输出格式：
【标题】Python 3.12 性能优化
【摘要】Python 3.12带来了多项性能优化，包括解释器重构和JIT编译器改进，性能提升约25%
文章2：Go语言的并发编程一直是其核心优势。goroutine机制让并发变得简单高效…
输出格式：
【标题】Go语言并发编程详解
【摘要】Go语言以其goroutine机制著称，并发编程简单高效…
“`
加了示例后，输出格式非常一致。这是Few-Shot Learning最基本的用法。
## 进阶用法：思维引导
Few-Shot Learning不仅能控制格式，还能引导模型的思考过程。处理复杂问题时，提供推理示例能帮助模型更好地解决问题。
比如做数学题或逻辑推理，只给问题，模型可能给出错误答案。加上推理示例后，模型就能沿着正确思路思考。
“`
请解答以下数学问题：
问题：小明有15个苹果，给了小红一半，又给了小李3个，小明还剩多少苹果？
推理过程：
15个苹果，先给了一半 = 15 / 2 = 7.5 ≈ 8个（题目通常取整，我们按8个算）
给了小李3个
剩余 = 15 – 8 – 3 = 4个
所以小明还剩4个苹果
请解答：小张有20块钱，买了单价3元的文具，买了5件，应该找回多少钱？
“`
有了这个示例，模型学会了分解问题的思路，能正确解答类似问题。
## 高级技巧：链式示例
有时候一两个示例不够用。可以使用链式示例，提供一连串相互关联的例子，让模型理解更复杂的任务逻辑。
“`
请判断以下评论的情感极性（正面/负面/中性），并给出理由：
评论1：这家店的服務態度非常好，東西也很好吃，推薦！
情感：正面
理由：使用了”非常好””好吃””推薦”等積極詞匯，表達了明確的認可
评论2：等了半小時才上菜，味道一般般，有點失望
情感：负面
理由：提到等待時間長、”失望”等負面詞匯，表達了不滿
评论3：餐廳位置在市中心，比較方便
情感：中性
理由：單純陳述事實，沒有明顯的正面或負面評價
請判斷：這個鍵盤的手感很不錯，就是價格有點貴
“`
这种链式示例让模型不仅能判断情感，还能给出合理的理由。
## 实际案例：SQL查询生成
再展示一个实用案例：如何使用Few-Shot Learning让模型生成SQL查询。
假设你有数据库，包含用户表（users）、订单表（orders）和产品表（products）。想让模型根据自然语言生成SQL，只需要几个示例就行。
“`
根据自然语言生成对应的SQL查询：
用户表结构：users(id, name, email, created_at)
订单表结构：orders(id, user_id, product_id, amount, status, created_at)
产品表结构：products(id, name, price, category)
示例1：
输入：查询所有已下单的用户名字
SQL：SELECT DISTINCT u.name FROM users u JOIN orders o ON u.id = o.user_id
示例2：
输入：查询每个类别的总销售额
SQL：SELECT p.category, SUM(o.amount) as total FROM products p JOIN orders o ON p.id = o.product_id GROUP BY p.category
示例3：
输入：查询状态为”已完成”的订单数量
SQL：SELECT COUNT(*) as count FROM orders WHERE status = completed
请生成：查询购买过”电子产品”的用户邮箱
“`
加上这几个示例，模型就能准确理解表结构和查询逻辑的关系。
## 注意事项和最佳实践
使用Few-Shot Learning时，有几点要注意：
首先，示例数量不用太多。2-5个足够。过多示例会增加提示词长度，还可能导致模型过度拟合特定示例模式。
其次，示例质量比数量重要。每个示例都应该清晰展示你想要的结果形式，避免歧义。
第三，示例顺序也有影响。如果任务逻辑是顺序相关的，示例顺序也应该反映这种关系。比如分类任务，可以按”正例->负例->边界case”的顺序排列。
最后，定期检查示例是否仍然有效。模型版本更新时，可能需要对示例进行调整。
## 总结
Few-Shot Learning是Prompt工程中最实用的技术之一。通过提供具体示例，它帮助模型快速理解我们的意图，输出更准确的结果。
优势在于简单有效。不需要额外训练，不需要改变模型配置，只需要在提示词中加入几个例子就可以。
当然，它也不是万能的。对于需要专业知识或精确推理的任务，可能还需要结合其他技术，比如Chain-of-Thought或ReAct。但对于大多数日常使用场景，掌握Few-Shot Learning已经足够让你的工作效率提升一个档次。
如果这篇文章对你有帮助，欢迎收藏并分享给其他需要的朋友。有任何问题或者建议，也欢迎在评论区留言讨论。