前阵子不少人问我货拉拉这种做同城货运的平台怎么也想起来要用大模型做营销广告了。说实话一开始我们内部也有这个疑问。广告业务本身有一套成熟的规则和工具模板文案、兴趣标签、人群定向用了很多年突然上个大模型到底解决什么问题会不会只是追热点后来真正把这个项目从0到1推上线我才想明白一个道理货拉拉广告场景的核心问题从来不是缺流量或缺工具而是创意供给跟不上投放规模人群理解粗糙到只能靠关键词去猜。这两个问题刚好是大模型的强项。这篇文章我会按一条完整的落地链路来写先讲讲我们为什么判断这个场景值得上大模型再拆技术架构和几个核心模块的实战细节包括提示词设计、微调、流式输出、效果实验、成本与安全最后聊一些不太会写进汇报材料里的经验教训。内容尽量说人话适合正在做大模型营销方向或者想搞清楚广告场景怎么落地的朋友参考。1. 为什么是货拉拉把广告场景的脏活累活先摊开看1.1 货运用户的决策链路和电商冲动消费完全不一样货拉拉的平台服务包括同城货运、跨城货运、搬家、企业物流等用户找车的行为有一个非常明显的特点决策短、目标明确、场景碎片化。比如一个用户搬家他可能今天下午就要用车在意的是有没有大面额优惠、司机多久能到、能不能搬运大件一个批发市场的商户要发货他在意的是能不能马上接单、车型对不对、费用怎么算。这和电商场景里逛着逛着就买了完全不同广告文案必须直击当时的即时需求。这就带来一个麻烦同一套文案模板放在深圳搬家场景和杭州商户发货场景效果差距很大。用户刷到一条同城货运低至X元的广告搬家用户关心的是有没有人帮忙搬商户关心的是能不能装下这批货。货拉拉本身覆盖的城市多、业务线多加上司机端招募、企业版、搬家、跑腿等不同业务都有投放需求创意要做的细分组合非常多。1.2 营销团队最真实的四类痛点项目立项之前我们花了两周时间把营销广告相关的同事全部聊了一遍把痛点归纳成四类创意供给瓶颈每个城市、每条业务线、每类人群都需要对应文案和素材。运营同学手动写一天最多出几十条还要做A/B测试经常是测试还没做完活动已经下线了。素材制作更慢一张banner从需求提出到设计返稿通常要一到两天。人群圈选靠规则原有的标签体系里面搬家意向人群基本靠用户搜索过搬家拉货这类关键词来圈但用户真实表达往往是周末要从宝安搬到南山东西有点多这种自然语言描述传递的意图规则标签根本覆盖不了。投放策略调优滞后广告出价和人群预算的调整依赖运营的经验判断数据反馈快则几小时慢则一天等发现某个组合效果差再手动调整预算已经花了不少。复盘分析太占人力每轮投放结束后团队需要人工看报表分析哪个渠道、哪类素材、哪个人群效果最好。数据量大、维度多运营同学大部分时间花在从数据里找结论而不是做决策。这四类痛点出来之后结论其实很清晰不是每一条都要用大模型解决优先级应该是创意生成和人群意图理解这两个是纯文本/语义问题大模型最擅长投放调优和复盘分析作为配套能力可以逐步建设。这样就避免了给所有问题都套上大模型的伪需求陷阱。2. 技术架构大模型在营销链路里的三个落位点2.1 整体思路不是做一个聊天机器人而是把大模型嵌进生产链路我们最终搭建的架构不是很多人想象中那种运营同学打开一个对话框让大模型帮写文案的单点工具而是把大模型拆成三个服务模块分别落在创意生产、人群理解、投放复盘三个环节上。第一个模块叫创意大脑负责广告文案生成、素材文案改写、落地页标题生成。它在离线批量任务和在线实时生成两种模式下工作离线场景下每天凌晨批量生成第二天的广告文案候选池在线场景下当某个用户命中实时营销事件系统在几百毫秒内动态生成个性化文案。第二个模块叫人群理解中枢负责把用户产生的非结构化文本比如搜索词、浏览记录、订单备注转换成结构化的投放标签。这个模块需要私有化部署因为它涉及用户行为数据不能随便走外部接口。第三个模块叫复盘助手负责把历史投放数据沉淀成语义向量存进向量数据库。运营同学用自然语言提问比如上个月深圳搬家业务的广告哪类素材转化最好系统通过向量检索加部分结构化查询返回结论和建议。2.2 模型选型的分层策略选型的时候我们定了两条原则第一在线链路尽量私有化部署因为latency和数据安全都不允许每次都调用外部API第二离线批量任务可以用性能更强的模型甚至允许少量使用云端API因为不涉及实时交互。具体选型上文案生成走的是偏中大规模的开源模型这里不写具体型号免得被当软广量化后部署在带GPU的集群上标签抽取和意图理解用稍小一号的模型尤其是在线请求量大的场景小模型速度快效果也够用复盘助手因为要处理长文本和复杂查询对语义理解要求高用的模型能力更强但处理的是离线和异步任务慢一点也可以接受。这套分层方案实施之后我们最大的感受是不要试图用一个模型解决所有问题。大模型的能力边界差异很大在广告场景里效果和速度往往要做一个清晰的取舍。2.3 统一模型网关所有广告业务方都走同一个入口三个模块不是零散地接给下游系统而是统一封装成一个模型网关服务。网关对外提供API内部做了路由、权限、限流、缓存、降级。广告投放系统、消息推送系统、运营平台都只需要对接网关不需要关心模型部署在哪、用什么框架。网关层的价值我们在上线第二周就体会到了。某一天在线生成接口的调用量突然涨了三倍如果每个业务方直连模型即时模型扛得住也会因为互相争抢资源导致响应变慢。有了网关我们可以在网关层把非核心任务的调用降级为返回缓存结果优先保障在线个性化文案的响应速度。广告系统这种高并发业务流量治理比模型本身效果更能决定生死。3. 文案生成的实战细节提示词架构、知识注入与效果约束3.1 结构化提示词让大模型从会写到写得对很多团队刚开始做文案生成都会遇到一个现象模型写出来的文案语句通顺但完全不能用。不是语法不对而是不落地——它不知道货拉拉的品牌调性不知道广告法有哪些极限词不能碰不知道不同城市的用户关注点完全不同。我们的解法是设计一套结构化的提示词模板把文案生成任务拆解成固定字段。以搬家业务为例最基本的模板长这样你是一位熟悉同城货运行业的资深广告文案专家。请根据以下结构化信息生成一条推广文案 业务线搬家 目标城市深圳 目标人群25-35岁近期需跨区搬家的上班族 核心卖点新用户首单立减、司机最快5分钟接单、可搬运大件家具 投放渠道App消息推送 文案字数30字以内 风格要求口语化、有紧迫感、避免夸张承诺 合规要求不得出现最便宜第一名100%准时等绝对化用语价格信息必须使用低至起等表述 输出格式直接输出一条文案不要解释。这套模板看起来简单但调参过程里我们踩过一个坑字段越多模型越容易在某个字段上忽略指令尤其是字数限制和合规要求。后来我们加了几个技巧一是把最重要的约束放在system prompt里并且用负面清单的方式写清楚不得出现……二是把历史上验证过效果好的文案作为few-shot示例拼在prompt里让模型模仿语感三是设置输出格式约束要求模型只输出最终文案不要带解释减少解析成本。3.2 从Prompt到微调什么场景值得投入LoRAPrompt调优能覆盖80%的通用场景但总有那么一些细分场景怎么调都差口气。比如货拉拉的企业版业务目标客户是B端商户文案需要更专业、更强调物流效率而通用模型的默认语感偏C端。又比如司机端招募广告目标人群是货拉拉司机文案要突出收入稳定平台单量充足但大模型生成的文字经常显得太画饼缺乏真实感。这些场景的共同点是有大量历史优质文案沉淀但分布和通用语料差异大。我们为此规划了LoRA微调。数据来自过去两年运营实际投放中点击率和转化率较高的历史文案清洗后大概攒了几万条每条包含业务线、城市、目标人群、文案正文。微调时只更新LoRA适配器基座模型权重冻结单卡即可完成训练。微调完成后再用同样提示词跑一遍测试集明显感觉到输出更贴业务调性了。但我也想提醒微调不是越多越好做之前先确认Prompt确实调不动了。LoRA微调会引入模型版本管理、数据回流、效果回归等一系列问题小团队贸然上微调很容易陷入调完一个场景另一个场景效果又掉了的循环。3.3 让大模型自动审稿合规不靠自觉靠流水线广告文案有一个硬约束合规审查。货拉拉的广告涉及价格、服务范围、时效承诺出问题就是虚假宣传另外广告法对绝对化用语查得很严。大模型生成内容天然有幻觉属性所以我们从一开始就明确不管模型生成能力多强审核环节不能省但可以用模型加速审核。我们做的第一层是规则审核内置一份敏感词、极限词、竞品词词典命中即拦截第二层是模型审核把生成的文案丢给一个小模型做文本分类判断是否存在违规风险第三层是人工抽检按一定比例抽看。三层下来违规文案才被真正拦截的概率已经非常低运营审核的人力从逐条看变成了看异常告警。这个流程上线后我们甚至反哺了生成环节把规则审核结果作为负样本回填到生成模型里让模型在生成阶段就主动避开违规表达。比如它知道最低价不能用会自动换成特惠价起步价低至这类合规表述。这比靠审查机制被动拦截要省事得多。4. 实时性这件大事广告系统接入大模型的延迟治理4.1 同步调用的痛一次文案生成拖垮整个投放编排广告场景对延迟的要求比很多人想象中苛刻。比如用户触发了一个营销弹窗从触发到展示留给我们的时间往往只有500毫秒。而大模型生成一句文案即便是量化部署的小模型首token返回也要几百毫秒全量生成一个短句通常要两三秒。如果走同步调用投放系统会被拖垮。我们最初上线时有一个业务场景就是同步等待模型返回结果接口超时率一度高达20%。监控图表拉出来后我们做了个决定在线强时效场景永远不直接同步调大模型除非你已经做好了缓存和降级方案。4.2 流式输出落地SSE协议下的任务分发与结果聚合对于某些在线但不要求秒回的场景比如运营后台的实时文案生成、部分Web端编辑器的辅助写作我们引入了SSE流式输出。这个技术本身不复杂核心就是通过HTTP长连接把大模型生成的token一个个推给前端前端逐字渲染用户体感是模型在边想边写比转圈等待舒服很多。但广告投放系统跟编辑器不一样它需要拿到完整文案后才能做合规审核、拼装落地页URL、走投放编排。所以我们在架构上做了个折中首包优先策略——模型先输出一个符合基本要求的短句作为种子文案马上返回给投放系统去跑流程后续输出的备选文案再通过异步回调写入候选池供下一轮使用。这样既保住了时效又把大模型的生产力全部用上了。还有一点容易踩坑SSE连接是长连接在广告这种高并发场景下如果不做连接管理大量半开连接会占满服务端资源。我们的做法是给SSE请求设置超时时间并在网关层做并发限制超过阈值的请求直接走缓存或降级路径。4.3 模型网关层缓存、降级与并发控制延迟治理的另一半是流量治理。广告业务的流量峰值非常集中比如大促活动一开闸瞬间可能有几十万次营销触达请求。模型再快也扛不住这种突发流量必须在网关层做文章。我们设计了三级缓存第一级是短文案缓存命中率大概在20%到30%因为同一个城市、同一个业务线、同一个活动期的组合经常重复第二级是语义相似缓存把用户请求转成向量后做最近邻检索相似的请求可以复用近似结果第三级才是真正调用模型。降级策略也预设了几档模型超时自动返回规则模板文案、模型过载自动切换小模型、小模型也扛不住就返回固定的兜底文案。上线运行一段时间后我们统计过一个数据加上缓存和降级最终走到模型推理的请求只占全部请求的一小半而整体p95延迟从近3秒压到了700毫秒以内。这个结果不是靠优化模型推理速度得来的是靠架构设计曲线救国。5. 从生成到投放匹配模型的优化与实验设计5.1 用大模型做用户需求意图抽取替代纯规则标签文案生成得再好如果推送给了错误的人群效果照样很差。这一步我们做了人群理解中枢模块核心任务是把用户的自然语言表达转化成广告系统能用的结构化标签。举个真实例子。以前用户搜索明天搬家到福田规则系统只能识别出搬家这个关键词然后给他打搬家意向标签。大模型的做法是把这句话联合用户的浏览序列和订单历史一起编码输出一个结构化的意图向量包含搬家场景跨城/同城是否有大件时间紧迫度价格敏感度等维度。相比关键词标签这个向量能在语义层面捕捉到虽然用户没直接说搬家但他在连续搜索纸箱、家电回收、小区停车管理费这类隐性强意图。落地时我们特别注意了隐私问题。用户的行为文本进了模型但无论训练还是推理都不能掺入手机号、真实姓名、具体门牌号。我们专门做了脱敏处理把所有个人标识符替换成掩码后再进入模型服务。这一步在合规上很重要我们把它写进了上线检查清单。5.2 A/B测试怎么切割流量才能看出效果模型和策略上线后最难回答的是到底有没有用。广告场景里指标太多CTR、CVR、ROI、拉新成本、留存率而且不同渠道之间的流量质量差异很大。如果A/B测试切分不干净很容易得出错误结论。我们的做法是以用户设备号广告活动为最小单元做分层划分保证同一个用户在一段时间内只会看到同一套策略的内容对照组和实验组的流量比例动态调整初期实验组占10%跑出明显正向结果后再逐步放量到50%同时设置一个刹车机制——如果实验组的核心指标连续三天显著差于对照组系统自动缩量。这里我想重点提一个容易忽略的指标后续自然转化率。大模型生成的内容如果过于同质化短期CTR可能不差但用户看多了会产生审美疲劳后续自然打开率和转化率反而下降。所以A/B测试不能只看投放期的转化还要观察测试窗口结束之后一段时间的自然行为否则你的收益可能是在透支用户注意力。5.3 我们遇到的冷启动与效果回落问题新品上市或新城市开城时没有任何历史投放数据人群标签和文案都无从下手。我们的临时方案是用大模型生成一批地域化种子文案结合地理围栏圈定目标区域小预算快跑同时人工审核每一批文案质量跑出正向样本后再逐步放量。更麻烦的是效果回落。有一段时间我们发现自己非常满意实验组CTR比对照组高了大约10%于是全量上线。结果上线第二周CTR优势缩水到3%左右。复盘下来原因是模型生成的文案高度雷同——同一个活动期系统反复推送句式相近的内容用户的新鲜感下降得很快。后来我们在生成环节加入了多样性控制调整采样温度、设置多套提示词路径、限制同一个文案模板的使用频次才把回落问题压住。这条经验后来写进了团队的操作手册大模型批量生产能力很强大但同质化风险也与生俱来必须从生成源头控制多样性。6. 成本与安全上线一段时间后不得不管的事6.1 单次生成成本预算从GPU占用到token消耗大模型不是免费的广告业务本身就对成本敏感。我们很早就算过一笔账一个文案生成任务带上完整的提示词和few-shot示例输入输出加在一起大概消耗多少token按部署的GPU集群折旧和电力成本折算单次生成的边际成本是多少。再乘以每天的调用量一个月下来就是一笔不小的数字。省钱的办法其实不复杂总结下来是三条减少重复输入把固定不动的system prompt和常量的few-shot拉出来做前缀缓存避免每次请求都重复计算。分层使用模型80%的简单请求用小模型完成只有复杂长文案才上大模型。小模型不够的情况再升级。错峰执行线下批量生成任务全部放到凌晨低峰期跑在线高优先级任务才占白天的GPU资源。这三条做完整体成本大概降了30%到40%效果没有明显衰减。6.2 内容安全与隐私红线广告场景比想象中敏感营销广告的内容安全比很多内部工具更严格因为它直接暴露给海量用户。哪怕是模型生成的一个价格数字如果跟实际活动不一致都可能引发客诉甚至合规问题。我们的做法是引入事实核对环节生成文案里出现的所有服务承诺、价格区间、时效说明都必须从活动配置中心实时拉取真实参数来填充模型只负责写表述方式不负责编造数字。隐私方面前面提到过用户文本要脱敏。除此之外还要注意日志安全模型请求日志里不能明文记录用户ID对应的详细行为序列。我们最初的日志系统会把整个请求体打出来里面包含用户搜索词后来统一改成了脱敏摘要只有标签结果不保留原文。这件事做的时候多花了一点时间但心里踏实很多。6.3 降本小模型先过滤、大模型做精修的分层思路最后说一个我们验证过的降本组合拳用生成式小模型做初稿用评估模型做打分必要时才调用大模型精修。这个思路跟很多人默认的所有内容都要让大模型生成不太一样。实际执行中我们把文案生成任务拆成两段第一段用一个量化的7B级别模型基于规则模板生成初稿速度极快、成本极低第二段用一个分类模型评估初稿质量如果评分超过阈值就直接采用只有评分不达标或属于重点业务线的文案才送到更大规模的模型做重写和润色。运行下来真正走到大模型精修的请求只占三分之一左右而整体文案合格率没有明显下降。这套方案的启发是大模型不应该被当成所有文本任务的默认选择它应该是那个在关键节点把质量兜住的角色。能用规则解决的就用规则能用小模型解决的就用小模型大模型的价值应该放在复杂难题上而不是流水线的每一环。7. 最后说说团队协作和踩过的路如果让我总结这个项目里最重要的经验我不会说是模型选型、提示词调优或者微调技术而是人的协作方式。第一次做这个项目时我们团队满脑子都是用大模型替代运营结果把运营同学搞得很紧张配合度很差。后来换了一种思路大模型先承担生成量大、重复度高的初稿工作运营从写文案的人变成审文案和定方向的人他们的工作量变化不大但成就感完全不同。还有个很务实的建议上线节奏别太急先让一个业务线跑通再横向推广。我们最开始只做了深圳搬家业务的文案生成跑了两个月把提示词、审核流程、效果评估都打磨顺了才逐步推到其他城市和业务线。如果一上来就铺所有场景团队根本忙不过来出了问题也分不清是模型的问题还是流程的问题。最后分享一个小技巧大模型生成内容的线上效果不一定看单次CTR有多高更要看文案与offer的匹配度。模型负责把话说得好听但说得对不对取决于你在提示词里给的事实信息是否真实。把活动配置和运营知识库接进生成环节比堆任何花哨的技巧都管用。这个思路对我们这种做交易撮合的平台来说比单纯追求模型能力上限更值得投入。
