1. 电商文案批量生成的项目背景与核心痛点做电商运营的朋友大概率都经历过这种场面大促前两周运营群里甩过来一张Excel表里面躺着三千个SKU要求三天内把每个商品的标题、卖点、详情页首段、短视频脚本全部写完。人工写一个人一天撑死写五十条还得保证质量不下滑这活儿根本干不完。外包一条文案五到十五块三千条就是小两万而且外包团队对产品理解参差不齐返工率极高。这就是电商文案批量生成这个需求最真实的来源——它不是技术团队拍脑袋想出来的伪需求而是被业务量硬生生逼出来的。我最早接触这类项目是在两年前当时帮一个做家居类目的团队搭自动化文案流水线。他们日均上新两百个SKU每个SKU需要至少三套不同风格的文案用于A/B测试。人工团队六个人每天加班到十点产出还跟不上上新的速度。上了大模型批量生成之后六个人缩减到两个人做审核和精修产出反而翻了四倍。这个账算下来人力成本一年省了四十多万而API调用成本一个月不到两千块。这就是为什么我说电商文案批量生成这件事核心不是“能不能用大模型写”而是“怎么用工程化的方式把成本压到最低、把质量稳到最高”。但这里有个误区需要先破掉。很多人一上来就问“哪个大模型写电商文案最好”这个问题本身就问偏了。电商文案批量生成是一个系统工程模型选型只是其中一环。你需要考虑的是批量生成的吞吐量怎么保证不同类目的文案风格怎么控制生成出来的内容怎么自动质检API调用成本怎么随着量级增长而不失控这些问题不解决你就算用最贵的模型产出的也是一堆需要人工逐条修改的废稿。所以这篇文章我会从工程化的角度把整个链路的成本结构、技术选型、实操步骤和踩坑经验全部拆开讲清楚。适合读这篇文章的人有三类一是正在做电商中台或运营工具的技术负责人需要评估自建批量生成系统的可行性二是运营主管想知道大模型批量生成到底能省多少钱、质量能不能过关三是独立开发者或小团队想用最低成本搭一套能跑的文案生成流水线。不管你是哪一类下面的内容都会给你可以直接抄作业的方案。2. 大模型选型与成本结构的深度拆解2.1 模型选型的三个梯队与适用场景电商文案批量生成对模型的要求跟通用对话场景完全不同。它不需要模型跟你聊哲学也不需要它解数学题它需要的是对商品属性的准确理解、对平台文案规范的遵循、以及在大批量调用下的稳定输出。基于这个判断我把市面上能用的模型分成三个梯队。第一梯队是闭源商业API代表是GPT-4o、Claude 3.5 Sonnet、通义千问Max、文心一言4.0这些。它们的优势是开箱即用文案质量高对中文电商语境的理解到位尤其是卖点提炼和场景化描述的能力很强。缺点是贵。以GPT-4o为例输入每百万token约2.5美元输出每百万token约10美元。一条电商文案平均消耗输入200token、输出300token算下来一条文案的成本大约是0.0035美元折合人民币两分五。听起来不贵但你一天生成一万条试试一天就是250块一个月7500块。而且这还没算上你为了控制质量而做的多轮生成和重试。第二梯队是开源模型本地部署代表是Qwen2.5-7B、Llama 3.1-8B、ChatGLM3-6B这些。它们的优势是边际成本趋近于零——部署一次后面生成多少条都不额外花钱。缺点是初始投入高你需要一张至少24G显存的卡比如RTX 4090或者A10硬件成本一万五到三万不等。而且7B级别的模型在电商文案这种需要一定创造力的任务上质量跟GPT-4o有明显差距容易出现套话、重复、对产品属性理解偏差等问题。我实测下来Qwen2.5-7B在标准化的商品标题生成上能打到GPT-4o的八成水平但在详情页长文案和短视频脚本上只能打到六成。第三梯队是国产轻量API代表是DeepSeek-V3、零一万物Yi-Large、百川Baichuan4这些。它们的价格介于前两者之间DeepSeek-V3的输出价格大约是每百万token一块钱人民币一条文案的成本不到一厘。质量上DeepSeek-V3在中文电商文案场景下表现相当能打我甚至觉得在某些类目上比GPT-4o更懂中国消费者的语言习惯。缺点是高峰期偶尔限流批量调用时需要做好重试和降级策略。我的建议是日生成量在五千条以下的直接用DeepSeek-V3或通义千问Turbo的API省事且成本可控日生成量在一万到五万条的考虑混合方案——用开源模型做初筛和标准化标题生成用商业API做高价值SKU的详情页文案日生成量超过五万条的必须上本地部署否则API成本会吃掉你所有的利润空间。2.2 成本结构的完整拆解与计算公式很多人算大模型成本只算token钱这是典型的漏算。完整的成本结构应该包括四块模型调用成本、工程基础设施成本、人工审核成本和失败重试成本。模型调用成本的计算公式是单条成本 (输入token数 × 输入单价 输出token数 × 输出单价) × (1 重试率)。重试率这个参数很关键因为批量生成时模型偶尔会输出格式错误、内容违规或质量不达标的结果你需要重新生成。实测下来不做任何约束的自由生成重试率在15%到25%之间加了格式约束和few-shot示例之后能压到5%以下。工程基础设施成本包括服务器、数据库、消息队列、监控告警这些。如果你用云服务一台4核8G的ECS一个月大概两百块RDS和Redis加起来一百五消息队列五十总共四百块左右。如果你用本地部署模型还要加上GPU服务器的电费和折旧一张4090满载功耗450W一天跑十小时就是4.5度电按商业电价一块二算一天五块四一个月一百六。人工审核成本是最容易被低估的。即使模型生成质量达到95%剩下5%的废稿也需要人工挑出来。按一天一万条算5%就是五百条一个审核员一天能看两千条你需要四分之一个审核员月薪六千的话就是一千五。但如果你不做自动质检让审核员逐条看一万条那就需要五个人月薪三万。所以自动质检模块的价值就在这里——它能把人工审核量从100%压到5%到10%。失败重试成本等于模型调用成本乘以重试率。假设单条成本两分五重试率10%那一万条的重试成本就是二十五块。看起来不多但如果你日生成量是十万条重试成本就是两百五一个月七千五这就不是小钱了。综合下来一个日生成一万条电商文案的系统月成本大概是这样模型调用DeepSeek-V3约三百块基础设施四百块人工审核一千五重试成本七十五块总计约两千三百块。平均一条文案两毛三。对比外包一条五到十五块成本降低了95%以上。2.3 批量生成的吞吐量瓶颈与优化思路批量生成跟单条生成完全是两码事。单条生成你等三秒就等三秒批量生成你等三秒乘以一万条就是八个小时这还没算上API的并发限制。所以吞吐量优化是工程化的核心命题。第一个瓶颈是API的并发限制。大部分商业API对免费用户限制在每分钟3到5次请求付费用户能到每分钟60到500次不等。如果你要一分钟生成一千条就需要至少两个并发通道。解决方案是用异步请求加连接池Python里用aiohttp或者httpx的AsyncClient配合asyncio.Semaphore控制并发数。我实测下来用asyncio.Semaphore(50)配合DeepSeek-V3的API一分钟能稳定生成八百到一千条。第二个瓶颈是模型推理速度。本地部署的7B模型在4090上用vLLM推理开启连续批处理continuous batching之后吞吐量能到每秒五十到八十个token。一条文案平均三百个输出token那就是每秒能生成0.2到0.27条。一万条需要十到十四个小时。这个速度对于日更一万条的需求来说勉强够用但如果你想更快就需要上多卡或者用更小的模型。第三个瓶颈是数据库写入。一万条文案的写入如果逐条insert数据库分分钟就跪了。解决方案是用批量插入每五百条一个批次配合连接池和事务控制。MySQL的话用INSERT INTO ... VALUES (...), (...), ...的语法PostgreSQL用COPY命令MongoDB用insertMany。实测批量插入比逐条插入快二十倍以上。这里有个坑要注意批量插入时如果单批次太大比如超过一千条可能会触发数据库的max_allowed_packet限制。MySQL默认是4MB一条文案按2KB算一千条就是2MB加上SQL语句本身的开销很容易超。建议单批次控制在三百到五百条或者调大max_allowed_packet参数。3. 工程化落地的完整技术方案3.1 系统架构设计与模块划分一个能扛住日生成万条级别的电商文案批量生成系统架构上至少需要六个模块任务调度模块、Prompt模板管理模块、模型调用模块、自动质检模块、数据存储模块和监控告警模块。任务调度模块负责接收运营提交的SKU列表拆分成小批次分配给不同的模型调用通道。我推荐用Celery做分布式任务队列Redis做broker。每个SKU生成任务作为一个独立的task这样可以并行执行而且某个task失败了不影响其他task。Celery的chord和group原语特别适合这种“批量执行然后汇总”的场景。Prompt模板管理模块是整个系统的灵魂。电商文案不是让模型自由发挥而是要在严格的框架内生成。你需要为每个类目、每个平台、每种文案类型标题、卖点、详情页、短视频脚本分别维护Prompt模板。模板里要包含角色设定、任务描述、输出格式约束、few-shot示例、以及商品属性占位符。我习惯用Jinja2来渲染模板因为它的语法灵活支持条件判断和循环方便处理不同类目的差异化需求。模型调用模块要支持多模型路由。比如标题生成走DeepSeek-V3详情页生成走GPT-4o短视频脚本走本地Qwen2.5-7B。路由策略可以基于类目、文案类型、成本预算来动态调整。这个模块还要实现重试机制、限流控制和降级策略。重试用tenacity库限流用令牌桶算法降级就是当主模型不可用时自动切换到备用模型。自动质检模块是降低人工成本的关键。它要做四件事格式校验检查输出是否符合JSON或Markdown格式、长度校验标题不超过60字符卖点不超过200字符、违禁词过滤用AC自动机做敏感词匹配、以及质量打分用一个小模型或者规则引擎给文案打分低于阈值的打回重生成。我实测下来加了自动质检之后人工审核量从100%降到了8%左右。数据存储模块要分冷热两层。热数据是最近七天的生成记录存在MySQL或PostgreSQL里方便运营查询和修改。冷数据是七天以上的历史记录归档到对象存储或者ClickHouse里用于后续的数据分析和模型微调。监控告警模块用Prometheus加Grafana监控指标包括生成成功率、平均耗时、重试率、各模型调用量、成本消耗。告警规则设好阈值比如成功率低于95%就发钉钉通知。3.2 Prompt工程的核心技巧与模板设计电商文案批量生成的质量七成靠Prompt三成靠模型。我见过太多团队花大价钱买了GPT-4o的API结果Prompt写得跟闹着玩似的生成出来的文案还不如实习生写的。Prompt工程在批量场景下有几个核心技巧。第一个技巧是角色锚定。不要跟模型说“帮我写一个商品标题”要说“你是一个有十年经验的天猫运营专家擅长用简洁有力的语言提炼商品核心卖点你的文案风格是直接、有冲击力、符合平台调性”。角色锚定能让模型的输出风格更稳定减少随机性。我实测下来加了角色锚定之后同一批次文案的风格一致性提升了40%以上。第二个技巧是输出格式强约束。批量生成最怕的就是模型自由发挥有的输出JSON有的输出纯文本有的还给你加一段解释。你需要在Prompt里明确要求“只输出JSON格式不要任何额外说明”并且给出JSON的schema示例。如果模型还是偶尔跑偏可以在调用API时用response_format参数强制指定JSON模式OpenAI和DeepSeek都支持这个参数。第三个技巧是few-shot示例的动态注入。不同类目的文案风格差异很大卖女装的文案要感性、有画面感卖数码产品的文案要理性、有参数支撑。你可以在Prompt模板里预留一个examples占位符根据SKU的类目动态注入三到五个同类目的优秀文案示例。这些示例可以来自历史高转化文案也可以人工标注。实测下来动态few-shot能让生成质量提升一个档次尤其是对中小模型来说效果更明显。第四个技巧是负面约束。告诉模型“不要做什么”有时候比“要做什么”更重要。比如“不要使用‘震撼’‘炸裂’‘绝绝子’这类过度夸张的词汇”“不要编造商品没有的功能”“不要使用疑问句开头”。负面约束能有效降低违禁词触发率和虚假宣传风险。下面是一个我实际在用的女装类目标题生成Prompt模板用Jinja2语法写的你是一个有十年经验的天猫女装运营专家擅长用简洁有力的语言提炼商品核心卖点。 你的文案风格是感性、有画面感、突出穿着场景、符合25-35岁都市女性的审美。 任务根据以下商品属性生成3个不同风格的商品标题。 每个标题不超过30个汉字必须包含核心卖点和至少一个穿着场景。 商品属性 - 品类{{ category }} - 材质{{ material }} - 风格{{ style }} - 核心卖点{{ selling_points }} - 适用场景{{ scenarios }} 参考示例 {% for example in examples %} - {{ example }} {% endfor %} 输出要求 1. 只输出JSON数组不要任何额外说明 2. 每个元素包含title和style两个字段 3. style字段标注该标题的风格类型如场景型、卖点型、情感型 负面约束 - 不要使用“震撼”“炸裂”“绝绝子”等过度夸张词汇 - 不要编造商品没有的功能 - 不要使用疑问句开头这个模板我跑了大概五万条女装标题人工抽检的合格率在92%左右比不用模板的自由生成高了三十多个百分点。3.3 批量生成的异步调用与并发控制批量生成的核心技术难点在于并发控制。你既要把吞吐量拉满又不能把API打挂或者触发限流。Python里做异步批量调用我推荐用asyncio加aiohttp的组合比多线程更轻量比多进程更好管理。先讲并发数的确定。并发数不是越大越好你要考虑三个约束API的QPS限制、你的网络带宽、以及下游数据库的写入能力。以DeepSeek-V3为例付费用户的QPS限制大概是50到100那你的并发数设成50到80比较合适。设太高会触发429错误设太低吞吐量上不去。我一般会先设一个保守值比如30然后逐步往上加观察错误率和响应时间找到那个拐点。代码结构上我会把整个批量生成拆成三个阶段准备阶段、生成阶段、落库阶段。准备阶段从数据库读取待生成的SKU列表渲染Prompt模板组装成请求参数。生成阶段用asyncio.gather并发调用API每个请求包在try-except里失败的重试三次。落库阶段把生成结果批量写入数据库。import asyncio import aiohttp from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) async def generate_one(session, semaphore, prompt, api_key): async with semaphore: async with session.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.7, max_tokens: 500, response_format: {type: json_object} } ) as resp: if resp.status 429: raise Exception(Rate limited) result await resp.json() return result[choices][0][message][content] async def batch_generate(prompts, concurrency50): semaphore asyncio.Semaphore(concurrency) async with aiohttp.ClientSession() as session: tasks [generate_one(session, semaphore, p, API_KEY) for p in prompts] results await asyncio.gather(*tasks, return_exceptionsTrue) return results这段代码的关键点有三个一是用Semaphore控制并发数二是用tenacity做指数退避重试三是用return_exceptionsTrue让单个任务的失败不影响整体。实测下来并发50的情况下一万条文案的生成时间在十二到十五分钟平均每分钟七百条左右。这里有个细节要注意aiohttp的ClientSession要复用不要每个请求都新建一个session。新建session的开销很大而且容易导致连接泄漏。正确的做法是在batch_generate外面创建session然后传给每个task。3.4 自动质检与人工审核的衔接策略自动质检模块的设计目标是把人工审核量压到最低同时保证漏网之鱼尽可能少。我的策略是三层过滤第一层是硬性规则过滤第二层是模型打分第三层是人工抽检。硬性规则过滤包括格式校验JSON能不能解析、长度校验标题是否超过平台限制、违禁词过滤是否包含广告法禁用的绝对化用语、重复度校验跟同批次其他文案的相似度是否超过阈值。这一层能过滤掉大概60%的明显废稿。模型打分是用一个小模型比如BERT或者Qwen2.5-1.5B给文案的质量打分分数范围0到1。打分维度包括与商品属性的相关性、语言流畅度、卖点突出程度、是否有编造信息。低于0.6分的打回重生成0.6到0.8分的标记为待审核0.8分以上的直接通过。这一层能再过滤掉25%左右的低质量文案。人工抽检是对通过前两层的文案按5%到10%的比例随机抽样由运营人员审核。如果抽检合格率低于90%说明自动质检的阈值设得太松需要调紧如果高于98%说明阈值太严可以适当放宽以降低重试成本。这个反馈闭环很重要能让系统持续优化。三层过滤下来最终需要人工逐条审核的文案大概只占总量的5%到8%。按日生成一万条算就是五百到八百条一个审核员半天就能搞定。4. 实操过程中的常见问题与排查技巧4.1 模型输出格式不稳定的排查与解决批量生成最让人头疼的问题就是模型输出格式不稳定。你明明在Prompt里写了“只输出JSON”它偏偏给你加一段“好的以下是为您生成的文案”然后再跟JSON。这种问题在批量场景下是灾难性的因为你的解析代码会直接报错整批任务都得重跑。排查这个问题的第一步是确认你用的API是否支持response_format参数。OpenAI、DeepSeek、通义千问都支持JSON模式开启之后模型会强制输出合法JSON。如果你的模型不支持这个参数那就需要在Prompt里把格式约束写到极致。我的做法是在Prompt的最后一段单独写“输出格式要求”用大写字母和加粗标记比如“只输出JSON数组不要任何解释性文字不要使用Markdown代码块包裹”。如果还是偶尔跑偏可以在解析层做容错。用正则表达式先把JSON部分提取出来再解析。比如用re.search(r\[.*\], text, re.DOTALL)把方括号之间的内容抠出来。这个正则能处理大部分“JSON外面包了一层废话”的情况。还有一个坑是模型输出的JSON里包含非法字符比如中文引号、换行符没转义、或者尾随逗号。Python的json.loads对这些很敏感直接报错。解决方案是用json5库代替标准库json5对尾随逗号和单引号更宽容。或者用demjson3它的容错能力更强。我踩过最坑的一次是模型在JSON字符串里输出了未转义的双引号导致解析直接失败。后来我在Prompt里加了一条“字符串值内如需使用引号请使用中文引号”这个问题就再也没出现过。4.2 API限流与超时问题的应对策略API限流是批量生成绕不过去的坎。你并发开高了API返回429并发开低了吞吐量上不去。我的应对策略是动态并发调整加多通道轮询。动态并发调整的思路是初始并发设一个保守值比如20每完成一百个请求统计一次错误率。如果错误率低于1%并发数加5如果错误率高于5%并发数减10。这样系统能自动找到当前API的最优并发点。实现上用asyncio的Queue加一个控制协程来动态调整Semaphore的值。多通道轮询是准备多个API Key或者多个模型供应商当一个通道被限流时自动切换到下一个。比如你同时有DeepSeek和通义千问的API可以做一个简单的轮询器每个请求轮流走不同的通道。这样单个通道的QPS压力就降下来了。如果预算充足还可以混用不同供应商的API进一步分散风险。超时问题相对好处理。aiohttp的ClientSession可以设置timeout参数我一般设成30秒。超过30秒没响应就取消请求走重试逻辑。重试三次还失败就标记为失败任务写入死信队列后续人工处理或者换模型重跑。4.3 成本失控的预警与优化手段成本失控通常发生在两个环节一是重试率过高导致token消耗翻倍二是模型选型不当导致单条成本过高。预警机制上我会在监控系统里设三个阈值日成本超过预算的80%发警告超过100%发严重警告并自动降级到便宜模型超过150%直接暂停任务并通知负责人。优化手段有几个立竿见影的。第一是压缩Prompt长度。很多团队的Prompt写得又臭又长光角色设定就五百字few-shot示例塞了十个。实际上角色设定两百字足够few-shot示例三到五个最佳。Prompt每压缩一百token一万条就能省一百万个输入token按DeepSeek的输入价格算就是一块钱。看起来不多但积少成多。第二是缓存高频请求。很多SKU的属性是相似的比如同一款衣服的不同颜色商品描述几乎一样只有颜色参数不同。你可以把商品属性做哈希相同的哈希直接返回缓存结果不用调API。我实测下来缓存命中率能到15%到20%直接省掉这部分成本。第三是分级生成。不是所有SKU都值得用GPT-4o。你可以按SKU的预期GMV或者利润率分级高价值SKU用贵模型低价值SKU用便宜模型或者本地模型。这个策略能让整体成本降低30%到40%而高价值SKU的文案质量不受影响。4.4 常见问题速查表问题现象可能原因排查方法解决方案生成成功率低于90%API限流或网络超时查看错误日志中的状态码分布降低并发数增加重试次数切换备用通道文案质量波动大Prompt约束不够或temperature过高抽检低分文案对比Prompt加强格式约束降低temperature到0.5-0.7成本突然翻倍重试率飙升或模型切换错误检查重试日志和模型路由配置修复重试逻辑确认路由规则数据库写入慢逐条插入或批次太小查看数据库慢查询日志改为批量插入单批次300-500条违禁词漏检敏感词库不完整人工抽检违禁词命中情况补充敏感词库加入变体词和拼音缩写JSON解析失败模型输出格式跑偏打印原始输出内容开启response_format加正则容错解析本地模型推理慢未开启连续批处理查看vLLM日志中的batch size开启continuous batching调大max_num_seqs人工审核量居高不下自动质检阈值太松统计各分数段文案的合格率调高通过阈值增加质检维度5. 从批量生成到质量优化的进阶思路5.1 用历史数据做Prompt的持续迭代批量生成系统上线只是开始真正的功夫在持续迭代。我习惯每周做一次Prompt效果复盘从数据库里拉出上周生成的所有文案按类目分组统计每个类目的合格率、平均质量分、人工修改率。合格率低的类目说明Prompt需要调整。调整的依据来自人工修改记录。运营审核时修改过的文案修改前后的差异就是Prompt的优化方向。比如运营把“修身显瘦”改成了“遮肉不挑身材”说明模型用的词太书面化不够口语化。你把这些修改点整理成规则补充到Prompt的负面约束或者few-shot示例里下一批生成的质量就会有提升。更进阶的做法是用这些修改数据做模型微调。把“原始生成文案”作为输入“人工修改后的文案”作为输出构造训练样本。积累到几千条之后用LoRA在开源模型上做微调。微调后的模型在特定类目上的表现能接近甚至超过GPT-4o而推理成本只有API的十分之一。我帮一个美妆类目的团队做过这个事微调后的Qwen2.5-7B在美妆文案上的合格率从78%提升到了91%而单条成本从两分五降到了几乎为零。5.2 多模态能力的引入与场景扩展电商文案不只是文字主图、详情页、短视频都需要文案配合。现在多模态大模型已经能看图说话了你可以把商品主图直接丢给GPT-4o或者Qwen-VL让它根据图片内容生成文案。这个能力在服装、家居、美妆类目特别有用因为很多卖点是视觉化的比如“显白”“有质感”“版型正”光看文字属性很难写准确但模型看了图就能抓住感觉。我实测过用Qwen-VL根据服装模特图生成卖点效果比纯文本输入好很多。模型能识别出“收腰设计”“V领显脖子长”“面料有垂坠感”这些视觉细节而这些细节在商品属性表里往往没有。当然多模态调用的成本比纯文本高Qwen-VL的图片输入按token计费一张图大概消耗一千到两千token。所以我的策略是只对高价值SKU用多模态普通SKU还是走纯文本。场景扩展上批量生成的能力可以复用到很多地方商品问答的自动回复、客服话术生成、直播脚本生成、站内信营销文案、甚至竞品分析报告。核心逻辑是一样的——把结构化的商品数据加上Prompt模板批量喂给模型自动质检后落库。你把这套流水线搭好了换个Prompt模板就能复用到新场景边际成本极低。5.3 本地部署方案的硬件选型与性能调优如果你决定走本地部署路线硬件选型是第一个要解决的问题。我的建议是根据你的日生成量来倒推。日生成一万条每条平均输出300token总输出量是三百万token。7B模型在4090上用vLLM推理吞吐量大概是每秒六十个token一天跑十小时就是两百一十六万token。不够。你需要两张4090或者一张A100 40G。两张4090的吞吐量能到每秒一百二十个token一天十小时就是四百三十二万token足够覆盖一万条的需求还有余量做重试。如果预算有限可以考虑用量化模型。Qwen2.5-7B的GPTQ 4bit量化版本显存占用从14G降到5G一张4090能同时跑两个实例吞吐量翻倍。代价是质量会有轻微下降实测合格率降低三到五个百分点。对于标题生成这种相对简单的任务量化模型的损失可以接受对于详情页长文案建议还是用全精度模型。性能调优上vLLM是目前最成熟的推理框架。关键参数有三个max_num_seqs控制同时处理的序列数设成64到128比较合适gpu_memory_utilization控制显存占用比例设成0.9tensor_parallel_size控制张量并行的卡数单卡设1双卡设2。开启continuous batching之后吞吐量能比朴素推理提升五到十倍。本地部署还有一个隐性成本是运维。模型更新、依赖升级、GPU驱动兼容性、显存泄漏排查这些都需要专人负责。如果你团队里没有熟悉CUDA和推理框架的工程师我建议还是先用API等量级上来了再考虑本地部署。5.4 成本与质量的动态平衡策略成本和质量的平衡不是一成不变的要根据业务阶段动态调整。冷启动阶段SKU少重点是验证模式直接用最好的模型成本高就高先把流程跑通。增长阶段SKU量上来了开始做模型分级高价值SKU用贵模型普通SKU用便宜模型。成熟阶段积累了大量人工修改数据开始做模型微调用微调后的本地模型替代大部分API调用成本降到最低。我一般会设一个质量底线核心SKU的文案合格率必须高于95%非核心SKU可以放宽到85%。核心SKU的定义可以按GMV、利润率或者战略重要性来定。这个底线决定了你在成本优化上能走多远。如果优化之后合格率跌破底线那就得往回退一步换更好的模型或者加更多人工审核。还有一个策略是A/B测试驱动。同一批SKU生成两套文案一套用贵模型一套用便宜模型上线跑一周看转化率差异。如果差异不显著那就全面切换到便宜模型。我做过好几次这样的测试结果发现对于标品比如日用品、基础款服装贵模型和便宜模型的转化率差异在统计上不显著但对于非标品比如设计师款、高端美妆贵模型的转化率明显更高。所以分级策略是有数据支撑的不是拍脑袋。6. 我个人在实际操作中的几点体会这套批量生成系统我前前后后搭过三版第一版踩了无数坑第二版勉强能用第三版才算顺手。最大的体会是不要追求一步到位。很多人一上来就想搭一个全自动、多模型、带微调的完美系统结果光架构设计就花了一个月代码写了三千行跑起来一堆bug。我的建议是先跑通最小闭环一个模型、一个Prompt模板、一个批量脚本、一个Excel输出。先让运营用起来收集反馈再逐步加自动质检、多模型路由、监控告警这些模块。另一个体会是人工审核不能省。我见过有的团队为了追求全自动把自动质检的阈值设得极松结果生成了一堆看起来通顺但实际有事实错误的文案上线之后被消费者投诉虚假宣传。电商文案涉及广告法、平台规则、消费者权益一旦出问题就是真金白银的罚款。所以哪怕自动质检做到95%的准确率剩下5%也一定要人工过一遍。这个成本不能省也不该省。最后分享一个小技巧把运营的修改记录当成宝贝。每次运营修改文案你都把修改前后的版本存下来。积累三个月你就有了一份高质量的微调数据集。用这份数据微调出来的模型比任何通用大模型都懂你们家的商品和用户。这才是批量生成系统真正的护城河——不是模型本身而是你积累的数据和迭代出来的Prompt资产。
电商文案批量生成：大模型选型、成本优化与工程化落地实战
1. 电商文案批量生成的项目背景与核心痛点做电商运营的朋友大概率都经历过这种场面大促前两周运营群里甩过来一张Excel表里面躺着三千个SKU要求三天内把每个商品的标题、卖点、详情页首段、短视频脚本全部写完。人工写一个人一天撑死写五十条还得保证质量不下滑这活儿根本干不完。外包一条文案五到十五块三千条就是小两万而且外包团队对产品理解参差不齐返工率极高。这就是电商文案批量生成这个需求最真实的来源——它不是技术团队拍脑袋想出来的伪需求而是被业务量硬生生逼出来的。我最早接触这类项目是在两年前当时帮一个做家居类目的团队搭自动化文案流水线。他们日均上新两百个SKU每个SKU需要至少三套不同风格的文案用于A/B测试。人工团队六个人每天加班到十点产出还跟不上上新的速度。上了大模型批量生成之后六个人缩减到两个人做审核和精修产出反而翻了四倍。这个账算下来人力成本一年省了四十多万而API调用成本一个月不到两千块。这就是为什么我说电商文案批量生成这件事核心不是“能不能用大模型写”而是“怎么用工程化的方式把成本压到最低、把质量稳到最高”。但这里有个误区需要先破掉。很多人一上来就问“哪个大模型写电商文案最好”这个问题本身就问偏了。电商文案批量生成是一个系统工程模型选型只是其中一环。你需要考虑的是批量生成的吞吐量怎么保证不同类目的文案风格怎么控制生成出来的内容怎么自动质检API调用成本怎么随着量级增长而不失控这些问题不解决你就算用最贵的模型产出的也是一堆需要人工逐条修改的废稿。所以这篇文章我会从工程化的角度把整个链路的成本结构、技术选型、实操步骤和踩坑经验全部拆开讲清楚。适合读这篇文章的人有三类一是正在做电商中台或运营工具的技术负责人需要评估自建批量生成系统的可行性二是运营主管想知道大模型批量生成到底能省多少钱、质量能不能过关三是独立开发者或小团队想用最低成本搭一套能跑的文案生成流水线。不管你是哪一类下面的内容都会给你可以直接抄作业的方案。2. 大模型选型与成本结构的深度拆解2.1 模型选型的三个梯队与适用场景电商文案批量生成对模型的要求跟通用对话场景完全不同。它不需要模型跟你聊哲学也不需要它解数学题它需要的是对商品属性的准确理解、对平台文案规范的遵循、以及在大批量调用下的稳定输出。基于这个判断我把市面上能用的模型分成三个梯队。第一梯队是闭源商业API代表是GPT-4o、Claude 3.5 Sonnet、通义千问Max、文心一言4.0这些。它们的优势是开箱即用文案质量高对中文电商语境的理解到位尤其是卖点提炼和场景化描述的能力很强。缺点是贵。以GPT-4o为例输入每百万token约2.5美元输出每百万token约10美元。一条电商文案平均消耗输入200token、输出300token算下来一条文案的成本大约是0.0035美元折合人民币两分五。听起来不贵但你一天生成一万条试试一天就是250块一个月7500块。而且这还没算上你为了控制质量而做的多轮生成和重试。第二梯队是开源模型本地部署代表是Qwen2.5-7B、Llama 3.1-8B、ChatGLM3-6B这些。它们的优势是边际成本趋近于零——部署一次后面生成多少条都不额外花钱。缺点是初始投入高你需要一张至少24G显存的卡比如RTX 4090或者A10硬件成本一万五到三万不等。而且7B级别的模型在电商文案这种需要一定创造力的任务上质量跟GPT-4o有明显差距容易出现套话、重复、对产品属性理解偏差等问题。我实测下来Qwen2.5-7B在标准化的商品标题生成上能打到GPT-4o的八成水平但在详情页长文案和短视频脚本上只能打到六成。第三梯队是国产轻量API代表是DeepSeek-V3、零一万物Yi-Large、百川Baichuan4这些。它们的价格介于前两者之间DeepSeek-V3的输出价格大约是每百万token一块钱人民币一条文案的成本不到一厘。质量上DeepSeek-V3在中文电商文案场景下表现相当能打我甚至觉得在某些类目上比GPT-4o更懂中国消费者的语言习惯。缺点是高峰期偶尔限流批量调用时需要做好重试和降级策略。我的建议是日生成量在五千条以下的直接用DeepSeek-V3或通义千问Turbo的API省事且成本可控日生成量在一万到五万条的考虑混合方案——用开源模型做初筛和标准化标题生成用商业API做高价值SKU的详情页文案日生成量超过五万条的必须上本地部署否则API成本会吃掉你所有的利润空间。2.2 成本结构的完整拆解与计算公式很多人算大模型成本只算token钱这是典型的漏算。完整的成本结构应该包括四块模型调用成本、工程基础设施成本、人工审核成本和失败重试成本。模型调用成本的计算公式是单条成本 (输入token数 × 输入单价 输出token数 × 输出单价) × (1 重试率)。重试率这个参数很关键因为批量生成时模型偶尔会输出格式错误、内容违规或质量不达标的结果你需要重新生成。实测下来不做任何约束的自由生成重试率在15%到25%之间加了格式约束和few-shot示例之后能压到5%以下。工程基础设施成本包括服务器、数据库、消息队列、监控告警这些。如果你用云服务一台4核8G的ECS一个月大概两百块RDS和Redis加起来一百五消息队列五十总共四百块左右。如果你用本地部署模型还要加上GPU服务器的电费和折旧一张4090满载功耗450W一天跑十小时就是4.5度电按商业电价一块二算一天五块四一个月一百六。人工审核成本是最容易被低估的。即使模型生成质量达到95%剩下5%的废稿也需要人工挑出来。按一天一万条算5%就是五百条一个审核员一天能看两千条你需要四分之一个审核员月薪六千的话就是一千五。但如果你不做自动质检让审核员逐条看一万条那就需要五个人月薪三万。所以自动质检模块的价值就在这里——它能把人工审核量从100%压到5%到10%。失败重试成本等于模型调用成本乘以重试率。假设单条成本两分五重试率10%那一万条的重试成本就是二十五块。看起来不多但如果你日生成量是十万条重试成本就是两百五一个月七千五这就不是小钱了。综合下来一个日生成一万条电商文案的系统月成本大概是这样模型调用DeepSeek-V3约三百块基础设施四百块人工审核一千五重试成本七十五块总计约两千三百块。平均一条文案两毛三。对比外包一条五到十五块成本降低了95%以上。2.3 批量生成的吞吐量瓶颈与优化思路批量生成跟单条生成完全是两码事。单条生成你等三秒就等三秒批量生成你等三秒乘以一万条就是八个小时这还没算上API的并发限制。所以吞吐量优化是工程化的核心命题。第一个瓶颈是API的并发限制。大部分商业API对免费用户限制在每分钟3到5次请求付费用户能到每分钟60到500次不等。如果你要一分钟生成一千条就需要至少两个并发通道。解决方案是用异步请求加连接池Python里用aiohttp或者httpx的AsyncClient配合asyncio.Semaphore控制并发数。我实测下来用asyncio.Semaphore(50)配合DeepSeek-V3的API一分钟能稳定生成八百到一千条。第二个瓶颈是模型推理速度。本地部署的7B模型在4090上用vLLM推理开启连续批处理continuous batching之后吞吐量能到每秒五十到八十个token。一条文案平均三百个输出token那就是每秒能生成0.2到0.27条。一万条需要十到十四个小时。这个速度对于日更一万条的需求来说勉强够用但如果你想更快就需要上多卡或者用更小的模型。第三个瓶颈是数据库写入。一万条文案的写入如果逐条insert数据库分分钟就跪了。解决方案是用批量插入每五百条一个批次配合连接池和事务控制。MySQL的话用INSERT INTO ... VALUES (...), (...), ...的语法PostgreSQL用COPY命令MongoDB用insertMany。实测批量插入比逐条插入快二十倍以上。这里有个坑要注意批量插入时如果单批次太大比如超过一千条可能会触发数据库的max_allowed_packet限制。MySQL默认是4MB一条文案按2KB算一千条就是2MB加上SQL语句本身的开销很容易超。建议单批次控制在三百到五百条或者调大max_allowed_packet参数。3. 工程化落地的完整技术方案3.1 系统架构设计与模块划分一个能扛住日生成万条级别的电商文案批量生成系统架构上至少需要六个模块任务调度模块、Prompt模板管理模块、模型调用模块、自动质检模块、数据存储模块和监控告警模块。任务调度模块负责接收运营提交的SKU列表拆分成小批次分配给不同的模型调用通道。我推荐用Celery做分布式任务队列Redis做broker。每个SKU生成任务作为一个独立的task这样可以并行执行而且某个task失败了不影响其他task。Celery的chord和group原语特别适合这种“批量执行然后汇总”的场景。Prompt模板管理模块是整个系统的灵魂。电商文案不是让模型自由发挥而是要在严格的框架内生成。你需要为每个类目、每个平台、每种文案类型标题、卖点、详情页、短视频脚本分别维护Prompt模板。模板里要包含角色设定、任务描述、输出格式约束、few-shot示例、以及商品属性占位符。我习惯用Jinja2来渲染模板因为它的语法灵活支持条件判断和循环方便处理不同类目的差异化需求。模型调用模块要支持多模型路由。比如标题生成走DeepSeek-V3详情页生成走GPT-4o短视频脚本走本地Qwen2.5-7B。路由策略可以基于类目、文案类型、成本预算来动态调整。这个模块还要实现重试机制、限流控制和降级策略。重试用tenacity库限流用令牌桶算法降级就是当主模型不可用时自动切换到备用模型。自动质检模块是降低人工成本的关键。它要做四件事格式校验检查输出是否符合JSON或Markdown格式、长度校验标题不超过60字符卖点不超过200字符、违禁词过滤用AC自动机做敏感词匹配、以及质量打分用一个小模型或者规则引擎给文案打分低于阈值的打回重生成。我实测下来加了自动质检之后人工审核量从100%降到了8%左右。数据存储模块要分冷热两层。热数据是最近七天的生成记录存在MySQL或PostgreSQL里方便运营查询和修改。冷数据是七天以上的历史记录归档到对象存储或者ClickHouse里用于后续的数据分析和模型微调。监控告警模块用Prometheus加Grafana监控指标包括生成成功率、平均耗时、重试率、各模型调用量、成本消耗。告警规则设好阈值比如成功率低于95%就发钉钉通知。3.2 Prompt工程的核心技巧与模板设计电商文案批量生成的质量七成靠Prompt三成靠模型。我见过太多团队花大价钱买了GPT-4o的API结果Prompt写得跟闹着玩似的生成出来的文案还不如实习生写的。Prompt工程在批量场景下有几个核心技巧。第一个技巧是角色锚定。不要跟模型说“帮我写一个商品标题”要说“你是一个有十年经验的天猫运营专家擅长用简洁有力的语言提炼商品核心卖点你的文案风格是直接、有冲击力、符合平台调性”。角色锚定能让模型的输出风格更稳定减少随机性。我实测下来加了角色锚定之后同一批次文案的风格一致性提升了40%以上。第二个技巧是输出格式强约束。批量生成最怕的就是模型自由发挥有的输出JSON有的输出纯文本有的还给你加一段解释。你需要在Prompt里明确要求“只输出JSON格式不要任何额外说明”并且给出JSON的schema示例。如果模型还是偶尔跑偏可以在调用API时用response_format参数强制指定JSON模式OpenAI和DeepSeek都支持这个参数。第三个技巧是few-shot示例的动态注入。不同类目的文案风格差异很大卖女装的文案要感性、有画面感卖数码产品的文案要理性、有参数支撑。你可以在Prompt模板里预留一个examples占位符根据SKU的类目动态注入三到五个同类目的优秀文案示例。这些示例可以来自历史高转化文案也可以人工标注。实测下来动态few-shot能让生成质量提升一个档次尤其是对中小模型来说效果更明显。第四个技巧是负面约束。告诉模型“不要做什么”有时候比“要做什么”更重要。比如“不要使用‘震撼’‘炸裂’‘绝绝子’这类过度夸张的词汇”“不要编造商品没有的功能”“不要使用疑问句开头”。负面约束能有效降低违禁词触发率和虚假宣传风险。下面是一个我实际在用的女装类目标题生成Prompt模板用Jinja2语法写的你是一个有十年经验的天猫女装运营专家擅长用简洁有力的语言提炼商品核心卖点。 你的文案风格是感性、有画面感、突出穿着场景、符合25-35岁都市女性的审美。 任务根据以下商品属性生成3个不同风格的商品标题。 每个标题不超过30个汉字必须包含核心卖点和至少一个穿着场景。 商品属性 - 品类{{ category }} - 材质{{ material }} - 风格{{ style }} - 核心卖点{{ selling_points }} - 适用场景{{ scenarios }} 参考示例 {% for example in examples %} - {{ example }} {% endfor %} 输出要求 1. 只输出JSON数组不要任何额外说明 2. 每个元素包含title和style两个字段 3. style字段标注该标题的风格类型如场景型、卖点型、情感型 负面约束 - 不要使用“震撼”“炸裂”“绝绝子”等过度夸张词汇 - 不要编造商品没有的功能 - 不要使用疑问句开头这个模板我跑了大概五万条女装标题人工抽检的合格率在92%左右比不用模板的自由生成高了三十多个百分点。3.3 批量生成的异步调用与并发控制批量生成的核心技术难点在于并发控制。你既要把吞吐量拉满又不能把API打挂或者触发限流。Python里做异步批量调用我推荐用asyncio加aiohttp的组合比多线程更轻量比多进程更好管理。先讲并发数的确定。并发数不是越大越好你要考虑三个约束API的QPS限制、你的网络带宽、以及下游数据库的写入能力。以DeepSeek-V3为例付费用户的QPS限制大概是50到100那你的并发数设成50到80比较合适。设太高会触发429错误设太低吞吐量上不去。我一般会先设一个保守值比如30然后逐步往上加观察错误率和响应时间找到那个拐点。代码结构上我会把整个批量生成拆成三个阶段准备阶段、生成阶段、落库阶段。准备阶段从数据库读取待生成的SKU列表渲染Prompt模板组装成请求参数。生成阶段用asyncio.gather并发调用API每个请求包在try-except里失败的重试三次。落库阶段把生成结果批量写入数据库。import asyncio import aiohttp from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) async def generate_one(session, semaphore, prompt, api_key): async with semaphore: async with session.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.7, max_tokens: 500, response_format: {type: json_object} } ) as resp: if resp.status 429: raise Exception(Rate limited) result await resp.json() return result[choices][0][message][content] async def batch_generate(prompts, concurrency50): semaphore asyncio.Semaphore(concurrency) async with aiohttp.ClientSession() as session: tasks [generate_one(session, semaphore, p, API_KEY) for p in prompts] results await asyncio.gather(*tasks, return_exceptionsTrue) return results这段代码的关键点有三个一是用Semaphore控制并发数二是用tenacity做指数退避重试三是用return_exceptionsTrue让单个任务的失败不影响整体。实测下来并发50的情况下一万条文案的生成时间在十二到十五分钟平均每分钟七百条左右。这里有个细节要注意aiohttp的ClientSession要复用不要每个请求都新建一个session。新建session的开销很大而且容易导致连接泄漏。正确的做法是在batch_generate外面创建session然后传给每个task。3.4 自动质检与人工审核的衔接策略自动质检模块的设计目标是把人工审核量压到最低同时保证漏网之鱼尽可能少。我的策略是三层过滤第一层是硬性规则过滤第二层是模型打分第三层是人工抽检。硬性规则过滤包括格式校验JSON能不能解析、长度校验标题是否超过平台限制、违禁词过滤是否包含广告法禁用的绝对化用语、重复度校验跟同批次其他文案的相似度是否超过阈值。这一层能过滤掉大概60%的明显废稿。模型打分是用一个小模型比如BERT或者Qwen2.5-1.5B给文案的质量打分分数范围0到1。打分维度包括与商品属性的相关性、语言流畅度、卖点突出程度、是否有编造信息。低于0.6分的打回重生成0.6到0.8分的标记为待审核0.8分以上的直接通过。这一层能再过滤掉25%左右的低质量文案。人工抽检是对通过前两层的文案按5%到10%的比例随机抽样由运营人员审核。如果抽检合格率低于90%说明自动质检的阈值设得太松需要调紧如果高于98%说明阈值太严可以适当放宽以降低重试成本。这个反馈闭环很重要能让系统持续优化。三层过滤下来最终需要人工逐条审核的文案大概只占总量的5%到8%。按日生成一万条算就是五百到八百条一个审核员半天就能搞定。4. 实操过程中的常见问题与排查技巧4.1 模型输出格式不稳定的排查与解决批量生成最让人头疼的问题就是模型输出格式不稳定。你明明在Prompt里写了“只输出JSON”它偏偏给你加一段“好的以下是为您生成的文案”然后再跟JSON。这种问题在批量场景下是灾难性的因为你的解析代码会直接报错整批任务都得重跑。排查这个问题的第一步是确认你用的API是否支持response_format参数。OpenAI、DeepSeek、通义千问都支持JSON模式开启之后模型会强制输出合法JSON。如果你的模型不支持这个参数那就需要在Prompt里把格式约束写到极致。我的做法是在Prompt的最后一段单独写“输出格式要求”用大写字母和加粗标记比如“只输出JSON数组不要任何解释性文字不要使用Markdown代码块包裹”。如果还是偶尔跑偏可以在解析层做容错。用正则表达式先把JSON部分提取出来再解析。比如用re.search(r\[.*\], text, re.DOTALL)把方括号之间的内容抠出来。这个正则能处理大部分“JSON外面包了一层废话”的情况。还有一个坑是模型输出的JSON里包含非法字符比如中文引号、换行符没转义、或者尾随逗号。Python的json.loads对这些很敏感直接报错。解决方案是用json5库代替标准库json5对尾随逗号和单引号更宽容。或者用demjson3它的容错能力更强。我踩过最坑的一次是模型在JSON字符串里输出了未转义的双引号导致解析直接失败。后来我在Prompt里加了一条“字符串值内如需使用引号请使用中文引号”这个问题就再也没出现过。4.2 API限流与超时问题的应对策略API限流是批量生成绕不过去的坎。你并发开高了API返回429并发开低了吞吐量上不去。我的应对策略是动态并发调整加多通道轮询。动态并发调整的思路是初始并发设一个保守值比如20每完成一百个请求统计一次错误率。如果错误率低于1%并发数加5如果错误率高于5%并发数减10。这样系统能自动找到当前API的最优并发点。实现上用asyncio的Queue加一个控制协程来动态调整Semaphore的值。多通道轮询是准备多个API Key或者多个模型供应商当一个通道被限流时自动切换到下一个。比如你同时有DeepSeek和通义千问的API可以做一个简单的轮询器每个请求轮流走不同的通道。这样单个通道的QPS压力就降下来了。如果预算充足还可以混用不同供应商的API进一步分散风险。超时问题相对好处理。aiohttp的ClientSession可以设置timeout参数我一般设成30秒。超过30秒没响应就取消请求走重试逻辑。重试三次还失败就标记为失败任务写入死信队列后续人工处理或者换模型重跑。4.3 成本失控的预警与优化手段成本失控通常发生在两个环节一是重试率过高导致token消耗翻倍二是模型选型不当导致单条成本过高。预警机制上我会在监控系统里设三个阈值日成本超过预算的80%发警告超过100%发严重警告并自动降级到便宜模型超过150%直接暂停任务并通知负责人。优化手段有几个立竿见影的。第一是压缩Prompt长度。很多团队的Prompt写得又臭又长光角色设定就五百字few-shot示例塞了十个。实际上角色设定两百字足够few-shot示例三到五个最佳。Prompt每压缩一百token一万条就能省一百万个输入token按DeepSeek的输入价格算就是一块钱。看起来不多但积少成多。第二是缓存高频请求。很多SKU的属性是相似的比如同一款衣服的不同颜色商品描述几乎一样只有颜色参数不同。你可以把商品属性做哈希相同的哈希直接返回缓存结果不用调API。我实测下来缓存命中率能到15%到20%直接省掉这部分成本。第三是分级生成。不是所有SKU都值得用GPT-4o。你可以按SKU的预期GMV或者利润率分级高价值SKU用贵模型低价值SKU用便宜模型或者本地模型。这个策略能让整体成本降低30%到40%而高价值SKU的文案质量不受影响。4.4 常见问题速查表问题现象可能原因排查方法解决方案生成成功率低于90%API限流或网络超时查看错误日志中的状态码分布降低并发数增加重试次数切换备用通道文案质量波动大Prompt约束不够或temperature过高抽检低分文案对比Prompt加强格式约束降低temperature到0.5-0.7成本突然翻倍重试率飙升或模型切换错误检查重试日志和模型路由配置修复重试逻辑确认路由规则数据库写入慢逐条插入或批次太小查看数据库慢查询日志改为批量插入单批次300-500条违禁词漏检敏感词库不完整人工抽检违禁词命中情况补充敏感词库加入变体词和拼音缩写JSON解析失败模型输出格式跑偏打印原始输出内容开启response_format加正则容错解析本地模型推理慢未开启连续批处理查看vLLM日志中的batch size开启continuous batching调大max_num_seqs人工审核量居高不下自动质检阈值太松统计各分数段文案的合格率调高通过阈值增加质检维度5. 从批量生成到质量优化的进阶思路5.1 用历史数据做Prompt的持续迭代批量生成系统上线只是开始真正的功夫在持续迭代。我习惯每周做一次Prompt效果复盘从数据库里拉出上周生成的所有文案按类目分组统计每个类目的合格率、平均质量分、人工修改率。合格率低的类目说明Prompt需要调整。调整的依据来自人工修改记录。运营审核时修改过的文案修改前后的差异就是Prompt的优化方向。比如运营把“修身显瘦”改成了“遮肉不挑身材”说明模型用的词太书面化不够口语化。你把这些修改点整理成规则补充到Prompt的负面约束或者few-shot示例里下一批生成的质量就会有提升。更进阶的做法是用这些修改数据做模型微调。把“原始生成文案”作为输入“人工修改后的文案”作为输出构造训练样本。积累到几千条之后用LoRA在开源模型上做微调。微调后的模型在特定类目上的表现能接近甚至超过GPT-4o而推理成本只有API的十分之一。我帮一个美妆类目的团队做过这个事微调后的Qwen2.5-7B在美妆文案上的合格率从78%提升到了91%而单条成本从两分五降到了几乎为零。5.2 多模态能力的引入与场景扩展电商文案不只是文字主图、详情页、短视频都需要文案配合。现在多模态大模型已经能看图说话了你可以把商品主图直接丢给GPT-4o或者Qwen-VL让它根据图片内容生成文案。这个能力在服装、家居、美妆类目特别有用因为很多卖点是视觉化的比如“显白”“有质感”“版型正”光看文字属性很难写准确但模型看了图就能抓住感觉。我实测过用Qwen-VL根据服装模特图生成卖点效果比纯文本输入好很多。模型能识别出“收腰设计”“V领显脖子长”“面料有垂坠感”这些视觉细节而这些细节在商品属性表里往往没有。当然多模态调用的成本比纯文本高Qwen-VL的图片输入按token计费一张图大概消耗一千到两千token。所以我的策略是只对高价值SKU用多模态普通SKU还是走纯文本。场景扩展上批量生成的能力可以复用到很多地方商品问答的自动回复、客服话术生成、直播脚本生成、站内信营销文案、甚至竞品分析报告。核心逻辑是一样的——把结构化的商品数据加上Prompt模板批量喂给模型自动质检后落库。你把这套流水线搭好了换个Prompt模板就能复用到新场景边际成本极低。5.3 本地部署方案的硬件选型与性能调优如果你决定走本地部署路线硬件选型是第一个要解决的问题。我的建议是根据你的日生成量来倒推。日生成一万条每条平均输出300token总输出量是三百万token。7B模型在4090上用vLLM推理吞吐量大概是每秒六十个token一天跑十小时就是两百一十六万token。不够。你需要两张4090或者一张A100 40G。两张4090的吞吐量能到每秒一百二十个token一天十小时就是四百三十二万token足够覆盖一万条的需求还有余量做重试。如果预算有限可以考虑用量化模型。Qwen2.5-7B的GPTQ 4bit量化版本显存占用从14G降到5G一张4090能同时跑两个实例吞吐量翻倍。代价是质量会有轻微下降实测合格率降低三到五个百分点。对于标题生成这种相对简单的任务量化模型的损失可以接受对于详情页长文案建议还是用全精度模型。性能调优上vLLM是目前最成熟的推理框架。关键参数有三个max_num_seqs控制同时处理的序列数设成64到128比较合适gpu_memory_utilization控制显存占用比例设成0.9tensor_parallel_size控制张量并行的卡数单卡设1双卡设2。开启continuous batching之后吞吐量能比朴素推理提升五到十倍。本地部署还有一个隐性成本是运维。模型更新、依赖升级、GPU驱动兼容性、显存泄漏排查这些都需要专人负责。如果你团队里没有熟悉CUDA和推理框架的工程师我建议还是先用API等量级上来了再考虑本地部署。5.4 成本与质量的动态平衡策略成本和质量的平衡不是一成不变的要根据业务阶段动态调整。冷启动阶段SKU少重点是验证模式直接用最好的模型成本高就高先把流程跑通。增长阶段SKU量上来了开始做模型分级高价值SKU用贵模型普通SKU用便宜模型。成熟阶段积累了大量人工修改数据开始做模型微调用微调后的本地模型替代大部分API调用成本降到最低。我一般会设一个质量底线核心SKU的文案合格率必须高于95%非核心SKU可以放宽到85%。核心SKU的定义可以按GMV、利润率或者战略重要性来定。这个底线决定了你在成本优化上能走多远。如果优化之后合格率跌破底线那就得往回退一步换更好的模型或者加更多人工审核。还有一个策略是A/B测试驱动。同一批SKU生成两套文案一套用贵模型一套用便宜模型上线跑一周看转化率差异。如果差异不显著那就全面切换到便宜模型。我做过好几次这样的测试结果发现对于标品比如日用品、基础款服装贵模型和便宜模型的转化率差异在统计上不显著但对于非标品比如设计师款、高端美妆贵模型的转化率明显更高。所以分级策略是有数据支撑的不是拍脑袋。6. 我个人在实际操作中的几点体会这套批量生成系统我前前后后搭过三版第一版踩了无数坑第二版勉强能用第三版才算顺手。最大的体会是不要追求一步到位。很多人一上来就想搭一个全自动、多模型、带微调的完美系统结果光架构设计就花了一个月代码写了三千行跑起来一堆bug。我的建议是先跑通最小闭环一个模型、一个Prompt模板、一个批量脚本、一个Excel输出。先让运营用起来收集反馈再逐步加自动质检、多模型路由、监控告警这些模块。另一个体会是人工审核不能省。我见过有的团队为了追求全自动把自动质检的阈值设得极松结果生成了一堆看起来通顺但实际有事实错误的文案上线之后被消费者投诉虚假宣传。电商文案涉及广告法、平台规则、消费者权益一旦出问题就是真金白银的罚款。所以哪怕自动质检做到95%的准确率剩下5%也一定要人工过一遍。这个成本不能省也不该省。最后分享一个小技巧把运营的修改记录当成宝贝。每次运营修改文案你都把修改前后的版本存下来。积累三个月你就有了一份高质量的微调数据集。用这份数据微调出来的模型比任何通用大模型都懂你们家的商品和用户。这才是批量生成系统真正的护城河——不是模型本身而是你积累的数据和迭代出来的Prompt资产。
