匿名模型服务越来越多但身份却越来越难确认。很多平台把开源底座、蒸馏模型、微调版本包装成自研API对外提供不公开权重、不透露架构、不标注版本。用户接入前想搞清楚这个黑盒接口背后到底是什么模型传统思路往往靠猜看回答风格、试几个经典问题、对比人工感受。这种做法既不稳定也无法沉淀成可复用的审计方法。Auditing Anonymous AI Models: A Four-Stage Protocol for Black-Box Identity Verification就是针对这个问题给出的一套四阶段黑盒身份验证协议。它把这个模型看起来像谁的模糊判断拆成采样探测、特征提取、画像比对、证据判定四个可执行阶段。这套协议的核心价值有三个第一整个过程不需要接触模型权重、训练数据或内部日志只通过接口请求和响应完成审计适用范围很广第二每一阶段都可以模块化实现方便接入批量审计任务第三它不是靠单一特征下结论而是把多个证据维度做加权聚合对匿名接口、包装模型、蒸馏模型的识别更接近真实答案。本文会按阶段拆解这套协议的技术细节给出可落地的采样策略、特征抽取方法、相似度评分与证据聚合代码模板并补充批量审计和工程化落地时需要注意的问题。如果你正在做模型选型评估、API合规审计、模型供应链管理或者需要验证自己采购的模型服务是否货真价实这篇文章可以直接收藏。1. 协议相关核心概念速览先明确四个关键概念避免后面混淆。概念说明匿名AI模型通过API或服务形式对外提供但不公开权重、架构、训练数据、版本号的模型黑盒身份验证审计方只能通过输入输出与模型交互无法读取中间层信息据此推断模型身份模型指纹模型在回答事实问题、风格问题、推理问题等方面表现出的稳定性特征身份画像把模型在多个维度上的响应特征汇总成一个可比较的模型身份证再看协议本身的规格能力项说明协议名称Four-Stage Protocol for Black-Box Identity Verification审计对象匿名模型API、封装服务、蒸馏或微调后的推理接口输入条件可访问的模型接口、候选模型参考集合输出结果身份匹配结论、各维度证据评分、置信度运行方式Python脚本/批量调度实现先探测后比对是否支持批量审计可以探测阶段按问题集批量执行是否依赖GPU不依赖特征提取阶段主要消耗CPU与API配额主要成本目标模型与参考模型的API调用次数适用场景模型选型评估、版权合规审计、供应链验证、防冒充检测依赖条件需要一组覆盖事实、推理、语言、代码等维度的探测题合规前提必须获得系统所有者授权符合API使用条款从规格可以看出这个协议的门槛不高不要求昂贵的GPU或本地模型部署真正消耗的资源是API调用次数和探测问题集的设计质量。协议结论的可靠性取决于参考模型库是否覆盖足够多的候选对象以及每一阶段的特征提取是否足够稳定。2. 协议解决什么问题边界在哪里黑盒身份验证要解决的核心场景有三类。第一类是模型冒充与误标。服务方声称自己的接口是某个主流模型实际背后跑的是开源小模型或蒸馏版本。普通用户从对话流畅度上很难察觉只有通过批量探测和系统化比对才能发现。第二类是供应商切换与降级。平台在高峰期偷偷把流量切到低成本模型但对外价格和命名不变。通过持续性身份审计可以发现响应特征发生偏移的时间点。第三类是自研模型抄袭排查。训练数据来自其他模型输出或多阶段蒸馏后形成了强烈模仿特征通过黑盒审计可以度量嫌疑程度为后续技术鉴定提供参考。这套协议的边界也很清楚。它只能做身份倾向性判断不能直接反向提取训练数据不能暴露模型权重也不能替代代码级溯源分析。当两个模型同源、能力接近或者经过了大量微调后指纹差异可能非常小此时协议能给出的只是相似度分数而非绝对断言。更稳妥的用法是把它作为持续监控和预筛工具发现问题后再结合服务条款审查、日志核验等传统手段确认。需要特别强调的是所有黑盒探测都必须在获得服务所有者授权、符合API使用条款以及所在地区法律要求的范围内进行。批量高频探测可能对目标服务造成负载压力也应该控制速率避免影响线上业务。3. 四阶段协议整体流程整个协议可以划分成四个阶段每个阶段有明确的输入和输出。阶段名称输入输出阶段一接口探测与采样目标模型API、探测题集原始响应日志阶段二响应特征提取原始响应日志结构化特征向量阶段三模型画像与相似度比对目标特征向量、参考特征库候选模型的相似度分阶段四证据聚合与判定多维度相似度分、环境信息身份判定结论与报告在实际执行时阶段一和阶段三有一个隐含的准备工作构建候选参考模型库。如果怀疑目标模型是某个特定模型或它的微调版本就需要用同一套探测题去请求候选模型把它们的指纹特征提前入库。这个过程可以由受控的API调用完成也可以通过本地部署候选开源模型完成。阶段一的任务是想办法让目标接口暴露自己的知识范围和生成习惯阶段二负责把文本响应转成可计算的数值特征阶段三解决目标指纹和哪个参考指纹最接近的问题阶段四则解决多个维度证据互相冲突时如何决策。下面按阶段展开。4. 阶段一接口探测与采样策略探测阶段决定了审计质量的上限。问题集设计不合理后续特征提取和比对做得再好也很难区分不同模型。4.1 探测维度设计建议从五个维度设计探测题每个维度都要保证答案有相对稳定的事实基础或结构特征。第一个维度是事实性知识。覆盖科学常识、历史事件、地理信息、人物生平。这类问题能反映训练数据的覆盖范围和截止时间。比如询问某个2023年后发生的事件如果模型总是拒绝回答或明显错误可以推测它的知识截止时间较早。第二个维度是推理能力。包括数学计算、逻辑推理、编程题。不同模型对同一道题的解题路径和错误模式存在差异。特别是数学题早期模型和现代模型在符号处理能力上差距明显。第三个维度是语言风格。让模型用不同文体写作观察词汇偏好、句式长度、标点使用习惯。有些模型倾向于使用首先、其次、最后这类结构词有些模型喜欢列表式回答这些习惯相对稳定。第四个维度是多语言能力。准备相同内容的中文、英文、日文、西班牙文、代码混排提问。不同训练语料配比会让模型在不同语言上的表现产生明显差异这个维度对识别开源底座尤其有效。第五个维度是格式化生成。要求模型输出JSON、XML、Markdown表格、CSV等。模型的模板遵循能力不一样对格式错误的处理方式也能作为身份特征的补充。4.2 采样数量与去重探测题数量不建议太少。单维度至少准备20到30道题五个维度合计100到150道题是比较稳妥的起步规模。如果目标只做快速筛查可以缩减到50道但结论置信度会下降。问题之间要去重避免歧义问题尽量保证参考答案是客观存在的。此外同一道题建议进行轻微改写生成多个变体。因为模型在温度较低时对相同问题的输出相对稳定但不同表述可能触发不同知识路径多个变体可以提高指纹覆盖率。4.3 请求参数固定化探测时一定要固定采样参数。温度、最大生成长度、系统提示词都会影响响应。建议温度固定为0或接近0关闭随机性让输出结果可复现。系统提示词不要频繁变化否则提取出的特征会混入提示词风格而不是模型本身风格。下面给出一段探测客户端的通用模板实际使用时要按目标API的请求格式调整import requests import time import json from typing import List, Dict, Any class ModelProbeClient: 黑盒探测客户端通用模板需按实际接口调整请求与响应解析方式 def __init__(self, endpoint: str, api_key: str , temperature: float 0.0): self.endpoint endpoint self.headers {Content-Type: application/json} if api_key: self.headers[Authorization] fBearer {api_key} self.temperature temperature def ask(self, prompt: str, max_tokens: int 512) - Dict[str, Any]: payload { prompt: prompt, max_tokens: max_tokens, temperature: self.temperature, } # 通用请求模板实际字段名需要根据接口文档调整 try: resp requests.post(self.endpoint, headersself.headers, jsonpayload, timeout60) resp.raise_for_status() data resp.json() # 兼容两种常见返回结构data[text] 或 data[choices][0][text] text data.get(text) or data.get(choices, [{}])[0].get(text, ) return { prompt: prompt, response: text, finish_reason: data.get(finish_reason) or data.get(choices, [{}])[0].get(finish_reason), latency_ms: resp.elapsed.total_seconds() * 1000, http_status: resp.status_code, } except Exception as e: return {prompt: prompt, error: str(e)} def batch_ask(self, prompts: List[str], interval: float 0.5) - List[Dict[str, Any]]: results [] for p in prompts: results.append(self.ask(p)) time.sleep(interval) return results if __name__ __main__: # 示例并发控制与简单调用 probe ModelProbeClient(endpointhttps://api.example.com/v1/completions, api_keyyour_key) test_prompts [解释什么是黑洞, 用Python实现冒泡排序, 写一段英文产品介绍] outputs probe.batch_ask(test_prompts, interval0.2) for out in outputs: print(json.dumps(out, ensure_asciiFalse, indent2))这个模板有三个地方需要注意。一是响应体解析不通用必须按实际API返回的字段调整。二是批量调用要控制间隔避免触发限流。三是每次探测要保留原始响应方便后续重新提取特征。4.4 探测Log记录不建议在探测阶段只保存文本回答。原始日志应至少包含问题ID、问题原文、模型响应全文、temperature、max_tokens、请求时间戳、响应延迟、finish_reason、Token用量如果接口返回。这些字段会为阶段二的特征提取和阶段四的证据聚合提供基础。5. 阶段二响应特征提取拿到原始响应日志后要做的是把非结构化文本转成结构化特征。这层特征设计得越细模型之间的区分度就越高。5.1 表层文本特征表层特征不需要模型参与直接计算文本统计量即可。这类特征适合做第一轮粗筛。具体包括响应平均长度、响应长度标准差、平均句子数、平均句长、标点使用频率、列表结构使用频率、Markdown标题使用频率、中英文混合比例。例如一些英文底座模型经过中文指令微调后虽然能流利回答中文但标点使用和列表偏好仍然保留英文模型的习惯。单纯看文本是否正确很难发现统计特征却能暴露。5.2 知识正确性特征逐题判断模型回答与标准答案是否一致。这里的一致不能只看字面完全相同应该包括关键实体是否命中、数值是否正确、立场是否一致、回答是否正确拒答。知识正确性特征通常组织成答对率。按维度分别计算事实题答对率、数学题答对率、代码题通过率。如果目标模型声称是某个旗舰模型但事实题答对率显著低于参考同款就需要警惕降级或替换。5.3 行为风格特征风格特征适合用固定的模板文本提取。例如让模型写自我介绍、产品文案、周报随后从输出中统计连接词频率、第一人称使用频率、正式度、emoji使用频率。这类特征受微调影响较大不适合作为唯一判断依据但能给证据聚合提供辅助分。5.4 格式遵循特征对JSON输出题、XML输出题、Markdown表格题解析模型输出结果判断是否合法、字段顺序是否固定、是否额外输出解释性文本。不同模型对格式指令的敏感度不同有的模型能够严格只输出目标格式有的模型则总会附带好的以下是结果这类冗余话术。下面是特征提取函数的通用实现框架实际特征类型可以按需扩展import re import statistics from typing import List, Dict, Any def extract_length_stats(responses: List[str]) - Dict[str, float]: 提取响应长度统计特征 lengths [len(re.sub(r\s, , r)) for r in responses] return { avg_len: statistics.mean(lengths), std_len: statistics.stdev(lengths) if len(lengths) 1 else 0.0, min_len: min(lengths), max_len: max(lengths), } def extract_markdown_ratio(responses: List[str]) - float: 统计Markdown结构使用比例如列表符、标题符、代码块 md_count 0 pattern re.compile(r(^|\n)\s*(#|[-*]|\d\.|), re.MULTILINE) for resp in responses: if pattern.search(resp): md_count 1 return md_count / max(len(responses), 1) def extract_correctness_rates(eval_results: List[Dict[str, Any]]) - Dict[str, float]: 按维度汇总答对率eval_results 需包含 dimension 和 is_correct 字段 dim_to_results {} for item in eval_results: dim item[dimension] dim_to_results.setdefault(dim, []).append(item[is_correct]) rates {} for dim, flags in dim_to_results.items(): rates[facc_{dim}] sum(flags) / len(flags) return rates def build_model_profile(probe_logs: List[Dict[str, Any]], eval_results: List[Dict[str, Any]]) - Dict[str, Any]: 把多个特征合并为一个结构化画像 responses [log[response] for log in probe_logs if log.get(response)] profile {} profile.update(extract_length_stats(responses)) profile[markdown_ratio] extract_markdown_ratio(responses) profile.update(extract_correctness_rates(eval_results)) # 这里可以继续加入风格、格式、多语言等特征 return profile if __name__ __main__: logs [ {response: 黑洞是由质量巨大的天体坍缩形成的。}, {response: 首先黑洞是时空的一个区域。其次它的引力极强。}, ] evals [ {dimension: fact, is_correct: True}, {dimension: fact, is_correct: False}, ] print(build_model_profile(logs, evals))特征提取要保证同一个特征对目标模型和参考模型使用一致的计算逻辑。任何特征定义上的偏移都会直接污染后续相似度计算。6. 阶段三模型画像与相似度比对有了目标模型的特征画像后要把它和参考模型库中的画像逐一比较得到相似度分数。6.1 参考模型库建设参考模型库需要覆盖所有候选模型。对每个候选模型执行同样的探测流程生成同等维度的画像。如果候选模型太多可以先做粗筛用20到30道高区分度问题快速淘汰明显不匹配的候选再对剩余候选执行完整探测。参考库建设完成后每个模型都对应一个统一 schema 的 JSON 画像。画像中既包括连续特征如平均长度、答对率也包括离散特征如格式偏好。6.2 相似度计算连续特征可以归一化后计算距离。同一维度上目标模型与参考模型的差距越小相似度越高。常用算法包括欧氏距离适合各特征均归一化到同一量纲的情况。余弦相似度适合关心特征方向而不关心整体长度的情况。KL散度适合比较响应长度分布、词频分布等概率分布特征。知识答对率这类特征直接计算差值即可再通过一个指数函数映射到0到1区间。例如import math from typing import Dict, List def normalize_features(profile: Dict[str, float], feature_keys: List[str], bounds: Dict[str, tuple]) - Dict[str, float]: 对特征做Min-Max归一化。 bounds 示例{avg_len: (0, 2000), acc_fact: (0, 1)} normalized {} for key in feature_keys: lo, hi bounds.get(key, (0.0, 1.0)) val profile.get(key, lo) if hi - lo 0: normalized[key] 0.0 else: normalized[key] (val - lo) / (hi - lo) return normalized def cosine_similarity(vec_a: Dict[str, float], vec_b: Dict[str, float], keys: List[str]) - float: 计算两个画像在指定特征集合上的余弦相似度 dot 0.0 norm_a 0.0 norm_b 0.0 for key in keys: a vec_a.get(key, 0.0) b vec_b.get(key, 0.0) dot a * b norm_a a * a norm_b b * b if norm_a 0 or norm_b 0: return 0.0 return dot / (math.sqrt(norm_a) * math.sqrt(norm_b)) def similarity_between(profile_target: Dict[str, float], profile_candidate: Dict[str, float], feature_keys: List[str]) - float: 封装相似度计算入口 return cosine_similarity(profile_target, profile_candidate, feature_keys)这个示例采用余弦相似度作为基础度量。实际执行时建议把特征分成文本统计、知识准确率、格式遵循等组分别计算组内相似度再按组加权得到综合相似度。直接对底层特征做全局距离会稀释掉某个维度上的强区分信号。6.3 排序与候选截断对所有候选模型计算完相似度后按分数降序排列。只保留Top 5候选进入阶段四。如果目标模型与最高分候选的相似度显著高出第二名那么身份判断通常比较明确。如果前几名得分接近则需要增加增补探测扩大样本量让阶段四做更稳健的证据聚合。7. 阶段四证据聚合与判定阶段三得到的是相似度排名阶段四要回答的是到底信谁、结论是否可信。7.1 证据维度不建议只把综合相似度作为唯一判定指标。建议单独维护以下证据维度证据维度说明参考权重建议知识答对率吻合度目标模型在各知识维度上的答对率与哪个候选最接近高响应统计特征吻合度长度、标点、列表等行为统计的相似度中格式遵循模式结构化输出与候选模型库中的格式特征是否一致中错误模式吻合度在推理题、数学题上犯错的位置和类型是否相似高多语言风格差异不同语言下的风格切换模式是否一致低错误模式是容易被忽略但区分度很高的维度。不同模型家族在数学解题上的失败模式不一样有些模型会因为计算中间步骤错误而得出错误结果有些则是公式引用错误。同一家族的两个版本在这类错误上往往有一定继承性跨家族模型之间的差异会更明显。7.2 加权评分与阈值每个维度先计算0到1之间的证据分再按权重加权求和。最终分数映射到判定结论总分大于等于0.85身份匹配报告为高度疑似。总分介于0.70到0.85之间倾向匹配建议人工复核或增加探测量。总分介于0.50到0.70之间无法判定需要补充候选模型。总分小于0.50不匹配目标模型不在当前参考库中。阈值需要根据实验标定。如果误报成本高应该提高第一档阈值比如从0.85调整到0.90。使用协议时不要照搬固定阈值要结合自己审计场景的精度要求做调整。7.3 报告结构每次审计建议输出结构化报告便于后续批量汇总和存档。参考JSON结构如下{ audit_id: audit_20250114_001, target_endpoint: https://api.example.com/v1/chat, audit_time: 2025-01-14T10:30:00Z, candidate_count: 8, top_matches: [ { candidate_model: llama-3-8b-chat, similarity: 0.91, evidence: { knowledge_acc: 0.88, text_stat: 0.93, format_follow: 0.85, error_pattern: 0.89 } }, { candidate_model: qwen2.5-7b-instruct, similarity: 0.72, evidence: { knowledge_acc: 0.77, text_stat: 0.70, format_follow: 0.74, error_pattern: 0.66 } } ], verdict: { conclusion: likely_matched, confidence: 0.88, suggested_action: manual_review } }审计报告本身也应该设计版本号。因为参考模型库会不断扩充旧报告使用的参考库版本可能影响结论。保留参考库版本、探测题集版本、特征提取代码版本才能保证报告可以追溯。8. 审计实验设计与效果评估如果要把这套协议落地成固定能力不能直接跳到生产环境应该先设计一个小规模实验验证有效性和稳定性。8.1 验证对象准备若干已知身份的模型作为验证集。模型中最好包含两个同源不同版本模型、两个不同家族但能力接近的模型、一个经过微调的伪装模型。这样能检验协议在相似但不同情况下的分辨能力。8.2 评估指标重点关注以下指标Top-1命中率对每个验证模型审计结果排名第一的候选模型是否就是真实身份。Top-3命中率真实身份是否出现在前三位候选里。真阳性率真实匹配被判定为高度疑似或倾向匹配的比例。假阳性率不匹配模型被错误判定为匹配的比例。稳定性重复执行同一审计结论不发生漂移的比例。8.3 样本量与重复测试先用50到100道探测题做一轮完整测试统计结论。接着把探测题随机拆成两半分别执行审计看两个半集的结论是否一致。如果结论不一致说明探测题量不足或包含区分度偏低的问题需要扩充。温度虽然是0但部分模型仍存在一定随机性。建议对同一问题重复请求2到3次观察输出方差并把方差纳入特征提取时的参考。多次结果高度不稳定的模型本身也会降低审计可信度。9. 批量审计与工程化实现单次审计适合临时验证生产环境往往需要对多个匿名模型接口做持续审计这就要引入批量调度。9.1 批量任务设计思路批量审计流程可以拆成三个环节输入侧维护一份待审计接口清单包含接口地址、密钥引用、速率限制等元信息。执行侧调度器从清单读取任务逐一对接口执行探测和比对。输出侧每次审计生成一个报告文件定期汇总为审计看板。9.2 批量调度代码模板一个可用的批量调度逻辑最关键的是分层控制并发。同一目标接口的探测请求要限速不同目标接口之间可以适度并发。import json import time import threading from queue import Queue from dataclasses import dataclass, asdict from typing import List, Dict dataclass class AuditTask: task_id: str endpoint: str api_key_ref: str question_set_id: str interval_seconds: float 0.5 class BatchAuditScheduler: def __init__(self, tasks: List[AuditTask], max_workers: int 3): self.tasks tasks self.max_workers max_workers self.queue Queue() def _worker(self): while not self.queue.empty(): task self.queue.get() try: self._run_single(task) except Exception as exc: print(ftask {task.task_id} failed: {exc}) finally: self.queue.task_done() def _run_single(self, task: AuditTask): # 实际实现替换为加载探测题 - 调用阶段一 - 阶段二 - 阶段三 - 阶段四 # 此处只演示任务级占位 result { task_id: task.task_id, endpoint: task.endpoint, status: success, time: time.time(), } with open(freports/{task.task_id}.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) def run(self): for task in self.tasks: self.queue.put(task) workers [ threading.Thread(targetself._worker, daemonTrue) for _ in range(self.max_workers) ] for w in workers: w.start() self.queue.join()批量审计要特别注意重试策略。接口返回限流或超时通常是临时问题返回鉴权失败或参数错误则是配置问题重试不会有效果。建议把任务状态拆成pending、running、retrying、failed、done失败任务写入单独队列等待人工检查。9.3 成本控制探测题集越大、参考模型数量越多API调用费用越高。可以建立分级策略日常监控使用30道题的快速套装只做Top-3粗筛仅在人工怀疑阶段使用150道题的完整套装。先粗筛后细查能显著降低成本。10. 常见问题与排查方法协议落地过程中问题往往出在数据、特征和参考库上而不是算法本身。问题现象可能原因排查方式解决方案同一模型两次审计结论不同探测题数量太少或模型输出方差大查看两次审计的样本重叠度增加题量对同一问题重复请求取多数结果两个明显不同模型得分都很高探测题区分度不足逐题计算判别力淘汰两边都答对或都答错的题目增加高区分度题目并重新标定特征权重模型知识答对率一直很低知识截止时间不同或领域覆盖不同按年份和领域拆分统计答对率单独增加时效性问题集不混合进总特征参考库中没有匹配项得分全低目标模型不在候选集中检查Top候选的最低得分分布扩充候选模型范围或提供不在库中判定探测请求频繁限流请求速率过高查看服务端限流头和响应码增大请求间隔加入指数退避重试特征提取结果与人工感受不符特征定义偏向统计量未覆盖语义层抽查个别样例的特征值增加语义正确性和错误模式等高质量特征API响应字段无法解析各家接口返回结构不统一输出原始响应检查实际JSON字段为每个接口单独写解析器不要强行统一微调模型与底座模型难区分微调保留了大部分底座能力特征对比知识答对率之外的行为细节增加格式遵循、结构化输出、安全拒答等特征维度遇到无法区分的情况不要急着增加相似度算法复杂度。先检查参考库是否覆盖了足够多的近亲模型。如果候选库中没有与目标模型同源的对象再好的特征也无法完成匹配。11. 最佳实践与使用建议这套协议要长期稳定运行建议遵循下面几条工程原则。第一建立可追溯的审计资产库。探测题集、参考模型画像、特征提取脚本、审计报告都要按版本管理。没有版本可追溯的审计结果在法律或商务场景中很难作为有效证据。第二把身份验证做成持续性监控而不是一次性动作。模型供应商可能在后台静默切换模型只有周期性运行同一套探测协议才能捕获特征偏移。建议设计每周或每月级别的监控任务保留历史曲线。第三合理设置告警阈值。不要等到相似度跌破匹配线才告警。如果某接口对历史画像的相似度连续三次下降超过5%就值得人工介入检查。持续下降的趋势往往比单次低分更有信号意义。第四严格遵守授权边界。黑盒审计目标服务的合法性取决于是否获得授权、是否符合服务条款。在未授权环境下进行批量探测既不专业也可能带来法律风险。建议先获取书面授权再开始探测。第五涉及人脸、声音、版权内容等敏感数据的模型审计必须更加谨慎。不要在探测问题中提交未授权的个人数据或受版权保护的素材。探测结果中包含用户生成内容时也要做脱敏处理后再入库。第六不要孤立使用相似度分数做自动决策。自动判定结果只能作为高置信度的预筛输出最终结论建议保留人工复核环节尤其是涉及采购、法律纠纷、安全事件时。12. 总结Auditing Anonymous AI Models: A Four-Stage Protocol for Black-Box Identity Verification本质上提供了一种把AI模型身份猜测工程化的思维框架。先用足够的探测题让模型暴露特征再把响应转成可计算的画像接着与参考库做系统比对最后用多维证据聚合出带置信度的审计结论。最关键的一点是这套协议的每一步都可以独立验证和迭代。今天可以先从100道探测题 5个候选模型的小实验入手跑通一次完整审计确认特征提取和报告输出是否符合预期后续再逐步扩充参考模型库和问题集。最容易踩的坑不是代码写错而是探测题区分度不够、参考库覆盖不全、以及把单一相似度指标当成了绝对真相。先小规模验证再放到持续监控场景里跑才是这套协议最稳妥的落地方式。