做营销投放的同学应该都有同感广告素材和文案的生产速度永远赶不上预算消耗的速度。我在货拉拉负责营销技术相关的工作前两年最让我们头疼的事情就是——投放量越来越大但文案产能、审核效率和试错成本全都卡在那里一句广告语从构思到过审快则两三天慢则一周等上线了市场热点都凉了。所以我们从去年开始系统性尝试把大模型接进营销链路从文案生成、用户定向、素材初筛到投放复盘都做了落地。这篇文章不聊概念就把我们实际跑通的东西拆开讲模型怎么选、为什么要私有化部署、提示词和上下文工程怎么搭、LoRA 微调的真实记录、效果评估体系的设计以及踩过的那些坑。如果你的团队也在做广告系统、营销中台或者增长方向的技术这篇应该能帮你少走点弯路。1. 货拉拉营销业务的三个核心瓶颈以及大模型的切入点1.1 三个绕不开的现实问题第一个是创意产能问题。货拉拉的业务覆盖面很广同城货运、搬家、企业用车还有司机端的招募和运营。每一个品类在投放时都需要不同卖点、不同人群、不同场景的文案组合。过去我们的做法是运营同学写一批通用文案再由投放同学手动改造成不同版本。这个流程在素材量小时没问题但一旦开启多渠道多人群投放文案数量是成百上千的人力根本撑不住最后只能复用老文案导致广告疲劳——同一个用户看到同一句文案五次十次点击率必然跳水。第二个是人群定向的粒度问题。传统的定向依赖规则和结构化标签比如一周内看过搬家页面但没有下单的用户。但用户真实需求往往藏在非结构化信息里比如搜索词三米二的厢货多少钱一趟、和客服聊天里说我周五要搬家但是东西不多。这些信号蕴含很强的下单意图但规则系统很难抽取成可用的定向条件。第三个是素材效果迭代的效率问题。一个素材投出去效果好不好为什么好往往要等几天数据回传后人工分析。等到发现文案方向不对预算已经浪费了一部分。我们一直想要一个上线前就能预估质量的机制而不是完全靠上线后试错。1.2 大模型在广告链路里的四个落地位置想清楚问题后我们把大模型的能力收敛到了四个具体位置而不是一上来就搞一个什么都做的营销大脑文案生成面向不同人群体、场景、渠道产出行销文案包括广告标题、落地页文案、推送消息、短信话术。意图理解从搜索词、浏览行为、客服对话等文本里抽取用户的场景和意图反哺广告定向和推荐策略。素材初筛对人工或模型生成的文案提前做质量评分、合规预检筛掉明显不合格的素材再进入投放池。投放复盘投放周报、效果归因、行业竞品素材分析的自动生成减少运营同学的重复劳动。这四个方向听起来都不复杂但真正做起来每一步都有坑。下面按我们落地的时间顺序展开讲。2. 模型选型与私有化部署一家物流公司不得不算的账2.1 为什么最后选了私有化部署项目刚立项的时候团队里争论过一个问题直接用大厂 API 还是自己部署开源模型。当时公有云 API 的便利性确实诱人但我们评估之后还是选择了私有化部署理由有三条第一是数据合规。营销系统里会涉及用户手机号、行为轨迹、交易记录、优惠券核销等敏感数据。如果把这些数据拼进 prompt 发给外部 API哪怕做了脱敏合规心里也是没底的。广告法、个人信息保护相关的要求摆在那里这块不能有侥幸心理。第二是链路稳定性。文案生成是异步任务晚几秒没关系但意图理解如果接到实时定向上要求单次推理几百毫秒内返回。外部 API 的延迟波动我们控制不了高峰期排队直接会让定向系统雪崩。第三是成本曲线。营销场景的 token 消耗量非常大——一个批次生成 5000 条文案可能就要百万级 token。按 API 计价的话这个成本没有上限自建推理服务虽然前期投入硬件但边际成本可控而且随着调用量增长越来越划算。2.2 基线模型的选择过程私有化部署决定了我们只能选开源模型。当时市面上可选的有 Qwen 系列、Baichuan、ChatGLM、Yi 等。我们没有只看榜单分数而是用自己攒的 200 条营销场景评测题做了一套盲测考核维度包括文案是否贴合货拉拉的品牌调性和品类特征能否输出符合广告法规范的表述有没有极限词、虚假承诺是否具备稳定的 JSON 结构化输出能力7B 量级在 A800 上的推理延迟和吞吐表现。最后选了 Qwen2.5 14B 作为主要生成模型7B 用于高并发低延迟的意图理解场景。选择 14B 的原因很朴素7B 在长文案的条理性和细节丰富度上明显弱一些而 72B 虽然效果好但部署成本翻了近三倍对营销文案这种批量产出版的场景来说性价比不够。我们当时的判断是先能用、好用再追求更好。2.3 vLLM 部署的实操参数部署上我们直接用了 vLLM原因就是它支持的 PagedAttention 显存管理和 Continuous Batching 能显著提升吞吐对我们这种批量生成场景特别合适。几个关键配置分享下每实例 4 张 A800 80GTensor Parallel 设为 4加载 14B 模型后还能余下大量 KV cache 空间--max-model-len设置成 8192营销文案一般不会超过这个长度太大会浪费显存--gpu-memory-utilization设到 0.9尽量把显存留给 KV cache批量生成时我们关闭了流式输出改用同步批量请求配合max_num_seqs参数控制并发度防止一次性涌入太多请求把显存打爆。实测下来单实例 14B 模型在吞吐上可以稳定跑到每秒 800 到 1000 tokens批量生成 300 条文案大概在 40 秒内完成。对于我们的异步任务完全够用。提示vLLM 早期版本对某些模型的支持有过兼容性问题升级版本前一定要先跑回归测试特别是自定义模板和停止符相关的逻辑。我们踩过升级后输出格式直接乱掉的坑后面细说。3. 广告文案生成的工程化提示词与上下文工程大于一切3.1 提示词的第一版设计思路第一次写营销文案 prompt 的时候我们的想法很简单给模型一段任务描述然后让它输出 10 条文案。跑出来效果非常拉跨——内容空泛、像心灵鸡汤、完全没有货拉拉的品牌印记。后来我们意识到营销文案生成不是让模型写作文而是让模型理解一个复杂的约束系统。我们重新梳理了系统提示词结构变成四层角色与任务定义明确模型是货拉拉营销文案助手产出的是用于投放的信息流广告文案。业务规则包括品牌红线比如不能承诺具体时效、广告合规要求不出现最、第一等极限词、文案长度限制。场景信息由外部传入本次投放的目标人群、品类、渠道、投放地区这部分不是写死在系统提示词里的而是每次请求动态拼接。输出格式要求模型严格输出 JSON包含title、desc、reason三个字段其中reason是模型解释为什么这样写方便我们追溯质量。第四层很重要。强制结构化输出不仅方便下游解析而且我们后来发现当模型需要给出为什么这么写的理由时文案质量会明显提升——这相当于强迫模型在生成前先做了一轮自我推理。3.2 上下文工程把历史爆款和行业语料变成上下文资产提示词写好后下一版迭代我们开始做上下文工程。因为我们逐步意识到模型没见过货拉拉式的文案长什么样你光靠规则约束它还是写不出有网感的语言。我们建了一个营销语料知识库里面分三类内容历史投放中点击率高、转化好的文案案例按品类和人群打标行业素材库同城货运、搬家行业的营销文案、头部平台的广告用语脱敏处理后入库品牌术语表货拉拉的车型名称、服务品类、品牌 Slogan、常用营销话术。在每次生成请求时我们通过检索把最相关的 3 到 5 条案例拼进 prompt 的 few-shot 位置让模型模仿着写。这个动作做完之后人工评审的通过率直接从 40% 提升到了 65% 以上。这也是我强烈建议任何做营销文案生成团队优先做的事——微调可以往后放先把上下文工程做好性价比最高。3.3 批量生产时的质量保障机制上下文工程解决的是写得好不好但批量生产还需要解决稳不稳。我们设计了一套三重质量闸门第一重是规则校验调用敏感词库和广告法词库用字符串匹配把明显不合格的文案直接拦截。这步不用模型纯规则速度快召回率不追求 100%只拦截确定有问题的。第二重是模型初筛规则通过的文案再拿一个小模型做合规分类和主观评分分低于阈值的直接进回收站。这个环节我们刚开始用 7B 模型跑准确率堪忧后来改为简单分类任务是否合规、是否符合场景把任务简化后准确率才上来。第三重是人工抽检批量生成的文案按 5% 到 10% 比例抽检运营同学发现问题后反馈到 prompt 或语料库形成闭环。实际上线的文案必须有至少一轮人工确认。这套机制上线后广告文案进入投放池的效率从原来的一周缩短到一天以内而且因为有了模型初筛人工只需要看质量而不是从零写效率提升非常明显。4. 微调实战LoRA 在营销语料上的训练记录4.1 数据准备质量比数量重要得多上下文工程做到位以后我们开始考虑微调。原因是有些场景下 prompt 已经堆得很长但风格还原还是不到位——比如司机端招募文案需要那种实在、接地气、有江湖气的语言风格纯靠 few-shot 模仿总差一口气。数据准备上我们没有贪多。团队从历史投放素材、客服话术、司机社群内容里筛选了大约 8 万条营销相关语料重点做了三类清洗去重和截断长文本按语义段落切分保证每一条训练样本是一个完整表达标注修正对明显违反广告法的历史文案做了剔除避免模型学到错误的合规观念指令配比把数据组装成指令 输出的形式指令涵盖生成、改写、缩写、风格迁移四类任务。这里特别提醒一点营销语料里历史素材的幸存者偏差很严重能留下来的一般是当时效果还行的但完全不代表它合规。之前我们拿一批未经清洗的历史文案直接微调结果模型学会了一堆全网最低价之类的表述差点出事故。4.2 训练细节算力、超参和收敛判断训练用的是 8 卡 A800QLoRA 方案。因为主要目的是让模型学风格和场景化表达而不是注入新知识所以只微调了 LoRA 适配层底座模型权重保持不变。核心超参我们调了两轮最终稳定在这组配置LoRA rank 16alpha 32只作用在 attention 层的 q、k、v学习率 2e-4带 cosine schedulewarmup 比例 3%batch size 64用梯度累积实现训练 3 个 epoch最大序列长度 2048超过的直接截断。训练过程我们一路盯着两个东西loss 曲线的收敛情况和验证集上的生成质量。这里有个经验——loss 降到 1.0 附近之后就不再明显下降但蒸馏出来的生成效果仍然在变好所以不能只靠 loss 数值判断一定要结合评测集上的人工打分。第三轮 epoch 跑完后我们发现打分提升已经趋平说明模型容量到头了再训只会过拟合。4.3 微调与提示词的边界划分整个项目跑下来我对要不要微调的判断标准越来越清晰如果只是让模型按规则输出提示词工程完全够用不要微调如果需要让模型说话像某个群体、像某个品牌且 few-shot 怎么学都不像那就考虑微调微调解决不了知识类问题知识类问题要用 RAG 补上下文两件事别搞混。我们内部现在有一条不成文的规定任何新需求先问三个问题——不微调能不能做、用多少样本能解决、不做是否影响业务目标。能靠提示词和上下文解决的绝不上训练任务团队的时间成本比几次 API 调用贵得多。5. 用户定向与素材初筛大模型在广告链路的两块隐形拼图5.1 从非结构化数据里抽取用户意图文案生成是最显性的应用但真正让我们 ROI 提上去的是用户意图理解。我们把平台内的搜索词、浏览标题、客服会话摘要这些文本流定时送到 7B 模型的意图抽取服务里输出结构化的标签比如场景标签搬家、大件运输、临时用车、商户补货车型意向小面、中面、厢货、平板决策状态比价中、待下单、犹豫期时间紧迫度当天、本周、周末。这些标签产出后一部分直接做成用户分群投放到定向包里另一部分作为特征拼接进传统的 CTR/CVR 预估模型里等于给深度学习模型补充了文本侧的理解能力。实际效果上加了意图特征的人群包转化率普遍高出大盘 15% 到 25%这是我们整个项目里回报最明显的一块。有个容易被忽略的坑意图标签是有时效的。一个用户上周搜索搬家不代表这周还要搬。我们给标签设置了衰减周期超过 7 天自动降低权重避免模型拿过期意图给用户推送不相关广告反而引起反感。5.2 用 LLM 做素材初筛和评分素材初筛是我们上得比较晚的一个模块但效果意外地好。逻辑是与其等广告上线跑几天再根据 CTR 撤掉不如在上线前就过一遍大模型的判断。我们让模型按照几个维度给素材打分与投放目标人群的相关度、卖点清晰度、文案吸引力、合规风险。然后让模型输出一个 1 到 5 分的综合评分并附上扣分理由。模型给的理由往往能直接指导修改方向——比如卖点集中在价格但目标用户更关心时效这种反馈非常具体运营同学可以据此快速迭代。5.3 与传统机器学习模型的配合关系大模型上线后团队里一度有人担心传统模型会被取代。实际上在我们这里两者是配合关系不是替代关系传统 CTR/CVR 模型处理高维稀疏特征、做实时预估这个能力大模型短期内替代不了大模型负责产出新特征、新标签让传统模型看到原本看不到的信息最终决策还是交给线上模型大模型的结果只是输入信号之一。这套架构的好处是改动风险低。大模型挂了定向人群包还会继续存在一段时间不会直接把投放打挂传统模型照常跑只是特征里少了几列。做系统落地永远要给自己留退路。6. 效果评估体系离线怎么评线上怎么测成本怎么算6.1 离线评估LLM-as-Judge 的坑与对策为了快速迭代 prompt 和微调版本我们建了一套离线评测集大约 500 条样本每个样本包含输入场景描述和对应的多组候选文案。刚开始我们想省人工直接用一个大模型当裁判给文案打分结果踩了一个大坑——大模型裁判有明显的长度偏好和华丽辞藻偏好它给那些啰嗦空洞但辞藻华丽的文案打了高分跟人工判断完全背离。后来我们改成了混合方案规则性指标长度、合规词、JSON 格式用代码算不依赖模型主观质量分分两步先用一个大模型做两两对比pairwise ranking再取多轮对比结果排序尽量减少位置偏差每轮迭代抽取 30 条样本人工复核保证机器打分与人工判断的相关系数维持在 0.7 以上低于这个值就调整裁判 prompt。这个方案不是最省事的但结果可靠。AI 生成内容的评估千万别全自动一把梭机器打分只用来筛差异最终裁量权要留在人手里。6.2 线上实验从点击率到生意的完整链条线上评估我们分三个层级看指标效率层CTR、CVR、单次点击成本。这个层级主要验证文案吸引力和人群匹配度。生意层7 日下单率、客单价、复购率。只看 CTR 会骗人有些文案标题党点击高但用户进来发现货不对板下单率反而跌了。品牌层负面反馈率、取关率。广告投放不能只盯着转化过度打扰用户会造成品牌伤害。我们跑过的最大一次实验是大模型生成文案 vs 人工文案在两个同质流量池各投放两周结论是大模型文案的 CTR 略高约 4%但 7 日下单率基本持平。这意味着大模型在效率上没有碾压人工但在产能和成本上优势巨大——人工一个月产 200 条文案模型一个小时就能产出并筛选出同等质量的 200 条。6.3 成本账单我们到底花了多少钱很多团队关心大模型的成本我直接给个参考数。我们两套推理服务14B 生成 7B 意图理解共 8 卡 A800初期硬件投入约百万级。日常运行的电费、折旧、带宽这些摊下来单次文案生成的成本不到一分钱单次意图抽取的成本在毫厘级别。作为对比如果全走外部 API按照我们的调用量每年的 token 费用有可能达到硬件投入的一半以上而且这还是不算数据合规风险的前提。所以从一年的维度算账私有化部署回本周期是可接受的。当然前提是你的调用量要够大、场景要足够稳定如果只是小规模试点用 API 反而更划算。7. 踩坑记录这一路我们交过的学费7.1 幻觉在营销场景的后果比想象中严重大模型的幻觉问题在代码场景可能只是 bug在营销文案场景直接是合规事故。我们遇到过模型生成48 小时必达超时全额退款这种它自己编出来的承诺也遇到过合作 x 家银行推出免息分期这种完全虚构的卖点。应对方案是双管齐下生成端在 prompt 里强制要求只使用给定的业务事实库内容不得创造事实把品牌权益类的表述限定为从知识库检索后原样引用审核端增加规则校验把价格、时效、服务承诺类的关键词全部匹配事实库不一致的一律拦截。到现在我们仍然不敢完全依赖模型自觉审核链路是底线不能省。7.2 提示词和模型版本的配置漂移系统上线三个月后我们遇到过一个诡异的问题同一段 prompt月初产出正常的文案月底突然开始变啰嗦。排查半天发现是运维升级了 vLLM 版本底层模型权重没变但采样相关的默认参数和实现细节变了导致输出分布漂移。从那以后我们做了两件事第一所有 prompt、模型版本、采样参数temperature、top_p全部纳入配置管理改动必须走评审第二每次升级推理框架或模型必须先跑一遍 100 条的回归评测质量分达标才能切流量。这一点对任何跑生产大模型服务的团队都值得借鉴。7.3 千万别忽视人的环节最后说个偏管理层面的教训。技术再强如果运营团队不相信大模型的产出系统是跑不起来的。项目初期我们踩过冷启动的坑——运营同学收到模型文案后基本不用理由是不接地气。后来我们调整了协作方式不是让模型取代运营写文案而是让它辅助运营更快地产出。模型先给 10 个方向的草稿运营在里面选、改、组合引擎才慢慢跑起来。这个认知转变很重要——大模型项目能不能落地很多时候不取决于模型本身多强而取决于你如何设计人和系统的协作关系让使用者从系统中获得掌控感和成就感他们才会主动用它、养它、反馈它。7.4 多模态的尝试与边界我们还尝试过把多模态大模型引入素材生成比如根据商品图和场景描述生成广告配图文案。坦白讲图像生成在广告素材上的效果还在探索中成本也比纯文本高很多。目前我们的做法是把多模态能力用在素材归类和审核上——识别图片里的违规元素、品牌露出、场景匹配度这些任务准确率已经可以商用。图像生成这块我们暂时没有大规模上原因很简单广告素材的审美标准非常高模型生成的图还需要大量人工修改省下的时间不够补修图的投入。我个人对这个方向的判断是多模态在广告领域一定会成熟但当前阶段更适合从理解切入而不是一上来就做生成等模型的审美能力再上一个台阶再扩展也不迟。如果你也在做营销侧的大模型落地我的建议很简单先从文案生成和意图抽取这两个投入小、见效快的场景切入把上下文工程做扎实评估体系建好再考虑微调和多模态。这条路我们走通了按这个顺序来你的团队大概率也能在半年内看到实际回报。