如果你做过大模型应用落地大概率被同一个问题折磨过线上模型效果说崩就崩但评测报告在哪儿呢翻遍实验记录只有几个跑过的人工标注集和一堆“模型自评分数”样本量少到根本不敢拿去跟老板汇报。更麻烦的是今天一个新模型号称“全面超越”明天另一个模型声称“推理更强”你拿什么标准去判断真伪标注数据贵、人工评测慢、模型自评又有偏好偏差整个评测环节成了大模型工程里最含糊、最容易被糊弄过去的部分。这篇标题看起来偏理论的论文正好切中了这个痛点Revealed Rationality: Label-Free Evaluation and Regularization from Representation Theorems。它把经济学里“显示性偏好”Revealed Preference的思想搬到了大模型评估上提出一种不依赖人工标签的评估与正则化思路。这篇论文的价值不在于给你一个现成的开源工具而在于它重新定义了“评估信号从哪来”——不再问“这个回答是不是正确”而是观察“模型在多个可选行为之间到底会怎么选”。读这篇文章你能理解三件事为什么无标签评估在大模型时代是刚需显示性偏好和表示定理怎么从数学上支撑“不依赖标签也能评估”以及这种思想如何落到工程里结合第三方评测工具和自定义评估 API 做出一个能跑的最小评测系统。1. 评估困局为什么无标签是被逼出来的方向先看现在 LLM 评估的真实处境。第一种做法是人工标注。找一批人来给模型的输出打分或者标注好坏对。这个方案的问题非常直接贵、慢、不稳定。一个覆盖 50 个场景的回归评测集人工标注可能要跑几天标注员之间的一致性还不一定高。而且模型一更新标注样本就过时了需要重新做。第二种做法是用大模型当裁判也就是 LLM-as-a-Judge。让 GPT-4 这类强模型给输出打分或做比较。成本低了很多速度也快但引入了新的偏差裁判模型会有位置偏好、长度偏好、自肥偏好还会因为提示词的措辞产生不稳定结果。你很难说清分数波动的来源是模型真的变好了还是裁判今天心情不对。第三种做法是继续依赖公开 benchmark。MMLU、GSM8K、HumanEval 这些基准确实有参考价值但问题是它们很快会被“刷爆”而且和你的业务场景不匹配。你做一个垂直领域的问答助手公开榜单排第一并不能证明它在你的私有数据上好用。这些问题背后有一个共同的约束我们太依赖“标签”来定义好坏。可真实环境中高质量标签极度稀缺甚至根本不存在。无标签评估想解决的问题就是在没有正确答案、没有人工偏好标注的前提下仍然找到稳定可靠的评估信号。“Revealed Rationality”这篇论文的切入点就在这里。它不讨论怎么造更多标签而是换了一个问题如果标签本质上不可靠、不可得那能不能从模型的行为选择本身推出它的“好坏”这在逻辑上是成立的。一个人不告诉你他喜欢什么但你看他反复在同类场景下都选了 A 而没选 B你就能推断 A 对他更有价值。模型也是一样观察它在大量输入上的选择行为比听它自述“我表现很好”要可靠得多。2. 显示性偏好从经济学借来的评估视角“显示性偏好”Revealed Preference是经济学里的经典概念由保罗·萨缪尔森在 1938 年提出。传统经济学讨论消费者偏好时习惯假设每个人心里有一个效用函数消费者依据效用最大化来做选择。但这个假设没法直接验证因为效用是内心的东西别人看不见。萨缪尔森做了一个关键转换别问消费者“你偏好什么”去看他在不同价格和收入约束下实际买了什么。从真实可见的选择行为中倒推他的偏好结构。比如一个人收入不变苹果从 5 块涨到 10 块他改买香蕉了。经济学家不需要知道他是不是“其实更爱苹果”只需要从行为变化中推断他在新的价格约束下显示性地偏好香蕉组合。当一组选择行为满足某些一致性条件时经济学家甚至能证明这些行为和一个效用最大化的模型相符。这就是“显示性理性”。把视角切回大模型。一个 LLM 面对用户问题时会从自己的策略分布中生成回答。如果我们在相同的输入上给模型两个候选输出让它自己选一个作为“更优输出”模型的这个选择行为就是一种“显示性偏好”。如果模型是理性的——也就是它的选择行为满足传递性、完备性等一致性条件——那么我们就能从大量选择行为中恢复出一个隐式的价值函数或评分函数用来表示模型对不同输出的偏好强度。这就是论文标题里“Revealed Rationality”的含义不是人造标签给模型打分而是模型的选择行为自己“暴露”了它的偏好结构。评估的核心不再是“标签是否正确”而是“行为是否一致”。这个概念和 LLM-as-a-Judge 最大的区别在于Judge 模式是让一个外部模型评价输出质量本质上还是“用另一个模型的意见当标签”。而显示性偏好思路关注的是行为选择自身的一致性即使没有外部标签选择集合里的内在结构也能提供足够的评估信息。3. 表示定理让“行为”映射到“评分”“Representation Theorems”表示定理听起来很数学但它的核心逻辑并不难理解。在决策理论中表示定理回答的问题是一个偏好关系满足什么条件下可以表示成一个数值函数如果决策者的偏好满足完备性任意两个选项都能比较和传递性如果 A 优于 BB 优于 C则 A 优于 C那么数学上可以证明存在一个效用函数 u(x)使得 x 偏好于 y 当且仅当 u(x) u(y)。这个定理给“直觉上的偏好”提供了一个扎实的数值化基础。把这件事迁移到模型评估上意义就显现出来了如果模型的选择行为满足一定的公理条件那么理论上存在一个潜在地价值函数能够完全解释模型的选择行为。这个价值函数就是我们可以用来评估模型的东西。换句话说无标签评估并不是无中生有而是从行为选择中“恢复”一个可量化的价值函数。这个思路在行为和决策研究里由来已久。经济学家通过消费选择恢复效用函数博弈论通过参与人的行动推断支付矩阵推荐系统通过用户点击行为推断用户偏好。这篇论文把同样的方法论应用到 LLM 评估领域并用表示定理保证这个“从行为到函数”的映射是良定义的。更直观地说表示定理在这里起的是“合法化”作用它告诉我们评估模型这件事不需要额外引入一个不可解释的裁判只需要确认模型的行为足够“理性”就能从行为本身构造出可靠的评估分数。反之如果模型的行为频繁违反一致性公理那说明它的决策机制本身有问题——这正好引出了正则化的用途。4. 无标签评估的最小落地流程从选择行为到评分论文的理论框架是美的工程落地则需要一步一步搭。下面我用一个最小示例展示如何不依赖人工标注只用模型的选择行为来给候选输出排序。整体流程分成四步准备一组提示词和候选输出。用 Judge 模型对候选输出做两两比较收集选择结果。将选择结果转换成偏好矩阵或胜负记录。用 Elo 评分或 Bradley-Terry 模型从胜负记录中恢复出每个候选的输出质量分。这里的 Judge 模型可以是任意一个通过 API 可调用的模型甚至可以是待评估的模型本身。如果同一模型自我比较得到的是“自我一致性”信号如果使用更强模型来做选择得到的是“参考价值”信号。两种信号都有意义。下面是一个完整的可运行示例。# 文件路径label_free_eval.py import requests from collections import defaultdict API_BASE https://your-api.example.com/v1 API_KEY your-api-key JUDGE_MODEL your-judge-model def call_llm(messages): resp requests.post( f{API_BASE}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: JUDGE_MODEL, messages: messages, temperature: 0, }, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] def judge_choice(prompt, candidate_a, candidate_b): user_msg f请比较下面两个回答判断哪一个对用户问题来说更好。 如果回答A更好只返回 A 如果回答B更好只返回 B 如果两者差不多只返回 TIE。 用户问题{prompt} 回答A {candidate_a} 回答B {candidate_b} out call_llm([ {role: system, content: 你是一个公正的评估助手只输出 A、B 或 TIE。}, {role: user, content: user_msg}, ]).strip().upper() if out.startswith(A): return A if out.startswith(B): return B return TIE class EloScorer: def __init__(self, init_score1000, k32): self.scores defaultdict(lambda: init_score) self.k k def expected(self, ra, rb): return 1.0 / (1 10 ** ((rb - ra) / 400)) def update(self, winner, loser): ea self.expected(self.scores[winner], self.scores[loser]) self.scores[winner] self.k * (1 - ea) self.scores[loser] self.k * (0 - (1 - ea))主流程代码如下# 文件路径run_label_free_eval.py from label_free_eval import judge_choice, EloScorer prompts [ 请解释什么是数据库索引。, 写一段 Python 代码实现快速排序。, 帮我总结这篇文章的核心观点。, ] candidates { model_a: [ 数据库索引是一种数据结构用于提高查询速度。, def quicksort(arr):\n if len(arr) 1:\n return arr\n pivot arr[len(arr) // 2]\n left [x for x in arr if x pivot]\n middle [x for x in arr if x pivot]\n right [x for x in arr if x pivot]\n return quicksort(left) middle quicksort(right), 文章主要讨论了AI技术在医疗领域的应用和挑战。, ], model_b: [ 索引就是数据库里一种让查询更快的机制。, def qsort(arr):\n return arr if len(arr) 1 else qsort([x for x in arr[1:] if x arr[0]]) [arr[0]] qsort([x for x in arr[1:] if x arr[0]]), 文章从多个角度分析了技术落地的难点。, ], } elo EloScorer() for i, prompt in enumerate(prompts): a candidates[model_a][i] b candidates[model_b][i] result judge_choice(prompt, a, b) if result A: elo.update(model_a, model_b) elif result B: elo.update(model_b, model_a) for model in elo.scores: print(f{model}: {elo.scores[model]:.0f})运行方式python run_label_free_eval.py这段代码的关键点在于整个流程里没有任何人工标注的“标准答案”只有模型对两个候选输出的选择结果。把这些选择结果喂给 Elo 评分器后模型的能力差异就被转换成了分数差异。如果你觉得 Elo 太简单可以换成 Bradley-Terry 模型假设模型 i 战胜模型 j 的概率是 sigmoid(score_i - score_j)用极大似然估计分数。原理一致只是对胜负数据的利用率更高。需要说明的是这个示例是对论文思想的一种工程化简化不是论文算法本身的复现。实际论文中的表示定理条件和恢复算法会更严格但最小流程已经能让你理解“从选择行为到评分”到底是怎么运转的。5. 把“一致性”变成正则化信号评估只是第一步论文标题里还有一个关键词Regularization。为什么行为选择不仅能用来评估还能用来训练关键在于“一致性”这个概念。如果模型是理性的那么它在选择 A 优于 B、B 优于 C 的情况下一定不会选择 C 优于 A。但在实际模型中这种偏好反转并不罕见。比如同一个模型换一种 prompt 表述对同一对输出的偏好顺序就可能改变。这种不一致意味着模型决策的底层价值函数不稳定。这种不稳定性可以直接用作训练信号。一个朴素的实现思路是对同一问题构造多个等价表述让模型分别做选择然后计算两次选择的一致性。如果模型在两个表述下产生了相反偏好就认为它违反了一致性约束在损失函数里加一个惩罚项。下面是一个概念性的 PyTorch 风格示例目的是展示“一致性惩罚”长什么样# 文件路径consistency_regularization.py # 概念示例假设 probs_a 和 probs_b 是模型在两次决策中 # 对同一组选项的概率输出 import torch import torch.nn.functional as F def consistency_loss(probs_a, probs_b): # 用对称 KL 散度衡量两次决策分布的距离 kl_ab F.kl_div( probs_a.log(), probs_b, reductionbatchmean ) kl_ba F.kl_div( probs_b.log(), probs_a, reductionbatchmean ) return (kl_ab kl_ba) / 2 # 示例两次决策分布 probs_a torch.tensor([[0.7, 0.2, 0.1]]) probs_b torch.tensor([[0.3, 0.5, 0.2]]) loss consistency_loss(probs_a, probs_b) print(loss.item())这个示例简化了许多细节但传达了一个核心思想评估得到的“行为一致性”可以直接反馈到训练目标里。模型不只是学会预测正确答案还要学会在不同表述、不同上下文下保持决策稳定。这也和当前对齐技术形成了呼应。DPODirect Preference Optimization等方法的底层假设就是“从偏好数据中直接优化策略”偏好数据本身就是一种选择行为记录。显示性理性框架提供了一个更系统的视角选择行为数据的来源可以更广泛质量判断也有更坚实的理论依据。6. 用第三方评测工具加自定义评估 API 落地理论思路清楚之后真正的工程问题是怎么把它接入现有评测体系现在市面上已经有不少第三方评估工具比如 promptfoo、DeepEval、ragas 等。它们通常具备评测用例管理、结果报告、回归对比等功能。很多人的需求是能不能调用自己写的 API按自己定义的评估标准来评估模型答案是可以。这类工具通常都提供了自定义评估器的扩展点。以 promptfoo 为例它支持在 YAML 配置里声明一个自定义 Python 评估器然后在 Python 文件里写自己的评估逻辑。这个逻辑完全可以调用你自己的 API按你自己的评分标准返回分数。一个自定义评估器的配置示例如下# 文件路径promptfooconfig.yaml prompts: - 请用中文回答{{question}} providers: - openai:gpt-4o-mini tests: - vars: question: 什么是欧几里得距离 assert: - python: my_evaluator对应的自定义评估器# 文件路径my_evaluator.py # 注意自定义函数签名以你使用的版本文档为准 import requests def get_result(prompt, vars, output, contextNone): # output 是待评估模型生成的结果 # 这里调用你自己的评估 API按你的标准打分 score call_my_eval_api(prompt, output) return { pass: score 0.8, score: score, reason: f自定义评估结果{score}, } def call_my_eval_api(prompt, output): resp requests.post( https://your-eval-api.example.com/score, json{prompt: prompt, output: output}, timeout30, ) resp.raise_for_status() return resp.json()[score]配置示例里把openai:gpt-4o-mini换成你自己账号里真实可用的模型 ID。如果你的模型走的是自建网关或私有化部署通常也可以把 provider 指到自定义 API endpoint。这种自定义评估器和显示性理性框架结合会形成一个很实用的工作流用第三方工具管理评测用例和回归对比。在自定义评估器里实现自己的评分逻辑不依赖工具内置的裁判模型。内部评分逻辑可以是用规则、用模型、用显示性偏好恢复出来的价值函数也可以用你自己的垂直领域指标。这样做的好处是工具负责调度和报告业务方负责定义“好”的标准。评估逻辑和评价标准解耦后续想换评估策略只改自定义评估器即可。7. 常见问题与排查方法无标签评估和自定义评估器虽然能跑通但实际使用中会遇到不少问题。以下是我认为最值得关注的几个。问题现象可能原因排查方式解决方案Judge 结果不稳定同一对输出反复反转温度参数过高或提示词表述含糊固定 temperature0检查提示词是否明确要求只输出 A/B/TIE增加输出格式约束多次采样取多数结论评估分数和人工判断明显不一致评估信号定义和业务目标不对齐抽样对比评估分数与人工标注结果调整评分标准增加业务侧指标权重模型在不同 prompt 表述下偏好反转模型对表述敏感价值函数不稳定检查是否同一问题只用了一种表述用多种等价表述测试计算一致性偏差自定义评估 API 超时评估逻辑复杂或推理模型响应慢查看 API 日志和耗时统计增加超时时间或拆分评估请求做异步处理小样本下 Elo 分数变化剧烈比较次数太少评分置信度不足检查每对候选的比较次数增加样本量至少保证每对候选比较 10 次以上第三方工具报告通过但实际业务仍差评测集覆盖度不够或评估标准过松检查评测集是否覆盖线上真实用户请求用线上日志构造评测集收紧 pass 阈值第 4 个问题要特别说明当评估结果和人工判断不一致时先不要急着换模型先检查评测信号本身。很多团队在这个环节浪费了大量时间最后发现是评估器的评分逻辑有 bug或者评测集里的 prompt 和线上真实输入分布差异过大。8. 最佳实践与工程建议从论文思想到生产环境落地中间还有一段工程化的路。下面几条建议是我认为适配大多数团队的。第一无标签评估不要一上来就追求完全替代人工。更务实的做法是保留一小部分人工标注集作为锚点用它校验无标签评估系统给出的分数是否与人工判断一致。当两者相关性稳定后再逐步扩大无标签评估的使用范围。第二评估信号要多源融合。显示性偏好提供了一种新信号不代表要抛弃规则指标和其他评估维度。准确率、延迟、拒绝率、成本、与业务指标的相关系数都应该一起看。单一评估维度在复杂业务场景下几乎必然失真。第三评测集要动态更新。用线上日志构造评测集是一个成本低、收益高的做法。定期从真实用户请求中采样经过脱敏后加入评测集能让评测结果持续贴近线上表现。静态评测集很容易让团队陷入“刷分数”的陷阱。第四记录每一次评估的完整上下文。包括输入、输出、Judge 模型、提示词版本、温度、seed、所用评估器版本、原始 API 响应。没有这些信息分数一波动就无从排查。评测系统的可追溯性比评测系统本身更重要。第五涉及自定义评估 API 时注意权限和数据安全。如果你用第三方评测工具去调用企业内部 API务必控制好 API key 的访问范围只授予评测任务必要的最小权限。涉及生产数据时脱敏处理是底线。涉及安全、权限、认证、生产环境操作时先在测试环境验证确认可行后再上生产并保留回滚方案。9. 总结与下一步学习方向回到很多团队真正关心的问题现在有没有好的第三方评估工具能调用自己的 API、按自己的评估标准来评估模型答案是工具已经很多promptfoo、DeepEval、ragas 都是不错的起点。它们解决的是评测基础设施的问题也就是评测用例怎么管理、报告怎么出、回归怎么对比。真正的难点从来不在工具而在于你如何定义“模型表现好”。显示性理性和表示定理这类研究给了一个更本质的启发与其依赖昂贵、易错、不断过时的标签不如认真观察模型在大量行为选择中的一致性。下一步建议你不必急着复现论文里的定理先做一件最小的事挑 10 个跟你业务最相关的 prompt准备两个模型的输出用第 4 节里的 pairwise 选择流程跑一遍看看哪些样本上模型的选择是稳定的哪些样本上偏好频繁反转。你会发现即使不看任何正确答案模型的行为数据也能透露很多问题。如果这个流程能帮你发现真实问题再回头深入阅读这篇论文研究表示定理如何保证恢复出的价值函数是可靠的然后思考能否把一致性损失接入训练流程。从行为到分数从分数到训练信号这条链路一旦打通评测就不再是项目末期才想起来的“补作业”而是一个持续驱动模型改进的引擎。