用大模型做电商商品资料自动审核:27个问题一次查出

发布时间:2026/9/5 21:06:18
用大模型做电商商品资料自动审核:27个问题一次查出 1. 先说说这 27 个问题是哪来的做电商运营的朋友应该都有过这种经历上架一个新品要准备主图、详情页、规格表、质检报告、授权书、品牌资质、物流说明、售后政策……少说五六份文档多的时候十几份。以前我都是自己肉眼核对对着屏幕看到眼花偶尔漏掉一个错别字、一处规格不一致等平台审核打回来重改一来一回就是大半天。这个项目的出发点很直接让模型替我把这些资料先过一遍把明显的问题找出来我再针对性地人工复核。选型的核心是 Qwen3.8-Max原因是它在长文本理解上表现够稳一次能吞下的内容足够多——6 份资料加 1 张商品图全部丢进去做综合判断这个场景对上下文长度和跨文档推理能力的要求都不低。那个27 个问题不是模型编出来的数字而是我自己预设了 8 类检查规则模型按规则跑完输出的汇总结果。规则覆盖的维度包括规格参数一致性、价格与促销逻辑、标题字数合规、图片与文字信息对应关系、资质文件时效性等。整个流程跑完我把模型输出的问题清单人工复核了一遍绝大多数判断是准确的这也是我敢把这个流程固化下来的原因。这篇文章就把搭建过程和踩坑记录完整写出来给同样被商品资料审核折磨的运营、电商开发者和技术爱好者做个参考。下面每段都是实操记录可以直接照着做也可以按自己的业务场景改规则。2. 整体设计与检查规则的拆解思路2.1 为什么选 Qwen3.8-Max 而不是其他方案市面上做文档审核的工具有很多传统方案无非是关键词匹配加正则表达式遇到主图上写 500ml详情页写 550ml这种语义层面的不一致就抓瞎了。还有一种方案是训练专门的 NLP 小模型但要标注足够多的商品资料样本起步成本太高中小卖家根本玩不起。大模型方案的优势在于不需要训练直接用提示词约束输出格式就行。我选 Qwen3.8-Max 有三个具体考量上下文窗口够大6 份资料全文加 1 张图片的描述文本整体输入量在一万三千多个 token 左右Qwen3.8-Max 处理这个量级比较轻松不需要做截断或者分块保证了检查的完整性。结构化输出稳定这个项目的关键不是让模型聊天而是让模型按我设定的 JSON 格式返回检查结果。模型在遵循指令方面的表现直接决定了下游解析的复杂度实测下来它的格式稳定性是能接受的。中文电商场景理解力商品描述里大量出现爆款正品保障限时特惠这类营销话术模型需要分辨哪些是正常表达、哪些是违规极限词。这一点上通用大模型的中文语义理解能力比传统规则方案强很多。对比下来Qwen3.8-Max 在这三个维度上比较均衡。如果换成纯开源小模型上下文窗口可能不够如果换成商用大模型 API成本会明显上升。对于商品资料审核这个场景来说够用和划算往往比最强更重要。2.2 检查维度的设计哪些问题模型能查哪些必须人工查在设计检查规则之前我先梳理了一遍电商商品资料里最常见的坑分成三类第一类是硬性合规问题规则必须覆盖。包括标题是否包含违禁词最第一国家级这类极限词、是否缺少必要的资质文件、生产日期是否在有效期内。这类问题规则明确交给模型做初筛效率最高。第二类是交叉一致性校验这是大模型最擅长的地方。比如主图上标注的容量、规格、颜色是否和详情页的参数表一致质检报告上的产品名称是否和商品标题一致保修条款是否和售后说明里写的一致。这类检查如果靠人肉看要把几份文档来回切换对比费眼睛且容易漏。第三类是主观判断类模型只能给参考不能下结论。比如图片是否美观、卖点文案是否有吸引力、定价是否有竞争力。项目中我把这类检查做成建议级别输出时单独标记不会混入问题列表里。检查级别代表问题处理方式硬性合规标题含违禁词、资质文件过期模型直接判为问题必须人工复核修改交叉一致性规格参数不一致、价格逻辑矛盾模型标记不一致项人工确认以哪份文档为准主观建议卖点不突出、图片构图不佳归入建议清单可选处理模型不负责图片是否真的清晰美观人工查看原图模型只看描述文本需要特别说明的是模型不是检测工具它的角色更像一个认真负责的助理。它会逐字读完你丢给它的所有材料然后按你的要求把可疑的地方列出来。最终的审核决定权始终在人工手里这个定位是搭建整个流程的前提。3. 核心实操从资料读取到规则引擎的实现细节3.1 资料格式预处理PDF、Word、Excel、图片统一转为文本实际工作中拿到的商品资料格式五花八门PDF 的授权书、Word 的产品介绍、Excel 的规格表、JPG 的商品主图。模型只认文本所以第一步是统一转格式。这一步是整个流程里最繁琐但最重要的环节。格式转得干不干净直接决定后面检查质量。我踩过的坑包括PDF 是扫描件直接提取文本会得到一堆乱码或空白。这种情况需要先做 OCR 识别我用的是 PaddleOCR中英文混排识别率不错。如果 PDF 是文字版直接用 pdfplumber 提取即可。Word 表格里的内容用 python-docx 提取时表格内容和正文段落是分开的需要分别遍历否则规格表会丢。提取时我在每个表格前加了【以下是表格内容】的标记方便后面模型识别结构。Excel 多 sheet 问题规格表经常有多个 sheet要用 openpyxl 逐个读取表头行、合并单元格需要处理。合并单元格里的内容会分布在多行处理不当会导致提取内容重复。图片商品图本身没法转文本这个场景下的正确做法不是丢原图给模型看而是先对图片做描述。我用 Qwen-VL 看图生成一段包含图中所有文字信息参数、规格、标签的文本之后再和文档类文本一起输入给检查模型。最后我把所有转好的文本都统一成纯文本格式每份资料用分隔标记区分开【资料1商品标题】 智能保温杯 500ml 316不锈钢 商务礼品定制 【资料2商品详情页】 容量500ml 材质316不锈钢 颜色黑色/白色 保温时间12小时这样模型一眼就能看出哪些内容来自哪份文件在做交叉一致性校验时不容易混淆来源。3.2 规则提示词的设计如何让模型输出结构化 JSON这个项目的技术核心不是代码多复杂而是提示词设计得好不好。我写了大概三百多行提示词定义了 8 类检查规则、每类的输出格式、判断标准以及一条重要约束——如果某条规则没有发现问题必须返回 pass不允许省略。提示词的结构大致是你是电商商品资料审核助手。我提供多份商品相关资料你需要按规则逐项检查。 规则1标题合规性 - 检查内容标题是否包含极限词最、第一、顶级、国家级等 - 输出格式{rule: title_compliance, status: pass/fail, issues: [{content: 具体问题文本, location: 资料N, suggestion: 修改建议}]} 规则2规格一致性 - 检查内容不同资料中商品规格参数容量、尺寸、颜色等是否一致 - 输出格式{rule: spec_consistency, status: pass/fail, issues: [{content: A资料标注xxxB资料标注xxx, location: 资料1/资料3, suggestion: 请确认以哪个为准}]} 后续规则类似 最后将所有规则结果汇总为一个 JSON 数组不要输出任何多余文字。有几个设计细节值得展开讲讲都是我试错试出来的经验第一每个规则必须给出判断标准不能只给规则名。比如规格一致性这条规则如果不写清楚包括容量、尺寸、重量、材质、颜色、接口类型这些具体字段模型就会把详情页写大容量标题写500ml这种描述性不一致也报出来增加很多无效问题。我给每条规则都列了具体的字段清单精确到不能再精确。第二输出格式用 JSON Schema 约束而不是泛泛地说请用 JSON 格式输出。我会在提示词里把每个字段的类型、含义、示例写清楚。如果模型返回的 JSON 有格式问题解析失败的话要有重试机制——我设置最多重试两次第三次还失败就标记为待人工处理不中断整个流程。第三关于未知内容的处理。如果资料里某项内容缺失模型不应该当作问题报出来也不应该自动忽略而要输出status: unknown。这是为了和fail严格区分——fail是内容有冲突unknown是材料本身不全后续处理方式完全不同。3.3 整体流程编排读文档、调模型、解析结果、出报告整个流程我用 Python 脚本串起来的核心调用代码如下import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-qwen-endpoint.com/v1 ) def check_product_materials(materials_text: str): system_prompt load_system_prompt() # 加载规则提示词 response client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: system_prompt}, {role: user, content: materials_text} ], temperature0.2, # 低温度减少随机性 response_format{type: json_object} # 强制 JSON 输出 ) return parse_json_response(response.choices[0].message.content)两个关键参数值得注意temperature 设为 0.2审核场景要的是稳定和准确不是创意发散。温度越高输出越随机同一个材料跑两次可能得到不同结果。我在实际测试中试过 0.7 和 0.2同一个提示词下 0.7 会出现漏检的情况0.2 则稳定很多。如果你对结果稳定性有更高要求可以直接设成 0。response_format 用 json_object这是 Qwen 系列 API 支持的原生 JSON 输出模式比在提示词里说请输出 JSON可靠得多。模型收到这个参数后会强制走 JSON 生成的解码路径你只需要在解析时做好健壮性处理就行。跑完检查后脚本把所有问题的 JSON 结果汇总生成两份报告一份给运营看的 Markdown 摘要一份给开发用的完整 JSON。摘要报告长这样## 商品资料体检报告 检查时间2025-01-15 14:32 检查资料6 份文档 1 张商品图4 份正常3 份存在疑点 ### 问题汇总 | 编号 | 问题类型 | 严重程度 | 具体描述 | 所在位置 | 修改建议 | |------|----------|----------|----------|----------|----------| | 1 | 规格不一致 | 高 | 详情页标注容量 550ml质检报告标注 500ml | 详情页/质检报告 | 请确认实际容量并统一 | | 2 | 标题违禁词 | 高 | 标题包含最优质 | 商品标题 | 替换为优选 | | ... | ... | ... | ... | ... | ... | ### 统计 发现问题27 个高严重程度 8 个中严重程度 12 个低严重程度 7 个 建议项3 个有了这份报告运营同学不需要再逐份文件翻看直接照着清单改就行。整个检查从上传资料到生成报告实测耗时 40 秒到 90 秒左右具体取决于资料的 token 总量和模型的实时负载。4. 检查规则的详细拆解8 条规则怎么定才能不冤不纵把检查规则设计成 8 条不是拍脑袋定的数字而是我把日常审核中遇到的所有历史问题做了一个简单的归类统计后确定的。下面逐条说明每条规则的判断逻辑和边界情况这部分是这套流程能否落地的关键。规则一标题合规性与字面质量主要查两件事标题是不是包含《广告法》明令禁止的极限词以及标题长度是否在平台限定的范围内比如某平台限制 120 字。极限词清单我直接内置在规则里了最、第一、首个、首选、顶级、独家、国家级、世界级、极致、完美、绝对、永久、万能、百分百...这里有个容易误判的地方第一用在每一步操作这种语境里是不违规的不能见词就报。所以我在规则里加了一句说明——请结合上下文判断如果极限词用于描述商品品质的绝对性承诺则判定为违规如果只是普通量词用法不判违规。这对模型来说是能理解和执行的实测误报率不高。规则二规格参数交叉一致性这是重头戏几乎所有高严重程度问题都出自这里。我把需要交叉核对的字段明确列了出来容量/净含量尺寸/规格材质/成分颜色/色号数量/包装规格保修期限产地判断逻辑是在不同资料中提取同一字段的值做交叉比对。如果 A 资料写 500mlB 资料写 550ml就标记为不一致。这里有个需要谨慎处理的坑不同资料对同一参数的表述可能不同但含义相同比如净含量500ml和容量500毫升模型要能识别这是同一个数值的不同表达不能误报。像这种细节需要在提示词里明确说明500ml 与 500毫升视为相同单位差异不算不一致数值差异才算。规则三资质文件完整性与时效性检查授权书、质检报告、检测证书等文件是否存在以及有效期是否覆盖当前时间。判断时效性时模型需要从文档中提取日期再跟当前日期做对比。这里要注意的是我需要把当前日期显式传给模型很多模型在不知道今天的情况下会给出过时判断或者干脆无法判断。我在输入文本的最后加了一行【系统时间】2025年1月15日模型就会以此为标准判断文件是否在有效期内。规则四价格与促销逻辑校验检查定价、划线价、促销价的数值关系是否符合常理逻辑。比如促销价不能高于划线价折后价不能高于原价满减条件是否合理。这个规则模型判断起来稍微费劲一些因为价格信息经常以199 元起券后低至 XX限量秒杀价这类模糊形式出现。我的处理方式是只对明确的数值关系做判断模糊表达一律标记为建议人工复核。规则五图片与文本信息对应这一步依赖图片识别的结果。流程是先用视觉模型对图片做文本提取和描述生成了图片包含的所有文字信息再和文档里的描述做对比。比如主图上印着500ml详情页写 550ml就会被查出来。这类问题传统关键词方案几乎不可能发现自然语言理解带来的增量价值在这个规则上体现得最明显。规则六营销话术与虚假宣传风险识别治愈根治防癌100% 有效这类夸大宣传用语也包括全网销售第一销量冠军这类无法提供证明的广告语。这条规则和规则一有部分重叠但侧重点不同——规则一针对的是极限词硬违规规则六针对的是宣传话术的合理性质疑输出结果时在这一类里会加上营销风险等级的评估。规则七文案文字质量检查错别字、病句、重复冗余内容。这个是通用文本检查范畴大模型的基础能力本身就覆盖了没有特别多可说的。需要注意的是不要给模型太大权力让它直接改文案——它可能改出和原意不同的内容。我限定它只能标记疑似错误和给修改建议最终改不改由人工决定。规则八禁忌词与特殊品类合规这个规则需要结合具体品类去扩展。比如食品类要查有没有宣称治疗功效化妆品类要查有没有药妆这类违规表述电子产品要查有没有强制性的认证标识如 CCC、CE。我把这里设计成一个可配置项规则内容放在一个单独的 JSON 文件里要适配不同商品类目时只改配置不碰代码。每次跑完 8 条规则脚本会统计每个规则的通过率和问题数量分布。归一化之后的检查结果还可以反过来优化规则提示词——比如某条规则经常漏检说明描述不够具体经常误报说明边界条件描述不够清楚。5. 实操过程完整跑一遍6 份资料 1 张商品图的体检老规矩直接上实操。下面是我这一批次实际处理的商品资料清单就用保温杯举例子资料脱敏处理过资料1商品标题文案txt——标题、卖点 资料2天猫详情页描述pdf——参数表、产品介绍 资料3质检报告pdf扫描件——需要 OCR 资料4品牌授权书pdf——有效期检查 资料5价格与促销表xlsx——多 sheet 资料6售后政策说明docx——保修条款 资料7商品主图jpg——图文一致性处理步骤细节如下。第一步统一格式转换耗时约 2 分钟。用 pdfplumber 提取详情页和品牌授权书的文字内容用 PaddleOCR 对质检报告做识别用 python-docx 提取售后政策的段落和表格用 openpyxl 按 sheet 读取价格表。这些代码逻辑比较直接我把它封装成了一个materials_loader.py模块每次处理新商品时只需要把新文件放到指定目录下就能自动处理。第二步图片描述生成耗时约 10 秒。商品主图的处理是个关键环节。我用的方法是调用视觉模型直接让它输出图片中的所有文字信息以及与商品相关的描述性内容请仔细观察这张商品图输出 1. 图片中所有可辨识的文字包括参数、品牌名、宣传语等 2. 图片中展示的商品类别和主要配色 3. 图片中是否有明显的品牌 LOGO 或认证标识 只输出事实描述不要添加你的主观评价。这一步输出的是结构化文本结构化文本再传给检查模型做交叉比对。很多做自动化审核的人会忽略这一步直接让文本模型去看图——但纯文本模型确实不具备图像理解能力如果 API 同时支持图片输入直接把图片传过去是更理想的选择。第三步组装输入文本把 7 份资料拼接成一个完整段落。按要求给每份资料加来源标记追加系统时间然后把这段文本发给 Qwen3.8-Max【资料1商品标题文案】 ... 【资料2商品详情页】 ... 以此类推 ... 以上是全部商品资料。请按既定规则逐项检查输出 JSON 格式结果。第四步解析模型返回人工复核疑似问题。模型返回的 JSON 解析后我人工过一遍问题列表。模型建议终归只是辅助重点还是需要人工判断。比如有一处模型报保修期限不一致——详情页写一年质保售后政策写三十天包退换模型不确定是否适用商品属于不同阶段的服务后来我们确认这是两个不同说法并不冲突补充了质保与服务政策分属不同维度的报告说明把这个问题降级为建议补充表述。这批 6 份资料加 1 张图的完整检查实际跑出来的结果是8 条规则共报出 27 个潜在问题其中人工复核确认需要改动的是 21 个有 6 个属于误报或在人工复核后排除。也就是说模型的准确率大约在 78% 左右。作为第一版流程这个水平已经能节省相当多的人工审核时间了。6. 运行时遇到的问题与排查记录把这套流程真正用起来的过程中遇到不少磕磕绊绊挑几个典型的问题记录一下既是给后来者避雷也是我自己后续优化的参考。6.1 问题一JSON 解析失败第一次跑的时候模型偶尔会在 JSON 前后加一段解释文字比如以下是检查结果导致json.loads()直接报错。排查后发现这是因为我没有在系统提示词里明确约束不要输出任何多余文字只说了输出 JSON。加上这句约束后失败率降到 1% 以下。如果你对接的是其他模型建议另外在代码层加一层兜底用正则把 JSON 部分截取出来再解析import re def extract_json(text: str): pattern r\{.*\}|\[.*\] match re.search(pattern, text, re.DOTALL) if match: return json.loads(match.group()) raise ValueError(No JSON found in response)6.2 问题二OCR 识别错误导致误报质检报告是扫描件OCR 识别时把500ml识别成了500m1数字 1 和字母 l 混淆规格一致性检查直接报了一个容量不一致的错。人工复核时才发现是 OCR 的问题不是资料本身的问题。解决办法是在 OCR 之后加一个后处理规则把常见的易混淆字符比如 1/l、0/O、2/Z做归一化后再进入比对环节这才把这类问题处理掉。另外对于数字和单位相连的文本我用了正则直接提取(\d(\.\d)?)(ml|g|kg|mm|cm)这类模式做标准化比让模型去裸读 OCR 文本靠谱得多。6.3 问题三多次运行结果不稳定同一批资料同一套提示词跑了三次两次报 27 个问题一次报 24 个。排查发现差异主要出在有没有漏掉一处隐藏在段落中间的违禁词。后来把 temperature 从 0.7 调到 0.2 之后结果基本稳定。这里想多说一句ctemperature 调到更低可以提高可复现性但也会降低模型的泛化能力。审核场景要的是可复现、可追责所以低温度是更合理的选择。6.4 问题四输入上下文过长导致超时资料多的时候全部输入可能超过 2 万 token单次请求耗时可能超过 60 秒偶尔会触发 API 超时。我的处理方式是把 visual 模型的图片描述单独走一次调用不混在主请求里主检查请求做了超时重试机制超时后自动拆成两个子请求比如资料 1-3 一个请求资料 4-7 一个请求分别检查分布式检查后需要再加一个汇总步骤把两部分结果合并成一份报告。拆分子请求的方式会丢失一些跨资料的语义关联比如资料 1 和资料 4 的对比检查所以我会在汇总时额外做一轮针对关联性规则的二次查询再把结果合并。这里有个取舍如果是验证阶段或资料量大可以优先选拆分明细如果对结果完整性要求高建议直接申请更高的并发。6.5 快速排查表现象可能原因排查方法解决措施取到 JSON 前有解释文本提示词缺少输出约束查看原始响应日志在系统提示词中明确只输出 JSON不要任何解释规格对比频繁报不一致OCR/模型数值提取错误对比原始文本加入 OCR 后处理数值提取正则化多次运行结果不同temperature 过高同一输入跑 3 次对比将 temperature 调至 0.2 以下请求超时输入过长查看调用耗时日志拆分子请求设置超时重试模型报告未知过多资料本身缺失信息检查原始材料完整性补充资料后重新检查或标记待人工确认JSON 解析报错响应被截断检查响应完整性加截断检测自动发起重试7. 这个方案的价值边界和后续能怎么扩展说句实在话这套流程不是万能的。它解决的是多资料交叉比对的效率问题解决不了资料本身质量差的问题。如果原始资料缺一堆参数模型能做的只是告诉你这里缺了但不可能凭空补出正确的数据。从实际效果看原来人工审一份商品资料大概需要 30 分钟到 1 小时用这版流程辅助之后人工复核只需要 10 分钟左右。对每天要上架几十个新品的团队来说这个时间差是实打实的。目前已经在规划中的三个扩展方向多轮审核与意见汇总同一商品在不同平台如电商平台、垂直行业平台上传时规则细节不同。现在只做了一版通用检查后续会做成规则配置文件按平台加载检查。批量队列化扫描把接口封装成异步任务批量跑一批商品资料最终只汇总异常项的表单彻底变成只看报表干活。问题标签反馈优化把人工复核时修正为误报的结果收集起来作为反馈样本可以持续打磨提示词的边界条件设定。我是建议有兴趣试类似方案的开发者不必一上来就追求把所有规则做到 100% 覆盖。先选 3 到 5 条最高频的检查规则跑通全流程让运营同学先用起来在过程中积累真实问题再逐步扩充规则这样推进更稳。