1. 项目背景与价值定位
1.1 为什么我会做这个项目
先交代一下背景。我是做电商运营出身,后面转的技术方向,这两年在团队里负责用户增长和营销策略相关的数据工作。电商这个圈子,大家嘴上都在喊“精细化运营”,但实际落地的时候,大部分团队做的还是最传统的套路:RFM模型分层、用户画像标签、固定规则触达。
不能说这些方法没用,只能说天花板太低。
比如你做RFM分层,最后分出来高价值、中价值、低价值三拨人,然后呢?高价值的发大额券,低价值的发小额券,这本质上还是“一刀切”的运营逻辑。用户为什么流失?用户现在想要什么?用户对什么内容感兴趣?这些问题传统模型回答不了。
我这次做的项目,就是尝试把AI大模型引入到电商精准营销的完整链路里,从用户洞察、内容生成、渠道匹配到效果复盘,用大模型把过去靠人肉和经验判断的部分自动化、智能化。项目跑了大概三个月,覆盖了一个月活大概80万的美妆垂类电商平台,整体效果超出预期,我挑几个核心数据先放这:
- 营销内容点击率平均提升了37%
- 推送触达后的下单转化率提升了22%
- 用户流失召回成功率(30天内回访并产生行为)从原来的8%提升到了19%
- 运营团队每周的营销物料产出时间从12人时压缩到2人时
这个项目不是纯算法团队的科研项目,而是我带着两个运营同学、一个后端开发,在现有业务系统上一点点搭出来的。所以整套方案的可复制性很强,这篇文章我会把所有关键环节、踩坑经历、代码逻辑都拆开讲清楚,希望对正在做电商运营或营销系统的朋友有实质性帮助。
1.2 这套方案能解决什么问题
先说痛点。电商精准营销这件事,本质上是一个“在合适的时间、通过合适的渠道、把合适的内容推给合适的人”的匹配问题。传统做法的瓶颈有这么几个:
第一,用户理解停留在标签层面。平台上的用户标签可能有大几十个甚至上百个,但标签是静态的、离散的,它不能准确表达“这个用户最近因为什么原因下单意愿降低”“这个用户对什么成分的护肤品有兴趣”。标签是“是什么”,但营销需要知道“为什么”。
第二,内容生产效率太低。做一场大促活动,运营团队要准备几十上百套文案、海报、推送话术,商品卖点要靠人肉提炼,不同人群看到的还是同一套内容。一个月几十场活动下来,团队精力全耗在文案复制粘贴上了,根本没有余力做策略思考。
第三,触达时机和渠道的选择靠经验拍脑袋。什么时间推送?推送几次?用短信、Push还是公众号模板消息?大多数团队是凭感觉定的,缺少数据和模型支撑。
大模型解决这三个问题的路径非常清晰:用大模型的语义理解能力做动态用户意图分析,用生成能力做个性化内容批量生产,再配合一个轻量级的决策模型来做触达策略的匹配。本质上不是用大模型替代运营团队,而是把运营从“人肉匹配”中解放出来,去做更高层的策略设计。
拿项目里的一个具体场景举例。我们有一个客单价比较高的贵妇面霜,过去运营策略是:加购未下单的用户,统一在第二天上午10点发一张50元优惠券。用上大模型之后,系统会先分析这个用户最近的浏览行为、加购时间、历史客单价、甚至她咨询客服时聊过的内容,然后生成完全不同的触达话术:有人收到的是“这款面霜对干皮改善很明显,和你上次买的精华是同系列”,有人收到的是“你关注的博主推荐过这款,目前库存紧张”,有人收到的是“你有2000积分,今天抵扣可以省120元”。同样的商品,三套完全不同的文案,三种不同的利益点,这才叫精准营销。
1.3 适合谁参考这份方案
如果你属于下面几类人,这篇文章值得仔细看:
- 电商平台的运营负责人、增长负责人,想引入AI能力但不知道从哪下手
- 负责营销系统的后端或算法工程师,需要一套具体的落地方案
- 独立开发者或小团队,想给客户的电商平台做智能化升级
- 对AI Agent、大模型应用感兴趣,想找一个真实业务场景练手的学习者
这篇文章不是纯学术讨论,而是会给你一套清晰的架构、可落地的Prompt模板、关键代码逻辑和完整的踩坑记录。项目里用到的技术栈是:GPT系列模型(也兼容主流的开源模型如Qwen、ChatGLM)、向量数据库(Milvus)、Doris作为用户行为数仓、Python写服务层、简单的规则引擎做兜底。整体成本核算下来,单用户每次营销触发的模型调用成本约0.02元,完全在可接受范围内。
2. 整体架构与技术选型解析
2.1 系统架构设计思路
整个系统我把它分成四个核心模块:用户意图理解层、内容生成层、策略决策层、触达执行层。每个模块的定位和核心职责如下:
用户意图理解层:处理用户的行为序列数据、历史订单数据、客服对话数据,通过大模型进行语义级理解,输出结构化的用户意图标签和兴趣向量。
内容生成层:基于用户意图和商品知识库,生成个性化的营销文案、推荐理由、优惠信息和推送标题。这个模块是大模型发挥最核心价值的地方。
策略决策层:决定什么时间触达、走哪个渠道、推送频次上限是多少。这一层我用了轻量级的规则引擎加评分卡模型,说实话没有上太重的东西,因为实际业务中稳定性比复杂度更重要。
触达执行层:对接实际的推送通道(Push、短信、公众号模板消息、站内信),负责内容渲染、发送、数据回流。
这个架构的核心思路是“大模型做理解与生成,规则系统做控制与兜底”。为什么不把决策也完全交给大模型?因为在真实生产环境里,营销触达是有成本约束和频控要求的,比如同一个用户一天最多推两条Push,这些是硬性限制,交给规则系统更可靠。
2.2 大模型选型:闭源API和开源模型的取舍
模型选型这个环节我纠结了挺久,也建议大家不要盲目跟风。我的实际经验是这样的:
如果预算充足、对数据合规要求相对宽松(比如非敏感行业的营销内容),直接调用闭源API是最省事的路径。GPT-4系列和Claude系列的指令跟随能力和文案质量确实目前最强,中文电商场景下GPT-4o的文案生成效果明显好于开源模型,尤其是涉及情感化表达、卖点提炼这种soft skills。
但如果你是给金融、医疗这类强监管行业做,或者公司要求数据不出域,那就得考虑本地部署开源模型。项目里我测试过Qwen2.5-72B和ChatGLM4-9B两个模型,结论是:
| 对比维度 | GPT-4o | Qwen2.5-72B | ChatGLM4-9B |
|---|---|---|---|
| 文案质量 | 优秀 | 良好 | 中等 |
| 指令跟随能力 | 极强 | 较强 | 中等 |
| 部署成本 | 按Token付费 | 需要4张A100/或2张A800 | 1张4090即可 |
| 中文电商语义理解 | 良好 | 很强(电商语料训练充分) | 中等 |
| 推理速度 | 快 | 中等 | 快 |
最后我选的是一个“混合架构”:核心的内容生成走了闭源API(因为运营对文案质量要求高),用户意图理解部分用本地部署的Qwen2.5-72B(因为涉及用户数据,不方便外传),完全离线运行。这样既有质量又有合规,成本也控制住了。
如果是个人开发者或者小团队测试,我建议先从ChatGLM4-9B开始,量化版用4bit跑在单张4090上完全没问题,够用。等业务量起来了再往上升级,前期不用把预算烧在显卡上。
2.3 为什么用向量数据库存用户特征
用户意图理解层产出的是结构化的意图标签和兴趣向量,这些数据需要有一个地方存储。传统的MySQL其实也能存标签,但大模型产出的标签是开放的、非预定义的,同一个产品可以拆出“成分党”“性价比敏感”“熬夜急救”“送礼场景”等无限种维度的标签,用MySQL维护起来非常痛苦。
所以我在这个项目里引入了向量数据库。用户的行为序列经过大模型embedding化之后,得到一个高维向量,这个向量代表了用户当前的兴趣状态。系统实时把新行为追加到这个向量里,让用户兴趣保持“动态更新”。
举一个具体场景:一个用户平时买的是平价护肤品,但她最近三天连续搜索了“抗老精华”“紧致面霜”,并且点开了一篇关于“视黄醇”的文章。传统的标签系统会给她打一个“抗老兴趣”标签,但不会知道她的兴趣强度在上升。向量检索的能力体现在:系统可以找到和她当前兴趣向量最相似的商品、最相似的内容、甚至最相似的“目标人群”,从而给出精准推荐。
实际选型上我用了Milvus,原因有三点:一是开源免费,社区活跃;二是支持实时写入,适合电商场景高频更新的需求;三是和Python生态集成流畅。如果你的项目数据量在百万级以下,用Chroma或者Qdrant的轻量部署就够,没必要上Milvus这种重量级组件。
2.4 技术栈清单与成本核算
完整的技术栈清单如下:
- 大模型:GPT-4o(内容生成)、Qwen2.5-72B(意图理解,本地化部署)
- 向量存储:Milvus 2.3
- 用户行为数仓:Doris
- 服务层:Python 3.10 + FastAPI
- 任务调度:Apache Airflow(每天凌晨跑离线意图更新任务)
- 消息队列:RocketMQ(做实时触发链路)
- 规则引擎:Drools(策略控制与频控)
- 前端后台:Vue3 + Element Plus(给运营看效果报表)
成本这一块,很多团队最关心。我按实际账单核算了一下:
- 闭源API调用成本:单月约3800元(包含内容生成和部分兜底请求)
- 本地部署GPU服务器:用已有的A100机器,平摊硬件成本约每月2000元
- Milvus、Doris等服务部署在已有集群里,增量成本忽略不计
整体算下来,单用户每次营销触发的综合成本在0.02元左右。而过去我们每条短信成本是0.035元,也就是说,现在用大模型生成的个性化内容加推送,比过去单纯发一条短信还便宜。这个账很好算,老板看了没有理由不批预算。
3. 用户意图理解:大模型如何读懂用户
3.1 从行为日志到结构化意图标签
用户意图理解是整个系统的地基。地基没打好,后面生成的内容再华丽也推不对人。
我们的数据基础是用户行为日志,包括:浏览记录、搜索关键词、加购行为、下单记录、退款记录、客服咨询记录。原始日志长什么样?大概就是一堆JSON格式的事件流,每条事件包含事件类型、商品ID、时间戳、停留时长等信息。这些原始数据没法直接喂给大模型,需要先做一层清洗和序列化。
我设计的处理流程是:
第一,把每个用户过去7天的行为按时间排序,截取最多50条关键行为。 第二,把商品ID映射为商品名称和品类(这个映射关系从商品库拿)。 第三,加入订单和客服上下文,比如用户最近一个月买了什么、退过什么、问过什么。 第四,把以上信息拼装成结构化的文本,作为Prompt输入给模型。
Promp模板大概长这样:
prompt = f""" 你是电商平台的用户分析师。请根据下面的用户行为数据,分析该用户的购买意图和兴趣偏好。 用户基本信息:性别-{gender},年龄区间-{age_range},历史累计消费-{total_spend}元,近30天订单数-{order_count_30d}。 用户近7天行为序列(按时间排序): {behavior_sequence_text} 用户历史客服咨询记录: {service_ticket_text} 请输出以下JSON格式的分析结果: 1. current_intention: 用户当前最主要的购买意向(一句话描述) 2. interest_tags: 兴趣标签数组(最多5个,用简短名词) 3. pain_points: 用户可能存在的顾虑/痛点(最多3个) 4. price_sensitivity: 价格敏感度(高/中/低) 5. best_touch_time: 建议的触达时间段(如"20:00-22:00") 6. recommended_product_ids: 推荐商品ID数组(最多3个) 只输出JSON,不要输出其他内容。 """这个Prompt的实际效果比我预期的好。因为大模型能综合理解“昨天凌晨三点还在搜索祛痘产品”和“三天前咨询过客服是否含酒精”这些细节,这些信息在传统标签体系里是很容易被忽略的。
3.2 意图理解的质量控制与降级策略
大模型的输出不是100%可信的,这一点必须有心理准备。我在项目里做了三层质量控制:
第一层,JSON格式校验。大模型输出的结果必须能被正则解析为合法JSON,解析失败的直接丢弃,走规则兜底。
第二层,字段合法性校验。比如千推的词不能是默认的100以内,否则视为没抓到信息。商品ID必须是商品库中真实存在的。
第三层,业务规则覆盖。比如一个用户历史客单价是2000元,模型却推荐了单价50元的商品,这明显是异常结果,会被拦截。
我统计过,这三个环节加起来,能拦截掉大约8%-10%的低质量模型输出。剩下的90%直接进入下一层。
另外要提一个非常重要的降级策略:如果大模型服务超时或返回异常,系统要能自动降级到传统规则引擎。我这边是在意图理解服务外面包了一层 try/except,超时时间设置为3秒,超时后直接走RFM分层的老逻辑。这个设计让我在模型服务不稳定的时候也没有出现过营销任务停摆的情况。
3.3 向量化:让用户兴趣可以被计算
意图理解层最后一步是向量化。我使用Qwen自带的embedding接口,把用户当前的所有兴趣标签、最近行为摘要拼接成一个文本块,embedding成1536维的向量,写入Milvus。
具体来说,每个用户会有两个向量对象:一个是长期兴趣向量(基于最近30天数据),一个是短期兴趣向量(基于最近3天数据)。营销任务里推荐商品时,短期兴趣向量的权重更高;做流失召回时,长期兴趣向量更有效。
这里有一个经验细节:Milvus里搜索时不要只用余弦相似度,最好结合时间衰减因子。同一个商品,三天前浏览的和昨天浏览的,行为向量应该有显著差别。我在计算短期向量时加入了指数时间衰减:
import numpy as np from datetime import datetime, timedelta def build_short_term_vector(user_events: list, event_vectors: dict) -> np.ndarray: # user_events: 用户最近N天的行为事件列表,每个事件包含event_time和embedding_id # event_vectors: 每个行为的预计算向量表 now = datetime.now() total_weight = 0 weighted_vector = np.zeros(1536) for event in user_events: # 计算时间衰减权重,半衰期设为24小时 time_diff_hours = (now - event['event_time']).total_seconds() / 3600 weight = 0.5 ** (time_diff_hours / 24) vector = event_vectors[event['embedding_id']] weighted_vector += weight * vector total_weight += weight if total_weight == 0: return np.zeros(1536) return weighted_vector / total_weight这段代码的逻辑是:距离当前时间越近的行为,在用户短期意图向量中的权重越大。24小时的半衰期是我根据多次A/B测试调出来的,太短会导致历史一周的收藏行为被完全遗忘,太长又会导致实时兴趣不敏感。
4. 内容生成:让大模型批量产出个性化营销物料
4.1 商品知识库的建设与Prompt设计
内容生成层依赖两大输入:用户意图信息和商品信息。用户意图我们已经在第三章建立好了,接下来要解决的是商品信息的结构化。
商品知识库不是简单的商品名称和价格,而是包含多维度的卖点信息、成分信息、适用人群、竞品对比等。我们团队花了大概两周时间,把库里的核心SKU全部手工梳理了一遍,每个商品都整理成统一的Markdown格式:
## 商品ID: SP20240116 - 商品名称: 某某品牌玻尿酸保湿精华液 - 核心成分: 玻尿酸、神经酰胺、泛醇 - 功效标签: 深层保湿、修护屏障、舒缓干燥 - 适用肤质: 干性、中性、混合偏干 - 核心卖点: 三重分子量玻尿酸,小分子深层渗透,大分子表层锁水 - 价格区间: 中高端(200-350元) - 目标人群: 25-40岁重视成分护肤的女性 - 差异化优势: 不含酒精、香精,敏感肌可用 - 典型使用场景: 换季干燥、暖气房熬夜后急救每一个商品文档控制在200-400字,太长了大模型容易“迷失重点”,太短了生成的内容缺乏支撑细节。
Prompt设计上,我的核心经验是把内容生成拆成“两步走”:第一步生成营销角度与策略,第二步生成具体文案。别指望一个Prompt直接产出完美文案,一步到位的结果通常是平庸的。
第一步的Prompt模板:
prompt = f""" 你是一位资深的电商营销专家。现在需要针对下面的用户画像和商品信息,制定营销策略。 【商品信息】 {product_doc} 【用户画像】 {user_profile_text} 请从以下三个角度考虑营销策略: 1. 用户可能最关心的利益点是什么? 2. 什么样的切入点最容易打动这类用户?(成分功效/价格优惠/场景共鸣/社交认同) 3. 建议的主标题方向(15字以内) 输出格式: 策略洞察:... 切入角度:... 主标题方向:... """第二步再将策略洞察作为上下文,结合商品信息和用户画像生成完整文案。这样生成出来的文案不是“通用模板套用户”,而是真正“以用户为中心”定制的。
4.2 不同触达渠道的内容模板
不同渠道对内容格式的要求不同,我这边是做了三套渠道模板:
Push通知:限制30字以内标题 + 50字以内正文,核心是“制造悬念+明确利益点”。比如:
“你关注的急救精华,今晚8点限时直降80元”
短信:限制70字以内,因为短信是按条计费的,太长浪费成本。核心是“利益点前置”。比如:
【某某美妆】您的专属券已到账!满300减80,限今日,点击领取>>
公众号模板消息/推文:可以承载更长内容,适合种草型营销。我会让大模型生成一段150字的推荐理由,再配上3-5条实用小建议,让用户觉得“这条推送对我是有价值的”,而不是单纯的广告。
模板切换是通过一个大函数控制的,根据触达渠道选择不同的生成约束:
CHANNEL_CONSTRAINTS = { "push": {"max_title_len": 30, "max_body_len": 50, "tone": "简洁有紧迫感"}, "sms": {"max_body_len": 70, "tone": "利益点前置,清晰明了"}, "wechat": {"max_title_len": 20, "max_body_len": 300, "tone": "种草推荐,内容有温度"} } def generate_channel_content(product_doc, user_profile, strategy, channel): constraint = CHANNEL_CONSTRAINTS[channel] channel_prompt = f""" 你是电商文案专家。请根据以下信息生成{channel}渠道的营销内容。 渠道要求:{constraint['tone']},标题不超过{constraint['max_title_len']}字,正文不超过{constraint['max_body_len']}字。 ...(商品信息、用户画像、策略洞察) """ ...4.3 内容质量过滤与A/B测试验证
大模型生成内容还有一个非常现实的问题:同一批商品反复触达同一个人,内容会很快同质化。我做过一次统计,同一个用户连续收到三条推送,如果推送模板的前15个字高度相似,点击率几乎腰斩。
所以我在内容生成后加了一个文案去重模块,用SimHash算法计算生成文案和历史推送的相似度,相似度超过0.85的主动弃用,重新生成。这个模块虽然逻辑简单,但对用户体验的提升非常明显。
质量过滤做完之后,还要经过内容合规审核。电商内容涉及的敏感词比较多——极限词(“最”“第一”)、医疗功效宣称(“祛痘”“抗炎”)等。我这边是接入了开源敏感词库再加上自定义规则,生成内容命中敏感词的直接打回重写,不允许直接标记过审。这条建议一定要落实到工程上,不要依赖人工审核,否则运营团队会被零碎的低质内容淹没。
最后,所有的文案上线之前都会进入A/B测试池。我们选了10%的流量做实验,用大模型生成内容和原有运营文案做对比,跑一周看数据。从项目累积的实验结果看,大模型文案综合点击率提升37%,不同品类存在较大差异:美妆类的提升最明显,接近50%;食品类的小一些,在20%左右;3C数码类的文案效果和人工写的相差不大。这说明大模型在情感表达和生活方式类内容上更占优势,在参数堆料型的产品描述上优势有限。
5. 策略决策与触达执行
5.1 触达时机与频次控制策略
内容生成好了,下一步就是决定“什么时候发”“发几次”。传统做法是运营拍脑袋定一个“黄金时间”,比如美妆品类晚上8点到10点效果最好,于是所有推送都放在这个时间段。但每个用户的作息不同,用一个固定的黄金时间触达所有人,本质上还是不精准。
我这边做了一套用户个体触达时间优化的方案。具体做法是,统计每个用户近30天在平台上产生行为的历史时间分布,行为包括开App、点击推送、下单等。假设一个用户经常在早上7点到8点刷手机看商品,系统就会把她的推送时间定在早上7点30左右。数据和规则很简单,效果却不小:整体推送的打开率提升了约15%。
频次控制方面,我设置了四级频控策略:
- 单用户每天Push不超过3条
- 单用户每天短信不超过1条
- 同一商品7天内对同一用户只推送一次
- 用户如果已经点击了某条推送,该推送所属活动的后续触达自动取消
这套频控规则是在规则引擎里实现的,不需要每次调用大模型反复判断。大模型管“质”,规则引擎管“量”,这个分工非常重要。如果让大模型来做频控决策,每次都要重新读一遍用户的历史接收记录,既增加调用延迟,又容易出错。
5.2 推荐商品匹配与优惠力度决策
推荐什么商品,也是一个需要结合用户意图做判断的事情。我在第三章提到用户意图理解层会输出一个recommended_product_ids数组,这个数组初筛范围大概在3到5个商品。正式推送前,系统会调一个轻量级排序模型,结合向量相似度和实时库存、利润、补贴预算等因素,最终确定推哪个商品。
优惠力度的决策,核心原则是“不为了发券而发券”。过去我们的运营经常一上来就发大额券,结果用户养成了“没券不买”的习惯,利润空间被压得很低。用大模型分析之后,我们发现有些用户需要的不是优惠券,而是“稀缺感”或“专业背书”。
举几个实际例子:
- 对成分党用户,推送“XX成分浓度提升到10%,点击查看成分解读”比发20元券有效得多
- 对价格敏感用户,推送“限时闪购,价格直降15%”比推送满减券更直接
- 对犹豫型用户(多次加购未买),推送“库存紧张,仅剩3件”配合小额优惠
所以这一层我也做了一个优惠策略生成器,让大模型根据用户画像给出优惠建议类型(直降、满减、赠品、积分抵扣、稀缺提醒等),再由规则引擎结合预算控制决定最终的优惠参数。
5.3 实时触发的技术链路实现
实时触发链路是这个项目里技术含量比较高的部分,我做了一个简单的流程控制。它的交互逻辑是:
用户产生关键行为(比如加购、搜索某个商品、点击某篇文章)→ 行为通过埋点上报 → RocketMQ收到事件 → 触发意图理解服务(调用本地Qwen2.5)→ 拿到意图理解结果 → 判定是否触发营销规则 → 生成个性化文案 → 推送到触达执行层。
这里有一个关键设计:不是每个行为都要触发大模型,那样成本扛不住。我设置了一个“行为阈值开关”,只有满足以下条件之一才触发:
- 用户加购后20分钟未下单
- 用户搜索同一关键词超过3次
- 用户点击了商品详情页超过5次且未加购
- 用户加入购物车的商品在24小时内降价
这几个规则的触发逻辑完全可以用Dropols规则引擎表达,轻量又可靠。大模型是被“按需调用”的,而不是常驻等待每个行为都回应。
5.4 数据回流与分析体系
触达执行完,事情还没结束。精准营销是一个持续优化的闭环,每一轮触达的效果数据必须回流到系统里,反向优化模型和策略。
回流的数据包括:
- 推送送达状态(送达/失败/被拦截)
- 用户打开行为(时间、设备、上下文)
- 用户点击行为(点击了哪个位置、是否跳转落地页)
- 转化行为(加购、下单、支付金额)
数据回流到Doris之后,我会定期跑几个关键指标的汇总:
| 指标 | 计算方式 | 业务意义 |
|---|---|---|
| 点击率 | 点击人数/送达人数 | 内容吸引力 |
| 转化率 | 下单人数/点击人数 | 内容说服力 |
| 退订率 | 退订人数/送达人数 | 内容骚扰度 |
| ROI | (营销带来的GMV - 营销成本)/营销成本 | 整体有效性 |
每个月我会做一次策略复盘,把RocketMQ里的所有触发记录带回给大模型,让它读一遍后找出策略中的漏洞。比如发现某一段时间内触达了过多对价格不敏感的用户,但推送内容还是以优惠为主,这就是策略和用户不匹配。大模型给出建议之后,我在Prompt里把这一类模式作为反例加进去,让后续的生成更加符合预期。
6. 常见问题与排查技巧实录
6.1 模型生成内容质量不稳定的问题
跑这个项目期间,我遇到的第一大问题就是大模型生成质量的波动。同一个Prompt,上午和下午生成的内容可能差很多。不是格式问题,而是“灵性”问题。有时候生成的内容让人眼前一亮,有时候却像在背书。
排查下来,原因有两个:一是模型温度的设置值太高,creative有余但可控性不足。我后来把temperature从0.9逐步降到0.6,稳定性明显提升,而内容的多样性并没有损失太多。二是Prompt里的信息太多了,大模型不知道该优先关注哪些。后来我把Prompt里最关键的“利益点”部分高亮突出,让模型明确知道这是核心约束条件。
我的经验是:在质量敏感性场景下,temperature设置在0.5-0.7之间,并且每次调整必须对比实际生成结果,不要只看指标。过于追求“稳定”会让文案模板化,过于追求“创新”又会让文案跑偏,这个平衡只有实测才能找到。
6.2 用户意图理解不准的问题
有段时间系统对“已经购买过的用户”推荐了同款商品,用户在反馈里直接吐槽“刚买的又推给我,是不是有毛病”。问题出在意图理解层的序列构建上:我的行为序列抓取逻辑同时包含了过去30天的“全部行为”,购买行为之后的历史浏览记录没有做剔除,导致模型认为用户还在浏览这个商品。
修复方案很简单:在构造行为序列时,如果用户已经购买了某个商品,就删除该商品id在购买时间节点之后的所有行为记录。同时在Prompt里加了一句“用户已购买的商品请勿推荐同款”。
这类问题用大模型反而好修,因为只要在Prompt层面调整规则即可,不需要像传统推荐系统那样去改复杂的推荐算法。
6.3 推送频次过高导致用户退订
项目上线初期,我给规则引擎设置了比较宽松的频控,导致一小部分高活跃用户一天收到七八条推送。这些用户本来就是平台的忠实客户,结果密集的推送让他们产生了厌烦情绪,退订率一度飙到3.2%。
这个问题的教训是:频控规则上线前一定要做用户分群的压力测试。活跃用户的接收阈值和沉默用户完全不同,不能用一套统一的频控。我后来把用户按照近7天活跃度分成了五个等级,越活跃的用户Push频次上限反而越低,因为他们本来就会主动打开App看到商品信息,不需要靠Push引导。调整后,退订率回落到0.8%,整体有效转化没有下降。
6.4 模型延迟导致触达超时的问题
还有一个实际运维中高概率遇到的问题是:大模型调用延迟导致推送错过最佳时间窗口。比如用户加购了商品,系统计划在20分钟后推送一条挽留文案,但模型生成花了15秒,加上网络传输和MQ排队,实际推送延迟到了25分钟。对于用户来说,“刚加购就被追着推荐”和“过了半小时才收到提醒”的体验差别是很大的。
我的解决思路是:加购挽留这个场景不走实时生成链路,而是用预生成模板加即时填充变量。用户在加购前,系统已经根据她的历史行为预生成了3套不同风格的挽留文案模板,等她触发加购事件时,只需要做一个动态变量的填充(比如商品名、优惠金额),整个过程在毫秒级完成。
这个改造成果是加了购挽留场景的转化率提升了12%,同时几乎没有额外增加模型调用成本。把大模型用在“策略生成”上,而不是“每个请求的实时推理”上,这个思路贯穿了整个项目。
6.5 问题排查速查表
最后整理一份速查表,方便大家在实际中遇到问题快速定位:
| 问题现象 | 可能原因 | 排查思路与解决方案 |
|---|---|---|
| 生成的文案模板化严重 | temperature值过高或过低 | 调整到0.5-0.7区间,同时丰富商品知识库 |
| 推送没送达 | 触达渠道token失效 | 检查用户授权状态,增加token刷新机制 |
| 点击率低但打开率高 | 内容与用户兴趣不匹配 | 检查意图理解层的行为序列是否最新 |
| 转化率低但点击率高 | 利益点不够吸引人 | 分析落地页质检,调整优惠力度 |
| 同一商品频繁推给同人 | 去重模块失效 | 检查SimHash阈值,加入商品维度的规则去重 |
| 模型调用超时 | 并发过高或模型推理慢 | 增加预生成模板,或用异步方式处理非紧急触达 |
| 向量检索结果不相关 | 用户向量数据过期 | 重建短期兴趣向量,检查时间衰减参数 |
7. 项目扩展方向与落地建议
7.1 从精准营销扩展到智能客服
这个项目的架构做完之后,我发现一个很有意思的事情:用户意图理解层的输出,实际上可以直接复用到智能客服场景上。当用户打开客服对话框,系统已经知道了她近期的兴趣偏好、购买意图和潜在痛点,客服机器人完全可以基于这些上下文做更精准的回答。
比如用户咨询“这款面霜会不会很油”,传统客服机器人只能根据预设问答回复产品质地。但如果系统知道这个用户最近搜索过“油皮面霜推荐”,客服就可以补充一句“这款专为油皮设计,很多油皮用户反馈吸收后不黏腻,和你上次买的乳液是同一系列”。这种体验上的提升是肉眼可见的。
7.2 从文本生成扩展到多模态营销物料
目前的方案主要解决的是文本内容生成,但实际上电商营销物料还有大量图片和短视频需求。下一阶段可以引入多模态大模型,根据商品知识库和用户画像自动生成海报文案配图、短视频脚本甚至数字人直播话术。
我这边已经在测试用文生图模型批量生成商品图背景和卖点示意图,相比人工设计效率提升非常明显。当然多模态这条链路的质量把控比纯文本更难,需要建立更严格的审核机制。
7.3 给团队落地这个项目的5条建议
最后,结合我个人经验,给想复制这套方案的团队一些建议:
第一,先跑通最小闭环,再想扩展。不要一上来就试图覆盖所有业务场景,选一个最核心的场景(比如购物车挽留),把意图理解、内容生成、触达、复盘整条链路跑通,看到数据效果再逐步扩展。
第二,数据基础决定上限。大模型再聪明,没有高质量的用户行为数据和商品知识库也是白搭。前期花在数据清洗和商品知识库整理上的时间,一定会在后面的效果上体现出来。
第三,建立“人机协同”的运营流程。大模型生成的内容必须有人在关键节点把关。我的做法是:日常营销内容全自动生成自动发送;大促期间,核心创意由人工定调,大模型负责批量微调和多版本生成。这样既有创意高度又有执行效率。
第四,监控和报警系统不能省。大模型是概率系统,偶尔输出离谱内容是必然事件。必须建立实时监控看板,关键指标(转化率、退订率、投诉率)出现异常时立刻触发人工介入。
第五,持续做Prompt迭代和知识库更新。大模型的输出质量高度依赖Prompt的质量。我建议每个月抽取一批新的成功案例和失败案例,把它们沉淀到Prompt模板和知识库中,让系统越来越“懂”你的业务。
踩了三个月的坑之后,我个人最深的体会是:AI大模型在电商精准营销里的价值不是“替代人”,而是把过去运营团队耗费在重复劳动上的时间释放出来,让大家专注于真正的策略思考和创意策划。这套方案能跑通,核心原因不是模型有多强,而是我们把“用户意图理解、内容生成、策略决策、触达执行”这条链路的每一步都拆得足够清楚,并且在大模型和规则系统之间做好了明确分工。
如果你也在做类似的尝试,从购物车挽留这个场景开始,一定不会错。