Production

网上很多教程在讲怎么写 prompt，但写完之后怎么评估、怎么调到能上生产环境，反而很少有人讲。最近刚好做完一个生产级意图识别项目，可以拿来聊聊。 一、先把秤搬出来 调 prompt 的时候，大多数人其实没在评估，凭感觉挑几条 case 跑跑，看着跑通就觉得没问题。但手挑的几条 case，远远覆盖不了模型可能犯错的方式。一条新规则可能修好了你想到的几个 case，但同时把你没注意到的另一类拖下水了。等到上线之后跑全量才发现指标根本过不了，只能紧急下线回炉。调prompt第一步不是动 prompt，是先把评测集建好。 我们项目里用了两份评测集。 评测集 A：全是边界 case，业务方一条条过、一条条拍板答案。规模小但口径权威，用来盯"模型在那些模棱两可的地方到底怎么判"。 评测集 B：从线上日志按真实分布抽样，用 LLM judge + 人工抽检校准答案。规模大，用来盯整体分布上的表现。 两份是互相牵制的。只盯 A，模型容易被调成"擅长边界但日常 case 退化"，因为你每次都在拿边界 case 优化，prompt 会越来越往边界倾斜，正常分布上的表现有可能掉。只盯 B，整体看着涨了实际边界全崩，因为分布集里边界 case 占比小，整体指标对边界不敏感，你看不到的地方边界已经在退化了。两份一起跑，每次改完同时看两个指标，谁退化都立刻能感觉到。并且对标线上分布的数据变化远比"我觉得这版更好"更有说服力。 Anthropic 的 prompt engineering 文档里也是同样的观点，原话是 “Prompt engineering is far more empirical than traditional software engineering”（prompt 工程比传统软件工程更依赖实证）。 二、错的 case 别一条一条改 评测集建好之后，第一次跑全量，错一片很正常，但不要每错一条就在 prompt 里加一条规则或者一条 few-shot 去针对它。错十条加十条，错二十条加二十条。这样加完以后，规则之间互相干扰，prompt字数暴增，模型很容易找不到重点，输出反而退化。 正确的做法是先给错误归类，再修。归类完你会发现，二十条错可能就几种类型，比如"规则和 few-shot 在打架"或者"某条规则太宽，触发条件没限定"，也可能真值本身就有歧义。这样按类改，一条规则能覆盖多类 case，比一条 case 加一条规则效率高得多。 归类完，就可以开始修了。 三、规则 vs Few-shot：跑一组 A/B 就别争了 但是该改规则，还是加 few-shot呢？在我们项目里做过一次严格对照：一版以规则为主、few-shot 兜底；另一版以 few-shot 为主、规则简化。两版同时上同一套评测集，结果如下： 版本 字符数 评测集 A 评测集 B 重规则版 3029 90.2% 94.6% 重 few-shot 版 4055 85.4% 87.5% 规则版的精确率优于few-shot版，因为规则能表达否定，而 few-shot 不行。“X 不算 Y"用规则写一句话就完了；用 few-shot 你得给每种反例都配一条，根本配不完。而画边界恰恰主要靠"否定”。所以规则管定义，few-shot 管边界，这俩搭配最合适。 Anthropic 关于 multishot prompting 的文档也是这个意思，原话是： Use examples that cover edge cases, not common cases. 那 few-shot 还要不要？要。每个候选标签至少留一条，作用是让模型"记住这个标签存在"。否则你会发现某个标签模型几乎不输出。不是它判错，是它压根想不起来这是个选项。 选 few-shot 还有几个具体心得。第一，用线上真实分布的 case，不要用被前置规则（正则、关键词）已经拦掉的标准句式。早期我们放过一些非常"教科书"的 case，后来发现这种 query 在正则那一层就被拦走了，LLM 永远见不到，这条 few-shot 等于纯浪费字符。第二，相似的别堆，两条句式高度相似只是换了名词的 case，留一条就够，两条都放反而会让模型在浅层特征上建立虚假相关。第三，数量别贪多，简单任务 3-5 条够用，多标签复杂任务经验值是 10-20 条，再多就开始边际递减，越过某个临界值甚至会倒挂，越加越差。 主力靠规则，那是不是规则越多越好？不是。 四、Prompt 不是越长越好 我们记录了几版 prompt 的字符数和评测数据： Prompt 字符 评测集 A 评测集 B 5989 61.0% — 3751 75.6% 97.8% 3029 90.2% 94.6% 2919 90.2% 95.7% 字符最长那版比字符最短那版效果差了将近 30%。 直觉上 prompt 越详细模型应该越懂，为什么反过来？一是规则太多，每条规则的分量都被稀释，规则之间还可能互相冲突，结果模型要么遵循不过来往"安全"标签（比如 unknown）上躲，要么干脆把某些规则当背景噪声忽略了。二是 few-shot 多了反而误导模型，例子超过某个数量后，模型会从无关特征里学到错误的关联。比如两条例子句式相似但属于不同类别，模型可能抓着句式不放，忽略了真正决定标签的语义。 数据已经说明 prompt 不是越长越好。那 prompt 偏长的时候，怎么精简？ 首先最先删的是重复内容，同一件事在规则里说过又在 few-shot 里举过、多条规则讲的其实是同一件事、多条 few-shot 句式高度相似，这些都只留一处。其次是用不到的内容，被前置规则或路由层处理掉的 case、不会传入的字段、不会触发的模式，整段删掉，因为模型根本见不到。最后是冗长表达，能 8 个字说清的不要写 20 个字，输出格式之类的指令尽量两行写完。每删一段都要跑一次评测确认不掉点。按这个顺序删下来，效果可能更好，因为删的本来就是噪声。 最后 整个流程串起来：建评测集 → 错误归因 → 选规则还是 few-shot → 调长度。每一步是下一步的前提。 顺序对了，技巧网上一搜就有；顺序错了，技巧再多也没用。