硬门槛、隐私与部署边界
本节目标
把不能用平均分补偿的要求写成先执行的 gate，并为每个 gate 保存可核验证据。
核心概念
硬门槛是候选必须满足的布尔条件。没有通过的候选不能进入加权排序，即使它的质量、速度或价格更好。常见 gate 包括：
| 类别 | 例子 | 证据责任人 |
|---|---|---|
| 能力 | 结构化输出、目标语言、工具协议 | 工程探测 + 官方文档 |
| 数据 | 训练用途、保留、驻留、删除、跨境 | 隐私/法务 + 合同 |
| 安全 | 身份隔离、加密、审计、漏洞响应 | 安全评审 + 控制测试 |
| 部署 | 托管区域、自托管、硬件、离线可用 | 平台团队 + 容量测试 |
| 许可 | 权重、代码、输出和派生用途 | 法务 + 许可证原文 |
| 运行 | 最大 p95、单位成本、配额和可用性 | 负载试验 + SLA |
| 质量 | 关键切片的最低成功率/零容忍失败 | 冻结评测 + 人工复核 |
“资料未知”不是通过。它应成为可解析的候选级 blocked 状态，由有权限的人补证或批准例外；不能把未知悄悄填成 false/0，也不应因一个候选待补证而让其他候选的整批报告消失。
为什么需要
一个不满足数据驻留的候选，不能因准确率高而“抵消”合规缺口；一个能越权执行写操作的候选，也不能用低成本补偿。NIST GenAI Profile 强调在生命周期中识别、测量、管理和治理风险，因此选择记录不仅是性能表，还应包含来源、责任和残余风险。
怎样实现
为每项 gate 固定以下字段：
gate_id, predicate, threshold/unit,
evidence_uri, evidence_checked_at, evidence_owner,
result(PASS/FAIL/BLOCKED), exception_id, expiry离线项目把候选证据收敛为严格对象：
{
"status": "verified",
"uri": "urn:example:model-card:v3",
"checked_on": "2026-07-17",
"owner": "model-governance",
"expires_on": "2026-08-17",
"missing_items": []
}字段阅读（严格 JSON 不能写行尾注释，避免示例变成不可解析的配置）：
status表示证据当前被核验为哪种状态；这里的verified不是模型自报，而是受控流程给出的结论。uri是能回查证据原件或记录的位置；它不应只是一段无法核验的自然语言说明。checked_on记录最近一次人工或受控流程核验的日期，便于判断结论是否过时。owner是对证据负责、能补证或解释异常的角色，而不是模型供应商名称的替代品。expires_on规定这份证据在何时失效；到期后应重新核验，而不是继续沿用。missing_items列出仍缺少的材料；已验证状态使用空数组，blocked状态则必须明确列出缺口。
verified 必须有 URI、owner、核验日、到期日且没有缺失项；到期后产生 evidence_expired gate failure。blocked 必须列出 missing_items，并产生候选级 evidence_status_blocked 与逐项缺口。缺字段、未知字段或互相矛盾的状态仍是 malformed schema，应拒绝整个输入；“结构合法但证据未齐”才是可比较报告里的 blocked 候选。
执行顺序建议为：证据完整性 → 法律/数据/安全 → 接口与部署 → 关键质量 → 成本与延迟。失败即停止后续“美化分数”，但仍保留原始评测供诊断。
对于托管模型，要核对具体服务、区域、账户层级和合同，而不是把同一模型在不同云上的政策视为相同。对于自托管模型，还要把硬件、量化、推理引擎、并发和补丁责任纳入选择对象。静态 capability 标签也不能替代行为 gate：当任务要求结构化输出或工具调用时，分别检查 min_structured_output_rate 与 min_tool_success_rate。
常见失败
- 把隐私写成供应商的一个
yes/no宣传字段。 - 用加权总分让高质量候选抵消安全或许可失败。
- 只记录网页截图，不记录 URL、日期、合同版本和适用范围。
- 将“自托管”等同于“自动安全”，忽略镜像、权重、运行时和运维责任。
- gate 过期后仍沿用旧结论，或例外没有 owner 与 expiry。
怎样验证
做一次故障注入：把最高质量候选的 training_use 改为不允许、把数据驻留证据删除，评分器必须将其排除且不给出加权分。再检查例外是否有明确批准人、范围和失效时间。
实践任务
为一个含个人数据的 RAG 应用写 10 项 gate。邀请安全、平台和产品各自指出一项无法由模型 benchmark 回答的问题；把证据缺口也作为阻断结果保存。