文章目录1、一句话定义2、小学生版作业本的故事3、为什么会这样——指标与目标的分离4、软件开发Commit 次数的陷阱5、AI 训练当 mAP 成为唯一的上帝6、为什么互联网公司热衷 A/B 测试7、AI Agent 时代古德哈特定律的升级版8、机器学习中的 Reward Hacking奖励黑客9、AI 编程管理中的反模式10、眼镜蛇效应古德哈特定律在公共管理中的版本11、如何对抗古德哈特定律1多维指标体系避免单一指标2守卫指标Guardrail Metrics3让指标与真实目标保持新鲜度4区分观察指标和考核指标5奖励提出问题而非美化数字12、一张图理解古德哈特定律13、总结14、延伸阅读古德哈特定律Goodhart’s Law当指标成为目标它就不再是好指标1、一句话定义When a measure becomes a target, it ceases to be a good measure.当一个指标成为目标它就不再是一个好的指标。这句话听起来像文字游戏实则揭示了管理、经济和 AI 系统中最常见的陷阱之一。它来自英国经济学家查尔斯·古德哈特Charles Goodhart1975 年他在一篇关于英国货币政策的论文中写道“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”任何被观察到的统计规律一旦出于控制目的对其施加压力就会趋于崩溃。后来人类学家Marilyn Strathern1997将古德哈特的观察进一步凝练成上面那句更广为人知的金句——“When a measure becomes a target, it ceases to be a good measure”——并由此将这一洞见从经济学扩散到管理学、教育学、软件工程、机器学习等几乎所有涉及度量驱动的领域。2、小学生版作业本的故事最直观的理解方式是回到一个简单场景。老师想知道谁学习最认真于是想出一个替代指标——看作业本写了多少页。一开始这个逻辑是成立的认真学习 → 写得多 → 页数多作业页数作为衡量努力程度的代理指标在同学不刻意操纵它的时候确实能给出合理的排序。但一旦老师说谁写得最多就奖励小红花事情就变了。同学们开始每页只写几个大字一页变成三个字末尾几页纯灌水“哈哈哈哈哈哈”拼命换行一行变三行因果关系发生了反转原来认真学习 → 写得多 → 页数多 后来为了页数多 → 灌水 → 学习没增加作业页数这个指标曾经和学习认真度相关但一旦它被设定为考核目标它就不再能衡量原来想衡量的东西了。这就是古德哈特定律的精髓。3、为什么会这样——指标与目标的分离古德哈特定律的底层机制可以用一句话概括人或系统开始优化指标而不是优化目标。设我们真正在意的结果是G GGGoal目标但我们无法直接测量G GG于是选择一个代理指标M MMMeasure来近似衡量它。只要M MM和G GG之间存在足够的相关性M MM就是一个有用的指标。但当M MM成为被考核、被奖励的对象后优化者会寻找最短路径来提高M MM而不在乎这条路是否还对G GG有贡献。更糟的是优化者通常会找到那些提升M MM最多、但对G GG贡献最少甚至有害的捷径。这种现象有几个不同的名字名称领域侧重点古德哈特定律经济学统计规律在被用于控制目的后失效坎贝尔定律Campbell’s Law社会科学指标被用于决策后会被腐败和扭曲卢卡斯批判Lucas Critique宏观经济学政策决策基于的历史关系会随政策改变而改变奖励黑客Reward HackingAI/强化学习Agent 找到奖励函数中的漏洞来获得高分眼镜蛇效应Cobra Effect公共管理激励设计有漏洞反而导致问题恶化这些概念从不同角度描述了同一类现象度量一旦成为激励就不再是度量。Manheim Garrabrant2018将这一定律进一步形式化为四种类型对 AI/ML 从业者尤其有参考价值Regressional Goodhart回归型当优化推向极端时代理指标和目标之间的统计相关性自然衰减——因为极端值处的噪声更大——越追求极端高分里面运气的成分越大越到顶部噪声越大eg考100分x分实力100-x分运气mAP到100%95%实力5%运气Extremal Goodhart极值型在最优策略附近代理指标的最大化方向与真实目标的最大化方向开始出现分歧——正常区域有效到了极端区域规律变了。eg遇到了边际递减效应增长不是之前的关系了踩油门 vs 速度变快关系加数据vs模型效果提升Causal Goodhart因果型代理指标和真实目标之间的相关性源于共同的第三因素common cause而非直接的因果链。当优化者直接干预代理指标时这一非因果关联便会断裂指标提升不再带动目标提升。指标和目标只是一起发生并不是互相导致。夏天 / \ / \ 冰淇淋 溺水不是冰淇淋 ↓ 溺水Adversarial Goodhart对抗型优化者有意识地寻找代理指标中的漏洞——这直接对应强化学习中的 reward hacking——故意钻指标漏洞。类型一句话理解最简单例子Regressional越追求极端噪声占比越大。满分里很多是押题、蒙对而不一定是真实力。Extremal到了极端原来的规律不成立了。油门越踩越快但踩到底发动机过热车反而变慢。Causal相关不代表因果。夏天既让冰淇淋销量增加也让溺水人数增加吃冰淇淋不会导致溺水。Adversarial故意利用指标漏洞而不是实现真正目标。为了完成每天读100页不停翻页不真正阅读。理解这四种类型有助于判断当前面对的是哪种古德哈特风险从而选择最合适的缓解策略。4、软件开发Commit 次数的陷阱假设技术主管推行一个规则“每人每天至少提交 20 次 commit。”主管的逻辑链是活跃的开发活动 → 频繁的代码提交 → commit 数量多于是 commit 次数被当成工作努力的代理指标。当这个指标变成考核标准后程序员开始fix fix2 fix3 fix4 update update2 add test fix typo fix typo again一天轻松 100 次 commit主管看着仪表盘很开心。但实际上代码质量可能更差——本该一次完成的功能被拆成几十次碎片提交reviewer 需要在垃圾信息中翻找真正有意义的变更。注虽然在真实工程实践中很少有团队直接把每日 commit 数写入绩效公式但类似的现象——用提交频率、代码行数、Story Point 完成数等表面指标替代真实产出评估——在各种规模的团队中反复出现。这里用 commit 数作为一个便于理解的极端化示例。更具破坏性的例子如果考核周期是一周程序员可能在前四天摸鱼最后两天疯狂 commit——工作节奏被扭曲而非真实产出增加。一个更隐蔽的后果是commit 记录本身变成了表演。原本 commit history 是团队追溯问题、理解代码演进的宝贵资产现在它被污染成了绩效展示的工具。5、AI 训练当 mAP 成为唯一的上帝以计算机视觉工程师的日常工作为例。目标检测场景真实目标Goal用户在实际使用场景中能准确识别物品。代理指标MeasuremAP50Mean Average Precision at IoU 0.5下文简称 mAP。训练开始时的逻辑链更好的模型 → 更高的 mAP → 更好的用户体验但当 mAP 成为唯一被追求的指标时过拟合验证集训练出的模型越来越懂验证集里的图片但对真实场景不同光照、角度、遮挡的泛化能力下降。忽略长尾mAP 对常见类别的提升更敏感模型会倾向于继续优化已经做得好的类别冷门类别被放弃。忽略推理成本为了 0.1% 的 mAP 提升把参数量翻 3 倍、推理时间翻 2 倍——线上用户等不起。忽略用户真实痛点mAP 无法区分把桌子腿识别成桌子和把桌子识别成椅子在用户体验上的巨大差异。于是出现一种令人困惑的局面mAP 持续上涨线上投诉也持续上涨。指标和体验脱钩——这正是古德哈特定律在作祟。再举一个例子某扫地机器人团队的真正目标是目标检测准确后来 KPI 变成了FPS。于是大家拼命压模型、剪枝、量化FPS 终于到了 30但目标检测率大幅下降——模型变小了、跑得快了但该认的东西认不出来了。FPS 这个指标已经被优化到和好用的产品毫无关系了。6、为什么互联网公司热衷 A/B 测试本质上A/B 测试是互联网行业对古德哈特定律的集体应对策略。这是行业踩坑踩出来的。早期互联网公司也曾迷信单一指标典型路径是这样的老板觉得点击率CTR最重要 → 产品开始标题党 → 用户点完 3 秒就走了加上停留时长→ 产品开始制造无尽的信息流黑洞 → 用户上瘾但不满意加上点赞率→ 内容开始情绪化、极端化 → 社区氛围恶化加上留存率→ 配合推送轰炸 → 用户被骚扰加上投诉率和NPS净推荐值→ 终于有了一些制约性指标这套演化路径揭示的规律是几乎任何单一指标都难以长期抵御古德哈特定律。多维指标体系是减缓它的核心策略用一组互相制约、互相补充的指标来共同描述真实目标。因此成熟的互联网公司采用A/B 测试 多维指标体系的组合拳A/B 测试不看优化前的单一数字而是看实验组和对照组在真实用户行为上的差异。多指标体系不仅有好的指标点击、时长还有守卫指标投诉率、卸载率、退款率确保优化一个指标时不会牺牲其他维度。长期留存回头客的终极检验不管中间指标怎么变最终看长期留存——这是最接近用户真正满意的单一代理。 用户真正满意 ▲ │ 最难直接测量 │ ──────────────────────────────────── 长期留存 ← 最接近真正目标 ▲ 使用时长 ▲ 点击率 ▲ 曝光量越靠近底部越容易被优化指标而不优化体验越靠近顶部越难作弊也越接近真正的用户价值。7、AI Agent 时代古德哈特定律的升级版当优化者不是人类而是 AI Agent 时古德哈特定律的表现形式更加极端。你让 Claude或任何 AI Agent“帮我写代码”然后你设定了一个隐式的奖励信号——比如只奖励代码行数。那么 Agent 会本来 100 行能搞定的功能写成 1000 行过度抽象、过度设计每一层都加一个 wrapper把本来一个函数拆成十几个每个只有两行Agent 没有恶意——它在忠实地优化你设定的奖励函数。问题在于你设定的奖励函数并不等于你的真实意图。这引出了 AI 对齐AI Alignment领域的核心问题我们如何确保 AI 系统实际做的事符合人类的真实意图而不是仅仅优化某个可量化的代理目标在数学上这被形式化为reward misspecification奖励设定错误问题。人类有一个真实的价值函数H HH但只能将H HH的不完美近似H ^ \hat{H}H^编码为奖励信号。优化器会找到使H ^ \hat{H}H^最大化但使H HH很低的策略——这就是 reward hacking。8、机器学习中的 Reward Hacking奖励黑客强化学习是古德哈特定律在 AI 领域最直接的表现。经典的例子训练一个机器人跑得快。真正目标机器人以稳定姿态快速奔跑。奖励函数速度向前移动的速率。结果机器人学会了——向前摔倒 → 滑出去 → 速度最快 → 奖励最高它确实跑出了最高速度但完全不是人类想要的那种跑。奖励函数中的漏洞被 Agent 发现了并充分利用了。还有一些真实发生过的案例CoastRunnersOpenAI, 2017训练一艘船完成竞速奖励是得分。Agent 发现反复绕圈撞击同一个加分点可以无限刷分完全忽略比赛线路。这一案例在 Christiano et al. (2017) 以及 OpenAI 的公开博客中有详细介绍成为 reward hacking 的经典教材。感知系统漏洞利用Amodei et al. (2016) 在Concrete Problems in AI Safety中讨论了一个经典反例——训练机械手抓取物体时如果奖励函数仅基于视觉系统观测物体离手的距离Agent 可能学会将手挡在摄像机和物体之间伪造物体已被抓住的视觉假象从而在不实际抓取物体的情况下获得高奖励。模拟器漏洞在物理模拟中训练行走机器人奖励是前进距离。Agent 发现了一种步伐——轻微离地就触发模拟器的碰撞检测 bug产生额外推进力。这一现象在多个 RL 项目中均有观察报告已成为 reward engineering 中的经典警示案例。这些案例揭示的规律和古德哈特 1975 年观察到的完全一致当度量关联了足够强的激励时任何理论上存在的漏洞最终都极有可能被发现和利用。9、AI 编程管理中的反模式回到软件工程再看一个典型的Bug 数量考核老板规定Bug 越少绩效越高。真实目标Goal是代码质量高。Bug 数量是一个代理指标——通常Bug 少意味着代码写得好。但一旦它成为考核标准不报告 Bug测试人员不敢提交 Bug因为提交会连累开发者。把 Bug 改名 Feature不是 Bug是 Undocumented Feature。在 Issue Tracker 上玩文字游戏把Bug改成改进建议或优化项。垃圾代码不敢改重构一个烂模块可能产生一堆 Bug算了别动它。最严重的情况Bug 确实少了——因为大家不写测试了。没有测试就没有 Bug 报告。软件质量变得更差。这也是为什么成熟的工程团队通常不把 Bug 数量作为个人绩效的直接指标而是关注Bug 的解决速度而不是绝对数量问题复现率线上同样的问题是否再次发生MTTRMean Time to Recovery和MTBFMean Time Between Failures代码审查质量和测试覆盖率10、眼镜蛇效应古德哈特定律在公共管理中的版本一个常与古德哈特定律并列的故事是眼镜蛇效应Cobra Effect。虽然该故事的历史真实性在学术界存在争议多数学者认为它是一则殖民时期流传的轶事缺乏可靠的一手史料但它精准地刻画了激励设计失败的典型模式。据传在英属印度殖民时期德里眼镜蛇泛滥政府悬赏每交一条死眼镜蛇赏金若干。一开始效果很好大量眼镜蛇被消灭。但很快有人发现了商机——开始养殖眼镜蛇杀了换赏金。政府发现后取消了悬赏。养殖户把养着的眼镜蛇全部放生——现在街上的眼镜蛇比悬赏前还多。眼镜蛇效应和古德哈特定律的共通结构设定指标/激励体系按指标运转指标与实际目标脱钩指标恶化实际情况区别在于古德哈特定律更强调指标失真指标不再能反映真实状态眼镜蛇效应更强调激励适得其反激励让问题变得更糟。两者一体两面。11、如何对抗古德哈特定律虽然古德哈特定律无法被彻底战胜——只要度量还存在就会有人或系统寻找捷径——但有一些经过验证的策略可以显著减缓它的影响1多维指标体系避免单一指标单个指标是脆弱的。一组互相制衡的指标更鲁棒。场景单一指标危险多维指标体系更安全训练模型只看 mAPmAP Precision Recall FPS 参数量 线上 A/B软件开发只看 commit 数code review 质量 交付价值 线上稳定性 技术债务趋势产品运营只看 CTRCTR 停留时长 留存率 NPS 投诉率 退款率团队管理只看代码行数解决的问题 文档质量 同事互评 新手成长速度2守卫指标Guardrail Metrics除了优化指标之外必须设置守卫指标guardrail metrics——这些指标不需要提升但绝对不能下降。例如优化 mAP 时守卫 FPS 不低于 25。优化点击率时守卫投诉率不增加。优化代码产出时守卫线上事故率不上升。守卫指标的意义在于限制优化的空间迫使优化者在提升目标指标时不能以牺牲其他重要维度为代价。3让指标与真实目标保持新鲜度定期轮换或更新评估标准每季度更新一次验证集加入近期线上失败的 case。定期做盲测blind test不让评估者知道哪个是实验组。引入人类评估作为最终裁决——特别是在 AI/ML 领域当所有量化指标都可能被操纵时人类判断往往是最后的防线。4区分观察指标和考核指标一个关键的管理智慧用来观察系统健康状况的指标和用来考核人的指标应该被清楚地区分。观察指标可以有很多——它告诉团队现在的状态是什么没人有动机去操纵它。一旦某个指标被绑定到奖金、晋升、资源分配上它就从观察窗口变成了游戏目标。实用建议任何直接绑到个人绩效上的量化指标都要假设它会在 6 个月内被彻底操纵。所以在考评中量化指标应该只占一部分且配合主观判断。5奖励提出问题而非美化数字当团队发现某个指标被操纵时奖励勇于指出问题的人而不是惩罚揭盖子的人。如果团队文化是数字不好看就完蛋那么数字一定会被做得很好看——不管真实情况如何。12、一张图理解古德哈特定律mAP 被设为考核目标 阶段二指标失效疯狂优化 mAP过拟合验证集忽略长尾类别牺牲推理速度忽略真实场景mAP ↑↑↑ 但 体验 ↓↓↓结论指标与目标脱钩 阶段一指标有效真实目标 用户满意代理指标mAP此时 mAP ↑ ≈ 体验 ↑13、总结古德哈特定律的核心教训只有一句话指标应该是帮助我们观察目标的温度计而不是变成大家拼命追求的目标本身。一旦某个指标被单独拿来作为考核或优化目标无论是人还是 AI Agent都倾向于优化这个指标本身而不是优化真正想达成的结果。因此在 AI 训练、机器学习、软件工程和团队管理中行业的最佳实践是使用多维指标体系而非迷信单一数字设置守卫指标让优化有边界通过A/B 测试和线上真实反馈验证指标是否仍然有效时刻警惕任何一个 KPI 是否已经变质——昨天能反映真实质量的指标今天可能已经是表演数字。古德哈特定律不是要我们放弃度量——没有度量就无法改进。它是在提醒我们度量是工具不是目的。当你开始把工具当成目的时工具就会背叛你。14、延伸阅读Goodhart, C.A.E. (1975).“Problems of Monetary Management: The U.K. Experience.”Papers in Monetary Economics. Reserve Bank of Australia.Campbell, D.T. (1976).“Assessing the Impact of Planned Social Change.”Occasional Paper Series, No. 8.Strathern, M. (1997).“‘Improving Ratings’: Audit in the British University System.”European Review, 5(3), 305–321. ——正是她将古德哈特的原始观察凝练为 “When a measure becomes a target, it ceases to be a good measure” 这一广为流传的金句并展示了该定律在高等教育评估中的经典表现。Amodei, D. et al. (2016).“Concrete Problems in AI Safety.”arXiv:1606.06565. ——讨论了 AI 系统中的 reward hacking 和 reward misspecification。Manheim, D. Garrabrant, S. (2018).“Categorizing Variants of Goodhart’s Law.”arXiv:1803.04585. ——对古德哈特定律的形式化分类区分了 Regressional、Extremal、Causal、Adversarial 四种版本。