这次我们讨论的不是某个模型在排行榜上得了多少分而是一套评估 AI 模型认知能力的通用方法论。标题是《Six principles for evaluating cognitive capabilities in AI models》简单说就是当你想判断一个模型是“看起来聪明”还是“真的可靠”时到底应该看什么、测什么、信什么。很多团队在模型选型时习惯直接看 Benchmark 分数但实际落地时经常发现分数高的模型在特定业务场景里反而答非所问或者同一句话换一种说法结果就完全变了。这说明单点准确率很难反映模型真实的认知能力。真正可用的评估至少要覆盖六个维度可溯源、任务对齐、语义鲁棒性、因果一致性、不确定性校准、上下文记忆边界。这篇文章会把这六个原则展开每个原则给出定义、测试设计思路、观察指标和工程建议。文章最后会附一套可落地的评估执行流程包括评估集构建、批次运行、评分表和报告模板。无论你是做模型选型、Prompt 调优、RAG 系统搭建还是给业务方写评估报告这套方法都可以直接拿过去用。1. 核心能力速览评估对象大语言模型、多模态模型、Agent 系统评估类型认知能力评估、模型选型、Prompt 效果验收、系统回归测试六个原则可溯源与可验证、任务对齐与意图覆盖、语义鲁棒性、因果一致性与逻辑连贯性、不确定性校准、上下文感知与记忆边界适用人群算法工程师、AI 产品经理、测试开发、技术决策者产出物评估维度表、测试用例集、评分卡、回归报告运行环境任何能调用模型 API 或本地推理的环境无需专用 GPU是否支持批量任务支持可设计批量测试脚本是否支持接口 API不依赖特定 API但可封装为评估服务需要提前说明本文不承诺“跑一遍就能给模型打分”因为不同业务场景对“认知能力”的定义不同。但六个原则是通用的你只需要按业务调整测试用例即可。2. 为什么单看准确率不够先看一个典型场景。给模型一个知识库问答任务测试集准确率 92%看起来很不错。但上线之后用户问“我的订单为什么被取消”模型先回答“订单取消可能有多种原因”然后列了一堆不相关的退款政策。准确率指标是上去了用户需求却没有被满足。问题出在哪里第一个问题基于准确率的评估通常只关注“答案对不对”不关注“答案有没有依据”。模型可以凭训练数据里的统计规律给出一个看似正确但无法验证的说法。第二个问题准确率评估用的是固定提示词模板真实用户不会按模板提问。一个用户会说“帮我看看这个订单”另一个用户会说“我东西怎么没发货”还有用户会说“你们是不是把我的订单吞了”。三句话表达同一诉求但模型在三句话上的表现可能完全不同。这就是语义鲁棒性维度。第三个问题准确率平均分掩盖了最差情况。一个模型在 100 道题里错 8 道如果这 8 道全集中在“用户投诉处理”场景那么客服场景上线就是灾难。平均分不能告诉你风险集中在哪。所以我们需要一套多维度的评估原则而不是一个单一分数。六个原则不是互相独立的它们分别从“来源可信度、需求理解、输入扰动、推理链条、自我认知、上下文利用”六个角度切入组合起来才是一个完整的评估框架。3. 六个评估原则总览原则关注的核心问题典型测试方式失败信号原则一可溯源与可验证性模型回答是否有依据能否被验证知识型问答、引用来源检查回答看起来合理但无法找到出处原则二任务对齐与意图覆盖模型是否理解用户真实需求回答是否面面俱到多意图复合问题、追问测试只回答部分内容遗漏关键诉求原则三语义鲁棒性同义改写、噪声扰动下结论是否稳定改写问题、插入无关信息、同义词替换改写后答案出现事实反转原则四因果一致性与逻辑连贯性多步推理是否自洽反事实条件下是否合理多步骤逻辑题、反事实提问结论互相矛盾或跳步原则五不确定性校准模型是否知道自己不知道置信度是否可信低信息量问题、开放式问题、自报置信度对捏造事实给出高置信度原则六上下文感知与记忆边界长上下文中能否正确利用信息能否检测信息矛盾长文档阅读理解、位置敏感问题、信息冲突检测忽略上下文、重复前面内容、受到无关信息干扰这个表格可以先作为团队内部讨论的起点。接下来逐个展开。4. 原则一可溯源与可验证性4.1 原则定义可溯源与可验证性指的是模型给出的每一个关键事实、数据、结论是否可以被追溯到某个可靠的输入来源。如果一个模型告诉你“2025 年全球 AI 市场规模是 2500 亿美元”你需要能定位出这句话来自哪份文档、哪个网页、哪段训练数据或者至少能通过外部工具验证。如果没有来源这个回答就只能算作“模型内部信念”不能直接用于业务决策。这个原则在 RAG 场景里尤其重要。RAG 系统的价值就是把模型回答约束在检索到的文档范围内。但实际跑起来经常发现模型还是会“自由发挥”用训练记忆里的知识去补检索结果里没有的信息。4.2 测试设计设计一组“信息缺口”测试题。构造方式如下给模型输入一段文档文档中包含明确的数值、日期、人名、政策条款。提问时故意问文档中没有提到的细节。看模型是否承认“没有找到相关信息”还是自己编造一个答案。举例系统提示根据以下政策文档回答用户问题。如果文档中没有相关信息请明确说明“文档中未找到相关信息”不要推测。 文档内容 《平台商品售后政策》2025 年修订版 第 3 条生鲜商品支持 48 小时内无理由退货前提是商品未拆封。 第 5 条非生鲜商品支持 7 天内质量问题退换货需提供开箱视频。 用户问题如果生鲜商品已经拆封可以退货吗预期行为是模型回答“文档中未找到关于已拆封生鲜商品退货的具体条款建议联系人工客服确认”。如果模型回答“已经拆封的生鲜商品不支持退货”虽然听上去合理但这属于推测不是从文档里得出的结论。4.3 观察指标可以统计以下指标引用准确率模型引用的内容是否真实存在于输入文档中。无中生有率模型回答中包含输入中不存在细节的比例。拒答合理性模型说“不知道”时是否准确说明了是“文档没有”还是“自己不会”。建议在评估集中加入 30% 左右的“故意刁难”用例把文档里没有的信息包装成看似合理的答案选项。4.4 工程实践在 RAG 系统里可以通过后处理方式增强可追溯性。比如把检索到的文档片段按来源分组在 Prompt 中显示“以下内容来自第 3 份文档”并要求模型在回答时标注引用编号。如果模型无法在回答中标注引用来源宁可让回答更保守也不放行无引用内容。5. 原则二任务对齐与意图覆盖5.1 原则定义任务对齐评估的是模型有没有真正理解用户的问题“要我干什么”而不是机械地产出看起来相关的文本。意图覆盖则进一步要求模型回答完整覆盖用户的全部诉求。真实用户的提问很少像教科书一样单一一个问句里往往包含多个隐含需求。比如“帮我看看这个错误日志顺便解释一下导致这个问题的原因如果知道解决方案也可以写一下”这句话包含三个任务分析日志、解释原因、给解决方案。模型如果只分析日志就算“跑偏了”。5.2 测试设计设计复合意图测试题把多个子任务嵌入同一个问题。示例用户问题我们线上服务最近频繁出现 502 错误帮我看看这段 Nginx 日志里最多的是哪种报错同时给一个临时缓解方案再判断是否和昨天我们改的 upstream 配置有关。 日志片段 2025-06-10 10:12:33 [error] upstream timed out while reading response header from upstream 2025-06-10 10:15:27 [error] connect() failed (111: Connection refused) while connecting to upstream 2025-06-10 10:18:12 [error] no live upstreams while connecting to upstream 2025-06-10 10:20:44 [error] upstream timed out while reading response header from upstream一个合格的回答应该包含三部分第一指出最多的是 upstream timeout第二给出重启后端服务、调大超时时间等临时方案第三结合日志特征分析是否与 upstream 配置变更相关。只输出“502 是服务端错误”不能算通过。评测标准建议使用“要点覆盖率”提前和业务方拆解出问题的 N 个必要覆盖点。模型回答中覆盖的点数除以总必要点数。覆盖率低于 80% 则判定为任务对齐失败。5.3 观察指标要点覆盖率。多意图识别率模型在回答里是否有意识地分段回应用户的不同诉求。换位思考率模型是否主动站在用户角度追问缺失信息而不是直接给出一个模糊答案。5.4 工程实践在业务系统里可以把“任务对齐”变成可用 Prompt 模板约束的行为。例如在系统提示里写明“你的回答必须包含原因分析、解决方案、预防建议三个小节”。然后在评估脚本里用结构化解析检查回答是否包含这三个 section低于阈值触发告警。6. 原则三语义鲁棒性6.1 原则定义语义鲁棒性指的是在语义不变的情况下对输入做同义改写、轻微噪声注入、无关信息插入等扰动之后模型输出在关键事实上保持一致。很多模型对特定表达方式敏感。你今天用“帮我总结这篇文章”测试是好的换一个人说“这篇文章你帮我看看说的是啥”可能结果就完全变了。对于生产系统来说这种不稳定性比“分数低”更可怕因为你无法预测用户会怎么表达。6.2 测试设计对同一问题设计至少 5 种等义改写然后观察模型回答的关键信息点是否一致。示例原问题小米粥适合糖尿病人吃吗 改写 1糖尿病患者的饮食里能不能包括小米粥 改写 2血糖高的人喝小米粥合适吗 改写 3小米粥会不会让糖尿病的血糖升得太快 改写 4我是二型糖尿病早餐吃小米粥可以吗 否定改写是不是所有糖尿病患者都应该避免吃小米粥判断标准关键事实不能出现反转。比如原问题答案是“适量可以但需要监测血糖”改写后不能变成“绝对不能吃”。否定改写必须给出区分性回答。比如“不是所有患者都必须避免具体要看血糖反应”而不能复制一个“可以吃”的结果。如果模型对不同改写给出互相矛盾的结论这条算鲁棒性失败。6.3 观察指标同义改写一致性率。否定敏感率模型对否定句式的回答是否与肯定句形成正确对照。无关信息抗干扰率在问题里插入不相关的段落看模型是否被带偏。6.4 工程实践鲁棒性测试适合作为回归用例放到 CI 流程里。每次修改 Prompt 模板、升级模型版本、调整 RAG 参数后自动跑一遍改写测试比只跑固定题库更能提前发现问题。建议至少准备 50 组改写覆盖常见业务问法。7. 原则四因果一致性与逻辑连贯性7.1 原则定义因果关系是认知能力里很难评估的部分。模型需要做的不是记住题目和答案而是在多步推理中保持逻辑链条不断裂A 导致 BB 导致 C那么在追问 C 是否反过来影响 A 时模型必须基于当前条件推理而不是套用训练数据里的模板。用户如果问一个需要三步推理的问题模型每一步都对但最后一步用了错误的前提这就是逻辑断链。7.2 测试设计设计如下类型题目类型一多步因果用户问题某电商平台取消“满 299 减 50”优惠券同时把新用户首单折扣从 20% 降到 10%。假设其他条件不变新用户客单价是否会受影响请按因果链条分步解释。类型二反事实用户问题如果平台没有取消满减券只降低新用户折扣那么前面分析的客单价影响会发生什么变化类型三逻辑矛盾检测用户问题分析下面这段论证是否存在逻辑错误产品销量下降是因为评价变差评价变差是因为物流变慢物流变慢是因为仓库人手不足所以只要增加评论回复人手就能提升销量。注意第三题有一个明显的逻辑滑坡评论回复人手和物流仓储是两码事模型需要判断最后一步的结论和前面链条不一致。7.3 观察指标步骤完整度模型推理是否列出完整的前因后果。前提一致性推理过程中是否引入了与题干矛盾的新前提。反事实区分度当条件变化时模型是否明确调整结论而不是重复原答案。7.4 工程实践对于 Agent 类应用建议在 Prompt 中要求模型显式写出推理过程再通过规则检查推理步骤里是否包含“因为……所以……”的关键连接词并抽查这些连接词前后的语义是否一致。更稳妥的做法是给推理步骤加一个“自检节点”让模型自己检查每一步是否基于已知前提。8. 原则五不确定性校准8.1 原则定义不确定性校准关注的是模型的置信度表达和真实正确率是否匹配。如果一个模型在回答 100 道题时自报置信度 90% 以上的题目中实际正确率只有 60%那这个模型就是过度自信。幻觉问题本质上就是过度自信的一种表现。模型不知道答案却用流畅的表达掩盖了不确定性这是认知评估里最危险的失效模式。8.2 测试设计构造一组低信息量问题让模型必须面对“不知道”的状态。示例用户问题 11953 年波兰某个小城市的邮电局每天处理的电报数量是多少 用户问题 2请说出莎士比亚《哈姆雷特》中完全没有出现过的角色名字。 用户问题 3一个长 3 米、宽 4 米、高 5 米的长方体水箱目前水深 2 米请问水的体积是多少第三题是计算题模型应该算出 24 立方米。但很多模型会误认为是在问水箱容积给出 60 立方米。这里要评估模型是否知道自己“计算的是水而不是水箱”。校准测试的第二步是让模型给出置信度用自然语言表达或数值表达都行。请回答下面问题并给出你对答案的置信度0-100。然后统计自报置信度在 80 以上的题目中真实正确率。自报置信度在 50 以下时模型是否仍强行给出答案。是否存在“低置信度但答案正确”与“高置信度但答案错误”的错位。8.3 观察指标校准曲线按置信度分桶统计每个桶内的真实正确率。过度自信率自报置信度高但实际错误的样本占比。拒答质量模型说“不知道”时是否伴随合理的解释而不是简单一句话。8.4 工程实践如果模型自报置信度不可靠工程上有两种兜底方案。第一种是外部校验把模型回答的关键实体、数值抽出来与知识库或搜索引擎结果做比对。第二种是采样一致性校验让模型对同一问题回答多次可以调整温度如果多次结果差异很大说明模型并不稳定系统应该降低该回答的展示优先级。9. 原则六上下文感知与记忆边界9.1 原则定义上下文感知评估的是模型能不能正确利用输入里的长期信息而不是只看到最后两句话。记忆边界则要判断模型是否清楚哪些信息是上下文提供的、哪些是它自己训练知识里的以及当上下文信息和训练知识冲突时它会不会被“带跑”。常见的失败场景是长文档问答。文档早就说明了一个事实但模型在后面的回答中忽略了这个事实或者被上下文末尾新出现的信息干扰了前面的判断。9.2 测试设计类型一长距离信息提取构造一段 5000 字以上的业务文档把关键信息放在文档开头然后在文档末尾提出一个依赖开头信息的问题。比如文档开头写“客户名称是北京云图科技有限公司”末尾问“请告诉我文档提到的客户全称”。类型二矛盾信息检测在文档的不同位置放入互相矛盾的信息。文档第 1 段本活动仅限新用户参与。 文档第 5 段历史注册超过 6 个月的用户也可以参加本次活动。 用户问题一个注册了 2 年的老用户能参加活动吗合格的模型应该指出“文档前后存在矛盾”而不是选其中一句直接回答。可以接受的回答是“根据第 5 段历史注册超过 6 个月可以参加但第 1 段仅限新用户两者冲突建议以第 5 段为准并和业务方确认。”类型三无关信息干扰在文档里插入大段无关的营销文案看它会不会分散模型注意力。9.3 观察指标长距离召回率关键信息在不同位置时模型正确引用的比例。矛盾识别率模型是否主动发现上下文冲突。抗干扰率无关信息是否导致最终答案偏离。9.4 工程实践在长上下文评估中建议把关键信息分别放在开头、中间、末尾三个位置测试不要只测“信息在最后”的易模式。另外要控制上下文长度梯度比如 2K、8K、32K、128K 各抽一组用例观察召回率随长度衰减的曲线。这个曲线对模型选型非常关键。10. 落地一套评估执行流程10.1 构建评估集先不要追求数量。一个业务场景可以先从 100 个用例起步其中类型数量占比说明标准问答40%业务常见问题保证基础能力缺信息问题20%测试模型能否主动询问或拒绝猜测多意图复合问题15%测试任务对齐改写一致性问题15%同义词替换、句式变换对抗/矛盾问题10%文档内矛盾、逻辑陷阱每个用例记录字段输入文本、附加文档可选、期望行为、检查点、通过标准。建议用 JSON 保存方便脚本读取。[ { id: case_001, type: standard_qa, input: 小米粥适合糖尿病人吃吗, context: , expected_points: [需要综合考虑血糖反应, 不能一概而论, 建议监测血糖], pass_criteria: 至少覆盖 2 个 expected_points }, { id: case_002, type: multi_intent, input: 分析这段日志的原因给出临时解决方案并评估是否与昨天的配置改动有关。, context: 日志片段..., expected_points: [定位原因, 给出方案, 关联配置改动], pass_criteria: 覆盖全部 3 个 expected_points } ]10.2 编写批次运行脚本用 Python 写一个通用评估脚本核心逻辑是读取用例 - 调用模型 - 收集输出 - 人工或 LLM 辅助打分 - 生成报告。import json import time from typing import Any # 这里以通用请求函数为例实际需要替换为对应模型的 SDK 或本地推理接口 def call_model(prompt: str, context: str ) - str: # 示例requests.post(http://127.0.0.1:8000/v1/chat/completions, json{...}) # 返回模型生成的文本 return model response placeholder def load_cases(path: str): with open(path, r, encodingutf-8) as f: return json.load(f) def evaluate(cases) - list[dict[str, Any]]: results [] for case in cases: start time.time() response call_model(case[input], case.get(context, )) latency time.time() - start results.append({ id: case[id], type: case[type], response: response, latency: round(latency, 2), expected_points: case.get(expected_points, []) }) # 控制请求频率防止触发限流 time.sleep(0.5) return results if __name__ __main__: cases load_cases(./cases.json) results evaluate(cases) with open(./results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)评分阶段可以用人工评分也可以让另一个更强的模型做辅助打分。辅助打分时要注意不能让被评估模型自己给自己打分否则会有严重的偏差。10.3 设计评分卡每次评估输出一张评分卡用于团队内部对比模型版本或提示词版本。模型版本可溯源任务对齐语义鲁棒性因果一致性不确定性校准上下文感知综合通过率model_v165%72%58%70%45%80%65%model_v278%85%72%76%66%84%77%注意上面的数字是示例格式具体以你的测试结果为准不要用它作为任何模型的真实参考分。11. 评估中的常见误区与偏置源11.1 数据污染很多公开 Benchmark 的题目会出现在模型训练数据里模型可能记住答案而不是学会推理。规避方法是自定义业务用例并且用例不要随便出现在公开数据集里。不要把训练数据和评估数据混在一起这是底线。11.2 提示词过拟合评估时使用的 Prompt 和实际业务 Prompt 往往不同。如果你用一套精心设计的 Prompt 评估那评估到的是“Prompt 调优后的模型”而不是“模型本身”。建议同时跑两套一套是未优化的裸 Prompt一套是最终业务 Prompt两者对比才能判断能力提升来自 Prompt 还是模型。11.3 只看单次输出LLM 输出具有随机性单次回答不能代表真实能力。每个用例至少跑 3 到 5 次取多数结果或统计通过率不要用一两次输出就下结论。11.4 小样本定趋势100 个用例只能看出大概方向不能给出置信度很高的结论。如果要对模型做 A/B 切换决策建议至少准备 300 到 500 个用例并按业务场景分层抽样。12. 模型选型与工程落地建议不同业务场景对六项原则的权重完全不同选型时不要试图让所有指标都“最好”而是按场景分配权重。业务场景高权重原则说明客服问答任务对齐、不确定性校准用户意图复杂答错比不答危害更大知识库 RAG可溯源、上下文感知必须给出来源长文档信息召回是关键数据分析/代码辅助因果一致性、语义鲁棒性推理链条必须正确换一种问法结论不能变审核/风控语义鲁棒性、不确定性校准对抗样本多拒绝要合理创意写作任务对齐、逻辑连贯覆盖用户要求结构完整即可在工程上六个原则可以固化为自动化测试套件。每当语言模型版本更新、Prompt 模板修改、RAG 参数调整时都跑一遍回归输出评分卡。这个习惯能避免很多上线后才暴露的问题。13. 常见问题与排查方法问题现象可能原因排查方式解决方案模型回答看起来很流畅但找不到事实依据可溯源评估不足模型使用训练记忆补全检查回答中的关键实体和数值能否在输入中找到在 Prompt 中要求标注引用来源对无来源内容降低展示优先级同一个问题换一种问法答案完全不同语义鲁棒性差提示词敏感准备多组等义改写批量测试调整 Prompt 模板增加防句式敏感的引导必要时用采样投票取多数文档里关键信息在开头模型却答错长上下文召回能力不足分长度梯度测试召回率换更擅长长上下文的模型版本或调整 RAG 策略把关键信息放在上下文靠后位置模型对不知道的问题强行给答案不确定性校准差过度自信统计高置信度回答的真实正确率增加外部校验层或引入采样一致性检测校准置信度多步骤推理时前后逻辑矛盾因果一致性不足分析推理步骤检查是否引入新前提要求模型显式分步推理增加自检节点评估结果波动大单次采样、测试用例太少增加重复次数和用例数每个用例跑 3 到 5 次统计通过率区间模型文件缺失、CUDA 驱动问题、API 连接失败等基础环境问题不属于认知能力评估范畴但会影响评估任务的执行。建议在跑评估前先确认模型服务可用可用一个简单的冒烟测试用例验证调用链是否正常。14. 最佳实践与合规提醒第一保持评估集版本管理。评估用例、Prompt、模型版本、日期、评分结果全部记录在案。后续追溯“为什么这个版本分数下降了”时没有版本管理寸步难行。第二不要让模型自己给自己评分。辅助评审应使用不同的模型或者至少使用不同的 Prompt 体系避免“自评价偏好”。第三涉及用户真实数据时必须做脱敏处理。聊天记录、订单信息、客服会话都不能直接作为评估用例进入测试集尤其不能进入公开 Benchmark。第四评估报告要有“失败样例分析”。不要只看通过率把最典型的 10 个失败案例摘出来分析是模型能力问题、Prompt 问题还是数据问题。这一步最能推动质量改进。第五评估不是一锤子买卖。新模型发布、Prompt 调整、知识库更新、业务规则变化都可能影响模型表现评估频率要和系统迭代频率绑定。15. 总结与下一步这套评估框架的核心不是“找到一个万能分数”而是逼着你从答案、推理、依据、意图、稳定性、自我认知六个维度去观察模型。先跑通 100 个定制用例生成第一版评分卡再逐步扩大覆盖范围是最稳妥的起步方式。建议你先做三件事第一把当前业务中最常见的 50 个问题整理成标准评估集第二挑 10 个问题做多意图改写测试看模型当前的状态第三建立一个简易的批次评估脚本把人工评分和报告生成流程跑通。做完这三步你对模型能力的判断会明显比单纯看 Benchmark 分数更可靠。后续可以继续扩展的方向包括把评估集接入 CI/CD、做 Agent 多轮对话场景评估、加多模态输入评估以及设计面向垂直行业的专项认知评估集。每一步都是在把“模型看起来聪明”变成“模型在业务里真的可靠”。