大模型营销文案生成：提示词工程、LoRA微调与私有化部署实践

去年下半年我们团队接到一个很现实的诉求：货拉拉的营销广告物料，靠运营同学手工产出已经撑不住了。促销活动密集的时候，光深圳一个城市就要出三十多套投放素材，还要按司机端、发货端、不同业务线做区分。天花板就摆在那儿——人不可能无中生有写出几百套不重样的卖点话术。所以我们把目光投向大模型，不是去跟风，而是为了解决实打实的产出效率问题。这篇文章我想把从立项到落地这段经历里最核心的东西讲清楚，包括技术选型的取舍、提示词与微调的分工、工程化落地的坑，以及一些只有踩过才知道的细节。

1. 项目背景与整体思路

1.1 先搞清楚业务到底疼在哪

货拉拉的营销广告有一个很容易被外人忽略的特点：它不是传统意义上一句slogan走天下的品牌广告，而是强转化导向的运营投放素材。整个平台横跨司机端和用户端，用户端里又有搬家、拉货、同城配送、企业租车等业务，不同城市、不同时间的运营策略也不同。活动文案里要写清楚"从哪到哪、什么车型、券面金额、使用门槛"，用户没时间看长篇大论，但投放系统又要求物料尽量差异化，这对人工产出是巨大的压力。

我一开始也以为广告文案嘛，让写手多写几版就行。后来开了几次需求评审会才意识到，真正的瓶颈不是"写不出漂亮句子"，而是"满足所有硬约束的同时还要保证数量"。运营同学每周要产出的文案不是几十条，而是几百条，每条还要挂上对应的活动ID、券模板、投放渠道，稍微出点错就影响核销和结算。这不是靠招人就能解决的，因为人的创作带宽是明摆着的上限，加班只能续一时，续不了一个季度。

所以项目立项的第一步，不是选模型，而是把所有需求场景梳理清楚。我们最终划分出三大类：活动落地页文案、投放素材标题与卖点、短视频/图文脚本。每一类的约束条件和可用数据都不一样，后续的提示词模板和技术方案也跟着有差异。这一步做扎实了，后面才不会出现"模型很强但业务用不上"的尴尬。

1.2 为什么大模型在这个场景里能站得住

营销广告本质上是一个语言生成问题，而大模型最擅长的就是语言生成。它能帮你把"拉货搬家"这种功能点，组合成"明码标价、不花冤枉钱"这类行动驱动的表达。再加上平台本身就积累了大量的历史广告文案和对应的投放效果数据，这些都是现成的训练语料，价值极高。

另一个现实因素是技术栈成熟了。开源底座模型已经有了很强的中文表达能力，配合推理框架可以私有化部署，数据不出域，这对含有用户数据特征和业务策略的广告场景非常关键。我见过不少团队纠结"要不要上大模型"，其实这个问题在营销侧早就不是"要不要上"，而是"从哪里切入、怎么控制风险"。货运物流的广告链路足够长、场景足够多，从文案生成这个单点切进去，是最稳、最容易被业务方看到价值的方式。

1.3 选型考量：私有化部署而不是直接调外部API

这个决定我们只讨论了一周就定了。核心原因有三个：数据安全、成本、可控性。广告物料里带着业务策略和价格信息，走外部API等于把家底交给别人，这在技术评审阶段就不可能通过；成本上，按我们日调用量估算，走API的token费用前期看着不高，但一旦要做到"批量生成+多次迭代评测"，账单会非常难看；可控性则是说，外部API版本更新不可控，提示词效果说变就变，我们无法对线上输出做稳定承诺。

最终我们选择基于开源底座模型做私有化部署。训练框架用LoRA做领域微调，推理框架用vLLM做服务化部署，整个链路都在内网完成。选开源模型还有一层考虑：社区活跃、迭代快，出了问题能很快找到人问，这一点在项目排期紧的时候非常救命。

2. 核心技术与方案选型：提示词工程与领域微调

2.1 先做提示词工程，把"下限"拉起来

项目第一阶段，我们用的是未经微调的开源底座模型，只靠提示词工程跑通流程。这么做有两个目的：一是快速验证业务场景到底吃不吃这套，二是积累一批bad case，为后续微调准备数据。很多人一上来就想着微调，我反而觉得应该先把提示词做到位，因为提示词改动成本低、见效快，能帮你在数据层面看清模型的行为边界。

我们设计了一套通用提示词模板，核心结构是"角色定义+任务描述+背景信息+输出约束+少样本示例"。以活动文案为例，大概是这样的格式：

你是一名资深的同城货运平台营销文案专家。 请根据下面的活动信息，生成3条用于投放的广告文案，要求： 1. 突出"拉货搬家"核心场景，行动导向； 2. 必须包含活动优惠信息，但不允许编造价格和券面金额； 3. 避免使用"最高级""第一"等广告法违规词； 4. 每条文案控制在30字以内； 5. 输出JSON数组，每个元素包含"title"和"desc"字段。 活动信息： - 业务线：搬家 - 城市：深圳 - 优惠内容：新用户首单立减30元，满100元可用 - 目标人群：需要搬家但还未使用过平台的新用户 少样本示例： [{"title":"搬家省钱攻略","desc":"新用户首单立减30元，满100可用，点击了解"}, ...]

这段提示词看着简单，实际迭代了很多版。比如"不允许编造价格和券面金额"这句话，最初写得软绵绵的，模型还是会编出一个"立减50元"。后来我们加了一个硬性机制：所有优惠信息在提示词里显式给出，同时在后处理环节做解析和字段匹配，一旦发现输出里的金额和输入不一致，直接丢弃这条结果。另外我们在输出约束里明确要求"只允许输出JSON结构，不要输出任何解释性文本"，等于把模型的自由发挥空间压缩到可控范围内，下游解析也稳定很多。光靠提示词不能彻底解决幻觉，但能大幅压缩出错概率。

温度参数上我们也很保守。文案生成的任务需要一定发散度，但又不能散到脱离业务约束，最终把temperature定在0.7到0.9之间，top_p固定0.9。max_tokens限制在200以内，因为广告文案本身短，给太多token反而容易让模型啰嗦。

2.2 上下文工程的细节：少样本和结构化字段

这里要提一个容易被忽略的点：大模型能不能写好一条文案，很多时候不取决于模型"聪明不聪明"，而取决于你给它的上下文够不够结构化。我们后期把活动信息从自由文本改成JSON输入，效果提升非常明显。模型不需要从一大段自然语言里自己提取"业务线、城市、优惠、人群"，而是直接拿到结构化的键值对，生成时出错概率自然就低了。

少样本示例也很讲究。一开始我们随便从历史文案里选了三条放进去，模型输出的风格一会儿像短促口号，一会儿像公众号推文，飘得不行。后来把示例按"风格标签"分类，比如"价格敏感型"、"效率导向型"、"情感共鸣型"，每次生成时根据活动类型选择对应的示例放入上下文。这样做的效果是，模型至少在格式和语气上稳定住了，人工修改率从第一版的接近80%降到40%左右。

上下文工程还有一个隐性的收益：它帮我们理解了模型的"脾气"。比如模型对"金额一致性"这类约束很敏感，但对"语气要有品牌感"这种模糊要求执行得很差。这直接决定了后续微调时，我们应该在哪些维度上加重训练比例，而不是凭感觉给所有bad case同等权重。

2.3 领域微调：从"通用文案"到"货拉拉风格"

提示词工程把下限拉起来了，但很快我们遇到另一层问题：模型写出来的文案还是"太通用"了，放在任何一家货运、搬家平台好像都成立，没有货拉拉特有的那股"实在、直接、不说虚话"的劲儿。这就是需要领域微调的时候了。

我们选了LoRA做参数高效微调，没有全量微调。原因很实际：一个是显存和训练成本，另一个是LoRA训练出来的权重文件只有几十MB到几百MB，部署和版本管理都方便很多。训练数据来自两个渠道：一是历史投放中点击率排名靠前的文案，二是运营同学手工标注的"优质范文"，总量大概十万条。清洗和处理是耗时的重活，但这一步的价值会在后面被反复放大。

微调参数上我们踩了不少轮才定下来一个相对稳的组合：LoRA rank=16，alpha=32，学习率设成1e-4，batch size是32，训练步数控制在2000步左右。rank不是越大越好，我们试着把rank提到64，训练loss是降得更低了，但生成结果反而出现了一些重复套话，说明在小数据量上过拟合了。学习率太大容易一步跨过最优区域，太小又要熬很久，1e-4配合warmup比例0.1是我们实测下来最稳的。

这里有个心得：微调之后不要急着大改提示词。我们微调完第一版，把同样的提示词直接跑了一遍，输出风格马上就"货拉拉"了，但格式稳定性反而略降。原因很典型——微调数据里字段格式五花八门，模型学偏了。解决办法是把微调数据的格式全部统一成线上提示词里要求的JSON格式，重新训练一轮，格式问题就稳定住了。这算是一个给后来者的重要提醒：微调数据格式必须和推断时保持同一套规范，否则模型会把训练时的格式习惯带到线上。

2.4 效果评估体系

我们从一开始就建立了一个三层评估体系。第一层是规则检查，包括广告法违禁词过滤、价格一致性校验、敏感词清洗、长度检查；第二层是模型打分，直接用底座模型对生成结果和"优质范文"做语义相似度打分，同时用BLEU/ROUGE做参考指标；第三层是运营人工抽检，每周固定抽100条做质量评审，分四个维度打分：合规性、吸引力、信息准确性、品牌风格。

这套评估体系帮我们避了一个大坑：只看BLEU分数会严重高估模型效果。有一版微调模型BLEU分数涨了不少，但人工抽检发现大量文案开头都是"亲，你还在为搬家发愁吗？"这种模板感极强的内容。后来我们明确了一点——对于广告文案，形式上可以雷同，但语气和表达要多样。于是把"句式多样性"也纳入人工评估，并且用文本去重算法对线上生成的文案做了聚类监控。有了这套机制，后续每轮模型迭代都能说清楚"到底哪里变好了，哪里变差了"，而不是靠感觉拍板。

3. 系统架构与工程化落地

3.1 整体链路与模块划分

从工程角度，大模型在营销广告里的落地不是一个"调API生成文本"的简单流程，而是一条完整的数据流水线。我们按五个层级拆：数据层、训练层、推理层、服务层、业务层。

数据层负责汇入历史文案、活动信息、投放效果数据，经过清洗后落入特征表存到内部数据库。训练层跑LoRA微调任务，产出模型权重并做版本管理。推理层用vLLM加载模型，对外提供HTTP接口，支持批量请求。服务层承接业务模块的调用请求，负责做参数组装、结果解析、缓存和后置校验。业务层就是上游的营销系统、投放系统、内容管理系统。

这个拆分看起来像教科书，实际价值在于"每层只操心一件事"。前期我们也想省事，把提示词组装、模型调用、结果清洗全写在一个脚本里，结果上线后改需求非常痛苦。后来花了几天重构，各层独立部署，问题定位和迭代速度都上去了。团队里的新同学过来接手，看架构图十分钟就能知道该去哪一层改代码。

3.2 推理服务与性能优化

推理层我们选了vLLM，核心考虑是它对并发和显存利用的优化比较成熟。模型底座用的是开源中文模型，参数量在7B到14B这一档，量化方案选了AWQ的INT4版本，显存占用比FP16下降了一大截，线上用两张卡就能撑住日常流量，高峰时段做弹性扩容。

部署之前有个参数要特别留意：max model length。广告文案场景的输入输出都不长，但我们最初按照模型默认的4096配置，导致显存被上下文占掉很多。后来根据线上实测把max model length压到2048，输出限制在500 token以内，吞吐直接翻了一倍。这个优化没花一分钱，效果却很实在。

性能优化上我们还做了一道硬缓存。货拉拉的营销活动本身有周期性，同一个活动在多个渠道会重复投放，我们就把"活动信息+提示词版本+温度参数"作为缓存key，对已经生成过的结果做24小时缓存。实测缓存命中率在40%左右，等于白拿了四成的算力红利。缓存之外还有一层降级逻辑：如果模型服务超时或返回异常，直接走模板引擎，用运营维护的静态文案兜底，保证投放不中断。这个兜底在线上出过两次模型服务故障，稳住了业务，那两次之后没人再质疑冗余设计。

3.3 多业务场景复用与审计

模型服务跑通之后，业务方陆续提了很多新需求，比如给素材配标题、给短视频写分镜脚本、给不同的投放渠道生成不同风格的卖点。这些场景共享同一套提示词框架，只是结构不同，服务层加了一些自定义模板字段来兼容。这样做避免了一个场景一套接口，极大降低维护成本。

因为营销广告要接受审计，我们把每次生成的log都做了记录，包括输入的活动信息、用的提示词版本、模型版本、输出结果、人工筛选结果。一旦出现合规问题，可以追溯是哪个环节引起的，这在真实的业务环境里不是可有可无的功能，而是必须项。尤其是广告物料会直接触达用户，出了问题不是删掉重发就能解决的，留痕是对自己的一种保护。

4. 踩坑实战与调优经验

4.1 幻觉问题：广告文案不能"编"

这是整个项目里最让我头大的问题。大模型生成文本本来就容易一本正经地胡说八道，放在广告场景里就变成了灾难：明明活动只写了"首单立减30元"，模型能给你来个"新老用户通用，下单即送50元券"；明明线路上说"从A点到B点"，模型非要加上"免费上门安装"。这些内容一旦投出去，用户按着错误信息下单，核销对不上账，客服就要被骂死。

我们用了三层防护。第一层从生成端控制：提示词里把所有优惠信息结构化写明，并明确要求"输出必须只使用输入中提供的信息"；第二层从后处理控制：写一个字段校验器，把模型输出解析成JSON，逐一对比金额、城市、业务线、优惠门槛这些关键字段，对不上就丢弃重试；第三层从数据控制：在微调数据里刻意加入大量"只呈现给定信息"的负样本，强化模型的边界感。三层叠加之后，幻觉导致的信息错误从最初的每个月几十例降到了个位数。

这里想多说一句：别指望任何一层单独解决问题。提示词能约束方向，但挡不住模型自由度；后置校验能拦截错误，但拦截了之后要重试，重试次数多了延迟就上去了；负样本则是在模型行为层面降低出错概率。只有三层配合，才能同时兼顾生成质量和系统稳定性。

4.2 成本与延迟的平衡

大模型应用的账单往往不是来自单次调用，而是来自迭代和无效调用。我们做过统计，模型生成结果后，有接近30%的输出会因为亮红灯被后端校验拦截，如果每次都正常计费，就等于烧掉了三成预算。为此做了两件事：第一，把校验前置到提示词层，增加"只输出合规字段"的指令，同时让模型以JSON格式输出，结构化解析效率更高；第二，对高频活动做结果缓存，并把人工确认过的优质结果回灌到样本库，后续生成直接优先复用。

延迟方面，我们一开始被业务方吐槽"生成一条文案要等三秒"。排查后发现瓶颈根本不在模型，而在服务层的JSON解析和后置校验里做了大量正则循环。后来把解析和校验逻辑改用并发执行，再对结果做批量合并，P95耗时从2.8秒降到900毫秒左右。这个案例也说明，很多性能问题不是模型本身慢，而是工程实现绕了远路。排查延迟问题时先画调用链，别急着怪模型。

4.3 效果回归体系

项目上线后，我们最担心的不是模型跑不起来，而是"模型跑得好不好"说不清楚。于是搭了一套效果回归体系，核心指标分两类：过程指标和业务指标。过程指标包括生成覆盖率、人工修改率、校验通过率、缓存命中率；业务指标包括投放素材的点击率（CTR）、转化率（CVR）、以及人工审核通过率。

大型营销活动期间，我们会把大模型生成的文案和人工模板做AB测试，分渠道、分人群控制变量。这里有个实际经验：别拿"大模型文案 vs 人工文案"做宏观对比，那很容易被活动类型干扰，要按业务线和目标人群分层，比如"搬家拉货新客"和"企业租车存量客"的文案逻辑完全不同，混在一起评估没有意义。

开始的时候我们遇到过AB结果反复震荡，后来发现原因是实验流量太小，平台本身的流量波动掩盖了文案差异。后来调整成"同一批用户随机分流+同时段同活动投放"，才得到相对可读的数据。最终结论是：大模型文案的CTR整体比人工模板高出8%到15%，但提升幅度在不同业务线之间差异很大——越接近标准化服务，模型优势越明显；越需要强情感共鸣的内容，人工仍有明显优势。这个结论也让我们调整了后续投入方向，把模型重点放在标准化物料上，而不是硬啃所有场景。

5. 数据沉淀与后续演进

5.1 项目效果盘点

项目运行了一段时间后，最直观的变化是生产效率。原来运营同学每周要花十几个小时在文案产出和修改上，现在只需要做最后的审核和少量润色，产出速度提升了将近三倍。统计下来，大模型生成的物料覆盖率已超过70%，人工修改率稳定在30%左右。

各项指标大致是这样的：

我这里想强调一下，表格里的数据不是"大模型吊打人工"，更准确的说法是"大模型把人的精力从繁重琐碎的初稿工作中解放了出来"。运营同学的时间被重新分配到了策略制定和创意策划上，这才是项目带来的真正价值。

5.2 后续演进与几点真实体会

再往后走，我们的规划有三个方向。第一是多模态化，在文案生成的基础上接入图片素材生成和视频脚本生成，让同一个大模型底座能支持"文案+视觉+音频"的完整物料链路；第二是策略智能化，把大模型生成的文案和投放出价、人群定向结合起来，实现"同一活动在不同渠道自动匹配最优物料"；第三是评估自动化，把人工抽检逐步替换成模型打分和规则引擎结合的自动质检系统，进一步释放运营人力。

最后说一点个人体会。做这类项目，别把大模型当成能自动生成一切的魔法盒子，它更像一个想象力放大器：上限很高，但需要用工程手段把下限兜住。真正吃功夫的地方，往往不在炫酷的模型结构，而在于数据怎么清洗、提示词怎么设计、校验逻辑怎么沉淀、线上异常怎么兜底。把这些问题想清楚了，大模型在营销广告里的价值才能真正落地，也更可持续。