供应商数据策略

• ZDR 的适用范围界定
• 例外（监控、日志、安全）的处理
• 工具/日志/第三方网关的覆盖缺口

ZDR 指供应商不保留用于训练的数据，但它只覆盖"发送给模型 API 的输入输出"，不自动覆盖：①工具遥测——IDE/SDK 自带的遥测可能上传片段；②日志——应用/网关日志可能记录 prompt 与响应；③第三方网关——若经网关/代理转发，网关可能缓存或记录。因此技术设计须明确 ZDR 的合同边界，并把"例外"（如安全监控、计费去重、调试）限定为最小必要且不用于训练。落地时：在网关层禁止持留数据、配置不存储、审查日志与遥测开关、管理第三方网关的存储策略，把 ZDR 的承诺延伸到所有数据经过的环节。

ZDR 是"合同承诺+配置行为"，而非"自动安全"。工具、日志、网关都可能成为数据留存点，只有把 ZDR 落到所有数据路径并审查例外，才能真正零保留。

• 各 Provider 条款差异的核验维度
• 数据保留/训练开关
• 条款→采购决策的映射

核验维度：数据是否用于训练、能否关闭（opt-out / zero retention）、保留时长、地域、子处理方、审计与合规承诺。OpenAI 提供企业零保留选项，Anthropic 有 trust portal，Azure/AWS 有合规承诺与数据驻留，Google 有数据治理选项——差异需逐一核验并记录核查日期。映射到采购决策：数据敏感度高的选可零保留+驻留的 Provider；合规要求严的选有 BAA/DPA 与审计的；成本与质量权衡决定默认 Provider。把"条款核验结果"作为选型依据，并写进合同在技术侧验证（配置开关、日志确认）。

Provider 条款差异直接决定数据合规风险。按维度核验并记录，再映射到"数据敏感度×合规要求×成本"的采购决策，避免"默认供应商"或"仅看价格"。

• 地域限定的技术路径
• 配置验证（DNS、端点、密钥、网关、遥测）
• 端到端验证

地域限定需在多个层保障并验证：①DNS——用地域 DNS 解析到指定区域端点，验证解析结果；②端点——密钥/配置绑定到区域专用 endpoint（如 Azure 的 regional endpoint、AWS 的 regional service），验证请求实际打到该区域；③密钥——用区域专属密钥/账号，防止跨地域凭据；④网关——网关层强制区域路由与白名单，拒绝非合规区域；⑤遥测——把遥测/日志的存储也限定在合规区域，验证数据驻留。端到端验证：从客户端发起请求，检查实际落点（响应头、trace 的区域字段）、日志与存储位置，确认所有数据路径都在限定地域。

地域限定是"配置+验证"的闭环。单设 DNS 或密钥不够，需端点、网关、遥测、存储全链路落在限定区域，并用实际请求验证落点，才能真正确保数据不跨境。

• 政策变化的影响分析
• 通知与透明
• 配置切换与历史数据处置

政策变化处理流程：①影响分析——对比新旧政策，识别对数据保留、训练、地域、子处理方的影响，评估涉及的数据与场景；②通知——向相关方（用户、合规、客户）透明告知变化与影响，必要时获得同意；③配置切换——若影响合规，切换到不违规的 Provider/配置，验证切换后行为正确；④历史数据处置——评估并处理已产生的数据（删除、迁移、保留合规），确保历史数据符合新政策。整个过程记录在案，更新供应商政策台账并定期复审。

供应商政策一变，既有数据与配置可能立即不合规。按影响分析→通知→切换→历史处置四步，把单点政策变化转化为可控的合规迁移，并留存审计。

• Fallback 的合规约束
• 数据分级与目标绑定
• 故障时的降级策略

Fallback 必须有合规约束：①按数据分级绑定目标——高敏感数据只能 fallback 到合同内、合规区域、满足保留/地域要求的 Provider，禁止 fallback 到无合同或不合规区域；②目标白名单——Fallback 目标须在预审的合规 Provider 白名单内，排除无合同/不合规供应商；③故障时降级而非违规——若合规目标不可用，宁愿降级（拒绝、缓存、人工）也不把受限数据发给不合规目标；④路由治理——网关层校验每次 fallback 的目标与数据分级匹配，记录审计。用"数据分级×目标合规"的矩阵强制 Fallback 决策。

故障时匆忙 fallback 是数据跨境、无合同供应商的高发时机。用数据分级绑定合规目标、白名单约束、违规宁可降级，把 Fallback 也纳入合规边界，避免"故障即违规"。

• 子处理方清单的跟踪
• 第三方插件的风险
• 数据流审计与合同核对

子处理方：供应商须提供 Sub-processor 清单，平台定期核对新增/变更，评估其对数据保留、地域、用途的影响，并纳入合同义务（DPA 中的子处理方条款）核对。第三方插件（Plugins/GPTs）是独立的数据接收方，调用时可能把上下文发送给插件开发者，需纳入数据流审计：记录插件调用、发送的数据、目标方，评估其合规与合同义务，对高风险插件禁用或限制。统一用"数据流图"追踪数据流向（主 Provider→子处理方→第三方插件），每个数据接收方核对合同与合规。

数据会经子处理方和第三方插件流出，形成"数据流不透明"。把子处理方清单与插件调用纳入审计，用数据流图核对每个接收方的合同义务，才能掌握数据真实流向。

• 事故通知的接收渠道
• 影响评估
• 客户告知与监管报告

流程：①接收——建立供应商事故通知的可靠接收渠道（SLA 通知、邮箱、监控订阅），确保及时收到；②影响评估——评估事故是否涉及我的数据、影响范围（数据泄露、可用性、合规）与严重程度；③客户告知——按合同与合规要求向受影响客户/内部相关方告知，说明影响与应对；④监管报告——若触发法定披露义务（数据泄露、GDPR 72h 等），按流程向监管机构报告并记录。全程留存时间线、评估与上报记录，并用演练验证流程可用。

供应商事故会传导到自家客户与监管。从接收→评估→告知→报告形成闭环，并演练验证，确保事故时能及时、合规地响应，避免因不知情而漏报。

• 政策与能力动态变化
• 核查日期与版本管理
• 定期复审机制

供应商政策（数据保留、训练、地域、定价）与能力（模型、端点、合规承诺）会随时间变化，旧结论可能已失效。标注核查日期让结论"可追溯、可判断时效"，避免把过时结论当现状。定期复审机制：设复审周期（如季度/半年度），重新核验政策与能力，更新结论与台账，识别变更对合规的影响并触发应对。用版本管理记录每次核查，风险变化时立即复审。这样保证采购、合规、技术决策始终基于最新事实。

供应商是动态的，结论有"保质期"。标注核查日期+定期复审+版本管理，让每一个"供应商结论"都可知其时效，避免基于过期信息做出错误或违规决策。

• 三类证据的不一致
• 技术验证优先
• 合同与合规闭环

不一致时以"技术验证"为准作为上线依据：因为合同条款和供应商声明都是"承诺"，而实际 API 配置/行为才是"事实"，只有技术验证能确认数据是否真的不保留、是否真的落在限定区域、是否真的不用于训练。上线审查流程：先做技术验证（配置检查、请求落点、日志存储、保留行为），与合同和声明比对；发现不一致，以实际行为为准评估风险，不符合合规则拒绝上线，并推动合同/声明修正或用技术手段强制合规。合同是依据，但决定"能否上线"的是技术的实际可验证结果。

声明与合同可能落后于实际，或配置未被正确执行。技术验证提供"事实"，是上线审查的最终裁决；合同与声明用于对照与追责，但不能替代实际行为验证。

• 数据控制差异
• 审计与合规差异
• 退出成本与锁定

对比维度：①数据控制——自有部署数据完全在本地，控制强、合规可控；托管 API 数据在供应商，受其条款与地域影响。②审计——自有部署可完全掌控日志与审计、满足严格合规；托管 API 依赖供应商提供的审计与合规承诺。③退出成本——自有部署有硬件与运维成本，但无供应商锁定、退出成本低；托管 API 迁移/退出可能受格式、SDK、存储、数据导出限制，锁定成本高。④运维——自有需要自建推理与 GPU 运维，托管省运维引入依赖。评估时按数据敏感度、合规要求、团队运维能力、长期锁定风险权衡，可混合部署。

自有与托管是"控制/合规 vs 运维/成本"的权衡。数据敏感与合规严的选自有，追求快速与低运维的选托管，但需评估退出成本与锁定，避免长期被供应商绑架。

• 各类反馈信号的语义
• 噪声来源
• 操纵检测

各信号语义：点赞/点踩是显式偏好（强但稀疏、易受 UI 影响）；用户编辑是对"回答不理想"的修正信号（强信号，反映真实需求）；偏好修正（用户主动纠正）是明确意图；人工标注是高可信但昂贵的金标准。识别噪声：UI 误触、急切点击、样本偏差、跨版本不一致。识别操纵：异常高频（脚本刷赞）、同质化操作、时间模式异常、账号特征异常，用频率/分布/一致性检测发现。综合多信号加权，对噪声样本降权、对操纵样本剔除或标记，用人工标注校准。

反馈信号各有价值与噪声。理解各信号语义（点赞稀弱、编辑强、标注金标准），用频率与分布检测操纵，多信号加权融合并人工校准，才能得到可靠的反馈信号。

• 合规采样
• hard negatives 与对抗样本构造
• 分层评估集

合规采样：从生产数据中按合规要求采样（脱敏、授权、去除 PII），保留时间与分布信息。构造 hard negatives：选取与正样本相似但语义不同的样本（难负例），增强判别能力；对抗样本：针对薄弱点（注入、偏见、边界）构造攻击性样本测试鲁棒性。分层评估集：按场景（领域、难度、语言、输入类型）分层采样，保证各层都有代表性样本，避免单层偏差。配合跨时间段采样避免时间漂移。样本标注用人工+金标准校准，记录来源与版本。

评估集质量决定评测可信度。合规采样保证数据合法，hard negatives 与对抗样本提升判别与鲁棒性，分层保证覆盖，三者构成有代表性的评估集。

• 代理指标失效的定义
• 不一致的诊断方法
• 校准与修正

代理指标失效指离线指标（如准确率、BLEU、judge 分数）不能反映线上真实结果（留存、解决率、人工接管率），因为离线评估分布/任务与线上不一致。诊断：①对比两类指标的相关性——按层/按样本看离线分与线上结果是否一致，定位失效层；②追溯线上差异——分析线上失败案例（人工接管、解决失败）在离线是否被低估；③检查分布漂移——离线评估集与线上输入分布是否不同；④检查代理指标本身——是否度量了错误属性（如偏长、偏格式）。诊断后修正：用线上结果校准评估集、补充线上样本、调整代理指标或改用线上指标。

离线指标是代理，线上结果才是事实。用相关性分析、失败案例追溯、分布漂移检查定位失效点，再校准代理指标或补充样本，避免"离线涨、线上差"的假象。

• 反馈飞轮的偏差放大机制
• 少数群体与虚假信息保护
• 偏差监测与缓解

反馈飞轮会放大偏差：多数偏好被强化、虚假信息获得正反馈、少数群体样本不足被忽视。缓解：①意识与检测——定期监测不同群体/主题的反馈分布与质量，识别偏差放大；②对少数群体加权——对样本不足的小群体提高权重或补充采样，避免被多数淹没；③虚假信息防护——对反馈内容做真实性校验，防止错误信息通过正反馈固化；④多样性保护——在反馈驱动的优化中约束多样性，避免单一偏好收敛；⑤人工校准——用金标准与公平性评估基准校正，记录偏差并定期复审。

反馈飞轮是"偏好固化"的加速器。通过监测、少数群体加权、虚假信息校验、多样性约束与人工校准，防止系统被多数偏好或错误信息带偏，保护少数群体。

• 标注一致性度量（Cohen's Kappa 等）
• 阈值设定
• 重新标注与剔除

标注一致性用 Cohen's Kappa（两标注者）、Fleiss' Kappa（多标注者）度量，考量"超出随机预期的同意程度"。设定阈值（如 Kappa>0.6 为中等、>0.8 为良好），低于阈值说明标注歧义或标注者能力不足。处理：①重新标注——对低一致样本交由更多标注者重标，或明确标注规范、修正歧义；②剔除——对始终无法一致、本质歧义的样本剔除，避免脏标签污染模型；③分歧分析——分析分歧来源（规范不清、样本本身模糊），改进标注规范。记录一致性指标与处理过程，保证数据集质量。

标注一致性是标注质量的核心度量。用 Kappa 量化一致度，低一致时通过重标、剔歧、修规范处理，确保反馈数据标签可靠、可复现。

• 刷反馈的动机与模式
• 检测方法
• 防御机制

刷反馈是为奖励（积分、优惠、排位）而制造虚假反馈。检测：①频率异常——单用户反馈量远超正常；②模式异常——高度同质化、快节奏、批量、创建时间集中；③内容异常——低质量、重复、与交互不符。防御：①去掉可刷的奖励——把奖励与"真实使用"绑定而非"反馈次数"；②质量校验——用内容质量、一致性、交互真实性过滤；③频控与限额——限制单用户反馈频率；④异常标记——对疑似刷量样本降权、剔除或人工复核；⑤匿名与去重——避免同一人重复贡献。用"动机+模式+质量"三重防御。

游戏化 feedback 会污染数据。通过捆绑真实使用、频控、质量校验与异常检测，从动机与模式上削弱刷反馈，保证反馈数据反映真实用户而非刷量者。

• 多维能力对比
• 服务能力对齐
• 能力匹配的 Fallback 选择

Fallback 前要比较能力而非仅换模型名：①结构化输出——候选模型是否支持 JSON schema / 函数调用且格式稳定；②工具——是否支持所需工具、参数解析、工具调用质量；③多模态——是否支持任务所需的图像/音频输入；④安全——内容安全、拒绝率、注入鲁棒性。比较方法：用统一评测在结构化、工具、多模态、安全四个维度打分，建立"能力矩阵"，按任务需求选匹配的 fallback 目标（如任务需多模态则 fallback 到多模态模型，需结构化则选 schema 稳定的模型）。同时兼容输出格式（归一化、schema 转换），记录能力差异。

只改模型名会导致 fallback 后能力不匹配（如降级到不支持多模态的模型）。按结构化/工具/多模态/安全的能力矩阵选 fallback，并归一化输出格式，才能保证降级后仍能满足任务。

• 退避与断路器
• 幂等键与去重
• 防重复扣费/副作用

故障期间重试可能造成重复扣费或重复副作用。防护：①带抖动的有界退避——重试间隔有上限且加随机抖动，避免重试风暴与峰值；②断路器——连续失败时熔断，停止重试，让系统冷却，避免在故障 Provider 上反复重试烧钱；③幂等键——每个请求带唯一 idempotency key，服务端对相同 key 只执行一次，重试不产生重复扣费/副作用；④请求去重——网关对相同 key 的重复请求去重，返回同一结果。四者组合：退避控频、断路器止损、幂等去重防重复。

故障时的重试是重复扣费与副作用的来源。退避+断路器控制重试节奏与止损，幂等键+去重保证重试幂等，从"频率"与"语义"两侧防重复。

• 降级策略分级
• 各降级手段的适用场景
• 降级与回退组选择

按降级深度排序：①固定回答（静态兜底文案）——适合最低级降级，Provider 全部不可用时给出安全、明确的兜底；②模板回答（结构化模板填充）——适合中等降级，用模板+已知格式给出基础回答；③历史已验证答案（缓存/知识库中已确认的答案）——适合高可用降级，质量较高、已验证，适合可复用场景；④人工接管——适合需要质量、风险高或自动化无法回应的场景，转人工保准确。降级链设计：优先用好质量手段（历史答案），再降模板，最后固定，必要时人工接管。每个等级要明确告知用户"能力受限"。

不同降级等级对应不同质量与成本。按可用性与质量需求选择：历史答案质量高、固定兜底最安全、人工接管保准确，组合成"由高到低"的降级链并明确告知。

• 容量与性能差异
• 数据格式兼容
• 内容安全与观测差异

切换前演练差异：①容量——自托管受 GPU/并发限制，需压测容量与吞吐，验证能否承接生产流量；②数据格式——自托管模型的输入输出、token 化、schema 可能不同，需验证格式兼容并做归一化；③内容安全——自托管默认可能缺少云端的内容安全护栏，需自建或接入安全过滤；④观测——自托管需自建日志、指标、trace、告警，验证可观测性。演练用影子流量/灰度在小流量上验证，对比切换前后行为，确认四类差异已处理，再逐步放量。演练还覆盖故障切换与回滚。

云→自托管是多维变化，不能只换端点。通过容量压测、格式兼容、内容安全补齐、观测自建的演练，并用影子流量/灰度验证，避免切换后容量不足、格式错乱、防护缺失、观测盲区。

• 降级标识的透明告知
• 能力受限与数据新鲜度的说明
• 避免误导

降级响应需明确告知：①能力受限——用可见标识（banner、tag、文案）说明"当前为降级模式/能力受限"，说明哪些能力不可用（如无法多模态、无法实时推理）；②数据新鲜度——说明回答基于的数据时间/来源（如"基于历史缓存，截至 X"），避免用户误以为是实时完整回答；③原因——简要说明降级原因（Provider 故障、容量不足）。用 UI 标识+文案+数据来源时间戳，让用户清楚"这不是完整智能服务"。避免用与完整版相同的呈现，造成误导。

降级若不加标识，用户会误以为结果仍代表完整能力。透明告知能力受限、数据新鲜度与原因，建立信任并管理预期，避免降级结果被误读为完整智能。

• 5 Why 方法
• 根因分析流程
• 行动项与预防

用 5 Why 逐层追问找到根因：从"Provider 事故发生了什么"开始，连续问"为什么"，直到找到系统/流程层面的根本原因（而非表层）。例如：事故→为什么降级失败→为什么 fallback 未生效→为什么配置未校验→为什么没有测试覆盖→为什么没有 fallback 演练。根因常指向流程/配置/测试缺失而非单点操作。复盘后形成可执行行动项（补演练、加校验、修配置），验证行动项落地并跟踪其有效性，写入标准作业。5 Why 要避免"归咎个人"，聚焦系统与流程。

Provider 事故的根因常被表层"换个供应商"掩盖。5 Why 穿透到流程/配置/测试的系统根因，配行动项与验证，把一次事故转化为体系改进，避免重复同类故障。

• 链路过长的延迟累计
• 总延迟预算
• 用户体验保障

Fallback 链过长会累计延迟，多次重试后用户体验恶化。保障：①限制链长——设定最大 fallback 次数（如 2-3 次），超过即停止，避免无限重试；②总延迟预算——给整条请求设总超时预算，fallback 各环节分配预算，超预算即返回当前结果或降级；③快速失败——对明显不可用的 Provider 快速判定（健康检查、超时缩短），不浪费重试；④尽早兜底——质量尚可时用高可用手段（历史答案），避免逐级重试到底；⑤用户体验——告知用户等待/降级，超过预算返回部分结果或明确错误。用"预算+限长+快速失败"控制链路。

Fallback 的价值是提高可用，代价是延迟。限长+总预算+快速失败+尽早兜底，把延迟控制在不损害体验的范围内，让 Fallback 在"可用"与"延迟"间平衡。

• 合规要求到技术配置的映射
• 端点/日志/工单/通知的具体落点
• 合规矩阵

把合规要求映射到具体技术落点：①端点——HIPAA 需 BAA 且数据加密，GDPR/PIPL 需地域驻留与合规端点，用区域端点+加密+合规 Provider 满足；②日志——日志需脱敏、最小化、保留期合规（GDPR 数据最小化、HIPAA 保护 PHI），删除/审计策略对齐；③支持工单——支持流程涉数据处理需符合合同与 DPA，工单内容脱敏、访问受限；④事故通知——GDPR 72h 泄露通知、HIPAA 泄露通知、企业合同通知义务，映射到事故通知流程与 SLA。建立"要求→落点"的合规矩阵，逐项核对并验证。

合规要求是抽象的，必须落到端点、日志、工单、通知等具体环节。用合规矩阵把每个监管/合同条款映射到可验证的技术配置，确保合规不是口头而是可执行。

• 各实验方法特性
• 假设匹配（排序、回答、可靠性）
• 方法选择

各方法适合不同假设：①影子流量（shadow）——把生产流量复制到新模型但不影响用户，适合验证"回答质量"与"系统可靠性"（无用户风险、可辅助离线评测），但无法测真实用户行为；②A/B——随机分用户对比，适合验证"真实用户偏好与业务指标"（回答是否被采纳、留存）；③Interleaving——同一请求内交替两种回答，适合验证"排序/偏好"（更敏感、样本效率高）；④Canary——小流量灰度发布，适合验证"系统可靠性"（稳定性、回归、容量）并逐步放量。按要验证的假设选择：排序用 Interleaving，回答质量+用户行为用 A/B，可靠性用 Canary/影子。

方法对应不同假设与风险。影子/Canary 验证系统可靠性，A/B 验证用户行为，Interleaving 验证排序偏好，按假设与风险权衡选型，避免方法错配。

• 冷启动与热启动的资源与耗时差异
• 预热机制与资源冗余
• 资源浪费与故障切换时间的权衡

冷启动（Cold Start）指从零拉起实例/加载模型权重，耗时最长、资源占用瞬时高，但闲置时几乎不占资源；热启动（Warm Start）是实例已就绪、仅需最小初始化，切换快但长时间占用资源。预热（Pre-warm）是在引擎空闲时预先拉起并保持就绪的实例池，本质是用"常驻资源"换"切换时间"。平衡策略：按流量与故障容忍度设置最小就绪池（min replicas），低峰期缩容、高峰与故障窗口前预热；对关键路径（如推理模型、网关）保留热备并做健康检查，无法承担切换延迟的服务用持续预热，允许冷启动的服务用弹性伸缩。核心是量化"多等几秒"的代价与"多占资源"的成本，用池化与弹性策略在两者间取折中。

冷启动省资源但切换慢，热启动/预热快但占资源。用就绪池+弹性伸缩+按关键度分级，把资源与切换时间的权衡变成一个可配置的工程参数，而非二选一。

• GameDay 演练的机制与频率
• 复现各类故障场景
• 验证降级与人工接管链路

GameDay 是定期在受控环境主动注入故障、验证系统在故障下行为与恢复预案的演练机制。做法：①建立故障清单——配额耗尽、区域故障、网关故障、人工接管等场景，为每个场景定义触发方式、预期行为与验收标准；②注入故障——在预演/影子环境真实触发（如人为耗配额、切断区域流量、模拟网关超时），观察降级、fallback、告警是否按预期工作；③验证人工接管——演练"自动降级不可用时的升级路径"，检验值班、审批、人工回退链路是否真的可操作，而非停留在文档；④复盘——记录演练结果，改进预案与自动化。GameDay 要定期（如季度）执行、覆盖真实链路、用演练结果反哺系统配置，避免"预案只在纸面"。

故障预案若从不演练，往往在真实故障时才发现链路断裂。GameDay 用定期、真实、受控的故障注入验证配额、区域、网关与人工接管链路真正可用，把就绪状态变成可验证、可持续的工程能力。