考察点
这道题看的是你对「上下文学习」（in-context learning）的实操理解。很多人以为示例随便抄两个就行，面试官想知道你是否清楚示例的相关性、多样性、数量、顺序各自的影响，以及线上系统怎么做动态示例选择。追问可能往「示例错了会怎样」「和微调比示例的边界在哪」走。
参考答案
示例选择的原则
示例质量比数量重要得多，选择时看四个维度：
- 相关性：示例要和当前输入的任务分布一致。做电商评论分类，就别放新闻情感分析的示例。更进一步的做法是按输入动态检索示例——把候选示例库做 embedding（比如 bge-m3），运行时拿当前输入去召回最相似的 K 条，这就是动态 few-shot，在分类、NER 这类任务上比固定示例稳不少。
- 覆盖度：示例要覆盖主要类别和典型模式，同时有意识地放 1-2 个边界 case（容易误判的样本），教模型划清界限。
- 标签均衡：分类任务里各类别示例数量尽量均匀。示例标签分布偏斜，模型输出也会跟着偏——比如三个示例里两个是「正面」，模型会有预测正面的先验。
- 格式一致性：示例的输入输出格式必须和期望完全一致，包括标点、字段名、大小写。模型对格式的模仿能力极强，示例里写错一个字段名，输出就会跟着错。
数量的影响：边际递减且占预算
示例不是越多越好。经验上 2-8 个是常见区间，简单任务 1-2 个就够，复杂格式或细粒度分类可能给到 8-16 个。超过一定数量后准确率提升趋于平缓甚至下降，原因有两个：示例占据上下文窗口，挤压了真正的输入和检索内容；示例之间的相互干扰增多，模型可能被示例中的巧合模式带偏（比如所有示例的答案都恰好是第二个选项）。
另一个要算的账是成本：每个示例都参与每次推理，10 个示例共 2000 token 的话，一百万次调用就多烧 20 亿输入 token。高频调用场景这个量级必须权衡，有时候把示例省下来换微调反而划算。
顺序的影响：真实存在且可利用
模型对示例顺序敏感，这是公认现象。两个可操作的结论：
- 相似度高的示例放后面。自回归生成更依赖邻近内容，把和当前输入最相关的示例排在靠近待处理输入的位置，效果通常优于随机排列。
- 避免顺序引入的偏差。如果示例按标签排序（前三个正面、后三个负面），模型可能学到「位置」和「标签」的虚假关联。随机打乱或者按相似度排，都比按标签聚堆好。
对顺序极度敏感往往说明模型没真正理解任务，这时候该做的是换更好的示例或者上微调，而不是继续调顺序碰运气。
一个落地做法
线上分类系统的典型实现：离线把标注好的几百条示例向量化入库；在线请求进来，检索 top-5 相似示例，按相似度从低到高排列（最高的紧贴输入），拼进 Prompt；定期用 badcase 补充示例库，把新出现的错误模式做成示例喂回去。这套东西成本不高，但对长尾 case 的改善立竿见影。
可能的追问
- 示例里的答案是错的会怎样？ 模型对示例的模仿强于对指令的服从，错误示例会直接带歪输出，甚至可能比没有示例更差。这引出一个工程要求：示例库必须经过人工审核，和训练数据同等对待。
- 动态 few-shot 的检索质量差怎么办？ 检索不准时宁可回退到固定的精选示例；也可以加一层判断，相似度低于阈值就不注入示例。另外 embedding 模型要和业务领域匹配，通用 embedding 在专业领域召回质量可能很差。
- 什么时候 few-shot 到头了，该上微调？ 示例数量加到十几个效果还是不动、格式仍然不稳定，或者示例 token 成本高到不划算，就是微调的信号。示例本质是「每次推理时临时教学」，稳定、高频、模式固定的任务教一次（微调）更经济。