给大模型画个圈：用System Prompt立规矩，省下Few-shot的Token钱

给大模型画个圈用System Prompt立规矩省下Few-shot的Token钱上一篇我们聊了Few-shot少样本提示。那招确实好用给个例子大模型就能照猫画虎出来的格式规规矩矩。但是呢Few-shot有个很现实的问题就是费Token。你每次发请求都得把那个好几百字的样例带在消息历史里。如果你一天跑一千次请求这个样例你就重复传了一千遍。这都是白花花的银子啊。而且有时候我们不需要那么复杂的例子我们只想让大模型守点基本规矩。比如别写废话、别乱猜原因、必须用列表输出。这种全局性的规矩有没有更省事、更省Token的办法来约束它当然有。今天我们就来深挖一下System Prompt系统提示词。这玩意儿就像是大模型的紧箍咒念上之后它就不敢造次了。一、 上回书说到Few-shot的痛点每次都要带例子Token烧得慌1.1 回顾Few-shot的套路上回我们在代码里往messages列表里塞了虚拟的对话历史。一条是样例提问一条是样例回答。这套路没毛病大模型看到历史就知道该按什么套路出牌。但是你算过账没有假设你的样例输入加上样例输出一共有400个字。这400个字在API调用里大概就是五六百个Token。你每次请求真实的业务数据这五六百个Token是雷打不动要带上的。如果你的业务并发量很大比如一个小时查一千次数据。这一个小时光传样例废掉的Token就有五十万。一天下来就是上百万Token。去后台 https://ai.timecho.com/settings/keys 一看账单这钱花得你肉疼。1.2 样例里的格式规矩其实是不变的你再仔细想想我们在样例里写的那些东西核心目的是什么其实主要就两个。第一是教它推理逻辑。这个必须用样例没辙。第二是教它输出格式。比如“必须列1234点”、“必须用【】做标题”。这第二条其实是一种死规矩。不管你查什么数据我都要求你这么排版。那既然是死规矩我们干嘛每次都要用样例去示范呢我们直接用大白话告诉它不就行了这就轮到System Prompt出场了。二、 什么是System Prompt凭啥它说话最管用2.1 大白话解释大模型脑子里的底层出厂设置在API的messages列表里消息的role除了user和assistant还有一个叫system。System Prompt跟普通的User提问不一样。User提问是临时起意问完就完了。System Prompt是系统级的指令它会在大模型生成每一个词的时候都像幽灵一样飘在它脑子里提醒它。你可以把它理解成你给这个大模型设定的“人设”或者“宪法”。如果你不设System Prompt大模型的人设就是个没受过训练的网民它想怎么回就怎么回。如果你设了System Prompt比如“你是一个严谨的运维工程师”那它在想乱说话的时候就会掂量掂量这不符合工程师的身份啊然后重新组织语言。2.2 优先级最高模型必须先满足System的约束在技术底层大模型对System的指令注意力权重是最高的。也就是说如果User让它往东System让它往西大模型大概率会往西走。System的约束力最强。这就给我们立规矩提供了完美的工具。我们把那些必须遵守、不能变通的格式要求和边界条件统统写进System Prompt里。这样我们就不需要在每次的User提问里反复唠叨也不需要在Few-shot样例里占篇幅了。三、 怎么写一个靠谱的System Prompt写System Prompt是个手艺活。写得太短不管用写得太长大模型会抓不住重点甚至直接遗忘。通常来说分三块来写最稳妥。3.1 定人设你到底是个啥角色第一块告诉它你是谁。角色定了说话的口吻和深度就定了。比如你写“你是一个拥有10年经验的企业级时序数据运维专家。”这句话不是废话。大模型见到“10年经验”和“运维专家”它调动出来的内部知识就不一样。它就不会用小学生的口吻跟你说“这个数字变大了”它会用专业的术语说“指标呈现上升趋势疑似触发阈值”。如果你做的是金融分析你就写“你是资深量化研究员”。人设一定要贴合你的业务。3.2 定格式输出必须长啥样第二块把死规矩写死。这是我们用来省Few-shot Token的关键。比如我对报告的格式要求是极其严格的我就可以这么写“你的输出必须严格遵守以下Markdown格式## 异常检测概要- 异常时间点 - 异常指标## 关联分析分析过程## 根因推测推测结论严禁输出任何上述格式之外的废话。不要写‘好的这是您的报告’之类的客套话。”你看这段话一贴大模型就不敢随便写散文了。它只能老老实实地填你给的框。这个效果跟你在Few-shot里给个样例是一模一样的。但是它只需要写一次不需要每次都带样例数据。3.3 定边界什么话绝对不能说第三块是防守。大模型有个毛病就是爱胡编。当它不知道原因的时候它也硬编一个原因给你这叫幻觉。我们在System里必须严禁这种行为。“规则如果根据现有数据无法推断出根因你必须明确回答‘信息不足无法推断’绝不允许猜测或编造看似合理的解释。”这就是给它的红线。有了这条线它在没把握的时候就会认怂而不是一本正经地胡说八道。认怂我们可以再去查数据胡说八道就会误导老板决策。四、 动手把System Prompt塞进代码4.1 在messages列表的第一位插入system消息按照API规范System Prompt必须放在messages列表的第一位。你不能把它插在中间或最后。我们写一段代码把System定义好defbuild_messages_with_system(real_data_text):# --- 第一步立规矩 (System Prompt) ---system_prompt 你是一个拥有10年经验的企业层级里的时序数据运维专家。 你的输出必须严格遵守以下Markdown格式不要输出任何其他内容 ## 异常检测概要 - 异常时间点 - 异常指标与数值 ## 关联分析 对比相关指标的步骤 ## 根因推测 给出最可能的1-2个原因 规则 1. 严禁输出“好的”、“没问题”等客套话。 2. 如果无法推断根因必须写“信息不足无法推断”绝不允许猜测。 # --- 第二步用户的真实提问 ---user_promptf请分析以下时序数据找出异常并推测原因\n{real_data_text}# --- 拼装Messages列表 ---messages[{role:system,content:system_prompt},# 必须放第一位{role:user,content:user_prompt}]returnmessages你看那个system_prompt里面人设、格式、红线全有了。而且我故意把格式写得非常具体连Markdown的二级标题符号##都给出来了。大模型只要照着填空就行。4.2 结合之前的Function Calling框架测试效果如果你把我们之前写的Function Calling框架拿出来把这段带System的messages塞进去你会发现大模型调用工具的精准度也提高了。为什么因为你在System里告诉它它是“资深专家”了。资深专家在查数据的时候是不会瞎查的。它给出的SQL参数会更合理它调用的次数也会更克制。你跑一下看看出来的报告绝对是干干净净没有一句废话格式完美符合你的Markdown要求。而这一切你根本没花一个Token去给Few-shot样例。五、 System Prompt和Few-shot该怎么选能不能一起上讲到这你可能有个疑问既然System这么牛那还要Few-shot干嘛5.1 System管宏观规矩Few管微观套路它们俩的分工是不一样的。System Prompt是宪法管的是大方向。什么不能干必须按什么大类格式干这归System管。但是具体的业务推理套路System管不了。比如CPU飙高到底是先看内存还是先看网络这个推理链条你用自然语言在System里写不清楚。你写个几百字的推理步骤大模型根本记不住它会遗忘。这时候就得Few-shot出马了。你在Few-shot的样例里展示一次从CPU高 - 查内存 - 发现也高 - 推断是GC的完整链路。大模型看一眼样例就懂了。5.2 混合双打的威力演示最爽的玩法是System和Few-shot一起上。System把格式框死Few-shot把逻辑教明白。而且有了System兜底你的Few-shot样例就可以写得很精简。你不需要在样例里再写一遍格式要求了因为System已经管了。你的样例可以缩水成这样样例输入CPU 88% (10:02), Memory 85% (10:02) 样例输出关联分析CPU与内存同涨。根因推测内存泄漏导致频繁GC。你看样例里连Markdown标题都不用写了只写核心逻辑。这省了多少Token格式的事全交给System去约束就行了。这就像你带徒弟System是员工手册告诉他上班别迟到、报告必须用Word写。Few-shot是老员工教他怎么填这个Word模板里的坑。两者结合徒弟带得又快又好。六、 System Prompt的坑规矩立太多模型会精神分裂System虽好但也不能滥用。如果你在System里塞了十几条互相打架的规矩大模型直接就摆烂了。6.1 自相矛盾的指令比如你在System里写“输出必须极其详细不少于500字。”接着你又写“严禁输出废话必须简短不超过100字。”大模型一看这就懵了。到底让我写长还是写短最后它可能精神分裂前半段写长后半段强行截断出来的东西莫名其妙。所以System里的规矩一定要互相兼容。你要详细就别嫌长。你要简短就别要求面面俱到。6.2 超出它能力范围的硬性要求还有些规矩大模型客观上做不到你硬写进去也没用。比如你在System里写“你的分析必须100%准确绝不允许出现任何误差。”大模型是概率模型它不可能100%准确。你写这句它只会学会伪装。它会把那些不靠谱的结论包装得像100%靠谱一样输出来。这反而增加了隐蔽的幻觉更危险。正确的写法是我们在前面定的边界“如果不确定就明说”。允许它认错它反而更诚实。七、 去官方文档和Playground里找灵感7.1 看看文档里有没有推荐的System写法写System Prompt没有标准答案不同的模型对指令的敏感度也不一样。建议你去翻翻开发文档https://ai.timecho.com/docs/。看看官方有没有给出一套针对时序分析的最佳实践System模板。有时候官方在文档里会给一段示例代码里面那个System Prompt写得特别地道。那是人家根据模型调优过的你直接抄过来用比自己瞎琢磨强一百倍。7.2 在示例页面里测试不同System Prompt的威力还有一个好去处就是应用示例页面https://ai.timecho.com/realtime。虽然网页端可能没法显式地让你设System字段但你可以把System的指令放在提问的最前面用个特殊符号括起来比如[System指令...]。你试着换几种System指令看看模型的输出变化有多大。你可以测测写“你是个暴躁的运维”和“你是个温柔的运维”出来的口吻有啥区别。这能帮你直观地感受System Prompt的威力。八、 总结与下期预告8.1 提示词工程三板斧凑齐了到今天这篇我们关于提示词工程最核心的三板斧就凑齐了。第一板斧是明确的指令这我们在前面就用了。第二板斧是Few-shot样例教它照猫画虎。第三板斧是System Prompt给它立规矩画圈。这三招配合起来大模型基本就被你拿捏得死死的了。它该查数据就查数据该出报告就出报告格式规范逻辑严密不废话不瞎编。这才是一个合格的AI员工该有的样子。8.2 下期我们讲讲怎么让它输出纯JSON对接下游系统今天我们让大模型输出了规整的Markdown报告。这对人看是爽了但是机器看不懂啊。如果你的下游还有个自动化脚本要去解析大模型的结论自动发报警或者重启服务。那个脚本怎么去读Markdown很难读。脚本只认识JSON。那怎么逼着大模型不输出人看的Markdown只输出机器看的JSON呢这就需要用到更硬核的约束手段了。下一期我们就来聊聊怎么开启JSON Mode彻底锁死大模型的输出格式。我们下篇见。