完整题目
在大模型推理过程中，何时应选择few-shot提示方式而非zero-shot或fine-tuning？其优势和局限性是什么？
本文目录
何时选择Few-shot
优先选Few-shot的典型场景：
- 任务模式复杂但样本少：如特定格式的日志解析、领域术语翻译，10-20个示例即可定义模式，无需几百条标注数据做SFT
- 需求变化快/多租户场景：不同客户（运营商A/B/C）有各自格式规范，用动态示例切换比维护多个LoRA权重更灵活
- 冷启动阶段：快速验证PMF，避免重训成本
三方案对比决策：
| 维度 | Zero-shot | Few-shot | Fine-tuning |
|---|---|---|---|
| 数据需求 | 无 | 5-20条 | 数百-数千条 |
| 成本 | 最低（推理） | 低（推理+示例token） | 高（训练+部署） |
| 效果天花板 | 受基座能力限制 | 中（模式迁移） | 高（深度适配） |
| 时效性 | 即时 | 即时 | 小时-天级 |
核心优势
- 免训练适配：利用预训练阶段的ICL（上下文学习）能力，通过注意力机制"复制"示例模式
- 动态可控：同一模型，换示例即可切换任务风格（如从"严谨报告"切到"口语化总结"）
- 知识隔离：敏感数据不进权重，示例随请求销毁，满足华为政企客户的数据合规要求
关键局限
- 上下文长度硬约束：示例占token，压缩可用推理空间；长文档分析场景需权衡
- 示例质量敏感：错误示例会误导，边缘案例覆盖不足时泛化差
- 推理成本上升：输入token增加，昇腾/NPU场景需评估吞吐影响
- 无法学习新知识：仅做"模式迁移"，示例外的知识盲区仍存在（此时需结合RAG）
华为场景实践
典型如网络故障诊断：用Few-shot定义"故障现象→根因→处置建议"的输出格式，同时RAG注入实时告警知识库，既保证格式合规，又解决知识时效问题。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设我们给电商客服做智能助手，客户问题格式五花八门：有直接问退款的，也有发一段截图描述故障的。如果只用零样本，模型有时候格式乱写；但全量微调成本又高。你觉得在什么情况下，用几条示例就够了？
层层追问
大模型在推理时，你是怎么选择提示方式的？……比如零样本、少样本和微调，你一般怎么权衡？……那如果任务模式很特别但标注数据只有十几条，你会选哪个？为什么？
直球架构
请比较一下零样本、少样本和微调这三种方式在大模型推理中的适用场景、优劣势。具体说，什么时候优先用少样本而不是微调？它的主要局限是什么？
练习口述回答 · 约4分钟
- 本质是数据、成本、效果的三角权衡
- Few-shot适合模式复杂但样本少、需求变化快、冷启动场景
- 优势是免训练、动态可控、知识隔离
- 局限是上下文压力、示例质量敏感、推理成本上升
- 实际落地常跟RAG配合，各有分工
这道题其实是在问，当你面对一个任务，数据、成本、效果这三个维度怎么取舍。[[Few-shot]]不是银弹，它跟[[Zero-shot]]、微调有清晰的边界，实际落地往往要组合着用。
先说什么时候选Few-shot。最典型的场景是任务模式复杂但样本很少。比如解析特定格式的日志，或者领域术语翻译，你给10到20个示例，模型就能通过[[In-Context Learning]]抓住模式，不需要为了几百条标注数据跑一遍[[SFT]]。再一个是需求变化快的场景，比如多租户服务，不同客户有自己的格式规范，用动态示例切换比维护多个[[LoRA]]权重灵活得多，换示例就行，不用动模型。还有就是冷启动阶段，快速验证产品市场匹配，避免重训成本。
那跟Zero-shot和微调怎么划边界呢？你可以这么想：Zero-shot成本最低，但效果天花板受限于基座能力，任务太复杂它就搞不定。微调效果上限最高，但数据门槛高，需要几百上千条标注，训练和部署成本也高，时效性差，小时到天级别。Few-shot刚好卡在中间，5到20条示例，成本低，效果能通过模式迁移达到中等水平，而且即时生效。所以真正落地时，很少只用一种，往往是Few-shot加微调或者加[[RAG]]一起上。
优势这块，核心是免训练适配。模型在预训练阶段已经学会了上下文学习，你给几个示例，它会通过注意力机制去复制模式，不需要更新权重。再一个是动态可控，同一个模型，换套示例就能从严谨报告风格切到口语化总结，非常灵活。还有一个容易被忽略的点是知识隔离：敏感数据只出现在示例里，不进权重，请求结束后示例就销毁，这对政企客户的数据合规特别重要。
但局限也很明显。首先是上下文长度硬约束，示例占token，会压缩可用推理空间。比如做长文档分析，你本来就需要塞很多内容，再加示例可能就超限了，这时得权衡。其次是示例质量非常敏感，一个错误示例就可能把模型带偏，边缘案例覆盖不足时泛化会很差。还有就是推理成本上升，输入token增加，在昇腾或者NPU场景下要评估吞吐影响。最关键的是，Few-shot不能学习新知识，它只做模式迁移，示例之外的知识盲区它还是不知道。所以实际中我经常把它跟RAG配合：用Few-shot定义输出格式，用RAG注入实时知识库，各管各的。
举个例子，网络故障诊断。你可以用Few-shot定义“故障现象→根因→处置建议”的输出格式，让模型按这个结构回复。同时用RAG注入实时的告警知识库，这样既保证了格式合规，又解决了知识时效问题。
不过这里有个隐含前提：Few-shot的效果高度依赖基座模型的上下文学习能力，如果模型本身对示例的利用效率低，比如更倾向于依赖预训练知识而不是示例，那Few-shot的效果就会打折扣。这其实跟模型的训练数据和[[Instruction Tuning]]策略有关。