为什么零样本指令会翻车
只给一句"请详细分析这段数据，找出异常波动点"时，模型并不知道你团队对"分析报告"的定义。它是预训练产物，见过互联网上成千上万种写法，会按它认为最主流的方式输出——有时是一坨散文，有时是干巴巴的数字堆。更麻烦的是不同业务的套路完全不同：运维看 CPU 异常，套路是"看 GC、看流量、看死锁"；金融看股价异常，套路是"看政策、看资金、看技术面背离"。你给一句笼统的"分析原因"，它可能拿金融的套路套到 CPU 上，结论自然驴唇不对马嘴。它不笨，只是不知道你这儿的规矩。
少样本提示到底在干什么
Few-shot 翻译过来就是少样本提示，本质就是照猫画虎。你在提示里不光下指令，还塞一两个"输入长这样、输出长这样"的完整样例。模型一看样例，立刻明白你要的格式和推理逻辑，照着画出来的结果就稳得多。
按给例子的数量分三档：
- Zero-shot：零样例，只干说指令，最容易翻车；
- One-shot：给一个样例；
- Few-shot：给两三个样例，通常效果最好。
样例给太多也不行，一来费 token，二来例子一多模型反而抓不住重点。时序分析里一般一个到两个极度典型的样例就够把模型的"手"教出来。
怎么造一个能教的样例
样例不是随便抓段废数据就行，它得成为你立的规矩。
输入部分必须和真实数据格式完全一致。比如你们约定数据格式是"时间, 指标名, 数值"，样例输入也得是这种：
2023-09-15 10:00:00, CPU, 25%
2023-09-15 10:01:00, CPU, 26%
2023-09-15 10:02:00, CPU, 88%
2023-09-15 10:03:00, CPU, 91%
2023-09-15 10:04:00, CPU, 27%
输出部分是你亲手写的一份"完美报告"，把想要的格式钉死：
【异常检测报告】
1. 异常时间点：2023-09-15 10:02:00 与 10:03:00
2. 异常指标及数值：CPU使用率分别飙升至88%和91%
3. 关联分析：该时段内存使用率未见明显上升，网络流量正常，初步排除GC和流量冲击。
4. 原因推测：极大可能为某个离线计算任务突发启动占用大量CPU，建议排查定时任务调度日志。
有了明确标题、1234 序号、从异常点推到排除项再到推测的链条，模型之后就会努力模仿这个结构，不再写散文。
样例一定要短。数据五六行、报告五六行足够，太长有两个坏处：每次请求都带着它，token 成本扛不住；模型可能去模仿你的废话语气，反而把核心逻辑丢了。
把样例塞进 messages 的正确姿势
在 OpenAI 兼容的 API 里，Few-shot 不该和真实提问挤在同一条 user 消息里。最佳实践是把它伪装成历史对话：在 messages 列表里先放一条虚拟 user（样例输入），再放一条虚拟 assistant（样例输出），最后才是真实 user。模型看到前面的"成功合作记录"，会顺着惯性继续。
def build_few_shot_prompt(real_data_text):
example_input = """
2023-09-15 10:00:00, CPU, 25%
2023-09-15 10:01:00, CPU, 26%
2023-09-15 10:02:00, CPU, 88%
2023-09-15 10:03:00, CPU, 91%
2023-09-15 10:04:00, CPU, 27%
"""
example_output = """
【异常检测报告】
1. 异常时间点：2023-09-15 10:02:00 与 10:03:00
2. 异常指标及数值：CPU使用率分别飙升至88%和91%
3. 关联分析：该时段无其他指标数据，无法做交叉对比。
4. 原因推测：短时突刺一般为后台单次重计算任务触发，建议排查应用日志。
"""
messages = [
{
"role": "user",
"content": f"请分析以下时序数据：\n{example_input}"
},
{
"role": "assistant",
"content": example_output
},
{
"role": "user",
"content": f"请按照刚才的格式，分析以下新的时序数据：\n{real_data_text}"
}
]
return messages
真实提问里特意加一句"请按照刚才的格式"，是把模型注意力拉回样例的强提示，防止它跑偏。
主流程与调用
import requests
def ask_with_few_shot(messages_list, api_key):
url = "
headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {api_key}"
}
payload = {
"model": "timecho-model",
"messages": messages_list
}
response = requests.post(url, headers=headers, json=payload, timeout=30)
result = response.json()
return result['choices'][0]['message']['content']
if __name__ == "__main__":
my_real_data = """
2023-10-25 10:00:00, CPU, 22%
2023-10-25 10:01:00, CPU, 24%
2023-10-25 10:02:00, CPU, 89%
2023-10-25 10:03:00, CPU, 92%
2023-10-25 10:04:00, CPU, 21%
"""
my_messages = build_few_shot_prompt(my_real_data)
print("正在请求大模型（带Few-shot示范）...")
final_answer = ask_with_few_shot(my_messages, my_key)
print("\n=== 大模型的分析报告 ===")
print(final_answer)
对比一下效果：去掉样例只留真实提问时，模型可能回"经过分析，我发现数据在10:02和10:03出现了异常，数值达到了89%和92%。这种情况通常是突发任务导致的，建议去查日志"——话对，但没条理，老板还得自己重排。加上 Few-shot 之后，出来的报告带标题、带序号、逻辑链跟样例一致，老板直接复制粘贴进周报。
样例选错了反而带沟里
Few-shot 是双刃剑。样例推理有硬伤，模型会把毛病一起学过去。比如样例里写"CPU 高是因为内存泄漏"，但样例数据里压根没有内存字段，这就是逻辑硬伤。模型看不懂，只会照学，等你喂真实数据，哪怕内存正常它也可能硬扯一句内存泄漏。手写样例必须推理自洽、经得起推敲，给烂样例不如不给。
另一种坑是样例和真实问题类型不匹配。样例是 CPU 突刺，你拿内存缓慢上涨的数据去问，模型被样例框死，还硬套"找突刺"逻辑，告诉你"没异常"或瞎指个点。这叫过拟合。解法是在提示里放两个样例，一个突刺型、一个缓涨型，模型见多了就学会灵活处理，代价是 token 变多，需要权衡。
工程上怎么用才稳
System Prompt 和 Few-shot 要分工：立规矩、定人设（"你是一个严谨的运维工程师，必须按 1234 列表输出"）放进 role: "system" 的消息，样例负责定格式，两套叠加最稳。但 in-context learning 有位置敏感性——离真实提问越近的样例影响越大，把最典型、最该模仿的样例放在样例序列末尾，比放在开头更不容易被前面的样例稀释。
token 成本得算清楚。Few-shot 的样例每次请求都带着走，反复累积会吃光上下文窗口。GPT-4o-mini 这类模型上下文上限在 128k token 量级，但样例加长文本一旦逼近上限，模型就会截断或降质。用 tiktoken 在本地先统计一次提示的 token 数，按调用量估算月度开销，再决定样例留几个、留多长。
验证效果不能靠肉眼。攒一批不在样例里的真实数据当评估集，跑完后用正则或轻量解析器检查输出是否都带"异常检测报告"标题和 1234 结构，算出格式合规率。合规率上不去，就调样例；合规率上去了但 token 翻倍，就砍样例。用数据说话，比"感觉这次挺好"靠谱。
playground 适合先验证后开发：网页里手调样例和格式，等提示词稳了再搬进代码，比改一次代码跑一次快得多。
评论0