1. 电商资料包合规体检为什么值得单独做一套工具做电商运营或者店铺管理的朋友应该都有体会平台对商品资料包的审核越来越细。所谓资料包就是商品上架时提交的那一整套东西主图、详情页文案、参数表、资质文件、售后说明、成分表、执行标准号等等。任何一个字段踩了红线轻则审核驳回、商品下架重则扣分降权赶上大促节点被卡住损失是实打实的。过去我们团队处理这块靠的是人工逐条核验。一个中等复杂度的资料包从文案敏感词、极限词、医疗宣称到资质文件的有效期、经营范围匹配、执行标准是否现行有效一套走下来差不多二十分钟。一个店铺几十上百个SKU人力根本扛不住而且人看久了会疲劳漏检率肉眼可见地上升。这套“合规体检”工具就是冲着这个痛点去的。核心思路是把资料包拆成结构化的字段交给大模型做语义级判断再用规则引擎兜底硬性校验最终把二十分钟的人工核验压缩到一分半左右。它适合电商运营、店铺合规岗、代运营团队也适合想了解 MaaS 平台怎么落地到具体业务场景的开发者。整条链路我用的是蓝耘元生代平台模型侧主要跑 qwen3.8-max 和 qwen3.5-omni-plus前者负责文本合规判断后者处理图片类资料的理解。先说清楚一个前提合规判断这件事纯规则做不了。敏感词库能拦住“最”“第一”这种明显的极限词但拦不住“本品对某某症状有改善作用”这种隐含医疗宣称也判断不了详情页里一段话是不是在暗示疗效。这类需要语义理解的部分必须交给大模型。而纯大模型也不行资质文件的有效期、标准号的现行状态这种硬事实模型容易一本正经地胡说得用规则和外部数据源卡死。所以整套方案是“模型 规则”双轨各管各的。2. 整体架构设计与模型选型思路2.1 为什么是 MaaS 而不是自己部署一开始我们也考虑过自己拉模型部署算了一下账就放弃了。合规体检这个场景有明显的波峰波谷大促前资料包集中提交QPS 能冲到很高平时又很闲。自己部署意味着要么按峰值买卡平时浪费要么按均值买峰值扛不住。MaaS 按调用量计费弹性伸缩对这种潮汐型负载天然友好。蓝耘元生代这个平台的好处是模型选择多qwen 系列、deepseek 系列都能直接调切换成本低。我们做合规判断时对比过几个模型qwen3.8-max 在中文语义理解和指令遵循上表现稳定尤其是让它按固定 JSON 格式输出判断结果时格式错误率明显低。qwen3.5-omni-plus 支持多模态图片里的文字、资质文件扫描件它能直接读省掉了单独接 OCR 的环节。提示选模型不要只看榜单分数一定要拿自己业务的真实样本跑一轮。我们当时用 200 条历史驳回记录做测试集qwen3.8-max 的召回率比另一个候选模型高了将近 12 个百分点这个差距在合规场景里就是真金白银。2.2 双轨校验的分工整套流程分三层。第一层是预处理把资料包里的文本、图片、表格拆出来统一成结构化字段。第二层是模型判断把每个字段连同对应的合规规则说明一起塞给 qwen3.8-max让它输出“是否合规 风险等级 理由”。第三层是规则兜底针对有效期、标准号、资质编号这类硬事实做精确校验模型结果和规则结果做交叉验证。这么设计的原因是模型擅长“理解意图”规则擅长“核对事实”。比如详情页写“适合敏感肌使用”模型能判断这属于功效宣称、需要相应资质支撑但资质文件到底有没有、过没过期模型看不准必须查数据库。两层结果合并后只有都通过才算低风险任何一层报警都要人工复核。2.3 关键参数与成本估算模型调用这块我们把 temperature 设成 0.1合规判断要的是稳定复现不需要创造性。max_tokens 按字段长度动态给短文案 512 够用长详情页给到 2048。批量处理时用并发调用单次体检大概发起 15 到 30 次模型请求取决于资料包字段数量。成本上一个资料包走完模型侧大概几分钱加上规则引擎的计算开销可以忽略。对比人工二十分钟的工时成本这个投入产出比非常划算。实测下来20 个资料包批量跑总耗时 30 分钟左右平均单个一分半和标题里说的数字对得上。3. 核心细节拆解与实操要点3.1 资料包字段的结构化拆解这一步是整个流程的地基拆得不好后面全白搭。电商资料包的字段其实是有规律的我按平台常见的提交项整理了一份拆解表字段类别具体内容校验重点标题类商品标题、卖点短句极限词、违禁词、品牌侵权描述类详情页文案、卖点描述医疗宣称、功效暗示、虚假宣传参数类成分表、规格参数、执行标准标准号现行性、成分合规性资质类营业执照、检测报告、授权书有效期、经营范围、主体一致性图片类主图、详情图、资质扫描件图片文字合规、资质真伪拆解的时候有个坑要注意不同类目的字段差异很大。美妆类目重点看成分和功效宣称食品类目重点看配料表和生产许可3C 类目重点看认证证书。所以拆解逻辑不能写死得按类目配置不同的字段模板。我们做法是维护一份类目-字段映射表新增类目时补配置就行不用改代码。3.2 提示词工程让模型稳定输出结构化结果合规判断最怕模型“自由发挥”所以提示词必须把输出格式卡死。我们的做法是给每个字段类型配一套专属提示词模板模板里包含三部分角色设定、判断规则、输出格式。角色设定部分明确告诉模型“你是一名电商合规审核专家依据平台规则判断以下内容是否存在风险”。判断规则部分把该类目的红线逐条列出来比如美妆类目要列出“不得宣称医疗作用”“不得使用绝对化用语”“功效宣称需有备案支撑”等。输出格式部分强制要求返回 JSON包含 risk_level、reason、suggestion 三个字段。{ risk_level: high|medium|low, reason: 判断理由50字以内, suggestion: 修改建议无风险时为空 }实测下来把规则写进提示词比让模型自己“凭常识判断”准确率高很多。原因是模型对平台具体规则的理解不如你喂给它的明确你写得越细它判断越准。这里有个经验规则描述要用“禁止”“必须”这种强约束词别用“建议”“尽量”模型对前者遵循度更高。3.3 多模态处理图片类资料图片类资料分两种一种是商品图要检查图上有没有违规文字另一种是资质扫描件要提取关键信息做校验。前者用 qwen3.5-omni-plus 直接读图让它描述图中文字并判断合规性后者让它做信息抽取把证书编号、有效期、发证机构这些字段结构化出来。注意多模态模型读扫描件时对模糊、倾斜、盖章遮挡的图片识别率会下降。我们的处理是先做一轮图像预处理把图片转正、增强对比度再送进模型。这一步能明显提升抽取准确率尤其是老式纸质证书的扫描件。图片处理还有个细节主图上的文字往往很小直接送模型可能读不清。我们的做法是先放大到模型能识别的分辨率再送进去。这个分辨率阈值实测在 1024 像素宽以上比较稳低于这个值识别错误率会上升。3.4 规则引擎的硬校验清单规则引擎负责的是模型搞不定的硬事实我整理了一份核心校验项资质文件有效期当前日期是否在有效期内临近到期30天内标黄提醒执行标准号是否在现行有效标准库中是否已被废止或替代营业执照经营范围是否覆盖所售商品类目检测报告检测项目是否覆盖商品关键指标报告编号是否可查主体一致性资质文件主体与店铺主体是否一致这些校验项的数据来源有两块一块是本地维护的标准库和规则表一块是外部接口查询。标准号现行性这块我们维护了一份定期更新的标准库避免每次实时查询。资质编号可查性这块部分平台提供了查询接口能接就接接不了就人工复核。4. 完整实操流程与关键环节实现4.1 环境准备与 API Key 配置先把平台账号和 API Key 准备好。蓝耘元生代的控制台里能创建 API Key创建后要妥善保存它只在创建时显示一次。配置到环境变量里别硬编码在代码中。export LANYUN_API_KEYyour_api_key_here export LANYUN_BASE_URLhttps://api.lanyun.net/v1这里有个常见坑API Key 配错或者没配调用时会报 401 未授权。错误信息通常是unexpected status 401 unauthorized: authentication fails看到这个先检查 Key 是否正确、是否过期、请求头里的 Authorization 格式对不对。格式是Bearer your_api_keyBearer 后面有个空格这个空格漏了也会 401。还有一种报错是api_key_required提示api key is required in authorization header这说明请求头里压根没带 Key检查一下代码里读取环境变量的逻辑是不是变量名写错了或者没加载到。4.2 调用 qwen3.8-max 做文本合规判断文本判断是主流程核心代码逻辑是读字段内容拼提示词调模型解析返回的 JSON。用 Python 写的话大概是这样import os import json import requests def check_text_compliance(field_name, content, category_rules): prompt f你是一名电商合规审核专家。请依据以下规则判断内容是否合规。 类目规则{category_rules} 待检字段{field_name} 字段内容{content} 请严格按 JSON 格式返回包含 risk_level、reason、suggestion 三个字段。 resp requests.post( f{os.environ[LANYUN_BASE_URL]}/chat/completions, headers{ Authorization: fBearer {os.environ[LANYUN_API_KEY]}, Content-Type: application/json }, json{ model: qwen3.8-max, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 1024 } ) result resp.json() return json.loads(result[choices][0][message][content])这段代码有几个实操要点。temperature 设 0.1 是为了结果稳定同一段内容多次调用结果应该一致。max_tokens 要留够返回被截断的话 JSON 解析会失败。解析返回内容时最好加个 try-except模型偶尔会返回带 markdown 代码块的 JSON需要先剥掉 json 标记再解析。4.3 调用 qwen3.5-omni-plus 处理图片图片处理走多模态接口把图片转成 base64 编码塞进消息里。核心区别是 messages 里的 content 是个数组包含文本和图片两部分def check_image_compliance(image_base64, check_type): prompt f请识别图中文字并按{check_type}的合规要求判断是否存在风险返回 JSON 格式结果。 resp requests.post( f{os.environ[LANYUN_BASE_URL]}/chat/completions, headers{ Authorization: fBearer {os.environ[LANYUN_API_KEY]}, Content-Type: application/json }, json{ model: qwen3.5-omni-plus, messages: [{ role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{image_base64}}} ] }], temperature: 0.1 } ) return resp.json()图片 base64 编码后体积会变大大图建议先压缩再编码控制在 2MB 以内比较稳。另外多模态调用比纯文本慢批量处理时图片类字段建议单独排队别和文本混在一起影响整体吞吐。4.4 结果合并与风险分级模型结果和规则结果都拿到后做合并。合并逻辑是规则层报错的直接标高风险不管模型怎么说规则层通过但模型报高风险的标中风险进人工复核队列两层都通过的标低风险自动放行。风险分级用表格管理比较清晰规则结果模型结果最终等级处理方式不通过任意高风险直接驳回通过高风险中风险人工复核通过中风险中风险人工复核通过低风险低风险自动放行这套分级逻辑的好处是把人工精力集中在真正有疑问的case上。实测下来低风险自动放行的比例在 70% 左右剩下 30% 进人工人工工作量比全量核验降了一大截。4.5 批量处理与并发控制单个资料包一分半批量处理时并发控制很关键。并发太高会触发平台限流太低又浪费时间。我们的做法是用线程池并发数控制在 5 到 8 之间实测这个区间既能跑满带宽又不容易被限流。from concurrent.futures import ThreadPoolExecutor def batch_check(packages, max_workers6): results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: futures [executor.submit(check_single_package, pkg) for pkg in packages] for future in futures: results.append(future.result()) return results并发数不是拍脑袋定的是压测出来的。我们拿 50 个资料包做压测并发 5 时总耗时 42 分钟并发 8 时 31 分钟并发 12 时反而涨到 38 分钟因为开始出现限流重试。所以 6 到 8 是甜点区。5. 常见问题与排查技巧实录5.1 模型返回格式错误怎么处理最常见的问题是模型返回的内容不是纯 JSON可能带 markdown 代码块标记或者前面加了一句“好的以下是判断结果”。处理办法是解析前先做清洗去掉json 和标记找到第一个 { 和最后一个 } 之间的内容再解析。如果清洗后还是解析失败加一层重试机制把 temperature 再调低或者把提示词里的格式要求再强调一遍。实测重试一次基本都能解决重试两次还失败的极少。5.2 401 未授权错误的排查顺序看到 401 别慌按这个顺序查第一API Key 是不是复制的时候带了空格第二环境变量有没有正确加载可以在代码里打印一下 Key 的前几位确认第三请求头的 Authorization 格式对不对必须是Bearer加 Key第四Key 是不是过期了或者被禁用了去控制台确认一下状态。还有一种情况是 Key 本身没问题但调用的模型没有权限。有些模型需要单独开通没开通的话也会报鉴权类错误。这个去控制台的模型列表里确认一下。5.3 模型判断结果不稳定怎么办同一段内容两次调用结果不一样通常是 temperature 设高了。合规判断场景 temperature 必须压到 0.1 甚至 0。如果已经压到 0.1 还不稳定检查一下提示词是不是有歧义模型对模糊指令的理解会有波动。另一个原因是模型版本更新。平台侧模型升级后行为可能变化所以生产环境建议锁定模型版本号别用 latest 这种浮动标签。我们吃过这个亏某次模型静默升级后一批原本判低风险的内容变成了中风险排查了半天才发现是模型变了。5.4 图片识别不准的优化方向图片识别不准先看图片质量。分辨率太低、文字太小、有遮挡识别率都会掉。优化方向有三个一是预处理转正、增强对比度、放大二是换更清晰的图源如果原始资料包里的图就糊那谁也救不了三是把图片里的文字区域裁出来单独识别减少干扰。还有个技巧是给模型提供上下文。比如识别资质证书时告诉模型“这是一张营业执照”比让它自己猜是什么证书抽取准确率会高。5.5 常见问题速查表问题现象可能原因解决方向401 未授权Key 错误/格式不对/未开通模型检查 Key、请求头格式、模型权限返回非 JSON提示词格式约束不够强化格式要求、加清洗和重试判断结果不稳定temperature 过高/模型版本变化降温、锁定模型版本图片识别不准图片质量差/无上下文预处理、提供上下文、裁切文字区批量处理被限流并发过高降并发、加重试退避规则与模型结果冲突规则库过期/模型误判更新规则库、冲突case人工复核6. 实操心得与后续扩展方向跑通这套流程后有几个心得值得分享。第一别指望模型百分百准确合规场景永远要留人工复核的口子模型是提效工具不是替代方案。第二提示词是要持续迭代的每次人工复核发现模型判错的case都要回头优化提示词我们迭代了大概五轮准确率才稳定下来。第三规则库要定期更新平台规则和标准号都在变规则库不更新模型再准也白搭。后续扩展的话可以把人工复核的结果回流成训练数据做提示词的自动优化也可以把整套流程封装成 API 服务对接店铺后台实现资料包提交即体检。再远一点可以按类目沉淀合规知识库让模型判断时能检索到同类目的历史案例进一步提升准确率。最后分享一个小技巧批量处理时给每个资料包打个唯一 ID日志里记录 ID 和对应的模型调用详情出问题的时候能快速定位是哪个包、哪个字段、哪次调用出的错。这个习惯在排查线上问题时能省大量时间。
