NXAI 文档

Appearance

关于 AI 大模型鉴别真伪的系统性方案 ​

客户要的是「真货」——来自官方 API、行为与承诺一致的模型。而你面对的是代理商、中转层、甚至逆向 CLI 包装的未知链路。看不到出站域名，摸不到 TLS 证书，只能盯着响应体。这种情况下，怎样判断：这是真的官方 API，还是套壳？是 Bedrock，还是 Codex？

本文从聚合平台的现实约束出发，整理出一套可落地的鉴伪体系：身份探测、故意犯错、能力面 canary、官方渠道识别、以及最难的一关——以次充好的模型身份鉴别。既有原理，也有示例，方便开发者直接落地。

一、问题的本质：什么叫「假货」？ ​

别急着下结论。不少人一听到「逆向」「非官方 API」「开源自建」就直接打上假货标签——这既不准确，也不利于落地。

核心只有一句：客户买到的，和供应商声称的，是否一致。

判据含义
身份一致模型名、版本、权重来源可验证
行为一致在固定 prompt 集合上表现落在预期区间
协议一致工具调用、上下文、流式格式符合承诺
可追溯有模型卡、校验信息或供应链证据

典型假货场景：同名不同版本（行为差异大却只报名字）、蒸馏/量化未披露、指令对齐与声明不符。反过来，自建开源模型只要披露清楚，就不算假；只是「非官方 API」也不能单独当假货判据。

先把「假货」定义清楚，后面的技术手段才有落脚点。

二、四大手段，一张图看清 ​

在「只能看响应、无法看出站」的前提下，我们依赖四类技术手段，并行使用，互为补充：

mermaid
flowchart TB
    subgraph 四大手段["AI 大模型鉴伪体系"]
        A[① 身份探测]
        B[② 故意犯错]
        C[③ 能力面 canary]
        D[④ 官方渠道 id 前缀]
    end
    A --> R[验证结果]
    B --> R
    C --> R
    D --> R

图 1：鉴伪体系整体架构

  • ① 身份探测：用固定 prompt 诱导模型自报身份，抓逆向 CLI 的「签名」
  • ② 故意犯错：构造违规参数，通过错误响应的结构特征判断是否官方
  • ③ 能力面 canary：探测 thinking、工具调用、多模态等「官方有、网页壳常缺」的能力
  • ④ 官方渠道区分：用响应 id 前缀区分 Bedrock / Anthropic / Codex

建议：日常监控跑 ①②，新渠道准入加 ③，结论输出时叠加 ④。多维并行，才能把误判压下去。

三、身份探测：让模型自己「招供」 ​

逆向 CLI 常把请求转发给真实模型，但很难在系统提示里完全抹掉模型的默认自我认知。用一句简单的「What are you? Reply briefly in one sentence.」就能诱出不少信息。

逆向签名（命中即判逆向）：kiro、kiro2api、codewhisperer、claude code、命令行工具 等。

正向放行：若响应结构命中官方特征——例如 id 前缀为 msg_、msg_bdrk_、chatcmpl- 等——则直接视为非逆向。

保守策略：未命中逆向签名时，不轻易判逆向，避免误伤正常代理商。

输出字段建议：is_cli、reason，并写入通道测试结果，便于审计和复现。

四、故意犯错：用违规参数换零成本鉴别 ​

这是整套方案里最划算的一招。

官方 API 在底层做了硬编码的参数校验。你传 candidateCount=9（Gemini 上限是 8），它会老老实实报错，并带上厂商专属的错误类型、字段名、request id。逆向和套壳呢？要么根本不做校验，要么自己做一层，错误结构往往简陋、含糊，很难完美伪造官方的细节。

mermaid
flowchart LR
    A[发送违规请求] --> B{API 返回错误?}
    B -->|是| C[解析错误结构]
    C --> D{含官方特征?}
    D -->|fieldViolations + request_id| E[✅ 正版]
    D -->|模糊 / 无字段名| F[❌ 逆向/套壳]
    B -->|否 正常返回| G[无法鉴别]

图 2：故意犯错鉴别流程

  • 正版：含 fieldViolations、generation_config.candidate_count、Google request id 等
  • 逆向/套壳：参数错误、1 (inclusive) to 9 (exclusive) 等模糊描述

优点：错误请求不消耗 token，适合周期性批量跑；错误结构相对固定，易做正则/关键词自动化；不涉及真实业务数据，安全。

刚性参数示例：

厂商参数合法范围违规值
GeminicandidateCount1～89
Claudetemperature0.0～1.01.5
Claudemax_tokens1～40960100000

正版 vs 逆向，错误长什么样？

Gemini 正版会返回类似：

text
candidate_count must be in the range [1, 8]. (request id: 202603192148286610505511h0dI2k0)

含 fieldViolations、generation_config.candidate_count、以及 Google 风格的 request id。

逆向/套壳则可能是：

text
...supported range is from 1 (inclusive) to 9 (exclusive)

或包含 submit request 的中转语义，如：

json
{"error":{"message":"Unable to submit request because it has a temperature value of 9.99 but the supported range is from 0 (inclusive) to 2.0001 (exclusive).","type":"upstream_error","code":400}}

这里的关键不是文字是否“像报错”，而是 submit request 的语义：调用方在“把请求再提交给下游”。官方 Gemini（AI Studio/Vertex）本身就是模型服务提供方，不会描述成“submit request to upstream”这种中转链路动作。因此本文落地规则收敛为强特征：

  • 命中 submit request → 判逆向/中转
  • 命中 2.0001（异常边界值）→ 判逆向/中转
  • 其他模糊错误文案（如仅有 range/inclusive/exclusive）不单独判逆向，避免误判

Claude 正版会明确写出 temperature must be between 0.0 and 1.0，并带有 invalid_request_error 或 ValidationException；逆向往往只有一句模糊提示。

请求示例（可直接用于自动化）：

json
// Gemini
{
  "contents": [{"role": "user", "parts": [{"text": "test"}]}],
  "generationConfig": {
    "temperature": 0.7,
    "maxOutputTokens": 1024,
    "candidateCount": 9
  }
}

// Claude
{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 16,
  "temperature": 1.5,
  "messages": [{"role": "user", "content": "hi"}]
}

自动化判定要点：看错误类型（INVALID_ARGUMENT、ValidationException、invalid_request_error）、描述是否包含官方字段名、以及是否有厂商风格的 request id。三者都具备，可视为正版；缺得多，则需结合其他手段再判。

五、能力面 canary：专治「缺胳膊少腿」的逆向 ​

网页版、App 逆向、薄封装代理，往往只实现了部分 API 能力。Thinking、工具调用、多模态出图、严格 JSON schema 等，要么不做，要么做残。

用「官方文档里有、逆向常缺」的能力做探测，每个用例记 pass / fail / skip：

优先级探测项残缺时常见表现
P0Thinking（thinkingConfig）无 thought: true，只返回最终文本
P0工具调用闭环无 functionCall，第二轮对话断链
P1结构化输出（responseSchema）非 JSON、schema 违约
P1多模态出图仅文本，无 inlineData
P2流式 + usageusage 缺失，chunk 结构异常

thoughtSignature 可以作为组合证据之一：部分 Gemini 响应会带此字段，若已知完整 API 有而某渠道稳定缺失，可视为能力降档；但缺字段本身不能单独判逆向，模型版本差异太大。

六、官方渠道区分：一个 id 就够了 ​

Bedrock、Anthropic 直连、Codex，都是官方或官方托管，但来源不同。好消息是：代理商一般不会改 id，看一眼前缀就能区分。

mermaid
flowchart LR
    A[AWS Bedrock] -->|id 前缀| A1["msg_bdrk_"]
    B[Anthropic 直连] -->|id 前缀| B1["msg_"]
    C[Codex] -->|id 前缀| C1["resp-"]

图 3：官方渠道 id 前缀映射

渠道id 前缀
AWS Bedrockmsg_bdrk_
Anthropic 直连msg_（且非 msg_bdrk_）
Codexresp- 等

在通道测试或 relay 层解析响应 JSON，按前缀落档即可。

AI Studio vs Vertex（Gemini）：两者响应 schema 高度相似，区分度弱一些。可结合 usageMetadata.trafficType（Vertex 有 ON_DEMAND、PROVISIONED_THROUGHPUT 等）、错误结构（Vertex 符合 Google Cloud 错误模型），以及故意犯错触发的错误形态，对已知渠道建基线后再写规则。

七、落地建议与诚实边界 ​

落地建议：

场景手段
日常监控故意犯错 + 身份探测，定期批量跑
新渠道准入加能力面 canary，记录特征向量
高价模型交付以次充好暂无稳定手段（§8），可关注后续探索
结论输出叠加 id 前缀、能力得分，落档到 channel/model 元数据

证据链：建议持久化 channel_id、model_name、endpoint_type、is_cli、reason、响应摘要、检测时间，方便审计和回溯。

诚实边界：代理商若完整透传官方 API，你无法从响应上区分「直连」和「透传」；高度定制的逆向也有可能仿造部分特征。多维并行能显著提高准确率，但做不到 100%。把这套方案当成「日常筛网 + 准入门槛」，而不是「终极铁证」，更符合实际。

八、以次充好：鉴别具体模型身份 —— 开放性问题 ​

前面的手段能区分「逆向 vs 官方」「Bedrock vs Codex」。但还有更难的场景：同是官方 Bedrock，供应商声称 claude-opus-4-5 实际却跑 claude-haiku-4-5。响应体无可靠模型标识，常规故意犯错对两者无效——目前尚无稳定、可落地的鉴别手段。

尝试过的方向：

  • 诱导出错：tool_reference 在 Bedrock 上需 tool-search beta，请求在参数校验阶段即被拒，无法触及 Haiku 的「不支持」错误；output_config.effort 在 Bedrock 上的行为与错误格式未确认。
  • 能力探针：深度推理、长上下文、代码能力等依赖推理表现，区分度与稳定性不足，易受版本、采样影响。

可探索的方向：模型专属参数在不同渠道的错误形态、官方 API 文档中「仅某型号支持」的字段、多厂商能力基线与异常检测。若有新的可行手段，可在此补充。

九、终极武器：智能体鉴别 —— 展望 ​

核心思路：用智能体（Agent）来鉴别模型真伪，再微小的区别也能发现。

前文手段依赖规则、关键词、错误结构、id 前缀等可形式化特征。但真货与假货的差异往往体现在更细微的层面：风格、语气、知识边界、对特定 prompt 的响应模式、推理链的「指纹」等。人类专家凭经验能觉察的微妙差异，规则难以穷举。

智能体可承担「专家评审」角色：

  • 多轮对话探针：构造一系列精心设计的 prompt，诱导模型在风格、事实、能力边界上暴露差异。例如：同一道数学题，不同型号的推理步骤和犯错模式不同；对冷门知识的回答，蒸馏/微调模型与原文表现不一。
  • 行为基线对比：在可信渠道建立「真货」的行为基线（对固定 prompt 集的响应分布、长度、格式、引用习惯等），待检渠道的响应与基线做相似度/一致性分析，偏差超出阈值则视为可疑。
  • 元认知与自描述：通过「请描述你的能力边界」「你与某某模型有何不同」等元问题，观察模型的自述是否与声明一致。假货在细节上容易露出破绽。
  • 对抗式探针：设计易混淆、易被套壳层「平滑」的输入，观察输出是否出现不该有的平滑、截断或风格漂移。

优势：理论上可捕捉任意维度的差异，不受限于预先定义的规则集；可随新型造假手段演化而调整探针策略，具备自适应性。

挑战：

  • 成本：每轮鉴别需调用待测模型与可选参考模型，token 消耗显著高于规则探针。
  • 稳定性：大模型输出有随机性，同一模型多次响应未必一致，需多次采样、统计检验。
  • 对抗演进：若造假方知晓探针逻辑，可能针对性优化以通过鉴别，形成对抗博弈。
  • 可信参考：建立基线依赖「已知真货」渠道，若基线被污染，结论失真。

定位：可作为高价值场景的最后一公里验证，在规则探针筛过之后，对可疑或高价交付的渠道-模型做智能体复核，而非取代现有规则体系。未来若多模态、长上下文、工具调用等能力进一步成熟，智能体在「行为指纹」提取与比对上的潜力将更大。

附录：Gemini 备选探测（safetySettings） ​

json
{
  "contents": [{"parts": [{"text": "hi"}]}],
  "generationConfig": {"maxOutputTokens": 16},
  "safetySettings": [
    {"category": "HARM_CATEGORY_FAKE", "threshold": "BLOCK_NONE"}
  ]
}

非法 category 会触发官方结构化错误；逆向常忽略或返回通用错误。可与 candidateCount=9 一起纳入 Gemini 的违规参数探测集。