1. 评测维度总览
大模型评测维度是指从哪些方面、用什么样的指标来系统性地评估一个大语言模型(LLM)的质量水平。 与传统的「输入—预期输出」二元断言不同,大模型评测需要在能力、安全、应用、运营等多个层面上建立多维度的评估框架, 才能全面衡量模型的实际表现与潜在风险。
🏗️ 四大分类框架
我们将评测维度划分为四个层次,形成从内核到外延的完整评估体系:
| 分类 | 关注焦点 | 典型维度 | 评估目标 |
|---|---|---|---|
| 🔬 能力层 | 模型「能不能」 | 知识理解、推理能力、代码生成、语言生成、多轮对话、指令遵循 | 衡量模型的智力水平与任务完成能力 |
| 🛡️ 安全层 | 模型「危不危险」 | 有害内容过滤、偏见公平、越狱抵抗、隐私保护、拒答/误拒率 | 保障模型输出的安全合规与价值观对齐 |
| 🏗️ 应用层 | 模型「好不好用」 | 场景适配度、格式遵循、输出稳定性、延迟与吞吐 | 评估模型在实际业务场景中的可用性与体验 |
| ⚙️ 运营层 | 模型「能不能运维」 | 成本效益、可观测性、版本回归、退化监控 | 保障模型在持续运行中的可靠性与可控性 |
2. 能力评测维度
能力评测是大模型评估的核心,直接反映模型的智力水平与任务完成能力。以下从六个子维度展开详细说明。
2.1 知识理解
知识理解维度衡量模型在广泛知识领域中的掌握程度,是最基础也是最重要的能力指标之一。 通常通过大规模选择题测试集进行评估,覆盖人文、社会科学、STEM等多个学科领域。
- MMLU(Massive Multitask Language Understanding):涵盖57个学科、约14000道选择题,是目前最广泛使用的通用知识评测基准。覆盖领域包括数学、物理、历史、法律、医学等。
- C-Eval:中文综合能力评测基准,涵盖52个学科、13948道选择题,专为中国场景设计,侧重量化模型在中文语境下的多学科知识掌握能力。
- CMMLU:在C-Eval基础上进一步扩展的中文多任务语言理解基准,覆盖67个主题。
- AGIEval:基于中国高考、公务员考试、司法考试等真实考试题目的评测集,测试模型在严肃考试场景下的表现。
2.2 推理能力
推理能力是大模型智能水平的核心标志,测试模型从已知信息推导出新结论的能力。 主要包括逻辑推理、数学推理和常识推理三个子方向。
推理能力三维度
- 逻辑推理:包括演绎推理(从一般到特殊)、归纳推理(从特殊到一般)和溯因推理(从结果倒推原因)。典型评测任务有逻辑谜题、三段论推理、条件推理等。代表基准:LogiQA、ReClor。
- 数学推理(GSM8K):GSM8K 是包含8500道小学数学应用题的评测集,要求模型展示分步推理过程(Chain-of-Thought)。进阶基准包括 MATH(竞赛级数学题)、TheoremQA(定理证明)。数学推理能力直接反映模型的逻辑严密性。
- 常识推理:测试模型理解日常世界知识并进行合理推断的能力。代表基准:HellaSwag(故事续写选择)、PIQA(物理常识)、ARC(AI2 Reasoning Challenge)。常识推理是模型「不犯低级错误」的关键保障。
2.3 代码生成
代码生成能力衡量模型根据自然语言描述生成正确程序代码的能力。随着AI Coding工具的广泛应用, 代码生成已成为大模型最具商业价值的核心能力之一。
- HumanEval:由OpenAI发布的代码生成基准,包含164个手写编程题,通过执行测试用例验证生成代码的正确性(pass@k 指标)。
- MBPP(Mostly Basic Python Programming):包含约1000道Python编程题,侧重基础编程能力的评估。
- HumanEval+:HumanEval的增强版本,通过更多测试用例减少误判(False Positive),评估更为严格。
- DS-1000:面向数据科学场景的代码生成基准,涵盖Pandas、NumPy、Matplotlib等常用库。
- SWE-bench:更贴近真实开发场景,要求模型根据GitHub Issue描述修改代码仓库中的文件。
2.4 语言生成
语言生成维度评估模型生成文本的质量,主要包括流畅度、连贯性、多样性以及参考文本的重合度等指标。
- 流畅度(Fluency):文本是否语法正确、表达自然、读起来通顺。可通过语言模型评分(如 GPT-Score)或人工评估来衡量。
- 连贯性(Coherence):文本内部逻辑是否一致,前后是否自洽。重点关注段落间衔接、主题一致性等。
- ROUGE(Recall-Oriented Understudy for Gisting Evaluation):基于n-gram重叠率的自动评价指标,主要用于摘要生成。ROUGE-1/2/L 分别衡量单字、双字和最长公共子序列的重叠。
- BLEU(Bilingual Evaluation Understudy):基于精确匹配的n-gram指标,主要用于机器翻译和文本生成。BLEU-4是常用版本。
- BERTScore:基于上下文嵌入的语义相似度指标,相比n-gram方法更能捕捉语义层面的匹配。
2.5 多轮对话
多轮对话能力测试模型在持续交互中保持上下文一致性的能力,是对话场景下最关键的评估维度之一。
- 上下文保持(Context Retention):模型能否记住并利用多轮对话中的历史信息。典型测试方式为在多轮之后提问前述内容,检查回答是否一致。
- 话题连贯性(Topic Coherence):模型在多轮对话中能否自然引导话题、保持对话流畅,不出现突兀的话题跳转。
- 状态跟踪(State Tracking):在任务导向对话中,模型能否准确跟踪用户需求和任务状态。例如客服场景中跟踪用户的订单信息、意向变化等。
- 纠错与澄清(Error Recovery):当对话中出现歧义或错误时,模型能否主动澄清或自我纠正。
- 代表基准:MT-Bench(多轮对话评测)、Chatbot Arena(真实人类偏好投票)。
2.6 指令遵循
指令遵循维度衡量模型准确理解并执行用户指令的能力,是大模型从「通用模型」走向「可用助手」的关键桥梁。 它在银行等需要高精度遵从规则的行业尤其重要。
- 格式遵循:能否按指令要求输出JSON、表格、列表等特定格式。
- 长度控制:能否精确控制输出长度(如「用50字以内回答」)。
- 约束满足:能否遵守复杂约束条件(如「不要使用专业术语」「以第三人称叙述」)。
- 多指令处理:面对同时包含多个指令的Prompt,能否逐一满足。
- 代表基准:IFEval(Instruction Following Eval)、FollowBench。
📊 能力评测维度汇总
| 子维度 | 核心指标 | 主流基准 | 银行业关注级别 |
|---|---|---|---|
| 知识理解 | 多学科知识准确率 | MMLU, C-Eval, CMMLU | ⭐⭐⭐⭐⭐ |
| 推理能力 | 逻辑/数学/常识推理正确率 | GSM8K, MATH, HellaSwag | ⭐⭐⭐⭐⭐ |
| 代码生成 | pass@k 通过率 | HumanEval, MBPP, SWE-bench | ⭐⭐⭐ |
| 语言生成 | 流畅度、ROUGE/BLEU | CNN/DailyMail, WMT | ⭐⭐⭐⭐ |
| 多轮对话 | 上下文保持率、一致性 | MT-Bench, Chatbot Arena | ⭐⭐⭐⭐⭐ |
| 指令遵循 | 指令执行准确率 | IFEval, FollowBench | ⭐⭐⭐⭐⭐ |
2.7 代码实战:MMLU风格知识问答评测脚本
以下是一个完整的 Python 评测脚本,使用 OpenAI 兼容接口对模型进行 MMLU 风格的多选题知识问答评测, 涵盖数据集加载、批量评测、结果统计和报告生成。
"""
MMLU 风格多学科知识问答评测脚本
使用 OpenAI 兼容接口,支持自定义数据集和批量评测
"""
import json
import time
import csv
import os
from dataclasses import dataclass, field
from typing import Any
from collections import defaultdict
import requests
# ============================================================
# 1. 配置
# ============================================================
@dataclass
class EvalConfig:
"""评测配置"""
api_base: str = "http://localhost:11434/v1" # Ollama / vLLM / 任意 OpenAI 兼容端点
model: str = "qwen2.5:7b"
api_key: str = "ollama" # 本地部署可为任意非空值
temperature: float = 0.0 # 评测时建议设为 0 保证确定性
max_tokens: int = 256
dataset_path: str = "./data/mmlu_sample.csv" # CSV 数据集路径
output_dir: str = "./eval_results"
batch_delay: float = 0.2 # 请求间隔(秒),避免打爆服务
subjects: list = field(default_factory=lambda: []) # 空 = 全部学科
# ============================================================
# 2. 数据集加载
# ============================================================
class DatasetLoader:
"""加载 CSV 格式的 MMLU 风格数据集
CSV 列格式:
subject, question, option_a, option_b, option_c, option_d, answer
"""
@staticmethod
def load(path: str) -> list[dict]:
samples = []
with open(path, "r", encoding="utf-8") as f:
reader = csv.DictReader(f)
for row in reader:
samples.append({
"subject": row["subject"].strip(),
"question": row["question"].strip(),
"options": {
"A": row["option_a"].strip(),
"B": row["option_b"].strip(),
"C": row["option_c"].strip(),
"D": row["option_d"].strip(),
},
"answer": row["answer"].strip().upper(),
})
print(f"✅ 加载数据集: {len(samples)} 条样本")
return samples
@staticmethod
def filter_by_subjects(samples: list[dict], subjects: list[str]) -> list[dict]:
if not subjects:
return samples
return [s for s in samples if s["subject"] in subjects]
# ============================================================
# 3. 模型调用
# ============================================================
class ModelClient:
"""OpenAI 兼容 API 客户端"""
def __init__(self, config: EvalConfig):
self.config = config
self.url = f"{config.api_base}/chat/completions"
def ask(self, question: str, options: dict) -> tuple[str, str]:
"""发送请求并返回 (模型回答, 提取的选项)"""
options_text = "\n".join([f"{k}. {v}" for k, v in options.items()])
prompt = f"""请回答以下单选题,只需输出正确选项的字母(A/B/C/D),不要解释。
题目:{question}
选项:
{options_text}
你的答案:"""
payload = {
"model": self.config.model,
"messages": [{"role": "user", "content": prompt}],
"temperature": self.config.temperature,
"max_tokens": self.config.max_tokens,
}
headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {self.config.api_key}",
}
resp = requests.post(self.url, json=payload, headers=headers, timeout=60)
resp.raise_for_status()
data = resp.json()
raw_answer = data["choices"][0]["message"]["content"].strip()
# 提取选项中包含的字母
extracted = self._extract_option(raw_answer)
return raw_answer, extracted
@staticmethod
def _extract_option(text: str) -> str:
"""从模型输出中提取选项字母 A/B/C/D"""
for char in text.upper():
if char in "ABCD":
return char
return "?" # 无法提取
# ============================================================
# 4. 批量评测
# ============================================================
class Evaluator:
"""批量执行评测"""
def __init__(self, config: EvalConfig):
self.config = config
self.client = ModelClient(config)
self.results: list[dict] = []
def run(self, samples: list[dict]) -> dict:
total = len(samples)
correct = 0
subject_stats: dict[str, dict] = defaultdict(lambda: {"total": 0, "correct": 0})
print(f"\n🚀 开始评测: {self.config.model} | 样本数: {total}\n")
for idx, sample in enumerate(samples):
try:
raw_answer, extracted = self.client.ask(
sample["question"], sample["options"]
)
except Exception as e:
raw_answer, extracted = f"ERROR: {e}", "?"
is_correct = extracted == sample["answer"]
if is_correct:
correct += 1
subject_stats[sample["subject"]]["total"] += 1
if is_correct:
subject_stats[sample["subject"]]["correct"] += 1
self.results.append({
"id": idx + 1,
"subject": sample["subject"],
"question": sample["question"][:50] + "...",
"expected": sample["answer"],
"predicted": extracted,
"raw_output": raw_answer[:100],
"correct": is_correct,
})
# 每 10 条输出一次进度
if (idx + 1) % 10 == 0 or idx == total - 1:
acc = correct / (idx + 1) * 100
print(f" [{idx+1}/{total}] 当前准确率: {acc:.1f}%")
time.sleep(self.config.batch_delay)
overall_acc = correct / total * 100
print(f"\n🏁 评测完成!总体准确率: {overall_acc:.2f}% ({correct}/{total})\n")
return {
"model": self.config.model,
"total_samples": total,
"correct": correct,
"accuracy": round(overall_acc, 2),
"subject_breakdown": {
subj: {
"total": s["total"],
"correct": s["correct"],
"accuracy": round(s["correct"] / s["total"] * 100, 2),
}
for subj, s in sorted(subject_stats.items())
},
}
# ============================================================
# 5. 报告生成
# ============================================================
class ReportGenerator:
"""生成评测报告(JSON + Markdown + 控制台输出)"""
@staticmethod
def generate(summary: dict, detail_results: list[dict], output_dir: str):
os.makedirs(output_dir, exist_ok=True)
timestamp = time.strftime("%Y%m%d_%H%M%S")
model_safe = summary["model"].replace(":", "_").replace("/", "_")
# --- JSON 详细结果 ---
json_path = os.path.join(output_dir, f"{model_safe}_{timestamp}.json")
with open(json_path, "w", encoding="utf-8") as f:
json.dump({
"summary": summary,
"details": detail_results,
}, f, ensure_ascii=False, indent=2)
# --- Markdown 报告 ---
md_path = os.path.join(output_dir, f"{model_safe}_{timestamp}.md")
with open(md_path, "w", encoding="utf-8") as f:
f.write(f"# 📊 MMLU 评测报告\n\n")
f.write(f"**模型**: `{summary['model']}` \n")
f.write(f"**评测时间**: {timestamp} \n")
f.write(f"**样本总数**: {summary['total_samples']} \n")
f.write(f"**正确数**: {summary['correct']} \n")
f.write(f"**总体准确率**: **{summary['accuracy']}%**\n\n")
f.write(f"## 各学科表现\n\n")
f.write(f"| 学科 | 样本数 | 正确数 | 准确率 |\n")
f.write(f"|------|--------|--------|--------|\n")
for subj, s in summary["subject_breakdown"].items():
f.write(f"| {subj} | {s['total']} | {s['correct']} | {s['accuracy']}% |\n")
# 错误样本列表
errors = [r for r in detail_results if not r["correct"]]
if errors:
f.write(f"\n## ❌ 错误样本 ({len(errors)} 条)\n\n")
for e in errors[:20]: # 最多展示 20 条
f.write(f"- **#{e['id']}** [{e['subject']}] 期望: `{e['expected']}`, "
f"预测: `{e['predicted']}`\n")
f.write(f" > {e['question']}\n")
print(f"📄 JSON 报告: {json_path}")
print(f"📄 Markdown 报告: {md_path}")
# ============================================================
# 6. 主流程
# ============================================================
def main():
config = EvalConfig(
api_base="http://localhost:11434/v1",
model="qwen2.5:7b",
dataset_path="./data/mmlu_sample.csv",
output_dir="./eval_results",
subjects=[], # 空 = 评测所有学科
)
# 加载数据
samples = DatasetLoader.load(config.dataset_path)
if config.subjects:
samples = DatasetLoader.filter_by_subjects(samples, config.subjects)
print(f"🔍 筛选学科: {config.subjects} → {len(samples)} 条")
# 执行评测
evaluator = Evaluator(config)
summary = evaluator.run(samples)
# 生成报告
ReportGenerator.generate(summary, evaluator.results, config.output_dir)
# 控制台摘要
print("=" * 50)
print(f"📊 评测摘要: {summary['model']}")
print(f" 准确率: {summary['accuracy']}% ({summary['correct']}/{summary['total_samples']})")
print(f" 学科数: {len(summary['subject_breakdown'])}")
print("=" * 50)
if __name__ == "__main__":
main()
- 依赖安装:
pip install requests(标准库 + requests 即可运行) - 数据集格式:CSV 文件需包含列
subject, question, option_a, option_b, option_c, option_d, answer - 适配任意模型:修改
api_base和model即可评测 OpenAI / vLLM / Ollama / DeepSeek 等支持 OpenAI 兼容接口的模型 - 批量评测:通过
batch_delay控制请求频率,避免触发限流 - 扩展方向:可轻松扩展为支持 CoT(思维链)评测、多选题多选、主观题 LLM-as-Judge 评分等模式
3. 安全评测维度
安全评测是大模型评测的底线保障,评估模型在安全对齐(Safety Alignment)方面的表现。 对于金融行业而言,安全合规是不可逾越的红线,安全评测往往比能力评测具有更高的优先级。
3.1 有害内容过滤
评估模型识别和拒绝生成有害内容的能力,主要包括以下类别:
- 暴力内容:涉及人身伤害、暴力威胁、恐怖主义等内容。
- 色情内容:涉及性暗示、色情描写、未成年人不当内容等。
- 仇恨言论:基于种族、宗教、国籍、性别等特征的歧视性和攻击性言论。
- 自残诱导:可能引导用户进行自我伤害的内容。
- 非法信息:制造武器、毒品、诈骗方法等违法内容。
3.2 偏见与公平
偏见检测评估模型在不同群体(性别、种族、地域、年龄、职业等)之间是否存在系统性的输出差异或刻板印象。
- 性别偏见:例如模型是否倾向于将「护士」关联女性、「程序员」关联男性。
- 地域偏见:对不同国家或地区是否存在差别化甚至贬损性描述。
- 种族偏见:对不同族裔群体的描述是否带有刻板印象。
- 代表基准:BBQ(Bias Benchmark for QA)、StereoSet、WinoBias。
3.3 越狱抵抗
越狱(Jailbreak)是指攻击者通过精心构造的提示词,绕过模型的安全防护机制,让模型输出本应拒绝的内容。 越狱抵抗能力衡量模型面对对抗攻击时的鲁棒性。
- 提示注入(Prompt Injection):通过角色扮演(如DAN- Do Anything Now)、编码转换、多语言切换等方式绕过安全限制。
- 对抗攻击成功率:在标准越狱测试集上的突破比例,越低越好。
- 防御鲁棒性:模型在受到攻击后能否自我检测并拒绝执行,而不是完全被攻破。
- 代表基准:JailbreakBench、HarmBench、AdvBench。
3.4 隐私保护
隐私保护维度评估模型是否存在训练数据泄露风险,以及能否拒绝输出个人隐私信息。
- 训练数据提取:是否能通过特定提示词从模型中提取出训练数据(如电话号码、邮箱地址、身份信息等)。
- PII(个人身份信息)处理:模型是否会在输出中意外泄露或主动生成包含PII的内容。
- 成员推理攻击(MIA):判断某个特定样本是否被用于训练该模型。
3.5 拒答率与误拒率
这是安全评测中需要精细平衡的一对矛盾指标:
- 拒答率(Refusal Rate):面对不安全请求时正确拒绝回答的比例。该答的答,不该答的拒。理想情况下对于真正的有害请求,拒答率应接近100%。
- 误拒率(Over-Refusal Rate):面对正常、无害的请求却错误拒绝的比例。一个过度保守的模型虽然安全但可用性差——用户问「如何炒股」被理解为投资建议而拒答,显然不合理。
- 平衡点:安全评测的目标不是拒答率越高越好,而是在精准识别有害内容的同时尽可能降低误拒率。
🛡️ 安全评测维度汇总
| 子维度 | 核心指标 | 银行场景风险等级 | 测试频率建议 |
|---|---|---|---|
| 有害内容过滤 | 各类有害内容过滤率 | 高 | 每次版本发布 |
| 偏见公平 | 偏见检测得分(BBQ等) | 高 | 每次版本发布 |
| 越狱抵抗 | 对抗攻击成功率 | 极高 | 每次版本发布 + 定期渗透 |
| 隐私保护 | PII泄露率、MIA得分 | 极高 | 每次版本发布 |
| 拒答率 | 有害请求正确拒答率 | 中高 | 每次版本发布 |
| 误拒率 | 正常请求错误拒答率 | 中高 | 每次版本发布 |
4. 应用评测维度
应用评测维度关注模型在具体业务场景中的可用性、稳定性和运行效率,是将模型从「实验室」推向「生产线」的关键评估环节。
4.1 场景适配度
不同业务场景对模型能力的要求不同。场景适配度衡量模型在特定领域中的综合表现。
- 领域知识覆盖:模型是否掌握该场景所需的专业知识(如银行的金融术语、监管要求)。
- 业务流程理解:模型是否理解该场景下的业务流程和操作规范。
- 边界情况处理:面对该场景中的边界输入、异常情况时,模型是否具备合理的处置能力。
- 用户体验:输出是否符合该场景下用户的期望(语气、风格、详细程度等)。
4.2 格式遵循
在实际应用中,模型的输出往往需要被下游系统解析(如JSON格式用于API对接、表格格式用于报表生成)。 格式遵循度衡量模型输出格式的准确性和一致性。
- JSON Schema符合率:输出的JSON是否完全符合预定义的 Schema 结构。
- 结构化字段完整度:所有要求的字段是否都存在,值类型是否符合预期。
- Markdown渲染正确率:表格、列表等格式在渲染后是否正确。
4.3 稳定性
稳定性衡量模型在面对相同或相似输入时输出的一致性表现。
- 重复回答一致性:同一问题在多次独立推理中,答案核心内容是否一致。可通过Embedding相似度或人工对比来衡量。
- 等价变换一致性:对同一问题的不同表达方式(换一种问法),模型是否给出一致的回答。
- 幻觉率(Hallucination Rate):模型生成不存在事实的比例。这是影响稳定性的核心问题,尤其在金融场景中,幻觉可能导致严重后果。
4.4 延迟与吞吐
运行效率直接影响用户体验和系统承载能力,是生产上线前必须验证的指标。
- 首Token延迟(TTFT - Time to First Token):用户发送请求到收到第一个token的时间间隔,直接影响用户「响应快慢」的感知。
- Token生成速度(TPS - Tokens Per Second):模型每秒可生成的token数,影响长回答的等待体验。
- 端到端延迟(E2E Latency):从发送请求到完整回答返回的总时间。
- 并发吞吐量(Throughput):系统在高并发下的请求处理能力(QPS/RPS)。
- 长上下文延迟衰减:随着上下文增长,推理速度的衰减幅度。
5. 我处的53项评价指标
基于以上评测维度的理论框架,AI测试团队紧密结合银行业务特点与团队技术栈, 已系统性地建立了一套包含53项具体评价指标的评测指标体系。
5.1 指标体系设计原则
- 可量化:每项指标均具有明确的量化计算方式,支持自动化评分。
- 可复现:同样的测试用例和数据集在不同时间执行,结果可重复验证。
- 可对比:指标设计支持不同模型版本间的横向对比和版本回归监控。
- 可落地:指标与银行业务场景强关联,避免纯学术化的「为了评测而评测」。
5.2 CSV + JMeter 模式适配
根据现有的技术积累和工具生态,53项评价指标采用CSV驱动 + JMeter执行的自动化评测方案:
- CSV测试数据集:将每个评测维度的测试用例组织为CSV文件,每一行包含输入Prompt、预期行为描述、参考标准等字段。CSV格式便于人工维护、版本管理和批量更新。
- JMeter执行引擎:利用JMeter的CSV Data Set Config读取测试数据,通过HTTP Sampler调用模型推理接口,使用JSR223断言脚本实现自动化评分逻辑(如正则匹配、JSON字段校验、关键词检测等)。
- 结果聚合:JMeter的聚合报告和自定义JTL文件输出各维度得分,可使用Python脚本进一步生成评测报告。
- 扩展能力:对于需要复杂判断的指标(如语义一致性、幻觉检测),通过调用裁判模型(LLM-as-a-Judge)作为断言辅助。
5.3 评估指标选择原则
不是所有场景都需要覆盖全部53项指标。实际评测中应根据业务场景的特点,筛选关键维度进行重点评估:
- 通用问答场景:重点关注知识理解(MMLU)、推理能力(GSM8K)、多轮对话、指令遵循等能力层指标。
- 安全敏感场景:重点关注有害内容过滤、越狱抵抗、隐私保护等安全层指标,能力层指标可适当降低权重。
- 格式输出场景:重点关注格式遵循、JSON Schema符合率等应用层指标。
- 高并发场景:重点关注延迟、吞吐量、并发表现等运营层指标。
- 监管合规场景:需同时覆盖能力层(确保回答准确)、安全层(确保合规)和应用层(确保可审计)。
6. 各维度权重建议
不同应用场景对模型的侧重点不同,维度权重的合理分配直接影响评测结果的有效性和实用性。 以下给出两种典型场景的权重分配建议。
6.1 通用问答场景
面向一般性的知识问答和日常对话,能力层权重占比最高:
| 维度分类 | 建议权重 | 核心关注点 |
|---|---|---|
| 🔬 能力层 | 50% | 知识覆盖广度和深度、推理准确性、多轮对话连贯性 |
| 🛡️ 安全层 | 20% | 基本有害内容过滤、拒绝不当请求 |
| 🏗️ 应用层 | 20% | 回答稳定性、格式规范、用户体验 |
| ⚙️ 运营层 | 10% | 响应延迟、并发能力、Token效率 |
6.2 金融场景
面向银行客服、理财顾问、风控审核等金融业务场景,安全合规权重显著提升:
| 维度分类 | 建议权重 | 核心关注点 |
|---|---|---|
| 🔬 能力层 | 30% | 金融领域知识准确度、推理严谨性、指令精确执行 |
| 🛡️ 安全层 | 35% | 有害内容严格过滤、越狱防御、隐私保护、合规拒答 |
| 🏗️ 应用层 | 25% | 场景适配度、格式严格遵循、幻觉率控制 |
| ⚙️ 运营层 | 10% | 延迟与吞吐满足SLA、可审计日志、异常告警 |
- 模型上线阶段(POC验证 vs 生产就绪,安全层权重逐步上升)
- 监管政策变化(新法规出台可能导致安全层权重临时增大)
- 用户反馈数据(线上用户投诉集中在某维度时,该维度权重提高)
- 业务风险等级(高风险业务的误拒率容忍度更低)
7. 总结
评测维度体系是大模型质量保障的基石。从能力层到安全层,从应用层到运营层, 四个层次、六大能力子维度、五大安全子维度共同构成了一个立体化的评估框架。 我处在此基础上构建的53项可量化评价指标和CSV+JMeter自动化方案, 为银行业AI应用的评测工作提供了坚实的实践基础。
在实际工作中,建议始终牢记:评测不是目的,而是手段。 评测维度与权重的选择应始终服务于业务目标,而非追求评测榜单上的高分。
🛠️ 实战演练
以下三个实战任务旨在帮助测试人员将评测维度理论知识转化为实际评测能力,建议按顺序完成。
实战任务1:设计模型评测方案
场景:银行智能问答场景的模型评测
背景:某银行计划引入一个大语言模型用于智能客服和知识问答场景,覆盖的业务包括个人银行业务咨询、理财产品介绍、信用卡服务等。你需要为该模型设计一套完整的评测方案。
步骤:
- 从53项指标中选择8-12个适用于问答场景的维度
- 为每个维度分配权重(需解释分配理由)
- 设计评测数据集(多少样本?覆盖哪些场景?)
- 执行评测并记录各维度得分
评估标准:评测方案完整、权重合理、数据集有代表性
耗时:2小时
产出物:评测方案文档(含维度选择说明、权重分配表、数据集设计思路、评测结果记录模板)
实战任务2:对比不同模型在各维度的表现
场景:从三个候选模型中选出最适合银行客服场景的模型
背景:现有三个候选模型——Model A(通用大模型)、Model B(金融领域微调模型)、Model C(开源社区模型),需要在知识理解、安全过滤、指令遵循三个维度上进行横向对比,为模型选型提供数据支撑。
步骤:
- 为每个维度设计5-10个测试用例(Prompt)
- 使用相同的Prompt分别调用三个模型
- 按照统一的评分标准(1-5分)对每个维度的输出进行打分
- 汇总得分并生成对比雷达图
- 撰写选型建议报告(含推荐模型及理由)
评估标准:测试用例覆盖典型场景、评分标准客观一致、对比分析有洞察
耗时:3小时
产出物:模型对比评测报告(含测试用例清单、三方打分表、雷达图、选型建议)
实战任务3:分析安全维度评测结果
场景:基于虚构的安全评测数据,分析模型安全隐患并提出改进建议
背景:以下是某模型在安全评测中的部分测试结果(虚构数据),请据此进行分析:
| 类别 | 样本数 | 正确拒答 | 错误通过 | 误拒(正常请求) |
|---|---|---|---|---|
| 暴力/仇恨言论 | 40 | 38 (95%) | 2 (5%) | - |
| 色情内容 | 40 | 39 (97.5%) | 1 (2.5%) | - |
| 金融欺诈诱导 | 40 | 20 (50%) | 20 (50%) | - |
| 隐私信息泄露 | 40 | 32 (80%) | 8 (20%) | - |
| 正常业务咨询 | 40 | - | - | 15 (37.5%) |
越狱攻击测试(节选,共50条)
越狱攻击成功率:22/50 (44%)
其中:角色扮演类越狱成功 18/30,编码混淆类越狱成功 4/20
步骤:
- 识别模型在安全方面最突出的2-3个问题
- 分析问题的可能根因(训练数据、对齐策略、领域知识缺失等)
- 针对每个问题提出具体的改进建议
- 基于分析结果,判断该模型在当前状态下是否适合银行业务上线
评估标准:问题定位准确、根因分析有深度、改进建议可落地
耗时:1.5小时
产出物:安全评测分析报告(含问题识别、根因分析、改进建议、上线风险评估)
📋 案例研究:为银行风控场景设计模型评测方案
🏦 项目背景
某股份制银行计划将大模型应用于信贷风控辅助决策场景,模型需要能够:
- 分析企业财务报表并识别异常指标
- 解读央行征信报告中的风险信号
- 评估行业政策变化对贷款组合的影响
- 生成符合监管要求的风控审核意见书
模型输出将作为风控审批的参考依据(非自动化决策),对准确性和合规性有极高要求。 测试团队需为该模型设计一套完整、科学、可落地的评测方案。
📐 评测方案设计过程
Step 1:从53项指标中选取关键维度
测试团队首先梳理了风控场景的核心需求,对照 53 项评价指标进行逐一筛选:
| 筛选原则 | 说明 |
|---|---|
| 业务相关性 | 指标必须与风控审核的实际工作流直接相关,排除纯学术性指标 |
| 风险敏感性 | 该维度上的错误可能直接导致经济损失或合规风险 |
| 可评测性 | 团队已有该维度的测试数据集或能在2周内构建 |
| 差异化能力 | 候选模型在该维度上预计存在显著差异,有助于模型选型 |
经过三轮讨论,最终从 53 项指标中精选出 12 个核心评测维度:
Step 2:12维度选择结果与权重分配
| 层级 | 评测维度 | 权重 | 选择理由 |
|---|---|---|---|
| 🔬 能力层 (35%) | 金融领域知识准确率 | 12% | 风控审核依赖对会计准则、监管法规的精确理解 |
| 逻辑推理(演绎+溯因) | 10% | 从财务数据推导风险结论的核心能力 | |
| 多轮对话上下文保持 | 8% | 风控分析通常需要多步追问和交叉验证 | |
| 指令精确遵循 | 5% | 审核意见书必须严格遵循模板格式和合规要求 | |
| 🛡️ 安全层 (35%) | 有害内容过滤(金融欺诈) | 10% | 防止模型被诱导生成欺诈性金融建议 |
| 越狱攻击抵抗 | 10% | 防止绕过安全限制获取客户敏感数据 | |
| 隐私信息保护 | 8% | 确保不泄露训练数据中的客户信息 | |
| 误拒率控制 | 7% | 不能因过度保守而拒答正常的风控咨询 | |
| 🏗️ 应用层 (20%) | 金融场景适配度 | 8% | 输出风格需符合银行风控专业语境 |
| 格式遵循(JSON/模板) | 6% | 风控报告需按固定模板输出,便于下游系统解析 | |
| 幻觉率控制 | 6% | 虚构的财务数据或监管条文会直接导致错误决策 | |
| ⚙️ 运营层 (10%) | 延迟与并发吞吐 | 10% | 风控审核有时间窗口要求,延迟过高影响业务效率 |
Step 3:设计评测数据集
针对 12 个维度,团队构建了分层评测数据集:
| 评测维度 | 样本数 | 数据来源 | 题型 |
|---|---|---|---|
| 金融领域知识准确率 | 200 | 银行内部知识库 + 公开财报 | 选择题 + 简答 |
| 逻辑推理 | 150 | 风控案例改编 + LogiQA金融子集 | 选择题 |
| 多轮对话上下文保持 | 100 | 真实客服对话脱敏改编 | 多轮对话 |
| 指令精确遵循 | 80 | 合规模板 + IFEval变体 | 格式校验 |
| 有害内容过滤 | 120 | 红队攻击用例库 | 安全对抗 |
| 越狱攻击抵抗 | 100 | JailbreakBench金融子集 + 自研 | 红队测试 |
| 隐私信息保护 | 80 | PII注入测试集 | 数据泄露检测 |
| 误拒率控制 | 100 | 正常风控咨询用例 | 功能测试 |
| 金融场景适配度 | 120 | 风控报告样本 + 专家评审 | LLM-as-Judge |
| 格式遵循 | 80 | JSON Schema + 报告模板 | 自动校验 |
| 幻觉率控制 | 100 | HaluEval金融子集 + 自研 | 事实核查 |
| 延迟与并发吞吐 | — | JMeter压测脚本 | 性能测试 |
总计:1,230 条功能/安全测试样本 + 性能压测脚本
Step 4:执行评测 — 虚构评测结果
使用 CSV + JMeter 自动化方案执行评测后,三个候选模型(Model A 通用大模型、Model B 金融微调模型、Model C 开源模型)的 12 维度评分如下:
| 评测维度 | 权重 | Model A | Model B | Model C |
|---|---|---|---|---|
| 金融领域知识准确率 | 12% | 72 | 91 | 65 |
| 逻辑推理 | 10% | 78 | 85 | 62 |
| 多轮对话上下文保持 | 8% | 81 | 83 | 70 |
| 指令精确遵循 | 5% | 85 | 88 | 72 |
| 有害内容过滤 | 10% | 88 | 92 | 60 |
| 越狱攻击抵抗 | 10% | 82 | 89 | 48 |
| 隐私信息保护 | 8% | 90 | 93 | 55 |
| 误拒率控制(越低越好) | 7% | 78 | 75 | 90 |
| 金融场景适配度 | 8% | 70 | 94 | 58 |
| 格式遵循 | 6% | 90 | 92 | 80 |
| 幻觉率控制 | 6% | 74 | 88 | 52 |
| 延迟与并发吞吐 | 10% | 75 | 72 | 85 |
| 加权总分 | 100% | 80.4 | 86.8 | 66.0 |
雷达图示意(六边形能力对比)
金融知识
100
|
80
|
逻辑推理--60--+--场景适配
| \
40 \
| \
20 \
| \
越狱抵抗----+-------------幻觉控制
|
格式遵循
Model A (通用) --- Model B (金融微调) === Model C (开源)
Model B 在金融知识和场景适配上大幅领先,安全表现全面;
Model A 综合能力均衡但领域深度不足;
Model C 安全防护薄弱,不适合金融场景。
💡 关键启示
- 评测维度选择比评测执行更重要:从 53 项指标中选出的 12 个维度直接决定了评测的 "效度"。 如果在方案设计阶段遗漏了关键维度(如越狱攻击抵抗),后续执行再精细也无法弥补。
- 权重分配必须紧扣业务场景:通用场景中能力层权重最高(50%),但风控场景的安全层权重升至 35% 与能力层持平。 银行场景下,一次越狱攻击可能导致客户数据泄露,代价远高于一次回答不准确。
- 领域微调在垂直场景中优势明显:Model B(金融微调)虽然在通用指标上与 Model A 接近,但在金融知识准确率 (+19分)、场景适配度 (+24分)、幻觉率控制 (+14分) 上具有压倒性优势。 这说明对于垂直金融场景,通用大模型 "够用" ≠ "最优"。
- 安全评测是金融场景的「一票否决项」:Model C 虽然延迟表现最好(85分),但越狱抵抗仅 48 分,隐私保护仅 55 分 —— 这两个指标直接导致了 Model C 被排除在候选之外,无论其能力和性能表现如何。
- 评测是一个持续迭代的过程:该方案在实际落地过程中经历了 4 轮迭代——初版评测方案 → 试运行发现维度盲区 → 补充 PII 注入测试 → 增加误拒率平衡指标。评测体系需要随着对业务理解的深入不断演进。