电商合规核验这类活儿干过的人都懂SKU一多光“核对资质证照是否在有效期”就能耗掉一上午。我接手资料包审核这块之后一直在找一个能把这类重复劳动真正压下来的办法。后来用蓝耘元生代这个MaaS平台做了套自动化体检流程把单份资料包的核验时间从20分钟压到一分半左右而且漏检率比我肉眼判断的时候还低。这篇文章就把整套思路和踩过的坑完整写出来给同样被审核量折磨的朋友做个参考。先说清楚这套东西的适用范围它做的是“初筛风险定位”不是替代人工最终判定。适合电商运营、合规岗、代运营公司、以及手里有几百上千个SKU需要定期巡检的人。如果你是品牌方需要按平台规则逐条核对商品详情页、资质证照、授权链路这套流程可以直接抄作业。1. 项目背景与需求拆解1.1 电商合规体检到底在审什么要压时间先得搞清楚“20分钟”花在哪了。我接手时梳理了一下一份典型的电商资料包通常包含这几块内容商品基础信息标题、卖点文案、详情页图片与说明文字证照资质营业执照、品牌授权书、质检报告、特殊品类许可证经营链路进货凭证、供应商资质、委托加工协议宣传用语详情页和主图里的绝对化用语、极限词、医疗相关表述每块内容都有对应的核查点。比如标题里出现“顶级”“第一”这类字眼详情页里出现“治疗”“药效”等医疗词汇证照扫描件模糊、有效期临近、授权链条断裂这些都是要标红的点。1.2 人工核验为什么这么慢慢不是审核员懒而是流程本身太碎。我实测过标准操作路径打开商品链接截图、下载资料包附件、逐页翻PDF找关键信息、切到规则文档确认当前平台禁词清单、再把发现的问题一条条录入Excel一个流程跑下来十五到二十分钟很正常。更麻烦的是规则本身一直在变。平台每个季度会更新细则可能这个月还允许的表述下个月就进了禁词库。人工核验得始终保持“最新规则”在脑子里这对人的要求其实非常高。1.3 为什么这件事适合交给大模型大模型在“套规则、找异常”这件事上天然有优势。它擅长把一段模糊的自然语言规则比如“不得出现表示绝对化的用语”转化为具体的判断动作见到“全网第一”就报警。之前也试过用正则表达式写禁词匹配效果一般——规则一多正则维护成本就失控而且很多问题不是“词命中”而是“语义违规”。比如“用了它皮肤变得非常好”这句话没有极限词但放在化妆品类目里就涉嫌功效宣称过度。正则抓不住这种问题大模型可以。2. 方案设计与工具选型2.1 为什么选蓝耘元生代而不是本地部署选型时我对比过三条路线纯开源模型本地部署、通用大模型API直连、蓝耘元生代这种MaaS平台。本地部署最先被否掉。我们即便只跑7B或13B量级的模型也需要一张像样的显卡来保证推理速度更别提还得有人维护推理服务、处理并发、做模型更新。电商合规这种需求一个月可能只有月初和月底两个高峰为了高峰期去运维一套本地推理集群成本完全划不来。通用大模型API直连我也试过一阵子效果不差但要命的是“平台绑定”太死。我有好几个模型供应商的Key接口风格各不相同每次想换一个更强的模型试试都要重新改造代码里的请求格式和解析逻辑非常痛苦。蓝耘元生代这种MaaS平台的优势在于它把多个模型放在同一个接入框架里我只需要对着它统一的OpenAI兼容接口写一次代码之后换模型就只是改个模型名的事。另外一点MaaS平台本身负责底层算力调度和模型运维出问题不用我半夜爬起来看日志排查推理服务挂了没有。我只需要关心业务逻辑本身也就是提示词和数据流的设计。2.2 模型选型逻辑蓝耘元生代平台上可选的模型不少我最终固定下来主用长文本能力强的模型原因是资料包动辄十几页PDF需要一次性塞进上下文才能做全局判断。选模型我主要看三个维度上下文窗口必须能容纳完整的资料包文本内容否则得拆分着来规则之间互相隔离判断容易割裂指令跟随稳定度能不能严格按我要求的JSON格式输出结果这对后续自动化处理至关重要成本与速度的平衡审核是批量任务单价哪怕差一分钱乘以一万个SKU都是大数字实测下来蓝耘元生代上的主力模型在长文本抽取和结构化输出上表现稳定基本满足需求。遇到“疑似有问题但判断不准”的情况我会再切到另一个更强的推理模型做二次复核双模型交叉确认。2.3 整体流程设计整套体检流程我设计成五个环节各环节之间通过JSON数据传递方便做日志回溯输入标准化把不同格式的资料包统一转为纯文本解析抽取用模型从文本中提取商品信息、证照信息、授权链信息规则比对将提取结果与最新的审核规则库逐项匹配生成风险点结构化输出生成包含风险等级、问题描述、引用原文的JSON报告人工复核审核员只看报告中标红的部分做最终判定这个流程的核心思路是“人管规则、模型管执行”。规则库由人维护但逐条跑规则的脏活累活交给模型。3. 实操过程与核心环节实现3.1 资料包标准化与预处理实际拿到的资料包格式五花八门有Word文档、有扫描版PDF、有图片合集、甚至还有Excel里塞了备注的。模型再好也不能直接啃二进制文件所以第一步必须做文本抽取。我踩过的一个坑是用通用的PDF解析库直接抽扫描版PDF抽出来的全是乱码——因为那是图片不是文字。后来加了OCR步骤先检测PDF是否含文本层没有的话先跑一遍OCR再送进模型。这里推荐用PaddleOCR对中文证照类图片的支持比较成熟。实测下来营业执照这类制式文档OCR准确率很高但用蓝耘元生代这样的大模型对OCR结果做二次校验能再捞回不少因为印章遮挡或者折痕导致识别偏差的内容。import pdfplumber import paddleocr from pathlib import Path def extract_text_from_pdf(pdf_path: str) - str: text_parts [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 提取文本层内容 page_text page.extract_text() if page_text and page_text.strip(): text_parts.append(page_text) else: # 无文本层判定为扫描件走OCR ocr_text ocr_page(page) text_parts.append(ocr_text) return \n.join(text_parts) def ocr_page(page) - str: # 将PDF页面转为图片后调用OCR import fitz pix page.to_image(resolution300) image_path temp_page.png pix.save(image_path) ocr paddleocr.PaddleOCR(use_angle_clsTrue, show_logFalse) result ocr.ocr(image_path, clsTrue) lines [line[1][0] for line in result if line] return \n.join(lines)注意OCR的图片分辨率一定要设到300dpi以上否则盖章和小的文字容易糊在一起。这块偷懒后面模型识别起来会非常痛苦。3.2 Prompt设计把审核规则翻译成检测指令这是整个项目中最重要的部分没有之一。同样一个模型Prompt写得烂和写得好的效果差距是数量级的。我维护了一个“审核规则库”把平台最新规则、广告法禁词、品类特殊要求全部拆成一条一条原子规则。然后通过Prompt把规则库注入给模型让它扮演“电商合规审核专家”对资料包进行逐条检查。Prompt结构分五层# 角色 你是一名资深的电商合规审核专家熟悉国内主流电商平台的运营规则。 今天请你协助我完成一份商品资料包的合规体检。 # 规则库 以下是本次审核需要遵守的规则 ## 规则1商品标题不得出现绝对化用语包括但不限于国家级、最高级、最佳、第一、顶级、最新、全面、全网领先等。 ## 规则2普通商品非药品/医疗器械详情页不得出现疾病治疗相关表述包括但不限于治疗、治愈、修复、根除、药效等。 ## 规则3若商品类目为化妆品不得出现“消炎”“杀菌”“祛疤”等医疗功效表述。 ## 规则4营业执照需在有效期内。当前日期为{today}。 ## 规则5品牌授权书中的授权有效期需覆盖当前日期且授权方、被授权方名称需与营业执照主体一致。 # 审核对象 以下是需要审核的商品资料包内容: {input_text} # 输出要求 请按以下JSON格式输出审核结果不要输出除JSON外的任何内容 { summary: 资料包整体评估简述, risk_items: [ { rule_id: 触发规则的编号, risk_level: high/medium/low, location: 问题出现的具体位置如商品标题、详情页第2段、营业执照, evidence: 触发规则的具体原文, risk_reason: 判断依据的简要说明 } ], suggestions: [整改建议1, 整改建议2] }规则库是动态的每次审核前用代码把最新的规则库渲染进Prompt模板。这样即使规则更新也不需要改动业务流程只需要更新规则记录就行。一个重要的经验是不要依赖模型“记住”法规原文把规则完整写在Prompt里让它“查”而不是“背”。模型训练数据里的法规记忆并不可靠尤其是在各平台细则快速更新的时候直接告诉它规则是什么准确率会高很多。3.3 批量处理与结构化结果单份资料包处理好之后批量跑就是时间问题了。我用Python写了个批量调度脚本用并发请求同时处理多个资料包再对结果做汇总。import json import asyncio from openai import AsyncOpenAI client AsyncOpenAI( api_keyyour_lanyun_api_key, base_urlhttps://your-endpoint.example.com/v1 # 蓝耘元生代控制台获取 ) # 这里直接填写你在蓝耘元生代控制台创建的服务接入地址 # 不同模型对应不同的model_name可以在平台控制台查看 async def audit_product(product_text: str, rules: str, model_name: str) - dict: prompt build_prompt(rules, product_text) resp await client.chat.completions.create( modelmodel_name, messages[ {role: system, content: 你是一个严谨的合规审核助手只输出JSON。}, {role: user, content: prompt} ], response_format{type: json_object}, temperature0.1 ) return json.loads(resp.choices[0].message.content) async def batch_audit(product_packages: list[dict], model_name: str, concurrency5): sem asyncio.Semaphore(concurrency) async def worker(pkg): async with sem: result await audit_product(pkg[text], pkg[rules], model_name) return {id: pkg[id], result: result} tasks [worker(pkg) for pkg in product_packages] results await asyncio.gather(*tasks) return results并发数不建议调太高。别贪心一次性塞50个并发进去模型接口会限流报错之后还得重试反而更慢。我调下来5到10个并发是性价比最高的区间。这份代码建议用异步而不是多线程因为这里瓶颈是网络IO等待模型返回异步非阻塞能更高效地利用等待时间。多线程在这种场景下反而容易因为GIL和线程切换损耗性能。这个差别在小批量时感觉不大跑上百份资料包时差距就明显了。3.4 用蓝耘元生代MaaS从零搭建Flask Web应用让审核自助化脚本跑通之后我又做了个增强用蓝耘元生代MaaS平台的接口把审核能力包装成一个简单的Flask Web应用让运营同学可以自助上传资料包不用每次找我跑脚本。这个应用的架构很简单前端上传页面 Flask后端 蓝耘元生代模型API。核心代码量不大主要是解决了两个实际问题让非技术同事也能用以及固化审核流程避免人为误操作。from flask import Flask, request, jsonify, render_template import json app Flask(__name__) # 加载最新的审核规则库 with open(audit_rules.json, r, encodingutf-8) as f: RULES f.read() app.route(/, methods[GET]) def index(): return render_template(upload.html) app.route(/audit, methods[POST]) def audit(): file request.files.get(file) if not file: return jsonify({error: 未收到文件}), 400 # 读取并抽取文本 text extract_text_from_file(file) if len(text) 50: return jsonify({error: 文件内容过短请检查是否为有效的资料包}), 400 # 调用蓝耘元生代进行合规体检 result asyncio.run(audit_product(text, RULES, your_model_name)) # 计算风险等级汇总 risk_count {high: 0, medium: 0, low: 0} for item in result.get(risk_items, []): level item.get(risk_level, low) risk_count[level] risk_count.get(level, 0) 1 # 将结果写入数据库或文件方便后续追溯 save_audit_log(file.filename, result) return jsonify({ risk_summary: risk_count, detail: result }) if __name__ __main__: app.run(host0.0.0.0, port8000, debugFalse)前端页面更简单一个文件上传框 一个提交按钮 结果显示区域。整体从零搭完不到两百行代码工作量主要在Prompt调优和规则库维护上Web壳子本身没什么难度。我把这个应用部署在了一个内网的小服务器上运营同事现在每天上班直接把当天的资料包拖到网页上几秒钟就能拿到一份带风险清单的报告。这一版跑通之后整个团队的审核效率明显提升终于有时间去处理真正需要人工判断的复杂情况了。3.5 巡检报表自动生成批量审核跑完后还需要把分散的结果汇总成一份决策层能看的报表。我在脚本里加了一个汇总模块把所有SKU的风险项合并成一张总表按风险等级、类目、违规类型三个维度做归类统计。报表长这样SKU类目风险等级违规类型问题来源整改状态A1001化妆品高医疗功效宣称详情页第3段待整改A1002食品中绝对化用语商品标题已完成B2031家电低证照模糊质检报告扫描件待补充这个报表我用的是最简单的方式——pandas处理数据后输出Excel。这里不建议直接让模型生成Excel文件模型擅长的是判断和抽取生成文件这种确定性工作交给代码做更稳定。4. 常见问题与排查技巧实录4.1 误报太多怎么办第一次跑全量的时候误报率高得吓人几乎每个SKU都能给你挑出七八个问题来。后来分析发现主要原因是Prompt里没有说清楚“违规判断的尺度”。比如规则1说“不得出现绝对化用语”模型就会把“最新款”这种相对表述也当成违规。但事实上“最新款”在大部分平台规则里是不违规的它表达的是“相对新”不是“绝对化”。解决办法是在每条规则后面补上“判断说明”和“豁免示例”## 规则1商品标题不得出现绝对化用语 - 违规示例全网第一、国家级、顶级产品、行业领先 - 豁免示例最新款相对概念、销量前三有具体数据支撑 - 判断说明只有当表述暗示“无可争议的绝对优势”时判定为违规有具体数据支撑的比较级表述不违规补充了这些说明后误报率下降得非常明显。核心经验是大模型需要“边界示例”来理解规则的应用范围光给抽象规则它容易发挥过头。4.2 模型“睁眼瞎”证照有效期识别不准有次抽检发现一个营业执照明明已经过期的商品模型竟然给判定为“在有效期内”。排查发现问题出在OCR环节——营业执照上的日期打印颜色浅OCR把“2023年6月30日”识别成了“2023年6月30目”模型看到“目”这种乱码也没意识到是日期识别错误就按错误日期做了判断。解决方法是加了一道“日期正则校验”在文本送入模型之前先用正则把疑似日期的片段提取出来做一次格式检测发现明显不合理的日期比如年份超出合理范围就强制打标为“疑似证照异常请人工复核”。这个问题的根因在于模型会“信任”输入文本尤其是结构规整的时间格式。如果OCR有误它不会主动怀疑数据的可信度。所以凡是涉及日期、金额、编号这类关键信息的都值得在模型之前加一道规则兜底。4.3 短文本判断太激进有的商品标题很短就十几个字“XX牌加厚垃圾袋 家用厨房用”。模型拿到这种文本时经常因为没有足够的上下文把“加厚”误判为绝对化用语。解决办法是给模型“降级”的机会在Prompt里加一句“如果信息不足无法判断是否违规请将该条目标记为low风险并在suggestions里注明需人工确认而不是直接判定违规”。意思就是让模型在该保守的时候保守不要硬下结论。电商审核这个场景里我宁可漏掉一两个疑似违规也不希望大量误报把人淹没。因为最终有真人复核漏掉的问题还有机会被捞回来但误报太多人就会疲劳反而会把真问题忽略掉。4.4 开始写Prompt后要不要开JSON模式蓝耘元生代的模型接口默认支持返回纯文本。我在最初版本没开JSON模式结果模型经常在JSON前后加上“好的以下是审核结果”这类前缀导致json.loads直接报错。后来开了response_format参数指定json_object之后模型输出就稳定多了。如果你用的模型不支持JSON模式也有一个变通方案在Prompt末尾加上一句“请直接输出纯JSON不要包含任何解释性文字不要使用Markdown代码块包裹”。实测大部分模型会照做但偶尔还是会抽风建议在解析端做容错处理。# 容错解析去掉可能的Markdown代码块包裹 import re import json def safe_parse_json(text: str) - dict: text text.strip() if text.startswith(): text re.sub(r^(?:json)?\s*, , text) text re.sub(r\s*$, , text) try: return json.loads(text) except json.JSONDecodeError: # 提取最外层大括号做兜底 match re.search(r\{.*\}, text, re.S) if match: return json.loads(match.group(0)) raise4.5 同一条规则为什么不同样品结果不一致大模型推理本身带有一定随机性即使temperature设到了0.1同一个输入跑两次结果也可能有细微差异。这在合规审核场景是有点危险的因为同一个SKU月初审核说不违规月末审核说违规没法向业务方交代。我的应对措施有两个核心规则用高置信度策略对于判断结果不确定的条目强制返回“需要人工复核”而不是给一个模糊的倾向性结论其次每次审核结果都带上下次审核的完整会话内容相当于让模型“记住上次的判断”减少随机波动。虽然不能完全消除差异但实际运行中关键高风险条目的判断一致性已经足够满足使用。5. 效果复盘与落地经验5.1 时间成本对比跑通全流程后我特意做了一次时间对比测试。选20份资料包分别用纯人工和这套自动化流程走一遍环节纯人工自动化流程单份资料包平均耗时约20分钟约1.5分钟20份资料包完成时间约6.5小时约30分钟含人工复核高风险问题识别准确率与个人经验相关稳定在较高水平审核结果可追溯性依赖个人笔记全流程留痕自动化的意义不只是快更重要的是把“审核标准”变成了团队资产。以前一个老审核员离职新来的人要花几个月才能积累起足够的规则感。现在规则全部沉淀在规则库里任何人接手都能快速上手。5.2 成本账这样跑到底贵不贵很多人一听用大模型跑批量审核第一反应是“那得花多少钱”。我算过一笔账蓝耘元生代按Token计费一份普通资料包经过抽取、审核、生成报告三个阶段大概消耗3万到5万Token。按平台定价折算单份成本差不多在几毛钱到一块钱之间。对比人工核验的人力成本和时间成本这个投入完全可以接受。当然如果你每个月要审几万份资料包成本会线性上升。这时候可以考虑在Prompt里加一层预筛选逻辑先让模型快速判断“这份资料包有没有明显高风险问题”没有的话直接跳过深度审核省掉大部分Token开销。这就像先看一遍标题再决定要不要细读全文一样能省不少。5.3 这套方案的边界哪些地方不能省人工虽然自动化流程效果好但它不是万能的。以下场景我坚持保留人工介入行政处罚风险高的重大违规必须由人工确认后再定级涉及品牌方特殊授权的复杂链路模型容易出现误判图片中的隐含宣传语如详情页角落的对比图、小字注释OCR和模型容易漏掉我的原则是把模型当“最细心的实习生”用它能帮你跑完90%的工作但最后签字负责的永远是人。一点总结之外的体会这套流程跑起来之后我最直观的感受是审核这件事终于从“拼体力”变成“拼规则管理能力”了。以前花大量时间在机械核对上现在可以把精力集中在规则更新、边界案例研判和业务沟通上。根据蓝耘元生代平台最近的更新节奏后续我打算再进一步——把审核结果直接通过API接入工单系统实现“发现风险自动创建整改任务”的闭环。另外也在尝试把同类方法用到供应商资质初审、活动素材预检这些场景上。思路是一样的把专业判断结构化让大模型处理重复劳动人只做最终决策。 蓝耘元生代MaaS平台：电商合规资料包自动化核验实战
电商合规核验这类活儿干过的人都懂SKU一多光“核对资质证照是否在有效期”就能耗掉一上午。我接手资料包审核这块之后一直在找一个能把这类重复劳动真正压下来的办法。后来用蓝耘元生代这个MaaS平台做了套自动化体检流程把单份资料包的核验时间从20分钟压到一分半左右而且漏检率比我肉眼判断的时候还低。这篇文章就把整套思路和踩过的坑完整写出来给同样被审核量折磨的朋友做个参考。先说清楚这套东西的适用范围它做的是“初筛风险定位”不是替代人工最终判定。适合电商运营、合规岗、代运营公司、以及手里有几百上千个SKU需要定期巡检的人。如果你是品牌方需要按平台规则逐条核对商品详情页、资质证照、授权链路这套流程可以直接抄作业。1. 项目背景与需求拆解1.1 电商合规体检到底在审什么要压时间先得搞清楚“20分钟”花在哪了。我接手时梳理了一下一份典型的电商资料包通常包含这几块内容商品基础信息标题、卖点文案、详情页图片与说明文字证照资质营业执照、品牌授权书、质检报告、特殊品类许可证经营链路进货凭证、供应商资质、委托加工协议宣传用语详情页和主图里的绝对化用语、极限词、医疗相关表述每块内容都有对应的核查点。比如标题里出现“顶级”“第一”这类字眼详情页里出现“治疗”“药效”等医疗词汇证照扫描件模糊、有效期临近、授权链条断裂这些都是要标红的点。1.2 人工核验为什么这么慢慢不是审核员懒而是流程本身太碎。我实测过标准操作路径打开商品链接截图、下载资料包附件、逐页翻PDF找关键信息、切到规则文档确认当前平台禁词清单、再把发现的问题一条条录入Excel一个流程跑下来十五到二十分钟很正常。更麻烦的是规则本身一直在变。平台每个季度会更新细则可能这个月还允许的表述下个月就进了禁词库。人工核验得始终保持“最新规则”在脑子里这对人的要求其实非常高。1.3 为什么这件事适合交给大模型大模型在“套规则、找异常”这件事上天然有优势。它擅长把一段模糊的自然语言规则比如“不得出现表示绝对化的用语”转化为具体的判断动作见到“全网第一”就报警。之前也试过用正则表达式写禁词匹配效果一般——规则一多正则维护成本就失控而且很多问题不是“词命中”而是“语义违规”。比如“用了它皮肤变得非常好”这句话没有极限词但放在化妆品类目里就涉嫌功效宣称过度。正则抓不住这种问题大模型可以。2. 方案设计与工具选型2.1 为什么选蓝耘元生代而不是本地部署选型时我对比过三条路线纯开源模型本地部署、通用大模型API直连、蓝耘元生代这种MaaS平台。本地部署最先被否掉。我们即便只跑7B或13B量级的模型也需要一张像样的显卡来保证推理速度更别提还得有人维护推理服务、处理并发、做模型更新。电商合规这种需求一个月可能只有月初和月底两个高峰为了高峰期去运维一套本地推理集群成本完全划不来。通用大模型API直连我也试过一阵子效果不差但要命的是“平台绑定”太死。我有好几个模型供应商的Key接口风格各不相同每次想换一个更强的模型试试都要重新改造代码里的请求格式和解析逻辑非常痛苦。蓝耘元生代这种MaaS平台的优势在于它把多个模型放在同一个接入框架里我只需要对着它统一的OpenAI兼容接口写一次代码之后换模型就只是改个模型名的事。另外一点MaaS平台本身负责底层算力调度和模型运维出问题不用我半夜爬起来看日志排查推理服务挂了没有。我只需要关心业务逻辑本身也就是提示词和数据流的设计。2.2 模型选型逻辑蓝耘元生代平台上可选的模型不少我最终固定下来主用长文本能力强的模型原因是资料包动辄十几页PDF需要一次性塞进上下文才能做全局判断。选模型我主要看三个维度上下文窗口必须能容纳完整的资料包文本内容否则得拆分着来规则之间互相隔离判断容易割裂指令跟随稳定度能不能严格按我要求的JSON格式输出结果这对后续自动化处理至关重要成本与速度的平衡审核是批量任务单价哪怕差一分钱乘以一万个SKU都是大数字实测下来蓝耘元生代上的主力模型在长文本抽取和结构化输出上表现稳定基本满足需求。遇到“疑似有问题但判断不准”的情况我会再切到另一个更强的推理模型做二次复核双模型交叉确认。2.3 整体流程设计整套体检流程我设计成五个环节各环节之间通过JSON数据传递方便做日志回溯输入标准化把不同格式的资料包统一转为纯文本解析抽取用模型从文本中提取商品信息、证照信息、授权链信息规则比对将提取结果与最新的审核规则库逐项匹配生成风险点结构化输出生成包含风险等级、问题描述、引用原文的JSON报告人工复核审核员只看报告中标红的部分做最终判定这个流程的核心思路是“人管规则、模型管执行”。规则库由人维护但逐条跑规则的脏活累活交给模型。3. 实操过程与核心环节实现3.1 资料包标准化与预处理实际拿到的资料包格式五花八门有Word文档、有扫描版PDF、有图片合集、甚至还有Excel里塞了备注的。模型再好也不能直接啃二进制文件所以第一步必须做文本抽取。我踩过的一个坑是用通用的PDF解析库直接抽扫描版PDF抽出来的全是乱码——因为那是图片不是文字。后来加了OCR步骤先检测PDF是否含文本层没有的话先跑一遍OCR再送进模型。这里推荐用PaddleOCR对中文证照类图片的支持比较成熟。实测下来营业执照这类制式文档OCR准确率很高但用蓝耘元生代这样的大模型对OCR结果做二次校验能再捞回不少因为印章遮挡或者折痕导致识别偏差的内容。import pdfplumber import paddleocr from pathlib import Path def extract_text_from_pdf(pdf_path: str) - str: text_parts [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 提取文本层内容 page_text page.extract_text() if page_text and page_text.strip(): text_parts.append(page_text) else: # 无文本层判定为扫描件走OCR ocr_text ocr_page(page) text_parts.append(ocr_text) return \n.join(text_parts) def ocr_page(page) - str: # 将PDF页面转为图片后调用OCR import fitz pix page.to_image(resolution300) image_path temp_page.png pix.save(image_path) ocr paddleocr.PaddleOCR(use_angle_clsTrue, show_logFalse) result ocr.ocr(image_path, clsTrue) lines [line[1][0] for line in result if line] return \n.join(lines)注意OCR的图片分辨率一定要设到300dpi以上否则盖章和小的文字容易糊在一起。这块偷懒后面模型识别起来会非常痛苦。3.2 Prompt设计把审核规则翻译成检测指令这是整个项目中最重要的部分没有之一。同样一个模型Prompt写得烂和写得好的效果差距是数量级的。我维护了一个“审核规则库”把平台最新规则、广告法禁词、品类特殊要求全部拆成一条一条原子规则。然后通过Prompt把规则库注入给模型让它扮演“电商合规审核专家”对资料包进行逐条检查。Prompt结构分五层# 角色 你是一名资深的电商合规审核专家熟悉国内主流电商平台的运营规则。 今天请你协助我完成一份商品资料包的合规体检。 # 规则库 以下是本次审核需要遵守的规则 ## 规则1商品标题不得出现绝对化用语包括但不限于国家级、最高级、最佳、第一、顶级、最新、全面、全网领先等。 ## 规则2普通商品非药品/医疗器械详情页不得出现疾病治疗相关表述包括但不限于治疗、治愈、修复、根除、药效等。 ## 规则3若商品类目为化妆品不得出现“消炎”“杀菌”“祛疤”等医疗功效表述。 ## 规则4营业执照需在有效期内。当前日期为{today}。 ## 规则5品牌授权书中的授权有效期需覆盖当前日期且授权方、被授权方名称需与营业执照主体一致。 # 审核对象 以下是需要审核的商品资料包内容: {input_text} # 输出要求 请按以下JSON格式输出审核结果不要输出除JSON外的任何内容 { summary: 资料包整体评估简述, risk_items: [ { rule_id: 触发规则的编号, risk_level: high/medium/low, location: 问题出现的具体位置如商品标题、详情页第2段、营业执照, evidence: 触发规则的具体原文, risk_reason: 判断依据的简要说明 } ], suggestions: [整改建议1, 整改建议2] }规则库是动态的每次审核前用代码把最新的规则库渲染进Prompt模板。这样即使规则更新也不需要改动业务流程只需要更新规则记录就行。一个重要的经验是不要依赖模型“记住”法规原文把规则完整写在Prompt里让它“查”而不是“背”。模型训练数据里的法规记忆并不可靠尤其是在各平台细则快速更新的时候直接告诉它规则是什么准确率会高很多。3.3 批量处理与结构化结果单份资料包处理好之后批量跑就是时间问题了。我用Python写了个批量调度脚本用并发请求同时处理多个资料包再对结果做汇总。import json import asyncio from openai import AsyncOpenAI client AsyncOpenAI( api_keyyour_lanyun_api_key, base_urlhttps://your-endpoint.example.com/v1 # 蓝耘元生代控制台获取 ) # 这里直接填写你在蓝耘元生代控制台创建的服务接入地址 # 不同模型对应不同的model_name可以在平台控制台查看 async def audit_product(product_text: str, rules: str, model_name: str) - dict: prompt build_prompt(rules, product_text) resp await client.chat.completions.create( modelmodel_name, messages[ {role: system, content: 你是一个严谨的合规审核助手只输出JSON。}, {role: user, content: prompt} ], response_format{type: json_object}, temperature0.1 ) return json.loads(resp.choices[0].message.content) async def batch_audit(product_packages: list[dict], model_name: str, concurrency5): sem asyncio.Semaphore(concurrency) async def worker(pkg): async with sem: result await audit_product(pkg[text], pkg[rules], model_name) return {id: pkg[id], result: result} tasks [worker(pkg) for pkg in product_packages] results await asyncio.gather(*tasks) return results并发数不建议调太高。别贪心一次性塞50个并发进去模型接口会限流报错之后还得重试反而更慢。我调下来5到10个并发是性价比最高的区间。这份代码建议用异步而不是多线程因为这里瓶颈是网络IO等待模型返回异步非阻塞能更高效地利用等待时间。多线程在这种场景下反而容易因为GIL和线程切换损耗性能。这个差别在小批量时感觉不大跑上百份资料包时差距就明显了。3.4 用蓝耘元生代MaaS从零搭建Flask Web应用让审核自助化脚本跑通之后我又做了个增强用蓝耘元生代MaaS平台的接口把审核能力包装成一个简单的Flask Web应用让运营同学可以自助上传资料包不用每次找我跑脚本。这个应用的架构很简单前端上传页面 Flask后端 蓝耘元生代模型API。核心代码量不大主要是解决了两个实际问题让非技术同事也能用以及固化审核流程避免人为误操作。from flask import Flask, request, jsonify, render_template import json app Flask(__name__) # 加载最新的审核规则库 with open(audit_rules.json, r, encodingutf-8) as f: RULES f.read() app.route(/, methods[GET]) def index(): return render_template(upload.html) app.route(/audit, methods[POST]) def audit(): file request.files.get(file) if not file: return jsonify({error: 未收到文件}), 400 # 读取并抽取文本 text extract_text_from_file(file) if len(text) 50: return jsonify({error: 文件内容过短请检查是否为有效的资料包}), 400 # 调用蓝耘元生代进行合规体检 result asyncio.run(audit_product(text, RULES, your_model_name)) # 计算风险等级汇总 risk_count {high: 0, medium: 0, low: 0} for item in result.get(risk_items, []): level item.get(risk_level, low) risk_count[level] risk_count.get(level, 0) 1 # 将结果写入数据库或文件方便后续追溯 save_audit_log(file.filename, result) return jsonify({ risk_summary: risk_count, detail: result }) if __name__ __main__: app.run(host0.0.0.0, port8000, debugFalse)前端页面更简单一个文件上传框 一个提交按钮 结果显示区域。整体从零搭完不到两百行代码工作量主要在Prompt调优和规则库维护上Web壳子本身没什么难度。我把这个应用部署在了一个内网的小服务器上运营同事现在每天上班直接把当天的资料包拖到网页上几秒钟就能拿到一份带风险清单的报告。这一版跑通之后整个团队的审核效率明显提升终于有时间去处理真正需要人工判断的复杂情况了。3.5 巡检报表自动生成批量审核跑完后还需要把分散的结果汇总成一份决策层能看的报表。我在脚本里加了一个汇总模块把所有SKU的风险项合并成一张总表按风险等级、类目、违规类型三个维度做归类统计。报表长这样SKU类目风险等级违规类型问题来源整改状态A1001化妆品高医疗功效宣称详情页第3段待整改A1002食品中绝对化用语商品标题已完成B2031家电低证照模糊质检报告扫描件待补充这个报表我用的是最简单的方式——pandas处理数据后输出Excel。这里不建议直接让模型生成Excel文件模型擅长的是判断和抽取生成文件这种确定性工作交给代码做更稳定。4. 常见问题与排查技巧实录4.1 误报太多怎么办第一次跑全量的时候误报率高得吓人几乎每个SKU都能给你挑出七八个问题来。后来分析发现主要原因是Prompt里没有说清楚“违规判断的尺度”。比如规则1说“不得出现绝对化用语”模型就会把“最新款”这种相对表述也当成违规。但事实上“最新款”在大部分平台规则里是不违规的它表达的是“相对新”不是“绝对化”。解决办法是在每条规则后面补上“判断说明”和“豁免示例”## 规则1商品标题不得出现绝对化用语 - 违规示例全网第一、国家级、顶级产品、行业领先 - 豁免示例最新款相对概念、销量前三有具体数据支撑 - 判断说明只有当表述暗示“无可争议的绝对优势”时判定为违规有具体数据支撑的比较级表述不违规补充了这些说明后误报率下降得非常明显。核心经验是大模型需要“边界示例”来理解规则的应用范围光给抽象规则它容易发挥过头。4.2 模型“睁眼瞎”证照有效期识别不准有次抽检发现一个营业执照明明已经过期的商品模型竟然给判定为“在有效期内”。排查发现问题出在OCR环节——营业执照上的日期打印颜色浅OCR把“2023年6月30日”识别成了“2023年6月30目”模型看到“目”这种乱码也没意识到是日期识别错误就按错误日期做了判断。解决方法是加了一道“日期正则校验”在文本送入模型之前先用正则把疑似日期的片段提取出来做一次格式检测发现明显不合理的日期比如年份超出合理范围就强制打标为“疑似证照异常请人工复核”。这个问题的根因在于模型会“信任”输入文本尤其是结构规整的时间格式。如果OCR有误它不会主动怀疑数据的可信度。所以凡是涉及日期、金额、编号这类关键信息的都值得在模型之前加一道规则兜底。4.3 短文本判断太激进有的商品标题很短就十几个字“XX牌加厚垃圾袋 家用厨房用”。模型拿到这种文本时经常因为没有足够的上下文把“加厚”误判为绝对化用语。解决办法是给模型“降级”的机会在Prompt里加一句“如果信息不足无法判断是否违规请将该条目标记为low风险并在suggestions里注明需人工确认而不是直接判定违规”。意思就是让模型在该保守的时候保守不要硬下结论。电商审核这个场景里我宁可漏掉一两个疑似违规也不希望大量误报把人淹没。因为最终有真人复核漏掉的问题还有机会被捞回来但误报太多人就会疲劳反而会把真问题忽略掉。4.4 开始写Prompt后要不要开JSON模式蓝耘元生代的模型接口默认支持返回纯文本。我在最初版本没开JSON模式结果模型经常在JSON前后加上“好的以下是审核结果”这类前缀导致json.loads直接报错。后来开了response_format参数指定json_object之后模型输出就稳定多了。如果你用的模型不支持JSON模式也有一个变通方案在Prompt末尾加上一句“请直接输出纯JSON不要包含任何解释性文字不要使用Markdown代码块包裹”。实测大部分模型会照做但偶尔还是会抽风建议在解析端做容错处理。# 容错解析去掉可能的Markdown代码块包裹 import re import json def safe_parse_json(text: str) - dict: text text.strip() if text.startswith(): text re.sub(r^(?:json)?\s*, , text) text re.sub(r\s*$, , text) try: return json.loads(text) except json.JSONDecodeError: # 提取最外层大括号做兜底 match re.search(r\{.*\}, text, re.S) if match: return json.loads(match.group(0)) raise4.5 同一条规则为什么不同样品结果不一致大模型推理本身带有一定随机性即使temperature设到了0.1同一个输入跑两次结果也可能有细微差异。这在合规审核场景是有点危险的因为同一个SKU月初审核说不违规月末审核说违规没法向业务方交代。我的应对措施有两个核心规则用高置信度策略对于判断结果不确定的条目强制返回“需要人工复核”而不是给一个模糊的倾向性结论其次每次审核结果都带上下次审核的完整会话内容相当于让模型“记住上次的判断”减少随机波动。虽然不能完全消除差异但实际运行中关键高风险条目的判断一致性已经足够满足使用。5. 效果复盘与落地经验5.1 时间成本对比跑通全流程后我特意做了一次时间对比测试。选20份资料包分别用纯人工和这套自动化流程走一遍环节纯人工自动化流程单份资料包平均耗时约20分钟约1.5分钟20份资料包完成时间约6.5小时约30分钟含人工复核高风险问题识别准确率与个人经验相关稳定在较高水平审核结果可追溯性依赖个人笔记全流程留痕自动化的意义不只是快更重要的是把“审核标准”变成了团队资产。以前一个老审核员离职新来的人要花几个月才能积累起足够的规则感。现在规则全部沉淀在规则库里任何人接手都能快速上手。5.2 成本账这样跑到底贵不贵很多人一听用大模型跑批量审核第一反应是“那得花多少钱”。我算过一笔账蓝耘元生代按Token计费一份普通资料包经过抽取、审核、生成报告三个阶段大概消耗3万到5万Token。按平台定价折算单份成本差不多在几毛钱到一块钱之间。对比人工核验的人力成本和时间成本这个投入完全可以接受。当然如果你每个月要审几万份资料包成本会线性上升。这时候可以考虑在Prompt里加一层预筛选逻辑先让模型快速判断“这份资料包有没有明显高风险问题”没有的话直接跳过深度审核省掉大部分Token开销。这就像先看一遍标题再决定要不要细读全文一样能省不少。5.3 这套方案的边界哪些地方不能省人工虽然自动化流程效果好但它不是万能的。以下场景我坚持保留人工介入行政处罚风险高的重大违规必须由人工确认后再定级涉及品牌方特殊授权的复杂链路模型容易出现误判图片中的隐含宣传语如详情页角落的对比图、小字注释OCR和模型容易漏掉我的原则是把模型当“最细心的实习生”用它能帮你跑完90%的工作但最后签字负责的永远是人。一点总结之外的体会这套流程跑起来之后我最直观的感受是审核这件事终于从“拼体力”变成“拼规则管理能力”了。以前花大量时间在机械核对上现在可以把精力集中在规则更新、边界案例研判和业务沟通上。根据蓝耘元生代平台最近的更新节奏后续我打算再进一步——把审核结果直接通过API接入工单系统实现“发现风险自动创建整改任务”的闭环。另外也在尝试把同类方法用到供应商资质初审、活动素材预检这些场景上。思路是一样的把专业判断结构化让大模型处理重复劳动人只做最终决策。