模型单一化风险：当所有 AI 都同意同一个错误答案

前面几章聊的都是多 model 方案的好处。这一章换个角度，聊聊坏处——把宝全押在一个 AI 家族上有多危险，而且危险的地方跟大多数人想的完全不是一回事。

没人聊的那个风险

一提到「只依赖一个 AI」，大家第一反应都是宕机。OpenAI 挂了，workflow 全停，开发到处找替代方案。2025 年 6 月确实出过事——ChatGPT 和 API 服务整整一天错误率飙升。2024 年 12 月更夸张，云厂商电力故障导致错误率超过 90%。还有 2024 年 7 月 CrowdStrike 那次更新，Parametrix 估计大约四分之一的 Fortune 500 公司中招。

这些事都是真的。但它们是看得见的风险。API 返回 500 的时候，谁都会注意到。

真正可怕的是看不见的风险：AI 给了你一个错误答案，而没有任何东西会跳出来反驳它。

想想看：如果你的开发团队全用 GPT 做 code review，同一类 bug 每次都能蒙混过关。不是随机冒出来的 bug，而是 model training 里自带的系统性缺陷。如果你的法务部门全用 Claude 审合同，同一类有问题的条款每次都会被漏掉。不是 model 不行——每个 model 都有盲点，你只用一个，它的盲点就自动变成了你的盲点。

宕机动静大，但总会恢复。系统性地给你错误答案，反而无声无息，影响也深远得多。

所有人拿到同一个错误答案

2008 年金融危机，不是某一家银行押错了赌注。原因一大堆——杠杆、证券化结构、激励错位、监管漏洞。但有个容易被忽视的因素：大多数银行用的 risk model 都差不多，基于相似的假设，对 mortgage-backed securities 得出相似的结论。错误之所以高度相关，是因为方法论本身就是共享的。Model 们互相「同意」，反而让共同的盲点更难被发现。

这就是 AI 单一化风险的核心。

当一个行业的大量分析都流经同一个 AI 家族，错误从结构上就注定了是相关的。不管哪个客户在调 API，model 看到的训练数据一样、架构一样、系统性偏差也一样。如果 GPT-4 系统性地低估了某类安全漏洞——而第一章引用过的研究显示 45% 的 AI 生成代码含有安全缺陷——那所有用 GPT-4 做安全审查的团队，都留着同一个口子。

第二章提到的 echo chamber 研究显示，同家族的 AI agent 不仅不会纠正错误，反而会「放大对错误答案的信心」。把这个效应放大到一个组织，再放大到整个行业。单一 AI 家族铺得越广，错误就越互相关联，也越难被发现——因为根本没有反对的声音。

这跟人类的单一化还不一样。同一所学校出来的人，好歹还有不同的人生经历、不同的直觉、处理问题时不同的 random noise。同一家族的 model 呢？共享训练数据、共享架构假设、共享优化目标。它们之间的一致不是独立验证，而是高度相关的训练产出了高度相关的结果。

认知锁定

Flexera 2025 State of the Cloud 报告显示，大约 86% 的组织已经在多个云上跑工作负载了。大部分人把这当成一个基础设施决策来看——容灾、failover、议价能力。

但更深一层的教训是关于依赖式思维的。那些 all-in 单一云厂商的组织，面对的不只是宕机时的运营风险，还有认知锁定。架构、工具链、工程文化全都围绕一个厂商的方式长出来了。切换不是一个 technical migration，而是一次 mindset 的迁移。

AI 依赖是同样的动态，但扎得更深。云厂商决定你怎么 deploy 代码，AI 厂商决定你怎么思考代码。哪些问题会被标出来、哪些 pattern 会被推荐、哪些 tradeoff 会被摆到台面上——全是它在替你选。当一个 model 家族包办了所有的思考，它的假设就变成了你的假设。它的盲点变得不可见，不是因为盲点小，而是你的 workflow 里没有任何东西会去挑战它。

Parallels 2026 年的调研显示，94% 的 IT 负责人在担心 AI vendor lock-in（样本偏 end-user computing，范围窄了些，但这个情绪是准的）。运营层面的锁定担忧没毛病。但认知锁定才应该让他们睡不着觉。

公平地说说反方观点

多 AI 策略确实会引入真实的复杂度，这点我不想装看不见。

合规复杂度。每多加一个 AI provider，就多一份数据处理协议、多一轮安全审计、多一层监管面。在受监管的行业里，三个 provider 意味着三次 vendor risk assessment、三份 DPA、三套 compliance monitoring。

数据治理。把 proprietary data 同时发给多个 provider，attack surface 变大了，data residency 的要求也更难搞。不是每个 provider 都支持每个 jurisdiction。

评估开销。你需要 benchmark 来搞清楚哪个 model 能抓住什么。Build 和 maintain 一套 evaluation infrastructure，去分辨 cross-family 之间的分歧到底是真正的纠正还是只是噪音——这不简单。

延迟。Sequential multi-model pipeline 更慢。对于 real-time 应用——live chat、fraud detection、trading system——multi-model routing 带来的 latency cost 可能比 accuracy gain 还大。

相关失败。如果多个 model family 都是在大量重叠的 internet data 上 train 出来的，它们的 blind spots 可能比想象中更相关。Cross-family diversity 未必看起来那么 orthogonal，尤其是 closed-source model，你根本看不到 training data 里有什么。

这些成本都是真的。但它们是可以 engineer 的问题。另一边的替代方案是什么？你整个组织的 AI 输出共享着互相关联的 blind spots——这是 structural vulnerability，堆再多算力、写再好的 prompt 也不会自动消失。

监管层已经看到了这个 pattern

监管机构开始标记 AI concentration risk 了，路径跟当年处理 cloud 和 financial services 集中风险时如出一辙。

Financial Stability Board 2024 年的报告把 AI service provider concentration 列为金融行业的 vulnerability。FSB 监测全球金融稳定，它的评估会影响各国监管框架。它们担心的不只是 outage，而是当 correlated AI errors 在整个行业里催生 correlated bad decisions 的时候，会发生什么。

EU AI Act 在 2024 年 8 月生效，覆盖 general-purpose AI model 的系统性风险，包括 risk assessment 和 incident reporting 要求。欧盟还在探索 Cloud and AI Development Act（公开咨询期是 2025 年 4 月到 7 月），专门针对对非欧盟 cloud 和 AI provider 的依赖问题。

监管层的逻辑，说到底跟银行投资组合分散要求是一回事：不要把赌注全押在一个 model 上。这里赌的不只是 availability，而是 correctness。

为什么这是结构性问题

AI 的 concentration risk 和其他领域不一样，因为 failure mode 完全不同。

Cloud provider 挂了，failure 是显性的。所有人都知道。Response team 启动，几小时或几天后服务恢复。

但当一个 AI model 的 blind spot 在成千上万用户那里生成系统性的错误输出时，failure 是隐形的。每个用户看到的都是一个语气自信、格式漂亮的答案。没有 error message，没有 alert。只是一个看起来正确的错误答案，在每个用同一个 model 的团队里悄悄复制。

问题不是「AI 挂了会怎样」，而是「AI 自信地错了、但没人知道会怎样」。

Cross-family review 就是用来抓这类问题的。当一个不同家族的 model 给出的输出跟第一个不一致，这个分歧本身就是信息。有时候分歧只是 noise。有时候它能抓到本来会在你整个组织里静默传播的系统性错误。你只有先制造出这种 conflict，才有机会区分这两种情况。