先说说背景。货拉拉这家公司主营同城货运、跨城运输和搬家用户规模几千万司机端和用户端的DAU都不低。营销广告的体量非常大——光是一天的Push推送、短信触达、App内弹窗、社交媒体投放就能产生几千条文案需求如果再算上不同城市、不同车型、不同用户标签的组合人工根本写不过来。我们团队从去年开始把大模型引入营销广告体系从最开始单纯用GPT类API生成文案到后面自己微调开源模型、搭建RAG知识库、做Agent编排整个过程踩了不少坑也沉淀了一些可复用的经验。这篇内容就围绕这个实践来聊适合那些正在做大模型 x 营销或者准备做营销中台改造的同学尤其是电商、本地生活、出行物流这类强运营属性的平台我们的问题和解法大概率你们也会遇到。1. 业务场景货拉拉营销广告到底需要什么1.1 货运平台营销的真实痛点货拉拉的营销场景比普通电商更复杂因为用户决策链路长而且带有很强的即时性和本地化属性。用户打开App可能是为了明天搬家也可能是为了立刻拉一批建材这两种状态下看到的广告文案完全不能一样。过去的做法是运营团队建一堆文案模板再用标签拼接的方式组合出千人千面的效果比如您附近的搬家师傅已就绪这种话术。模板化的问题很明显写多了用户会产生模板疲劳打开率越来越低同时模板是静态的无法根据时段、天气、库存运力动态调整。更麻烦的是素材维度。广告除了文字还有图片、短剧脚本、语音外呼话术。货拉拉做过不少这类活动比如拉货节搬家季需要大量视觉素材和互动内容。以前这些全靠外包设计团队和运营手工磨一个活动上线光物料准备就要2到3周等上线的时候市场热点早就过了。运营同学经常抱怨好创意是有的但量产不出来一个活动只能保重点渠道。投放侧的痛点同样突出。货拉拉的获客渠道分付费投放信息流、搜索和自有渠道Push、短信、应用内消息每一类渠道都需要对应的广告文案、落地页和人群定向策略。传统的投放优化依赖优化师经验A/B实验一个一个做周期长而且很难把用户行为和文案内容建立细粒度的归因关系。比如某个渠道的点击率突然下降优化师没法快速判断是文案问题、出价问题还是人群包过窄。这正是大模型能切入的地方。LLM天然适合做三件事文本生成、意图理解、知识组织。营销广告本质上就是在合适的时间用合适的语言把合适的服务推给合适的人。大模型可以把原来由人完成的创意发散、文案起草、素材标注、内容审核这些环节自动化而且可以基于实时反馈做迭代。我们在立项的时候就是围绕这四个环节来的内容生成、用户理解、投放优化、效果复盘。1.2 大模型能切入的四个环节第一是内容生成。利用大模型生成活动主题词、Push文案、短信、落地页标题、商品利益点以及多模态的图片素材比如用Stable Diffusion或者多模态大模型生成活动海报底图再用LLM生成配套文案。我们最开始投入产出的就是这里因为需求最直接、见效最快。第二是用户理解。这里的理解不是做用户画像标签这种传统东西而是把大模型变成语义引擎去解析用户的进线诉求。比如用户在App内搜索搬钢琴我们不只是知道搬家需求而是知道这是一个需要专业钢琴搬运、需要气垫膜和固定绳的高价值订单从而生成更精准的广告文案和调度建议。第三是投放优化。利用大模型生成人群包解析报告和渠道投放策略建议。这不是让模型直接改出价而是让它从历史投放数据中总结规律输出哪些人群在什么时间段更容易转化用什么样的话术刺激这类可执行建议辅助优化师决策。第四是效果复盘。大模型把每周的广告数据报告自动生成摘要识别异常波动并关联到可能的原因——比如点击率下降了可能是因为上周主打搬家场景而这周新用户比例增加新用户对搬家措辞的共鸣度较低。这个能力帮运营省了大量的读表时间。这四个环节不是一次性铺开的而是按季度分批推进。第一阶段只做文案生成跑通评估流程第二阶段做知识库和微调提升内容的业务匹配度第三阶段才做 Agent 编排。接下来重点讲技术选型和工程落地过程中的细节。2. 技术选型不是越大的模型越好2.1 基础模型对比与实际选型营销广告场景对模型的要求有几个特点第一是输出长度不长但必须高度符合业务语境第二是需要支持多轮改写和微调第三是单次调用的成本敏感因为广告文案生成的调用量非常大一天可能几百万次。如果完全依赖闭源API费用会非常失控。所以我们的底座选型是闭源API 开源大模型双轨制。一些复杂的创意发散任务比如活动主题脑暴、短剧脚本用更强的闭源模型而高频、规则化的任务比如Push文案生成、短信文案改写用开源自部署模型。开源的候选模型当时主要看了Qwen2.5系列和Llama 3系列。经过一段时间实测我们最终把主力模型定在Qwen2.5-7B-Instruct和Qwen2.5-14B-Instruct两个规格上。为什么是Qwen而不是其他模型几个实际原因第一Qwen的中文能力在同尺寸模型里确实靠前尤其是在营销文案这种需要一点语言巧思的任务上生硬感明显更少第二Qwen对Function Call和工具调用的支持比较完整后续做Agent编排很方便第三有大量社区微调案例我们踩到坑的时候能搜到很多解决方案。14B模型用于质量要求高的场景7B模型用于成本和延迟敏感的场景。两个模型可以共用一套微调流程只换底座权重适配器Adapter分开管理非常灵活。关于多模态我们后期也接入了图片生成模型用来生成活动海报的底图和优惠券的视觉素材。这部分单独做了一个图像服务和文本生成服务解耦。注意多模态大模型不是必须的如果你的营销素材主要靠设计师手工做我建议先别急着重投入文本广告的应用边际价值更大。2.2 微调方案LoRA与QLoRA的选择逻辑刚开始我们也想过用闭源API加提示词的方式硬扛。但做了两个月发现不行因为营销文案有很强的品牌调性比如货拉拉的拉货赚钱口号就不能让模型随意发挥出高端物流的调性。提示词里写了要符合货运平台风格模型还是会不稳定。于是我们决定微调。从热搜里你应该也看到大模型微调实战和qwen2.5-7b微调行业大模型这些词越来越火说明微调已经是一个被广泛验证的技术路径。我们的微调方案首选LoRA而不是全量微调原因很朴素我们的数据量只有几万条全量微调容易过拟合而且我们需要快速迭代多个业务线的模型LoRA可以做到每个业务一个Adapter最初用一套底座基座需要切换业务时动态加载不同的LoRA权重存储开销和训练成本都很低。QLoRA我们也测过就是在LoRA的基础上把基座模型量化到4bit后再训练。对于单卡24G显存的机器QLoRA可以跑14B模型LoRA只能跑7B或者小规模14B。如果你的资源有限可以优先QLoRA如果追求训练稳定性和效果LoRA更好。我们最终对14B模型使用了QLoRA对7B模型使用LoRA因为7B模型直接加载到单卡很轻松没必要量化引入额外的精度损失。微调数据方面我们把历史上所有点击率高于渠道均值1.5倍的文案作为正样本把低于阈值的作为负样本让模型学习什么样的措辞更受欢迎。具体训练时不是让模型去分类而是把正样本作为标准答案做条件生成训练负样本用来构造对比样本做DPODirect Preference Optimization。DPO的效果比单纯SFT要好因为模型能学到避免用户不喜欢的话术而不仅仅是模仿好文案。2.3 推理部署策略vLLM与Ollama的取舍部署层面我们分两套环境。开发测试环境用Ollama因为启动快、配置简单不需要额外写服务代码适合算法同学本地验证。生产环境我们用的是vLLM因为它支持PagedAttention和Continuous Batching吞吐量比原生Transformers的生成方式高很多。我们压测过同样一张A10显卡部署Qwen2.5-7B用vLLM的并发吞吐量大约是原生推理服务的2.5到3倍而且长文本生成时的显存占用更稳定。如果你也需要部署生产环境的大模型记住几个关键点第一使用OpenAI兼容的API接口这样上层业务代码可以无感切换闭源API和自建模型我们整个营销系统对外暴露的统一接口就是这种格式第二必须开启流式输出SSE因为广告文案生成如果让用户等2秒再一次性返回体验很差流式可以边生成边展示首字延迟能做到500毫秒以内第三要有完善的监控包括每秒钟请求数、平均首字延迟、平均Token生成速度、显存占用和GPU利用率这些指标任何一个异常都可能导致线上事故。关于本地部署大模型和ollama部署私有大模型这些热词如果只是个人玩玩或者做POCOllama确实很方便。但假如你做生产环境还是老老实实用vLLM这类工业级推理框架。Ollama在模型并发、服务稳定性、量化精度控制上还是相对弱一些。3. 工程化实践从Prompt到Agent3.1 提示词工程与上下文工程营销文案稳定性的第一道防线很多团队一上来就微调其实顺序错了。提示词工程是性价比最高的手段先用好提示词再考虑微调。我们的Prompt模板经历过四个版本迭代。第一版是一个简单的指令给我写一条货拉拉搬家优惠的Push文案带上限时优惠。结果输出的文案千篇一律而且格式很乱。第二版加入了角色设定和输出格式要求比如你是一位资深用户运营专家请用口语化的语气生成一条Push文案不超过30个字必须包含利益点和紧迫感。效果好了不少但内容仍然不够有针对性。第三版引入了结构化输入。我们把用户特征、活动信息、渠道特征全部作为上下文输入比如{ user_profile: { city: 成都, user_type: 三个月未下单, last_order_category: 搬家, preferred_time: 周末上午 }, campaign: { name: 周末搬家优惠, discount: 满80减20, start_time: 2025-06-14 00:00:00, end_time: 2025-06-15 23:59:59 }, channel: app_push, output_format: title: [10字以内]\\n body: [30字以内]\\n action_url: [短链] }自从用了结构化输入模型的输出稳定性大幅提升。这就是为什么大模型提示词工程与上下文工程现在被频繁放在一起说——上下文工程不只是往Prompt里塞几个变量而是把业务语义、场景约束、输出schema都系统化管理起来。第四版加入了Few-Shot示例。我们从历史点击率最高的文案中挑选了5条不同风格悬疑型、直接利益型、情感共鸣型、地域型、时效紧迫型作为示例每次调用时动态选择最贴近当前用户特征的2到3条放入Prompt。这里有个细节示例不要只给好的不给坏的。我们试过在示例中加一条错误示例用户不喜欢的文案风格模型会明显更懂得规避。提示词的核心原则可以归纳成三点第一角色设定能改变文风第二输出schema能改变格式第三Few-Shot能改变专业性。做营销广告这三层缺一不可。3.2 RAG把品牌规范和业务知识注入生成过程光有提示词还不够因为营销知识是动态的。比如货拉拉在不同时间段有不同的活动政策价格权益也在调整。如果把这些信息写死在Prompt里一旦政策变化就得改代码很不方便。我们引入了RAG检索增强生成用向量数据库存储所有活动规则、品牌关键词表、禁忌词表、历史优秀文案库每次生成前先检索最相关的几条知识作为上下文。举例说明运营在后台创建一个新的活动新人首单立减25元并写了活动说明。系统会先把活动说明存入向量库同时关联到已有的新用户引导话术知识块。当用户触发Push生成请求时RAG会检索新人首单立减25元相关的知识片段再结合用户画像去生成文案。这样就保证了文案一定包含正确的优惠金额不会出现立减30之类的幻觉金额。RAG的落地有几个坑要提醒向量库的切分粒度不要太大我们最初按整个活动页面切chunk检索出来很多无关内容后来改成按利益点适用人群时间限制切检索准确率提升明显。混合检索比纯向量检索好。营销文案里经常有搬家拉货这种词向量相似度不一定抓得住我们加了BM25关键词召回再做RerankTop1的命中率从62%提升到了89%。知识库需要定期更新和清理。我们每周跑一次脚本把已过期的活动规则从向量库中移除避免模型生成时推荐已经下线的权益。RAG的意义不只是知识补充它还给模型提供了一条证据链。当运营同事问为什么生成这样一条文案时系统可以展示命中了哪些知识片段这在业务评审时非常重要。广告是强合规场景任何一句全场五折的幻觉都可能带来客诉。3.3 Agent编排让大模型真正参与投放决策把RAG和提示词用好之后再进一步就是Agent编排。我们做了一个叫活动操盘助手的系统输入一个活动目标和预算Agent会自动完成以下任务第一步调用意图识别模型解析活动目标比如提升老用户复购就触发老用户召回策略。第二步从用户画像库中圈选目标人群这一步不是用大模型直接生成SQL而是让模型通过Function Call调用人群筛选工具传入结构化参数。第三步生成多套文案方案并配上预估点击率这里用了一个小的CTR预测模型做打分。第四步根据渠道特点自动选择文案和素材比如Push渠道用短文案短链信息流渠道用视频脚本落地页。最后生成完整活动配置工单交给运营确认后一键发布。这套Agent的技术架构不复杂就是一个带工具调用能力的大模型加一个工作流引擎。重点在于每一步都要有人审开关不能完全自动。因为营销涉及用户的钱袋子和品牌形象任何一环出错都可能是事故。我们把Agent的自动率控制在40%左右剩下的60%由系统生成建议、人工确认。随着模型效果稳定再逐步放宽自动执行的范围。从热搜词大模型智能体 旅游推荐能看出来Agent应用正在各种行业渗透。但营销Agent和泛娱乐Agent有一个本质区别营销需要可量化的商业目标每一步都围绕转化率、客单价、ROI来优化而不是聊得开心就行。所以建议各团队在做Agent时先把业务指标拆到底再设计工具链顺序不能反。4. 实操记录一套完整的落地步骤4.1 数据准备从历史广告日志里挖金子数据是微调模型的根基。我们在启动微调前花了两周时间专门做数据清洗。原始数据是广告投放日志包含渠道、文案内容、展示次数、点击次数、转化次数、用户标签、时间戳等。第一步做数据去重把内容完全相同的文案合并保留累计数据。第二步做质量过滤把长度小于5个字的、包含明显拼写错误的、没有CTA的文案剔除。第三步做正负样本标注。正负样本的判定不能只看点击率因为不同渠道的基准点击率差异很大。比如Push的平均点击率可能只有3%但短信可能只有0.5%信息流的点击率又不同。所以我们对每个渠道单独计算中位数点击率高于渠道中位数1.5倍的算正样本低于0.8倍的算负样本中间的部分不参与训练。这样做的目的是让模型学到相对优秀而非绝对点击率高。我们还需要广告分层数据。例如一个活动文案可能被推给了不同的人群同一句话在不同人群上的点击率差异很大。为了简化初版模型我们只保留那些在至少三个不同人群上都高于中位数的文案做正样本这样可以减少过拟合。总共筛出正样本2.3万条负样本1.8万条。说实话这个数据量训练7B模型不算多但配合DPO和强基座效果还是够用的。4.2 微调实战基于Qwen2.5-7B的LoRA代码微调我们基于LLaMA-Factory来做因为它内置了LoRA、QLoRA、DPO等训练脚本省了很多底层功夫。关键配置如下model_name_or_path: Qwen/Qwen2.5-7B-Instruct dataset: marketing_ad finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 num_train_epochs: 3 learning_rate: 2e-4 per_device_train_batch_size: 4 gradient_accumulation_steps: 8 lr_scheduler_type: cosine warmup_ratio: 0.1训练过程中有两个需要特别留意的地方第一是训练数据格式LLaMA-Factory要求对话格式的字段。我们把营销场景封装成一个三段式对话system描述品牌调性和输出约束user输入用户特征和活动信息assistant输出标准文案。这样微调出来的模型推理时也沿用同样的格式一致性很强。第二是学习率不要设太大。LoRA的r16在营销数据上如果学习率超过5e-4特别容易灾难性遗忘也就是模型开始生成乱码或者重复文本。另外alpha是lora_rank的两倍这是社区验证过的较优默认值我们试过1倍和4倍效果都没有2倍稳定。训练完成后把Adapter保存下来和基座模型一起加载到vLLM。这里还有一个实用技巧如果多个业务线各有一个Adapter一定要在服务启动时一次性加载所有Adapter然后通过请求里的lora_name字段动态切换而不是每次都重新加载模型这样可以节省好几个数量级的切换时间。我们最初就是每次切换都reload模型接口延迟直接飙到3秒以上后来改成动态切换后延迟降到了200毫秒。4.3 部署与评测不能只看BLEU部署阶段我们用vLLM起了两个推理服务一个跑基座带LoRA一个跑纯通用模型。对外统一走OpenAI兼容接口用Nginx做负载均衡和路由根据请求中的model字段区分调用哪个服务。刚上线时我们犯过一个低级错误没有做并发控制和排队机制。广告运营在活动高峰时会一次性批量生成几千条文案直接把GPU服务打满导致后面的请求全部排队等待首字延迟从500毫秒飙升到10秒。后来在API层加了基于Redis的令牌桶限流又增加了一个异步任务队列批量请求先落数据库由Worker从队列中消费再调用大模型生成完后回调通知前端。用户体验从等10秒出全部变成了先看到生成进度30秒后查看结果。虽然表面看起来还是等但不会因为超时导致失败。评估维度上我们分自动化和人工两条线自动化评分用中文BLEU和ROUGE跟历史最优文案做相似度对比此外还加了三个业务指标利益点完整率是否包含满减金额、券码、时间、品牌词规范率是否出现货拉拉正确拼写、CTA完整率是否包含行动号召。人工评分运营同事按1到5分打分维度包括相关性、吸引力、合规性、格式质量。每个版本上线前抽200条样本做人工盲评。实践三个月后我们发现BLEU和ROUGE与业务指标的相关性其实不强。有的文案ROUGE得分高但因为模仿痕迹太重点击率反而不高。所以后期我们对自动化评分做了降权处理人工评分权重提上来同时直接用线上A/B点击率作为最终裁判。工具指标用于快速筛选业务指标用于最终决策。5. 常见问题与排查技巧实录5.1 模型输出幻觉和违规内容怎么处理广告内容最怕幻觉。我们遇到过几次模型生成了不存在的优惠比如活动明明是满100减10模型却写了全场6折原因是训练数据里有过期活动文案模型学到了不该学的模式。解决分三层第一层Prompt层强约束在system提示中明确写优惠金额必须引用用户输入中的campaign字段禁止编造折扣信息同时给出JSON Schema要求输出时带上discount_source字段这个字段标注了金额引用的是哪条知识。第二层RAG兜底生成完成后把输出中的金额类关键词与知识库中的有效活动规则做一次精确匹配校验如果发现不一致自动重新生成或进行纠正。这一步我们直接用简单的正则加向量检索做不需要再调一次模型。第三层输出审核服务所有生成内容过一遍敏感词表和合规规则引擎比如全网最低唯一绝对这类广告法禁词直接用黑名单拦截。对于更隐性的违规比如过度承诺服务质量目前的做法是在训练数据中增加人工标注的负面样本然后定期做RLHF或者DPO迭代。这个方向不能指望一步到位需要业务同学持续反馈错误案例沉淀成违规样本库变成我们的负例知识库。5.2 推理延迟和成本如何平衡营销广告生成服务有两大成本GPU硬件成本和API调用成本。我们用自部署模型后单条Push文案生成的成本大概只有闭源API的十分之一但GPU资源本身也很贵。平衡手段有三招首先是模型分档。最轻量的场景比如Push内容用7B模型承载80%的流量复杂场景比如落地页长文案用14B模型承载15%流量剩余的创意性任务活动主题、视频脚本才调用闭源API。分档之后整条链路的单位成本下降了约60%。其次是输出Token限制。很多营销文案其实20字就够但模型默认配置可能会输出70到80字导致推理时间翻倍。我们在API层对所有生成任务都设置了max_tokens上限Push文案限制32短信限制48标题限制12。别小看这个调整整体吞吐量提升了接近20%。最后是缓存。同一用户在同一活动周期内点击同一条Push的概率其实很低但同类型用户之间文案相似度很高。我们做了一层语义缓存把用户特征向量活动ID作为key生成结果缓存5分钟。对于高峰期的批量发送场景这个缓存可以拦截大约30%的重复生成请求性价比非常高。5.3 业务指标提升不明显怎么办上线大模型后运营最常问的问题是点击率提升了吗第一个版本我们确实没有达到预期点击率只比原来的模板系统高了0.2个百分点几乎可以忽略。后来复盘发现问题不在模型而在实验设计。原来的模板系统用于点击率比较低的角落渠道而大模型优先接入的却是主Push渠道。主Push本身的点击率基数高用户已经形成习惯几行字的变化对点击影响有限。我们调整策略后先把大模型应用在短信、应用内消息、社交弹窗这些文案敏感型渠道上去做A/B测试效果立刻明显了点击率普遍提升了1到2个百分点。这告诉我们大模型营销不是把每个渠道的文案都替换一遍就完事要找准对内容最敏感的触点。另一个教训是不要频繁更换文案风格。模型生成的文案如果天天变用户会失去辨识度。我们后来固定了每个活动的文案风格候选池只允许模型在5个风格之间选择而不是每次都零样本从头生成。这个约束反而让点击率更稳定因为用户对固定风格产生了预期。如果你的业务也遇到指标不涨的情况我建议按这个顺序排查第一渠道是否选对了用文案敏感度分析第二实验是否跑够了周期至少两轮完整活动第三模型输出的内容是否和活动目标一致别把促销文案写得像品牌软文第四是否过度依赖模型而忽略了下游的落地页承接。点击率提升不是文案单点的事落地页如果跟不上用户点进来也是跳出。6. 踩坑总结那些文档里不会写的经验最后分享几个文字之外的体会。第一大模型落地营销广告组织协作比技术选型难。算法团队和运营团队需要建立一套共建机制。我们每周做一次案例评审运营把本周他们觉得不好用的生成结果贴出来算法反向拆解是提示词问题、数据问题还是模型问题。这个机制让模型的迭代方向始终贴近业务而不是算法自嗨。如果没有这个机制光靠我们自己在办公室闭门造车可能三个月都摸不透业务侧的真实需求。第二不要试图让模型一步到位取代运营。最理想的状态是模型产出80分的初稿运营用10分钟调优到90分。我们之前的误区是想让模型直接输出95分的成品结果投入了巨大的调优成本边际收益反而很低。后来我们把生成系统定位为超级助理而不是投放决策者运营写文案的时间从每天2小时压缩到20分钟大家满意度大幅提升。工具的价值不是替代人而是帮人节约低效劳动。第三数据安全要前置考虑。营销文案涉及用户手机号、下单记录、行为轨迹等数据大模型服务不能直接接触这些字段的原始值。我们做了严密的脱敏处理所有传入模型的特征都经过映射和泛化比如精确的下单时间会被转换为周末上午这种语义标签手机号从不会出现在Prompt里。另外模型服务的访问控制在虚拟私有网络内部通过网关统一鉴权外部无法直接访问。这块一定要在项目启动时就规划好后期补会极其痛苦。第四关于微调数据的活水问题。模型上线后不是一劳永逸的每周都会有新的优秀案例和失败案例。我们搭了一个案例回流管道每次运营在后台手动修改过模型生成的文案都会自动被记为一条增量样本每周聚合成微调数据。这样模型会越来越熟悉运营的偏好。这个机制虽然简单但坚持做了半年后运营的修改比例从最初的40%降到了大概15%效果是肉眼可见的。现在这套系统已经在货拉拉营销侧稳定运行了一段时间每天生成几万条定制文案覆盖Push、短信、弹窗、外呼话术等多个场景。我们从最开始的写着玩变成了真正能提效的业务工具中间的过程说不上顺利但每一步试错都很有价值。如果你们也在考虑把大模型引入营销体系希望这篇实践记录能帮你少踩几个坑尤其是在数据准备、指标评估和运营协作这几个方向多做一点准备后面会省很多事。