模型能力画像专题

版本：v1.1
最后更新：2026-07-06
适用对象：负责模型选型、模型路由、多模型编排、成本优化、评测体系和企业 AI 平台治理的工程师、架构师与产品负责人。

1. 为什么需要模型能力画像

很多团队在选模型时最容易掉进一个坑：

只记得某个模型“很强”
只看公开榜单排名
只看一次 demo 的效果
只比较价格，不比较失败成本
只比较准确率，不比较延迟、稳定性、安全和工具调用能力

这会导致模型上线后出现典型问题：

问答任务效果很好，但结构化输出经常坏
推理能力很强，但延迟太高，客服链路无法接受
长上下文表现不错，但引用证据经常错位
工具调用看似可用，但参数填错导致业务接口报错
成本低的小模型能处理 80% 请求，但没有路由策略，所有流量都打到大模型

模型能力画像的目的不是给模型贴一个“强”或“弱”的标签，而是回答：

这个模型适合哪些任务
不适合哪些任务
在什么输入条件下稳定
在什么风险等级下可以自动化
成本、延迟和质量之间如何取舍
模型版本变化后是否需要刷新结论

OpenAI 的模型选择文档强调，选模型需要在准确性、延迟和成本之间做平衡；Anthropic 的提示词工程文档也明确提到，并不是所有失败都应该靠调 Prompt 解决，有些成本和延迟问题更适合通过换模型处理。模型能力画像就是把这些权衡系统化。

2. 什么是模型能力画像

模型能力画像可以理解为：

用一组稳定维度描述某个模型在某类任务、某套 Prompt、某种工具协议和某批样本上的表现边界

它不是一句主观评价，而是一份可追溯、可比较、可更新的模型档案。

一份完整画像至少应该回答 6 个问题：

模型会不会做这个任务
做得是否稳定
失败时通常怎么失败
成本和延迟是否可接受
风险是否可控
是否适合作为默认模型、备用模型或人工前置模型

更准确地说，画像对象不是“模型整体”，而应该是：

text

任务类型 x 模型版本 x Prompt 版本 x 工具协议 x 检索配置 x 评测集版本

如果这些条件变了，画像结论也可能变。

3. 为什么不能只看公开榜单

公开榜单有价值，但不能直接替代内部画像。

3.1 榜单的问题

公开榜单常见局限：

任务不一定和你的业务一致
输入分布和线上数据不同
不一定覆盖结构化输出、工具调用、RAG、低质量输入等工程问题
不一定反映成本和延迟
不一定测试中文、行业术语、企业内部知识
不一定测试你的 Prompt 和工具协议

HELM 论文提出“整体评估”的重要性，强调语言模型评估需要覆盖多场景、多指标，而不只是看单一准确率。这对企业模型画像很有启发：真实系统更关心多维权衡，而不是一个总分。

3.2 内部画像要回答的问题

企业内部更关心：

模型能否稳定返回合法 JSON
是否能遵守企业安全规则
是否能正确引用检索证据
是否能在工具报错时不假装成功
是否能处理真实用户的脏数据
是否能在预算内满足延迟
是否能支持灰度、回滚和多模型路由

这些问题通常只有内部评测集能回答。

4. 模型画像的基本原则

4.1 按任务画像，不按模型整体画像

不要写：

text

模型 A：强
模型 B：中等
模型 C：便宜

应该写：

text

客服意图分类：
- 模型 A：准确率高，成本高，适合高风险请求
- 模型 B：准确率略低，延迟低，适合普通请求
- 模型 C：便宜，但边界样本容易错，适合预筛

合同条款抽取：
- 模型 A：字段完整性最好
- 模型 B：表格字段容易漏
- 模型 C：不建议用于该任务

同一个模型在不同任务上的表现差异可能很大。

4.2 画像结论必须可追溯

每个结论都应该能追溯到：

评测集版本
样本数量
Prompt 版本
模型版本
运行参数
评分方式
失败样例

不可追溯的画像很快会变成经验传闻。

4.3 能力、稳定性、经济性分开看

一个模型“能做”不代表“适合上线”。

建议把画像分成三层：

层级	关注问题	示例
能力层	会不会做	能否解题、能否抽字段、能否调用工具
稳定层	能否持续稳定地做	多次运行是否一致、边界样本是否可靠
经济层	值不值得用	成本、延迟、吞吐、失败补偿成本

这样不会只盯着能力上限，而忽略生产可用性。

4.4 画像要随版本更新

模型能力不是静态的。

会影响画像的版本包括：

模型版本
Prompt 版本
检索策略
工具 schema
后处理逻辑
安全规则
输入数据分布
评测集

所以画像必须绑定版本，而不是写成一次性文档。

5. 模型能力画像维度

下面是一套比较实用的画像维度。

5.1 基础能力

维度	说明	典型评测
语言理解	是否理解中文、英文、行业术语	问答、分类、摘要
推理能力	是否能处理多步推理和复杂约束	数学、逻辑、业务规则判断
写作能力	是否能按风格生成内容	邮件、公告、报告、营销文案
代码能力	是否能读写代码和定位 bug	PR 审查、单测生成、错误修复
多模态能力	是否能理解图像、音频、视频	截图问答、文档图片、语音总结

5.2 指令遵循

重点看模型是否能遵守：

角色设定
输出格式
长度限制
禁止行为
拒答规则
优先级规则
多步骤任务顺序

很多模型在简单任务中表现接近，但在复杂指令下差异明显。

5.3 结构化输出

结构化输出是生产系统最关键的能力之一。

评测指标：

JSON 解析成功率
必填字段完整率
枚举值合法率
字段类型正确率
是否输出额外字段
schema 校验通过率
失败场景是否仍返回合法结构

对于 API 链路，结构化输出稳定性往往比文采更重要。

5.4 工具调用能力

Agent 和平台工程里要重点评估工具调用。

评测指标：

是否知道何时调用工具
是否会选择正确工具
参数是否完整
参数类型是否正确
是否能处理工具失败
是否会重复调用无效工具
是否会在高风险工具前请求确认

工具调用失败不只是模型回答错，而可能导致真实业务操作错误。

5.5 RAG 与证据使用能力

RAG 任务要评估模型是否能正确使用证据。

评测指标：

是否只基于检索片段回答
是否能发现证据不足
是否引用正确来源
是否能处理证据冲突
是否能区分事实和推测
是否会编造文档中不存在的内容

对于知识库问答，忠实性往往比回答流畅度更重要。

5.6 长上下文能力

长上下文不只是“能塞多少 token”。

要评估：

长文中定位关键信息的能力
多处证据合并能力
开头、中间、结尾信息是否同等可用
是否会忽略中间段落
是否能处理多文档冲突
输出是否仍然稳定

长上下文评测要覆盖不同位置的信息，不要只测试开头几段。

5.7 稳定性

稳定性关注同样输入多次运行是否表现一致。

评测方式：

同一批样本重复运行多次
比较分类一致率
比较 JSON schema 通过率
比较关键字段波动
记录高方差样本

一些任务不要求完全一致，但关键字段和风险判断必须稳定。

5.8 安全与合规

评测维度：

是否泄露系统提示词
是否服从提示注入
是否输出敏感信息
是否拒绝越权请求
是否能识别高风险操作
是否遵守行业合规规则
是否能把高风险样本升级人工

安全能力不能只靠供应商声明，需要内部样本验证。

5.9 成本与延迟

经济层画像至少记录：

输入 token 单价
输出 token 单价
平均输入长度
平均输出长度
平均延迟
P95 延迟
P99 延迟
重试率
回退率
单任务平均成本

很多时候最优模型不是最强模型，而是“在可接受质量下成本最低、延迟最稳”的模型。

6. 画像评分方法

6.1 不建议只用一个总分

单一总分会掩盖关键差异。

例如：

模型	总分	问题
A	90	成本高，适合高风险任务
B	86	成本低，适合大部分普通任务
C	84	JSON 不稳，不适合自动化链路

如果只看总分，可能会错过模型 B 的性价比，也可能误用模型 C。

6.2 推荐使用雷达图或维度表

可以使用 1-5 分评分。

维度	1 分	3 分	5 分
指令遵循	经常忽略关键要求	大部分遵守，复杂场景会漏	复杂约束下仍稳定
结构化输出	经常无法解析	基本合法，边界场景会坏	schema 通过率接近 100%
工具调用	经常误调或漏调	常规工具可用	能处理失败、确认和停止
RAG 忠实性	经常编造	基本基于证据	证据不足时稳定拒答
延迟	无法满足链路	勉强可用	满足 P95 要求
成本	超预算	可接受	有明显性价比优势

6.3 使用门槛线

有些维度不应该参与加权平均，而应该设为门槛。

例如：

JSON schema 通过率低于 98%，不能进入自动化抽取链路
高风险拒答召回低于 95%，不能处理安全敏感任务
P95 延迟超过 5 秒，不能进入实时客服链路
引用准确率低于 90%，不能作为知识库默认回答模型

门槛线比总分更适合生产决策。

7. 评测集怎么设计

模型画像依赖评测集。评测集太粗，画像就会失真。

7.1 样本来源

推荐来源：

线上真实请求
历史失败案例
客服工单
人工标注样本
专家构造边界样本
安全攻击样本
低质量输入样本

不要只用理想样本。真实系统的难点往往来自脏数据、模糊表达、冲突证据和恶意输入。

7.2 样本分层

建议按下面比例起步：

类型	占比	示例
正常样本	50%	标准问答、标准抽取
边界样本	20%	模糊、冲突、字段缺失
失败样本	15%	无证据、无法判断、输入不完整
安全样本	15%	越权、提示注入、敏感信息

关键任务可以增加安全样本和边界样本比例。

7.3 每条样本记录什么

建议结构：

json

{
  "id": "router-001",
  "task": "ticket_routing",
  "input": {
    "user_message": "我已经付款了，但是发票一直开错",
    "context": ""
  },
  "expected": {
    "queue": "finance",
    "priority": "medium"
  },
  "must_have": ["finance", "发票"],
  "must_not_have": ["sales"],
  "tags": ["normal", "finance"],
  "risk_level": "medium"
}

这样后续可以按任务、标签、风险等级统计模型表现。

7.4 人工评分 Rubric

对于总结、写作、分析类任务，可以使用人工评分。

分数	标准
5	完全满足任务，可直接上线使用
4	基本满足任务，只有轻微格式或表达问题
3	有可用内容，但遗漏重要信息或需要明显修改
2	方向错误或关键事实错误
1	不符合任务，存在严重幻觉或安全问题

评分时要同时记录失败原因，例如：

漏字段
格式错误
证据错引
编造事实
工具误调
延迟超标
拒答不当

8. 模型画像的数据结构

画像最好不要只写在文档里，也要能进入配置系统。

示例：

json

{
  "profile_id": "ticket_routing__gpt_x__v2026_07_06",
  "task": "ticket_routing",
  "model": "model_name",
  "model_version": "2026-07-06",
  "prompt_version": "ticket_router_v1.4",
  "tool_schema_version": "none",
  "eval_set": "ticket_routing_eval_v3",
  "sample_count": 240,
  "scores": {
    "accuracy": 0.92,
    "json_schema_pass_rate": 0.995,
    "risk_recall": 0.97,
    "p95_latency_ms": 1800,
    "avg_cost_per_1k_requests": 0.42
  },
  "strengths": [
    "普通客服分流准确率高",
    "结构化输出稳定"
  ],
  "weaknesses": [
    "投诉升级和退款混合场景偶尔误判"
  ],
  "recommended_use": [
    "default_for_low_and_medium_risk"
  ],
  "not_recommended_use": [
    "legal_risk_final_decision"
  ],
  "fallback_model": "stronger_model_name",
  "last_updated": "2026-07-06"
}

核心思想：

画像要机器可读
画像要绑定版本
画像要能被路由策略调用

9. 画像如何驱动模型路由

模型画像最大的价值，是进入运行时决策。

9.1 默认模型选择

可以按任务选择默认模型：

任务	默认模型选择
普通分类	低成本、低延迟模型
高风险审核	更强模型或人工复核
长文分析	长上下文能力强的模型
代码修复	代码能力强、工具调用稳的模型
语音实时问答	延迟低、支持实时交互的模型

9.2 风险分层路由

示例：

text

低风险请求 -> 小模型
中风险请求 -> 中等模型
高风险请求 -> 强模型 + 人工复核
模型低置信度 -> 强模型复核
结构化输出校验失败 -> 重试或回退

9.3 成本优化

画像可以帮助找到成本优化空间：

80% 简单请求用小模型
15% 中等请求用默认模型
5% 高风险请求用强模型

比所有请求都走最强模型更经济。

9.4 回退策略

画像要记录每个模型的可替代关系。

例如：

主模型失败原因	回退策略
JSON 解析失败	同模型重试一次，仍失败则强模型
证据不足	不回退，直接拒答或请求补充
延迟超时	切低延迟模型
工具调用失败	不换模型，先检查工具状态
高风险命中	升级人工

不是所有失败都应该换模型。

10. 画像如何驱动模型更新

模型版本更新时，不应该直接全量替换。

推荐流程：

固定当前线上画像作为 baseline
用同一评测集跑新模型
对比质量、延迟、成本、安全指标
按失败类型分析差异
小流量灰度
观察线上指标
更新画像和路由配置
保留回滚版本

10.1 需要重点观察的变化

输出风格是否变化
JSON 是否更稳或更差
工具调用是否更激进
拒答是否变多
长上下文是否更可靠
成本是否上升
P95/P99 延迟是否变化
安全样本是否退化

10.2 模型变化不一定是坏事

有时新模型会：

更严格遵守安全规则
更少编造
更愿意拒答
更不愿意做不确定判断

这可能导致短期通过率下降，但对高风险任务是好事。所以画像要区分“业务期望变化”和“模型能力退化”。

11. 常见任务的画像关注点

11.1 分类与路由

重点指标：

分类准确率
高风险召回率
混淆矩阵
JSON 合法率
低置信度处理

最常见失败：

类别定义重叠
高风险请求误分到普通队列
对提示注入没有识别

11.2 信息抽取

重点指标：

字段准确率
字段完整率
缺失字段识别
枚举合法率
evidence 是否可追溯

最常见失败：

自动补全不存在字段
把推测当事实
数字、金额、日期出错

11.3 RAG 问答

重点指标：

忠实性
引用准确率
证据不足拒答率
冲突证据处理
答案可读性

最常见失败：

检索证据不足时仍然回答
引用和答案不匹配
把旧知识当成新知识

11.4 Agent 工具调用

重点指标：

工具选择正确率
参数正确率
工具失败处理
停止条件
高风险确认率

最常见失败：

不该调用时调用
该调用时凭空回答
工具失败后假装成功
高风险动作未确认

11.5 内容生成

重点指标：

风格匹配
信息完整
不编造
可读性
品牌和合规约束

最常见失败：

过度发挥
语气不符合品牌
生成未经批准的承诺

12. 画像报告模板

可以按下面结构写一份模型画像报告。

markdown

# 模型能力画像：{任务名称} x {模型名称}

## 1. 基本信息
- 模型：
- 模型版本：
- Prompt 版本：
- 工具协议版本：
- 检索配置：
- 评测集：
- 样本数量：
- 评测日期：

## 2. 推荐结论
- 推荐用途：
- 不推荐用途：
- 默认路由建议：
- 回退建议：
- 是否需要人工复核：

## 3. 核心指标
| 指标 | 结果 | 门槛 | 是否通过 |
|---|---|---|---|
| 准确率 | | | |
| JSON 通过率 | | | |
| 高风险召回 | | | |
| 引用准确率 | | | |
| P95 延迟 | | | |
| 平均成本 | | | |

## 4. 优势
- ...

## 5. 短板
- ...

## 6. 典型失败样例
- ...

## 7. 上线建议
- ...

## 8. 下次刷新条件
- 模型版本变化
- Prompt 版本变化
- 样本分布变化
- 线上失败率升高

13. 常见反模式

13.1 只看模型总榜

问题：

榜单任务不等于业务任务

修正：

用内部任务集建立画像

13.2 所有任务共用一张表

问题：

写作、抽取、工具调用、RAG 的评价维度不同

修正：

按任务类型建立画像

13.3 只看准确率

问题：

忽略成本、延迟、结构化输出和安全

修正：

建立多指标画像

13.4 没有失败样例

问题：

画像只描述平均表现，不能指导回退

修正：

每次评测保留典型失败样例

13.5 画像不进系统配置

问题：

画像只是文档，不能影响运行时决策

修正：

将画像转成路由规则、回退规则、门槛配置

13.6 模型更新后不刷新

问题：

画像结论过期

修正：

建立模型升级评测流程

14. 落地检查清单

14.1 建立画像前

是否明确任务类型
是否有真实样本
是否定义成功标准
是否定义失败类型
是否区分能力、稳定性和经济性
是否有安全样本

14.2 画像评测时

是否记录模型版本
是否记录 Prompt 版本
是否固定评测集
是否记录运行参数
是否统计 P95/P99 延迟
是否记录失败样例
是否进行 schema 校验

14.3 画像上线后

是否进入模型路由配置
是否进入回退策略
是否有灰度计划
是否有回滚方案
是否定期刷新
是否把线上失败样本回流

15. 推荐搭配阅读

16. 推荐资料

以下资料在 2026-07-06 检查时可访问。

官方文档

OpenAI Model selection：https://developers.openai.com/api/docs/guides/model-selection
OpenAI Models：https://developers.openai.com/api/docs/models
OpenAI Working with evals：https://developers.openai.com/api/docs/guides/evals
OpenAI Evaluation best practices：https://developers.openai.com/api/docs/guides/evaluation-best-practices
OpenAI Evals GitHub：https://github.com/openai/evals
Anthropic Prompt engineering overview：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview

论文与评测框架

HELM: Holistic Evaluation of Language Models：https://arxiv.org/abs/2211.09110
Stanford HELM：https://crfm.stanford.edu/helm/

17. 一句话总结

模型能力画像的核心不是证明某个模型“最强”，而是用可复现的任务样本和多维指标描述模型在真实业务中的能力边界，并把这些结论转化为模型选型、路由、回退、灰度和治理策略。

模型能力画像专题 ​

1. 为什么需要模型能力画像 ​

2. 什么是模型能力画像 ​

3. 为什么不能只看公开榜单 ​

3.1 榜单的问题 ​

3.2 内部画像要回答的问题 ​

4. 模型画像的基本原则 ​

4.1 按任务画像，不按模型整体画像 ​

4.2 画像结论必须可追溯 ​

4.3 能力、稳定性、经济性分开看 ​

4.4 画像要随版本更新 ​

5. 模型能力画像维度 ​

5.1 基础能力 ​

5.2 指令遵循 ​

5.3 结构化输出 ​

5.4 工具调用能力 ​

5.5 RAG 与证据使用能力 ​

5.6 长上下文能力 ​

5.7 稳定性 ​

5.8 安全与合规 ​

5.9 成本与延迟 ​

6. 画像评分方法 ​

6.1 不建议只用一个总分 ​

6.2 推荐使用雷达图或维度表 ​

6.3 使用门槛线 ​

7. 评测集怎么设计 ​

7.1 样本来源 ​

7.2 样本分层 ​

7.3 每条样本记录什么 ​

7.4 人工评分 Rubric ​

8. 模型画像的数据结构 ​

9. 画像如何驱动模型路由 ​

9.1 默认模型选择 ​

9.2 风险分层路由 ​

9.3 成本优化 ​

9.4 回退策略 ​

10. 画像如何驱动模型更新 ​

10.1 需要重点观察的变化 ​

10.2 模型变化不一定是坏事 ​

11. 常见任务的画像关注点 ​

11.1 分类与路由 ​

11.2 信息抽取 ​

11.3 RAG 问答 ​

11.4 Agent 工具调用 ​

11.5 内容生成 ​

12. 画像报告模板 ​

13. 常见反模式 ​

13.1 只看模型总榜 ​

13.2 所有任务共用一张表 ​

13.3 只看准确率 ​

13.4 没有失败样例 ​

13.5 画像不进系统配置 ​

13.6 模型更新后不刷新 ​

14. 落地检查清单 ​

14.1 建立画像前 ​

14.2 画像评测时 ​

14.3 画像上线后 ​

15. 推荐搭配阅读 ​

16. 推荐资料 ​

官方文档 ​

论文与评测框架 ​

17. 一句话总结 ​

模型能力画像专题

1. 为什么需要模型能力画像

2. 什么是模型能力画像

3. 为什么不能只看公开榜单

3.1 榜单的问题

3.2 内部画像要回答的问题

4. 模型画像的基本原则

4.1 按任务画像，不按模型整体画像

4.2 画像结论必须可追溯

4.3 能力、稳定性、经济性分开看

4.4 画像要随版本更新

5. 模型能力画像维度

5.1 基础能力

5.2 指令遵循

5.3 结构化输出

5.4 工具调用能力

5.5 RAG 与证据使用能力

5.6 长上下文能力

5.7 稳定性

5.8 安全与合规

5.9 成本与延迟

6. 画像评分方法

6.1 不建议只用一个总分

6.2 推荐使用雷达图或维度表

6.3 使用门槛线

7. 评测集怎么设计

7.1 样本来源

7.2 样本分层

7.3 每条样本记录什么

7.4 人工评分 Rubric

8. 模型画像的数据结构

9. 画像如何驱动模型路由

9.1 默认模型选择

9.2 风险分层路由

9.3 成本优化

9.4 回退策略

10. 画像如何驱动模型更新

10.1 需要重点观察的变化

10.2 模型变化不一定是坏事

11. 常见任务的画像关注点

11.1 分类与路由

11.2 信息抽取

11.3 RAG 问答

11.4 Agent 工具调用

11.5 内容生成

12. 画像报告模板

13. 常见反模式

13.1 只看模型总榜

13.2 所有任务共用一张表

13.3 只看准确率

13.4 没有失败样例

13.5 画像不进系统配置

13.6 模型更新后不刷新

14. 落地检查清单

14.1 建立画像前

14.2 画像评测时

14.3 画像上线后

15. 推荐搭配阅读

16. 推荐资料

官方文档

论文与评测框架

17. 一句话总结