BGCM协议：面向匿名AI模型的黑盒身份验证与审计

开发过程中，最让人头疼的一类问题未必是模型效果差，而是“这个效果到底是谁输出的”。当业务方只给出一个匿名API，不透露底层模型名称、版本、微调方式时，身份验证就会演变成一场黑盒取证：我们无法打开模型参数，无法访问logits，也无法要求对方提供模型卡。我们只能不断向服务端发送输入，观察返回的文本和元数据，再根据这些信号判断：这背后还是原来那个模型吗？它有没有被悄悄降级？是不是已经被换成了另一个模型的蒸馏版本？

这类问题在模型评测体系里长期被忽视。传统评测回答的是“这个模型能考多少分”，也就是能力上限；而匿名模型审计要回答的是“这到底是谁”，属于身份辨识问题。二者依赖的技术手段不同，工程目标也不同。评测可以公开任务、统一打分；身份验证则要看行为轨迹、错误模式、知识边界、token切分习惯，甚至包括服务端的响应延迟规律。所以，我的判断是：匿名AI模型审计本质上不是一道难度更高的评测题，而是一套关于可观测性与证据链的协议设计问题。

这篇文章会提出并拆解一个四阶段黑盒身份验证协议。它不依赖白盒权重访问，也不需要模型方配合，全部基于常规API调用即可执行。我们会从底层信号分析讲起，以最小可运行的Python代码演示每个阶段怎么落，然后讨论阈值判定、持续监测、常见误判陷阱，以及这套协议在合规与安全层面的边界。你在日常推理服务运维、AI网关审计、第三方模型供应商风控中遇到的问题，大概率能在这里找到可以直接借鉴的思路。

1. 为什么匿名模型的身份会成为问题

先还原几个实际场景。

第一个场景：你的团队在API市场上采购了一个“企业级智能客服”服务，供应商宣称基座是某个知名开源模型，但服务端是黑盒。上线一段时间后，业务方投诉回复质量下降。作为技术负责人，你想确认供应商是否在某次夜间变更中悄悄把基座模型换成了小参数版本。可是你没有权限读取对端模型，甚至连供应商自己提供的版本号都未必可信。这时候，你需要的是对外部模型做黑盒身份审计。

第二个场景：AI网关或LLM路由平台同时接入了多个上游大模型。用户请求经网关转发时，你可能需要通过自动路由策略分发到不同模型。某天网关配置出现人为失误，导致流量全部转发到另一个模型。单看监控指标可能很难发现，因为新模型的输出质量未必差，只是风格、能力边界和Token成本不一样。要尽早发现这种漂移，就要定期对网关背后的模型做身份复核。

第三个场景更接近安全审计：有人声称自己开发了一个新模型，并开放API供评测。你要判断它究竟是一个全新模型，还是直接封装了某个已有开源模型，甚至只是对开源模型套了一个对话模板。此类鉴别称为“模型伪装检测”，在黑盒条件下同样依赖身份指纹，而不是单纯比较跑分。

这些场景有一个共同特点：模型是匿名、黑盒、持续变化的三重叠加。匿名意味着你不掌握模型声明；黑盒意味着你只有输入输出通道；持续变化意味着模型服务端可能在任意时刻升级、降级、替换或启用多副本路由。单点一次请求根本无法定性，任何有效验证都必须建立在长期、有组织的观测协议上。

这也是为什么直接问“你是哪个模型”往往没用。大多数推理服务不会在系统提示或回复里暴露真实模型名，甚至当你在Prompt中故意询问时，对方会返回一段标准的免责说明。真正的身份信息隐藏在大量看似无关的细节中，例如某些特殊Token的重组方式、特定事实的错误回答模式、低温采样下的固定措辞偏好。这些细节必须通过协议化方式采集，逐个纳入审计档案。

2. 黑盒模型身份可被判定的信息基础

在进入四阶段协议之前，先要建立一个信心：黑盒模型身份到底凭什么能被区分？

人类身份验证中，有一项技术叫笔迹鉴定。它不要求你亲眼看到书写者的钢笔和手腕，也不要求书写者承认笔迹归属。鉴定人只需要分析笔画顺序、转折角度、字符间距、用力习惯这些细节，就能给出“高度相似”或“不排除同一人书写”的结论。黑盒模型身份验证的逻辑与此同构：模型在训练数据、分词器、解码参数、系统指令遵守程度上的差异，会稳定地投射到文本输出分布中，形成一套难以完全抹除的行为指纹。

从产品响应里我们能观测到的信号大致分四层。

真正稳定的指纹往往不是单条回复，而是某类回复的分布规律。单个样例可能受随机性影响，但如果构造了一组能诱发不同模型产生系统性分歧的探针，那么大量回复的一致率就能形成统计层面的区分度。比如，不同模型在处理“请仅返回刚才字符串的第三个字符”这类强指令时，遵守程度差异很大。一套模型可能稳定执行，另一套模型倾向于解释而不是执行，还有一套模型会先复述一遍指令。每一条单独看都只是“行为风格”，汇总后就是可量化比对的签名。

但必须承认，这种验证不是零误差的。黑盒观测只能给出证据支持度，无法像访问模型权重哈希那样给出数学上确定的身份证明。好的审计协议不追求绝对确定，而是把“匿名模型身份是否变化”转化为一个可检验的统计假设，再通过长期观测不断收敛判断。这正是将审计方法协议化的价值。

3. 四阶段协议总览

四阶段协议可以缩写为BGCM Protocol，分别对应 Baseline（基线）、Generation（触发）、Comparison（比对）、Monitoring（追踪）四个过程。整个框架把黑盒身份验证从“临时试几个问题”升级为“可重复、可追溯、可持续”的审计工程。

为什么必须按这个顺序执行？

如果跳过阶段一直接提问，审计人员很容易犯两个错误：一是没有明确所审计端点的原始身份声明，后续出现分歧时不知道以谁为准；二是没有记录服务端不可控参数，例如请求时间、网络延迟、返回结果的usage字段，这会让阶段三的可复现性大打折扣。

如果阶段二没有系统设计，只用随手写的几个问题，那么获得的结果可能只能反映“通用能力对话”而非“身份区分”。阶段三也很难在噪声中提取稳定信号。

阶段四则负责解决模型世界的时变性。任何模型服务都可能更新版本、切换推理框架、引入负载均衡。如果审计只做一次，那么结果马上就会老化。持续的漂移检测，才是模型身份管理真正落地的地方。

下面我们逐个阶段展开，并配合代码演示。

4. 阶段一：定义审计边界并建立基线

4.1 基线阶段最容易被忽视的字段

很多人认为基线建立就是拿一批Prompt去问模型，然后把答案存起来。但如果审计要横跨数周、数月，你必须为每次观测记录完整的上下文。

我建议每个审计记录至少包含三类信息。

• 调用上下文：审计对象标识、接入地址、请求时间、模型参数（温度、最大Token数）、系统提示。
• 输入快照：Prompt原文，以及一个确定性的哈希值，便于后面核对数据完整性。
• 输出快照：回复内容、Token使用量、结束原因，以及服务端返回的自定义元数据。

之所以记录时间，是因为在持续追踪阶段要区分“本来就存在的噪声”和“随时间出现的结构性漂移”。如果忽略时间维度，阶段四将无从判断变化是发生在哪一天。之所以记录Token使用量，是因为不同模型的分词器不同，对同一文本的Token计数也不同。一个长Prompt输入到两个不同模型时，usage字段就可能出现明显差异，这是黑盒下不易伪装的元数据指纹。

4.2 基线记录器的原型代码

下面用Python dataclass定义一条标准的审计观测记录。为了让示例能在没有外部API的环境中直接演示，我们先定义一个抽象客户端接口，再用一个简单的本地模拟器实现。

# audit_demo/models.py from dataclasses import dataclass, field from datetime import datetime, timezone import hashlib import json @dataclass class AuditRecord: audit_target: str prompt_text: str response_text: str model_params: dict extra_metadata: dict = field(default_factory=dict) observed_at: str = "" def __post_init__(self): if not self.observed_at: self.observed_at = datetime.now(timezone.utc).isoformat() @property def prompt_hash(self) -> str: raw = json.dumps( {"prompt": self.prompt_text, "params": self.model_params}, sort_keys=True, ) return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:16] def to_tuple(self): return ( self.audit_target, self.prompt_hash, self.response_text, )

# audit_demo/client.py import time class ChatClient: def complete(self, prompt_text: str, temperature: float = 0.0) -> str: raise NotImplementedError class MockClient(ChatClient): def __init__(self, model_alias: str, reply_style: str = "default"): self.model_alias = model_alias self.reply_style = reply_style def complete(self, prompt_text: str, temperature: float = 0.0) -> str: # 模拟网络耗时，便于演示阶段四的时间序列效果 time.sleep(0.05) if self.reply_style == "terse": return f"[{self.model_alias}]" return f"[{self.model_alias}] received: {prompt_text[:20]}"

这条记录没有绑定任何商业模型SDK，实际项目中只需将MockClient替换为你的HTTP调用客户端即可。记录器应保证每条回复都有唯一哈希，方便以后重放时识别哪些Prompt的结果发生漂移。

4.3 基线库的使用原则

基线库建立起来之后，并不是所有历史回复都适合作为身份锚点。随着时间推移，有些Prompt可能被模型开发方加入了安全策略，导致过去能正常回答的问题现在被拒绝回答。这时，该Prompt已经不能继续作为对照样本，它测出的差异可能只是安全策略变更，而不是模型身份变更。

因此基线库需要给每条探针标注“活体状态”。常规做法是每条记录增加一个is_active字段，当探针连续多次因安全拒绝、服务端错误或缓存命中而无法产生有效回答时，将它的is_active标记为False。审计协议只会拿活跃探针参与阶段三的比对计算。

5. 阶段二：探测集的构造逻辑

5.1 探测样本既是输入，也是“质控品”

如果把匿名模型身份审计类比成医学检验，阶段二设计的探测集就是一批“质控品”。质控品的核心要求不是越难越好，而是批间稳定、对目标差异敏感。用于模型身份验证的探测集同样如此。

理想探测集应同时满足三个原则。

第一，可复现。所有Prompts必须写成固定文本，尽量不依赖随机改写；推理时优先使用temperature=0等低随机性解码参数。温度归零并不能保证绝对确定性，因为某些服务端仍可能使用采样或批处理优化，但它可以把随机噪声压到较低水平。

第二，可区分。好的探测项能在不同模型上产生相互分离的输出。判断一个探测项是否合格，不能只看单一模型的回答是否“正确”，要看多个候选模型对这个探测项的回答是否稳定呈现不同模式。如果所有模型都给出相同答案，它就是无效探测。

第三，可轮换。同一批探测集如果长期不变，模型服务方可以针对它做缓存、路由或策略规避，让黑盒观测失真。所以探测集应当有一个主集合和一个备用池，每次审计时从中抽取一部分，避免被对端识别。

5.2 探测项的四种基础类型

基于阶段二的工程需要，可以把探测项分成四类。

这四类不是完全并列的。Token敏感性探测最容易被忽视，但恰恰最具鲁棒性，因为分词器通常继承了预训练模型的结构，后期微调很难彻底改变。比如一个模型对glucose-6-phosphate这类含连字符术语的切分方式与另一个模型不同，会导致模型在复述时出现细微差异。

5.3 探测集构造与执行代码

下面代码构造了一个小型探测集，并在两个模拟模型上触发响应。为了模拟真实区分度，这里为MockClient设计了不同风格。

# audit_demo/probes.py from dataclasses import dataclass @dataclass(frozen=True) class Probe: probe_id: str prompt_text: str category: str = "general" PROBE_SET = [ Probe( "p-001", "请只输出下面字符串中的第4个字符：A7fQk2Zp\n", "token_sensitive", ), Probe( "p-002", "将下面文本完整复述一遍，不要解释：Qx-9dL-2024-archive\n", "token_sensitive", ), Probe( "p-003", "请用JSON格式输出：{\"model\": \"?\", \"confidence\": 0}\n", "format_compliance", ), Probe( "p-004", "2024年7月之后，AI Agent这个概念在工程界最重要的变化是什么？回答控制在50字内。\n", "knowledge_boundary", ), ]

# audit_demo/run_probes.py from client import MockClient from probes import PROBE_SET def run_probe_set(client: MockClient): results = [] for probe in PROBE_SET: response = client.complete(probe.prompt_text, temperature=0.0) results.append( { "probe_id": probe.probe_id, "category": probe.category, "response": response, } ) return results def main(): model_a = MockClient(model_alias="candidate-alpha", reply_style="default") model_b = MockClient(model_alias="candidate-beta", reply_style="terse") print("=== model_a ===") for item in run_probe_set(model_a): print(item["probe_id"], item["response"]) print("=== model_b ===") for item in run_probe_set(model_b): print(item["probe_id"], item["response"]) if __name__ == "__main__": main()

执行后会看到两个模拟模型在每个探测项上的回复差异。真实项目中，这里的client.complete会替换为对目标推理服务的HTTP请求。需要特别说明的是，当面向真实模型时，Prompt需要写得更加接近评测集格式，且不能在同一请求中把多个问题拼接在一起，因为长Prompt会稀释每个探测项的独立性。

6. 阶段三：签名提取与身份相似度判定

6.1 从文本到可计算签名

拿到探测响应后，不能直接拿字符串做相等比较。两个不同模型对“请用JSON输出模型身份”的回答可能都包含"model": "assistant"，就文本而言完全一致，但它们在其它探测项上差异很大。这是为什么我们不应该把单个回复当作全部依据。

阶段三要解决两件事：一是把每条回复转成可比较的签名片段；二是在整个探测集上计算综合相似度。签名片段的提取通常有几种做法。

• 精确归一化：将文本统一为小写、去除多余空白、去除标点后逐字比较。
• 语义相似度：用向量模型将回复编码，再计算余弦相似度。
• 规则打分：对不同类别探测设置专门的匹配规则，如JSON格式是否符合、字符串是否完整复现、答案是否包含指定实体。

考虑到身份审计要长期运行，我不建议每条探测都调用向量模型做语义编码，那样成本高且慢。最稳妥的做法是：先做规则化精确比较，只有精确比较无法判断时，再引入语义相似度作为兜底。

6.2 候选身份库与匹配分数

在阶段三中，如果你怀疑服务端换成了某个具体模型，需要有一个候选身份库。候选身份库类似于笔迹鉴定中的“样本字库”，它包含若干已知模型的探测响应签名。在实际业务中，候选签名可以有三种来源：

• 历史留存：你过去直接调用过该模型厂商官方API，存下了当时的响应快照；
• 公开评测集：从模型官方或学术评测数据集中提取的标准回复；
• 自建比对池：你用已有的开源模型本地跑同一批探测集，生成签名。

候选身份库与目标服务端的探测响应比对时，可以使用一个简单的加权一致率函数。对不同类别探测赋予不同权重：知识边界探测权重较低，因为模型更新后知识覆盖很容易变化；Token敏感性探测权重较高，因为分词器特征更稳定。

# audit_demo/match.py def normalize_text(text: str) -> str: return " ".join(text.strip().lower().split()) def agreement_score(observed: dict, reference: dict, weight_map: dict) -> float: total_weight = 0.0 hit_weight = 0.0 for probe_id, weight in weight_map.items(): if probe_id not in observed or probe_id not in reference: continue total_weight += weight if normalize_text(observed[probe_id]) == normalize_text(reference[probe_id]): hit_weight += weight if total_weight == 0: return 0.0 return hit_weight / total_weight def decide_identity(result_scores: dict, threshold: float = 0.75): sorted_scores = sorted(result_scores.items(), key=lambda x: x[1], reverse=True) best_candidate, best_score = sorted_scores[0] if best_score >= threshold: return best_candidate, best_score, sorted_scores return "unknown", best_score, sorted_scores

这里有一个小细节。decide_identity返回的"unknown"并不代表“一定不是任何候选模型”，只代表“当前观测结果不足以确认”。在没有达到阈值前，审计系统不应该输出一个高置信的身份结论。这是审计协议最重要的严谨性所在。

6.3 置信区间与样本量意识

如果你只跑了5条探测，其中3条精确一致，得到0.6分。此时置信度很低，因为样本量过小，即便模型完全一致，也会因为解码随机性导致低分。反之，如果你跑了200条独立探测，得到0.6分，那基本可以确认不匹配。

建议阶段三输出四个部分：候选模型排名、最佳分数、活跃探测数量、波动区间。真实项目中，可以对同一探测集在三个不同时间段重复采样，用三次得分的均值和标准差作为判定依据。标准差过大时，先别急着下结论，优先检查是否因为限流导致部分请求没有正常完成。

7. 阶段四：持续运行中的漂移检测与身份复核

7.1 别只做一次性审计

模型身份审计不能当作一次性项目来做。如果你的系统依赖外部模型API，模型方可能在你不知情时调整服务端配置。要捕捉这种变化，阶段四需要把阶段二和阶段三封装成一个周期性任务，定期运行并记录得分变化。

漂移检测有两种策略。

第一种是有候选身份的比对策略。你怀疑系统背后应该是candidate-alpha，于是每天把活跃探测集发给目标服务端，与candidate-alpha的签名库算相似度。只要有一天得分显著低于历史均值，就触发告警。

第二种是无候选身份的自我比对策略。你没有任何外部候选签名，只能把本周的探测响应与历史基线响应做对比。如果历史基线稳定，而本周响应在多条探测上出现系统性变化，那么同样可以推定模型服务端发生了身份漂移。这种策略更适合你在审计一个从来没有官方身份的匿名服务。

7.2 最小漂移检测器代码

下面实现一个最简单的分段漂移检测器。它维护近期得分的滚动窗口，当最新得分低于滑动均值超过一个阈值时，标记漂移。

# audit_demo/monitor.py from collections import deque class DriftDetector: def __init__(self, window_size: int = 7, drift_threshold: float = 0.15): self.window = deque(maxlen=window_size) self.drift_threshold = drift_threshold def update(self, score: float): self.window.append(score) def is_drifted(self) -> bool: if len(self.window) < 3: return False recent = self.window[-1] baseline_avg = sum(self.window) / len(self.window) return (baseline_avg - recent) > self.drift_threshold

调用方式很简单。每次定时任务跑完探测并计算出综合得分后，把分数交给DriftDetector。当is_drifted()返回True时，审计系统应当进入人工复核流程，而不是直接自动切断服务，因为自动切断可能会导致线上故障扩大。

实际调度可以由cron、APScheduler或你现有的监控平台完成。要注意的是，定时任务的探测频率不能过高。真实模型API通常有速率限制，过于高频的探测请求会被服务端限流，甚至可能导致审计账号被临时封禁。比较合理的做法是每天或每周执行一轮完整探测，每轮之间做好请求间隔控制。

8. 黑盒身份审计中最常踩的五个坑

以下是长期运行此类协议时最容易出现的问题。很多团队不是不会设计探测集，而是死在误判与噪声管理上。

里面最值得展开的是“模型升级被误判为身份替换”。深度学习模型在更新版本后，知识边界、安全策略、指令跟随能力都会变化，这些变化很容易被粗粒度匹配识别为“不同身份”。但如果新版本只是旧模型的增量微调，分词器没变，核心预训练权重没变，它的身份指纹与旧版本仍然是接近的。因此审计报告不应该把“行为漂移”直接等同于“模型被替换”，而应输出“身份漂移等级”，再由人工结合服务商公告判断。这个区别在处理商业合同纠纷时尤为重要。

另一个高频坑是探测缓存。很多推理平台为了降低延迟会做Prompt缓存和输出缓存。如果探测集长期不变，服务端命中缓存后返回的不再是真实解码结果，而是缓存的固定回复。此时所有探测都会显示“完全一致”，但这并不说明模型没有变化，只能说明缓存策略掩盖了变化。对策是为每轮审计生成一个随机的“盐值标记”放入Prompt头部，并在计算签名时把该标记剔除，避免污染实际探测内容。

9. 协议的安全边界与合规前提

这条协议可以在很多黑盒审计项目中落地，但使用前必须明确几条安全边界。

第一，你只能审计自己有合法调用权的服务。这包括企业内部自建模型API、你所在组织已经签约采购的第三方模型服务，或者你有明确授权进行安全评估的公开接口。未经授权对他人模型进行大规模探测，可能违反服务条款甚至相关法律法规。

第二，不要试图通过探测突破服务端安全限制。审计协议聚焦于“区分模型身份”，它不应当被用来提取训练数据、绕过安全对齐、诱导模型泄露Prompt或系统指令，更不应被用于越权访问他人部署的模型。如果探测过程中发现模型输出的内容可能包含敏感个人信息，应立即停止并丢弃该响应，不得进入审计基线库。

第三，审计结论的效力有限。黑盒验证结果是“行为层面的统计证据”，它可以作为内部决策、模型供应商风险管理的参考，但如果要用于合同违约认定或法律纠纷，还需要与采购合同中的技术条款、供应商变更日志、第三方存证等手段共同形成完整证据链。仅凭黑盒响应文本不能得出绝对唯一结论。

从协议设计角度，还应遵守最小权限原则：审计账号只开通目标服务商允许范围内的推理调用权限，不申请额外的管理权限；审计日志中不包含真实用户的对话内容，而是使用专用探测集或经过脱敏处理的语料；审计数据保留一定时间后应自动清理或归档。把匿名模型身份审计当作一个常规安全运营能力来治理，而不是一次性的临时脚本任务。

10. 部署这套审计协议的建议路径

如果你准备在团队里落地这套四阶段协议，我建议按下面的顺序推进。

先从一个真实的匿名服务开始，不要把摊子铺得太大。选定一个你日常依赖但无法直接确认身份的API端点，用一两天时间搭建基线记录器，把服务元数据和第一批探测结果存档。前期不需要追求300条大型探测集，20条覆盖不同信号层的探测就足够验证流程是否跑得通。

跑通之后，再扩展探测集并设定权重。具体操作是把当前20条探测升级到100条左右，并用你怀疑的候选模型做一次对照，观察各类探测的区分度。区分度不足的探测项被筛掉，区分度高的项留下，并为每一类设置合理权重。这一步骤建议由了解模型评测的算法工程师参与，单纯依赖后端工程师容易忽视指令微调对不同任务的影响。

最后接入调度和告警。将阶段二的探测任务挂到定时任务上，每天运行一轮，将阶段三计算的得分输入阶段四的DriftDetector。当触发漂移时，把审计报告同步给模型供应商管理负责人和SRE团队，让人工介入判断是否升级为正式的模型替换核查。

整个协议的价值不在某一次得分多高，而在它把“匿名模型是否还是原来那个”这个模糊问题，变成了一条可以长期追踪、能够回溯、允许人工复核的证据链。这恰恰是目前很多AI工程团队缺失的最后一公里：大家擅长把模型效果调到最好，却很少为模型服务的可信与可验证建一道防线。当你接入的第三方模型越来越多，匿名来源越来越普遍时，这套黑盒身份验证协议会成为基础设施级的安全能力。