说出来你可能不信我们团队最初接到“大模型营销广告”这个项目时第一反应不是兴奋而是头疼。头疼的原因很简单货拉拉的广告场景跟常见的电商广告差别太大了。同城货运、搬家拉货、新用户补贴、司机端任务这些场景交织在一起产出的素材量以万计但每一批素材的有效生命周期可能就几天。外部API调用成本太高数据出域又有顾虑传统的模板系统又撑不住千变万化的营销活动。做了几个月的实践之后我最大的感触是大模型在营销广告里的价值远不是“AI写文案”这么简单它真正改变的是整个内容生产链路。这篇文章我会从业务痛点、技术选型、场景落地、微调实战、工程排查几个维度把我们在货拉拉营销广告场景里的实践思路和踩过的坑都摊开讲。1. 项目背景与业务痛点拆解1.1 货拉拉营销广告场景的特殊性先聊聊场景本身。货拉拉是货运平台但它跟传统物流公司不太一样用户画像更复杂一边是C端用户搬家、拉货、临时用车另一边是司机端和商户端跑腿、批发市场进货、工厂发货。广告场景不只是App里的banner和弹窗还包括应用商店、信息流、短信push、户外广告、司机端任务卡片等等。这个场景有几个很鲜明的特点直接影响了大模型落地的方向。第一地域属性极强。同城货运里“距离”是核心变量用户在某条街打开App看到的应该是附近能接单的司机。广告文案里写“你的城市也能用”和“全国通用”完全是两种说服力。第二长尾需求非常多。“搬冰箱”“买家具送货”“批发市场拉货”“店面搬迁”这种长尾词传统人工写文案很容易漏掉但大模型对这种长尾语义的理解和表达非常在行。第三促销与补贴节奏极快。平台经常按城市、按人群、按时段切换补贴策略文案、素材、落地页都要跟着变这时候内容生产的吞吐量就变成一个硬指标。传统做法是运营提需求、设计师出图、文案写手出词再一轮一轮审核修改一套素材下来少说两三天。活动多的时候团队被大量基础性生产任务淹没真正花在策略思考上的时间反而很少。我们做这个项目本质上是想把“内容生产”从人力密集型变成“人审模型生产”的模式让人的精力更多放在判断和决策上。1.2 传统广告生产流程的瓶颈传统流程的瓶颈可以归纳成三点这三点也是我们立项时写进需求文档的核心依据。第一是速度。一次大规模拉新活动可能同时需要几十个城市的素材每个城市还要配好几套文案和配图。人工做一轮要两三天等做完市场和竞对的节奏早就变了。第二是风格统一难。不同写手写出来的文案风格差异很大有的偏粗暴直给有的偏文艺品牌调性很难稳定审核成本也不低。第三是定向粗放。传统素材大多是“一个版本打天下”虽然能按城市粗分但很难做到真正的千人千面。这三个瓶颈指向同一个问题平台需要一种能快速生成、批量生成、并且可控性强的内容生产方案。大模型恰好具备这个潜力但“有潜力”和“能用”之间还有很大距离这也是后面章节会详细展开的部分。说白了模型只是发动机要让发动机带动整台车跑起来还得配变速箱、刹车和方向盘。1.3 为什么选择大模型而不用传统NLP有人会问文案生成以前也有模板系统自动填充城市名和优惠金额不就行了为什么一定要上大模型我的回答是模板系统解决的是“确定性内容”的问题它只能生成结构固定的句子比如“今日{城市}搬家优惠立减{金额}元”。但营销广告里大量需求是非确定性的同一个促销信息要在不同渠道、面向不同人群生成不同语气、不同侧重点的表达传统模板要覆盖这些变体只能靠人工枚举成本极高枚举完还容易不自然。大模型解决的是“给定的意思用不同方式表达”的问题它本质上是一个语义层面的生成器而不是字符串拼接器。同时经过微调的模型可以学习到货拉拉风格的具体表达习惯比如司机师傅关心“单量稳不稳”用户关心“价格透明不透明”。这些都是传统规则很难建模的东西。当然大模型也有自己的问题幻觉、成本、延迟、不可控。这正是项目里需要在工程层面逐一解决的部分后面每一章都会提到对应的处理办法。2. 技术选型与整体架构思路2.1 基座模型怎么选中文能力、成本、可控性模型选型是这个项目最早、也最纠结的决策。我们当时主要看开源模型核心原因是数据可控性和成本可控性。广告素材涉及大量业务关键词、城市名称、价格档位如果全部走外部API一是费用随调用量线性增长二是数据出域这件事在合规上就有压力。数据在自己手里模型参数在自己手里迭代和生产才有安全感。当时对比了多个开源基座Qwen系列、Llama系列以及一些垂直中文模型。综合来看我们选了Qwen系列作为主力基座。原因有三中文语料质量高生成的口语化文案更自然对长上下文和工具调用的支持比较完善生态好周边工具链齐全从微调到推理都有成熟方案。这不是说其他模型不行而是这个选择匹配我们的业务场景。这里想强调一点选模型不是看跑分而是看场景。营销文案生成这个任务对模型的“中文口语自然度”和“业务指代理解”要求高而不是对数学推理能力要求高。用那些以代码和逻辑见长的模型来写广告文案效果反而一般。这也是很多团队在选型时容易踩的坑——只看榜单不看任务。榜单上的综合分高不代表它在你的数据分布上表现好。2.2 本地部署与资源评估GPU配置与推理引擎定了基座模型接下来就是部署形态。营销内容生产分为离线批量和在线实时两条链路。离线批量用于大规模的素材预生成对延迟不敏感但吞吐量要求高在线实时用于投放系统中的动态拼接比如根据用户实时位置、活动信息生成个性化文案对延迟有硬要求。我们当时的GPU资源比较紧张不是所有场景都能上满血大模型所以做了分级策略复杂创意生成走微调后的7B/14B模型用vLLM做推理部署配合张量并行提升吞吐简单拼接类任务走轻量模型甚至规则模板。离线生产用异步队列每天凌晨批量跑一轮把生成结果落到缓存线上优先读缓存既省成本又能控延迟。关于推理引擎vLLM是我们用得比较顺手的方案显存管理好、吞吐高部署也简单。如果只是内部实验Ollama也能快速起一个环境但生产环境建议还是用vLLM这类专用推理框架量化、并发、API接口都更可控。GPU配置方面7B模型做推理基本需要16GB以上显存如果加长上下文和并发24GB是更稳妥的起点。上线前一定要做压测用实际业务prompt跑一轮观察最大吞吐和尾延迟再决定上线规模和实例数量。提示不要凭经验估计并发能力。大模型推理的显存占用、并发吞吐和模型配置强相关建议拿真实业务prompt先压测再定容器规格不然上线第一天容易被流量打爆。2.3 整体架构从生成到审核到投放的闭环整个系统架构可以概括成三层闭环内容生产层、审核风控层、投放反馈层。内容生产层负责生成文案、图片素材、落地页要素核心是几个微调模型加一批动态模板。审核风控层是所有生成内容上线前的必经关卡包含广告法违禁词检测、敏感内容识别、事实一致性校验这部分后面会详细讲。投放反馈层负责把生成内容接入广告投放系统实时收集点击率、转化率、成本等指标再把这些指标反馈给生成层形成素材迭代的闭环。三层的关系就像一条流水线模型生产出毛坯素材审核层做质检和修正投放层负责试错和验证验证结果再指导下一轮生产。这套架构的好处是每个环节可以独立迭代模型升级不用等投放系统改造投放策略更新也不用动生成逻辑。我们团队只有十几个人如果做成一个大一统的系统迭代速度根本跟不上业务节奏分层是必然选择。3. 核心落地场景一营销文案与素材的智能化生产3.1 文案生成的业务化改造从通用生成到货拉拉风格文案生成是我们第一个落地、也是收益最明显的场景。最开始我们直接用基座模型试跑生成的文案通顺但“平台感”很强放在货运场景里很突兀一看就不是人能写出来的业务文案。后来才发现问题所在基座模型学的是全网语料它理解的“货运”是物流行业的货运不是同城搬家拉货的货运。解决办法是微调。我们整理了几万条历史优质文案和对应的投放数据构造了“城市人群活动信息文案”的训练对用LoRA微调了一个货运广告文案模型。微调后生成的文案明显有了业务味道比如会用“师傅接单快”“价格透明”“新用户立减”这些真实场景里的表达不再是泛泛的“专业货运服务”。这里分享一个实践细节微调不是让模型变聪明而是让模型“知道自己是干什么的”。训练数据里不只是文案本身还要带上业务上下文让模型学习的是“这个城市、这批用户、这个活动下该说什么”而不是孤立地学造句。数据里如果没有业务上下文模型学到的是语言风格而不是决策逻辑两者差别很大。3.2 多模态素材生成广告图与落地页的尝试文案跑通之后我们开始尝试图片素材的生成。这里说的不只是简单的文生图而是“活动运营图”比如“搬家场景优惠信息品牌元素”的组合图。坦白讲这块难度比文案大很多。大模型生成的图片在美观度上进步很大但有几个业务硬伤。第一文字渲染容易出错广告图里经常要显示“首单立减20元”模型很容易把字写错。第二品牌元素一致性难保证品牌色、logo形状每次生成都有偏移。第三审核风险生成图里可能莫名出现路人、车牌号、其他品牌logo这些都是广告素材审核的红线。我们的方案是分步走先有可控的模板底图再用模型生成特定的场景背景或人物姿势最后把业务文字用程序化渲染的方式叠加回去。简单说大模型负责“创意层”程序负责“确定性层”。这样既保留了生成的多样性又保证了文字和品牌元素的准确性。如果你也想做类似的事建议不要指望模型一步到位输出最终素材而是把流程拆成多个环节每个环节只解决一类问题。3.3 提示词工程与动态模板的配合还有一个容易忽视但很重要的点提示词和动态模板怎么配合。营销活动信息是高频变化的今天北京做“满100减20”明天上海做“满120减30”。如果这些信息都靠写死在提示词里活动一变就要重新生成一批素材成本很高。我们的做法是把活动信息外置通过动态模板拼装上下文让模型只负责生成“表达层”。举个例子提示词模板里会预留变量系统设定你是货运平台的营销文案专家熟悉同城搬家、拉货场景的用户心理。 业务背景今天是{date}城市{city}正在开展活动{activity}。 目标人群{audience}如“近期打开过App但未下单的搬家用户” 生成要求写一条不超过{max_len}字的拉新文案语气{style}重点突出{key_points}不得使用广告违禁词。然后程序去读取当前活动配置动态填充这些变量。这样模型不需要重新微调也能适配不同促销节奏。这个思路也适用于Agent场景等于把“知识”和“表达”做了一个清晰的分层。注意动态模板里的变量一定要做白名单校验。如果这个环节漏了用户输入或活动配置里的内容可能绕过审核层形成提示词注入风险。我们在这方面吃过亏现在是强制校验后再拼模板。4. 核心落地场景二投放策略与AI Agent4.1 人群包与定向策略的智能化生成内容生产只是前半段后半段是投放。广告投放里最核心的动作之一是“定向”决定这批素材投给谁。货拉拉的定向维度很多城市、距离、用户活跃时段、搬家需求信号、历史车型偏好等。以前运营是人肉配置人群包每个活动配几十个包就要忙很久。我们尝试用大模型来做人群包生成的辅助判断比如运营用自然语言描述“我要上海最近30天打开过App但没下单的搬家用户”模型自动转换成结构化的定向条件。这个场景本质上不是生成任务而是“自然语言到结构化规则”的翻译任务。我们一开始直接用基座模型做结构化输出的格式总是不稳定偶尔多一个括号、少一个引号下游系统就报错。后来加了一层约束解码限定模型只能输出预定义的操作符和字段格式错误率就降下来了。这里给所有要做类似事情的朋友一个建议凡是涉及结构化输出的任务一定在输出层做刚性约束不能完全信赖模型自己保证JSON格式解析失败的成本远高于约束实现的成本。4.2 Agent在广告计划管理中的位置再往上一层我们尝试过用Agent框架来做广告计划的日常管理。当时主流的Agent框架我们都调研过包括LangChain这类偏通用编排的以及一些更垂直的广告投放Agent框架。坦白讲完全自主的“无人驾驶”式投放管理现在的技术成熟度还不足以支撑。广告投放涉及真金白银的预算消耗如果Agent在某个环节判断失误损失不可逆。所以我们采用的是一种“人类决策Agent执行”的人机协同模式Agent负责监控投放数据、发现异常比如某个人群包成本飙升、生成调整建议运营人员确认后Agent再去执行调价、暂停计划、换素材等动作。这个模式落地之后运营团队的工作模式从“盯数据”变成了“审建议”效率提升是肉眼可见的。但这里也暴露了一个问题Agent生成建议的可解释性不够。运营看不到完整的推理链路有时不敢直接采纳。所以我们在Agent输出里增加了“决策依据”字段要求Agent给出影响因素和优先级排序让运营能快速判断建议是否合理。没有可解释性的Agent在一个敢花预算的团队里是很难被信任的。4.3 效果数据回流与素材自动迭代闭环最后是一个很容易被忽视的工程点数据回流。模型生成了一批素材投放出去了效果好坏必须回流给模型侧否则整个系统就是“盲人摸象”。我们搭了一套素材标签体系每一批生成素材都带上活动ID、文案模板版本、提示词版本、模型版本、投放渠道等元数据。投放后24小时点击率、转化率、获客成本等指标会回写到素材管理系统里。这个数据回流的价值不只是用来做报表更重要的是指导下一轮生成。比如我们发现某个文案模型在“搬家场景”的点击率明显高于“拉货场景”就会把训练数据里搬家场景的比例调高或者单独微调一个搬家专用版本。通过这种方式素材生产效率是持续迭代的而不是一次性上线就结束了。数据回流链路看着简单但埋点规范、口径对齐都是细活前期投入不要省。5. 微调实战从数据准备到LoRA落地的关键细节5.1 数据准备prompt构造、清洗与标注规范微调能不能成数据质量占七成这是老生常谈。但具体到广告文案这个任务有几个特殊要求。第一历史文案的“正负样本”怎么分。不能只看文案本身好不好要看投放结果。点击率高且转化率达标的文案才是正样本光有创意但转化差的文案反而要控制负采样比例。第二要覆盖足够的场景多样性。同一个城市搬家、拉货、租车、跑腿语气和侧重点完全不同如果数据只有搬家场景模型对其他场景的生成能力会非常弱。第三数据清洗要严格。广告文案里经常有超链接、emoji、特殊符号这些要在预处理阶段统一处理掉否则会污染模型的学习信号。提示词模板方面我们构造了一套统一格式系统角色设定、业务背景、活动信息、用户人群、输出要求。训练时让模型学习这种结构化的输入输出推理时只要填不同的业务内容就能稳定产出一致风格的文案。这套模板要固定下来不能在训练集里一会儿用这种格式一会儿用另一种模型会混乱。5.2 LoRA参数选择与训练避坑参数层面我们用LoRA微调主要原因是训练成本和数据量都有限全参数微调性价比不高。LoRA的几个关键超参数我们是这么定的秩通常取16到32适配当前的7B模型能力够用学习率从1e-4起步用余弦衰减训练轮次控制在3到5轮轮次多了很容易过拟合轮次少了又学不到业务风格。判断过拟合有一个很实用的方法保留一部分纯通用的prompt微调前后分别跑一遍。如果通用prompt的生成质量下降了说明模型开始牺牲通用能力去记训练集也就是过拟合前兆。另一个方法是看loss曲线但实际经验是广告文案这类任务生成效果的盲测往往比loss更敏感。显卡方面7B模型用单张24GB显存的卡做LoRA微调batch size设置2到4梯度累积开到8左右整体是跑得动的。如果显存紧张可以用QLoRA的4比特量化版本效果损失在可接受范围内。训练日志一定要监控尤其关注训练集和验证集的loss是否开始背离这是过拟合的早期信号。5.3 模型评估离线盲测、线上A/B与成本回归评估是我们踩坑最多的环节。一开始只看指标比如BLEU、ROUGE分数结果发现分数再高业务方就是不买账。后来才明白文案生成这类创意任务计算指标只能做粗筛不能做终判。我们最终搭的评估体系分三层第一层是机器规则检查检查违禁词、长度限制、敏感信息等硬性要求。第二层是人工盲测把新旧模型生成的文案混在一起让运营团队打分维度包括语义准确、业务贴合、风格自然、吸引力。第三层是线上A/B测试这是最终裁判。前两层筛选出候选版本线上A/B用真实投放数据说话胜出版本再全量切换。这里提醒一句广告文案的线上效果受季节、竞对、平台投放环境等多重因素影响A/B测试周期不能太短。我们通常跑满7到14天而且要看转化率和成本的联合分布单看点击率容易被带偏。有些版本点击率高但转化率低反而拉高获客成本这种版本宁可不放量。6. 工程化落地常见问题与排查实录6.1 生成内容合规广告法违禁词与幻觉处理生成式内容在广告场景里绕不开的一个问题是合规。大模型对广告法违禁词的敏感性普遍不够很容易生成“全网最低价”“100%有效”“国家级”这类表述。这些词在普通文本里没问题在广告素材里就是高压线。我们的处理是双保险生成之后先过一遍规则引擎把命中违禁词的内容直接打回或替换同时在提示词层面做负向引导明确告诉模型哪些词不能用哪些表述要加“以页面实际展示为准”之类的限定。两个环节配合下来违禁词漏网率基本能控制在极低水平。另一个高频问题是幻觉。模型有时会把活动信息搞错比如把“新用户立减20元”生成成“老用户立减30元”。针对这个问题我们做了活动信息的事实一致性校验在审核层解析生成文案中的活动字段和后台配置做比对不一致就重写。这套校验逻辑不复杂但能把大模型最不擅长的事实准确性问题兜住。记住大模型负责表达事实只能由业务系统兜底。6.2 延迟与成本治理缓存、异步与模型分级上线一段时间后我们面临的最实际挑战是成本和延迟。内容生成调用量上来以后GPU成本随活动数量线性增长。我们的治理思路是三个字分、缓、小。“分”是分级复杂创意用大模型简单素材用轻量模型“缓”是缓存活动素材的生成结果尽量离线跑好线上直接读缓存“小”是蒸馏把高频简单任务沉淀下来的生成模式蒸馏到一个更小的模型上推理成本能降一个量级。延迟方面在线动态拼接场景要求首token延迟尽量低。我们实测下来7B模型用vLLM部署加上合理的prompt长度控制和KV cache复用首token延迟可以压到几百毫秒能满足投放系统的要求。如果还想再快可以考虑把prompt里反复出现的固定部分提前做prefix caching省掉重复计算。延迟优化没有银弹越往后越是看细节但收益是复利的。6.3 线上效果不达预期的排查方向模型上线后效果不达预期是大概率事件。我们的排查经验是先不要急着怀疑模型按下面这个顺序逐一检查数据回流对不对、定向人群对不对、素材投放的频次控制有没有出问题、落地页的承接是否顺畅、最后才是模型生成的文案本身。这个顺序看起来很简单但实际操作中很多人一上来就调模型调了半天发现是数据回流从源头就错了白白浪费几周时间。我们有一次排查出一个很隐蔽的问题同一个活动在App首页和push渠道用了同一批文案push渠道的文案长度超限被截断导致转化率掉了一截。这类问题模型再调优也解决不了因为根因在渠道适配层。所以排查问题时先把链路走一遍再动模型。6.4 后续还可以做什么项目跑到现在我们觉得还有几个方向值得探索。一是B端营销内容的个性化比如针对批发市场商户、连锁门店这类B端用户生成更贴合生意场景的物料。二是把素材效果数据接入模型的在线学习实现更短周期的素材迭代。三是把生成模型和投放策略模型做更深的联动从“生成素材再投放”变成“根据投放目标反向生成素材”。这些方向都需要长期投入但方向上很明确。最后分享一点个人体会。很多人以为大模型加广告就是让模型写文案、出图做完这个项目才发现最难的不是模型生成能力而是怎么把技术能力嵌进一条成熟、复杂、牵一发动全身的广告业务链路里。模型在前面跑后面要有审核、有校准、有反馈、有迭代。与其神话大模型不如把它当作一个能力强但需要严格管理的新同事——它负责产出人负责判断和把关。这个定位想清楚很多技术决策就不会跑偏。
货拉拉大模型营销广告实践：从文案生成到投放闭环
说出来你可能不信我们团队最初接到“大模型营销广告”这个项目时第一反应不是兴奋而是头疼。头疼的原因很简单货拉拉的广告场景跟常见的电商广告差别太大了。同城货运、搬家拉货、新用户补贴、司机端任务这些场景交织在一起产出的素材量以万计但每一批素材的有效生命周期可能就几天。外部API调用成本太高数据出域又有顾虑传统的模板系统又撑不住千变万化的营销活动。做了几个月的实践之后我最大的感触是大模型在营销广告里的价值远不是“AI写文案”这么简单它真正改变的是整个内容生产链路。这篇文章我会从业务痛点、技术选型、场景落地、微调实战、工程排查几个维度把我们在货拉拉营销广告场景里的实践思路和踩过的坑都摊开讲。1. 项目背景与业务痛点拆解1.1 货拉拉营销广告场景的特殊性先聊聊场景本身。货拉拉是货运平台但它跟传统物流公司不太一样用户画像更复杂一边是C端用户搬家、拉货、临时用车另一边是司机端和商户端跑腿、批发市场进货、工厂发货。广告场景不只是App里的banner和弹窗还包括应用商店、信息流、短信push、户外广告、司机端任务卡片等等。这个场景有几个很鲜明的特点直接影响了大模型落地的方向。第一地域属性极强。同城货运里“距离”是核心变量用户在某条街打开App看到的应该是附近能接单的司机。广告文案里写“你的城市也能用”和“全国通用”完全是两种说服力。第二长尾需求非常多。“搬冰箱”“买家具送货”“批发市场拉货”“店面搬迁”这种长尾词传统人工写文案很容易漏掉但大模型对这种长尾语义的理解和表达非常在行。第三促销与补贴节奏极快。平台经常按城市、按人群、按时段切换补贴策略文案、素材、落地页都要跟着变这时候内容生产的吞吐量就变成一个硬指标。传统做法是运营提需求、设计师出图、文案写手出词再一轮一轮审核修改一套素材下来少说两三天。活动多的时候团队被大量基础性生产任务淹没真正花在策略思考上的时间反而很少。我们做这个项目本质上是想把“内容生产”从人力密集型变成“人审模型生产”的模式让人的精力更多放在判断和决策上。1.2 传统广告生产流程的瓶颈传统流程的瓶颈可以归纳成三点这三点也是我们立项时写进需求文档的核心依据。第一是速度。一次大规模拉新活动可能同时需要几十个城市的素材每个城市还要配好几套文案和配图。人工做一轮要两三天等做完市场和竞对的节奏早就变了。第二是风格统一难。不同写手写出来的文案风格差异很大有的偏粗暴直给有的偏文艺品牌调性很难稳定审核成本也不低。第三是定向粗放。传统素材大多是“一个版本打天下”虽然能按城市粗分但很难做到真正的千人千面。这三个瓶颈指向同一个问题平台需要一种能快速生成、批量生成、并且可控性强的内容生产方案。大模型恰好具备这个潜力但“有潜力”和“能用”之间还有很大距离这也是后面章节会详细展开的部分。说白了模型只是发动机要让发动机带动整台车跑起来还得配变速箱、刹车和方向盘。1.3 为什么选择大模型而不用传统NLP有人会问文案生成以前也有模板系统自动填充城市名和优惠金额不就行了为什么一定要上大模型我的回答是模板系统解决的是“确定性内容”的问题它只能生成结构固定的句子比如“今日{城市}搬家优惠立减{金额}元”。但营销广告里大量需求是非确定性的同一个促销信息要在不同渠道、面向不同人群生成不同语气、不同侧重点的表达传统模板要覆盖这些变体只能靠人工枚举成本极高枚举完还容易不自然。大模型解决的是“给定的意思用不同方式表达”的问题它本质上是一个语义层面的生成器而不是字符串拼接器。同时经过微调的模型可以学习到货拉拉风格的具体表达习惯比如司机师傅关心“单量稳不稳”用户关心“价格透明不透明”。这些都是传统规则很难建模的东西。当然大模型也有自己的问题幻觉、成本、延迟、不可控。这正是项目里需要在工程层面逐一解决的部分后面每一章都会提到对应的处理办法。2. 技术选型与整体架构思路2.1 基座模型怎么选中文能力、成本、可控性模型选型是这个项目最早、也最纠结的决策。我们当时主要看开源模型核心原因是数据可控性和成本可控性。广告素材涉及大量业务关键词、城市名称、价格档位如果全部走外部API一是费用随调用量线性增长二是数据出域这件事在合规上就有压力。数据在自己手里模型参数在自己手里迭代和生产才有安全感。当时对比了多个开源基座Qwen系列、Llama系列以及一些垂直中文模型。综合来看我们选了Qwen系列作为主力基座。原因有三中文语料质量高生成的口语化文案更自然对长上下文和工具调用的支持比较完善生态好周边工具链齐全从微调到推理都有成熟方案。这不是说其他模型不行而是这个选择匹配我们的业务场景。这里想强调一点选模型不是看跑分而是看场景。营销文案生成这个任务对模型的“中文口语自然度”和“业务指代理解”要求高而不是对数学推理能力要求高。用那些以代码和逻辑见长的模型来写广告文案效果反而一般。这也是很多团队在选型时容易踩的坑——只看榜单不看任务。榜单上的综合分高不代表它在你的数据分布上表现好。2.2 本地部署与资源评估GPU配置与推理引擎定了基座模型接下来就是部署形态。营销内容生产分为离线批量和在线实时两条链路。离线批量用于大规模的素材预生成对延迟不敏感但吞吐量要求高在线实时用于投放系统中的动态拼接比如根据用户实时位置、活动信息生成个性化文案对延迟有硬要求。我们当时的GPU资源比较紧张不是所有场景都能上满血大模型所以做了分级策略复杂创意生成走微调后的7B/14B模型用vLLM做推理部署配合张量并行提升吞吐简单拼接类任务走轻量模型甚至规则模板。离线生产用异步队列每天凌晨批量跑一轮把生成结果落到缓存线上优先读缓存既省成本又能控延迟。关于推理引擎vLLM是我们用得比较顺手的方案显存管理好、吞吐高部署也简单。如果只是内部实验Ollama也能快速起一个环境但生产环境建议还是用vLLM这类专用推理框架量化、并发、API接口都更可控。GPU配置方面7B模型做推理基本需要16GB以上显存如果加长上下文和并发24GB是更稳妥的起点。上线前一定要做压测用实际业务prompt跑一轮观察最大吞吐和尾延迟再决定上线规模和实例数量。提示不要凭经验估计并发能力。大模型推理的显存占用、并发吞吐和模型配置强相关建议拿真实业务prompt先压测再定容器规格不然上线第一天容易被流量打爆。2.3 整体架构从生成到审核到投放的闭环整个系统架构可以概括成三层闭环内容生产层、审核风控层、投放反馈层。内容生产层负责生成文案、图片素材、落地页要素核心是几个微调模型加一批动态模板。审核风控层是所有生成内容上线前的必经关卡包含广告法违禁词检测、敏感内容识别、事实一致性校验这部分后面会详细讲。投放反馈层负责把生成内容接入广告投放系统实时收集点击率、转化率、成本等指标再把这些指标反馈给生成层形成素材迭代的闭环。三层的关系就像一条流水线模型生产出毛坯素材审核层做质检和修正投放层负责试错和验证验证结果再指导下一轮生产。这套架构的好处是每个环节可以独立迭代模型升级不用等投放系统改造投放策略更新也不用动生成逻辑。我们团队只有十几个人如果做成一个大一统的系统迭代速度根本跟不上业务节奏分层是必然选择。3. 核心落地场景一营销文案与素材的智能化生产3.1 文案生成的业务化改造从通用生成到货拉拉风格文案生成是我们第一个落地、也是收益最明显的场景。最开始我们直接用基座模型试跑生成的文案通顺但“平台感”很强放在货运场景里很突兀一看就不是人能写出来的业务文案。后来才发现问题所在基座模型学的是全网语料它理解的“货运”是物流行业的货运不是同城搬家拉货的货运。解决办法是微调。我们整理了几万条历史优质文案和对应的投放数据构造了“城市人群活动信息文案”的训练对用LoRA微调了一个货运广告文案模型。微调后生成的文案明显有了业务味道比如会用“师傅接单快”“价格透明”“新用户立减”这些真实场景里的表达不再是泛泛的“专业货运服务”。这里分享一个实践细节微调不是让模型变聪明而是让模型“知道自己是干什么的”。训练数据里不只是文案本身还要带上业务上下文让模型学习的是“这个城市、这批用户、这个活动下该说什么”而不是孤立地学造句。数据里如果没有业务上下文模型学到的是语言风格而不是决策逻辑两者差别很大。3.2 多模态素材生成广告图与落地页的尝试文案跑通之后我们开始尝试图片素材的生成。这里说的不只是简单的文生图而是“活动运营图”比如“搬家场景优惠信息品牌元素”的组合图。坦白讲这块难度比文案大很多。大模型生成的图片在美观度上进步很大但有几个业务硬伤。第一文字渲染容易出错广告图里经常要显示“首单立减20元”模型很容易把字写错。第二品牌元素一致性难保证品牌色、logo形状每次生成都有偏移。第三审核风险生成图里可能莫名出现路人、车牌号、其他品牌logo这些都是广告素材审核的红线。我们的方案是分步走先有可控的模板底图再用模型生成特定的场景背景或人物姿势最后把业务文字用程序化渲染的方式叠加回去。简单说大模型负责“创意层”程序负责“确定性层”。这样既保留了生成的多样性又保证了文字和品牌元素的准确性。如果你也想做类似的事建议不要指望模型一步到位输出最终素材而是把流程拆成多个环节每个环节只解决一类问题。3.3 提示词工程与动态模板的配合还有一个容易忽视但很重要的点提示词和动态模板怎么配合。营销活动信息是高频变化的今天北京做“满100减20”明天上海做“满120减30”。如果这些信息都靠写死在提示词里活动一变就要重新生成一批素材成本很高。我们的做法是把活动信息外置通过动态模板拼装上下文让模型只负责生成“表达层”。举个例子提示词模板里会预留变量系统设定你是货运平台的营销文案专家熟悉同城搬家、拉货场景的用户心理。 业务背景今天是{date}城市{city}正在开展活动{activity}。 目标人群{audience}如“近期打开过App但未下单的搬家用户” 生成要求写一条不超过{max_len}字的拉新文案语气{style}重点突出{key_points}不得使用广告违禁词。然后程序去读取当前活动配置动态填充这些变量。这样模型不需要重新微调也能适配不同促销节奏。这个思路也适用于Agent场景等于把“知识”和“表达”做了一个清晰的分层。注意动态模板里的变量一定要做白名单校验。如果这个环节漏了用户输入或活动配置里的内容可能绕过审核层形成提示词注入风险。我们在这方面吃过亏现在是强制校验后再拼模板。4. 核心落地场景二投放策略与AI Agent4.1 人群包与定向策略的智能化生成内容生产只是前半段后半段是投放。广告投放里最核心的动作之一是“定向”决定这批素材投给谁。货拉拉的定向维度很多城市、距离、用户活跃时段、搬家需求信号、历史车型偏好等。以前运营是人肉配置人群包每个活动配几十个包就要忙很久。我们尝试用大模型来做人群包生成的辅助判断比如运营用自然语言描述“我要上海最近30天打开过App但没下单的搬家用户”模型自动转换成结构化的定向条件。这个场景本质上不是生成任务而是“自然语言到结构化规则”的翻译任务。我们一开始直接用基座模型做结构化输出的格式总是不稳定偶尔多一个括号、少一个引号下游系统就报错。后来加了一层约束解码限定模型只能输出预定义的操作符和字段格式错误率就降下来了。这里给所有要做类似事情的朋友一个建议凡是涉及结构化输出的任务一定在输出层做刚性约束不能完全信赖模型自己保证JSON格式解析失败的成本远高于约束实现的成本。4.2 Agent在广告计划管理中的位置再往上一层我们尝试过用Agent框架来做广告计划的日常管理。当时主流的Agent框架我们都调研过包括LangChain这类偏通用编排的以及一些更垂直的广告投放Agent框架。坦白讲完全自主的“无人驾驶”式投放管理现在的技术成熟度还不足以支撑。广告投放涉及真金白银的预算消耗如果Agent在某个环节判断失误损失不可逆。所以我们采用的是一种“人类决策Agent执行”的人机协同模式Agent负责监控投放数据、发现异常比如某个人群包成本飙升、生成调整建议运营人员确认后Agent再去执行调价、暂停计划、换素材等动作。这个模式落地之后运营团队的工作模式从“盯数据”变成了“审建议”效率提升是肉眼可见的。但这里也暴露了一个问题Agent生成建议的可解释性不够。运营看不到完整的推理链路有时不敢直接采纳。所以我们在Agent输出里增加了“决策依据”字段要求Agent给出影响因素和优先级排序让运营能快速判断建议是否合理。没有可解释性的Agent在一个敢花预算的团队里是很难被信任的。4.3 效果数据回流与素材自动迭代闭环最后是一个很容易被忽视的工程点数据回流。模型生成了一批素材投放出去了效果好坏必须回流给模型侧否则整个系统就是“盲人摸象”。我们搭了一套素材标签体系每一批生成素材都带上活动ID、文案模板版本、提示词版本、模型版本、投放渠道等元数据。投放后24小时点击率、转化率、获客成本等指标会回写到素材管理系统里。这个数据回流的价值不只是用来做报表更重要的是指导下一轮生成。比如我们发现某个文案模型在“搬家场景”的点击率明显高于“拉货场景”就会把训练数据里搬家场景的比例调高或者单独微调一个搬家专用版本。通过这种方式素材生产效率是持续迭代的而不是一次性上线就结束了。数据回流链路看着简单但埋点规范、口径对齐都是细活前期投入不要省。5. 微调实战从数据准备到LoRA落地的关键细节5.1 数据准备prompt构造、清洗与标注规范微调能不能成数据质量占七成这是老生常谈。但具体到广告文案这个任务有几个特殊要求。第一历史文案的“正负样本”怎么分。不能只看文案本身好不好要看投放结果。点击率高且转化率达标的文案才是正样本光有创意但转化差的文案反而要控制负采样比例。第二要覆盖足够的场景多样性。同一个城市搬家、拉货、租车、跑腿语气和侧重点完全不同如果数据只有搬家场景模型对其他场景的生成能力会非常弱。第三数据清洗要严格。广告文案里经常有超链接、emoji、特殊符号这些要在预处理阶段统一处理掉否则会污染模型的学习信号。提示词模板方面我们构造了一套统一格式系统角色设定、业务背景、活动信息、用户人群、输出要求。训练时让模型学习这种结构化的输入输出推理时只要填不同的业务内容就能稳定产出一致风格的文案。这套模板要固定下来不能在训练集里一会儿用这种格式一会儿用另一种模型会混乱。5.2 LoRA参数选择与训练避坑参数层面我们用LoRA微调主要原因是训练成本和数据量都有限全参数微调性价比不高。LoRA的几个关键超参数我们是这么定的秩通常取16到32适配当前的7B模型能力够用学习率从1e-4起步用余弦衰减训练轮次控制在3到5轮轮次多了很容易过拟合轮次少了又学不到业务风格。判断过拟合有一个很实用的方法保留一部分纯通用的prompt微调前后分别跑一遍。如果通用prompt的生成质量下降了说明模型开始牺牲通用能力去记训练集也就是过拟合前兆。另一个方法是看loss曲线但实际经验是广告文案这类任务生成效果的盲测往往比loss更敏感。显卡方面7B模型用单张24GB显存的卡做LoRA微调batch size设置2到4梯度累积开到8左右整体是跑得动的。如果显存紧张可以用QLoRA的4比特量化版本效果损失在可接受范围内。训练日志一定要监控尤其关注训练集和验证集的loss是否开始背离这是过拟合的早期信号。5.3 模型评估离线盲测、线上A/B与成本回归评估是我们踩坑最多的环节。一开始只看指标比如BLEU、ROUGE分数结果发现分数再高业务方就是不买账。后来才明白文案生成这类创意任务计算指标只能做粗筛不能做终判。我们最终搭的评估体系分三层第一层是机器规则检查检查违禁词、长度限制、敏感信息等硬性要求。第二层是人工盲测把新旧模型生成的文案混在一起让运营团队打分维度包括语义准确、业务贴合、风格自然、吸引力。第三层是线上A/B测试这是最终裁判。前两层筛选出候选版本线上A/B用真实投放数据说话胜出版本再全量切换。这里提醒一句广告文案的线上效果受季节、竞对、平台投放环境等多重因素影响A/B测试周期不能太短。我们通常跑满7到14天而且要看转化率和成本的联合分布单看点击率容易被带偏。有些版本点击率高但转化率低反而拉高获客成本这种版本宁可不放量。6. 工程化落地常见问题与排查实录6.1 生成内容合规广告法违禁词与幻觉处理生成式内容在广告场景里绕不开的一个问题是合规。大模型对广告法违禁词的敏感性普遍不够很容易生成“全网最低价”“100%有效”“国家级”这类表述。这些词在普通文本里没问题在广告素材里就是高压线。我们的处理是双保险生成之后先过一遍规则引擎把命中违禁词的内容直接打回或替换同时在提示词层面做负向引导明确告诉模型哪些词不能用哪些表述要加“以页面实际展示为准”之类的限定。两个环节配合下来违禁词漏网率基本能控制在极低水平。另一个高频问题是幻觉。模型有时会把活动信息搞错比如把“新用户立减20元”生成成“老用户立减30元”。针对这个问题我们做了活动信息的事实一致性校验在审核层解析生成文案中的活动字段和后台配置做比对不一致就重写。这套校验逻辑不复杂但能把大模型最不擅长的事实准确性问题兜住。记住大模型负责表达事实只能由业务系统兜底。6.2 延迟与成本治理缓存、异步与模型分级上线一段时间后我们面临的最实际挑战是成本和延迟。内容生成调用量上来以后GPU成本随活动数量线性增长。我们的治理思路是三个字分、缓、小。“分”是分级复杂创意用大模型简单素材用轻量模型“缓”是缓存活动素材的生成结果尽量离线跑好线上直接读缓存“小”是蒸馏把高频简单任务沉淀下来的生成模式蒸馏到一个更小的模型上推理成本能降一个量级。延迟方面在线动态拼接场景要求首token延迟尽量低。我们实测下来7B模型用vLLM部署加上合理的prompt长度控制和KV cache复用首token延迟可以压到几百毫秒能满足投放系统的要求。如果还想再快可以考虑把prompt里反复出现的固定部分提前做prefix caching省掉重复计算。延迟优化没有银弹越往后越是看细节但收益是复利的。6.3 线上效果不达预期的排查方向模型上线后效果不达预期是大概率事件。我们的排查经验是先不要急着怀疑模型按下面这个顺序逐一检查数据回流对不对、定向人群对不对、素材投放的频次控制有没有出问题、落地页的承接是否顺畅、最后才是模型生成的文案本身。这个顺序看起来很简单但实际操作中很多人一上来就调模型调了半天发现是数据回流从源头就错了白白浪费几周时间。我们有一次排查出一个很隐蔽的问题同一个活动在App首页和push渠道用了同一批文案push渠道的文案长度超限被截断导致转化率掉了一截。这类问题模型再调优也解决不了因为根因在渠道适配层。所以排查问题时先把链路走一遍再动模型。6.4 后续还可以做什么项目跑到现在我们觉得还有几个方向值得探索。一是B端营销内容的个性化比如针对批发市场商户、连锁门店这类B端用户生成更贴合生意场景的物料。二是把素材效果数据接入模型的在线学习实现更短周期的素材迭代。三是把生成模型和投放策略模型做更深的联动从“生成素材再投放”变成“根据投放目标反向生成素材”。这些方向都需要长期投入但方向上很明确。最后分享一点个人体会。很多人以为大模型加广告就是让模型写文案、出图做完这个项目才发现最难的不是模型生成能力而是怎么把技术能力嵌进一条成熟、复杂、牵一发动全身的广告业务链路里。模型在前面跑后面要有审核、有校准、有反馈、有迭代。与其神话大模型不如把它当作一个能力强但需要严格管理的新同事——它负责产出人负责判断和把关。这个定位想清楚很多技术决策就不会跑偏。
