ISO 2859-1 AQL抽样方案解析：批量分档、Ac/Re判定与Python实现

简介ISO 2859-1抽样检验标准全英文原版PDF面向质量管理、工业制造、贸易检验及服务业从业者用于规范批量产品的属性抽样检验程序帮助相关人员在制定抽样计划、选择抽样方法、抽取样本、评估检验结果与作出接收或拒收决策时有据可依。整个资源包仅包含1个PDF文件体积约3.93MB属于轻量型标准文档可直接保存、打印或导入阅读器使用PDF格式便于关键词检索、跨设备阅读与长期存档。该资料在平台已有296人学习适合需要对照国际标准原文进行质量体系搭建、供应商审核或进出口商品检验的读者。文档内含术语定义、抽样方案索引、基于接收质量限AQL的批量检验程序以及附录公式等完整内容可结合日常质量管理实践反复查阅为质量控制、成本降低和生产效率提升提供权威依据。1. 为什么物料检验系统绕不开 ISO 2859-1 的 AQL 抽样方案判定逻辑一次客户审计对方 SQE 指着系统里刚生成的抽样方案问批量 5000AQL 0.65为什么样本量是 200判定数却是 Ac3、Re4我当时按 GB/T 2828.1 的表格核了一遍样本量没错但再往深处核对发现箭头方案的处理方式和 ISO 2859-1 原文之间存在细微偏差。后来我把整套抽样方案表按 ISO 2859-1 英文原版重新整理了一遍才彻底解决问题。对质量工程师、供应链系统开发、制造企业数字化项目负责人来说这份资料的价值不在于翻译它而在于把标准里定义的批量分档、样本量字码、Ac/Re 判定和转移规则落到代码里。这篇文章会把 ISO 2859-1 里最关键的三层结构——抽样表、箭头规则、转移状态机——完整拆开并给出可以直接改造成服务的 Python 实现。2. AQL 抽样方案的三个基础概念批量分档、检验水平与字码表2.1 AQL 是过程平均的容忍线不是批次判定线把 ISO 2859-1 原文打开第一件要纠正的认知是 AQL 的定义。AQL 是 Acceptance Quality Limit标准把它描述为过程平均可容忍的最差质量水平作用是索引抽样方案。也就是说当供应商的过程平均不良率不高于 AQL 时按对应方案长期检验绝大多数批都会以高概率被接收但这不是在给单独某个批打质量保证。不少团队在做来料检验系统时直接把 AQL 值当成批次允收线不良率超过 AQL 就判退。这样做的后果是样本量越大误判越明显尤其是 AQL0.65 这类小数值批次真实不良率在 1% 左右时接收概率仍然很高这是统计特性决定的不是系统 Bug。理解了这个前提后面查表和使用转移规则时才能自洽。原文里还区分了两种质量表示方式按不合格品百分数计数和按每百单位不合格数计数。前者针对“一个产品上只要有一个问题就算不合格品”后者针对“一个产品上可能同时存在多个不同类型的不合格”。在数字化方案表时这两种方式对应的 AQL 档位不同存表时建议加一个 quality_type 字段区分避免把两种体系混在一个表里用。2.2 批量范围和检验水平决定样本量字码ISO 2859-1 的查表起点是把批量换算成样本量字码sample size code letter。批量区间与检验水平Inspection Level, IL共同决定字码。检验水平分为一般水平 I、II、III 和特殊水平 S-1 至 S-4。一般水平 II 是默认选择也是绝大多数制造企业落地时的首选特殊水平样本量极小只在破坏性检验、单体检验成本极高的场景下使用对应的判别能力也会明显下降。批量范围一般水平 I一般水平 II一般水平 III2–8AAB9–15ABC16–25BCD26–50CDE51–90CEF91–150DFG151–280EGH281–500FHJ501–1200GJK1201–3200HKL3201–10000JLM10001–35000KMN35001–150000LNP150001–500000MPQ500001 及以上NQR这是一般检验水平下批量与字码的对应关系。注意批量区间的边界处理比如批量恰好是 281应进入 H 而不是 G。系统实现时使用左闭右闭区间也就是条件写成 281 lot_size 500并且下一段从 501 开始这样不容易在边界处漏判。2.3 从字码到抽样方案Ac 与 Re 的主表逻辑拿到字码之后到主表按字码和 AQL 档位交叉查找得到一组判定数据样本量 n、接收数 Ac、拒收数 Re。一次抽样方案的判定逻辑是从批中抽取 n 个样本检验后若不合格数不超过 Ac则该批接收若达到 Re则拒绝。ISO 2859-1 规定当 Ac 和 Re 之间存在差值时抽到不合格数落在中间的情况不属于正常流程实际操作中 Re Ac 1 是最常见形态。主表里大量存在箭头。箭头表示当前字码和 AQL 组合处没有直接可用的方案必须沿箭头方向移动取第一个非空方案作为最终方案同时样本量也要改成箭头所指方案对应的样本量。常见的错误是只改 Ac/Re 不改样本量这会让整个抽样方案失去统计基础。def lookup_plan(code, aql, table): key (code, aql) if key in table: return table[key] return None这段代码展示的是精确查询逻辑key 由字码和 AQL 组成命中就直接返回方案。实际生产里我建议把箭头关系在数据准备阶段展开好运行时只做精确查找。不要在主程序里做模糊匹配也不要让程序在查不到时自动返回同字码下的任意方案那样会让 AQL 档位错配被静默吞掉。返回的方案我一般设计成三元组(n, ac, re)便于后面直接传给判定函数。3. 把 ISO 2859-1 主方案表程序化Python 查表与箭头展开实践3.1 方案表的数字化结构与 AQL 档位规律把 ISO 2859-1 的表格搬进系统我建议先按检验严格度拆成三张表正常检验表、加严检验表、放宽检验表。每张表的键用字码与 AQL 组合值为(n, ac, re)。AQL 档位本身是离散的0.10、0.15、0.25、0.40、0.65、1.0、1.5、2.5相邻两档大致呈 1.585 倍的比例。这个规律可以用来做数据校验如果某个档位值脱离了这个序列表格大概率在录入时出了问题。PLANS { normal: { (A, 0.65): (2, 0, 1), (B, 0.65): (3, 0, 1), (C, 0.65): (5, 0, 1), (D, 0.65): (8, 0, 1), (E, 0.65): (13, 0, 1), (F, 0.65): (20, 0, 1), (G, 0.65): (32, 0, 1), (H, 0.65): (50, 0, 1), (J, 0.65): (80, 1, 2), (K, 0.65): (125, 1, 2), } }这段数据来自正常检验一次抽样方案表。可以看到同是 AQL 0.65字码从 A 到 H 时都是(0, 1)的零拒收判定到 J 与 K 才变成(1, 2)。这说明字码变大后样本量增大到一定程度才允许出现一个不合格品。使用这套数据时需要注意不同 AQL 下 Ac 的跳变位置不同具体值必须以标准原文的表格为准不能靠推导。3.2 批量到字码再到方案的完整查询函数把批量转换成字码是查表流程的第一步。下面这个函数接收批量并返回字码核心是按批量区间顺序匹配。def sample_size_code_letter(lot_size, inspection_levelII): ranges { I: [(2, 8, A), (9, 15, A), (16, 25, B), (26, 50, C), (51, 90, C), (91, 150, D), (151, 280, E), (281, 500, F), (501, 1200, G), (1201, 3200, H), (3201, 10000, J), (10001, 35000, K), (35001, 150000, L), (150001, 500000, M), (500001, None, N)], II: [(2, 8, A), (9, 15, B), (16, 25, C), (26, 50, D), (51, 90, E), (91, 150, F), (151, 280, G), (281, 500, H), (501, 1200, J), (1201, 3200, K), (3201, 10000, L), (10001, 35000, M), (35001, 150000, N), (150001, 500000, P), (500001, None, Q)], } for lo, hi, code in ranges[inspection_level]: if lot_size lo and (hi is None or lot_size hi): return code raise ValueError(lot_size out of valid range)参数说明lot_size 是当前送检批的批量值inspection_level 指定检验水平。函数逐行匹配区间命中即返回字码。这里把批量上限为无穷的情况用 None 表示。注意批量小于 2 时应提前拦截因为标准的最小批量范围从 2 开始实际业务里批量 1 通常采用全数检验不在抽样范围内。组合前面的查找逻辑批量 5000、AQL 0.65、一般水平 II 时字码是 L正常检验方案在完整表中对应样本量 200Ac 为 3Re 为 4。这与我在开头提到的客户审计场景完全一致也说明边界处理正确时流程能自洽。3.3 箭头表展开数据预处理阶段解决最易错环节箭头是 ISO 2859-1 主表里最容易让程序写错的地方。常见做法是在 ETL 或数据初始化阶段把箭头的跳转逻辑全部展开之后运行时不再解析任何特殊符号。展开逻辑可以这样写从正序字码列表的头部开始对每个 AQL 列做一次扫描如果当前格是向下箭头就继续往下找直到遇到真实方案如果当前格是向上箭头就往上找直到遇到真实方案。def expand_arrow(codes, aql_values, raw_table): expanded {} for aql in aql_values: for idx, code in enumerate(codes): cell raw_table.get((code, aql)) if cell is None: continue target_idx idx if str(cell).startswith(↓): while str(raw_table.get((codes[target_idx], aql))).startswith(↓): target_idx 1 expanded[(code, aql)] raw_table.get((codes[target_idx], aql)) elif str(cell).startswith(↑): while str(raw_table.get((codes[target_idx], aql))).startswith(↑): target_idx - 1 expanded[(code, aql)] raw_table.get((codes[target_idx], aql)) else: expanded[(code, aql)] cell return expanded这个函数的核心是 target_idx 的移动。遇到向下箭头时字码索引不断加一直到取到非箭头内容向上箭头同理。展开后的 expanded 字典可以直接被业务系统使用程序运行时不再关心原表是不是有箭头。使用这个函数的要求是 codes 必须按字母升序排列且 raw_table 的键严格为(code, aql)形式。我在实际项目里就把这套逻辑做成初始化脚本每次更新标准表后自动生成展开表再跑一遍抽样测试用例防止人工整理时引入不一致。4. 加严检验与放宽检验的状态机转移规则与转移得分的工程落地4.1 为什么不能只有正常检验如果系统只实现一套正常检验方案供应商实际上可以贴着方案边界生产长期来看质量水平会缓慢下降。ISO 2859-1 用加严检验和放宽检验构成一个闭环控制机制质量变差时通过更严格的抽样方案施压并要求供应商整改质量稳定且明显优于 AQL 时适当减少检验成本。这个反馈机制是标准里统计思想最强的地方也是软件系统里最容易遗漏的部分。4.2 转移规则与触发条件当前状态转移目标触发条件正常加严连续 5 批中有 2 批在初次检验时不接收加严正常加严检验下连续 5 批全部被接收加严暂停加严检验中不接收批数累计达到 5 批正常放宽连续 10 批正常检验全部接收转移得分不低于 30生产稳定过程平均优于 AQL放宽正常出现 1 批不接收或生产中断或出现其他规定条件需要特别注意转移规则的计数只基于初次检验结果重新提交的返工批不参与计数。工程上要单独维护一个状态字段记录当前检验严格度不能从最近检验记录里临时推断。否则系统重启、批次跨月、多个供应商共用同一条产线时状态会互相污染。4.3 转移得分表与状态机实现正常检验状态下每次一批被接收都会按该批方案的 Ac 数值累加转移得分。标准给出了明确得分表Ac0 时接收得 2 分Ac1 得 3 分Ac2 得 5 分Ac3 得 7 分Ac4 得 10 分Ac5 得 14 分Ac6 得 20 分。只有累计达到 30 分以上才具备转为放宽检验的候选资格。switching_score {0: 2, 1: 3, 2: 5, 3: 7, 4: 10, 5: 14, 6: 20} class InspectionSwitcher: def __init__(self): self.state normal self.score 0 self.recent_5 [] self.tight_rejected 0 self.tight_accepted_streak 0 def on_batch_result(self, rejected, ac): if self.state normal: self.recent_5.append(rejected) if len(self.recent_5) 5: self.recent_5.pop(0) if rejected: self.score 0 else: self.score switching_score.get(ac, 0) if sum(self.recent_5[-5:]) 2: self.state tightened self.score 0 elif self.state tightened: if rejected: self.tight_rejected 1 self.tight_accepted_streak 0 else: self.tight_accepted_streak 1 if self.tight_rejected 5: self.state suspended elif self.tight_accepted_streak 5: self.state normal这段状态机代码把整个转移流程压缩在了一个类里。核心是三个计数recent_5 保存最近 5 次的判定结果用于判断正常转加严tight_rejected 用于累计加严状态下的拒收批数tight_accepted_streak 用于计算连续被接收批数。使用上需要注意正常状态下的 score 一旦遇到拒收就清零这符合标准中“出现不接收批时转移得分重新开始”的精神。生产环境里建议把状态字段持久化到数据库并且按供应商和物料维度分别维护避免全局共享。5. 上线前用 OC 曲线验证抽样方案的五个细节抽样方案写进代码后建议用 OC 曲线验证方案强度。OC 曲线描述一批产品在不同真实不良率下被接收的概率可以直接看出方案是过严还是过松比肉眼对比样本量和 Ac 更可靠。from scipy.stats import binom def oc_curve(n, ac, p_values): return [binom.cdf(ac, n, p) for p in p_values]参数说明n 是样本量ac 是接收数p_values 是一组真实不良率。binom.cdf 计算不良百分比 p 时样本中不超过 ac 个不合格品的累积概率也就是接收概率。调用时传 p_values[0.1, 0.25, 0.5, 0.65, 1.0, 1.5, 2.5] 这类档位可以快速画出一条曲线。把不同字码的方案曲线叠在一起能直观判断批量对方案强度的影响。实际验证时我会重点检查五个细节。第一批量边界批量 5000 和 5001 落在不同区间字码可能不变但批量恰好落在区间端点时要确认逻辑一致。第二箭头展开把标准原文里每个箭头所在的格子单独列出来与展开表比对确保没有漏展开。第三转移计数用历史批次数据回放状态机看加严和放宽触发是否和人工复盘结果一致。第四多 AQL 并存同一批产品有多个 AQL 时样本量以对应方案中最大样本量为准判定时按各自 Ac/Re 分别判定任何一项不通过都判整批不接收。第五英文原版与国标差异GB/T 2828.1 是采标产物绝大多数内容一致但个别附注和警告措辞存在偏差。如果你的客户只看 ISO 原版建议系统表结构直接以英文原版为唯一数据源并在数据库中保留来源页码字段方便审计追溯。每次更新表格后跑一遍这五项检查抽样方案模块基本上就不会再出方向性错误。本文还有配套的精品资源点击获取