对齐与评测的底层:怎么让AI按你的标准干活

我第一次意识到"对齐"这个词，是在造完《造一个需求评审Copilot：PRD扔进去，风险点出来》的需求评审Copilot之后。

第三版已经能标"推断/原文"了，幻觉压下去了，跨模块风险也能扫。上线两周，我寻思该稳定了。

结果某天早上，产品经理把一份评审报告甩我桌上："你看第7条。"

第7条写着："PRD未提及，AI基于通用实践推断：该模块应支持灰度发布。"

推断标得清清楚楚，来源标得明明白白。但产品经理一句话点醒我："通用实践？哪门子的通用实践？我们整个公司就没用过灰度发布。"

我突然明白了。我一直在让AI"说真话"——别脑补、别编、标清楚来源。但我从来没让它"按我们的标准说话"。

它说的每句话都是真的，但每句话都不是我们想要的。

这就是对齐——让AI不光说真话，还说"对你有用的"真话。

对齐到底是什么

把模型想象成一个刚毕业的实习生。

能力很强，什么都能干。但他干活的"标准"是模糊的——他按自己理解的方式干，不按你的方式干。

你要他写测试用例，他写出来了，但你团队的规范是"每个用例必须有前置条件"，他一条没写。

不是他不会写，是他不知道这条规范重要。

对齐就是把这层"模糊标准"变清晰的过程。技术术语叫RLHF、RLAIF，大白话说就是"反复告诉模型什么算好、什么算差，让它学会按这个标准判断自己的输出"。

这期从第一篇开始讲的，是模型"会做什么"——生成文字、检索文档、调用工具、记住进度。

这篇要讲的是：它会的那些事，按什么标准干。

RLHF和RLAIF，用大白话讲

RLHF（人类反馈强化学习）的流程其实很朴素：

1. 模型生成一堆输出

2. 人来打分——这个好，那个差

3. 模型根据分数调整，下次更倾向生成高分的那种

听起来眼熟吗？这就是你给ChatGPT点"👍"和"👎"在干的事——你在帮它对齐。

它的本质是：用人的偏好，去校准模型的概率分布。 《为什么同样的Prompt答案不一样：温度与随机性》讲过温度控制"敢不敢猜"，对齐控制的是"往哪个方向猜"。一个模型对齐得好，它在"该保守"的地方会保守，在"该发挥"的地方会发挥。

RLAIF（AI反馈强化学习）更进一步：让人工智能替人打分。

原因很现实：让人给一万条输出打分，太贵了。所以让一个"裁判模型"来打分——这个裁判通常是一个被精心Prompt过的强模型，按你定义的规则评判。

但RLAIF有自己的坑：裁判模型的偏见，会直接灌进被训练的模型里。 裁判觉得"长答案就是好答案"，被训练的模型就会越写越长。这跟《幻觉的根源：AI为什么会一本正经地胡说八道》讲的标注偏见是一回事，只不过从"人的偏见"变成了"AI的偏见"——AI的偏见更隐蔽，因为你以为它客观。

听起来是不是跟《给你的AI工具做评测：怎么知道它到底好不好》讲的评测有点像？因为本质就是一回事。

对齐为什么会失败

对齐不是万能的。它有几种典型失败模式，每一种都跟你测试AI工具时遇到的问题同源。

失败一：标准本身有矛盾。

你想让模型"有创意"——但又让它"不编造"。

你想让它"详细"——但又让它"简洁"。

这些标准本身就是冲突的，你给模型打分时它就只能二选一，最后它学到的不是"平衡"，而是"在某种统计意义上的折中"。

测试视角：《给你的AI工具做评测：怎么知道它到底好不好》那个"步骤详细了覆盖率掉下来"的坑，本质就是对齐冲突——你没法同时优化两个互斥的指标。对齐失败不是模型笨，是你给的标准本身就打架。

失败二：标注者的偏见成了模型的标准。

RLHF里，谁打分，谁就是"标准"。如果标注者全是一类人（比如全是美国英语母语的本科生），模型会对齐到这群人的偏好上。

这就是为什么很多模型在某些文化语境里"对不齐"——标注者的盲区，就是模型的盲区。

测试视角：《幻觉的根源：AI为什么会一本正经地胡说八道》讲过概率平滑导致过度泛化。对齐偏见是它的上游版本——训练阶段就把某些路径的权重压死了。这不是Prompt能修的，是你评测时必须意识到的天花板。

失败三：对齐过度——模型变得"无趣但安全"。

太追求"不编造、不冒犯、不出错"，模型会走向另一个极端：它什么都拒绝回答，什么都加免责声明，什么都说"建议咨询专业人士"。

OpenAI内部管这叫"对齐税"（alignment tax）——你为安全付出的代价，是能力下降。

测试视角：上篇定是常态"。对齐过度相当于把概率分布压得特别窄——确实稳定了，但稳定性换来的可能是无能。这跟S5-02温度=0的坑一脉相承。

你在这套体系里的位置

这是这一篇最关键的部分。

很多测试工程师听到"RLHF""对齐"这些词，第一反应是："这是算法团队的事，跟我有什么关系？"

关系大了。

你回想一下《给你的AI工具做评测：怎么知道它到底好不好》讲的——评测集、任务特定指标、基线、属性测试。这四样东西，和对齐训练用的偏好数据、奖励模型、评估基准，本质是同一个东西。

• 你建的评测集，是模型上线后持续对齐的数据源

• 你定的任务指标，是对齐目标的具体化

• 你跑的基线对比，是在量化"对齐到什么程度"

• 你做的属性测试，是约束模型行为不变量的最低底线

算法团队负责训练阶段的对齐，你负责上线后的对齐维护。 一个是"出厂调校"，一个是"在用调校"。

而且——你比算法团队更懂业务。

算法团队对齐的是"通用偏好"——不骂人、不编造、有帮助。你面对的是"业务对齐"——这个PRD评审工具输出的风险，必须是测试团队关心的那种风险，不是产品经理关心的那种风险。

通用对齐是算法的事，业务对齐是你的事。 后者更难，因为你得先想清楚"测试团队的标准到底是什么"。

落到测试：五条

一、你做的评测，就是对齐的一部分。 别把"评测"和"对齐"当两件事。你建的评测集、定的指标、做的基线对比，本质都是在定义"什么算好"——这就是对齐。

二、对齐失败先问标准，再问模型。 模型表现不好，别急着改Prompt。先问：你给的标准本身自洽吗？指标之间是不是在打架？

三、意识对齐的天花板。 模型在某些文化、某些行业、某些细分领域"对不齐"——这不是Prompt能修的，是训练阶段带来的。评测时要把这个天花板算进去，别拿"理想模型"当基线。

四、业务对齐是你的活。 算法团队管通用对齐，你管业务对齐。S4-09那个评审Copilot，要让它输出"测试视角的风险"，这层标准算法团队不会替你想。

五、你的评测数据有双重价值。 一份评测集，当下用来验证模型；未来可能成为模型持续对齐的训练数据。你标注的每一份"好/差"，都是模型未来的"老师"。 这就是为什么评测不能糊弄——你糊弄的不是工具，是模型进化的依据。

小结

对齐的本质是让AI不光"会干活"，还"按你的标准干"。RLHF是用人的偏好校准模型，RLAIF是用AI替人打分——底层都是"定义什么是好，然后用量化方式告诉模型"。

对齐三种失败：标准矛盾（指标打架）、标注偏见（标注者的盲区成模型的天花板）、对齐过度（安全换稳定但能力下降）。每种都跟你测AI工具时遇到的问题同源。

作为测试工程师，你在对齐体系里的位置是：算法团队管训练阶段对齐，你管上线后的对齐维护。 评测集、指标、基线、属性测试——这些你已经在做的事，就是对齐的一部分。而业务对齐这层，算法团队不会替你做——你比他们更懂"测试视角的标准是什么"。