电商资料包的合规核验是很多做店铺运营、类目审核、供应链对接的人绕不开的一道工序。所谓资料包通常包含商品详情页文案、主图与详情图的文字信息、资质证照扫描件、检测报告、授权链路文件、品牌授权书、进口报关资料等一堆东西。过去我们团队的做法是人工逐份翻一份中等规模的资料包二十来分钟是常态遇到图片里嵌字的还得放大看眼睛都花了还容易漏。这次我拿蓝耘元生代的 MaaS 接口做了一套自动化的合规体检流程把单份资料包的核验时间压到了一分半左右而且漏检率明显下降。这篇就把整套思路、接口选型、提示词设计、踩过的坑以及怎么把结果落成可复核的报告完整讲一遍。1. 先搞清楚资料包合规体检到底在查什么1.1 合规核验的四类高频问题很多人一上来就想调模型其实第一步应该是把查什么定义清楚。资料包合规体检不是笼统地看有没有问题而是要拆成可判定的检查项。我们实际业务里问题集中在四类绝对化用语与违禁词比如最字头、第一、国家级、全网最低这类表述在商品文案里出现就是高风险。资质与文案的一致性检测报告上的产品名称、型号、执行标准和详情页宣称的是否对得上。这一条人工最容易漏因为要跨文件比对。证照有效期与主体一致性营业执照、授权书的有效期是否覆盖当前时间授权方与被授权方是否和店铺主体对得上。图片内嵌文字主图、详情图里直接P上去的文字纯文本提取拿不到必须走多模态识别。把这四类列清楚之后你才会知道为什么单一模型搞不定——纯文本模型处理不了图片纯多模态模型做长文档比对又不够稳。这也是后面要讲多模型组合的原因。1.2 为什么人工核验要二十分钟我专门掐过表。一份包含 12 张详情图、3 份 PDF 资质、1 份授权书的资料包人工流程是这样的打开每张图看文字约 6 分钟、翻 PDF 找关键字段约 5 分钟、跨文件比对名称和型号约 5 分钟、记录问题并写备注约 4 分钟。加起来二十分钟出头。瓶颈不在看而在比对和记录。人眼在多个文件之间来回切换时工作记忆会衰减看第三份文件时已经记不清第一份的型号了。所以自动化的价值不只是快更是把比对这个动作交给不会疲劳的机器。1.3 一分半是怎么算出来的目标时间拆解图片文字识别并发处理约 20 秒长文档结构化抽取约 30 秒跨文件一致性比对约 20 秒报告生成约 20 秒。合计约 90 秒。这里的关键是并发和结构化输出——如果串行调用光等接口返回就不止一分半。所以整套方案的设计核心是能并发的绝不串行能让模型直接吐 JSON 的绝不让它吐自然语言再解析。2. 蓝耘元生代 MaaS 的接入准备与模型选型2.1 API Key 的获取与最小权限管理接入第一步是拿 API Key。蓝耘元生代的控制台里创建密钥后建议按用途拆分成多个 Key比如图片识别专用文档抽取专用比对专用而不是全项目共用一个。原因很实际一旦某个环节的调用量异常你能快速定位是哪个 Key 出的问题也方便单独限流。Key 的存放千万别硬编码在代码里。我见过太多人直接把 Key 写进 Flask 的配置文件然后提交到代码仓库这是大忌。正确做法是走环境变量export LANYUN_API_KEY_OCRyour_ocr_key export LANYUN_API_KEY_DOCyour_doc_key export LANYUN_API_KEY_CMPyour_cmp_key代码里用os.environ.get()读取。如果团队有密钥管理服务优先接那个环境变量只是最低要求。注意调用时如果返回api_key_required或401 unauthorized先别急着怀疑 Key 失效八成是请求头里没带对。Authorization 头的格式是Bearer 你的Key中间那个空格经常被漏掉这个坑我踩过。2.2 模型选型qwen3.8-max 与 qwen3.5-omni-plus 的分工这次用到两个主力模型分工很明确模型承担任务选它的理由qwen3.5-omni-plus图片内嵌文字识别、图文混合理解多模态能力强能直接读图里的文字并理解上下文qwen3.8-max长文档结构化抽取、跨文件一致性比对长上下文稳定指令遵循好适合输出严格 JSON为什么不用一个模型全包因为多模态模型在处理超长纯文本比对时成本更高且稳定性不如纯文本旗舰模型而纯文本模型又读不了图。分开用各司其职整体成本和准确率都更优。选型时我还对比过其他几个模型结论是图片识别优先看多模态能力文档比对优先看长上下文和 JSON 输出稳定性。不要只看参数规模实际跑一批真实样本比什么都准。2.3 请求封装统一客户端与重试策略所有调用我都封装在一个统一的客户端里核心是三点超时设置、重试、错误分类。import os import time import requests class LanyunClient: def __init__(self, api_key, base_url, timeout60, max_retries3): self.api_key api_key self.base_url base_url self.timeout timeout self.max_retries max_retries def chat(self, model, messages, temperature0.1): headers { Authorization: fBearer {self.api_key}, Content-Type: application/json } payload { model: model, messages: messages, temperature: temperature } last_err None for attempt in range(self.max_retries): try: resp requests.post( f{self.base_url}/chat/completions, headersheaders, jsonpayload, timeoutself.timeout ) if resp.status_code 200: return resp.json() if resp.status_code in (429, 500, 502, 503): time.sleep(2 ** attempt) continue resp.raise_for_status() except requests.RequestException as e: last_err e time.sleep(2 ** attempt) raise RuntimeError(f调用失败: {last_err})temperature设成 0.1 是刻意的——合规核验要的是稳定复现不是创意发挥。同样的输入必须给出同样的判定否则复核时没法解释。3. 把资料包拆成可并行处理的流水线3.1 输入归一化图片、PDF、纯文本分流资料包进来的时候格式是乱的。我的处理逻辑是先分流图片类jpg/png/webp→ 走多模态识别PDF 类 → 先判断是扫描件还是文本型扫描件转图片走多模态文本型直接抽文字纯文本类txt/docx→ 直接进文档抽取这一步看着简单但分流错了后面全错。比如把扫描件 PDF 当文本型处理抽出来是空的模型就会幻觉出一堆不存在的内容。判断方法用 PDF 解析库尝试抽文字如果抽出的字符数少于阈值比如每页少于 50 字就判定为扫描件。3.2 并发调度为什么用线程池而不是串行前面算过串行调用光等待就超时。图片识别和文档抽取之间没有依赖关系完全可以并发。我用concurrent.futures.ThreadPoolExecutor控制并发数from concurrent.futures import ThreadPoolExecutor, as_completed def process_package(files): results {} with ThreadPoolExecutor(max_workers6) as executor: future_map {} for f in files: if f.type image: future_map[executor.submit(ocr_image, f)] (ocr, f.name) elif f.type doc: future_map[executor.submit(extract_doc, f)] (doc, f.name) for future in as_completed(future_map): kind, name future_map[future] try: results[name] future.result() except Exception as e: results[name] {error: str(e)} return resultsmax_workers设 6 是实测下来的平衡点。设太高会触发限流设太低又浪费并发能力。这个值要根据你账号的配额调整别照抄。3.3 中间结果落盘为复核留证据链每个环节的原始返回我都存一份到本地按资料包ID/环节/文件名.json组织。为什么因为合规核验的结果是要给人复核的如果只存最终结论复核的人问你凭什么判定这行字违规你拿不出证据。存了原始返回就能追溯到具体是哪张图、哪段文字触发的判定。这一步还顺带解决了调试问题。模型偶尔抽风给出奇怪结果时翻原始返回比重新跑一遍快得多。4. 提示词设计让模型稳定吐出可判定的结果4.1 结构化输出强制 JSON 而不是自然语言这是整套方案里最影响效率的一个决定。如果让模型用自然语言回答这份资料有没有问题你还得再写一层解析逻辑而且解析本身就会出错。直接要求 JSON{ check_items: [ { type: absolute_wording, hit: true, evidence: 全网最低价, location: 详情图3, risk_level: high } ], summary: 发现1处绝对化用语 }提示词里要明确写只输出 JSON不要任何解释性文字不要 markdown 代码块标记。实测下来加了这句之后解析成功率从七成提到九成五以上。4.2 分而治之每类检查项单独一次调用一开始我想让模型一次调用把所有检查项都做了结果准确率很差——模型会顾此失彼。后来改成每类检查项单独调用违禁词一次、一致性比对一次、有效期检查一次。虽然调用次数多了但每次任务单一准确率大幅提升而且并发跑起来总耗时没增加多少。这背后的逻辑是模型的注意力是有限资源任务越聚焦表现越稳。这跟人一样你让一个人同时查五件事他每件都查不细。4.3 少样本示例给模型一个判定标准光说检查绝对化用语不够模型对边界的理解和你不一样。我在提示词里塞了两三个示例明确告诉它什么算命中、什么不算品质优良 → 不命中普通描述全网最优 → 命中绝对化销量领先 → 命中无法证实的排他性表述给了示例之后误报率明显下降。尤其是领先优选这类模糊词没有示例模型会乱判。4.4 温度与随机性控制前面提过temperature0.1。这里再强调一次合规判定必须可复现。如果同一个资料包今天判合规、明天判违规这套系统就没法用。低温度是保证稳定性的基础配合固定的提示词模板基本能做到同输入同输出。5. 跨文件一致性比对最容易出错的一环5.1 抽取关键字段而不是全文比对一致性比对如果拿全文去比又慢又不准。正确做法是先抽取关键字段产品名称、型号、执行标准、生产商、授权方、被授权方、有效期。把这些字段结构化成一张表再比对。{ product_name: XX牌空气净化器, model: KJ-500, standard: GB/T 18801, manufacturer: XX电器有限公司, valid_until: 2026-12-31 }字段抽取本身也是一次模型调用提示词里明确列出要抽哪些字段、每个字段的格式要求。5.2 比对逻辑规则引擎兜底模型处理模糊情况字段抽出来之后比对分两层精确比对型号、标准号这种直接字符串比对不一致就报。模糊比对产品名称这种可能有简称全称差异交给模型判断是否指同一产品。为什么不全交给模型因为精确字段用规则比对又快又准没必要浪费模型调用。模型只处理它擅长的模糊判断。这个分工能省下大量成本。5.3 处理模型说一致但实际不一致的情况这是最危险的错误类型——漏报。我的应对是关键字段双检型号、标准号这类硬字段除了模型抽取再用正则从原文里捞一遍两者结果交叉验证。如果模型抽的和正则捞的不一致就标记为待人工确认不直接下结论。这个双检机制救过我好几次。有一次模型把型号里的字母 O 识别成了数字 0正则捞出来的是正确的交叉验证直接暴露了问题。6. 实测中的坑与排查链路6.1 图片文字识别漏字从分辨率查到压缩第一批测试时发现详情图里的文字经常漏识别。排查链路是这样的先怀疑模型能力换了个更大的多模态模型还是漏然后怀疑图片本身把原图放大看发现文字清晰最后查传输环节发现是上传前做了压缩文字边缘糊了。解决办法上传前不做有损压缩或者压缩质量设到 90 以上。图片识别对清晰度极其敏感省那点带宽不值得。6.2 长文档截断上下文窗口的边界有份 PDF 资质特别长抽取结果只覆盖了前半部分。原因是超过了模型的上下文窗口。解决办法是分段抽取再合并按页切分每段单独抽取字段最后合并去重。合并时如果同一字段出现多个值标记为冲突待确认。这里要注意分段不能按固定字符数硬切会切断字段。按页或按段落切更合理。6.3 返回格式不稳定解析失败的兜底即使提示词写了只输出 JSON模型偶尔还是会加一句好的以下是结果。我的兜底逻辑是先用正则从返回里提取第一个{到最后一个}之间的内容再解析。如果还失败就把原始返回存下来并标记该环节失败走人工。import json import re def safe_parse(text): try: return json.loads(text) except json.JSONDecodeError: match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass return None这个兜底不优雅但实用。生产环境里能兜住比优雅重要。6.4 限流与超时并发数的动态调整并发跑起来后遇到过 429 限流。解决办法有两个一是把max_workers降下来二是加指数退避重试前面客户端代码里已经包含。实测下来把并发从 10 降到 6配合退避重试基本不再触发限流。提示限流阈值和账号等级有关别人的并发数不一定适合你。上线前先用小批量压测找到自己的安全并发数。7. 结果落地从 JSON 到可复核的报告7.1 报告结构问题清单加证据链最终报告不是简单罗列有问题/没问题而是每个问题都带证据问题类型、风险等级、证据原文、所在位置、原始返回的引用。这样复核的人能直接定位到具体文件的具体位置不用重新翻一遍。报告用 HTML 生成方便在浏览器里看也方便截图存档。每条问题做成可折叠的卡片默认收起点开看证据。7.2 风险分级高、中、低三档的处理策略不是所有问题都一样严重。我分了三档高风险绝对化用语、资质过期、主体不一致 → 直接拦截必须整改中风险表述模糊、字段缺失 → 提示补充低风险格式不规范 → 建议优化分级之后运营同学的处理优先级就清楚了不用在一堆问题里纠结先改哪个。7.3 人工复核的介入点自动化不是要取代人而是把人从重复劳动里解放出来专注在真正需要判断的地方。我设了三个必须人工介入的点模型判定为待确认的、双检结果冲突的、以及所有高风险项。这样人工只需要看少数几条而不是从头翻到尾。实测下来一份资料包人工复核时间从二十分钟降到三到五分钟加上自动化的九十秒整体还是比纯人工快很多而且漏检率更低。8. 成本与性能的平衡取舍8.1 调用次数与准确率的权衡前面提到每类检查项单独调用调用次数是上去了但准确率提升明显。这里有个取舍如果预算紧张可以把低风险的检查项合并调用如果准确率优先就分开。我的建议是高风险项必须单独调用低风险项可以合并。8.2 缓存相同文件不重复调用资料包里经常有重复文件比如同一份营业执照在多个资料包里出现。我用文件内容的哈希值做缓存键命中缓存直接返回上次结果。这一招在批量处理时省下的调用量相当可观。import hashlib def file_hash(path): h hashlib.sha256() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest()8.3 什么时候该放弃自动化不是所有资料包都适合自动化。如果资料包格式极其混乱、扫描件质量极差、或者包含大量手写内容自动化的准确率会掉得厉害。这种情况下与其硬上自动化然后人工返工不如直接走人工。判断标准很简单先跑一批样本如果自动化的漏检率超过你能接受的上限就老老实实人工。9. 几个我踩过之后才明白的细节第一个细节是提示词里的字段名要和代码里的键名完全一致。我一开始提示词写的是productName代码里读的是product_name结果一直取不到值排查了半天才发现是命名不一致。这种低级错误在联调阶段特别浪费时间。第二个细节是图片识别要带上业务上下文。同样是XX两个字在资质文件里可能是公司简称在详情图里可能是产品系列名。提示词里告诉模型这张图属于哪类文件识别准确率会更高。第三个细节是别信模型的自信。模型有时候会用非常肯定的语气给出错误结论。所以关键判定一定要有规则引擎或双检兜底不能全凭模型一句话。第四个细节是日志要记全。每次调用的输入、输出、耗时、token 消耗都记下来。出问题时这些日志就是你的排查依据也是优化成本的依据。我后来靠日志发现某个环节的 token 消耗异常高一查是提示词里塞了太多无关示例精简之后成本降了三成。这套流程跑顺之后我们团队的资料包核验基本实现了机器初筛加人工复核的模式效率提升是实打实的。如果你也在做类似的合规核验建议先从一类检查项跑通再逐步扩展别一上来就追求大而全。