大模型赋能营销广告：从文案生成到智能投放的工程实践

最近我们在货拉拉营销广告链路里铺了一批大模型能力从广告文案生成、图片素材制作到投放后的反馈分析都有参与。这篇文章把我在这个项目里踩过的坑、验证过的方案、以及最终跑通的技术路径整理出来。如果你正在做营销中台、广告智能投放或者团队刚准备把大模型接进业务可以拿这份实践当参考。我会尽量把关键决策背后的原因讲清楚而不是只贴一堆参数。货拉拉的广告场景覆盖司机端和用户端两个方向。司机端要讲收入、接单效率、平台规则用户端要讲便宜、准时、拉货省心。两者语气完全不同投放渠道更是分散在信息流、搜索、短视频、线下物料等多处。以前靠运营手工写文案、设计师逐张出图效率低而且很难在不同渠道快速做A/B测试。大模型进来以后我们重点解决三件事用生成模型批量产出多版本创意用多模态能力把文案和配图一次性生成再用模型对投放效果进行归因和迭代。1. 项目背景营销广告场景为什么值得用大模型1.1 业务痛点与需求解析货拉拉本身是做同城货运的营销团队的日常工作里有大量重复且需要快速响应的内容生产。比如大促期间一天要产出上百条不同渠道的广告语还要配合优惠券策略、车型活动、区域差异化运营。以前的做法是运营写几版文案设计出几张图投放同学拿去开计划跑出来以后再人工看数据。这种流程的问题很明显生产速度跟不上投放消耗创意同质化严重很难针对不同人群做个性化表达。我们拆解以后发现广告内容生产其实是一个典型的生成任务输入的是商品利益点、目标人群、渠道规则、品牌语调输出的是文案、图片、视频脚本。大模型天然适合做这件事尤其生成式语言模型和多模态模型本质上就是把“输入约束”转化为“输出内容”。但难点在于怎么让模型输出符合货拉拉的品牌调性而不是看起来像通用AI写出来的那种“重磅上线”“重磅福利”。另一个痛点是经验沉淀。老运营脑子里有一套“什么人群吃什么文案”的打法比如对搬家用户强调“不用跟车便宜透明”对企业客户强调“运力稳定、可开发票”。这些经验散落在表格和微信聊天记录里很难系统化。我们后来用RAG把过往优秀文案、品牌规范、广告法禁用词列表全部做成知识库让大模型每次生成前先检索再组织语言效果比裸用模型稳定很多。1.2 大模型能切入的营销环节从项目梳理来看大模型在营销广告里至少有四个可落地切入点。第一个是广告文案批量生成。这里不只是简单的“写一句话”而是要支持多个维度组合生成渠道朋友圈、抖音、搜索、人群新用户、沉默用户、高频司机、业务线搬家、拉货、企业版。每个组合需要不同的利益点和语气。我们用了一套基于提示词编排的生成管线把维度拆成参数再交给模型。第二个是图片和视频素材生成。用多模态大模型做场景图、背景图、甚至动态视频脚本能极大节省设计工时。尤其货拉拉的素材经常涉及货车、搬运、小区、仓库这类实体场景模型生成后还需要跟真实产品图、司机形象结合所以我们采用的是“文生图图生图人工精修”的混合流程。第三个是投放入口的人群策略。大模型可以从历史投放数据里学习人群特征输出投放建议。这个严格来说不算是内容生成但它是广告系统的一部分。我们让模型基于广告文案自动打标签再结合后端人群包数据帮助投放平台更精准地圈选受众。第四个是效果反馈分析。以往看投放报表需要人工写总结现在让大模型读数据自动生成归因摘要、异常波动提醒和下一步优化建议。这个环节投入产出比最高因为不需要太多生成控制只需要让模型理解表格和指标含义。2. 技术选型与整体方案设计2.1 模型选型开源底座加微调的取舍项目一开始我们就讨论过用闭源API还是开源模型。广告内容属于业务敏感数据而且我们需要频繁调整生成风格频繁调用API的成本和延迟都是问题。最后决定以开源大模型为底座在私有化环境部署关键场景做微调非核心场景直接走提示词。底座选型上我们主要对比了Qwen、Llama、DeepSeek、ChatGLM这几个系列。实际跑下来Qwen系列对中文广告语的理解和生成稳定性最好尤其是处理短文本、口语化表达、品牌词这些场景。Llama中文能力稍微弱一些需要额外做中文词表扩充成本高。所以我们主力用了Qwen2.5系列的7B和14B两个版本轻量任务用7B复杂文案和多轮改写用14B。这里有个重要经验模型不是越大越好。我们的广告文案生成任务属于短文本生成7B模型在微调以后已经能输出不错的效果14B虽然质量更高但推理延迟和显存占用都上了一个量级。后来我们做了分层策略简单模板化文案直接走7B复杂创意文案走14B实测下来整体成本降低了一半可接受的延迟控制在500毫秒以内。2.2 系统工程架构从生成到投放的闭环整体架构不是简单调API而是一个完整的内部服务。我简单说一下分层。最底层是模型推理层用vLLM部署Qwen模型支持流式输出和并发请求。vLLM的PagedAttention机制对显存利用率提升非常明显我们单卡A100能同时服务几十个请求吞吐量比之前用过的一种简单方案高了两倍多。模型部署我们做了两个容器一个跑7B一个跑14B通过服务路由自动分流。中间层是业务逻辑层包含提示词模板管理、知识库检索、敏感词过滤、结果缓存。这里最重要的是提示词模板管理。我们不是把提示词硬编码在代码里而是做成可配置的JSON每个场景对应一个模板模板里可以引用知识库检索结果和业务参数。这样运营同学可以自己调整语气词、利益点顺序不需要每次改代码。上层是业务接入层对接公司内部的广告投放中台、素材管理系统和实验平台。投放计划创建的时候系统自动调用生成服务生成完文案和图片以后推送到人工审核后台。审核通过以后进入A/B测试池。等投放数据回来以后再自动反馈给效果分析模块。整个链路形成了一个闭环而大模型是其中一个核心组件。3. 核心实操从数据处理到模型微调与部署3.1 广告文案生成系统的搭建文案生成是我们第一个上线的能力。上线初期我们直接用通用的提示词让模型扮演“货拉拉营销文案专家”结果生成的文案很多是套话比如“一站式搬家服务省心省力”。这个问题不在于模型差而在于提示词里没有足够的约束。后来我们重新设计了提示词结构分成五个部分角色设定、业务背景、生成要求、参考示例、负面约束。角色设定告诉模型它是什么业务背景说明货拉拉的品牌定位生成要求里有字数范围、必须包含的关键词、目标人群参考示例给它看几组真实优秀文案负面约束明说不能出现哪些夸张词和禁用词。一个典型的提示词模板长这样{ role: 你是一位熟悉同城货运行业的资深广告文案编辑, background: 货拉拉为用户提供面包车、小货车等运输服务核心卖点是便宜、准时、透明计价, task: 针对搬家用户生成一条30字以内的朋友圈广告文案, constraints: 必须包含搬家体现价格优势语气轻松不使用最、第一等极限词, examples: 参考今天搬家没被坑比打车还便宜货拉拉师傅准时到楼下 }这套模板上线后文案合格率从30%提升到了70%。但依然有部分输出太死板所以后来我们加入了知识库检索。把历史投放表现最好的1000条文案按场景拆开生成时先找到最相似的五条作为参考示例放进提示词里。这个做法本质上是RAG虽然看起来简单但对文案自然度的提升非常明显。为了进一步提高效果我们还做了微调。微调数据来自两部分一是历史库里的优质文案二是运营人工修正过的生成结果。我们按渠道和业务线分别整理了几千条数据使用LoRA方式微调Qwen2.5-7B。LoRA的优势是训练参数少我们只用了两张A100跑了大概三小时就完成了一个领域的微调模型文件才几百MB。微调以后风格稳定性好了很多不再频繁出现“共同富裕”“阖家欢乐”这类的通用祝福词。3.2 多模态素材生成与广告审核图片素材这块我们最初想直接用文生图模型生成整张海报后来发现可控性太差。比如模型生成的货车经常贴地飞行车身上的字也是乱写的直接投放会砸招牌。我们的方案是把文生图用于背景合成比如生成“上海某小区门口搬家场景”再让后端合成引擎把真实货拉拉车辆和品牌标识贴进去。这里用到的多模态大模型既包括图像生成模型也包括图像理解模型。生成场景图之后会用图像理解模型做一轮自动审核检测有没有车牌号、人脸、违规标语。注意广告素材涉及真实人物和车辆合规要求很高自动审核人工复核的流程必须保留不能为了效率完全依赖模型判断。另外我们还训练了一个小模型做品牌一致性打分。输入生成图片输出一个0到1的分数低于阈值的图片直接退回重新生成。这种打分模型的训练数据来自历史素材库人工标注过“是/否符合品牌规范”效果比单纯用提示词约束图片生成模型可靠得多。3.3 大模型微调实战与部署优化微调这块我多说一点技术细节。我们用的底座是Qwen2.5-7B-Instruct微调框架是LLaMA-Factory。数据格式统一成对话式历史文案作为人类回答前面拼接一个系统提示词描述场景和约束。训练轮数控制在三到四个epoch学习率设置在2e-4左右LoRA rank设16alpha设32。经验是轮数太多容易过拟合导致输出全是训练集里的句子。训练完成后我们把LoRA权重合并到基础模型导出成HuggingFace格式再用vLLM部署。合并后的模型大小和基础模型差不多但显存占用还要考虑上下文长度。广告文案任务上下文比较短我们控制在2048 token以内这样7B模型用一张A10也跑得动性价比很高。部署的时候有两个优化点。一个是动态批处理vLLM默认支持连续批处理但需要把max_num_seqs调大否则并发一高就会排队。我们把max_num_seqs从32调到64吞吐量提升明显。另一个是preemption策略长上下文请求偶尔触发显存不足我们把gpu_memory_utilization调成0.9并且启用swap空间牺牲一点速度换稳定性。3.4 提示词工程与上下文管理提示词工程在这类业务里比想象中重要得多。很多人觉得大模型能力强随便写几个词就行实践下来不是这样。广告文案对措辞极其敏感差一个字可能就会触碰广告法禁用词或者语气跟品牌不符。我们做了几层提示词优化。第一层是词汇级限制把禁用词列表挂在每个请求后面让模型在生成前先“过一遍脑子”。第二层是句式偏好通过示例指导模型使用“越短越有力”的句式。第三层是上下文管理RAG检索到的内容会放在知识块里并明确告诉模型哪些是必须使用的卖点哪些是可以忽略的背景。再说说流式输出。营销后台的体验要求看到生成过程所以接口是SSE流式。但流式输出有一个麻烦就是敏感词过滤没法逐字判断。我们的做法是前端展示流式内容最终生成结束以后后台再跑一遍完整过滤如果命中禁用词整条文案标记为待人工修改而不是直接丢弃。这样既保证交互体验也不让风险内容漏出去。4. 踩坑实录与问题排查4.1 内容质量与效果波动问题第一个典型的坑是模型输出效果不稳定。同样的提示词早上生成和下午生成的文案措辞会有差异哪怕温度参数设成0也一样。这个问题的根源在于采样随机性和后端工程的并发状态。我们最终把生成结果的候选数设成三个由评分模型选一个最优输出同时配置了固定随机种子。虽然不能保证100%一致但线上可接受。第二个坑是过度优化。我们曾经把温度调得很低让输出更加稳定结果文案变得干巴巴全是模板句。后来调整为温度0.7top_p 0.9既保留一定的多样性又不至于跑偏。这个参数我们测了很多组最终定下来不同任务可能不一样但大方向是这样。第三个坑是数据回流。一开始我们只做生成不做反馈闭环模型根本不知道哪条文案最后转化率高。后来我们在生成结果里带上了生成时的参数和业务ID投放结束以后把点击率、转化率回写到文案条目上。每个月用这些带效果标签的数据重新微调一次模型才真正越用越准。4.2 推理性能与成本控制性能方面最大的坑是并发突刺。大促期间广告系统会一次性预生成几百条文案导致推理服务瞬间被打满。我们做了三层防护一是整体批量任务走异步队列不是同步请求二是模型服务单独限流超过阈值直接报错让上游重试三是主动缓存如果同一个业务参数组合已经有生成结果就直接从缓存里返回不再调用模型。成本方面建议不要把大模型用在所有生成任务上。我们做了一个很简单的判断逻辑纯模板套路的文案用规则引擎加随机词汇组合就能生成成本几乎是零只有需要创意表达、风格把控、语义泛化的任务才走大模型。这个判断逻辑上线后大模型调用量下降了40%但文案整体质量没有明显下降。GPU成本也要细算。我们最初租了好多卡后来发现大部分时间利用率不到10%。现在改成动态扩缩容非高峰时段只保留两个节点高峰时段自动扩到八个节点。这个在Kubernetes里配一下HPA就行。注意要用模型自身的吞吐指标来做扩缩容依据不要只看CPU因为大模型推理瓶颈在显存和计算CPU高不代表卡忙。4.3 数据安全与广告合规广告营销直接对外内容合规是底线。我们总结了几条硬规矩。第一所有生成内容必须经过机审和人审两道关。机审用规则匹配和大模型判别结合规则负责禁用词、商标词、极限词大模型负责捕捉语义风险比如文案里虽然没有禁用词但整体暗示“必赚”“保底”。第二素材里涉及真实人物、地址、车牌要打码或替换不能直接用真实场景照进广告。第三用户数据不能直接拼进提示词比如不能用“李先生的手机号是138xxxx”这种内容作为生成上下文否则会造成隐私泄露。我们的做法是把用户信息脱敏成占位符比如“用户A所在城市是上海”模型只感知到业务变量不需要知道真实个人信息。在合规这块我们专门整理了一个动态更新的禁用词库除了广告法明确禁止的“最”“第一”“国家级”以及相关变体还包括货拉拉业务里不适合出现的金融暗示词。词库放在配置中心里每次生成前自动拉取不写死在模型权重里这样改动词库不需要重新部署模型非常灵活。5. 后续扩展可能性这套体系跑通以后我们发现它其实不止能用在广告内容生产上。货拉拉还有大量面向司机的运营通知、App端弹窗文案、甚至客服话术本质上都是同一类生成任务只要把知识库替换成对应业务域的内容微调一下语法风格就能快速复制。我个人在实际操作中的体会是大模型在营销广告落地的关键不是模型本身多强而是业务上下文够不够厚。你给模型多少好数据、多少清晰的约束它就还给多少靠谱的输出。盲目上大带宽、大算力不如先把提示词和知识库做扎实。后面如果继续做我计划把多轮改写能力加进去让模型能根据历史投放数据自动优化一句差评文案而不是每次都从零生成。