先聊一个很朴素的观察货拉拉这盘生意营销广告从来不是“拉新一个算一个”的简单活。用户端、司机端、B端商户每个群体都有差异极大的诉求再加上同城货运、搬家、企业物流这些细分场景广告物料和人群策略的复杂度远超大多数人想象。项目组最早尝试用大模型说白了就是被两个问题逼的一是素材生产速度跟不上投放消耗二是人群圈选和策略解释的粒度不够。于是我们开始把大模型往营销广告的链路上放从文案生成、人群圈选、素材生产到效果评估一点点抠细节。这篇就当是这段时间的实践记录适合正在做营销增长、广告平台或者AIGC应用的同学参考内容以技术选型、落地实操和踩坑实录为主不写虚的。1. 先捋一下货拉拉的营销广告为什么要碰大模型1.1 业务规模带来的物料压力和小流量困局货拉拉的营销侧有几个特点投放渠道多、触达场景杂、人群分层细。开屏、Push、短信、小程序弹窗、社群话术、线索投放每一个渠道都需要大量文案和素材。过去靠运营和外包写手撑一个活动下来几十上百条物料是常态遇到大促或区域投放量级直接翻倍。更麻烦的是很多物料其实只在小范围投放比如某个城市针对“搬家用户”的召回Push可能只有几万条展示量但依然需要专属文案和对应人群包。这种小流量场景人工写文案不仅贵而且排期慢等物料上线活动热度都过去了。大模型在这里解决的不是“写得更好”的问题而是“批量产出合格内容”的问题。先把量补上再谈质。另一个卡点是人群圈选。货拉拉的营销数据维度很杂用户叫过几次货、上次下单什么时候、浏览过哪个品类的服务、司机侧有没有接单意愿、企业客户有没有开票需求……传统做法是梳理规则标签运营同学用RFM模型或者行为标签做圈选。规则多了以后标签体系越来越重维护成本也高。而且运营同学脑子里想的往往是一句自然语言“最近一个月叫过搬家但没下单、且收藏过搬家攻略的人”到了系统里要翻译成一串标签组合。大模型能直接把这个翻译过程接过去把自然语言变成圈选条件这是让我觉得很有价值的切入点。1.2 大模型在营销链路里的四个落点我们后来把大模型的落点收敛成四个方向全部围绕广告投放闭环来做。第一是文案生成面向开屏、Push、短信、Banner等广告物料用一个通用的生成服务来支撑不同渠道只要保证输出协议一致就能接入。第二是人群圈选与策略解释把自然语言查询变成标签条件或规则引擎的输入同时让AI生成人群包的命名和说明方便复盘。第三是素材生产文案之外还可以联动文生图做 banner底图、活动页头图甚至给司机端定向物料做不同风格适配。第四是数据洞察和复盘让大模型读投放报表摘要自动生成周报、异常归因和优化建议。这四个方向不是一次性做完的而是一个阶段一个阶段推的。我们从文案生成开始因为它门槛最低、见效最快后续才逐步扩展。2. 方案选型底座模型、微调方式、部署形态怎么定2.1 底座模型选型开源为主API为辅选型是项目里最纠结的一步。商用API的效果确实好稳定性和速度都省心但营销广告的场景牵扯到用户画像、订单数据、优惠策略很多数据不能出内网。所以我当时的判断是核心链路以开源模型为主商用API只用来做尝试性对比和兜底。开源模型里我们重点看三个维度中文能力、指令跟随能力和社区活跃度。国内团队做得比较早的Qwen系列基本是首选比如Qwen2.5-7B/Qwen2.5-14B中文语料底子好指令跟随在7B这个规模也算能打。另一个选择是ChatGLM系列对话生成自然度不错部署也方便。如果GPU资源更紧张可以看更小参数的模型比如Qwen2.5-3B但广告文案质量会明显下滑尤其是需要处理双端人群差异化表达时。我们内部给底座模型定的标准是“同样一段Prompt至少要有80%的输出能直接过审核”达不到就换模型或者上微调。选型还要考虑生态配套。Qwen系列的量化版本很全AWQ、GPTQ、GGUF格式都有现成产物vLLM、Ollama这些推理框架都支持得好这对后续上线是实打实的帮助。如果选了一个社区热度低的模型遇到推理框架兼容问题都要自己改代码太伤了。2.2 微调 or Prompt不是所有场景都要微调很多团队一上来就想着微调我反而建议先做Prompt工程和上下文工程把投入产出算清楚。文案生成这个场景我们一开始用的是纯Prompt把产品信息、优惠力度、用户画像、平台调性都写进上下文。运营反馈说效果能到“70分水平”这个分数对批量生产已经够了。真正需要微调的情况是当你在特定风格上反复翻车比如写司机招募文案时总爱用“多劳多得”这类老话Prompt怎么调都改不过来这时候才值得用几十条人工精修样本做轻量微调。我们实际采用的方案是LoRA和QLoRA。用Qwen2.5-7B作为基座LoRA rank设成32alpha设成64训练数据三百到五百条每条是“业务指令上下文标准答案”的格式。QLoRA的4-bit量化能显著降低显存门槛一张24G显存的卡就能跑7B模型的微调。训练轮数一般控制在3到5轮多了容易过拟合生成的文案会开始“复读”。如果目标是只做风格迁移不改变模型的基础能力LoRA效果非常够用。全参数微调不是不能碰但需要更大数据和算力营销文案这种高频迭代的场景没有必要。3. 营销链路平台架构从需求到上线的工程骨架3.1 整体流程与模块划分营销广告系统接入大模型之后流程不是简单的“前端传一句话模型吐一段文案”我们拆成了五个模块请求接入层、策略编排层、模型推理层、内容审核层和效果回流层。请求接入层负责统一接收各个业务方的调用比如活动后台要生成Push文案、人群平台要解析圈选指令。输入协议统一成JSON包含业务类型、素材规格、用户特征、投放渠道、预期语气。策略编排层是一个中间层负责把业务请求组装成模型真正需要的Prompt同时决定走哪个模型、用不用缓存、要不要带检索结果。模型推理层是核心负责加载模型、执行推理、流式返回结果。内容审核层对所有生成结果做违规词、广告法违禁词、敏感信息检查。效果回流层则是把每次生成的结果、业务方的人工修改、投放后的转化数据都记录下来形成闭环。这个架构最大的好处是可替换。模型推理层被隔离成一个标准接口今天用7B模型明天想试试14B只需换一个模型加载配置。Prompt模板的调整也只发生在策略编排层不会影响下游结构。3.2 数据安全与内容审核不能省营销广告场景里数据安全和合规是不可回避的。用户画像数据不能出域所以模型服务必须部署在内网或私有云环境。我们做了一整套脱敏逻辑进入Prompt之前把手机号、地址等强标识字段替换成占位符模型输出里如果出现这些占位符就用真实值回填。生成的素材还要再走一轮内容审核首先是规则引擎检查广告法违禁词和平台敏感词然后是模型复核让大模型判断文案是否包含绝对化用语、虚假承诺、夸大表述最后人工抽检。这不是走形式广告文案一旦涉及“最便宜”“百分百成功”这类表述轻则被平台处罚重则影响品牌信任必须掐死。4. 四个核心场景的落地实操4.1 广告文案生成两步走模板先行再上微调文案生成是我们最先落地的场景这里细说一下实操过程。第一步是搭Prompt模板第二步是攒样本决定要不要微调。Prompt模板的结构很关键。我踩过不少坑最初只是简单写“请为货拉拉写一条开屏广告文案”输出质量极不稳定。后来总结出一套相对稳定的结构。你是一名货拉拉营销文案专家请根据以下信息生成一条开屏广告文案。 ## 用户特征 - 行为近30天浏览搬家服务3次以上未下过单 - 意向新用户首单优惠敏感偏好“免费上门估价” ## 核心卖点 - 新用户首单立减50元免费上门估价 ## 平台调性 - 实用、接地气、不浮夸 ## 文案要求 - 正标题不超过15个字副标题不超过18个字 - 必须包含“首单立减50”和“免上门估价” - 不得使用“最”“第一”“100%”等绝对化用语 - 输出格式为JSON{title: 正标题, subtitle: 副标题, risk_check: 合规自检}这个模板把一个营销任务拆成了用户特征、卖点、调性、约束、输出格式五个区块模型理解起来明确得多。尤其是risk_check字段让模型在生成时顺便自检一遍虽然不能完全替代审核但能显著降低违禁词出现的概率算是一个很讨巧的手段。输出格式强制为JSON看起来只是技术细节但它让业务方接入成本大降。运营同学不必再对着纯文本手动整理字段模板渲染系统可以直接读取JSON里的title和subtitle。为了保证格式稳定推理参数的温度需要控制在0.3到0.7之间太高会输出乱格式太低又容易文案风格固化。我们在服务里默认温度0.5重试时再尝试0.3。微调的触发时机也简单如果同一类文案连续两周的人工修改率超过40%说明Prompt已经带不动了就把这批数据整理成训练样本做一次LoRA微调。我们第一次微调就是针对“司机招募文案”这个子场景样本量只有四百多条但上线之后修改率直接从38%降到21%效果非常直观。4.2 人群圈选用大模型把自然语言变成圈选条件人群圈选是更有想象力的场景。货拉拉的标签体系数量很多运营同学要圈一个人群得在后台一层一层翻标签效率很低。我们用大模型做了个“自然语言圈选”的入口。输入示例是“最近30天叫过搬家但没下单、且收藏过搬家攻略的高潜用户”。模型输出的是一段可执行的条件规则比如last_order_time 30天 AND service_type 搬家 AND order_count 0 AND favorite_content CONTAINS 搬家攻略为了让模型输出稳定我们把标签字典喂进上下文也就是把系统中所有标签名、标签值、含义说明做成一份字典让模型基于字典做翻译。这里有个细节标签字典不能太长标签一多Prompt会膨胀影响生成速度。我们做了两个缓解方案第一是标签按一级分类拆开先让模型判断输入涉及哪几个分类再去对应分类的字典里翻译第二是引入向量检索把输入语句和标签描述都embedding化只检索Top 20相关标签再送入Prompt。后者效果好很多相当于给模型配了一个动态标签库。最终这套实现最关键的收益不只是“翻译准确”而是人终于可以用业务语言对话式圈选。运营同学不需要记标签ID也不需要在几十个标签里翻找系统还能自动给生成人群包命名比如“近期搬家意向但未转化用户”。复盘时看一眼人群名就知道当初圈选逻辑不用再翻历史配置。4.3 素材批量生产文生图与多模态的实操边界文案问题解决后素材生产是下一步。货拉拉的活动物料里banner底图和活动头图需求很大但很多物料只需要简单的背景图加文字。我们用文生图模型做了批量生成底图的实验。实操中文生图最大的问题是不稳定。同一个Prompt生成两张图构图和风格差异可能很大。我们做了三层控制第一把Prompt模板化固定描述背景色、主体元素、构图位置、字体预留区域第二对生成图统一做后处理用目标尺寸裁切和调色第三把生成图作为底图文案由渲染层叠加避免因为文生图的文字渲染能力弱导致广告字变乱码。这里要给个很实际的建议别指望文生图一步到位生成带正确文字的成图。现在的开源文生图模型写中文广告语经常出错更稳的做法是“图归图字归字”。底图生成后走一遍合规检测检查是否有不合适的元素人工抽检通过后直接进入物料池。货拉拉这种本地生活服务场景素材的真实感比炫酷更重要用户看到一张干净、信息清晰的banner点击率比看着高大上但信息模糊的图好得多。多模态的边界在于成本和速度。文生图模型部署成本并不低在并发量上来后GPU消耗比文生文高一个量级。我们的策略是让文生图走专门的GPU队列和文案服务隔离避免相互影响。线上活动高峰期只对高频渠道开放图片生成低频渠道复用素材池里的历史底图。4.4 效果评估与数据回流AI生成了不等于AI有效很多团队把大模型接进去之后很容易掉进“生成即完成”的误区。实际上文案生成只是起点关键要看投放数据。离线评估阶段我们用了三类指标。第一是基础质量指标包含BLEU、ROUGE这些文本相似度指标用于监控输出偏差但不能迷信它们因为广告文案的好坏和字面相似度相关性很弱。第二是模型评估直接用一个大模型作为裁判LLM-as-judge对候选文案从“信息完整度、卖点突出度、平台调性契合度、合规风险”四个维度打分。这样可以批量筛选把明显不合格的物料直接拦掉人工只需要看Top级别的候选。第三是人工抽样每周从线上投放的AI物料中随机抽取人工打标作为最终质量准绳。在线评估是真正的试金石。我们对同一条广告设置AI文案和人工文案两个版本跑AB实验看CTR和CVR的差异。跑下来一个反直觉的经验是AI文案在大促场景下因为信息密度更高、卖点覆盖更全点击率往往能和人工文案持平甚至略高但在品牌向、情感向的文案上AI容易被人工文案甩开。这个发现很重要它直接决定了我们不同场景用不用AI、用多少比例。数据回流还要做得再细一点。运营同学如果修改了AI生成的文案这份修改记录本身就是宝贵的训练样本。我们把A/B测试的结果和人工修改记录汇总成数据集定期补充微调样本。这样每次优化都和真实业务反馈挂钩不会出现模型越改越偏的情况。5. 部署与推理加速从实验到线上5.1 用vLLM做服务化部署显存和并发估算方案落地后部署是第一道坎。我们早期用HuggingFace的transformers直接部署发现并发一上来就原地爆炸吞吐太低每个请求还得排队等前一个推理完成。后来切到vLLM情况立刻改善。vLLM的核心优势在于PagedAttention和Continuous Batching前者能显著降低显存碎片后者可以把多个请求的动态Batch合并起来吞吐量提升非常明显。部署形态上我们用FastAPI包一层HTTP服务模型推理调用vLLM暴露的OpenAI兼容接口。外部业务方完全感知不到背后是开源模型他们只需要按Chat Completions格式调用即可。流式输出用SSE做客户端拿到第一个Token的时间大幅缩短体感上比等待完整响应好很多。显存估算有一个简单的经验公式。7B模型fp16权重大约14GB4-bit量化后大约5GB左右但推理时KVCache才是容易被忽略的大头。并发越高KVCache占用越大。我们以单卡A100 80G为例7B模型AWQ量化后单请求预留8GB到10GB的显存空间大概能并发8到10路。这只是静态估算实际还要靠压测。我们当时做了个简单压测脚本模拟不同并发下请求的TTFT首Token延迟和TPOT后续Token延迟最后把最大并发压到一个能让P95延迟控制在2秒以内的数值。营销广告场景不是对话助手用户不需要1秒以内出结果稳定比极致的快更重要。如果GPU资源紧张Ollama也能用它部署简单、支持GGUF量化适合原型验证和小并发场景。但一旦进入生产且并发上到几十路还是优先vLLM。我们还踩过一个小坑不同量化格式在同一框架下的兼容性参差不齐比如AWQ在vLLM下支持很好但某些小众量化格式需要改代码。所以选型时就要确认推理框架的官方支持列表别等上线才发现加载不起来。5.2 GPU成本与压测的几条经验成本压力是老板一定会问的问题。我们的办法是把成本拆成研发成本和线上推理成本。研发阶段的微调QLoRA让7B模型训练只需要一张24G显存的卡一天内能跑完几百条样本的多轮训练这部分成本很低。线上推理成本才是大头。为了控制它先做缓存相同业务类型、相同Prompt模板、相同参数的请求结果直接走Redis缓存文案类请求的重复率不低这个策略能省不少算力。再做请求聚合有些渠道一次要生成多条文案我们支持单次请求批量生成减少HTTP开销和排队次数。模型规模上7B是成本和质量的平衡点如果某个子场景的文案难度确实低可以单独部署一个3B模型做降级链路高峰期直接把部分流量切到小模型保住整体可用性。压测时要特别注意长尾请求。广告文案的输入差异很大有些Prompt特别长包含大量标签字典或用户特征这会显著影响KVCache的分配。我们曾遇到压测时平均延迟正常但偶尔出现一个超大上下文请求直接把整批并发拖垮。给单请求的max_token和上下文长度设置上限很重要超过上限的请求统一走降级逻辑回退到最短模板。6. 踩坑实录幻觉、延迟、效果波动6.1 幻觉问题广告文案里写错价格和时限这是最容易出事的地方。某次活动我们让模型生成Push文案业务方明明传的是“首单立减50元”模型却在文案里写了“全场半价”幸好审核层用关键词匹配拦住了否则上线就是事故。这类问题的根源在于模型会把训练时见过的知识带进来而不完全遵循上下文中的事实字段。我们的解法是把事实信息结构化用变量占位比如“首单立减{var_discount}元”而不是让模型从长文本里自己抽取。同时模板里很明确地写明“所有优惠信息必须从‘核心卖点’字段中提取禁止推测”。再配合risk_check字段让模型自检双保险。如果生成结果与模板中的约束不一致系统直接拒收重新生成。这样做一次生成成本变高但大大降低了审核压力。广告场景的合规底线远远比多花一点算力更重要。6.2 延迟、并发和输出格式的坑线上系统的坑千奇百怪。印象最深的是一次全链路压测发现大部分时间不是在模型推理而是浪费在Python序列化和网络传输上。JSON格式化大字段时序列化耗时明显后来全部改成使用orjson并压缩大字段名称延迟直接下降不少。另一个坑是SSE流式输出时的客户端断连业务方没有正确消费流式响应服务端却还在继续生成Token白白浪费算力。我们在接入层做了一份标准SDK统一处理流式消费和超时中断。输出格式问题是我们推的最细的一件事。模型虽然被要求输出JSON但在低温度下偶尔也会输出Markdown块包裹的JSON或者多余注释。解析层必须做容错先用正则提取花括号部分再用JSON解析器处理如果解析失败就重新生成一次。重试逻辑不能无限循环最多两次超过就返回降级文案模板。这套兜底机制上线后文案服务的可用性从97.5%提升到99.2%。6.3 效果波动与回归体系大模型上线后另一个头疼的问题是效果不稳定。同一条Prompt模型更新版本后输出可能大变线上CTR说掉就掉。我们的应对是建立回归数据集每周跑一次测评对比新候选模型和线上模型的离线指标。版本上线前用小流量灰度跑48小时AB重点看CTR、转化率和人工修改率这三个指标。改动模型参数或Prompt模板必须走灰度不允许直接全量替换。这里还有一个经验Prompt模板不能频繁改。每次改模板线上效果都要重新学习一波。我们内部做了一个模板版本管理所有Prompt变更都像代码一样走评审记录变更原因和预期影响。一个月内对同一个场景的Prompt改动控制在两次以内效果波动会小得多。6.4 最后的实操心得做个简单总结心态上的体会。大模型落地营销广告本质是在“内容生产”和“策略翻译”两个环节做人力替代。不要一上来就追求全自动化先把生成能力用起来用人工审核兜底再把反馈数据喂回模型逐步扩大自动化比例。你会在极端情况里遇到幻觉、延迟、成本、效果波动的轮番纠缠但每一项都有系统性的解法。现在回头看当时最该早做的事情其实是把效果评估和数据回流做好否则后面一切的优化都缺方向。最后再分享一个小技巧如果你也正在做类似的事情可以先找一个月内被人工修改最多的五类文案把它们拿到大模型生成一版人工对照修改把修改日志保存下来这就是最优质的微调数据集。不需要去外面找数据你的运营同学每天都在标注。把这些数据用起来比换更大的模型有用得多。