别再让RAG“裸奔”了给大模型喂几个“样板案例”回答准确率、格式稳定性、语气一致性直接起飞——从Zero-shot到Few-shot教你把检索回来的知识真正“驯服”成用户想要的模样。Few-shot提示在RAG中加入示例1 为什么RAG需要Few-shot2 示例从哪来检索与挖掘3 示例格式与结构4 数量与质量的博弈5 动态注入与静态模板6 效果评测与迭代零样本的局限示例的魔力文档库淘金Badcase回收Input-Output对思考过程链少即是多一致性过滤上下文动态拼接领域模板固化离线评估线上监控文字目录为什么RAG需要Few-shot零样本的局限与示例的魔力示例从哪来从业务文档与历史日志里“挖金矿”示例格式与结构给模型画一张清晰的“填空模板”数量与质量的博弈宁可三颗钻石不要三十颗玻璃珠动态注入与静态模板让示例“量身定制”还是“统一工装”效果评测与迭代没有数据反馈的优化都是玄学嗨大家好呀我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》154.[第16章 提示词工程与RAG] Few-shot提示在RAG中加入示例。有句话怎么说的来着“饭要一口一口吃代码要一行一行敲但大模型学你的业务逻辑你得先给它‘打个样’。” 很多刚入门的兄弟做完RAG demo看着检索器呼呼地往外吐文档就觉得“成了知识都给模型了它肯定能答好”。结果一上线回答要么像 Wikipedia 一样又臭又长要么像机器人念经要么格式崩得 downstream 系统直接报错。你急得抓耳挠腮模型却一脸无辜“你也没告诉我标准答案长啥样啊”这种焦虑我太懂了。今天咱们就掰开了、揉碎了聊聊怎么在RAG里加入Few-shot示例让检索回来的“生肉”变成用户爱吃的“熟菜”。1. 为什么RAG需要Few-shot零样本的局限与示例的魔力很多兄弟以为RAG就是“把知识喂给模型模型就能自动变聪明”。检索增强生成重点在“检索”和“生成”但你别忘了大模型本质上是个“概率游戏”。检索回来的文档是原材料可怎么炒这盘菜模型并不总是按你的心意来。Zero-shot也就是零样本提示就是你只给模型任务描述和文档不给它看“标准答案长啥样”。结果就像让一个新入职的员工直接上手没培训、没SOP全凭感觉。Few-shot说白了就是“给你看几个标杆案例你照着做”。在RAG里加入Few-shot不是锦上添花而是给检索到的知识装上“行为导航”。痛点分析你是不是也这样写过Promptpromptf 根据以下参考资料回答问题{retrieved_documents}用户问题{question}请直接回答 看起来简洁明了对吧但一上线各种问题扑面而来。用户问“这款手机的续航怎么样”模型把整篇评测文档的核心卖点全罗列了一遍从屏幕讲到芯片最后才提到续航答案跟流水账似的。你要求它输出JSON格式它给你来个Markdown列表。你让它用客服口吻它给你整得像论文答辩。为啥因为你只给了它“知识”没给它“规矩”。更坑的是RAG检索出来的文档往往碎片化、有噪声。Zero-shot状态下模型不知道该如何权衡这些碎片。它可能把A文档的开头和B文档的结尾拼凑出一个自相矛盾的答案。你以为RAG能兜底其实它只是在裸泳。解决方案咱们得在Prompt里塞几个“样板房”。Few-shot的核心就是展示“输入—输出”的映射关系。还是上面那个场景咱们改一改promptf 你是一个专业且友好的数码产品客服。请根据参考资料回答用户问题要求 1. 只回答与问题相关的要点不要发散 2. 语气亲切像和朋友聊天 3. 如果涉及参数请用通俗语言解释 4. 末尾标注信息来源。 ## 示例1 参考资料 [1] 该款手机搭载5000mAh电池支持67W快充续航测试可达8小时亮屏。 用户问题这手机电池耐用吗 回答挺耐用的它配了5000mAh大电池正常用一天没问题亮屏能坚持8小时左右还支持67W快充没电了也能快速回血~ [来源参数文档] ## 示例2 参考资料 [1] 本机采用6.7英寸OLED屏幕支持120Hz刷新率。 用户问题屏幕显示效果好吗 回答屏幕素质很棒哦6.7英寸大屏还是OLED材质支持120Hz高刷刷视频打游戏都特别丝滑~ [来源屏幕规格] ## 正式任务 参考资料{retrieved_documents}用户问题{question}回答 看到没模型瞬间就知道“哦原来要这么答”。示例给了它三个锚点格式、语气、引用规范。有了这些样例RAG检索回来的知识就有了“组装说明书”输出稳定性直接起飞。而且示例还能帮助模型理解“什么信息该忽略”过滤掉检索结果里的噪声。这就是从“有知识”到“会表达”的跨越。小结RAG负责让模型“有料”Few-shot负责让模型“懂规矩”。知识加上样例才是完整的交付物。2. 示例从哪来从业务文档与历史日志里“挖金矿”示例不能拍脑袋瞎编。很多新手坐在屏幕前凭想象写几个“理想型”问答对结果上线后发现真实用户的问题五花八门编的示例根本覆盖不了。好示例不是“造”出来的是从你的业务数据里“生长”出来的。痛点分析误区一闭门造车。你硬编了五个示例问题都是“产品怎么退款”“产品怎么使用”。上线后用户问的是“我同时买了A和B能不能合并退款”模型傻了因为示例里全是单一路径的简单问题。误区二示例和文档脱节。你编的例子基于旧版产品手册但RAG检索的是新版文档。结果示例在教模型“不支持XX功能”但检索回来的文档明明写着“已支持”。模型左右为难输出就开始 hallucinate幻觉。误区三示例太干净。现实中的文档有表格、有错别字、有口语化表达。你编的示例全是标准书面语模型遇到真实脏数据就懵了。解决方案兄弟去你的日志里挖矿第一招历史日志淘金。把过去半年的人工客服对话、线上QA日志拉出来。筛选那些“用户满意度高、回答准确”的会话提炼成问题, 回答对。这才是最真实的用户分布。第二招文档反向生成。把RAG要检索的文档切片用另一个小模型批量生成“如果用户问XX该怎么答”。比如# 伪代码从文档批量生成Few-shot示例forchunkindocument_chunks:qa_promptf 根据以下文档片段生成3个用户可能提出的问题以及标准答案。 要求问题要口语化答案必须严格基于文档内容不要发散。 文档{chunk}examplesllm.generate(qa_prompt)human_review_and_save(examples)生成后必须加一轮人工审核别让错误信息混进去。第三招Badcase变废为宝。线上测试时发现模型答错了别急着骂模型把这条记录下来。人工修正答案后它就是一个绝佳的Few-shot示例特别是针对那些容易踩坑的边缘问题。小结示例不是作文比赛是考古现场。越贴近真实业务地层模型学得越像样。3. 示例格式与结构给模型画一张清晰的“填空模板”有了好素材还得会摆盘。示例格式就是模型的“阅读理解题模板”。格式搭得乱模型看完一脸懵格式搭得清模型直接开启复制粘贴模式。痛点分析常见翻车现场把示例写成一坨自然语言没有任何结构分隔。示例用户问续航文档说5000mAh回答就是挺耐用的有5000mAh电池。模型看完根本不知道哪部分是“输入”、哪部分是“输出”、哪部分是“要求”。它可能把示例里的“回答”当成新的任务指令。还有一个大坑在示例里用了和正式任务一样的占位符名比如都用{question}结果模型把示例里的占位符也当成变量去解析或者直接混淆上下文输出的内容里带着莫名其妙的{question}原样文本。解决方案给示例穿上“结构化盔甲”。最稳妥的方式是用明确的标签做隔离few_shot_prompt 请根据提供的参考资料回答用户问题保持简洁和友善。 #### 示例1 [参考资料] 文档1本服务支持7天无理由退货需保证商品未拆封。 文档2退货时请保留原快递包装。 [用户问题] 我买错了能退吗 [标准回答] 可以的亲我们支持7天无理由退货只要商品没拆封保留好原包装就能申请退款啦~ #### 示例2 [参考资料] 文档1会员等级分为普通、银卡、金卡。 文档2消费满1000元升级银卡满5000元升级金卡。 [用户问题] 怎么升级会员 [标准回答] 您的消费累计达标就能自动升级哦目前分普通、银卡、金卡三档多多支持就能更快升级啦~ #### 现在轮到你了 [参考资料] {documents} [用户问题] {question} [标准回答] 看到没[参考资料]、[用户问题]、[标准回答]这就是给模型划分的“三界”。模型很清楚哦我在示例阶段看的是别人的作业现在轮到我写了。如果任务需要推理还可以在示例里加入思考过程Chain-of-Thought[思考过程] 1. 用户关心的是退货时间 2. 文档明确写了7天无理由 3. 需要提醒保留包装 4. 组织成口语化回答。 [标准回答] ...这种方式在复杂RAG场景里尤其管用相当于给模型看了“解题草稿”。小结示例的格式越像“填空题模板”模型的答案就越像标准答案。4. 数量与质量的博弈宁可三颗钻石不要三十颗玻璃珠很多人一听Few-shot有效就恨不得把整本习题册塞进Prompt。但上下文窗口就那么大示例太多不仅烧Token还会让模型“中间迷失”更麻烦的是劣质示例的破坏力远超你的想象。痛点分析典型错误在Prompt里塞了8个、10个甚至更多示例。结果呢Token爆炸。本来RAG检索回来的文档就占了不少空间再加上一堆示例上下文直接拉满API调用成本高得离谱响应还慢。Lost in the Middle。模型对Prompt中间位置的信息记忆力最差。你塞了10个示例真正被模型记牢的可能只有开头1个和最后1个中间的都白给了。示例打架。示例1要求“详细展开”示例5要求“一句话说完”。模型看了想摔键盘你们到底要怎样解决方案记住八字真言少即是多贵精不贵多。第一控制数量。对于常规RAG任务2到4个高质量示例通常足够。如果任务类型多样可以用“聚类代表”策略把你的历史问题用Embedding聚类分出“事实查询类”“比较类”“推理类”每类只挑1-2个最典型的示例。第二保持风格一致。所有示例必须遵循同一套输出规范。你不能一个带Emoji一个不带一个用JSON一个用纯文本。统一规范后模型才能稳定复现。第三做减法。定期审视你的示例库把失效的、过时的、效果差的剔除。示例库不是博物馆不需要保留历史文物。第四监控Token。拼接Prompt前先用Tokenizer数一下importtiktoken enctiktoken.encoding_for_model(gpt-4)full_promptbuild_prompt(question,docs,examples)token_countlen(enc.encode(full_prompt))print(f当前Prompt共{token_count}tokens)如果示例占比超过30%你就要警惕了。小结三颗钻石远比三十颗玻璃珠值钱示例贵精不贵多。5. 动态注入与静态模板让示例“量身定制”还是“统一工装”示例写死在代码里叫静态Few-shot根据用户问题实时去案例库检索相似的示例拼进去叫动态Few-shot。这两种打法差别巨大选错了场景效果大打折扣。痛点分析误区A一刀切的静态示例。你做了一个法律咨询的RAG把“离婚财产分割”的示例写死在Prompt里。结果用户问的是“劳动合同纠纷”模型还按照离婚案子的口吻和格式去回答驴唇不对马嘴。误区B盲目动态不做过滤。你建了个示例库用户一来随便检索几个示例就塞进去。用户问“Python怎么写Hello World”你塞进去的示例是“Java多线程并发优化”模型直接精神分裂。解决方案先想清楚你的业务场景。如果你的场景高度垂直、问题类型单一比如内部IT工单系统全是“服务器报错了怎么办”“VPN连不上怎么处理”那静态模板就够。好处是速度快、确定性高、省Token。代码里直接写死STATIC_EXAMPLES ## 示例1网络类 ... ## 示例2权限类 ... 但如果你的用户问题跨度大、领域广比如一个综合电商客服从3C数码到生鲜食品都有那你就得上动态注入了。动态注入的本质是再做一次RAG——不是检索文档而是检索“示例”。架构是这样的用户问题Embedding文档检索 Top-K Docs示例检索 Top-N ExamplesPrompt组装大模型生成伪代码实现defbuild_prompt(query,doc_store,example_store):# 1. 检索文档docsdoc_store.similarity_search(query,k3)# 2. 检索相似示例examplesexample_store.similarity_search(query,k2)# 3. 组装PromptpromptSYSTEM_PROMPTforexinexamples:promptf[参考资料]{ex.docs}\n[用户问题]{ex.query}\n[标准回答]{ex.answer}\n\npromptf[参考资料]{docs}\n[用户问题]{query}\n[标准回答]returnprompt动态注入的核心是“相似度匹配”。你的示例库也得向量化和用户Query算相似度确保给模型看的示例是和当前问题同频的。这样模型才能做到“看人下菜碟”。小结静态示例是工装普适但呆板动态示例是定制西装合身但需要好裁缝相似度算法。6. 效果评测与迭代没有数据反馈的优化都是玄学加了Few-shot感觉好像变好了别靠感觉要靠数据。没有评测体系的Few-shot优化就是盲人摸象。痛点分析很多团队的评测流程极其草率。找几条自己熟悉的问题肉眼看看觉得“嗯通顺了”就上线了。结果呢上线后用户投诉率不降反升。为啥因为你的评测集和示例库高度重叠模型只是在“背答案”不是真学会了。还有一个隐蔽的坑只评测“答案对不对”不评测“格式有没有崩”。你加了Few-shot想让模型输出JSON结果80%的时候是对的20%的时候模型忘了加闭合括号下游系统一解析直接报错。这种“软错误”比答错内容更致命。解决方案建立一套针对Few-shot的“体检报告”。首先评测集必须独立。从线上流量中随机抽样且这些样本绝对不能出现在你的示例库或训练集中。这叫 hold-out test。其次评测维度要全面维度说明建议指标忠实度答案是否基于检索文档Faithfulness Score相关性是否答非所问Answer Relevance格式合规JSON/Markdown是否可解析Pass Rate风格一致语气、长度是否符合预期人工/模型打分第三做对照实验。同一批问题跑两个版本V1是Zero-shotV2是Few-shot。用LLM-as-a-Judge或者人工标注来打分。只有V2显著优于V1你的Few-shot才算合格。第四建立迭代飞轮。线上每周回收Badcase分析是因为“示例缺失”还是“示例误导”。如果是缺失补同类示例如果是误导修正或删除。示例库是活的不是一锤子买卖。小结没有评测的Few-shot是玄学有数据反馈的Few-shot才能越养越精。写在最后同学们咱们今天把Few-shot在RAG里的玩法从头到尾捋了一遍。你会发现大模型应用开发拼到最后拼的不是算法多高深而是细节有多扎实。一个示例的选取、一段格式的打磨、一次评测的迭代这些看似琐碎的“体力活”才是决定产品体验的分水岭。很多新手总觉得自己是在“调Prompt”其实咱们是在“教模型做人”——教它怎么听话、怎么表达、怎么在复杂的现实世界里不迷路。这个过程没有捷径就是不断地试、不断地测、不断地从Badcase里长记性。所以啊别怕麻烦。每一个高质量的Few-shot示例都是你给模型铺的一块砖。砖铺够了路就稳了。编程之路不易但每一步成长都算数。保持好奇持续学习你也能成为代码高手。咱们下回见关注私信备注“资料代找获取”全网计算机学习资料代找例如:《课程2026 年多模态大模型实战训练营》《课程AI 大模型工程师系统课程 (22 章完整版 持续更新)》《课程AI 大模型系统实战课第四期 (2026 年开课 持续更新)》《课程2026 年 AGI 大模型系统课 23 期》《课程2026 年 AGI 大模型系统课 21 期》《课程AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》《课程AI 大模型系统实战课三期》《课程AI 大模型系统课程 (2026 年 2 月开课 持续更新)》《课程AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》《课程AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》《课程2026 年最新大模型 Agent 开发系统课 (持续更新)》《课程LLM 多模态视觉大模型系统课》《课程大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》《课程大模型智能体线上速成班 V2.0》《课程JavaAI 大模型智能应用开发全阶课》《课程PythonAI 大模型实战视频教程》《书籍软件工程 3.0: 大模型驱动的研发新范式.pdf》《课程人工智能大模型系统课 (2026 年 1 月底完结版)》《课程AI 大模型零基础到商业实战全栈课第五期》《课程Vue3.5Electron 大模型跨平台 AI 桌面聊天应用实战 (2025)》《课程AI 大模型实战训练营 从入门到实战轻松上手》《课程2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》《课程大模型训练营配套补充资料》