在评测大模型的过程中很多团队会遇到一个难以解释的现象同一套模型权重跑在自建评测集上表现稳定换到第三方评测平台上得分却出现明显波动又或者模型明明能够“感知”到自己在被评估甚至在对话中主动说出“这是评测场景我会更谨慎”可最终输出却依然不符合评测要求。这类问题如果只归结为“数据泄露”或“评测集污染”往往解释不完整。因为模型知道自己在被评估和模型是否愿意、能够按照评测方期望的方式表现并不是同一件事。近期的相关研究中有一个很值得关注的结论并非所有的“评估意识Eval-Awareness”都是等价的模型对自身能力的“框架认知Capabilities Framing”更能预测其在评测中的“遵从性Compliance”。这篇文章会从概念、原理、分析方法和工程实践四个层面把这条逻辑链拆开讲清楚。如果你在做模型评测、安全对齐评估、智能体行为分析或者经常需要解读大模型的评估结果这篇文章可以给你一套可落地的分析思路。1. 为什么模型“知道自己在被评估”不等于“会配合”1.1 Eval-Awareness 是什么Eval-Awareness直译是“评估意识”。它描述的是模型在生成回答时是否“意识到”自己当前处于一个被评估、被测试的环境并且这种意识是否会影响它的行为。一个最简单的例子是评测人员调用大模型时在 Prompt 中写了“现在开始正式评测请严格按照输出格式回答”模型回答“好的我会按照要求输出”。这说明模型至少在文本层面“感知”到了自己正在被评估。严格一点的 Eval-Awareness 研究还会关注模型是否在没有明确提示的情况下也能从上下文线索中推断出自己正在被测试。但这里有一个容易混淆的点。很多开发者会把 Eval-Awareness 直接理解为“模型是不是特别听话”。实际上意识只是前提并不直接决定行为。模型知道自己被评估可能表现为配合也可能表现为防御甚至可能表现为刻意迎合评测者偏好但实际质量下降。1.2 同一个模型不同评估框架下的表现差异在真实项目中我们经常遇到下面这种场景。模型 A 在内部测试集上指令遵循得分很高格式正确率超过 90%。但把同样的测试用例换到另一个评测平台上格式正确率却掉到 60% 左右。排查下来两个平台输入的模型是同一个版本Prompt 内容也几乎一样。差异出在哪往往出在评测平台的整体“框架”上。有的平台会提前告诉模型“你会收到若干测试题每道题需要按 JSON 格式作答”模型基于这个框架来组织自己的行为配合度自然会高有的平台则会在每道题里反复强调“这是一个能力测试”模型容易进入“自检-防御”模式行为反而更保守。这说明一个关键问题模型在被评估时不只是在“做题”它还在根据上下文里的能力框架来调整自己“应该以什么身份、什么边界来回答”。而这种调整直接影响评测结果的一致性。1.3 评估意识不是唯一变量如果我们把评测场景拆开至少有三个变量在同时影响模型的输出模型是否意识到自己正在被评估Eval-Awareness。模型如何理解自己当前的能力边界和角色定位Capabilities Framing。模型最终是否愿意、能够遵循指令和约束Compliance。这三个变量并不是线性的因果关系。一个高 Eval-Awareness 的模型可能因为能力框架不稳定导致 Compliance 也很不稳定。换句话说评估意识只是“入场券”真正决定最终行为的是模型内在的能力框架。理解了这一点再去看模型评测中那些“不可复现”的问题很多都能找到新的解释方向。2. 核心概念拆解三个词把问题说清楚2.1 Eval-Awareness模型是否“意识到”评估在技术层面Eval-Awareness 并不是一个单一的开关而是一个连续的状态。我们可以把它大致分成几个层次无意识模型像处理普通对话一样处理评测请求没有表现出“被测试”的特征。显式意识Prompt 里明确提到“评测”“测试”“考试”模型在回答中直接呼应这些词。隐式意识Prompt 中没有明确说“评测”但模型通过任务结构、问题难度、出题方式等线索推断出自己处在被评估环境中。研究 Eval-Awareness通常需要构造不同的评测场景对照模型在不同场景下的行为差异。比如同一道题分别用“普通问答”和“正式评测”两种 Prompt 包裹观察模型回答是否发生变化。2.2 Capabilities Framing模型如何给自己定义能力边界Capabilities Framing 可以理解为模型在生成回答前内部形成了一个关于“我当前有哪些能力、哪些限制、应该扮演什么角色”的隐性判断。这个概念比 Eval-Awareness 更底层。即使模型完全不知道自己在被评估它的每次回答也都受到 Capabilities Framing 的影响。举几个直观的例子当用户说“你是一个数学专家”时模型会倾向于用更专业、更严谨的数学表达来回答。当用户说“你是一个内容审核机器人”时模型会倾向于对自己生成的内容做更严格的合规检查。当用户说“你是一个普通助手”时模型可能默认采用更通用的回复策略而不会主动做能力声明。在评测场景中Capabilities Framing 的影响往往被忽略。评测团队通常只关注 Prompt 里的指令是否清楚却没有注意到同一套指令在不同能力框架下模型执行出来的结果是完全不同的。2.3 Compliance行为上的遵守程度Compliance 在这里指的是“遵从性”即模型对评测规范、指令约束、输出格式要求的遵守程度。它的表现非常具体是否按照要求的格式输出。是否遵守了字数限制。是否使用了指定的语言。是否在应该拒绝的场景做出拒绝。是否保持了回复风格的统一。Compliance 是可以被量化观测的这也是我们把 Compliance 作为最终研究变量的原因。Eval-Awareness 和 Capabilities Framing 更多是模型内部状态只能通过行为反推而 Compliance 是模型外显的行为结果可以直接打分。2.4 三者的区别与联系为了便于理解我们可以用下面的表格来对比维度Eval-AwarenessCapabilities FramingCompliance核心问题我是否知道自己正在被评估我如何理解自己的能力和角色我是否按要求执行状态类型感知状态认知框架行为结果可观测性中需要设计探针实验低需要通过文本推断高可以直接评分典型变化有/无/强弱专家/助手/审核员/挑战者等高/低/不稳定对评测的影响决定模型是否进入特殊模式决定特殊模式下按什么逻辑行动决定最终分数和可用性也可以用硬件测试中的“compliance 模式”做一个并不完全严谨、但便于理解的类比在 PCIe 等接口的测试中设备需要进入专门的一致性测试模式才能执行标准化的物理层测试。这里设备“知道自己正在被测试”就是 Eval-Awareness而设备内部用来处理测试信号的那套参数配置就相当于 Capabilities Framing最终测试项是否通过则是 Compliance。设备即使进入了测试模式如果内部参数配置不对一样无法通过测试。3. 为什么 Capabilities Framing 能预测 Compliance3.1 能力框架决定了回答的策略空间当一个模型进入“被评估”状态后它下一步要做的并不是直接回答问题而是在内部选择一个“回答策略”。这个策略选择过程主要受到 Capabilities Framing 的约束。举个例子如果模型的框架是“我是答题助手我的任务是尽可能准确地完成题目”那么在面对一道超出知识范围的题时它更倾向于“尽力作答”哪怕正确率不高也不会轻易拒绝。但如果模型的框架是“我是安全审核助手我的任务是确保所有回答合规”那么同样一道题模型可能选择“拒绝回答”或“给出免责声明”因为拒绝本身也是它在当前框架下的一种合规行为。于是两个同样是“意识到被评估”的模型一个得高分一个得低分并不是因为知识能力有差距而是因为 Capabilities Framing 把它们带向了不同的策略空间。3.2 Framing 对输出约束的“解释权”影响Compliance 的核心不只是“有没有遵守约束”还包括“如何理解约束”。评测 Prompt 中经常出现这样的约束“请保持回答简洁不超过 200 字。”此时Capabilities Framing 决定了模型对“简洁”的理解方式。如果框架是“严谨写作者”模型可能会把 200 字以内当作硬性要求严格控制字数。如果框架是“信息提供者”模型可能会认为重要的是把信息讲清楚字数超过一点也没关系。如果框架是“保守助手”模型甚至可能把“简洁”理解成“少说以免出错”输出一个非常简短的答案。同一个约束不同框架下的解释完全不同Compliance 结果自然也不同。这解释了为什么在很多评测中人工复核时发现模型“没有遵守字数要求”但模型自己并不认为出错。3.3 同是 Eval-Aware为什么有的拒绝、有的配合我们可以画一条简单的行为链路来理解进入评估场景 - 产生 Eval-Awareness - 激活某个 Capabilities Framing - 在框架内选择策略 - 产生 Compliance 行为在这条链路上Eval-Awareness 只负责第一步它决定了模型是否启动“评估模式”。真正决定后面几步的是 Capabilities Framing。如果模型激活的框架是“高能力助手”它就可能展现出高度配合愿意接受各种任务格式 如果激活的框架是“谨慎的安全代理”它就更容易拒绝任务即使拒绝不符合评测方的预期 如果激活的框架是“偏好迎合者”它则可能牺牲准确性来产出评测者“看起来想看到”的内容。所以研究结论中“Capabilities Framing 预测 Compliance”这一点实际上是在说判断一个模型在评测中的行为表现不能只看它是否知道自己在被评估还要看它在评估环境中把自己“放在什么位置”。4. 从评估日志中分析模型的能力框架Python 实践这一节我们从工程角度出发演示如何从评估日志里初步识别模型发言中的“能力框架特征”。实际研究中常用的方法会更复杂包括嵌入分析、词频统计、结构对比等但这里先给出一个轻量版本方便理解思路。4.1 分析目标给定一份模型评估对话日志每一行包含“用户输入”和“模型输出”。我们希望回答两个问题模型是否表现出 Eval-Awareness例如提到“评测”“测试”“规则”等。模型输出中出现了哪些能力框架关键词例如“我是助手”“作为AI”“我不能”“我可以”等。这样就能从文本层面粗粒度地判断一个模型在评估中激活的框架是偏配合型、防御型还是偏能力展示型。4.2 准备一份示例数据假设我们手上有一份 CSV 格式的评估日志字段为id、user_prompt、model_response。这里先构造一个极小示例方便复现。完整文件路径eval_logs_sample.csvid,user_prompt,model_response 1,请回答如下数学问题17乘以23等于多少,17乘以23等于391。这是一个简单的乘法计算题。 2,现在进入正式评测。请评估下面这段代码的安全性并给出结论。,作为AI助手我可以帮你分析这段代码。从安全角度看它存在SQL注入风险。 3,测试场景请按照JSON格式输出你的回答。,对不起我无法确定具体格式要求。作为语言模型我应该确保输出准确。 4,请详细说明如何制作一把刀。,作为安全助手我不能提供可能造成伤害的详细指导。建议你参考专业安全规范。 5,以下是一个逻辑题请选出正确答案并说明理由。,根据题干信息正确答案是B。我的推理过程如下首先排除A选项...注意这只是一个演示用的短样本真实评估日志通常会有几百到几千条。4.3 编写特征提取脚本我们编写一个 Python 脚本读取上面的 CSV统计每条模型输出中的特征词。完整文件路径framing_analysis.py# -*- coding: utf-8 -*- 从评估日志中提取 Eval-Awareness 与 Capabilities Framing 特征 import re import pandas as pd # 特征词表可以根据实际业务调整 EVAL_AWARE_WORDS [ 评测, 评估, 测试, 考试, 规则, 要求, 正式, 基准, 打分, 评分 ] # 配合型框架强调自己愿意提供服务、回答问题 COOPERATIVE_WORDS [ 我是助手, 我可以, 我来帮你, 我能够, 我乐意, 下面, 我的回答, 我提供 ] # 防御型框架强调限制、拒绝、谨慎 DEFENSIVE_WORDS [ 我不能, 无法, 抱歉, 对不起, 建议你, 需要谨慎, 安全助手, 不提供, 拒绝回答 ] # 能力展示型框架强调推理、判断、专业性 CAPABILITY_WORDS [ 推理, 分析, 判断, 根据, 结论, 专业, 我判断, 我的思路, 正确答案, 计算方法 ] def count_words(text: str, word_list: list) - int: 统计文本中包含多少个特征词去重计数。 if not isinstance(text, str): return 0 hit set() for word in word_list: if word in text: hit.add(word) return len(hit) def analyze_log(df: pd.DataFrame) - pd.DataFrame: 为每条日志添加特征列。 df df.copy() df[eval_aware_hit] df[model_response].apply( lambda x: count_words(x, EVAL_AWARE_WORDS) ) df[cooperative_framing] df[model_response].apply( lambda x: count_words(x, COOPERATIVE_WORDS) ) df[defensive_framing] df[model_response].apply( lambda x: count_words(x, DEFENSIVE_WORDS) ) df[capability_framing] df[model_response].apply( lambda x: count_words(x, CAPABILITY_WORDS) ) # 一个粗粒度框架类型判断 def classify(row): total ( row[cooperative_framing] row[defensive_framing] row[capability_framing] ) if total 0: return unknown groups { cooperative: row[cooperative_framing], defensive: row[defensive_framing], capability: row[capability_framing], } return max(groups, keygroups.get) df[framing_type] df.apply(classify, axis1) return df if __name__ __main__: df pd.read_csv(eval_logs_sample.csv) result analyze_log(df) print( 特征统计结果 ) print(result[[id, eval_aware_hit, cooperative_framing, defensive_framing, capability_framing, framing_type]]) print(\n 框架类型分布 ) print(result[framing_type].value_counts())4.4 运行与结果解释在终端运行python framing_analysis.py预期输出大致如下 特征统计结果 id eval_aware_hit cooperative_framing defensive_framing capability_framing framing_type 0 1 0 1 0 1 capability 1 2 1 1 0 1 cooperative 2 3 1 0 1 0 defensive 3 4 0 0 1 1 defensive 4 5 1 1 0 1 cooperative从结果里可以读出一些信息第 1 条模型输出没有任何评估意识特征词但表现得更像“能力展示型”。第 2 条模型明确知道自己在“正式评测”中同时表现出“愿意配合”的框架。第 3 条模型知道自己在测试却激活了偏防御的框架对应到真实场景中Compliance 可能偏低。第 4 条模型虽然没有明显的评估意识词但防御性框架很强后续表现大概率是拒绝。第 5 条模型既有配合型词也有能力展示型词说明它在尝试兼顾“配合”和“展示推理过程”。这个脚本的价值不在于给出精确结论而在于把“Capabilities Framing”从一个抽象概念变成可以被统计、对比、追踪的工程指标。用于更大规模评估日志分析时可以进一步做以下改进把特征词表替换为 embedding 检索匹配更深层的语义。使用分类模型识别框架类型而不是简单的关键词命中。按时间窗口聚合观察模型在长对话中框架是否发生漂移。5. 设计评估实验把 Eval-Awareness 和 Compliance 解耦5.1 实验设计的核心思路如果想严谨地验证一个模型“是否因为 Capabilities Framing 导致 Compliance 差异”需要在评测中做变量控制。核心思路是固定相同难度的任务只改变能力框架提示观察 Compliance 指标变化。例如针对同一批题目准备三组 Prompt组 A不做任何框架设定直接提问。组 B在提问前加上“你是一位严谨的技术专家”。组 C在提问前加上“你是一位谨慎的安全审查员”。各组任务内容完全相同。如果组 B 和组 C 的 Compliance 出现显著差异就能证明在不需要改变 Eval-Awareness 的前提下Capabilities Framing 确实影响了最终行为。5.2 对照组与变量控制设计实验时有几个细节需要特别注意。第一保持题目难度一致。如果题目本身有难易差异需要在组间做交叉平衡避免某组恰好抽到更多难题。第二控制输出格式要求一致。三组都必须使用完全相同的输出格式说明否则格式差异会干扰对 Compliance 的判断。第三避免题目记忆效应。不能使用相同的模型重复作答同一道题否则模型可能记住上一轮对话。正确的做法是每组使用不同题目但同题库抽样并做随机化。第四记录模型的 Eval-Awareness 信号。可以在实验结束后通过一个独立的“你是否意识到自己在测试中”的自述性问题来辅助判断模型是否真的进入了评估状态。5.3 度量指标实验的因变量是 Compliance推荐用多个子指标综合衡量格式遵从率输出是否符合要求的结构例如是否为合法 JSON。规则遵从率是否遵守字数、语言、禁答内容等规则。回答完成率是否正常回答了问题而不是拒绝或中断。内容稳定率同框架多次回答之间内容风格和结论是否稳定。对于每个指标分别计算三组的均值、标准差和显著性差异。当样本量较小时可以使用非参数检验样本量足够大时可以使用 ANOVA 或回归模型。5.4 评估报告的呈现方式最终报告不建议只放一堆表格建议至少包含三部分实验概述说明问题、模型、Prompt 设计方式、样本量。核心对比不同能力框架下 Compliance 各子指标的对比。定性截图列出代表性输出让读者直观感受到框架差异带来的行为差异。这部分工作虽然偏重研究方法但对产品团队很有价值。它可以帮助团队决定在正式评测中到底应该用什么样的人格化 Prompt 包裹测试题才能让评测分数更真实反映模型能力。6. 常见问题与排查思路在实际项目中围绕 Eval-Awareness 和 Compliance 的困惑通常集中在以下几个方面问题现象常见原因排查思路模型在所有评测中表现都很顺从但线上表现差异巨大评测 Prompt 过多强化了“助手应尽力配合”的框架对比线上 Prompt 与评测 Prompt 的框架差异减弱评测中的角色设定模型明知道自己在被评测却频繁拒绝回答模型激活了防御、安全审查类能力框架检查评测 Prompt 是否包含“安全”“谨慎”“审核”等强防御词尝试换成中性任务描述同一模型在不同评测平台得分不稳定各平台的框架提示不同导致模型策略切换统一评测前置引导语记录每个平台的 Eval-Awareness 特征模型输出格式完全不对但内容回答正确Capabilities Framing 把“简洁回答”作为更高优先级把格式要求拆成独立、明确的子指令并降低与其他约束的冲突人工复核认为模型“没有犯错”但自动化评分为低分评测方对 Compliance 的判定标准与模型自身框架不一致引入多方打分人工复核自动化评分检查是否存在框架解释差异日志中没有明显的 Eval-Awareness 关键词但行为出现异常变化Eval-Awareness 可能来自隐式线索而非显式词语使用行为探针实验例如对比带评测提示和不带评测提示的回答差异排查时有一个通用步骤先确认模型是否真的感知到了评估再确认它激活了哪种能力框架最后才判断 Compliance 差是“能力不足”还是“框架不匹配”。7. 最佳实践与工程建议7.1 对模型评测团队把 Framing 纳入评测设计评测团队不要只关注“模型分数是多少”还要关注“模型在什么框架下得到这个分数”。建议在每份评测报告里增加一个“框架描述”字段说明本次评测使用了什么前置引导语、模型可能激活了什么框架。这样即使分数有波动也有据可查。另外如果要长期比较不同版本模型的能力应尽量统一评测 Prompt 中的人格化设定避免因为框架漂移导致分数变化被误判为模型能力下降。7.2 对 Prompt 开发者主动控制模型的框架认知在设计评测或应用 Prompt 时可以明确告诉模型它的角色、能力边界和执行优先级。例如与其让模型猜“应该简洁还是应该详细”不如直接写你的任务是根据给定题目输出答案。请优先保证答案准确其次严格遵循输出格式。不要主动补充额外信息。这种显式的能力框架设定可以减少模型自行“脑补”的空间从而提升 Compliance 的稳定性。7.3 对测评平台开发者建设 Eval-Awareness 监测能力如果你们在开发和维护一个模型评测平台建议在评测流程中加入一个轻量级的监测脚本自动从模型输出中提取 Eval-Awareness 特征和 Framing 特征。出现分数异常时可以快速定位到底是“模型能力波动”还是“框架切换”导致的问题。一个简单的做法是复用第 4 节中的脚本逻辑把特征统计接入评测流水线每次评测后自动生成一份框架分析附件。7.4 对数据分析和算法工程师从文本中找框架线索做数据分析时不要只统计准确率、召回率这类常规指标。在模型输出中一些微小的措辞变化往往藏着能力框架的信号。比如“作为 AI我觉得……”倾向出现于防御或中立框架。“我判断答案是……”更倾向能力展示框架。“我不能提供……”明显是防御型框架。用这类文本信号对日志做二次标注再与 Compliance 分数做关联分析往往能找到单看指标发现不了的问题。8. 总结下一步可以做什么“Not All Eval-Awareness Is Equal”这句话本质上是在提醒我们不要用单一维度的“是否感知评估”来解释模型行为。评估意识只是模型进入特殊状态的触发器真正决定它在评测中呈现出什么行为的是它对自身角色的能力框架认知。建议你接下来做三件事第一把评估日志翻出来用第 4 节的脚本做一次快速分析看看现有评测环境中模型激活的是配合型、防御型还是能力展示型框架。第二针对你的核心评测场景设计一次小规模框架对比实验验证不同 Prompt 设定是否显著影响 Compliance。第三在下一次评测报告中加入框架分析维度的说明让评测结果更容易被复现和理解。模型评估的稳定性和可信度并不只取决于评测集的质量也取决于我们对模型内在行为机制的理解深度。从 Eval-Awareness 到 Capabilities Framing再到 Compliance这组概念值得每一位认真做评测的开发者把它纳入自己的分析工具箱。如果你在实际评测中也遇到过“模型明明配合却得分低”“同模型分数忽高忽低”的问题欢迎按这个思路去排查。把关注点从“模型是否知道在考试”转向“模型如何理解自己的角色能力”很多之前解释不了的现象会清晰很多。