开工。先说句实在话这两年大家都在聊大模型聊智能体聊 Agent但真正落到业务里、能算清楚投产比的项目其实没有那么多。货拉拉的营销广告链路比较有代表性——它涉及海量文案、图片素材、多端投放和内容审核每一个环节都有痛点也都有大模型可以插手的空间。这篇文章把我自己从立项、技术选型、模型微调到上线发布、效果观测的完整过程写出来尽量少讲虚的多讲实操。刚开始接手这个项目时内部讨论里最常被问到一句话“大模型到底能帮广告做什么”说实话这个问题不难回答但难的是给出一个能落地、能统计收益的答案。我们花了大概三周时间把营销广告的整个生产链路盘了一遍才真正找到大模型服务业务的位置。1. 项目背景与问题拆解1.1 货运平台营销广告的典型业务场景货拉拉的营销广告和普通电商广告有相似之处但也有自己的特殊性。用户群主要分两端一端是货主他们需要发货、叫车另一端是司机他们需要接单、跑活。不同的用户群体广告沟通的诉求完全不一样。对货主文案偏向“发货快、价格透明、服务有保障”对司机文案偏向“单量多、补贴高、结算快”。这种双端投放结构天然导致一个结果同一个营销活动可能需要几十甚至上百套不同口径的文案和配图。投放渠道也相当分散。应用商店的标题和截图信息流广告的封面图、标题、标签短信和 push 的短文案还有落地页的 hero 图和副标题。每个渠道对内容长度、风格、格式的要求都不一样。应用商店标题可能只有十几个字短信文案要控制在一百字以内信息流封面图上有大标题也有小角标。问题在于营销节奏极快。一个节日大促、一个城市开城、一个新功能上线都需要短时间内产出大批量素材。在引入大模型之前这部分主要靠运营和设计师手工完成一个熟手文案一天大概能产出十到二十条不同方案的文案设计师一天完成三到五张 banner 主图已经算高效率了。一旦遇到大促节点需求量和人力之间的矛盾就非常突出排期卡得死死地素材供给的速度直接限制了投放计划的上线节奏。1.2 大模型在广告链路上的四个切入点我们把整个广告业务拆开发现内容生产是最大的瓶颈。这个链条大致是营销目标确定 - 创意策划 - 内容生产 - 合规审核 - 投放 - 数据回收 - 复盘优化。大模型能在其中四个环节产生实际价值文案生成围绕活动卖点、用户群体、渠道特征生成多版本营销文案这是文本生成能力最直接的落点。图片素材生成基于文生图模型快速生产广告主图、背景图、节日氛围图辅助设计师提升出图效率。内容合规审核用大模型的语义理解能力替代部分规则匹配更灵活地识别广告法违规词、夸大宣传和敏感表述。复盘数据解读把投放数据转化为可阅读的总结报告自动产出日报、周报和活动复盘摘要缩短运营分析时间。这四个点有一个共同特征它们解决的都不是“从零到一”的创造性问题而是“从少到多”“从慢到快”的规模问题。大模型不负责告诉你这次活动到底该做什么创意它负责在你确定了创意方向之后用极低的边际成本把内容供给量做上去。这一点很重要它决定了整个项目的定位——大模型不是创意本身而是创意工业化生产的放大器。2. 技术选型与整体架构设计2.1 为什么放弃纯闭源 API选择私有化部署项目立项时第一场争论就是底座模型选型。有人建议直接用闭源 API理由是效果好、接口简单、接进来就能跑也有人坚持私有化部署开源模型。最后我们选的是以开源模型为主、私有化部署的路线。理由有三个第一数据安全边界。营销文案本身可能不涉及核心用户隐私但广告投放会涉及人群定向策略、转化数据和活动成本信息。把这些内容发送到外部 API哪怕只传文案和素材也存在数据出域的风险。公司的安全合规团队明确要求核心业务数据不能出域这一条就基本排除了直接调用外部接口的方案。第二定制化和微调的空间。文案生成不是通用对话任务它要求句式结构、卖点表达、词汇风格都贴近货拉拉的品牌调性。闭源 API 可以通过提示词调整一部分但很难针对我们自己的优质历史文案做有监督的深度定制。开源模型则完全不同我们可以拿真实业务数据做 LoRA 微调把模型的语言习惯逐步拉向目标方向。第三长期成本结构。广告素材生产的调用量一旦跑起来规模会非常大。一个活动生成几百条文案一个季度下来就是几十万次调用。按 token 计费短期看起来不高但长期算账自有 GPU 集群的边际成本会更低。而且模型迭代完全自主不用等上游厂商升级。2.2 底座模型与推理部署的取舍底座模型我们做了逐个评测主要看中文理解、指令跟随、文案质量和商用许可。几款主流开源模型都测过一轮最后用的是 7B 和 14B 两个规格的模型搭配使用。简单场景用 7B比如标题改写、标签生成、文本分类复杂场景用 14B比如完整活动文案生成、复盘报告总结。规格选择的逻辑很直白7B 快、省显存、吞吐高14B 质量更好但推理成本也高。两者配合比单一模型更经济。推理服务我们用 vLLM 搭的这里多说一句。vLLM 的 PagedAttention 和 Continuous Batching 两个特性对广告文案这种场景帮助很大。文案生成请求的输入长度通常只有几百 token输出长度从几十到几百不等请求之间长短差距很大。如果等一个长请求生成完再处理下一个GPU 利用率会很难看。Continuous Batching 允许请求粒度动态调度实测单卡吞吐量比普通方式高出两三倍。部署拓扑大致是这样的GPU 节点负责模型推理前端接一个统一 API 网关内部按场景路由到不同模型。同步请求走生成接口批量任务走异步队列。整个链路用 Docker 容器编排配合内部的服务注册与负载均衡业务方不需要关心背后是哪个模型。2.3 先做提示词还是直接微调这是很多团队都会纠结的问题。我们的判断原则是能用提示词解决的绝对不上微调提示词解决不了的才考虑有监督微调。为什么微调的工程成本比很多人想象中要高。要准备训练数据、标记样本、做评测、防过拟合还要保持基座模型原有的通用能力不退化也就是灾难性遗忘问题。这一整套流程下来至少需要两周以上的时间投入。哪些任务留在了提示词方案比如素材合规审核本质是一个带说明的分类任务把广告法规则写进系统提示词配合少量示例Few-shot效果就已经能达到业务要求。再比如投放数据复盘摘要逻辑相对固定提示词也能稳定输出。哪些任务必须微调核心是 banner 文案和落地页文案生成。这类文案有强烈的品牌风格要求比如货拉拉的文案喜欢用短句、动词开头、强调结果。通用模型默认生成的文本偏向说明书口吻不够“广告”。我们积攒了上万条历史高转化文案这些数据不拿来微调太可惜了。微调之后输出风格的稳定性有了质的提升。3. 训练数据构建与 LoRA 微调实战3.1 数据是最重要的环节不是模型我必须强调在整个项目里最后影响效果上限的不是模型而是训练数据。我们花了接近三周时间做数据清洗真正微调只花了几天的 GPU 时间。数据来源主要有四个渠道历史投放优质文案把过去两年 CTR 和 CVR 表现好的文案捞出来按行业归类。这些是模型学习“什么文案能吸引点击”的核心正样本。运营手工优化稿运营同学在投放前会针对渠道特性手工修改文案。这些修改痕迹记录了对字数的控制、语气词的增删和卖点的排序本质上是一份很高质量的“改写对齐数据”。设计师和投放经理反馈收集他们觉得“有感觉”的素材描述作为风格参考。合成数据扩展用更强的大模型对少量种子文案做扩写和改写生成候选池后人工打分筛选。数据清洗要处理三个典型问题一是重复内容同一个活动不同渠道的文案高度相似需要按文本相似度去重二是文案与活动主题不匹配比如“拉新补贴”活动中混入了“司机接单”相关内容这类脏数据会让模型混淆卖点边界三是低质量机器生成内容早期测试阶段产出的文本不能进训练集。清洗后的数据总量接近 5 万条按 8:1:1 切分训练集、验证集、测试集。3.2 LoRA 微调的显存估算和参数配置我们用的微调方式是 LoRA。它是目前工程上最流行的参数高效微调方法核心逻辑是不动原模型的权重而是在每层注入两个低秩矩阵训练时只更新这两个小矩阵。这样的好处是显存占用大幅下降训练完只需要保留几百 MB 的增量文件部署时和基座模型合并即可。显存是 GPU 微调中最容易踩坑的点。我当时做了一个粗估算以 7B FP16 模型为例权重本身约 14GB。一般微调还需要存梯度和优化器状态如果全量微调额外需要约 14GB 梯度和 28GB 优化器状态一张 40GB 的卡都扛不住。但 LoRA 只需要优化 LoRA 分支的参数梯度和优化器状态开销从 GB 级别降到了 MB 级别。主要开销反而变成了激活值——也就是前向传播过程中间变量以及反向传播时需要的中间结果。所以实际可行的配置是单卡 24GB比如 4090 或 A10开启梯度检查点batch size 设 4序列长度 512就能稳定跑 7B 的 LoRA 微调。如果想在同样显存下加大 batch可以配合梯度累积把每 4 个 step 的梯度累加一次再更新参数等效于 batch size 16。参数配置方面我分享一组比较稳的配方LoRA rank 8alpha 16。这个组合通常能兼顾拟合能力和过拟合风险。rank 太大容易记住训练集噪声太小则表达力不足。学习率 1e-4使用 cosine 调度warmup 比例 3%。训练 3 个 epoch。我们试过 5 个 epoch效果反而下降因为模型开始把训练集里的营销卖点和句式当成了通用模式。训练过程用开源微调框架跑支持多个实验并行。每个实验大概需要 4 到 8 个 GPU 小时成本完全可控。3.3 提示词工程与上下文工程不是非此即彼做完微调之后很多人以为提示词就不重要了这是个误解。微调解决的是风格和基础能力问题但具体到一个渠道一条文案要多少字、卖点怎么排序、有没有禁用词这些还得靠提示词和上下文工程来约束。我们把提示词拆成了几个固定的结构块角色设定、任务描述、输入输出格式、示例、约束条件。比如短信文案的提示词里会明确写出“输出不超过 70 字”“不得使用最高级形容词”“必须包含行动指令词”。上下文工程在这里的价值是动态注入。同一条卖点文案在不同渠道、不同用户群体下的写法差异很大。我们做了一个简单的上下文检索模块给用户群体打上标签新司机、老司机、高频货主、低频货主根据标签从历史优质文案库里检索最相似的三条示例拼进上下文里再调用模型。这比每次手工换示例效率高很多效果也更稳定。所以微调和提示词不是替代关系而是分层协同微调保证基础表达风格提示词保证单次任务的输入结构上下文工程保证输入信息的丰富度。4. 核心场景的落地实现4.1 广告文案生成从标题到落地页文案生成是第一个上线的场景也是效果最直观的场景。我们做的不是让模型自由发挥而是把它嵌入到一个有约束的生产流程里。运营同学在系统里新建一个活动填上活动名称、目标用户、核心卖点、优惠力度和投放渠道点击生成系统就会向模型发送包含这些信息的请求。模型输出多个候选版本运营在页面上勾选或微调后一键发布。不同渠道的参数约束在模板里写死。以短信推送为例历史上发现超过 70 字的文案打开率明显下降所以把长度上限设为 70 字。push 的约束是 30 字落地页主标题是 20 字副标题是 45 字。这些规则全部做成配置项每次生成前由程序自动验证输出长度超长则触发改写重试。一个活动我们默认生成 20 条候选。早期版本的问题是候选多样性不够20 条之间差别不大运营选不出感觉。后来在生成参数里调整了采样温度temperature和 top_p温度从默认的 0.7 调到 0.9top_p 从 0.9 调到 0.95多样性明显改善。但也要注意温度过高会产生语义漂移出现过文案与活动不相关的案例所以最终选择了 0.85 作为浮动区间的上限。4.2 多模态素材生产图片创意的辅助生成文案之后是图片。这一块我们用的不是自研模型而是基于开源文生图模型做二次开发。整体工作流分三步第一步由文生图模型生成纯背景层。比如“新司机注册有礼”的活动生成一张城市货运车辆行驶在街道上的场景图要求风格明亮、无明显文字、留出足够的产品和文案区域。第二步把背景图交给设计师设计师只需要把主视觉元素比如车辆、货品、人物对位摆放再把运营确定的文案标题叠加上去。模型产出的图片不直接作为成品而是作为底图或氛围图这既保证了品牌视觉的一致性也降低了纯 AI 出图带来的生硬感。第三步针对特定车型或活动主题训练 LoRA 风格控制模块。简单来说我们筛选了大约 800 张历史表现好的广告背景图训练了一个专属的风格 LoRA确保生成图片的色彩倾向和视觉风格贴近既有品牌素材。实测下来设计师的单个素材制作时间从平均 45 分钟缩短到 15 分钟左右主要时间花在挑选底图和微调合成上。这带来一个直接变化——设计师的角色从“画手”变成了“创意导演精修师”这比单纯追求生成效果更符合实际业务需要。4.3 内容合规审核从规则引擎到大模型分类广告行业有个绕不开的环节是合规审核。过去我们用过规则引擎通过一个敏感词表和正则表达式做匹配能拦住一部分明显违规的表述但对语义层面的违规识别能力很弱。比如“最便宜”“第一”“绝对划算”这类词可以通过规则命中但像“其他平台做不到的优惠力度”这种话没有直接触发敏感词意思却明显有问题。大模型在语义理解上有先天优势。我们做的是一个少样本分类任务把广告法常见违规类型极限词、夸大承诺、贬低同行、未证实数据引用等定义成几个类别每个类别给两条示例让模型判断输入文案属于哪类风险或合规。输出格式限定为 JSON包含分类结果和风险说明。实测数据是单纯规则引擎的召回率约 72%加入大模型兜底审核后召回率提升到 94% 以上同时误报率没有明显上升。合规团队日常审核压力大幅下降漏网案例主要集中在语义比较隐晦的表述这种案例我们还在持续收集作为新的示例补充进 prompt。4.4 活动复盘与数据解读最后一个落地场景是投放后的数据复盘。投放系统每小时的曝光、点击、转化数据量很大过去运营同学每天早上要手动拼一份 Excel 日报费力且容易遗漏关键指标。我们做了一个数据到文本Data-to-Text的生成流程每天定时从数据仓库取前一日各渠道数据以结构化文本形式拼成一段描述再输入大模型让它生成一段包含关键结论的复盘摘要。提示词里要求模型只基于给定数据做总结不进行推测并且明确列出“环比变化20%”的指标方便运营快速聚焦问题。这个功能上线后运营同学从每天 40 分钟的数据整理时间里省出了 30 分钟而且日报的覆盖完整度反而更好了。模型偶尔会出现读错数字的问题所以在输出后加了一层规则校验把文本中出现的百分比数据与原始数据比对不一致就自动重新生成基本杜绝了幻觉。5. 效果评估与业务收益观测5.1 离线评估大模型评大模型的靠谱做法评估文案生成质量是项目中最难的一环。传统的 BLEU 和 ROUGE 指标在机器翻译场景很有效但广告文案没有唯一标准答案同一卖点可以有无数种表达方式SacreBLEU 分数对营销文案的参考价值很有限。我们采用的方案是 LLM-as-a-Judge也就是让能力更强的大模型充当评委对生成文案从相关性、卖点清晰度、表达吸引力和合规风险四个维度打分。这个方案有一个值得注意的坑评委模型本身会有偏好偏见。比如评委模型默认喜欢更长的文本但短信文案要求短评委模型偏好权威口吻但广告文案有时候需要亲切调侃的风格。为了解决这个问题我们做了两个处理。一是给评委模型提供明确的评分标准和正反例二是把人工评分的样本混入评测集用人工分和模型分的相关性Spearman 相关系数来校验评委的可靠性。实测最终相关性能到 0.8 左右虽然不算完美但足够用于日常迭代模型的快速筛选。5.2 线上 AB 实验设计离线评估之后必须过线上 AB 实验这一关。我们的大致做法是选一个持续两周的常规营销活动将投放人群随机切分对照组使用人工原版文案和素材实验组使用大模型生成、运营确认后投放的文案和素材两边预算相同渠道相同。核心看三个指标素材利用率运营实际采纳并投放的比例、点击率 CTR 和转化率 CVR。这里透露一个真实的尴尬早期实验模型组文案的 CTR 一度低于人工组 0.3 到 0.5 个百分点说明大模型生成的内容虽然在语言表达上没问题但在“激发点击欲望”这方面还差一点。后来我们缩小了生成范围让模型参考历史高 CTR 文案的句式结构才把差距缩小到不明显。最终实验结论是模型组单条文案平均 CTR 与人工组基本持平CVR 略低但统计不显著但模型组的文案供给量是人工组的三倍以上最终整体消耗和订单转化量比对照组提升约 12%。运营同学的核心任务从“无中生有地写文案”变成了“从大量候选中快速挑选和微调”整体效率提升非常明显。5.3 成本和收益的通盘账算账这件事建议一定要早算算清楚了才能说服预算委员会。我们项目上线后一个季度的整体成本大致分为三块GPU 资源3 台双卡 A10 服务器用于日常推理和部分微调月摊销大约数万元级。训练和调试成本LoRA 微调每个实验几十 GPU 小时一个季度累计几百 GPU 小时成本占比不高。人力投入算法团队从 3 人扩展到 5 人这部分是真实增加的。收益方面文案产能从每天约 10 至 20 条提升到 100 条以上素材制作时长缩短约 60%合规审核人力需求明显下降。如果按外包设计一条主图 200 元、一条文案 30 元的市场价折算一个季度节省的外包费用远大于 GPU 和人力成本。更关键的是素材供给能力提升后带来的投放增量收益比直接节省的人力成本高一个数量级。所以如果只从“省了多少人力”角度看这个项目的收益可能有限但如果从“多做了多少业务”角度算回报相当可观。6. 常见问题与排查技巧实录6.1 幻觉问题营销文案里的“假承诺”大模型生成文案最常见的问题是幻觉尤其是陈述事实和承诺服务时。曾经有一次生成的司机招募文案里写了“月入保底一万五”这个数字我们从未承诺过如果直接投放出去后果非常严重。处理经验有三层第一层是输入约束在提示词中把卖点改成一个结构化对象而不是让模型自由发挥模型只能从给定字段里提取卖点信息输出中不允许出现字段之外的数值第二层是输出校验对生成的文案做正则和规则检查命中“保底”“最高”“第一”等高风险词直接拦截第三层是引用可靠数据涉及具体补贴金额时强制从知识库中检索真实活动规则再写入文案。6.2 推理延迟与吞吐优化广告文案生成对时延的容忍度比聊天场景高一些运营可以接受 3 秒内的响应。但如果推送场景未来要接实时投放延迟就必须压到 1 秒以内。我们做了三件事第一开启 vLLM 的 Continuous Batching把不同请求混合调度单卡吞吐提升了约 2 倍。第二对 7B 模型做 AWQ 4bit 量化显存占用下降约 60%但由于解码速度瓶颈在内存带宽量化加速效果有限更多是提升了显存利用率。第三做了基于前缀缓存prefix caching的请求复用同一个活动下的多个文案请求共享输入前缀KV cache 可以直接复用长请求场景下时延下降比较明显。实测数据供参考7B 模型在 A10 单卡、并发 16 路的条件下单条 100 token 文案的 P95 延迟约 1.4 秒14B 模型在同等条件下 P95 约 2.8 秒。业务上我们一般把 14B 模型用于离线批量生成和审核在线优先转发给 7B。6.3 长上下文与知识注入的处理技巧广告营销场景中模型需要知道的背景信息有时候远超过训练时见过的任何单条样本。比如一个完整的活动方案包括目标人群画像、商品价格区间、历史活动表现、渠道注意事项加在一起可能超过 3000 token。这时如果不加处理地把全部信息拼进 prompt模型会在中段“迷失”输出内容只反映开头和结尾的信息。我们的解决方案是信息分层。最核心的卖点和规则永远放在 prompt 末尾模型对末尾内容注意力最强较长的背景资料放在中段用 XML 标签做分组历史优秀案例以 Few-shot 形式放在最前面。这样调整之后生成的准确率提升很明显。如果上下文长度真的超过模型限制优先考虑做检索压缩而不是直接截断。把活动方案中与当前渠道最相关的 3 到 5 条信息抽取出来替换为结构化摘要比硬截断损失的语义少得多。6.4 多团队协作与工程规范这个项目的参与方不止算法一个团队还有运营、设计、合规和投放工程团队。协作中踩过各种坑之后我总结出几条必须尽早确立的规范版本管理模型文件、微调数据和 prompt 模板全部纳入版本管理每次修改有记录可回溯。灰度发布新模型不得直接全量上线先在 10% 流量上跑一天对比线上指标没问题再逐步放量。接口契约先行算法团队先定义好输入输出 JSON Schema交给业务方对接避免两边各自开发最后格式对不上。评测集持续沉淀每次线上发现的问题案例都追加进评测集确保修复后不会回归。7. 踩坑记录与后续规划7.1 三个印象深刻的坑第一个坑是微调过拟合后文案“千篇一律”。早期训练时只用了约 2 万条文案模型收敛得很快但生成结果高度趋同句式全是“限时领取”“立即参与”这类模板运营看上几条就腻了。增加数据多样性、拉大采样温度之后才缓解。第二个坑是审核模型误伤严重。最早用来做合规审核的模型把“优惠力度大”也判成了夸大承诺导致大量正常文案被拦截。排查发现是示例数据选择问题——只给了违规示例、没给合规示例模型学会了“宁可错杀”。在 prompt 中增加同类型合规正例后误报率立刻降了一半。第三个坑是长任务的超时设置。最初调用推理服务时把超时时间设成 3 秒结果批量生成任务频繁超时重试浪费了大量算力。后来改成同步短任务 3 秒超时、异步长任务 30 秒超时的双通道机制才把问题解决。7.2 从生成到决策后续想做什么目前的系统本质是大模型辅助人做内容生产人在环节里依然是决策核心。下一步我们计划往更深的自动化方向走让大模型基于投放实时数据自动发现低效素材并给出优化建议运营确认后闭环修改。这一步本质上是从“生成”走向“决策”对模型的要求会更高但对业务的放大效应也更明显。另一个方向是 Agent 化。目前大模型在审核、生成、分析之间还是独立的 API逻辑要靠编排系统串起来。后续考虑把整个链路做成一个可配置的 Agent内部规划任务、调用工具、校验结果。营销场景的步骤相对固定Agent 的落地难度可控值得尝试。最后再分享一点我的个人心得。这个项目做下来我最大的感受是大模型的真正价值不在于它单独能做什么而在于它嵌入到一条成熟的业务链路后把原先受限于人力瓶颈的环节放大了。文案、图片、审核、复盘这些环节过去靠人现在靠模型辅助人单位人力能覆盖的业务规模有了数量级的提升。如果你也在考虑上大模型项目我建议先别急着追求最新最强的模型而是回到业务链路里找出那些“人力堆不出来规模”的环节从那里切开。模型的强弱是暂时的业务链路的改造才是长期有效的。