四阶段黑盒身份验证：AI模型行为指纹审计方法

在 AI 模型以 API、镜像权重、第三方封装等各种"半匿名"形态快速扩散的今天，模型身份审计已经不只是研究课题，而是工程安全里的刚需。这篇不以论文复述为目标，而是把四阶段黑盒身份验证协议的方法论讲清楚：它解决什么问题、每一阶段做什么、需要哪些输入与输出、适合在哪些场景落地、以及作为审计人应该如何设计与使用这套协议。

1. 核心能力速览

在动手拆解协议之前，先把这套方法的关键参数放在一张速览表里，后面所有细节都围绕这个框架展开。

这套协议的核心思路是：如果一个模型和一个已知身份之间存在可观测的一致性，而这个一致性在随机模型中几乎不可能出现，那就说明匿名模型大概率就是这个身份。与直接看参数、看网络结构不同，黑盒协议完全靠"行为指纹"来推断身份。

2. 为什么需要匿名模型身份验证

先看一个实际场景。

企业内部采购了一个"某开源大模型的私有化部署包"，供应商声称它就是 Llama-3-8B 二次微调后的版本。但交付时只给了一个容器镜像和推理 API。你无法直接查看权重文件，无法确认它究竟是基于 LLama 改的、还是套了 Qwen 的壳、又或者是完全不同的模型套用了统一的 API 包装。

再比如，一家公司发现内部某个深度学习平台疑似被外部代理商用镜像方式重新部署，对方否认模型来自本公司。此时要验证身份，却又拿不回对方的训练数据，唯一能访问的就是对方对外开放的推理接口。

这些场景有一个共同点：

• 你有一个或多个"身份候选"，假设模型可能源自某个已知模型。
• 你和目标交互的唯一通道是黑盒推理接口。
• 你需要给出一个可量化、可复核的身份判断结论。

四阶段黑盒身份验证协议就是为这种场景设计的。它不需要对方提供任何内部信息，只需要审计方主动构造输入、收集输出，通过统计分析建立模型间的行为关联。

从适用性来说，这套协议不仅适用于大语言模型，也适用于图像分类、图像生成、语音识别等不同模态的黑盒模型推荐。它真正区分模型的依据不是某一条输入的表现，而是大量输入之下的系统性模式。

3. 四阶段身份验证协议整体框架

把整套协议拆开，逻辑上非常清晰。

阶段一：黑盒探测与数据采集 阶段二：模型行为指纹构建 阶段三：候选身份匹配与相似度计算 阶段四：置信度推断与审计决策

3.1 协议设计原则

四阶段结构的底层设计原则有三条。

第一，分离采集与推断。探测阶段只负责采集尽量干净的输入输出行为，不急于做任何判断。匹配阶段只使用前面已经固化好的指纹数据，不再重新请求目标模型。这样一方面可以避免循环采样带来的统计偏差，另一方面也能让协议具备可复现性，因为一次采集出的指纹可以被反复审计。

第二，统计推断替代确定性判断。匿名模型的身份判定必须允许存在"不确定区间"。当两个模型之间高度相似时，审计方可以给出"高度疑似同源"；当相似度只比随机基线高一点时，协议必须诚实输出"无法判断"。这个设计是为了避免黑盒行为天然存在的多义性导致误报。

第三，可扩展候选池。协议设计不能只在两个模型之间做二分类，要能在几十个候选身份中做匹配，因此第三阶段的匹配算法必须具备索引和降维能力。

3.2 协议的最小运行条件

运行这套协议不要求重型基础设施，但有几个必要条件：

• 一个可编程访问的目标模型接口，能接受批量请求。
• 一组稳定的输入样本，最好与目标模型业务领域相近。
• 至少两个候选模型用于对照实验，否则无法建立随机基线。
• 足够的请求配额，因为四阶段协议对探测请求的数量有较高要求。

如果目标接口限制了单位时间请求次数，协议需要加入自适应限速策略。

4. 阶段一：黑盒探测与行为数据采集

第一阶段是整个协议的基座。探测方案不行，后面三个阶段计算得再严谨也没有意义。

4.1 探测样本的来源与构造

采集阶段的核心任务是生成一组能"逼出模型特点"的输入样本。这类样本可以来自三个方向。

第一，公开基准测试集。用 MMLU、GSM8K、HumanEval 这类标准评测集做初始输入，优点是稳定、可复现、对比性强。缺点是公开样本可能出现在多个模型的训练数据里，导致不同模型在这些样本上表现趋同，区分度不足。

第二，领域相关业务样本。如果你审计的是一个法律咨询模型，那就构造一批法律条款解释、合同条款分析、判例检索类问题。领域样本能有效放大模型间在特定任务上的能力差异，是比公开集更有区分度的一类输入。

第三，极端与对抗样本。这是黑盒身份验证里最关键的一类探测样本。它们不关心模型能否"正确回答"，而是关心模型在异常输入下会形成什么错误模式。比如语法正确的无意义句子、特别长的上下文、逻辑矛盾问题、Unicode 混淆文本、重复字符序列等。不同模型在训练数据、分词器、对齐策略上的差异，会在这些异常输入上暴露无遗。

从实操角度，推荐的样本构成比例是：

• 30% 通用公开测试题，用于确认模型的基础能力区间。
• 30% 领域特定业务题，用于检验应用场景特征。
• 40% 极端与对抗样本，用于提取高区分度指纹。

4.2 输出特征要记录什么

向目标模型发出请求后，不应该只保存生成的最终文本。建议把以下信息全部记录下来：

• 模型的文本输出。
• 输出 token 序列长度。
• 逐 token 对数概率（如果接口支持）。
• 推理响应时间。
• 解码参数的设置（在可控状态下固定解码参数）。
• 多次请求同一输入时的输出稳定性。

输出特征越细，第二阶段能构建的指纹维度就越高。不过默认大多数商业 API 不开放 logprobs 参数，因此协议设计要把文本输出本身作为主信号，logprobs 只作为附加增强信号。

4.3 控制变量

这个阶段最常见的错误是采集环境和条件不一致。比如审计 A 模型时用贪婪解码，审计 B 模型时用随机采样，那么两者输出行为上的差异可能完全来自解码策略，而不是模型身份差异。

正确的做法是固定所有可控制的推理参数，包括：

• temperature 固定为 0.1 或 0。
• top_p 固定为 1。
• max_tokens 固定为统一上限。
• 输入 prompt 的格式完全一致。

如果目标接口不允许修改采样参数，则必须在记录中标注，并在后续分析阶段把采样随机性纳入误差估计。

5. 阶段二：模型行为指纹构建

采集阶段结束后，审计方手里会有一份"模型行为档案"。第二阶段要做的是把这份原始档案压缩成维度更低、可比性更强、噪声更小的指纹表示。

5.1 指纹的三个层次

模型指纹建议从三个层次构建。

输出分布指纹。对同一个输入集合，统计模型输出 token 的概率分布或输出类型分布。如果两个模型使用相同的基础架构和相近的训练数据，它们的输出概率分布会在大量样本上表现出显著相关性。具体可以计算每个测试样本下两个模型得到相同输出或语义等价输出的频率。

错误模式指纹。把测试样本分成若干语义类别，统计模型在每个类别上的错误率。不同模型在数学、逻辑、代码、多语言等类别上的能力分布不同，这个能力曲线本身就能构成一个指纹向量。例如一个模型可能在代码能力上很强但在数学上很弱，另一个模型恰好相反。这种错位是身份区分的重要依据。

语义嵌入指纹。把模型的输出文本通过一个独立的嵌入模型转换成向量，然后在向量空间中比较距离。这种模式在小规模测试集上的稳定性通常弱于输出分布指纹，但是当候选池很大时，嵌入指纹可以提供初筛能力。

5.2 指纹构建的标准化流程

假设在阶段一采集到 N 条输入及对应输出，可以按下面的流程构建指纹：

import numpy as np from sklearn.preprocessing import StandardScaler def build_fingerprint(input_ids, outputs, error_labels, categories): """ 构建标准化的模型行为指纹向量。 输入: input_ids: 样本编号列表 outputs: 模型输出集合 error_labels: 每个样本的分类/正确性标签 categories: 样本所属语义类别 输出: fingerprint: 标准化后的指纹向量 metadata: 指纹构建元信息 """ feature_dim = len(set(categories)) category_error = [] for c in set(categories): indices = [i for i, cat in enumerate(categories) if cat == c] if indices: errors = [error_labels[i] for i in indices] category_error.append(np.mean(errors)) else: category_error.append(0.0) # 加入整体输出多样性特征 unique_output_ratio = len(set(outputs)) / len(outputs) fingerprint_raw = np.array(category_error + [unique_output_ratio]) scaler = StandardScaler() fingerprint = scaler.fit_transform(fingerprint_raw.reshape(-1, 1)).flatten() metadata = {"n_samples": len(input_ids), "feature_dim": len(fingerprint_raw)} return fingerprint, metadata # 使用示例：根据审计需求传入采集数据 fp, meta = build_fingerprint( input_ids=[f"sample_{i}" for i in range(100)], outputs=["output_a"] * 100, error_labels=[0] * 100, categories=["math"] * 50 + ["code"] * 50 ) print(meta)

注意，不同候选模型的指纹必须在完全相同的输入集合上构建，否则指纹之间不具备可比性。

5.3 多轮采样对噪声的抑制

黑盒访问有一个固有噪声来源：即使固定输入，模型也可能会因为随机采样、批处理、服务端负载等原因产生浮动输出。为了得到稳定指纹，建议对关键测试样本做多次重复请求，取统计量而非单次结果。

推荐重复次数根据区分度要求来定，低区分度场景至少重复 3 次，高精度身份认定建议重复 5 到 10 次。重复请求会增加成本和耗时，但能显著降低后续阶段出现误判的概率。

6. 阶段三：候选身份匹配与相似度计算

有了目标模型的指纹以后，第三阶段就是把这份指纹与候选身份库中的指纹逐一比对。

6.1 相似度度量方法选择

指纹向量之间的相似度度量有多种选择，没有一种方法能通吃所有场景。

在实际审计项目中，建议至少同时使用皮尔逊相关系数和 KL 散度作为互补度量。前者给出正负相关的总体判断，后者能捕捉同一输入集合上的分布细微差异。

6.2 随机基线与身份先验

只算候选池内部的相似度是不够的，因为不同任务上模型整体的相似度基线不同。比如在 MMLU 这类常见公开测试集上，几乎所有开源模型都经过训练，表现本身趋同，两个完全无关的模型也可能在某些子集上有较高的输出一致性。

所以，协议还必须建立随机基线。

实际操作方法是：从候选池中随机抽取若干对无关模型，计算它们在相同测试集上的相似度分布，得到平均值和标准差。目标模型和某一个候选模型之间的相似度需要明显高于随机基线，才可以认为存在身份关联。

更严谨的做法是引入身份先验。如果被审计模型的输入输出风格、能力边界与某个候选模型的公开描述高度吻合，那么匹配阶段的先验概率可以相应上调。

6.3 多候选池的快速筛选

候选池不大时直接用全量两两对比。

候选池很大时，比如超过 20 个模型，建议先做初筛：

import numpy as np from sklearn.metrics.pairwise import cosine_similarity def rank_candidate_models(target_fp, candidate_fp_dict, top_k=5): """ 基于余弦相似度对候选模型做初筛排序。 """ scores = {} for name, fp in candidate_fp_dict.items(): sim = cosine_similarity([target_fp], [fp])[0][0] scores[name] = float(sim) sorted_scores = sorted(scores.items(), key=lambda x: x[1], reverse=True) return sorted_scores[:top_k] candidate_fp_dict = { "model_A": np.random.rand(10), "model_B": np.random.rand(10), "model_C": np.random.rand(10), } target_fp = np.random.rand(10) print(rank_candidate_models(target_fp, candidate_fp_dict, top_k=2))

初筛后，对排名靠前的 2 到 3 个候选再做高成本的高精度指纹比对，用更细致的测试子集消耗更多请求额度。这种"粗筛加精排"的流程比一次性全量高精度比对更经济。

7. 阶段四：置信度推断与审计决策

第四阶段是整个协议的输出层。身份匹配不能简单说"是"或"否"，必须输出一个带统计意义的结论。

7.1 置信度计算方法

在完成目标模型和所有候选模型的比对后，需要判断目标模型是否属于某个候选身份。

推荐的判断标准是基于偏差 z 分数：

z_score = (observed_similarity - mean_random_similarity) / std_random_similarity

z 分数越高，说明观察到的相似度越偏离随机水平。在此基础上，可以定义审计决策规则：

这个阈值不是固定标准，而是需要根据被测模型领域和随机基线波动幅度做动态调整。候选池越大、任务类别越窄，z 分数阈值应适当提高。

7.2 审计报告的标准化输出

协议的最后输出尽可能采用标准化格式，方便后续归档和复核。建议报告包含以下字段：

{ "audit_id": "audit_20250218_001", "target_model": "anonymous_api_001", "audit_date": "2025-02-18T14:30:00Z", "candidate_pool": ["known_model_A", "known_model_B"], "test_samples": 180, "fingerprint_dimension": 16, "similarity_scores": { "known_model_A": 0.782, "known_model_B": 0.251 }, "random_baseline": { "mean": 0.45, "std": 0.12 }, "z_scores": { "known_model_A": 2.77, "known_model_B": -1.66 }, "verification_result": "weak_positive", "confidence": 0.83, "recommendation": "collect_more_data_and_reaudit", "probe_log_location": "s3://audit_bucket/probes/audit_20250218/", "auditor": "security_team_01" }

输出的关键点在于可复核性。其他审计人员拿到报告后，应该能根据 probe_log_location 里的原始探测日志，重新运行指纹构建和匹配流程，得到完全一致或高度接近的结论。

7.3 不确定结论的处理

四阶段协议最难处理的不是"匹配上了"，而是"看起来很像但无法完全确定"。

当结论落在中间区间时，不要试图通过微调阈值让结果偏向某一方。正确做法是补充三类额外证据：

• 更多极端与对抗样本，提高区分度。
• 引入时间维度特征，观察目标模型不同时段的行为漂移。
• 增加交互式探针，通过连续对话或多轮交互提取更深层的一致性或差异度。

如果补充证据之后仍然无法得出结论，审计报告应当明确标注"证据不足以支持身份一致性判断"。这个"无法判断"的结论在审计实务中同样很有价值，它意味着采购方需要要求供应商提供更多内部材料作为佐证。

8. 接口审计场景下的协议与批量任务设计

在实际工程落地中，很少有审计方会手动逐条发请求。四阶段协议通常要封装成一个可重复执行的审计工具，并放在批量任务管线里运行。

8.1 审计任务编排

建议把一个完整的四阶段审计任务拆成三个独立可调度的子任务：

# 阶段一：探测采集 python stage1_probe.py \ --target-api http://127.0.0.1:8000/v1/completions \ --sample-file ./data/probe_samples.jsonl \ --output-dir ./probe_result/target_model \ --max-retries 3 \ --rate-limit 5 # 阶段二和三：指纹构建 + 候选匹配 python stage2_build_fingerprint.py \ --input-dir ./probe_result \ --output-file ./fingerprints/target_fp.json python stage3_match.py \ --target-fp ./fingerprints/target_fp.json \ --candidate-fp ./fingerprints/candidate_pool.json \ --output-file ./results/match_result.json # 阶段四：置信度判断与报告生成 python stage4_report.py \ --match-result ./results/match_result.json \ --output-report ./reports/audit_report.json

8.2 API 请求过程中的异常处理

在批量采集模型行为时，最常见的工程问题来自 API 服务端的不稳定性。建议在审计工具中加入两级容错机制：

• 瞬时错误：网络超时、限流、5xx，自动重试 2 到 3 次。
• 永久错误：模型不存在、接口参数错误、鉴权失败，跳过并记录原因。

批量任务完成后需要生成一份采集质量报告，里面包含成功请求数、失败请求数、失败类型分布、平均响应时间。任何在探测阶段应该采集却因为异常没有采集到的样本，都要在报告中标注。

8.3 多模型并行审计队列

如果一次需要对多个匿名模型进行身份验证，可以按"模型维度"并行，而不是按"样本维度"并行。每台审计机器负责一个模型的完整指纹采集，避免不同模型之间的请求互相干扰、增加协调复杂度。

一个典型的并行方案是：

{ "audit_batch": { "models": [ {"model_id": "anon_001", "api_url": "http://x.x.x.x:8000", "priority": 1}, {"model_id": "anon_002", "api_url": "http://y.y.y.y:8000", "priority": 2} ], "probe_repeat_times": 5, "timeout_seconds": 180, "concurrent_limit": 4 } }

批量任务跑完后，将各个模型自动生成 z 分数组，再做一次横向比较，观察是否存在整体偏高的系统性偏差。这一步经常能发现数据集泄漏或某种全局相似性问题。

9. 协议的性能观察与资源预估

这套协议不涉及训练，主要是推理请求加计算，因此资源开销的理论上限是可预估的。

9.1 请求量与时间估算

探测请求总量参考公式：

总量 = 样本数 × 重复次数

假如采用常规配置：600 个测试样本、每个重复 5 次，总量就是 3000 次请求。以每请求平均 2 秒、并发 4 计算，单目标模型的探测耗时大约是 25 分钟。如果加入更多长文本生成测试，耗时可能上升到 1 到 2 小时。

9.2 内存与计算要求

指纹构建阶段的计算量极小。即使对几千条输出做嵌入向量化，也只对 CPU 有基本需求，连入门级笔记本都能跑动。

真正可能吃资源的是嵌入模型的加载。如果使用本地嵌入模型，需要预留 2G 到 8G 内存，这取决于嵌入模型的大小。采用纯输出统计分析和字符串匹配的方案则完全可以避开 GPU，内存占用通常在 2G 以内。

9.3 降低请求量的策略

请求量往往是审计项目最大的瓶颈，尤其是被测模型接口有配额限制时。降低请求量的方法有：

• 先用 100 个低成本的短输出样本做初筛，只在匹配结果集中到少数候选时再扩大到 600 个。
• 使用语义等价判断替代逐字匹配，不需要为了统计输出结果而反复生成。
• 优先选择短答案类样本，减少每次请求的生成 token 数，既降低费用又提升吞吐。

10. 常见问题与排查方法

11. 部署时的合规与安全边界

把四阶段黑盒身份验证协议投入实际应用，必须明确几个边界。

只做行为审计，不绕过安全控制。所有探测请求都应约束在目标接口允许的正常调用范围内。不得利用协议尝试破解接口鉴权、提取训练数据、实施模型窃取攻击或越权访问内部系统。探测样本的选取以公开数据和审计方自有数据为限。

涉及商业模型时注意使用条款。对商业 API 发起大规模探测前，应确认其服务条款是否允许自动化测试和基准测试。部分模型服务会禁止批量抓取输出用于构建指纹。审计方需要在这种情况下改用人工抽样和更小规模的探测方案，或提前取得授权。

不要使用身份验证结论做未授权的公开披露。当审计发现匿名模型确实来自某个候选身份时，这个结论本身可能涉及商业机密、外包协议或泄露溯源。在披露之前，应当先走内部安全合规流程，确认信息公开范围。

涉及个人数据时严格匿名化。如果测试样本中包含真实用户数据，必须在送入目标模型前脱敏。尤其在法律、医疗、金融等敏感领域，任何探测请求都会把数据发送给第三方模型，一旦泄露就会形成合规事故。

协议输出仅作为概率结论，不能作为唯一的司法或商业证据。黑盒审计的天然局限是"无法看到模型内部"，因此即使 z 分数非常高，也仍然存在因为共同训练数据、外部蒸馏、统一部署框架等原因造成的伪匹配。正式决策需要结合采购合同、部署日志、供应链信息等其他证据链。

12. 最佳实践：从一次审计到持续验证

最后给出一套值得借鉴的工程实践思路。

12.1 为每个模型维护独立指纹档案

不要只在发生争议时临时构建指纹。对采购来的模型、自研模型、外部 API 服务，在接入时就跑一次指纹采集，把结果存档。这个"前摄性指纹库"在未来遇到匿名模型时可以直接作为候选池匹配，大幅缩短审计周期。

12.2 动态补充高区分度测试样本

协议中使用的测试样本不是一成不变的。每次审计结束后，应该把那些区分度最高的样本挑选出来，单独存放为"高价值探针集"。这些样本通常是一些极端输入、边界输入、格式诡异输入。随着高价值探针集越来越大，后续审计的精度也会越来越高，请求成本反而会下降。

12.3 统计结论与人工复核结合

任何自动化的审计工具都不应该直接输出最终定性结论。建议系统自动完成前三个阶段的采集、指纹构建、匹配和 z 分数计算，然后由审计人员人工检查高评分候选的输出样本日志。人工复核的重点是确认二者的相似不是表面模板化，而是底层推理模式的一致。

12.4 关注模型的版本漂移

模型服务会升级，同一个模型 ID 背后可能悄悄换了新版本。四阶段协议的价值不只是给模型"验明正身"，也可以长期跟踪同一个接口的行为漂移。如果每天定时跑一次轻量采样，一旦发现输出分布指纹显著偏移，就说明接口背后的模型可能已经更换或更新，这时应当重新走完整的四阶段审计流程。

13. 从协议到工具链的最后建议

四阶段黑盒身份验证协议不是一个需要完整商业产品才能使用的框架。最小可用版本的实现很简单：准备一个 HTTP 请求脚本、一个样本库、一个统计函数，就可以对两个模型跑出相似度和 z 分数。

但要在真实审计项目中输出可信结论，建议做一个稍微正式一点的小工具链：

• 阶段一用独立脚本控制探测流程并记录原始日志。
• 阶段二把每次构建的指纹版本化存储。
• 阶段三固定候选池版本，不轻易改变指纹处理逻辑。
• 阶段四自动生成标准化 JSON 报告并由人复核后签发。

这套协议最值得注意的一点并不是算法复杂度，而是它对模型间系统性行为模式的敏感度。黑盒推理下两个模型如果来自同一基础底座或同源训练管线，哪怕部署方刻意修改了提示词模板和输出包装，也很难掩盖在大量极端输入下保持一致的内在倾向。反过来，如果两个模型的内部结构完全不同，无论部署方如何声称同源，在足够多的探测样本面前也会暴露出显著差异。

对于模型采购验收、API 合规审计、供应链安全团队来说，这个四阶段协议可以直接作为内部审计流程的骨架。第一次审计时建议先用小样本集跑通，再逐步扩大样本库和候选池，在跑完整协议的同时记录实际效果和耗时成本，慢慢调出一套适合自身业务场景的参数组合。