多模态大模型 few-shot

你手里有个图文任务——批量读票据、判图表趋势、给商品图打标签——直接问模型，结果时好时坏；加了一堆说明文字，还是不稳。这时候多数人会想到给几个示例，但示例放几张、挑哪种、顺序怎么排，没人说清。这篇不聊原理，只给一套能照着做的 few-shot 组装与排查流程。

手里有个图文任务，比如批量读票据、判图表趋势、给商品图打标签，直接问模型，结果时好时坏；你加了一堆说明文字，还是不稳。这时候多数人会想到给几个示例，但示例放几张、挑哪种、顺序怎么排，没人说清。这篇不聊原理，只给一套能照着做的 few-shot 组装与排查流程，从判断该不该上示例开始，一直到上线后怎么维护。

先说清一件事：few-shot 不是「多给几个例子就更准」的万能开关。示例本身占上下文、占图片 token，还可能把模型的输出风格锁死。所以整套流程的第一步不是「怎么加示例」，而是「这个任务到底该不该加」。后面每一节都围绕一个可执行动作展开，能直接拿去改你手上的提示词。

先判断：这个任务到底该不该上 few-shot

适合上 few-shot 的任务有个共同特征：判定标准靠人嘴说不清，但你看一眼就知道对错。比如区分「轻微划痕」和「明显磨损」，写十条规则总会有漏网的，给两三个示例模型反而抓得住边界。反过来，开放生成类任务（写文案、编故事）加示例会把输出风格锁死，模型只会模仿你给的那几个例子，失去多样性。

• 适合：输出格式固定、类别边界微妙、判定标准难用文字穷举，比如票据字段抽取、图表趋势粗判、商品图瑕疵分级。
• 不适合：开放生成类任务，示例会压缩输出空间；以及模型完全没见过的领域，示例也救不了，得换模型或补上下文。
• 先跑零样本基线：零样本已经能过就别加示例，示例有成本还可能引入偏差，跑一批固定样本比对再决定。
• 基线比对别凭单次手感，去 /tools/quality-check 用同一批样本跑一轮，看的是稳定性不是某一次的好结果。

挑示例：挑「边界样本」，不是挑「标准答案」

很多人挑示例的习惯是找最典型、最漂亮的那几个。这恰好是错的。示例的作用是划定边界，所以最该挑的是你平时最容易判错的那类样本。全是标准正例，模型会把所有东西都往正例上靠，遇到模糊样本就翻车。

• 每个类别尽量覆盖「明显正例」「明显反例」「模棱两可」三档，只给正例是最常见的错误。
• 示例的输入要和真实输入同分布：线上是手机随手拍，示例就别用影棚精修图，否则模型学到的判断依据在真实数据上失效。
• 数量先按每类一两个起步，上限取决于你模型的上下文和图片 token 开销，去 /tools/token-price-calculator 估一下每张图吃掉多少额度。
• 示例自己要先判对，你自己都拿不准的样本不要放进去，矛盾示例会让模型在两个规则之间摇摆。

排示例：顺序、标签和输出格式都要统一

示例挑好了，怎么排也有讲究。同一批示例换个顺序，结果可能就不一样。原则是把最接近当前待判样本的那个示例放在最后，模型对末尾内容的模仿倾向更强。如果每次待判样本差异很大，固定顺序反而更稳，别为了「贴近」频繁重排。

顺序

最接近待判样本的示例放最后，模型模仿末尾倾向更强；样本差异大时用固定顺序更稳。

标签位置

类别定义写在示例之前，示例内部只给图和判定结果，别塞解释。

格式一致

字段名、大小写、标点在每个示例里完全一致，不一致模型就随机挑一种。

理由字段

要模型给理由就单独放一个结构化字段，先理由后标签，否则理由会混进标签里输出。

还有一个容易被忽略的点：示例和待判样本之间要有明确分隔。如果格式上分不清哪段是示例、哪段是真正要判的输入，模型可能把待判样本也当成一个示例去模仿。用清晰的分隔标记，或者把待判样本放到最后并显式说明「以下是待判」。

图文配对：图片放哪、放几张、要不要压缩

图文任务里，图片和文字的顺序关系经常被搞乱。多图场景下，图片出现顺序和文字里提到的顺序必须一一对应，并且在文字里显式编号「图 1」「图 2」。不编号的话，模型张冠李戴是常事，尤其是几张图长得很像的时候。

1. 编号并对应多图任务里每张图显式编号，文字描述中按同一编号引用，检查顺序是否一致。
2. 控制比例示例图和待判图的尺寸比例尽量同一档，长宽比差异大时部分模型表现会掉。
3. 拆分任务同一张图既要读文字又要看版式，拆成两轮问，比硬塞进一轮稳得多。

跑一轮、改一轮：把失败样本变成新示例

示例集不是设计出来的，是迭代出来的。第一版按上面的方法搭好之后，别急着上线，先跑真实样本，把失败的和判得含糊的都挑出来。注意不是只看准确率那个总数，总数会掩盖具体错在哪。

• 跑 20 到 50 条真实样本，把所有判错、判得含糊的条目单独拉出来看。
• 给失败样本分类：看错图、理解错规则、格式跑偏，只有「理解错规则」这一类适合靠加示例解决。
• 把失败样本里的典型代表补进示例集，同时删掉一个已被覆盖的旧示例，保持总数稳定。
• 改完必须重跑同一批样本对比，把改动内容和结果记下来，否则几轮之后说不清哪次改动起了作用。

没效果时的排查顺序

加了示例还是不行，多数人第一反应是继续加示例或者换模型，这两个顺序都太靠后了。按下面这个顺序查，能省掉大量无用功。前两步解决不了，才轮到改任务定义和换模型。

1. 第一步 查输入图片有没有传错、多图顺序有没有乱、编码有没有被压过头，这类低级问题占失败原因的大头，先排除。
2. 第二步 查示例质量示例自己判得对不对，有没有两个示例规则互相打架，这种矛盾会直接让模型摇摆。
3. 第三步 查任务可行性同一张图你自己判两次都不一致，说明标准本身模糊，该改的是任务定义不是继续调示例。
4. 第四步 才考虑换模型去 /multimodal 对一下同类任务的适配情况，再决定是换模型还是换做法。

成本、失效边界与维护

few-shot 的成本主要藏在图片 token 上。示例图一多，单次调用成本就跟着涨。按量调用的场景，上线前先估一遍单次调用开销和预计调用量，具体单价和额度去 /price-watch 核对当时的数字，别用几个月前的印象做预算。

• 示例集不是写完就完事，判定口径变了就得同步改，否则模型和业务脱节。
• 不同模型对示例的敏感度差别很大，换模型时不能直接搬示例集，要重新验证。
• 分类判定场景保留一份固定的回归样本集，每次改示例都跑一遍，防止按下葫芦浮起瓢。
• 示例总量别无限增长，定期删冗余，保持每类重点清晰。

few-shot 不是把答案抄给模型，是把边界画给它看。