这道题其实问的是,怎么让大模型在电商这种业务里稳定输出,而不是偶尔惊艳偶尔翻车。核心就一句话:用工程手段把不确定性锁住。我主要从三个层面来拆。
先说角色锚定和结构化。很多人觉得给模型一个角色就够了,比如“你是导购”,但真正落地你会发现,角色不锚定场景,模型容易跑偏。比如商品推荐,我会把用户画像、当前库存、价格带都写进 [[System Prompt]],像“你是资深导购,用户是25-30岁女性,偏好简约,预算300以内”,这样输出才聚焦。然后输入输出必须结构化,输入用JSON包字段,输出强制格式,比如“推荐1: 商品ID | 理由: 一句话”。为什么?因为自然语言输出太飘了,下游系统没法解析,你总不能人肉看吧。
再一个,[[少样本]]示例。光靠指令不够,模型对格式的理解不稳定。我会给两三个完整示例,比如“用户问夏天透气运动鞋,商品A是网面跑鞋,输出推荐商品A | 理由:网面透气”。这能让模型模仿格式,减少乱答。
举个例子,客服退款场景。用户问“我订单超时没退款”,模型不能瞎编政策。我会把知识库检索到的相关政策段注入prompt,比如“退款规则:超时未退自动触发,48小时到账”,然后加拒答策略:“若问题不在知识库,回复‘已转人工’”。这样既准确又安全。少样本示例在这里特别有用,我通常给一个正确回答和一个拒答示例,模型就学会什么时候该说“不知道”。
但这里有个坑:少样本示例不能太多,否则prompt太长,成本高还容易超上下文。一般两三个就够了,而且要选典型场景。
落地风险我重点说两个。一是[[幻觉]],模型可能推荐下架商品或编造退款金额。所以输出后一定要加规则校验,比如用正则查商品ID是否在库、金额是否合理,不通过就降级到兜底文案。二是成本,电商场景量大,prompt不能太肥。我通常把长商品描述用 [[Embedding]] 检索,只取Top3注入,而不是全量。这样延迟和成本都能接受。
还有个延伸点:当知识库更新频繁时,Few-shot 示例也要跟着变,否则模型用旧示例会误导。我倾向于把示例也做成动态检索,根据当前query取最相关的示例,效果比固定示例好不少。
最后说下边界。有人问为什么不用 [[RAG]] 或微调?我的看法是:RAG适合知识密集但不需要模型理解的任务,比如政策问答;微调适合风格固定、输出格式统一的任务,比如评论摘要。但电商场景复杂,往往是混合的。比如商品推荐,既需要实时库存(RAG),又需要个性化风格(微调),我会先用微调让模型学会推荐逻辑,再注入实时数据做 RAG。说白了,没有银弹,落地时我会优先用prompt工程,成本低迭代快,只有prompt搞不定才考虑微调。
总结一下,我的核心思路是:用结构化和少样本稳住输出,用规则校验兜住幻觉,用检索压缩控制成本,同时动态调整示例。这样模型才能在生产里稳定跑起来。