Google提示工程PDF拆解：从零样本到自洽性投票的实战指南

简介这份《google提示工程.pdf》面向具备一定编程基础、希望深入掌握大语言模型交互技巧的开发者、数据科学家与机器学习工程师系统讲解如何编写高质量提示词以提升模型输出的准确性与相关性。内容覆盖零样本、少样本、系统提示、角色提示、上下文提示、退步提示、思维链、自洽性、思维树与ReAct等主流技巧并延伸至自动提示工程APE、代码生成与调试提示、多模态提示等进阶主题。同时详解温度、Top-K与Top-P等输出配置参数以及提供示例、保持简洁、明确输出要求、优先使用指令而非约束等最佳实践还讨论了JSON输出格式的优势与挑战。资源包为1个PDF文件大小约1018KB结构完整、便于通读与检索。目前已有393人学习下载适合希望从入门到进阶系统梳理提示工程知识体系、对照实例优化自身提示词的读者参考。1. 从一份 Google 提示工程 PDF 说起它到底能解决什么问题很多人第一次接触提示工程是从零散刷到的「咒语」片段开始的某个 prompt 模板、某段角色设定、某个让模型输出 JSON 的小技巧。碎片看多了反而更乱——不知道哪些是通用原则哪些只是针对特定模型的玄学。这份 Google 提示工程 PDF 的价值就在于它把提示工程从「技巧合集」拉回到一套可复用的方法论从最基础的清晰指令、少样本示例到思维链、自洽性、逐步推理再到自动提示工程APE这类让模型自己优化提示的方向链条是完整的。它适合两类人一是刚上手大语言模型应用、需要一套系统参照的开发者二是已经在写 prompt、但输出不稳定、想搞清楚「为什么这次行下次不行」的从业者。下面我按「先立住原理、再动手复现、最后讲坑」的顺序把这份资料拆开讲透。2. 提示工程的核心机制为什么同样的模型换个问法结果差这么多2.1 从 token 预测到指令遵循模型到底在做什么要理解提示工程先得接受一个反直觉的事实大语言模型本质上是在做「下一个 token 的概率预测」它没有真正的「理解」只有基于上下文的模式延续。你给的提示就是它续写时唯一的条件。所以提示工程不是「跟人说话」而是「给一个概率分布设定初始条件」。这解释了几个常见现象。第一为什么指令越具体输出越稳定——因为条件约束越强模型可选的续写路径越少。第二为什么少样本示例few-shot有效——示例本质上是在上下文里「演示」你要的模式模型会顺着这个模式续写。第三为什么思维链Chain-of-Thought能提升推理任务准确率——把中间步骤显式写出来等于把一个大跳转拆成多个小跳转每一步的预测难度都降低了。这份 PDF 里反复强调的一个底层逻辑是提示工程的目标不是「让模型变聪明」而是「降低任务的歧义度」。模型能力是固定的你能改的是它接收到的条件。常见做法是在写任何 prompt 之前先问自己一句如果换成一个完全不了解背景的新人只看我的提示能不能做出我要的结果如果不能模型大概率也不能。2.2 零样本、少样本与思维链三种模式的选型依据这三种模式不是「越复杂越好」而是对应不同任务复杂度。选错了要么浪费 token要么效果反而下降。零样本zero-shot适合任务定义清晰、输出格式简单的场景比如分类、改写、翻译。它的前提是模型在预训练阶段见过足够多的同类任务。少样本few-shot适合输出格式有特殊要求、或者任务边界模糊的场景比如「按我们公司的语气写一段客服回复」。思维链CoT适合多步推理任务比如数学应用题、逻辑推断、需要拆解的规划任务。这里有个容易翻车的点思维链不是万能加成就。对于简单任务强行加「让我们一步步思考」反而可能引入多余步骤导致输出啰嗦甚至跑偏。我一般的判断标准是——如果这个任务人来做也需要打草稿那就上 CoT如果人一眼就能答就别加。下面这段代码演示了三种模式在同一个任务上的写法差异用的是常见的对话式调用结构你可以直接替换成自己用的 SDK# 三种提示模式对比以判断评论情感并给出理由为例 # 注意这里只演示 prompt 结构实际调用需替换为你自己的模型接口 # 1. 零样本直接给指令适合模型已熟悉的简单任务 zero_shot 判断下面这条评论是正面还是负面只输出正面或负面。 评论这个耳机音质不错但续航太短了。 # 2. 少样本给 2-3 个示例锁定输出格式和判断标准 few_shot 判断评论情感只输出正面或负面。 评论屏幕很清晰就是有点重。 情感正面 评论用了三天就坏了客服还不理人。 情感负面 评论这个耳机音质不错但续航太短了。 情感 # 3. 思维链要求先分析再结论适合需要权衡的模糊样本 cot 判断下面这条评论的整体情感倾向。 请按以下步骤 1. 列出评论中提到的所有优点和缺点 2. 判断优点和缺点哪个占主导 3. 给出最终结论正面/负面 评论这个耳机音质不错但续航太短了。逻辑说明零样本靠模型自身能力直接判断少样本通过示例把「判断标准」和「输出格式」同时固定下来减少格式漂移思维链把「权衡」这个过程显式化适合正负混杂的样本。参数上要注意的是少样本示例的数量不是越多越好2 到 5 个通常就够太多会挤占上下文窗口还可能让模型过度拟合示例的表面特征。思维链的步骤描述要具体到「列优点缺点」这种可执行动作而不是笼统的「仔细思考」。2.3 自动提示工程APE让模型帮你写提示自动提示工程是这份资料里比较进阶的一块。核心思路是既然提示的好坏可以用任务表现来衡量那就可以把「写提示」本身当成一个优化问题让模型生成候选提示、评估、再筛选。常见做法是三步第一步让模型根据任务描述生成一批候选提示第二步用一批带标注的样本测试每个候选提示的准确率第三步选表现最好的或者让模型基于失败案例继续改写。这个流程在有明确评估指标的任务上分类、抽取、格式转换效果比较明显在开放式生成任务上则不太适用因为「好」很难量化。我一般会把它用在两类场景一是需要批量处理、对稳定性要求高的抽取任务二是自己写了几版提示都不满意、想看看模型能给出什么不同角度的时候。要注意的是APE 生成的提示往往比较长、比较「啰嗦」上线前最好人工精简一遍否则 token 成本会上去。3. 把 PDF 里的方法落到代码一套可复现的提示迭代流程3.1 搭一个最小评估集没有评估就没有优化提示工程最大的坑是「凭感觉调」。改了一版提示看着输出顺眼了就以为变好了结果换个输入又崩了。要避免这个第一步不是写提示而是搭一个最小评估集。评估集不需要大20 到 50 条就够但必须满足两个条件一是覆盖你实际会遇到的主要输入类型包括边界情况二是每条都有你认可的「参考答案」或至少一个判断标准。对于分类和抽取任务参考答案可以是精确的标签对于生成任务可以是一个评分标准或者几个关键要点是否命中。# 最小评估集结构每条包含输入和期望输出 # 实际使用时建议存成 jsonl方便逐行读取和版本管理 eval_set [ { input: 订单号 20240315客户反馈收到商品有划痕要求退货, expected_intent: 退货, expected_urgency: 高 }, { input: 咨询一下这个产品有没有蓝色款, expected_intent: 咨询, expected_urgency: 低 }, { input: 发票什么时候能开出来已经等了一周了, expected_intent: 催办, expected_urgency: 中 } ] # 评估函数逐条跑提示统计命中率 def evaluate(prompt_template, eval_set, call_model): hits 0 for item in eval_set: prompt prompt_template.format(inputitem[input]) output call_model(prompt) # 这里用简单的包含判断实际可按任务改成精确匹配或结构化解析 if item[expected_intent] in output: hits 1 return hits / len(eval_set)逻辑说明eval_set是评估的基准evaluate把提示模板套到每条输入上调用模型后比对结果。参数上call_model是你自己的模型调用函数建议加上重试和超时控制避免单条失败影响整体统计。这个评估函数很粗糙但足够让你在改提示时有一个客观数字而不是靠印象。我一般会把每次改动的提示和对应得分记在一个表格里几轮下来就能看出哪类改动真正有效。3.2 提示模板的参数化把变量和指令分开很多人写提示是「一坨」写死的改一个地方要动整段。更好的做法是把提示拆成「固定指令」和「可变输入」两部分用模板变量隔开。这样既能复用也方便做 A/B 对比。# 参数化提示模板固定部分和变量部分分离 # 好处改指令不影响输入格式改输入不影响指令逻辑 INTENT_PROMPT 你是一个客服工单分类助手。 任务根据用户描述判断意图类别和紧急程度。 意图类别只能从以下选项中选择 - 退货 - 咨询 - 催办 - 投诉 紧急程度只能从以下选项中选择 - 高 - 中 - 低 判断标准 - 涉及金钱损失或明确不满的紧急程度至少为中 - 明确要求退货或赔偿的紧急程度为高 - 单纯询问信息的紧急程度为低 用户描述{user_input} 请严格按以下格式输出不要添加任何其他内容 意图类别 紧急程度程度 # 使用时只替换 user_input def build_prompt(user_input): return INTENT_PROMPT.format(user_inputuser_input)逻辑说明把类别选项、判断标准、输出格式都写进固定指令user_input作为唯一变量。这样做的好处是当你要调整判断标准时只改指令部分评估集和调用逻辑都不用动。参数上要注意输出格式的约束要「可解析」比如用固定的「意图xxx」前缀方便后面用正则或字符串切分提取结果。如果模型经常加多余的解释可以在指令里加一句「不要添加任何其他内容」但这句话不是万能的必要时还是要在解析层做容错。3.3 迭代记录表让每次改动可追溯提示工程是一个迭代过程没有记录就会陷入「改了又改回原点」的循环。我一般会维护一张简单的记录表字段包括版本号、改动内容、评估得分、备注。版本改动内容评估得分备注v1基础指令无判断标准0.62边界样本容易分错v2加入判断标准0.78催办类明显改善v3输出格式改为固定前缀0.81解析成功率提升v4加入 2 个少样本示例0.85投诉类仍有误判这张表的作用不是好看而是让你在得分下降时能快速定位是哪次改动引入的。常见做法是每次只改一个变量比如这次只加判断标准下次只改输出格式这样得分变化才能归因。如果一次改三四个地方得分涨了也不知道是哪个起了作用跌了更不知道回退哪个。4. 提示工程避坑五条血泪经验4.1 现象输出格式时好时坏解析经常失败原因模型对输出格式的遵循不是 100% 确定的尤其是当指令里同时有多个要求时模型可能顾此失彼。另外如果输出格式的约束只写在开头模型在长输出后容易「忘记」。解决把格式约束放在指令的最后靠近生成位置遵循率会明显提升。同时在解析层做容错比如允许前后有空白、允许大小写差异。如果任务对格式要求极高考虑用结构化输出能力如果模型支持而不是靠提示硬约束。4.2 现象少样本示例加了之后效果反而变差原因示例本身可能有偏差比如示例的分布和实际输入不一致模型会过度拟合示例的表面模式。另一个常见原因是示例太多挤占了上下文导致模型对当前输入的注意力下降。解决先检查示例是否覆盖了主要类别避免某一类示例过多。示例数量控制在 2 到 5 个并且定期用评估集验证加示例是否真的带来提升。如果加了没提升果断去掉。4.3 现象思维链让简单任务变得啰嗦还增加了错误原因思维链适合多步推理但简单任务强行拆步骤会引入不必要的中间环节每一步都可能出错错误还会累积。解决先判断任务是否需要「打草稿」。如果人一眼能答就别加 CoT。如果确实需要推理步骤描述要具体避免「仔细思考」这种无法执行的指令。4.4 现象换个模型原来的提示就不灵了原因不同模型在预训练数据、指令微调方式、上下文窗口大小上都有差异对同一提示的敏感度不同。在一个模型上调好的提示换模型后可能完全失效。解决不要把提示和模型绑死。把提示模板和模型调用分离换模型时重新跑一遍评估集根据结果微调。常见做法是针对每个候选模型维护一份评估得分选性价比最高的组合而不是默认用最贵的。4.5 现象提示越写越长效果却没提升原因提示长度和效果不是线性关系。过长的提示会稀释关键指令的权重还可能超出上下文窗口。很多「补充说明」其实是冗余的。解决定期精简提示把不影响评估得分的句子删掉。一个实用的判断方法是删掉某句话后重跑评估集如果得分不变这句话就是冗余的。我一般会在提示稳定后做一轮「瘦身」通常能砍掉 20% 到 30% 的长度效果不变成本下降。5. 进阶技巧用自洽性投票提升推理任务的稳定性当任务涉及推理、且对准确率要求较高时单次生成的结果可能因为采样随机性而不稳定。自洽性Self-Consistency的思路是让模型用相同的提示生成多次结果然后对最终答案做投票取出现次数最多的那个。这个方法在数学题、逻辑题上效果比较明显代价是调用次数成倍增加。具体做法是把温度参数调高一点比如 0.7让每次生成有差异然后跑 5 到 10 次提取每次的最终答案统计频次。下面是一个简化实现# 自洽性投票多次生成 答案聚合 # 适用于有明确最终答案的推理任务开放式生成不适用 from collections import Counter def self_consistency(prompt, call_model, n5): answers [] for _ in range(n): # 温度调高增加生成多样性 output call_model(prompt, temperature0.7) # 提取最终答案这里假设答案在答案之后 if 答案 in output: ans output.split(答案)[-1].strip() answers.append(ans) # 投票取最高频 if not answers: return None counter Counter(answers) return counter.most_common(1)[0][0]逻辑说明n是生成次数一般 5 到 10 次足够再多边际收益递减。temperature调高是为了让每次生成有差异如果温度太低多次结果几乎一样投票就没意义。答案提取部分要根据你的实际输出格式调整如果格式不稳定提取失败率高投票结果也不可靠。这个方法的成本是单次的 n 倍所以只用在真正需要的任务上不要滥用。我一般会先用评估集测一下单次生成的准确率如果已经很高比如 90% 以上就不上自洽性如果在 70% 到 85% 之间波动自洽性通常能拉到 90% 左右。从那以后我每次上推理类任务前都会先跑一遍单次基线再决定要不要加投票避免为了几个点准确率把成本翻好几倍。希望这份拆解能帮到你把 PDF 里的方法真正落到自己的项目里。本文还有配套的精品资源点击获取