2024 年我做一个用户反馈分类功能——用户提交的每一条反馈,自动归到"Bug 报告""功能建议""使用咨询""情绪吐槽"四类里的一类,方便团队分流处理。第一版我做得很顺手:写一段任务说明发给模型——"请把下面这条用户反馈分到这四类中的一类"。本地测了几条,有的对有的错,效果飘忽。我想起 few-shot 这个技巧:给模型几个例子,让它照着做。于是我在提示词里塞了几个"反馈 + 它属于哪类"的示例。一加上,准确率肉眼可见地涨了,我心里很笃定:few-shot 嘛,就是多给几个例子,例子越多模型学得越像,这分类功能稳了。可等真正用起来,一串问题冒了出来。第一种最先把我打懵:我加的例子里,"Bug 报告"那一类碰巧多了两条,结果模型开始把一些明明是"功能建议"的反馈,也硬归成 Bug。第二种最难缠:我只是把例子的先后顺序调了一下,内容一个字都没改,分类结果竟然变了。第三种最头疼:遇到一条我例子里没覆盖到的、有点边角的反馈,模型不会说"拿不准",而是硬套了一个跟它最像的例子的标签。第四种最莫名其妙:我有个例子的输出格式手滑写得和别的不一样,结果模型的输出格式也跟着乱套了。我盯着这一连串问题想了很久,才彻底想明白:第一版错在一个根本的认知上。我以为few-shot 就是"多给模型几个例子做参考"——例子是放在那儿给模型查阅的资料,越多越全,模型答得越准,我只要把例子凑够数就行。可这个认知是错的。few-shot 的例子,根本不是"参考资料",它是给模型的一套"行为示范"。模型不会挑挑拣拣地"参考"你的例子,它会整体地、不加区分地模仿例子里的一切——你想让它学的(任务该怎么做),和你没想让它学的(标签的分布、例子的顺序、输出的格式、用词的偏好),它一起学了去。要把 few-shot 用扎实,根上要明白:例子是一种极强、且很容易反噬的引导,你要管的不是"例子的数量",而是"例子在示范什么"。本文从头梳理:为什么"加几个例子"不等于效果就变好,few-shot 到底在做什么,例子怎么选,例子的顺序和格式有什么讲究,什么时候 few-shot 反而不如 zero-shot,以及一些把它做扎实要避开的工程坑。
问题背景
先把 few-shot 和 zero-shot 这两个词说清楚。zero-shot,是你只给模型一段任务说明,不给任何例子,让它直接做。few-shot,是你在任务说明之外,再给模型几个"输入—输出"的示例,让它照着示例做。few-shot 通常能提升效果,所以它被当成一个"几乎无害的加分技巧"——但这正是第一版踩坑的地方。
错误认知是:例子是给模型查阅的参考资料,越多越准,凑够数就行。真相是:例子是行为示范,模型会整体模仿示例的一切特征,而不只是你心里想的那个"任务逻辑"。把这一点摊开,第一版的几类问题就都能解释了:
- 某类例子多就偏向某类:模型把"例子里各类的数量分布"也当成了任务的一部分,例子里 Bug 多,它就以为答案大多是 Bug。
- 调顺序结果就变:模型对例子的位置是敏感的,尤其对靠后的例子印象更深,顺序一变,它归纳出的模式就变了。
- 边角输入硬套标签:模型从例子里学到的是"模仿最像的那个",它没有"这个我没见过"这种选项。
- 格式不一输出就乱:例子之间格式不统一,模型会把这种不一致也当成一种要模仿的模式。
所以让 few-shot 用对,核心不是"把例子加够",而是管好例子在示范什么:选得均衡、排得讲究、格式统一,该用规则的时候不硬堆例子。下面六节,就从第一版"加几个例子就放心"的想当然讲起。
一、为什么"加几个例子"不等于效果就变好
第一版加 few-shot 的方式,是这样的:我手头攒了几个分类正确的反馈,就把它们直接拼进了提示词。没怎么挑——能用就行。
# 反面教材:手头有几个例子,就随手塞进提示词
# 我手头攒的几个例子 —— 没怎么挑,碰巧 Bug 类多了两条
EXAMPLES = [
("打开页面就闪退,根本用不了", "Bug报告"),
("点保存没反应,数据全丢了", "Bug报告"),
("登录之后头像不显示", "Bug报告"),
("希望能加个夜间模式", "功能建议"),
("你们的客服电话是多少", "使用咨询"),
]
def build_prompt_v1(feedback):
lines = ["请把用户反馈分到:Bug报告/功能建议/使用咨询/情绪吐槽。\n"]
for text, label in EXAMPLES:
lines.append(f"反馈:{text}\n分类:{label}\n")
lines.append(f"反馈:{feedback}\n分类:")
return "\n".join(lines)
# 我以为:例子加上了,准确率涨了,就算调好了。
# 没意识到:这 5 个例子里 Bug 占了 3 个,
# 我无意中是在"示范"给模型看:这个任务,大多数答案是 Bug报告。加上例子后准确率确实涨了,这是真的——但它涨得不稳。因为 few-shot 的例子,是一种强引导:它对模型的影响很大,引导对了,效果明显提升;引导歪了,它把模型带偏的力度,同样明显。我那 5 个例子里 Bug 占了 3 个,这个"碰巧"的分布,被模型当成了任务的一个特征学走了——于是模型遇到模棱两可的反馈,就往 Bug 上靠。第一版的错,不在"用了 few-shot",而在把 few-shot 当成了一个"加了就只会变好"的无害技巧。
这一节要建立的认知是:few-shot 是一把双刃的强力工具——它对模型输出的影响是巨大的,而巨大的影响,意味着它既能巨大地帮你,也能巨大地坑你。第一版把 few-shot 理解成了一个"加分项":加了例子,分数往上走,不加就维持原样,反正没坏处。但 few-shot 不是加分项,它是一个"方向盘":你打对了方向,车走得又快又稳;你随手乱打,车一样会快速地冲向沟里。例子选得好,模型表现跃升;例子选得偏,模型会被你那几个例子里的偶然特征,系统性地、稳定地带偏。所以你不能"随手"用 few-shot——既然它影响这么大,你就必须郑重地对待你放进去的每一个例子。要郑重对待它,先得搞清楚它到底在模型那里发生了什么,这是下一节的事。
二、Few-shot 到底在做什么:示范,而不是参考
要用好 few-shot,得先看清模型拿到例子之后,到底做了什么。模型的核心工作方式是"续写"——给它一段文本,它接着往下生成最合理的内容。你的 few-shot 提示词,在模型眼里就是一整段文本。
# Few-shot 提示词在模型眼里,是这样一整段文本:
SAMPLE = """请把用户反馈分到:Bug报告/功能建议/使用咨询/情绪吐槽。
反馈:打开页面就闪退,根本用不了
分类:Bug报告
反馈:希望能加个夜间模式
分类:功能建议
反馈:点保存没反应,数据全丢了
分类:???"""
# 模型做的事,是"续写"最后那个 ??? 的位置。
# 它从前面的例子里归纳出一个模式,然后套到新输入上。
# 关键:它归纳的"模式",包含了例子的方方面面 ——
# - 任务逻辑:反馈内容 -> 哪一类(这是你想让它学的)
# - 输出格式:就回一个标签词,不加解释(它也会顺带学走)
# - 标签分布:例子里哪类多,它就倾向哪类(你没想让它学)
# - 字段措辞:字段叫"反馈""分类",顺序固定(它也会学)这就是问题的核心。模型不是在"参考"你的例子——"参考"意味着它会有选择地、聪明地只取你想让它取的那部分(任务逻辑)。模型做的是"归纳模式":它把你给的几个例子看成一组样本,从中归纳出一个尽量能解释所有样本的模式,然后把这个模式套用到新输入上。而它归纳出的模式,是例子的全部可观察特征,不只是你心里那个"任务逻辑"。
这一节的认知是:few-shot 的本质是"让模型从你的例子里归纳出一个模式",而模型归纳的对象,是例子的一切——你没法只示范"任务逻辑",你示范的是例子的全貌。这是第一版认知错位的根源。我以为我在用例子"教模型怎么分类",我以为模型会聪明地只学"分类逻辑"这一件事。但模型分不清"哪些特征是你想教的、哪些是你不小心带进来的"。在它看来,例子里所有稳定出现的东西——格式、字段名、标签的比例、例子的难易、措辞的风格——都是这个模式的一部分,都该被学走。一旦你接受了"我示范的是全貌,不是局部"这件事,你对待例子的态度就会彻底改变:你不会再"随手挑几个能用的",你会开始字斟句酌地控制例子的每一个特征。后面三节,讲的就是怎么控制这些特征——选什么、怎么排、什么时候干脆别用。
三、例子怎么选:覆盖、均衡、贴近真实分布
既然模型会把例子的全貌当成任务的定义,那"选哪些例子",就是 few-shot 里最要紧的一件事。选例子有三个原则。第一是覆盖:每一个类别都要有例子,容易混淆的、边角的情况也要尽量有。第二是均衡:各类别的例子数量要大致相等,别让某一类畸多。第三是贴近真实分布:例子的难度、风格,要像真实会遇到的输入,别全是"一眼就能分对"的简单货。
# 按类均衡地挑选示例:每一类都给够,且数量大致相等
from collections import defaultdict
ALL_LABELS = ["Bug报告", "功能建议", "使用咨询", "情绪吐槽"]
def select_balanced_examples(example_pool, per_label=2):
# example_pool: [(反馈文本, 标签), ...] 一个攒好的例子库
by_label = defaultdict(list)
for text, label in example_pool:
by_label[label].append((text, label))
selected = []
for label in ALL_LABELS:
# 每一类都取 per_label 个 —— 四类一视同仁,不让某类畸多
selected.extend(by_label[label][:per_label])
return selected
# 这样选出来的例子,四类各 2 个,共 8 个,分布是均衡的。
# 模型从中归纳出的"任务",才不会偏向某一类。三个原则里,"均衡"最容易被忽略,而它正是第一版第一种问题的成因。这个现象有个名字,叫标签偏置(label bias):模型会把例子里各标签的出现频率,当成一种"先验概率"——例子里 Bug 多,它就先入为主地认为"这个任务的答案大概率是 Bug"。
# 标签偏置直观感受:例子的分布,会被模型当成先验
# 例子集 A:四类均衡(各 2 个)
# 模型对一条模棱两可的反馈,会相对中立地判断
# 例子集 B:Bug报告 占了 6 个,其余各 1 个
# 模型会显著地偏向把模棱两可的反馈判成 Bug报告
# 同一个模型、同一条待分类反馈,只因为例子分布不同,
# 结论就不同 —— 这不是模型"笨",这是 few-shot 的固有特性:
# 例子的分布,就是你喂给模型的"这个任务大概长什么样"。这一节的认知是:选例子,你不是在"给模型看几个样品",你是在"给模型定义这个任务长什么样"——模型对这个任务的全部理解,就来自你给的这几个例子。这是一个视角的转变。"看样品"的视角下,例子是次要的、辅助的,选哪个都差不多。但"定义任务"的视角下,例子是这个任务在模型那里的全部画像:类别有哪些,看的是例子里出现过的;每类大概多常见,看的是例子里的数量比例;什么样的输入算典型,看的是例子的风格。你给的例子要是只有简单货、只有某一类、风格单一,那模型眼里这个任务就是个"简单的、偏向某类的、风格单一的"任务,它在真实的复杂输入上自然就垮。所以选例子时,你要时刻问自己:我这组例子,拼出来的是不是这个任务真实的样子?把选例子当成"为任务画像"这件郑重的事来做,few-shot 才选得对。
四、例子的顺序和格式:模型会模仿你没想让它学的东西
选对了例子,还有两个更细、更容易被完全忽略的特征要控制:例子的顺序和格式。第一版第二种问题——"只调了顺序,结果就变了"——讲的就是顺序。模型对例子的位置是敏感的,尤其对排在靠后的例子印象更深(因为它离待预测的位置更近)。这意味着,把哪个例子放最后,会微妙地影响结果。
顺序敏感不好彻底消除,但可以管理:一是让顺序固定下来(别每次随机排,否则结果不可复现);二是别把同一类的例子全堆在结尾(否则结尾那一类被过度强调)。而格式,则是可以、也必须做到完全一致的——所有例子的字段名、标点、换行,都要严丝合缝地统一。
# 用统一模板拼装每个例子,保证所有例子的格式绝对一致
EXAMPLE_TEMPLATE = "反馈:{text}\n分类:{label}"
def render_examples(examples):
# 每个例子都过同一个模板 —— 字段名、冒号、换行,完全一致
blocks = [
EXAMPLE_TEMPLATE.format(text=t, label=l)
for t, l in examples
]
return "\n\n".join(blocks)
# 关键:绝不要手写每一个例子。手写时,你迟早会在某个例子里
# 多打一个空格、把"分类"写成"类别"、或调换字段的顺序 ——
# 而模型会把这种不一致,也当成一种"模式"忠实地模仿出来。
# 用模板渲染,是把"格式一致"这件事,从"靠自觉"变成"靠代码"。第一版第四种问题——"一个例子格式手滑写歪了,模型输出也跟着乱"——根子就在"手写例子"。手写时,你以为格式都一样,但人总会出错:这个例子结尾多个句号,那个例子字段名换了个说法。这些在你眼里是"无关紧要的小疏忽",在模型眼里,却是需要解释的"信号"——它会困惑:既然例子的格式不统一,那我的输出格式,大概也不用太统一吧?
这一节的认知是:在 few-shot 里,凡是"在所有例子中保持一致"的东西,模型都会把它当成"任务要求"的一部分;凡是"在例子之间有变化"的东西,模型会把它当成"可以自由发挥"的部分。这条规律,是理解顺序和格式问题的钥匙。你希望模型稳定输出某种格式,那所有例子的那个格式就必须分毫不差地一致——一致,模型才会认为"这是硬要求"。你不小心让格式有了变化,模型就会认为"这里可以随意"。反过来,真正该在例子间变化的,只有一样东西:任务逻辑本身(不同的输入,对应不同的输出)。除此之外的一切——格式、字段、措辞、结构——都应该被刻意地、用代码强制地固定下来。你对例子里"什么该变、什么不该变"控制得越精确,模型模仿出来的行为就越是你想要的。把例子的格式交给模板,而不是交给手写,是这个精确控制的第一步。
五、什么时候 few-shot 反而不如 zero-shot
前面四节都在讲"怎么把 few-shot 用好",但有一个更上层的问题:这个任务,到底该不该用 few-shot?few-shot 不是免费的,它有明确的代价——例子要占掉宝贵的提示词长度(token),它会引入标签偏置,它有顺序敏感性。当一个任务的规则,本来就可以用语言清清楚楚地讲明白时,堆例子往往不如直接把规则写清楚。
# 能用规则讲清的任务,优先把规则写清楚(zero-shot)
# 任务规则清晰 -> zero-shot 加明确指令,往往比堆例子更稳
ZERO_SHOT = """请判断这条反馈是否描述了功能无法使用。
规则:只要反馈里提到崩溃、闪退、报错、点了没反应、
数据丢失中的任意一种,就归为 Bug报告。
反馈:{feedback}
分类:"""
# 任务逻辑只可意会 -> 这时才该用例子来示范
# 比如判断一条反馈是不是阴阳怪气 ——
# 阴阳怪气没法用规则穷举,但给几个例子,模型一看就懂
FEW_SHOT_FOR_TONE = """判断反馈的语气。看下面几个例子:
反馈:哇你们这优化真用心啊,卡得我想砸手机
语气:阴阳怪气
反馈:这个功能很好用,谢谢
语气:真诚
反馈:{feedback}
语气:"""
# 原则:先问这任务能不能用语言讲清规则。
# 能 -> 写规则;不能 只能靠示范 -> 才上 few-shot。这里的判断标准很清楚:看这个任务的逻辑,能不能被语言讲清楚。"包含崩溃、闪退、报错就算 Bug"——这种规则可以被穷举、被明确描述,那就把规则写进 zero-shot 提示词,干净、没有偏置、不受顺序影响。而"判断一句话是不是阴阳怪气"——这种东西没法用规则穷举,你说不清"阴阳怪气"的判定条件,但你给三五个例子,模型一看就领会了。few-shot 真正不可替代的价值,恰恰是在这种"只可意会、不可言传"的任务上。
这一节的认知是:few-shot 和 zero-shot 不是"高级与初级"的关系,而是适配不同任务类型的两种工具——能被规则讲清的任务,用规则;只能被示范传达的任务,才用例子。很多人有个隐含的偏见,觉得 few-shot 比 zero-shot"更高级、更强",所以遇事就先堆例子。但这是个误区。例子有它的副作用——偏置、顺序敏感、占长度——当一个任务的规则本来就清晰时,你用例子去"示范"这个清晰的规则,是用一个有副作用的工具,去做一件本可以用无副作用的工具(明确的规则描述)做好的事,得不偿失。正确的工作流是:拿到一个任务,先问"它的逻辑我能不能用几句话讲清楚?"——能,就老老实实写规则;不能,确实存在"我知道怎么做但说不清"的成分,这时 few-shot 才上场,用例子去传达那个语言传达不了的部分。先判断任务类型,再选提示方式,而不是无脑堆例子,你才用对了 few-shot。
把"该用哪种提示方式"的完整决策流程画出来,就是下面这张图:
[mermaid]
flowchart TD
A[要做一个提示词] --> B{任务规则能用语言讲清吗}
B -->|能讲清| C[zero-shot 把规则写清楚]
B -->|讲不清 只能靠示范| D{真实输入的形态多样吗}
D -->|比较同质| E[静态 few-shot 固定一套均衡例子]
D -->|很多样| F[动态 few-shot 按输入检索例子]
C --> G[进评估集 验证效果]
E --> G
F --> G
六、把 few-shot 做扎实,要避开的工程坑
前面五节讲清了 few-shot 的原理和用法。但要在生产里真正用好,还有几个工程坑得专门讲。第一个,也是最容易被忽略的:固定一套例子,服务不了五花八门的真实输入。如果你的输入形态很多样,更好的做法是动态 few-shot——维护一个大的例子库,每来一条输入,就从库里检索出和它最相关的几个例子,临时拼进提示词。
# 动态 few-shot:根据当前输入,从例子库里检索最相关的几个
def build_dynamic_prompt(feedback, example_pool, k=6):
# 第 1 步:把当前输入和例子库里的每个例子做相似度匹配
scored = []
for text, label in example_pool:
score = similarity(feedback, text) # 语义相似度
scored.append((score, text, label))
# 第 2 步:取最相关的 k 个例子
scored.sort(reverse=True)
top = [(t, l) for _, t, l in scored[:k]]
# 第 3 步:仍要保证这 k 个里各类都有,别全挤在一类
top = ensure_label_coverage(top, example_pool)
# 第 4 步:用统一模板拼进提示词
return assemble_prompt(feedback, top)
# 固定一套例子,服务不了五花八门的真实输入;
# 按输入动态选最贴近的例子,few-shot 的引导才用在刀刃上。第二个坑,是例子库本身的正确性。你的例子,在模型眼里就是"标准答案"——如果例子库里混进了一个标错的例子,模型不会质疑它,只会一丝不苟地把这个错误的模式学下来。所以例子库要像代码一样被校验、被 review。
# 例子库本身要校验:一个标错的例子,会被当成正确模式学走
def validate_example_pool(example_pool):
problems = []
for i, (text, label) in enumerate(example_pool):
# 校验一:标签必须是合法的那几类之一
if label not in ALL_LABELS:
problems.append(f"例子{i}:非法标签 {label}")
# 校验二:反馈文本不能为空、不能过短
if len(text.strip()) < 4:
problems.append(f"例子{i}:文本过短,不像个像样的例子")
return problems
# 例子库要像代码一样被 review、被纳入版本管理。
# 因为 few-shot 里,例子就是模型眼中的"标准答案" ——
# 标准答案错了,模型只会一丝不苟地把错的学下来。还有几个坑值得点一下。其一,例子要占掉提示词的长度——例子越多,每次调用花的 token 越多、成本越高,还可能把上下文挤爆,所以例子不是越多越好,够用就行。其二,你改了 few-shot 的例子,等于改了提示词,必须重新在评估集上跑一遍回归——例子是会显著影响输出的,不能改完就上线。其三,例子要和真实输入同步更新:线上出现了新形态的反馈,例子库也要补上对应的例子。下面把三种提示方式集中对照一下:
三种提示方式对照
方式 做法 适用场景
--------------------------------------------------------------
zero-shot 只写任务说明 不给例子 规则能讲清的任务
静态 few-shot 固定一套例子塞进提示词 输入同质 规则难讲清
动态 few-shot 按当前输入检索最相关的例子 输入多样 覆盖要求高
原则:能讲清规则就别堆例子;要用例子,
就把例子当数据来管 —— 均衡 一致 可检索 不能有错。
这一节这几个坑,串起来是同一个意思:few-shot 的例子,不是你写提示词时一劳永逸塞进去的一段"配置",它是一组需要被当作"数据"来认真管理的东西。当作数据管理,意味着:它要有正确性校验(不能有错例),要纳入版本管理(改了能追溯),要被评估(改了要回归),要随真实情况更新(线上有新形态就补例子),输入多样时还要支持检索(动态 few-shot)。这些动作,没有一个是"写一次提示词"的工作量,它们都是"管理一份数据"的工作量。第一版之所以坑,就是因为我把例子当成了提示词里几行随手写的字符串——它配不上这个待遇。例子是直接塑造模型行为的东西,它的地位,和你的代码、你的评估集一样重要。把 few-shot 的例子提升到"一类需要被工程化管理的数据"的高度去对待,你的 few-shot 才能在生产里长期稳定地起作用。
关键概念速查
| 概念 | 说明 |
|---|---|
| few-shot 提示 | 在提示词里给模型几个输入输出例子,让它照着做 |
| zero-shot 提示 | 不给例子,只用任务说明让模型完成任务 |
| 行为示范 | few-shot 例子的本质,模型会整体模仿例子的一切特征 |
| 模式归纳 | 模型从例子里归纳出一个模式再套用,归纳对象是例子全貌 |
| 标签偏置 | 例子里某类偏多,模型就先验地倾向输出那一类 |
| 顺序敏感性 | 例子的先后顺序会影响输出,靠后的例子影响更大 |
| 格式一致 | 所有例子的字段、措辞、标点、换行必须严格统一 |
| 覆盖与均衡 | 例子要覆盖所有类别且各类数量大致相等 |
| 动态 few-shot | 按当前输入从例子库检索最相关的例子临时拼入 |
| 例子库 | 攒起来的候选例子集合,要像代码一样校验和管理 |
避坑清单
- 不要以为加例子就一定变好:例子是强引导,选偏了会把模型带歪。
- 不要随手挑例子:你挑的例子分布,就是模型眼里这个任务的样子。
- 不要让某一类例子畸多:标签偏置会让模型无脑偏向那一类。
- 不要忽视例子顺序:顺序变了结果会变,靠后的例子影响更大。
- 不要手写例子放任格式不一:用模板渲染,保证格式绝对一致。
- 不要只放容易的例子:边角、易混的情况也要有例子覆盖。
- 不要凡事都堆例子:规则能讲清的任务,zero-shot 写清规则更稳。
- 不要用一套固定例子打天下:输入多样时用动态检索来选例子。
- 不要让例子库混进错例:标错的例子会被模型当正确模式学走。
- 不要把例子当一次性配置:它是数据,要校验、版本管理、回归评估。
总结
回头看第一版那个"加几个例子凑够数就行"的分类功能,它的错误很典型。它不在某一行代码,而在一个对 few-shot 的根本误解:以为例子是给模型查阅的参考资料,越多越准。真相是,例子是给模型的行为示范,模型会整体地、不加区分地模仿例子的全部特征——任务逻辑、输出格式、标签分布、措辞顺序,一起学走。你想教的它学了,你没想教的它也学了。few-shot 不是无害的加分项,它是一个影响巨大的方向盘,打对了帮你、打偏了坑你。
而把 few-shot 用对,工程量并不小。它不是"塞几个例子"那么简单,而是要理解例子在做行为示范,要让例子覆盖、均衡、贴近真实分布,要把例子的顺序固定下来、把格式用模板严格统一,要先判断任务该用规则还是该用示范,还要把例子库当数据来管——校验、版本管理、回归评估,输入多样时再做动态检索。一套真正可靠的 few-shot,是这些环节一个不少地拼起来的。
这件事其实很像带一个新人上手工作。你不会干巴巴地给新人讲一堆抽象规则,你会甩给他几个"过往的处理案例",让他照着做——这就是 few-shot。但带新人你会发现:你给的案例,他会整个地模仿,不只模仿"该怎么处理"。你给的案例碰巧都是某一类客户,他就以为这工作天天都是这类客户(标签偏置);你几个案例的文档格式各写各的,他整理出来的东西也跟着乱(格式不一致);你案例里某一份其实处理错了,他不会质疑,只会一丝不苟地把错的学走(错例的危害)。而如果这件事本来就有明文规定的操作流程,你与其翻一堆案例给他看,不如直接把流程文档递给他,清楚又不会让他学偏(该用规则时用规则)。带新人靠"示范"非常有效,但你示范的一切他都会学——这一点,对新人成立,对大模型一样成立。
这类问题还有一个共同的麻烦:它在开发和测试时很难暴露。你自己测,用的是你写例子时脑子里想着的那几种典型反馈,模型在这些"和例子很像"的输入上,表现得又准又稳,你会觉得这套 few-shot 天衣无缝。真正会把问题撑开的,是上线后真实用户五花八门的反馈:形态是你例子没覆盖到的,语气是你没示范过的,而你那几个例子里某个偶然的偏向——某类多了两条、某个格式手滑写歪了——会被模型稳定地、放大地作用到这些陌生输入上。所以如果你正在用 few-shot 做一个功能,别等分类结果一片混乱才回头怀疑提示词。在写下第一个例子的时候就想清楚:我这组例子示范的,是不是这个任务真实的样子、它均不均衡、格式统不统一、这个任务到底该用例子还是该用规则——把"给模型几个例子"和"管好这些例子在示范什么"当成两件必须分别去做的事,这是这篇文章最想留给你的一句话。
—— 别看了 · 2026