面经策

如何选择和设计 Few-shot 示例以提升效果？ ​

  • 标签：Prompt、Few-shot 示例设计

🏛 业务架构师 ​

选择与设计 Few-shot 示例的方法，我按"选什么—怎么排—验什么"讲：

1. 示例怎么选（质量大于数量）：

  • 代表性：覆盖任务的主要输入形态（长/短、正式/口语、不同业务类别）——按业务分布采样，而非随手挑；
  • 边界示范：至少一个边界 case 示例（资料不足时如何拒答、模糊输入如何澄清）——边界行为靠示例教最有效；
  • 难度适当：示例太难（模型模仿不来）或太简单（没有信息量）都不行——选"中等偏难、能展示完整处理逻辑"的；
  • 数量控制：3~5 个通常最优——超过 5~8 个边际收益骤减，纯增加 token 成本；有明确分版的场景可按类别各给 1~2 个。

2. 怎么排（有讲究）：

  • 格式严格一致：所有示例的输入输出格式完全统一——格式不一致模型会随机模仿，输出稳定性崩塌；
  • 顺序影响结果：研究显示示例顺序改变可导致输出波动——重要场景做顺序敏感性测试；通常"最相关的示例放最后"（靠近用户输入，注意力更强）；
  • ** diversity 排布**：不同类别的示例穿插，避免同类扎堆让模型误以为"最近的都是这个类"。

3. 怎么验：示例集变更跑评测集回归——示例是提示词的一部分，同等的严谨度；线上 badcase 出现时，先看"是否缺这类示例"，把 badcase 转化为新示例是最高效的迭代。

成本提醒：示例是每次调用都付的常驻 token——高频场景做"示例精选+定期审计"（删掉不产生行为差异的示例）；或把稳定示例的范式通过微调固化，一劳永逸。

🏗 系统架构师 ​

Few-shot 示例的质量决定效果——我的设计五原则：

  • 代表性（覆盖决策边界）：示例要覆盖典型 case + 边界 case（易混淆对、反例）——模型从示例泛化判断标准，边界示例教它"什么不算"；只给正例不给反例，模型会过度泛化；
  • 多样性（防过拟合到伪模式）：示例间要有变化（不同长度、不同表述风格、不同难度）——高度相似的示例会让模型学到"表面共性"（都以某词开头就都归某类）；
  • 格式严格一致（输出契约）：示例的输出格式 = 你要的格式，分毫不差——模型的格式行为主要从模仿示例获得，示例间格式漂移 = 输出随机漂移；
  • 难度与数量梯度：3~8 个是常用区间；从简单到复杂排列（渐进难度有助于模型抓住规则演化）；超关键的约束可在最后一个示例后重申（尾部注意力）；
  • 公平性/偏差审查：示例的隐含倾向会被放大（姓名、地域、性别的伪关联）——生产上线前做偏差测试。

迭代方法（工程闭环）：

  • 错误驱动增补：线上 badcase → 转化为示例（"这个 case 之前错了，加进示例"）——示例库随失败进化，这是最高效的迭代路径；
  • 示例选择自动化：按与当前 query 的语义相似度动态选示例（检索式 few-shot）——固定示例集的覆盖有限，动态选择效果常更好（成本：相似度检索 + 缓存优化）；
  • A/B 验证：示例增删改动跑回归集——示例是"软训练"，影响难预测，必须数据说话。

成本提醒：示例吃输入 token 且每请求都付——Prompt Cache 前缀化（示例放稳定前缀）是标配；QPS 高 + 示例集稳定时，考虑把示例行为微调进权重（省掉这部分 token）。

💻 全栈开发专家 ​

Few-shot 示例的质量决定效果上限，我的设计与选择方法：

1. 示例要有什么（单个示例的标准）：

  • 代表性：覆盖任务的主分布（典型输入长什么样）；
  • 边界性：必须包含边界/异常示例（拒答、空输入、格式陷阱）——模型遇到边界的行为完全靠示例教，全放「正常例」的示例集=埋雷；
  • 正确且规范：答案本身准确、格式严格符合输出模板（示例里的瑕疵会被 1:1 模仿）。

2. 怎么选这 3~5 个（组合策略）：

  • 多样性优先：覆盖不同输入类型/长度/难度，别选三个长得一样的；
  • 难例优先：对模型易错的模式（多约束并存、需要拒答的）占一席；
  • 排列顺序：存在近因效应——最重要的模式放最后；可用评测集对排列做小搜索。

3. 动态示例选择（进阶，效果显著）： 静态示例对当前输入未必贴切——把候选示例库（几十条）入向量库，按当前 query 语义检索最相关的 3 条注入（KNN few-shot）：

python
examples = example_store.similarity_search(user_query, k=3)
prompt = template.format(examples=format(examples), question=user_query)

示例库随 badcase 持续扩充——few-shot 从「一次性设计」变成「可持续运营的资产」。

4. 数量与成本：3~5 个通常饱和，>8 个边际收益趋零还挤占上下文；示例与结构化输出配合（示例定风格，schema 定格式）。

反模式提醒：示例之间格式不一致（一个 JSON 一个散文）模型必然混乱；示例泄露敏感数据（真实用户信息）——上线前脱敏。