模型评测中最危险的陷阱不是缺乏测试，而是测试泛滥却无法推动决策。本文介绍一套经实战验证的分类评测体系：专项能力、功能模块、性能指标三大航道，助你将评测从散点检查升级为精准决策工具。
———— / BEGIN / ————
我做模型评测时，最怕的不是“没测”，而是“测了很多，但结论推不动任何决策”。一旦评测目标不清晰，团队容易陷入散点式测试：今天跑文本效果，明天测推理速度，后天试RAG，最终堆出一堆表格——看起来很努力，却没人能回答一句：这次评测究竟服务于哪个上线动作？
因此，我会先将“测什么”明确划分为三类，并将其作为评测导航：专项能力、功能模块、性能指标。
每次评测都先选定“航道”，再决定题目、方法和产出形式。
这样做的核心价值在于：评测不再是零散检查，而是可直接支撑产品选型与迭代优先级的决策工具。
评测三航道：能力、链路、成本
以下“导航图”是我常用的心智模型，既用于文章中引导读者，也作为我日常评测的Checklist。
这三类并非“全部都要做”，而是“按阶段做”：先证明它会，再证明它能稳定用，最后证明它能在预算内跑得动。
专项能力评测：确认“它会不会这件事”
专项能力评测类似“岗位技能面试”：明确模型需承担的工作，就针对性测试其是否具备相应能力。它适用于模型选型、升级或首次接入新模型阶段——此时无需完美，只需判断是否有资格进入下一环节。
我以具体业务场景拆解能力，而非泛泛评价“生成效果好不好”。例如：
文本生成（客服/助手类）
重点考察三项能力：会不会装懂、会不会走流程、会不会说人话。
会不会装懂：设计模型必然不知答案的问题，观察其是坦诚回应、引导补充信息，还是自信编造合理解释。线上投诉高发点往往不是“答错”，而是“自信地胡说八道”。
会不会走流程：使用需多步追问才能解决的问题（如“订单一直显示已揽收怎么办”），检验系统是否能主动索要订单号、渠道、收件信息等关键字段，而非输出万能话术。
会不会说人话：在确保答案正确的前提下，评估语气是否自然友好；“能解决问题”是底线，“让用户愿意继续聊”是加分项。
文生图（电商/内容生产类）
不只问“好不好看”，而聚焦四个可执行检查点：要素齐不齐、风格稳不稳、材质光影真不真、细节有没有崩。
以白底主图为例，重点检查：主体是否居中、阴影是否自然、透视是否一致、包装文字/标识是否变形、材质表现是否符合描述（如磨砂/金属/玻璃的反光逻辑差异）。
垂类能力（教育/医疗/法律等）
将垂类任务视为“逻辑考试”而非“语言考试”。最大风险不在于表达不流畅，而在于用流畅语言输出违背行业逻辑的结论。因此，题型强调强约束性：需明确推导过程的任务，或要求解释“为什么”的判断题。
专项能力评测的目标非常明确：不是寻找“最强模型”，而是筛选“有资格进入下一关”的模型。宁可在本阶段剔除明显不合格者，也不将其带入系统链路造成工程资源浪费。
功能模块评测：测“链路”，不是“模型看起来很聪明”
进入此阶段，关注点从“模型单点能力”转向“系统协作能力”。RAG、Agent、多模态均被视为端到端链路进行测试——多数线上问题并非源于模型本身，而是链路不稳定、约束缺失或工具调用不可靠。
一句话定义该类评测：我不是测“它会回答”，而是测“它能否可靠完成任务”。
RAG 评测：紧盯“检索 + 引用 + 约束”
核心考察点包括：检索是否找得到、找得准；引用是否正确；回答是否被证据严格约束。
我会故意注入“相似但错误”的干扰材料。最危险的情况是：检索命中错误文档，模型仍高度自信输出结论。稳定RAG系统应在证据不足时降低置信度、提示信息缺失，或明确声明“需要更多资料”。
Agent 评测：紧盯“计划—调用—校验—收尾”
将Agent视作做事的人来考核：能否先拆解目标、再调用工具、继而校验结果、最终闭环收尾。
重点关注三类典型失败：漏步骤（如未确认关键信息）、调用错工具（将查询误作修改）、未校验即下结论（工具返回为空时仍编造结果）。
多模态评测：紧盯“看懂 + 结构化输出 + 一致性”
不止满足于“能描述图片”，更关注能否将图像信息结构化提取，并在多轮交互中保持前后一致。
例如分析商品图，期望输出涵盖材质、颜色、版型、细节；换一种提问方式后，答案仍须保持一致，避免自我矛盾。
此类评测越扎实，越易定位问题根源：是模型能力、检索机制、工具调用、还是提示词/约束设置所致。对产品而言，意味着能快速迭代，而非陷于“模型不行/系统不行”的无效争论。
性能指标评测：不上线才发现“太慢/太贵/撑不住”
性能指标看似偏工程，实为产品成败分水岭。常见情形是：效果评测优异，但上线后因响应慢、成本高、上下文承载力不足，导致体验崩塌——前期所有质量优化随之失效。
我用朴素的产品语言定义该类评测：能否以可承受的成本，稳定交付预期体验？
速度：不仅关注平均响应时间，更紧盯P95/P99长尾延迟。用户体验往往死于高峰期突然不可用。
成本/资源：相同效果下若成本相差一倍，产品策略将完全不同——是否全量上线、是否需分层路由、是否引入降级机制。
上下文：拉长多轮对话，观察模型是否会遗忘先前内容。许多复杂任务失败，并非因推理能力不足，而是上下文断裂导致链路中断。
一个极简选择流程，让评测不再散点
为避免“什么都测一点”，我采用如下决策流程确定当前评测主战场：
我现在处在什么阶段？
未更改： │
未更改： ├─ 选模型 / 换模型 / 新模型到手 → 先做①专项能力（确认有没有资格）
未更改： │
未更改： ├─ 做成系统 / 接 RAG / 上 Agent / 做多模态 → 主做②功能模块（把链路测稳）
未更改： │
未更改： └─ 准备上线 / 扩量 / 预算敏感 / 高峰期风险 → 补齐③性能指标（跑得动、扛得住）
这套逻辑的核心价值在于：每轮评测都能产出“可行动”的结论——明确告知团队：本次评测是为“选谁”“修哪里”，还是“能不能全量上线”服务。
本文最后想强调的一句话：
我做模型评测不是为了跑分，也不是为了做漂亮的报告。我真正想要的是：用一套清晰的分类，把“我觉得”变成“我有证据”，把“争论”变成“决策”。只要评测能推动下一步动作，它就是有价值的；反之，若评测结束无人知道该做什么，那它大概率只是“看起来很努力”的自我感动。
———— / END / ————