用大模型搭建电商商品资料包体检助手：跨文件一致性审核实战

我遇到过最崩溃的一次审品是运营同事一口气丢来一个网盘链接里面躺着 6 份新品资料和 1 张商品主图要求当天下午 4 点前给出上架审核结论。人工逐份核对文案、参数、图片、资质看到第三份文件时眼睛已经花了第五份和第一份的容量数据对不上时我甚至怀疑自己记错了。后来我直接用 Qwen3.8-Max 搭了一个商品资料包体检助手把 6 份资料和 1 张图片全部灌进去做交叉检查第一轮跑完就吐出一份 27 个问题的体检报告从“净含量标错”到“授权书已过期”再到“主图水印残留”一条条列得清清楚楚。这篇文章就把这套方案的完整思路、代码实现、Prompt 设计和排坑经验全部摊开讲适合正在做电商上架审核、商品运营、供应链品控或者想用大模型解决多文档一致性校验的朋友参考。1. 为什么电商资料审核值得做成自动化一场发生在详情页里的“世界大战”电商上架一个新品尤其是标品/快消品类资料包动辄五六份起步标题文案、卖点、详情页长图文案、SKU 参数表、质检报告、授权书、主图、活动价格表。这些文件来自不同部门、不同供应商系统字段口径经常对不上。审核要做的就是找出所有“不一致、缺失、夸大、过期、错别字”。但人工审核有几个天然盲区这也是我决定用 LLM 做自动化的根本原因。1.1 资料包到底长什么样以我这次处理的案例为例一共 7 个输入对象标题文案.docx商品标题包含品牌、品名、规格、卖点关键词商品卖点.txt运营写的卖点提炼用于主图文案和详情页首屏详情页文案.docx完整的长图文案包含成分、功效、使用场景、售后说明SKU 参数表.xlsx规格、颜色、条码、重量、材质、价格、库存质检报告.pdf第三方检测机构出具的检测结果品牌授权书.pdf品牌方给店铺的销售授权商品主图.jpg用于商详页首图的商品白底图这些资料之间不是孤立的标题里的“500ml”要对上 SKU 参数表的“净含量”卖点里写“纯棉”要对上质检报告的材质结论详情页里说“7 天美白”需要有对应的检测依据授权书的有效期要覆盖当前上架时间。任何一环脱节上架后就是差评、投诉、平台处罚的隐患。1.2 人工审核为什么必然漏先说结论不是审核的人不负责而是这个任务的认知负荷远超人类常规注意力区间。第一交叉引用需要短期记忆同时维护多个字段。标题、详情页、SKU 表、质检报告四份文件里都出现了“容量”这个属性但表述分别是“500ml”“500mL”“净含量 500g”“容量 480ml”。不把它们拉平到同一个维度上肉眼很难发现其中有一个是异常值。第二审核任务存在典型的“搜索抑制”效应。当你想找“价格不一致”时视觉会自动忽略“材质不一致”的信息。逐项核对 20 个属性真正能稳定发现的问题大概只有 60%。第三新人审核员没有“问题直觉”。老运营看到“医用级”三个字就会敏感看到“7 天美白”就知道要查检测报告看到“全网销量第一”就知道这是无实证绝对化用语。但这些经验很难标准化团队里一旦有人休假审核质量就断崖式下跌。所以这个场景天然适合分层自动化硬规则用正则和脚本筛软规则和跨文件语义比对交给 Qwen3.8-Max 这类大模型去做。2. 体检助手整体架构规则引擎筛硬伤LLM 负责动脑子一开始我踩过一个误区想直接把 6 份资料全部丢给大模型让它一次性输出所有问题。结果输入超长、输出失控、该查的漏了一堆。后来我调整了架构把整个流程拆成四层每一层只做自己最擅长的事第一层资料解析与标准化第二层规则引擎检测第三层LLM 交叉检查第四层结果汇总与去重2.1 为什么先过规则引擎成本与可靠性很多朋友看到“用大模型搭工具”就觉得应该什么都让大模型干。实际跑过之后你会发现规则引擎这层绝对不能省原因有三。成本层面Qwen3.8-Max 是每百万 token 计费的6 份资料加起来将近 2 万 token如果每个字段都让模型从头到尾读一遍一次体检消耗的 token 非常多。而规则引擎只用正则和字典匹配几乎零成本。可靠性层面日期是否过期、字段是否缺失、价格是否为数字、条码位数是否合法这些是“确定性问题”规则引擎 100% 准确大模型反而可能因为上下文干扰出现幻觉。比如我把“2023 年 12 月 31 日”到期的授权书输入进去模型第一次给的结果居然是“有效期内”因为它默认当前时间是 2024 年完全没有意识到时间已经过了。可解释性层面电商审核是高责任场景发现问题之后要跟供应商、运营、品牌方沟通需要指出“是哪个文件哪一行出了什么问题”。规则引擎的每一次命中都可以精确到行号和原始文本而大模型的判断往往是“感觉不对”必须要求它输出引用原文否则没法追责。所以我最终的分工是规则引擎负责查缺失、过期、格式错误、极限词库命中Qwen3.8-Max 负责跨文件语义一致性、逻辑合理性、图片内容与文案的匹配度。两边的结果合并后统一去重形成一个完整的问题清单。2.2 文件解析这一步比想象中坑多先上代码这一步是基础但坑全在这里。import re import pdfplumber from docx import Document from openpyxl import load_workbook from PIL import Image FILES { title: 标题文案.docx, selling_points: 商品卖点.txt, detail_page: 详情页文案.docx, sku_table: SKU参数表.xlsx, test_report: 质检报告.pdf, authorization: 品牌授权书.pdf, main_image: 商品主图.jpg, } def extract_docx(path): doc Document(path) parts [] for para in doc.paragraphs: if para.text.strip(): parts.append(para.text.strip()) for table in doc.tables: for row in table.rows: row_text | .join(cell.text.strip() for cell in row.cells) parts.append(row_text) return \n.join(parts) def extract_txt(path): with open(path, encodingutf-8, errorsignore) as f: return f.read() def extract_xlsx(path): wb load_workbook(path, data_onlyTrue) lines [] for ws in wb.worksheets: for row in ws.iter_rows(values_onlyTrue): vals [str(v).strip() if v is not None else for v in row] if any(vals): lines.append( | .join(vals)) return \n.join(lines) def extract_pdf(path): text_parts [] with pdfplumber.open(path) as pdf: for page in pdf.pages: text page.extract_text() if text: text_parts.append(text) return \n.join(text_parts) def extract_image(path): img Image.open(path) width, height img.size return f[商品主图] 尺寸: {width}x{height}, 格式: {img.format}三个容易踩的坑第一docx 里的内容不只存在于段落里还有大量表格。如果只用doc.paragraphsSKU 表、参数表里的数据全都会被漏掉。必须同时遍历doc.tables。第二PDF 分两种文字版和扫描版。pdfplumber 只能处理文字版。如果质检报告是扫描件extract_text()返回空字符串。这种情况只能先问供应商要原始电子版或者接 OCR。最保险的做法是解析完检测文本长度低于阈值就标记为“疑似扫描件需人工介入”。我这次遇到的质检报告就是文字版省了很多事。第三xlsx 里的合并单元格会导致某些行出现大量空值。data_onlyTrue可以拿到公式计算后的值但如果单元格本身是空的需要自己判断是否需要跳过。解析完成之后我建议把所有文本统一打上来源标签格式像这样【标题文案.docx / 第1段】 XX品牌 山茶花修护精华水 500ml 保湿补水收缩毛孔 【SKU参数表.xlsx / Sheet1行3】 规格 | 480ml | 颜色 | 雾霾蓝 | 条码 | 6901234567890带来源标签非常重要大模型输出问题时必须引用“哪个文件的哪句话”只有来源清晰才能做到这一点。3. 核心如何让 Qwen3.8-Max 从“闲聊模式”切到“审查模式”模型本身能力再强如果 Prompt 给得不到位它也只是个聊天机器人。要让 Qwen3.8-Max 干商品体检这种活儿必须把审查标准、输出格式、引用要求全部写清楚一次到位。3.1 给模型的“审查手册”把经验固化成指令我最终用的 Prompt 大概长这样你可以直接抄走改一改你是一名资深电商商品合规审核专家负责对商品上架资料包进行交叉检查。 下面会提供多份带【来源标签】的资料全文以及一张商品主图的描述信息。 请完成以下任务 1. 检查不同资料之间是否存在冲突或矛盾。 2. 检查单份资料内部是否存在逻辑错误、错别字、夸大宣传。 3. 检查商品主图描述与文案/SKU参数是否一致。 4. 检查是否存在极限词最、第一、顶级、全网销量第一等且无明确依据。 5. 检查资质文件授权书、质检报告的有效期和关键信息是否匹配。 输出格式要求 - 严格输出 JSON 对象不要输出任何额外说明。 - 格式为 {problems: [{id: 1, type: 一致性/完整性/合规性/逻辑性/图片问题/文本质量, severity: high/medium/low, source_files: [文件名, 文件名], evidence: 问题涉及的原文内容引用要具体, reason: 为什么这是问题, suggestion: 修改建议}]} - 每条问题必须基于原文证据不要猜测不确定的情况不要输出。 - 本次资料共包含N份文件请重点做交叉比对。每一轮调用前动态拼接实际的文件清单和全文内容。注意“本次资料共包含 N 份文件”这个信息要动态填充模型对“有几份资料”有预期之后才不会漏检某些文件。3.2 图片也要“开口说话”多模态输入的两种用法商品主图不是普通附件它和人眼看到的商品、详情页文案是强关联的。Qwen3.8-Max 这类多模态模型可以直接接收图片输入我在项目里试了两种用法第一种整图直传。把主图压缩到合适尺寸直接作为图片消息传入让模型描述图片内容提取主图上的可见文字、商品外观、背景色、是否存在水印。这适合查大问题比如水印、背景色不纯、商品和文案严重不符。第二种局部裁剪后再传。主图右下角常有小字标注“赠品以实物为准”或者“专利设计”整图看过去模型容易忽略。我用 PIL 把图片切成九宫格或者按四个角落裁剪放大再逐块传给模型识别识别率明显提升。这里有个很现实的取舍图片上的小字模型不是每次都能准确读取。如果出现疑似重要信息最好让模型标注“图片区域有文字但内容不清晰建议人工放大确认”而不是强行猜测。from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: [ {type: text, text: full_text_payload}, {type: image_url, image_url: {url: base64_image_data_url}} ]} ] response client.chat.completions.create( modelqwen3.8-max, messagesmessages, temperature0.1, response_format{type: json_object}, max_tokens3000 )3.3 控制变量temperature、max_tokens、json 输出设置审查是确定性要求非常高的任务不是创意写作。temperature必须拉到 0.1 以下我实测 0.2 时模型会偶尔给出“可能、应该、似乎”这种模棱两可的判断0.1 时明显更干脆。max_tokens不能设太小。27 个问题的 JSON 结构加上 evidence 里的原文引用一次输出很容易到 2000 tokens 以上。我一开始设的 1500结果模型只输出到第 18 个问题就被截断了之后重跑才完整。保险起见设 3000 以上。response_format{type: json_object}这个参数至关重要。不加它模型会在 JSON 外面裹一层“根据您的要求我分析了以下内容”这种废话解析时还得写正则去剥离。加上之后输出干净很多。4. 一次跑出 27 个问题体检报告的维度、实例与可信度排序这才是重头戏。Qwen3.8-Max 配合前面的规则引擎第一轮总共找出了 27 个问题。问题不是越多越好关键是每个问题都有证据、有等级、有修改建议。4.1 27 个问题总览我把这 27 个问题按类型和严重程度做了个汇总你可以对照自己的资料包看看是不是同样的坑问题类别数量严重high中等medium轻微low跨文件信息一致性7331完整性缺失5221合规风险6411逻辑/参数矛盾4211图片问题4121文本质量1001套用一句在系统设计领域的老话没有统一的问题分类体系就没有后续的追踪管理。我自己用的分类就是上面这六类覆盖了电商资料审核里最常见的六大场景。4.2 典型问题案例复盘下面挑几个最有代表性的问题展开讲讲每一个都是真实会发生在电商运营日常里的。案例一标题净含量与 SKU 参数表对不上严重·一致性标题文案里写的是“精华水 500ml”SKU 参数表里对应的规格却是 480ml详情页里又出现了一次“500ml”三处信息互相打架。这个问题是靠 LLM 交叉比对发现的规则引擎很难抓因为“500ml”和“480ml”都是合法数字正则无法判断哪个才是正确值。模型给出的证据来自两个文件直接锁定矛盾。商品净含量是上架信息中最敏感的字段之一标题、主图、详情页、SKU 表、物流面单上任何一处不一致都可能在发货后引发批量客诉。案例二主图产地与详情页“国产”宣传冲突严重·一致性商品主图上温度标签清晰写着“Made in Vietnam”详情页文案却强调“国货精选”。LLM 把图片识别结果和详情页文本做了交叉比对直接命中。这种问题最棘手因为主图的识别依赖多模态能力传统 OCR 只能提取文字“Made in Vietnam”但不知道这句话代表产地更不会把它和详情页的“国货”标签关联起来。大模型具备常识推理知道两者矛盾。案例三授权书有效期已过严重·合规性这里我要承认最初这个问题是规则引擎抓出来的而不是 LLM。授权书 PDF 里有一行“有效期至 2023 年 12 月 31 日”我用正则提取日期后和系统当前时间做比较直接判定为过期。LLM 在长文本里对日期是否过期的敏感度远低于规则引擎这是我在初版测试里踩过的坑。保留这种“规则抓确定性、LLM 抓语义性”的分工才是正确的架构。案例四卖点宣称“全网销量第一”但没有任何佐证材料严重·合规性这是极限词命中的典型案例。卖点文件里有一句“全网销量第一的修护精华水”但质检报告、销售数据截图、第三方榜单里都没有任何可以支撑这一结论的信息。规则引擎靠极限词词库先定位了“销量第一”LLM 进一步核实了“是否有相应依据文件”。大模型的判断能避免“是极限词但恰好有第三方排名证明”这种误判两个模型叠起来准确率最高。案例五主图出现竞品 logo 水印中等·图片问题这张主图的水印在左下角颜色和背景接近不仔细看很难发现。Qwen3.8-Max 识别图片后原文返回了一句“图片左下角疑似包含一个非本品牌的 logo 水印”。这类问题规则引擎完全无能为力必须依赖多模态模型的视觉能力。但模型表述中用了“疑似”两个字我在后处理脚本里把这种不确定描述自动升级为“需人工确认”宁可不漏也不能直接放过。案例六SKU 表颜色命名与详情页不一致轻微·一致性SKU 参数表里写的颜色是“雾霾蓝”详情页里对应的颜色叫“烟灰蓝”。消费者实际收到的商品颜色只可能有一种客观值但两个文件里用了完全不同的两套命名体系用户很可能在详情页确认颜色后收到包裹时对不上号。这种问题看起来小但客诉和下差评的概率极高。模型给出的修改建议也简单统一成一个色号名称最好在 SKU 表里补充行业标准色号编码。4.3 报告如何导出与追踪拿到 27 个问题的 JSON 之后我直接转成了 Markdown 报告左侧是问题列表右侧是原始证据链接。同时导出一份 Excel给运营同事按严重程度排序后分发给对应负责人。问题状态我用三种标记待处理、处理中、已确认不修改。已确认不修改的情况也要留痕例如“品牌方坚持保留‘7 天美白’表述并提供体外测试报告佐证”这个备注是事后复盘时最重要的资料。5. 实战避坑从漏报到误报我在这套流程上踩过的五个坑跑这个项目的过程中踩过的坑比预想的多。以下五个最具代表性每一个都是花了不少时间换来的经验。5.1 长文本超上下文分块与分层摘要最开始我很天真想把所有资料全文一次性拼接后丢给模型。结果发现 6 份文件的原始文本加起来超过 3 万 token而 Qwen3.8-Max 的上下文窗口虽然很大但在超长输入下输出质量会明显下降尤其容易在分析后半段文件时遗忘前面的内容。解决方案是“分层审查”第一轮先让模型分别对每一份文件做独立的关键信息提取输出结构化摘要第二轮把各文件摘要合并进行交叉比对。这样上下文长度大幅压缩同时保留了全文的证据引用——模型在输出问题时引用的可以是原始文件中的句子摘要。比如 SKU 参数表我会让它提取“规格、颜色、条码、重量、材质、价格”等核心字段质检报告提取“检测项目、结论、报告编号、有效期”。摘要带上文件来源第二轮交叉比对时模型依然知道信息来自哪里。5.2 同一字段多种写法导致的误报与漏报这是初版误报最多的来源。SKU 表里写的是“净含量 480ml”详情页里写“容量 0.48L”标题里写“500ml”质检报告里写“标示容量 480mL”。规则引擎和 LLM 都容易把“0.48L”和“480ml”当成不同的值从而误报。我的解法是在预处理层加一个字段归一化映射表容量ml / mL / ML / 毫升 / L / 升统一换算成 ml重量g / kg / 克 / 公斤统一换算成 g颜色常见色名映射到标准色号如“雾霾蓝 / 烟灰蓝 / 灰蓝”指向同一色号材质棉 100% 和纯棉、全棉统一归一为“100%棉”这一层做完模型面对的输入就从“多个同义词”变成“统一标准上的数据”误报率直接下降一半以上。5.3 JSON 输出不稳定Qwen3.8-Max 设了response_format{type: json_object}之后大多数情况下输出是规范的 JSON但偶尔还是会出现字段缺失比如某条问题没有suggestion字段或者severity的值不是 high/medium/low 而是“严重”。我的后处理脚本加了两层保险import json def safe_parse_json(raw): try: data json.loads(raw) except json.JSONDecodeError: match re.search(r\{.*\}, raw, re.DOTALL) if match: data json.loads(match.group(0)) else: return None return data def normalize_problem(item): item[severity] str(item.get(severity, unknown)).lower()[:4] allowed [high, medi, low, unkn] if item[severity] not in allowed: item[severity] unknown return item第一层是解析兜底用正则从{到最后一个}截取 JSON第二层是字段归一化把严重程度的各种说法映射回标准值。如果解析失败超过一次干脆把这一轮结果缓存下次跑的时候只重试失败的轮次。5.4 图片上的小字识别准确率受限Qwen3.8-Max 对整张图的语义理解很强但商品图上的小字、细纹、低对比度水印仍然是难点。我实测下来800×800 的主图里右下角一行 12px 的“赠品以实物为准”模型要么读不出来要么读出来但不确定。我的应对策略是“裁剪放大”加辅助 OCR。先把图片四角和中央区域各裁剪一次放大两倍后再传。如果裁剪后还是读不清就用 OCR 工具做文字提取把提取结果和模型描述合并。图片处理的结果会作为一个“图片信息块”单独传入 LLM而不是直接让模型看原始大图这样组合方案的稳定性远高于单独依赖某一种识别能力。5.5 成本与耗时控制每次体检涉及的 token 量并不小。简化输入之前一轮完整分析大约要消耗 4 万 token成本虽然谈不上昂贵但一天跑十几轮还是要心疼的。做了规则引擎前置过滤和分层摘要之后单次成本降到原来的三分之一左右。耗时也从最初的 3 分钟降到了 40 秒上下关键就在于第一批硬性问题全被规则层拦截真正需要模型动脑的是那些跨文件语义冲突。如果你要在生产环境持续跑这套流程我强烈建议加上“变更增量体检”的概念上次跑过且一致的字段如果这次资料包没有变化就不要重复传给模型只把变更部分和高风险字段重新检查耗时和成本都能大幅压缩。这套体检助手运行到现在帮我从一个又一个资料包里救回了不少问题也让我对“大模型不是魔法而是需要认真设计流程才能发挥价值”这句话有了更深的体会。我踩过最痛的坑是过度信任模型的输出后来养成了让模型必须附带原文证据的习惯。现在每次跑完体检报告我首先看的是没有任何问题的高风险字段是否都检查到了这个习惯才真正保证了上线率而不是被一长串问题清单冲昏头脑。