面试题 · 模型微调
在大模型推理过程中，何时应选择few-shot提示方式而非zero-shot或fine-tuning？其优势和局限性是什么？
Zero-shot、Few-shot 和 Fine-tuning 不是按“样本达到某个固定数量”自动切换。先建立覆盖正常输入、边界、拒答和分布外样本的评测集，再比较质量、延迟、单次成本、维护成本和隐私边界。没有这条基线，“Fine-tuning 天花板更高”或“10 个示例就够”都只是猜测。
| 方案 | 更适合的情况 | 主要代价与风险 |
|---|---|---|
| Zero-shot | 基座模型已经理解任务，指令和输出契约可以直接说清 | 最省上下文；复杂标签、特殊格式或隐含业务规则可能不稳定 |
| Few-shot / ICL | 少量代表性示例能澄清标签边界、风格或输入输出映射；规则变化快，需要按请求或租户切换 |
按学习路线查看教程、项目和面试题。
| 示例占上下文和输入成本；结果对示例选择、顺序、格式及当前输入的相似度敏感 |
| Fine-tuning | 任务长期稳定、调用量足够，提示已优化但仍有可重复的行为缺口；需要更短提示或控制特定模型 | 需要代表性的训练集、留出评测、训练与版本运维；数据偏差会被学进去，换基座后还要重验 |
Few-shot 的数量没有通用答案。一个示例可能足够，也可能放入几十个仍不稳定；应在目标模型、上下文长度和真实查询分布上测。动态示例检索还要防止召回错误、重复标签和把不可信内容当作指令。
Fine-tuning 也不是默认“深度适配后效果最高”。它适合修正稳定、可由高质量示例表达的行为问题，例如分类边界、固定输出风格或持续的指令遵循失败。若缺的是当天政策、库存、告警或可引用事实，应通过受权限控制的数据查询或 RAG 提供上下文；微调不能替代实时事实源。
场景切入
假设我们给电商客服做智能助手，客户问题格式五花八门：有直接问退款的，也有发一段截图描述故障的。如果只用零样本，模型有时候格式乱写；但全量微调成本又高。你觉得在什么情况下，用几条示例就够了？
层层追问
大模型在推理时，你是怎么选择提示方式的？……比如零样本、少样本和微调，你一般怎么权衡？……那如果任务模式很特别但标注数据只有十几条，你会选哪个？为什么？
直球架构
请比较一下零样本、少样本和微调这三种方式在大模型推理中的适用场景、优劣势。具体说，什么时候优先用少样本而不是微调？它的主要局限是什么？
我不会先给出“五个示例用 Few-shot、几百条数据就微调”这种固定分界。第一步是做一套代表线上分布的评测集，覆盖常规输入、边界、拒答和分布外样本，然后让三种方案在同一口径下比较质量、延迟、成本和维护复杂度。
如果基座模型已经理解任务，指令和输出契约也能直接说清，我先用 Zero-shot。它上下文最短、维护最简单。遇到特殊标签边界、固定格式或少量示例比文字规则更清楚时，再用 Few-shot。示例数没有通用答案，一个可能够，几十个也可能因为选择或顺序不合适而退化。示例还会占上下文和输入成本；动态检索示例时，要防止召回错例和把不可信文本当指令。
Fine-tuning 适合另一类问题：需求相对稳定，提示已经优化，但模型仍反复出现可由高质量样本表达的行为缺口，比如分类边界、固定风格或持续的指令遵循问题。它需要训练集、留出评测、版本管理和上线回归。数据有偏差，模型也会把偏差学进去，所以不能简单说微调的效果天花板一定最高。
还要把行为和事实分开。如果系统缺的是当天政策、库存、网络告警或需要引用的内部资料，我会用受权限控制的查询或 RAG 提供事实。微调权重不是实时数据库，也不能保证把事实更新到位。实际系统可以组合：RAG 给证据，Few-shot 给当前任务示例，Fine-tuning 改善稳定行为，但组合后仍要用评测证明收益。
隐私方面也不能说“示例只在请求里，所以结束后一定销毁”。数据是否进日志、保留多久、是否用于训练和在哪个区域处理，都取决于部署方式、服务条款和配置。敏感数据需要最小化、脱敏、权限控制、留存策略和审计。Fine-tuning 数据同样要做这些治理。
最后我的决策顺序是：先 Zero-shot 基线，再加经审核的 Few-shot；如果错误来自事实缺失就补检索，如果是稳定行为缺口且流量、延迟或成本值得才做 Fine-tuning。每次模型、提示、示例集或数据分布变化，都重新跑同一套评测。