这道题其实在问,怎么让大模型稳定地做意图分类,核心就是模板设计。模板不只是写几句提示词,它是你跟模型沟通的接口,决定了模型能不能准确理解任务边界。
先说角色定义。你不能只扔给模型一句话说“给我分个类”,要明确告诉它“你是一个用户意图理解助手,你的输出要严格遵守我给的分类体系”。我一般会这样写:你是一位专业的意图分析助手,请从以下类别中选择最匹配的,如果都不匹配就输出“其他”。类别列表我会列清楚,比如查询、预订、投诉、闲聊。这样模型就知道自己的职责范围,不会跑偏。
再一个是结构化输出。我强制要求模型输出 JSON,这样下游解析方便,也方便做校验。比如输出里要有 intent、confidence、slots,还有 clarification_needed 字段。confidence 分高、中、低三档,低的时候触发澄清对话。这个格式本身也是对模型的一种约束,让它不能随便乱写。
接下来是[[少样本]]示例。这是提升稳定性的关键。每个意图类别我一般放 2-3 个示例,但要覆盖常见变体,比如口语化的“帮我订个票”和省略主语的“明天酒店”。还有边界情况,比如“帮我订个票”其实需要澄清是机票、火车票还是电影票,我会在示例里展示模型如何输出 slots 和 clarification_needed。说白了,示例就是给模型打样,让它学会怎么处理模糊输入。
这里有个坑,就是意图漂移。模型可能看到相似表达就跳到别的意图去。我的做法是加反例,明确告诉模型“这个不属于XX意图”。比如“我想退票”如果意图列表有“投诉”和“退款”,示例里要展示“退票”属于退款而不是投诉。
多意图混合也是个常见问题。用户说“帮我查一下订单,顺便问问满减政策”,这就涉及两个意图。我一般设计层级结构,主意图是“查询”,子意图是“订单查询”和“政策查询”。或者让模型输出一个主意图加多个子意图,但这样复杂度高,我更倾向在模板里加一条规则:如果检测到多个意图,先输出主意图,然后触发澄清。
置信度校准很重要。模型输出低置信度的时候,不要硬猜,要主动问用户。我上线前会特别关注低置信度样本的分布,如果某个意图频繁低置信度,说明模板里的示例不够,或者意图定义太模糊。还有一个常见失败场景是,用户输入很短,比如“你好”,模型可能误判为闲聊。我会在示例里把这种边界 case 加进去,明确告诉模型“你好”属于闲聊,但如果是“你好,我想查订单”,就属于查询。
迭代优化方面,我倾向做动态示例选择。根据用户画像或场景,从示例库里检索最相关的 few-shot。比如用户是商家,就多放跟订单、库存相关的示例。还有一个关键点是负样本强化,定期收集误识别 case,加到 prompt 里作为反例。温度参数我一般设 0 到 0.3,保证输出稳定。
其实还有一个延伸点,就是模板的可维护性。业务方经常改意图列表,你不能每次都改 prompt,所以我会把模板跟意图列表解耦,用模板变量动态注入。但这样做有个风险,模型可能对新意图不熟悉,需要额外的示例。这个平衡怎么把握,我觉得值得深入讨论。
所以总结一下,我会把 prompt 模板设计看作一个系统工程,核心是角色定义、结构化输出、少样本示例,加上迭代优化。前提是你的分类体系要清晰,如果不清晰,模板写得再好也没用。我更倾向用少量高质量示例加动态选择,而不是堆大量示例,因为示例太多会让模型困惑。