1. 从“只给几个例子”说起大模型到底在学什么第一次接触 Few-shot 这个概念是在做一个无人机巡检项目的时候。当时的需求很具体给一段无人机拍摄的画面描述让模型判断当前飞行阶段属于“起飞爬升”“定高巡航”“目标锁定”还是“返航降落”。我手里只有不到两百条标注数据按传统思路这点数据连一个像样的分类器都训不出来更别说深度学习模型了。但同事丢过来一个提示词模板里面只放了四个例子模型在测试集上的准确率直接到了八成以上。那一刻我的反应和大多数人一样这不科学。后来把 In-Context Learning 的机制啃了一遍才明白大模型在 Few-shot 场景下做的事情和传统机器学习里的“训练”根本不是一回事。传统监督学习是通过反向传播调整权重把任务模式“写进”参数里而 Few-shot 是模型在推理阶段利用已经预训练好的能力从你给的几个例子里“临时推断”出任务模式整个过程参数完全冻结。换句话说模型不是学会了新任务而是被你用几个例子“激活”了它本来就具备的某种能力。这个区别非常关键因为它直接决定了你在 UAV 场景下该怎么设计提示词。如果你把它当成训练来对待就会陷入“例子越多越好”的误区但如果你理解它是在做模式匹配和任务推断就会把精力放在例子的质量、多样性和排列方式上。我在实际项目里试过同样四个例子换一种排列顺序准确率能差出十五个百分点。这不是玄学是 In-Context Learning 的固有特性。面向 UAV 应用的 Prompt Engineering核心要解决的问题就三个第一怎么用最少的标注成本让模型理解你的任务第二怎么设计例子让模型抓住你真正关心的判别边界第三怎么让这套方案在不同机型、不同任务之间快速迁移。这三个问题贯穿了后面所有内容也是我踩了无数坑之后总结出来的主线。提示Few-shot 不是“少量样本训练”而是“少量样本推理”。理解这一点后面所有的设计决策都会顺理成章。2. 核心机制拆解为什么几个例子就能“教会”模型2.1 In-Context Learning 的底层逻辑要理解 Few-shot 为什么有效得先搞清楚大模型在预训练阶段到底学到了什么。简单说一个在足够大规模文本上训练过的模型它的参数里已经隐含了大量任务的“模式”。比如“把下面这句话翻译成英文”“判断这段评论是正面还是负面”“从这段文字里抽取人名和地名”这些任务模式在预训练语料里反复出现模型已经把它们编码进了自己的表示空间。当你给出几个“输入-输出”对的时候模型做的事情是在它的表示空间里搜索一个映射关系使得你给的例子能够被最好地拟合然后用这个映射去处理新的输入。这个过程不需要梯度更新完全发生在前向传播中。你可以把它想象成一个经验丰富的老师傅你给他看几个样品他就能推断出你的验收标准然后按这个标准去检验后面的产品。这里有一个容易被忽略的点模型推断出的映射关系未必是你心里想的那个。我遇到过好几次给的例子里正样本都是“目标在画面中央”负样本都是“目标在画面边缘”结果模型学到的判别规则变成了“看目标位置”而不是“看目标类型”。这就是所谓的“虚假相关”问题在 Few-shot 场景下特别常见因为例子太少模型没有足够信息去排除干扰维度。2.2 Few-shot 与传统微调的本质差异很多人会问既然 Few-shot 效果不稳定为什么不直接微调这个问题在 UAV 场景下尤其现实因为无人机采集的数据往往涉及特定视角、特定光照、特定目标形态通用模型直接拿来用确实可能不够。但微调有几个硬伤第一你需要至少几百到几千条高质量标注数据而 UAV 场景下标注成本极高尤其是涉及专业判读的任务第二微调后的模型会“过拟合”到你的数据分布上换个机型、换个飞行高度、换个季节效果可能断崖式下跌第三微调需要 GPU 资源而很多 UAV 应用是边缘部署根本跑不动训练。Few-shot 的优势恰恰在这些地方零训练成本、快速迭代、天然支持任务切换。你可以在飞行前根据任务类型动态组装提示词今天做电力巡检就用电力设备的例子明天做农业估产就用农作物的例子同一个模型不用改任何参数。这种灵活性在传统微调范式下是不可想象的。当然 Few-shot 也有它的天花板。当任务复杂度超过模型预训练时见过的模式范围或者当你的判别边界需要非常精细的数值判断时Few-shot 就会力不从心。我的经验是分类、抽取、格式转换类任务Few-shot 通常够用涉及精确回归、复杂空间推理、多步规划的任务还是得考虑微调或者混合方案。2.3 UAV 场景下的特殊约束UAV 应用和通用 NLP 任务有几个显著区别这些区别直接影响 Prompt Engineering 的设计策略。第一是多模态输入。无人机采集的往往是图像、视频、遥测数据纯文本提示词不够用。你需要把视觉信息转成文本描述或者用多模态模型直接处理。我试过用纯文本描述图像内容再喂给语言模型信息损失很大尤其是空间关系和小目标细节。后来改用多模态模型把图像和文本提示一起输入效果明显好很多。第二是实时性要求。无人机飞行过程中决策窗口可能只有几百毫秒。Few-shot 提示词如果太长推理延迟会直接影响到任务执行。我实测过同样一个七 B 参数的模型提示词从五百 token 增加到两千 token单次推理时间从三百毫秒涨到一点二秒。在巡检场景下这个延迟还能接受但在避障场景下就是致命的。第三是领域术语密集。UAV 领域有大量专业缩写和特定表达比如“云台俯仰角”“航线重叠率”“地面采样距离”。通用大模型对这些术语的理解往往不到位你需要在提示词里给出术语解释或者用例子来锚定含义。注意UAV 场景下不要直接套用 NLP 任务的提示词模板。视觉信息怎么转文本、实时性怎么保证、领域术语怎么对齐这三个问题必须先解决。3. 动手设计 Few-shot 提示词从零到可用的完整流程3.1 任务定义与输出格式约定一切从任务定义开始。我见过太多人一上来就写提示词结果模型输出格式五花八门后处理代码写了一堆。正确的做法是先想清楚三件事输入是什么、输出是什么、边界在哪里。以无人机目标识别为例。输入是一段视觉描述或者图像本身输出是目标类别加置信度。边界条件包括目标被遮挡怎么办、多个目标同时出现怎么办、目标不在预设类别里怎么办。这些边界条件必须在提示词里明确否则模型会自己“发明”规则。输出格式我强烈建议用结构化格式比如 JSON。原因很简单后处理方便而且结构化输出本身就能约束模型的生成空间减少胡言乱语。下面是一个我实际用过的模板{ target_type: string, one of [vehicle, person, building, vegetation, unknown], confidence: float between 0 and 1, bbox_description: string, relative position in image, reasoning: string, brief explanation }这个模板里reasoning字段看起来多余但实际上非常有用。它强迫模型在给出结论之前先“想一步”实测能提升复杂场景下的准确率。而且当模型判断错误时你可以通过reasoning字段快速定位是理解偏差还是视觉信息不足。3.2 例子选择质量远比数量重要Few-shot 里的“few”到底是多少学术界一般把 1-5 个例子叫 Few-shot5-20 个叫 Medium-shot。但在实际工程中我的经验是三个精心设计的例子效果往往好过十个随手抓的例子。例子选择的核心原则是覆盖判别边界。什么叫判别边界就是那些容易混淆的类别之间的分界线。比如你要区分“轿车”和“卡车”边界就是车厢形状和尺寸比例你要区分“正常植被”和“病虫害植被”边界就是颜色纹理和分布模式。你的例子里必须包含这些边界附近的样本模型才能学到正确的判别规则。我通常会用这个流程来选例子先把所有标注数据按类别分组每个类别随机抽五条作为候选池在候选池里找“典型样本”和“边界样本”各一条典型样本用来锚定类别的基本特征边界样本用来明确判别规则如果类别之间容易混淆额外加一条“对比样本”同时展示两个类别的差异举个例子在区分“定高巡航”和“目标锁定”这两个飞行阶段时我选的三个例子是一个典型的定高巡航高度稳定、航向稳定、速度稳定、一个典型的目标锁定高度微调、航向微调、速度降低、一个边界样本高度稳定但航向开始偏转标注为“目标锁定”。第三个例子最关键它告诉模型“航向偏转”比“高度稳定”优先级更高。3.3 例子排列顺序真的会影响结果这一点听起来很反直觉但确实如此。In-Context Learning 对例子的排列顺序敏感原因是模型在处理序列时存在“近因效应”——越靠近末尾的例子对最终输出的影响越大。我的实测数据同样四个例子把最典型的放在最后准确率比放在最前面高八到十二个百分点。把最容易混淆的边界样本放在最后效果更好因为模型在生成答案前“最后看到”的就是判别边界。所以我的排列策略是从典型到边界从简单到复杂把最关键的判别规则放在最后。具体来说第一个例子最典型的正样本锚定基本模式第二个例子最典型的负样本明确排除条件第三个例子边界样本展示判别规则的优先级第四个例子可选格式示范确保输出结构正确如果例子数量有限优先保留边界样本和格式示范典型样本可以合并。3.4 提示词模板的完整结构一个完整的 Few-shot 提示词包含四个部分任务说明、例子集合、待处理输入、输出指令。我习惯用 Markdown 格式来组织因为大模型对 Markdown 结构的理解比较好。# 任务 你是一个无人机视觉分析助手。根据给定的图像描述判断目标类型并输出结构化结果。 # 输出格式 {target_type: ..., confidence: ..., reasoning: ...} # 示例 ## 示例1 输入画面中央有一辆白色轿车车顶可见尺寸约占画面宽度15%。 输出{target_type: vehicle, confidence: 0.95, reasoning: 车顶轮廓清晰尺寸符合轿车特征} ## 示例2 输入画面左下角有一个人形目标部分被树木遮挡可见上半身。 输出{target_type: person, confidence: 0.78, reasoning: 人形轮廓可辨但遮挡导致置信度降低} ## 示例3 输入画面右侧有一辆大型车辆车厢方正尺寸约占画面宽度40%。 输出{target_type: vehicle, confidence: 0.88, reasoning: 车厢方正且尺寸较大判定为卡车类} # 待处理输入 输入{{user_input}} # 输出这个模板里任务说明用一句话讲清楚角色和核心动作输出格式单独列出方便模型对齐示例部分用二级标题分隔每个例子待处理输入用占位符标记。整个提示词控制在八百 token 以内兼顾效果和延迟。提示模板里的reasoning字段不要省。它不仅能提升准确率还能在你排查问题时告诉你模型“为什么这么判”。4. 实操中的坑与排查技巧4.1 模型“学会”了错误规则怎么办这是 Few-shot 最常见的翻车场景。你给的例子里正样本恰好都是晴天拍摄的负样本恰好都是阴天拍摄的模型就会把“天气”当成判别依据。等你拿晴天拍的负样本去测试模型直接懵了。排查方法很简单构造对抗测试集。把你认为模型可能“走偏”的维度单独拿出来构造一批测试样本看模型在这些维度上的表现。比如怀疑模型在“看天气”就找一批晴天负样本和阴天正样本看准确率是否下降。解决方法有两个。第一是增加例子多样性在正样本里混入不同天气、不同角度、不同尺寸的样本让模型无法依赖单一维度。第二是在任务说明里显式排除干扰维度比如加一句“判断依据仅限目标形状和尺寸不考虑光照条件”。实测下来第二种方法见效快但第一种方法更根本。4.2 输出格式不稳定的处理模型有时候会“忘记”输出格式尤其是当例子数量少或者任务说明不够明确的时候。我遇到过模型把 JSON 输出成自然语言、把置信度写成“很高”而不是数值、把target_type写成中文的情况。解决这个问题的核心是格式示范要足够强。具体做法第一在任务说明里用代码块明确写出输出格式第二每个例子的输出都严格遵循格式不要有例外第三在待处理输入后面加一句“请严格按照上述 JSON 格式输出”。如果还是不稳定可以用强制前缀技巧在输出指令后面直接写上{target_type: 让模型从这个前缀开始续写。这个方法几乎能百分之百保证格式正确代价是牺牲一点灵活性。4.3 长提示词导致的延迟问题UAV 场景下延迟是硬约束。我实测过不同提示词长度对推理时间的影响数据如下提示词长度token推理时间ms准确率%30021076.260034083.590048085.1150079085.82500135086.0可以看到从 600 token 到 900 token准确率只涨了 1.6 个百分点但延迟增加了 140 毫秒。从 900 到 1500准确率几乎没变延迟却翻了近一倍。所以我的建议是把提示词控制在 600-900 token 之间这是性价比最高的区间。如果任务确实需要更多例子可以考虑动态例子选择根据当前输入的特征从例子库里检索最相关的几个例子组装提示词。这样既能保证相关性又能控制长度。实现方式可以用简单的关键词匹配也可以用嵌入向量相似度检索。4.4 常见问题速查表问题现象可能原因排查方法解决措施准确率远低于预期例子存在虚假相关构造对抗测试集增加例子多样性或显式排除干扰维度输出格式混乱格式示范不够强检查例子输出是否统一加强格式说明或使用强制前缀推理延迟过高提示词过长统计 token 数量精简例子或使用动态选择换任务后效果骤降例子未覆盖新任务边界对比新旧任务差异重新设计例子集合模型“胡言乱语”任务说明模糊检查任务定义是否清晰明确输入输出和边界条件置信度普遍偏高模型过度自信统计置信度分布在例子里展示不同置信度水平4.5 我的独家避坑心得第一个心得例子里的reasoning字段要写“人话”。我见过有人把 reasoning 写成“根据特征提取和模式匹配结果”这种废话对模型没有任何帮助。好的 reasoning 应该像老师傅带徒弟时说的话“你看这个车顶是平的轿车车顶一般是弧形的所以这是卡车。”具体、可操作、有判别依据。第二个心得定期用新数据回归测试。Few-shot 提示词不是一劳永逸的随着任务场景变化原本好用的例子可能失效。我习惯每周抽一批新数据跑一次回归准确率下降超过五个百分点就重新审视例子集合。第三个心得保留一个“万能兜底例子”。当模型遇到完全没见过的输入时容易乱输出。我在例子里加了一个“未知类别”的示范告诉模型“如果无法判断输出 unknown 并给出低置信度”。这个兜底例子能显著减少误报。第四个心得不要迷信“更多例子”。我做过对比实验在目标识别任务上三个精心设计的例子和十个随机例子准确率分别是 84.3% 和 81.7%。例子多了反而引入了噪声和矛盾信息。质量永远优先于数量。5. 从 Few-shot 到 Zero-shot能力边界与迁移策略5.1 Zero-shot 在 UAV 场景下的可行性Zero-shot 就是不给任何例子直接让模型执行任务。听起来很美好但在 UAV 场景下纯 Zero-shot 的准确率通常比 Few-shot 低十五到二十个百分点。原因是 UAV 领域的任务定义往往比较特殊通用模型没有见过足够多的类似模式。但 Zero-shot 有一个 Few-shot 比不了的优势零延迟开销。没有例子意味着提示词可以极短推理速度最快。所以在一些对实时性要求极高、但对准确率容忍度也较高的场景下Zero-shot 是合理选择。比如无人机的初步目标筛查先用 Zero-shot 快速过滤掉明显无关的画面再对可疑区域用 Few-shot 精细分析。我的建议是把 Zero-shot 和 Few-shot 做成两级流水线。第一级用 Zero-shot 做粗筛第二级用 Few-shot 做精判。这样既保证了速度又保证了关键环节的准确率。5.2 从 Few-shot 到微调的平滑过渡当 Few-shot 的天花板不够用时就需要考虑微调。但微调不是推倒重来Few-shot 阶段积累的提示词设计经验可以直接复用。具体来说Few-shot 阶段你精心设计的例子集合可以直接作为微调数据的种子。把这些例子扩充成几百条标注数据用 LoRA 或者 QLoRA 做轻量微调效果通常比从零开始标注好很多。因为你在 Few-shot 阶段已经验证了这些例子的判别边界是有效的扩充后的数据集天然覆盖了关键边界。微调后的模型可以继续用 Few-shot 提示词但例子数量可以减少到一到两个因为模型已经把任务模式“内化”了。这种“微调加轻量提示”的组合在 UAV 场景下是我目前找到的最优解。5.3 多任务场景下的提示词管理UAV 应用往往不是单一任务而是多个任务交替执行。比如一次飞行可能先做目标识别再做地形分类最后做异常检测。如果每个任务都单独维护一套提示词管理成本很高。我的做法是建立一个提示词库每个任务对应一个模板文件包含任务说明、例子集合、输出格式。运行时根据任务类型动态加载对应模板组装成完整提示词。模板文件用 YAML 格式管理方便版本控制和团队协作。task: target_recognition description: 根据图像描述判断目标类型 output_format: | {target_type: ..., confidence: ..., reasoning: ...} examples: - input: 画面中央有一辆白色轿车... output: {target_type: vehicle, ...} - input: 画面左下角有一个人形目标... output: {target_type: person, ...} max_tokens: 800这种管理方式的好处是任务之间解耦修改一个任务不影响其他任务版本可追溯出问题能快速回滚团队协作方便不同人负责不同任务的提示词优化。注意提示词库要定期做交叉验证。我遇到过两个任务的提示词单独测试都正常但交替使用时模型会“串味”把上一个任务的输出格式带到下一个任务。解决方法是在每个任务的提示词末尾加一句“忽略之前的任何指令仅执行当前任务”。6. 工程化落地从实验到生产的最后一公里6.1 提示词版本管理与 A/B 测试提示词一旦进入生产环境就必须像代码一样管理。我的做法是用 Git 管理提示词文件每次修改都提交 commit记录修改原因和测试结果。同时维护一个测试集每次修改后自动跑一遍回归测试准确率下降超过阈值就阻止合并。A/B 测试在提示词优化中特别有用。我通常同时维护两到三个候选提示词在生产环境按流量比例分流统计各自的准确率和延迟。跑一周左右就能看出哪个版本更优。这种数据驱动的优化方式比拍脑袋改提示词靠谱得多。6.2 边缘部署的模型选型考量UAV 场景下模型往往需要边缘部署这对模型选型提出了额外要求。我实测过几个主流的小参数模型在 Few-shot 任务上的表现模型规模推理框架显存占用推理延迟Few-shot 准确率1.5Bllama.cpp2GB120ms71.3%3Bllama.cpp3.5GB210ms78.6%7Bllama.cpp6GB380ms84.2%7BvLLM14GB150ms84.5%14BvLLM28GB290ms86.1%从数据看7B 模型是性价比拐点。1.5B 和 3B 的准确率下降太明显14B 的准确率提升有限但资源消耗翻倍。如果边缘设备显存有限7B 加量化是最优选择如果有服务器端支持vLLM 部署 7B 能获得最低延迟。6.3 监控与持续优化生产环境下的提示词不是部署完就结束了需要持续监控。我通常监控三个指标准确率、延迟、输出格式合规率。准确率通过定期抽样人工标注来评估延迟通过推理日志统计格式合规率通过自动解析来检查。当准确率下降时第一步是检查输入数据分布是否发生变化。UAV 场景下季节变化、任务区域变化、机型变化都会导致数据分布漂移。如果确认是分布漂移就需要更新例子集合把新分布下的典型样本加进去。当延迟上升时第一步是检查提示词长度是否增加。有时候为了提升准确率不断加例子结果延迟超标。这时候需要做权衡或者引入动态例子选择来压缩长度。格式合规率下降通常意味着模型版本更新或者提示词被意外修改。检查模型版本和提示词版本回滚到稳定版本即可。6.4 一个完整的落地案例最后分享一个我实际做过的项目。任务是无人机电力巡检中的绝缘子缺陷检测需要判断绝缘子是否破损、是否有异物、是否正常。标注数据只有一百二十条分三类。我的方案是用 7B 模型加 QLoRA 微调微调数据就是这一百二十条加上数据增强扩充到五百条。微调后的模型再用 Few-shot 提示词做推理每个类别两个例子提示词长度控制在七百 token 以内。部署在机载边缘设备上用 llama.cpp 量化到 Q4 精度。最终效果准确率 91.2%单次推理延迟 420 毫秒显存占用 5.8GB。这个延迟在巡检场景下完全够用因为无人机在绝缘子附近会减速悬停决策窗口有将近一秒。踩过的坑最开始用纯 Few-shot 方案准确率只有 79%主要问题是绝缘子缺陷的视觉特征比较细微通用模型没有见过足够多的类似样本。后来加了微调准确率直接跳到 89%再用 Few-shot 优化提示词最终到 91.2%。这个案例说明Few-shot 和微调不是二选一而是可以叠加使用各自发挥优势。我个人在实际操作中的体会是Few-shot 提示词工程的核心不是“写提示词”而是“设计信息”。你给模型的每一个例子、每一句说明、每一个格式约束都是在向它传递信息。信息设计得好模型就能推断出正确的任务模式信息设计得差模型就会走偏。这个思路在 UAV 场景下尤其重要因为领域知识密集、标注成本高、实时性要求严每一个 token 都要花在刀刃上。