个人主页： > for_ever_love__ <（欢迎各位大佬莅临😊）其他栏目: > 大模型开发从0到1 <其他栏目: > iOS项目总结大全 <其他栏目: > 我想学python了 <其他栏目: > iOS UI <文章目录Few-shot RAG 实战：给几个示例，模型就知道该怎么答一、什么时候需要 few-shot二、示例怎么挑才有效1. 示例要覆盖典型问题类型2. 示例答案要「标准到可以当模板」3. 示例的文档要和真实文档同源4. 数量克制：3~5 个足够三、few-shot 的拼接结构四、动态 few-shot：按相似度选示例五、示例也要版本管理六、常见坑小结Few-shot RAG 实战：给几个示例，模型就知道该怎么答普通 RAG 的 prompt 只告诉模型「依据文档回答」。但有些场景，光说不够——你希望答案有特定的格式、口吻、组织方式，模型却总答得五花八门。这时候，与其在指令里写一大段「要这样要那样」，不如直接给几个示范样例（few-shot）：看例子比听指令管用得多。这就是 Few-shot RAG：在 prompt 里塞入几个「（问题，参考文档，标准答案）」的三元组示例，让模型照葫芦画瓢。本文讲清楚它适合什么场景、示例怎么挑、以及工程上怎么管理。一、什么时候需要 few-shot不是所有 RAG 都要 few-shot。以下场景它特别有用：答案格式严苛：比如你必须输出 JSON、必须按固定字段、必须带特定标签。指令容易写不清，示例一目了然。领域口吻特殊：法律、医疗、金融文档，答案要符合行业表述习惯，给示例比写「请用专业口吻」精准。少样本冷启动：新上线的知识库，评测集还没攒够，用人工写的几个高质量示例快速拉齐基线。多语言 / 多风格切换：同一问题要中文答、英文答、或者口语化答，示例直接定调。反过来，如果是开放的事实问答、答案天然多样，few-shot 收益不大，还可能限制模型的灵活性。二、示例怎么挑才有效few-shot 的效果，七分看示例质量。几条原则：1. 示例要覆盖典型问题类型如果你的问答有「事实型 / 对比型 / 操作型 / 摘要型」四类，每类至少一个示例。模型会按最像的那个示例来对齐。2. 示例答案要「标准到可以当模板」示例的答案必须是你想让模型模仿的标杆：格式规范、引用到位、不啰嗦。一个脏示例会带歪一堆真实回答。建议示例由人工精心撰写，而不是随便抓一条历史回答。3. 示例的文档要和真实文档同源示例里的「参考文档」片段，应该和线上真实文档风格一致（同样的字段、同样的排版）。否则模型学到的「怎么组织答案」和实际文档对不上。4. 数量克制：3~5 个足够太多示例挤占上下文、抬高延迟，且模型容易「过度模仿」某个示例。一般 3~5 个覆盖不同类型即可。三、few-shot 的拼接结构把示例放在系统指令之后、真实问题之前：【系统提示】你是 XX 领域问答助手，依据参考文档作答。 【示例 1】 参考文档：[1] ... [2] ... 问题：XXX 答案：<标准答案> 【示例 2】 参考文档：[1] ... 问题：XXX 答案：<标准答案> 【真实输入】 参考文档：[1] ... [N] ... 问题：{真实 query} 答案：关键细节：示例的文档也要带[1][2]编号，和真实输入结构完全对齐，模型才能「照格式填」。真实输入最后以「答案：」结尾，引导模型续写（而不是再输出一遍问题）。示例的问题要和真实问题类型不同但格式相同，避免模型误以为示例就是答案。四、动态 few-shot：按相似度选示例固定示例有个问题：用户问 A 类，你给的示例却是 B 类，对齐效果差。进阶做法是动态 few-shot——从示例库里，挑和当前 query 最相似的几个示例拼进去。实现：defpick_few_shots(query_vec,shot_library,k=3):# shot_library: [(示例文本, 示例向量, 标准答案)]scored=[]fortext,vec,ansinshot_library:sim=cosine(query_vec,vec)scored.append((sim,text,ans))scored.sort(reverse=True)returnscored[:k]# 取最相似的 k 个代价是多一次「示例库 embedding + 检索」，但示例贴合度上来后，答案质量提升明显。适合对格式一致性要求极高的场景。五、示例也要版本管理few-shot 的示例本质是一种「软配置」：改一个示例，全体答案风格都可能变。所以：示例库存配置中心，不要硬编码在代码里；每次改示例，跑一遍评测集回归，确认 Faithfulness / Relevance 没掉；和 prompt 模板一样，做 A/B：有 few-shot vs 无 few-shot，用数据说话。六、常见坑示例答案本身有幻觉：示例是标杆，标杆错了全员错。示例上线前必须人工核验「答案每句都能在示例文档里找到」。示例和指令冲突：指令说「简洁」，示例却很长，模型听示例的。指令和示例要对齐，不一致时模型默认模仿示例。泄露答案：动态 few-shot 如果选到了和真实问题几乎相同的示例，等于把答案直接喂给模型，评测会虚高、线上却露馅。要过滤掉「和当前 query 相似度过高」的示例。上下文爆炸：每个示例都带文档，3 个示例可能比真实输入还长。可以示例里只用「问题+答案」不用完整文档，或示例文档只留关键句。小结Few-shot RAG 是用「示例」代替「啰嗦指令」的利器，特别适合答案格式严苛、领域口吻特殊的场景。核心是：挑 3~5 个覆盖典型类型、答案标杆化的示例，结构和真实输入对齐；进阶可做动态 few-shot 提升贴合度。记住——示例是软配置，要版本化、要评测回归，示例错了比没示例更糟。
个人主页： > for_ever_love__ <（欢迎各位大佬莅临😊）其他栏目: > 大模型开发从0到1 <其他栏目: > iOS项目总结大全 <其他栏目: > 我想学python了 <其他栏目: > iOS UI <文章目录Few-shot RAG 实战：给几个示例，模型就知道该怎么答一、什么时候需要 few-shot二、示例怎么挑才有效1. 示例要覆盖典型问题类型2. 示例答案要「标准到可以当模板」3. 示例的文档要和真实文档同源4. 数量克制：3~5 个足够三、few-shot 的拼接结构四、动态 few-shot：按相似度选示例五、示例也要版本管理六、常见坑小结Few-shot RAG 实战：给几个示例，模型就知道该怎么答普通 RAG 的 prompt 只告诉模型「依据文档回答」。但有些场景，光说不够——你希望答案有特定的格式、口吻、组织方式，模型却总答得五花八门。这时候，与其在指令里写一大段「要这样要那样」，不如直接给几个示范样例（few-shot）：看例子比听指令管用得多。这就是 Few-shot RAG：在 prompt 里塞入几个「（问题，参考文档，标准答案）」的三元组示例，让模型照葫芦画瓢。本文讲清楚它适合什么场景、示例怎么挑、以及工程上怎么管理。一、什么时候需要 few-shot不是所有 RAG 都要 few-shot。以下场景它特别有用：答案格式严苛：比如你必须输出 JSON、必须按固定字段、必须带特定标签。指令容易写不清，示例一目了然。领域口吻特殊：法律、医疗、金融文档，答案要符合行业表述习惯，给示例比写「请用专业口吻」精准。少样本冷启动：新上线的知识库，评测集还没攒够，用人工写的几个高质量示例快速拉齐基线。多语言 / 多风格切换：同一问题要中文答、英文答、或者口语化答，示例直接定调。反过来，如果是开放的事实问答、答案天然多样，few-shot 收益不大，还可能限制模型的灵活性。二、示例怎么挑才有效few-shot 的效果，七分看示例质量。几条原则：1. 示例要覆盖典型问题类型如果你的问答有「事实型 / 对比型 / 操作型 / 摘要型」四类，每类至少一个示例。模型会按最像的那个示例来对齐。2. 示例答案要「标准到可以当模板」示例的答案必须是你想让模型模仿的标杆：格式规范、引用到位、不啰嗦。一个脏示例会带歪一堆真实回答。建议示例由人工精心撰写，而不是随便抓一条历史回答。3. 示例的文档要和真实文档同源示例里的「参考文档」片段，应该和线上真实文档风格一致（同样的字段、同样的排版）。否则模型学到的「怎么组织答案」和实际文档对不上。4. 数量克制：3~5 个足够太多示例挤占上下文、抬高延迟，且模型容易「过度模仿」某个示例。一般 3~5 个覆盖不同类型即可。三、few-shot 的拼接结构把示例放在系统指令之后、真实问题之前：【系统提示】你是 XX 领域问答助手，依据参考文档作答。 【示例 1】 参考文档：[1] ... [2] ... 问题：XXX 答案：<标准答案> 【示例 2】 参考文档：[1] ... 问题：XXX 答案：<标准答案> 【真实输入】 参考文档：[1] ... [N] ... 问题：{真实 query} 答案：关键细节：示例的文档也要带[1][2]编号，和真实输入结构完全对齐，模型才能「照格式填」。真实输入最后以「答案：」结尾，引导模型续写（而不是再输出一遍问题）。示例的问题要和真实问题类型不同但格式相同，避免模型误以为示例就是答案。四、动态 few-shot：按相似度选示例固定示例有个问题：用户问 A 类，你给的示例却是 B 类，对齐效果差。进阶做法是动态 few-shot——从示例库里，挑和当前 query 最相似的几个示例拼进去。实现：defpick_few_shots(query_vec,shot_library,k=3):# shot_library: [(示例文本, 示例向量, 标准答案)]scored=[]fortext,vec,ansinshot_library:sim=cosine(query_vec,vec)scored.append((sim,text,ans))scored.sort(reverse=True)returnscored[:k]# 取最相似的 k 个代价是多一次「示例库 embedding + 检索」，但示例贴合度上来后，答案质量提升明显。适合对格式一致性要求极高的场景。五、示例也要版本管理few-shot 的示例本质是一种「软配置」：改一个示例，全体答案风格都可能变。所以：示例库存配置中心，不要硬编码在代码里；每次改示例，跑一遍评测集回归，确认 Faithfulness / Relevance 没掉；和 prompt 模板一样，做 A/B：有 few-shot vs 无 few-shot，用数据说话。六、常见坑示例答案本身有幻觉：示例是标杆，标杆错了全员错。示例上线前必须人工核验「答案每句都能在示例文档里找到」。示例和指令冲突：指令说「简洁」，示例却很长，模型听示例的。指令和示例要对齐，不一致时模型默认模仿示例。泄露答案：动态 few-shot 如果选到了和真实问题几乎相同的示例，等于把答案直接喂给模型，评测会虚高、线上却露馅。要过滤掉「和当前 query 相似度过高」的示例。上下文爆炸：每个示例都带文档，3 个示例可能比真实输入还长。可以示例里只用「问题+答案」不用完整文档，或示例文档只留关键句。小结Few-shot RAG 是用「示例」代替「啰嗦指令」的利器，特别适合答案格式严苛、领域口吻特殊的场景。核心是：挑 3~5 个覆盖典型类型、答案标杆化的示例，结构和真实输入对齐；进阶可做动态 few-shot 提升贴合度。记住——示例是软配置，要版本化、要评测回归，示例错了比没示例更糟。