直接回答：Few-shot Prompting（少样本提示）是在同一次提示中放入少量“输入—输出”示例，再让模型处理新输入。模型权重不会因此更新；示例为本次推断提供任务、标签、格式和输入分布线索。它适合分类、抽取、改写和固定格式任务，但效果会随模型、示例、顺序、数量和测试数据变化。
Few-shot 不是“多放几个优秀答案”。可靠做法是先写清任务契约，再从经过审核的示例库选择能代表常见情况和关键边界的演示，用独立测试集比较零样本与少样本基线，并记录模型、提示、示例集合和顺序版本。
Few-shot、Zero-shot、微调有什么区别？
GPT-3 论文系统展示了模型仅通过文本交互执行零样本、单样本和少样本任务的现象，且没有进行任务专用的梯度更新。这个现象通常称为 In-context Learning（上下文学习），但“学习”发生在当前推断行为中，不表示模型永久记住示例。
| 方法 | 给模型什么 | 是否改权重 | 适合场景 | 主要代价 |
|---|---|---|---|---|
| Zero-shot | 指令与新输入 | 否 | 任务清楚、模型已熟悉 | 格式和边界可能不稳 |
| One-shot | 1 个示例 | 否 | 展示输出形状 | 容易受单例偏差影响 |
| Few-shot | 少量示例 | 否 | 分类、抽取、风格和边界 | 占上下文、顺序敏感 |
| RAG | 检索到的事实证据 | 否 | 更新或私有知识 | 检索与引用链路 |
| 微调 | 训练数据集 | 是 | 稳定行为、术语和规模化任务 | 数据、训练与部署成本 |
示例主要告诉模型“怎样完成任务”，事实材料主要告诉模型“依据什么回答”。二者可以组合：RAG 提供最新制度，Few-shot 展示如何把制度片段转换成结构化答复。RAG 边界见检索增强生成指南，微调边界见LoRA/QLoRA 与上线验收。
一个 Few-shot 提示包含什么？
任务：把客服消息分类为 refund、delivery、account 或 other。
规则：只输出 JSON；证据不足时使用 other。
<example>
输入：钱付了两次，怎么退回？
输出：{"label":"refund","reason":"重复扣款并请求退款"}
</example>
<example>
输入：物流三天没更新。
输出：{"label":"delivery","reason":"询问物流状态"}
</example>
<query>
输入：{真实待分类消息}
</query>示例应使用与真实请求完全相同的字段、分隔符和输出 schema。不要在示例中加入生产时不会出现的解释，也不要让一个示例的标签拼写与任务定义不同。Anthropic 的提示实践建议示例与目标任务相关、多样、清晰并使用一致结构；OpenAI 的提示工程文档也强调不同模型类型、快照和消息层级会影响提示行为。
| 组件 | 必须一致的内容 | 常见错误 |
|---|---|---|
| 任务定义 | 标签、字段、允许动作 | 示例暗示了指令没有说明的新规则 |
| 输入 | 字段名、语言、噪声和长度分布 | 示例过于干净，生产输入含错字和缺项 |
| 输出 | schema、类型、空值和拒答 | 示例输出含 Markdown，生产要求纯 JSON |
| 分隔 | 示例与真实输入边界 | 用户文本被解释为新指令 |
| 验收 | 可机器检查的成功标准 | 只凭“看起来不错”选择提示 |
示例怎么选：不是只看“相似”或“多样”
示例选择至少要同时考虑质量、相似性、覆盖率、边界和安全。What Makes Good In-Context Examples for GPT-3?研究了按语义相似度检索示例的路线，但论文结果来自特定任务和模型，不能推出“最近邻示例永远最好”。相似示例有助于贴近当前输入，覆盖示例则帮助模型看到标签和边界。
| 维度 | 检查问题 | 失败表现 | 处理方式 |
|---|---|---|---|
| 正确性 | 输出是否经领域人员确认 | 模型稳定复制错误标签 | 双人复核或规则校验 |
| 相似性 | 是否贴近当前意图和表达 | 任务方向偏离 | 语义检索后再过滤 |
| 覆盖率 | 标签与常见输入是否覆盖 | 多数类被过度预测 | 分层抽样 |
| 边界 | 歧义、缺失和拒答是否出现 | 遇到异常就猜测 | 加入高价值难例 |
| 代表性 | 长度、语言、错字是否接近生产 | 离线好、线上差 | 从真实流量脱敏取样 |
| 安全 | 是否包含秘密、恶意指令或个人信息 | 泄露或被注入 | 脱敏、隔离、白名单 |
标签、格式和内容，究竟哪个更重要？
Min 等人的研究在其分类与多项选择实验中发现，把演示标签随机替换后性能下降有限，而标签空间、输入分布和整体格式等因素仍很重要。这是对特定实验的观察，不能改写成“示例答案可以随便写”。抽取、计算、代码、法律或医疗任务中，错误演示可能直接传播错误逻辑。
| 任务 | 示例最重要的信号 | 错误示例风险 |
|---|---|---|
| 封闭标签分类 | 标签集合、输入分布、输出格式 | 类别边界偏移 |
| 字段抽取 | schema、缺失值和跨度规则 | 字段错位或编造值 |
| 风格改写 | 语气、结构和禁用表达 | 复制敏感或不适合内容 |
| 数学/代码 | 正确方法、接口和约束 | 复制错误步骤 |
| 高风险判断 | 证据、拒答和升级路径 | 把演示当专业结论 |
示例顺序为什么也要测试？
Few-shot 提示可能对示例排列敏感。Fantastically Ordered Prompts研究了顺序导致的性能变化。实际工程中，最近的示例、标签聚集、长示例占据窗口和首尾位置都可能改变输出，因此不能只测试一种排列。
| 顺序策略 | 优点 | 风险 | 测试方法 |
|---|---|---|---|
| 固定人工顺序 | 易复现 | 对特定位置过拟合 | 运行多组随机排列 |
| 最相似放最后 | 新输入附近有相似模式 | 最近示例偏置 | 与放首位/中间比较 |
| 按标签交错 | 减少同类聚集 | 不一定适合生成任务 | 看各类召回与混淆矩阵 |
| 随机顺序 | 可估计稳定性 | 线上不可完全复现 | 固定随机种子并记录排列 |
如果不同顺序导致结论大幅变化，不应挑最好的一次当最终结果。先检查示例是否冲突、标签是否不平衡、任务是否含糊；再用多排列平均值、最差分位或稳定性阈值评估。
静态示例与动态示例检索
静态 Few-shot 为所有请求使用同一组示例，适合任务稳定、标签少、审计要求高的场景。动态示例检索则按当前输入从示例库选取候选，适合意图多、表达差异大或长尾明显的场景，但它新增了检索、污染、延迟和不可复现问题。
| 方案 | 适合 | 上线要求 |
|---|---|---|
| 固定 2—5 个示例 | 小标签集、固定格式 | 版本号与回归集 |
| 按标签分层选择 | 类别不平衡 | 每类最低覆盖 |
| 语义最近邻 | 表达差异大 | 相似度阈值与质量过滤 |
| 相似 + 多样重排 | 需兼顾当前输入与覆盖 | 去重和边界样本配额 |
| 人工场景路由 | 高风险、规则明确 | 路由失败与默认降级 |
动态库中的示例必须是审核后的白名单，不能把任意用户输入和模型输出直接写回示例库，否则错误、个人信息和提示注入会被后续请求检索出来。示例 ID、来源、审核人、版本和选取分数应进入日志。
三类任务的示例应该怎样设计？
分类：先定义标签边界，再展示难例
分类任务最常见的问题不是模型不认识标签，而是业务标签互相重叠。例如“物流延迟”和“要求退款”可能同时出现在一条消息中。任务契约需要说明单标签还是多标签、冲突时的优先级、证据不足时是否使用 other；示例再展示这些规则如何应用。
| 示例角色 | 应包含 | 不应包含 |
|---|---|---|
| 典型正例 | 一个标签的清楚证据 | 与真实输入完全不同的教科书句子 |
| 相邻边界 | 容易与另一标签混淆的表达 | 没有说明为何选择该标签 |
| 多意图 | 优先级或多标签输出 | 示例与任务规则冲突 |
| 无答案 | other、拒答或转人工 | 为了覆盖而强行归类 |
信息抽取：缺失值比完整案例更重要
抽取任务应展示字段缺失、多个候选、单位换算和原文冲突时的行为。若所有演示都恰好包含完整姓名、日期和金额，模型可能在生产中为缺失字段补造值。示例输出要区分 null、空字符串、未知和不适用，并保留支持字段的原文片段或位置。
改写与生成：把“好风格”变成可观察特征
不要只挑编辑认为“写得好”的文章。先把目标拆成句长、结构、受众、语气、禁用表达、引用规则和事实边界，再让示例一致体现这些特征。涉及事实的生成任务仍需可靠来源；示例只说明表达方式，不能成为事实证据。幻觉与证据核验可参考AI 幻觉核验指南。
类别偏置与校准
示例中的标签频率、排列和标签词本身都可能造成偏置。Calibrate Before Use研究了上下文学习中的答案偏置与校准方法。论文方法和收益来自特定模型与任务，生产团队不应直接套一个校准公式，而应先观察空输入、无信息输入或标签互换时模型是否偏向固定类别。
- 比较每个标签在测试集中的真实占比与预测占比，避免只看总体准确率。
- 交换标签名称或示例顺序，检查结论是否异常变化。
- 记录置信信息时先验证其与真实正确率是否一致，不把模型自报概率当校准概率。
- 业务代价不对称时，用每类召回、精确率和代价矩阵决定阈值，而不是追求单一最高分。
| 偏置来源 | 诊断实验 | 可能修复 |
|---|---|---|
| 多数类示例过多 | 平衡示例后比较各类召回 | 分层配额或代价敏感规则 |
| 最后一个示例影响大 | 轮换首尾位置 | 多顺序评测或固定稳定排列 |
| 标签词有语义暗示 | 换成中性标签 ID | 标签映射与后处理 |
| 某种格式被偏爱 | 保持内容不变只换格式 | 统一模板和解析器 |
上下文预算怎样分配？
上下文窗口并不只装示例，还要容纳系统指令、真实输入、检索证据、工具结果和输出空间。示例过多会挤掉事实材料或使模型更难找到关键条件。应按任务价值分配预算，而不是“窗口还有空间就继续加”。
| 内容 | 优先级 | 压缩原则 |
|---|---|---|
| 系统与安全边界 | 最高 | 保留明确规则，不由示例隐含 |
| 当前真实输入 | 最高 | 不删除影响结论的字段 |
| 事实证据 | 高 | 保留来源、版本和例外 |
| Few-shot 示例 | 按增益决定 | 用消融删除无贡献或重复示例 |
| 历史对话 | 按相关性决定 | 去除跑题和过期指令 |
压缩示例时不能只缩短文字，还要重新验证输出。删掉一句看似多余的限制，可能改变标签边界；把真实错误码换成通用占位符，可能使示例失去精确匹配价值。Google 的提示设计策略也把清晰指令、少样本示例、上下文和迭代评测作为相互关联的实践，而不是固定公式。
什么时候不应该继续增加 Few-shot？
| 现象 | 更可能需要 | 原因 |
|---|---|---|
| 答案缺少最新或私有事实 | RAG、数据库或 API | 示例不是事实更新机制 |
| JSON 仍偶尔不合法 | 结构化输出、schema 校验与重试 | 示例不能提供确定性语法保证 |
| 数千种稳定标签且请求量大 | 专用分类器或微调 | 上下文示例成本和覆盖受限 |
| 需要付款、删库或改权限 | 工具权限、审批与业务规则 | 提示不能授予或限制真实权限 |
| 所有提示版本都在长尾失败 | 补数据、换模型或重新定义任务 | 问题可能不是措辞 |
停止调提示也是工程决策。若 Few-shot 相对基线的收益小于新增 Token、延迟和维护成本，保留 Zero-shot 可能更合理；若行为需要跨大量请求稳定复用，应评估微调；若错误会造成高影响动作，应使用确定性规则和人工审批。
如何评测 Few-shot 是否真的有用？
先建立不包含在示例库中的保留测试集，再比较 Zero-shot、固定 Few-shot 和动态 Few-shot。调示例时使用开发集；最后只在保留集上验收，避免反复看测试答案后把示例挑成“考试泄题”。
| 门禁 | 指标 | 需要回答 |
|---|---|---|
| 任务质量 | 准确率、F1、字段正确率或人工量表 | 是否优于 Zero-shot 基线 |
| 格式 | schema 通过率、可解析率 | 是否可被下游稳定消费 |
| 覆盖 | 各标签召回、长尾与边界通过率 | 是否只改善多数类 |
| 稳定 | 不同顺序、种子和复跑方差 | 是否依赖幸运排列 |
| 迁移 | 不同模型/快照的回归差异 | 升级模型后是否仍有效 |
| 运行 | 输入 Token、P95 延迟、单次成本 | 收益是否值得上下文开销 |
| 安全 | 注入成功率、敏感信息暴露率 | 示例是否扩大攻击面 |
至少做三类消融：去掉全部示例、逐个去掉示例、打乱示例顺序。若删除某个示例反而更好，它可能是噪声；若只在开发集提升，可能已经过拟合；若格式变好但事实变差，应分开报告，而不是用一个平均分掩盖。
示例版本与可复现记录
“提示词没有改”并不等于系统行为没有改。模型快照、系统消息、分词、动态选例模型、示例库内容、顺序、采样参数和结构化输出实现都可能变化。每个线上请求应生成一个可追溯版本身份，出现投诉时能还原当时到底使用了什么。
| 记录项 | 建议内容 | 缺失后的问题 |
|---|---|---|
| 模型 | 供应商、模型 ID、快照/发布日期 | 无法判断是否因模型升级退化 |
| 提示 | 系统、开发者和用户模板哈希 | 不知道真实指令层级 |
| 示例 | ID、版本、顺序、选择分数 | 动态 Few-shot 无法复现 |
| 参数 | 温度、最大输出、随机种子等 | 无法区分提示与采样波动 |
| 输入 | 脱敏后的稳定样本 ID | 无法重放且可能过度记录隐私 |
| 结果 | 原始输出、解析结果、校验错误 | 只看到最终修正稿，漏掉失败 |
示例库发布可采用“草稿—审核—灰度—生效—撤回”状态。修改标签、输出 schema 或来源时创建新版本，不覆盖旧记录；动态检索只从当前生效的白名单取样。删除敏感示例时，还要清除缓存和派生索引，而不是只在管理界面标记删除。
发布报告应同时保存基线与候选的测试集版本、逐样本差异和失败清单。若总体分数提高但高风险类别下降，不能直接上线；若某组示例只对一个模型有效，应把适用模型写入版本元数据。这样 Few-shot 才从“聊天技巧”变成可审计的配置资产。
人工复核应该看什么？
人工评审不应只对最终文字打“喜欢/不喜欢”。先按任务契约拆成可观察项：标签是否正确、字段是否有原文依据、格式能否解析、缺失时是否拒答、语言是否符合受众、是否暴露隐私。评审者看不到模型或提示版本时，也很难判断问题来自示例还是模型。
- 双人独立标注一小部分样本，先解决标准分歧，再扩展评测集。
- 把“无法判断”作为合法标签，避免评审者被迫猜测。
- 记录错误类型而非只记总分，使后续能针对性补示例。
- 定期抽查线上真实失败，防止测试集长期停留在旧分布。
对于开放式生成，可以准备成对比较：向评审者隐藏方案名称，只判断哪个回答更符合事实、完整性、格式和受众要求，同时允许“二者都不合格”。交换左右位置并随机化顺序，减少展示偏置。评审意见应回到具体句子或字段，不能只写“感觉更自然”。若模型评分器参与扩展评测，仍需与人工校准集比较，并监控它是否偏好更长、更自信或与自身风格相似的答案。
上线后也要保留人工抽样。尤其关注业务代价高、模型置信表达很强、解析器自动修复过、或动态检索分数接近阈值的请求。把确认后的失败加入开发集时，应另留新的保留样本，避免每次修复都把最终测试集变成训练题。
常见失败与修复
| 症状 | 可能原因 | 修复 |
|---|---|---|
| 总预测同一标签 | 标签不平衡或顺序偏置 | 分层选择、交错排列、看混淆矩阵 |
| 复制示例内容 | 任务与输入边界不清 | 使用明确标签并加入新输入标识 |
| JSON 偶尔无法解析 | 示例格式不一致 | 统一 schema，并做程序校验/重试 |
| 线上效果低于离线 | 示例不代表真实分布 | 从脱敏流量补充错字、缺项和长尾 |
| 模型升级后退化 | 提示行为发生变化 | 锁定模型版本并运行回归 |
| 成本明显升高 | 示例过长或重复 | 压缩但保留关键结构，比较最小集合 |
如果主要问题是指令冲突、上下文污染或模型没有工具权限，继续加示例通常治标不治本。可使用提示词故障排查流程定位根因；完整的任务契约和版本管理见Prompt Engineering 指南。
生产上线清单
- 任务、标签、schema、拒答和升级规则写成可测试契约。
- 所有示例都有稳定 ID、来源、审核记录和版本。
- 示例库与保留测试集严格隔离，避免数据泄漏。
- 比较 Zero-shot、固定 Few-shot 与动态方案，而非默认示例越多越好。
- 测试多种顺序、模型版本、温度和真实边界输入。
- 对示例和真实输入做清晰分隔，不执行其中的外部指令。
- 上线记录实际选取的示例 ID、顺序、模型和提示版本。
- 质量下降时能回滚到上一组示例和模型配置。
常见问题
示例越多越好吗？
不是。更多示例增加覆盖，也占用上下文并可能引入冲突、顺序偏置和成本。应从最小集合开始，用消融实验决定保留哪些。
Few-shot 会让模型永久学会任务吗？
不会。它不更新模型权重，下一次请求若没有携带这些示例，模型不会因为本次提示而永久保存任务。
应该选最相似还是最多样的示例？
没有通用答案。相似性帮助贴近当前输入，多样性帮助覆盖标签与边界；实际可先相似召回，再加入覆盖配额和质量过滤，并与固定基线比较。
能把用户好评的输出自动加入示例库吗？
不建议直接加入。用户反馈不等于事实或标签正确；必须脱敏、复核、去除注入内容并记录来源后，才能进入白名单。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。旧稿中的拟人化机理、虚构准确率/解决率、规则必然优于示例及强迫展示隐藏思维链等表述已删除；新版依据 GPT-3、示例选择、演示作用与顺序敏感性研究，以及 OpenAI、Anthropic 当前提示文档重建示例选择和评测流程。本站的来源、更新与纠错原则见关于本站与编辑规范。
