营销广告通常被认为是离钱最近的业务之一。在货拉拉营销广告同时覆盖C端用户的拉新、留存、促活司机端的招募与激励以及面向企业客户的月结账户场景过去这些场景的文案物料主要靠运营手工产出速度慢、版本少节假日大促经常要临时堆人力。把大模型接进这条链路之后我们的素材产出效率有了非常明显的变化更重要的是运营经验第一次被变成了可迭代的工程资产。这篇文章就围绕大模型在货拉拉营销广告里的落地实践展开讲讲场景拆解、技术选型、微调部署和上线后踩过的坑适合正在做广告、营销、用户增长方向AI应用的同学参考。全文不会刻意回避细节但也会尽量说人话。你会发现真正决定项目成败的往往不是模型本身有多强而是你愿不愿意把流程、数据、兜底规则这些“脏活”做扎实。1. 营销广告场景里的“三高”痛点以及为什么必须上大模型1.1 业务线拆解我们到底在生成什么货拉拉的广告业务不是一个单一的“发广告”动作而是多条业务线并行。C端用户增长侧有新用户首单立减、老用户召回、搬家节和拉货节大促司机端有招募、周排行榜激励、油卡充值提醒企业侧有企业搬家、月结账户和SaaS增值服务。每条业务线都有不同的利益点、目标人群、合规约束和投放渠道。物料形态更杂。同一个活动可能要拆成几十条Push通知、短信、落地页首屏标题、Banner文案、弹窗提醒甚至短视频脚本。文字普遍不长15到50字之间却要求短时间内抓住注意力同时把“立减”“满赠”“限时”这类利益点说清楚。过去这套东西靠运营手工写。正常情况下还能应付一旦遇到大促运营一天要产出上百条组合文案还要针对不同城市、不同车型、不同用户状态做差异化基本就是在赶工。这带来三个很直接的痛点第一人力成本高且产出速度跟不上投放系统消耗素材的速度第二同质化严重同一个利益点换个城市名就是一条新文案用户看多了会疲劳第三合规压力很大广告法对极限词、虚假承诺管得严人工检查容易漏。1.2 为什么用大模型而不是继续堆模板刚接这个项目时团队内部有过一个很实际的争论到底要不要用大模型很多人第一反应是“我们已经有模板系统了加变量就行”。模板系统确实有优势可解释、成本低、不会乱说话。但它解决不了组合爆炸的问题。举个例子用户维度有城市、车型、活跃度、最近一次下单时间活动维度有满减金额、券有效期、适用线路渠道维度有Push、短信、弹窗。把这些维度两两组合模板数量会指数膨胀。就算你维护了5000条模板新活动来的时候还是要人工选模板、填参数、写变体本质还是在靠人。大模型擅长的是“给定信息约束下的自然语言生成”。这正是广告文案的典型场景输入活动参数、用户画像、渠道要求输出一批符合规范且能体现利益点的文案。它不需要维护无限多的模板只要把业务规则写清楚模型就能在约束内自由发挥。同时大模型还能做传统模板做不到的事。比如根据用户行为序列生成“个性化描述”你可以说“这位用户三个月内下过3次搬家单主要用小面车型夜晚完成居多”大模型就能据此生成强调“夜间搬家”“小面车型”的文案而不是所有人看到的都是同一句“快来搬家吧”。我们的选型结论是把大模型定位为内容工厂和辅助决策大脑而不是直接控制预算、出价、人群包的交易系统。交易决策继续由规则和算法系统负责大模型只负责生成、解释、总结和辅助判断。这个边界意识是整个项目后面没翻车的最重要原因。1.3 整体架构设计的“四层闭环”真正动手后我习惯把整个链路拆成四层方便和产品、运营、算法同学对齐。数据层在最底下包括用户画像、订单行为、广告物料库、活动配置、违规词库和运营知识库。它通过ETL和特征平台统一处理大模型和业务系统都从这一层拿数据。模型层是底座包含开源中英文底座模型、经过行业数据微调后的文案模型、用于语义匹配的向量模型、以及用于审核的多模态模型。部署全部在内网环境数据不出平台。再往上是Agent和编排层。这一层负责意图识别、Prompt组装、RAG检索、工具调用和业务API查询。比如运营问“华东区搬家用户召回活动还剩多少预算”模型不直接知道预算而是通过Function Calling去调用预算查询接口拿到实时结果后再组织语言。最上面是应用接入层面向运营平台提供Web端助手面向投放系统提供批量生成接口还提供一套SSE流式输出通道解决前端需要实时打字机体验的问题。这个四层闭环最大的好处是解耦。模型可以随时替换升级业务方不用关心底层是7B还是13B业务数据通过API和知识库接入模型不直接碰数据库避免越权和安全问题。2. 在货拉拉营销广告里落地大模型的四个关键场景2.1 广告文案批量生成从Prompt到JSON第一个落地点也最直接就是广告文案批量生成。我们最开始只选了Push和短信两个渠道做试点。Prompt模板我打磨了很久现在看起来核心就五件事角色、任务、输入参数、输出格式、示例。一个好的业务Prompt必须让模型清楚自己是谁、要干什么、有什么约束、最后交什么格式的结果。下面是一个简化过的Prompt模板具体参数从活动配置系统实时注入你是一名货拉拉运营增长文案专家擅长用简洁、口语化、符合平台语气的风格写作。 请根据以下信息生成5条Push通知文案 - 活动名称搬家节大促 - 目标用户近30天浏览过搬家页面但未下单的用户 - 核心利益点满99元立减18元 - 车辆类型小面、中面 - 投放渠道App Push - 字数限制标题不超过18字正文不超过40字 - 合规要求不得使用“最”“第一”“100%”等极限词不得夸大服务承诺 输出JSON数组每个元素包含 - title标题 - content正文 - cta引导文案 - risk_tags可选字段如果内容涉及价格、时效、服务承诺列出风险标签 请确保每条文案都包含满99元立减18元这个利益点。为什么要求输出JSON而不是纯文本因为下游素材系统、规则引擎要直接消费JSON可以结构化解析避免“模型输出了一堆废话导致系统报错”的问题。如果某条生成结果里利益点金额和活动配置不一致规则引擎能立刻拦截而纯文本就要靠人去肉眼看。在Prompt工程之外我们还会刻意控制模型参数。批量生成阶段temperature通常设置在0.8左右保证同一批文案有足够的多样性到了合规审核阶段temperature会降到0.2让模型做判别时更稳定。另外提一嘴上下文工程。大模型本身并不知道“货拉拉搬家”和“滴滴货运搬家”有什么区别也不清楚上一次大促有没有出过违规。所以我们会把相关业务知识、历史活动总结、常见违规案例放进上下文中让模型有据可依。上下文工程做得好比盲目堆模型参数量有用得多。2.2 人群包语义扩展用Embedding和LLM做人群理解第二个场景偏算法方向人群包的语义理解和扩展。传统人群圈选靠运营手动点选条件比如“近90天下单次数大于等于3次”“车型为小面”“夜间完成订单占比超过50%”。有经验的老运营能圈出好人群但很难把经验结构化。新的运营接手后往往需要很长时间才能上手。我们用大模型做了一件事自动化生成人群圈选规则。具体做法是把用户的最近订单行为、活跃标签、城市属性先整理成一段自然语言描述再让大模型输出结构化的人群规则JSON。比如输入是这样的用户画像描述该用户位于上海近90天下单4次其中3次为搬家订单 车型偏好小面订单完成时段集中在20点到24点最近一次下单在7天前。 请输出一个用于圈选相似人群的规则JSON包含下单次数、时间窗口、 车型偏好、完成时段、城市等条件。模型输出可能是一个结构化的规则再通过一个翻译器转换成实际的人群服务查询条件。这大大降低了运营写规则的门槛。同时我们还加了向量召回通道。把历史高转化用户包的描述文本用Embedding向量化然后做相似人群扩展。这里要特别提醒一句向量相似不等于高转化语义相似的人可能在转化率上差异很大。所以召回之后必须再接一层由业务规则或轻量排序模型组成的过滤否则会扩出一批“长得像但不买单”的人。2.3 多模态素材合规与质量审核广告上线前必须过合规审核这是营销场景里绕不过去的一环。以前审核靠运营同学人工看一条条检查有没有极限词、有没有虚假承诺、图片有没有文字截断。我们后来引入了多模态大模型做素材初审。具体来说做了三件事第一OCR识别图片和Banner上的文字。很多设计师会把利益点做进图片里但这些文字不在文案库里所以传统纯文本审核覆盖不到。OCR识别之后文字统一进审核流。第二判断文案与落地页是否一致。比如Push文案说“立减18元”但落地页首屏根本看不到这个优惠多模态大模型可以通过对比识别出“货不对板”直接打回。第三识别图片风格与品牌调性是否冲突。比如货拉拉的品牌色是橙色调如果素材整体是冷色且没有品牌标识系统会提示风险。这里有个原则必须强调大模型审核只是初审和抽检辅助不能完全替代审核员。尤其涉及价格、时效、服务承诺这些高风险内容必须人工把关。我们采用的是“规则引擎小型分类模型大模型”三级过滤每一级都可以拦截并留下记录方便事后追溯。2.4 对话式运营助手RAG和工具调用的组合拳最后一个场景是给运营同学用的对话式助手。运营经常需要查数据、查活动配置、看历史文案参考如果每次都去BI系统里翻报表效率很低。这个助手背后是RAG加Function Calling的组合。知识库里面放了历次活动复盘、优秀文案案例、物料规范文档和违规案例。运营提问时先把问题做向量检索从知识库里找出相关内容再交给大模型组织答案。如果问题涉及实时数据比如预算、曝光量、点击率大模型不会胡编而是触发工具调用去查数仓API。举个例子运营问“五一搬家节华东区的预算还剩多少Push文案点击率怎么样帮我生成三条召回文案。”助手会先去调用预算接口拿到数字再根据用户画像和活动配置生成文案最后统一回复一段带有数据引用的文字。注意一点工具调用不等于数据库裸奔。运营能查什么数据完全由账号权限决定大模型生成的所有查询语句都要经过权限校验和白名单过滤。我们遇到过模型自作主张拼接SQL的情况差点绕过了普通运营的权限范围。从那之后所有工具调用都做了严格的参数校验凡是和登录账号权限不匹配的查询一律拒绝。3. 从数据准备到微调部署一条可以复现的完整路径3.1 数据准备没有高质量数据一切都是白搭很多人会把重心放在模型微调上但实际上数据准备阶段才最耗时。我们的数据来源主要有三个历史投放消耗过的优质文案、运营手工标注的指令样本、以及从用户反馈和客诉里挖出来的负样本。指令样本的格式长这样{ system: 你是货拉拉运营增长文案专家..., instruction: 生成一条搬家节Push文案目标用户是近30天浏览过搬家页但未下单用户渠道为Push字数不超过40字需包含满99元立减18元。, output: 搬家还挑车小面中面都划算满99立减18抽空看看~, negative: 搬家必选全市最便宜100%准时马上来 }拿到这些样本后清洗工作非常关键。第一去掉历史上有客诉或违规记录的文案不能让模型学到坏例子。第二去掉语义高度重复的文案否则微调后会严重过拟合生成出来的东西千篇一律。第三把所有价格、折扣、时效字段和活动配置表做一次对齐避免训练数据本身就有错误。负样本很重要。我们从客诉和审核记录里挑出过很多“问题文案”比如夸大时效的、乱承诺赔偿的、包含极限词的。把这些负样本混合进训练集模型会更快学会“什么事不能干”。数据量不需要特别大。我们做第一版只用了大概几千条指令样本效果已经可用。核心判断标准是覆盖度看这些样本有没有覆盖不同活动类型、不同受众、不同渠道、不同利益点而不是盲目堆条数。3.2 底座微调实操LoRA与QLoRA的参数怎么调底座模型我们选的是开源中英文模型当时对比了几个7B和13B级别的候选最终综合中文能力、社区生态和部署成本选了Qwen系列作为主要底座。这里直接给一份可以参照的LoRA微调参数表参数建议值说明base_modelQwen2.5-7B / 同级别中文效果好显存压力可控lora_r16~32太小易欠拟合太大会破坏底座能力lora_alpha32~64常见取r的两倍learning_rate1e-4 ~ 2e-4比全参微调偏大但注意loss震荡num_epochs2~3超参数敏感太大会复制历史文案max_seq_len1024~2048广告物料普遍短不需要过长train_batch_size16~32看GPU显存动态调整target_modulesq_proj, v_proj, k_proj, o_projAttention线性层是微调主力微调时我发现一个常见误区以为Loss降得越低越好。实际上我们在第2个epoch附近就停了因为继续训练会让模型开始“背诵”历史文案输出变得过于机械多样性明显下降。微调的目标不是背题而是学会“换一种表达方式讲清楚利益点”。为了保留模型的通用能力我们还在训练集里混入了10%到20%的通用对话数据让模型不要忘记怎么理解复杂指令。量化方面训练时用QLoRA 4bit可以有效降低显存占用部署时则用AWQ或GPTQ做量化推理效果损失很小。3.3 推理部署vLLM、量化与SSE流式输出模型训练出来只是第一步真正要支撑线上批量生成和运营助手,推理部署才是硬功夫。我们内部统一用vLLM来做服务化部署吞吐量和并发能力比原生HuggingFace推理高很多。下面是一个方案对比表给选型的人参考方案吞吐显存占用延迟适用场景vLLM高中高中低多并发生产环境TGI高中中低HuggingFace生态闭源部署llama.cpp中低低中边缘设备或CPU推理Ollama中低低快速原型和单机试用vLLM部署时要重点配置max-model-len避免长上下文场景下显存爆炸。量化模型在较新版本里和PagedAttention兼容得不错但我们每次升级版本都要专门跑一轮线上流量压测防止吞吐回退。应用侧用了SSE流式输出主要面向运营助手和系统生成结果展示场景。大模型生成文案需要几秒如果前端一直在转圈体验很差。SSE可以让用户看到文字逐字出现中间如果发现内容跑偏前端可以随时中止服务端也实现了对该生成请求的取消。伪代码示意一下服务端事件流处理async def generate_text(request): result await llm_engine.generate(request.prompt) async for token in result: # 流式过滤如果检测到违禁词立即终止 if not safety_check(token): yield data: [STOP]\n\n return yield fdata: {token}\n\n实际做的时候还有一层业务缓存。同样活动参数、同样用户画像组合的Prompt如果最近几个小时内已经生成过并审核通过直接返回缓存结果这能省下大量重复计算和GPU成本。3.4 应用编排与A/B实验从生成到投放的完整链路模型服务化之后业务侧需要一套编排流程。我们上线时的链路是这样的运营在活动系统里配置活动参数系统自动组装Prompt调用生成服务生成的JSON结果先过业务规则引擎核对折扣金额、时效、违禁词再由大模型自评或分类模型做质量打分低于阈值直接丢弃进入人工抽检池运营看到的是按风险分排序的候选文案审核通过后写入物料库投放系统自行取用投放数据回流到数据仓库用于评估和后续微调。这套流程最大的价值是让系统出大问题之前有足够多的人工兜底点。大模型生成100条文案系统先自动过滤掉20条明显不合规的剩下80条里再按质量分层运营只需要从最推荐的Top里挑个几条。A/B实验方面我们坚持三个原则同一活动、同一人群、随机分组。实验组用大模型生成的文案对照组用运营手写或模板文案。核心指标可以看点击率和转化率次生指标还盯客诉率和退单率。这里要特别提醒大模型很容易写出“更抓眼球”的标题点击率可能提升但如果落地页承接不住转化率反而下跌。只看点击率你会被假象骗得非常惨。4. 落地过程中的高频问题与排查技巧4.1 幻觉与合规宁可保守不要激进大模型在营销场景里最危险的就是幻觉。明明活动只给10元券它生成“全场免费”明明时效是次日达它写“同城30分钟必达”。这种幻觉一旦被投放出去轻则引发客诉重则带来合规风险。我们的排查结论是不能把“防幻觉”完全寄托在模型身上。模型生成能力越强越需要有更硬的外部约束。具体做了三层防护。第一把核心业务参数作为结构化约束传入Prompt并在生成结果里强制校验。比如活动配置里的“券金额”字段生成系统会抽取结果中的金额字段做一致性比对不一致直接拦截。第二建一个覆盖广告法违禁词和内部敏感词的规则库。规则库不一定要多复杂但必须常更新。刷到“最便宜”“第一品牌”“100%保证”这类词直接不通过。第三给自己留一道“置信门槛”。无论是多模态审核还是质量打分只要模型自评分低于阈值一律进入人工审核。宁可少产出素材也不能放高风险内容出门。4.2 延迟、成本和容量GPU成本怎么算才不心虚模型服务的延迟和成本是每个项目组都会面临的灵魂拷问。我们一开始也遇到过大并发时生成任务排队运营页面转圈圈的问题。排查思路分三步走。第一步看是不是Prompt太长导致推理变慢。广告文案场景其实不需要塞一堆无关上下文把Prompt精简到必要字段延迟可以降下来一大截。第二步看模型规模是不是过大。后来我们把常见的短文案生成任务分流到7B模型只有复杂的多轮生成才动用13B模型整体吞吐改善很明显。第三步上语义缓存。相同或相似的Prompt直接命中缓存不重新计算。成本这块让财务看得明白比什么都重要。内部成本估算公式很简单GPU月成本约为实例数量乘以单价乘以24小时乘以30天再加上存储和带宽成本。然后和过去人工外包文案的成本做对比。但我不建议只看省钱大模型带来的核心价值是响应速度、版本数量和24小时可用性这些都要写进ROI汇报里。容量上我们后来做成了弹性部署。大促期间提前扩容、拉高并发上限平时自动缩容。模型服务是无状态的后端只要接好注册中心和调度策略扩缩容并不复杂。4.3 效果评估与口径统一别让点击率欺骗你效果评估是个大坑。运营团队和算法团队如果口径不统一后面全是指责和扯皮。先说口径。我们内部约定任何实验都要同时看两层指标第一层是广告效率包括曝光量、点击率、点击成本第二层是业务效果包括下单转化率、GMV、客诉率。大模型可能提升第一层指标但只有第二层指标也正向才算真正有效。再说新奇效应。新文案刚上线时用户因为有新鲜感所以点击率高但两周后可能回落。所以我们看数据至少观察两个完整业务周期不能只看前三天。最后说显著性。小样本下点击率差一两个点没有统计意义不要急着全量。先用AA实验测系统本身的波动再用合理的样本量做AB实验确保实验结果能够服众。5. 工程化经验把大模型变成可靠的生产力而不是玩具5.1 边界意识大模型不直接做决策这是整个项目里我最想强调的一点。大模型适合当副驾驶不适合当驾驶员。人群包最终圈谁预算给哪个活动花多少出价是1块还是2块这些强决策问题应该继续交给业务规则和专门算法模型。我们吃过亏。早期有人提议“让大模型根据当前转化情况自动调整出价和预算”听起来很美好但我们最终没有这么做。原因很简单模型如果幻觉一次损失的可能是真金白银而且是难以追溯的。大模型生成的建议可以作为参考但不能直接写进交易系统。如果你也准备做类似项目我建议把“人机闭环”写进产品PRD里而不是只靠技术同学自觉。5.2 工程化的几个习惯版本、灰度、监控、团队大模型应用开发和传统后端开发一样需要工程纪律。Prompt版本化。每改一次Prompt都要像改代码一样提交到仓库记录改动原因和影响评估。否则你会发现项目上线三个月后没人说得清当前线上Prompt是谁在什么情况下改的。数据版本化。每批微调训练数据上线前打tag保留基座模型、训练数据、训练参数之间的对应关系。模型效果回退了可以快速定位是哪一批数据或哪一个参数导致的。灰度机制。所有模型上线都走Shadow模式即先和线上规则并行跑一段时间只记录结果不对外放量。确认质量稳定后再切小流量再到全量。灰度期间一定要接监控。监控项至少包括生成成功率、审核通过率、GPU利用率、P99时延、缓存命中率和客诉率。任何一个指标异常都要能自动报警。团队配置上这个项目不是纯算法项目。我们实际是按照”算法一到两人加工程一到两人加运营对接一人加风控审核兼职“的方式组建的。运营同学负责数据标注和最终审核风控同学帮忙梳理合规边界技术团队负责模型和系统建设。缺少任何一环项目都会变成“算法自嗨”。5.3 后续扩展方向动态创意和智能体项目上线稳定后我们考虑的方向有三个第一是动态创意组合根据用户实时行为自动选择文案模板和图片素材大模型负责生成多个候选再交给排序模块挑选第二是视频脚本生成把现有文字能力往短视频脚本方向延展配合素材库自动生成分镜描述第三是把运营助手升级成更完整的智能体支持多轮对话、自动复盘活动效果、甚至给出下一期活动建议。这些方向本质上还是围绕“生成加审核加评估”的闭环做深做透。我个人在实际操作中的体会是大模型落地营销广告真正的分水岭不是“有没有用到大模型”而是“有没有为它建立完整的流程边界”。项目上线后的第一次全量我半夜收到预警排查了半天发现不是模型出了问题而是活动参数把截止时间配错了导致模型基于错误参数生成了一批“已过期”文案。从那以后所有活动参数接入生成系统前都要做合法性校验生成侧读取活动配置时也加了只读约束任何可疑字段直接拒绝参与Prompt组装。这件事让我更确定我们不需要一个能写所有文案的模型我们需要的是一个能理解边界、可以被审核、坏消息能及时被拦截的写作助手。把这点想清楚大模型在营销广告里的价值会比大多数人想象中更持久。
