课程：B站大学
记录大模型评测和AI测试工具的提效

---

1.初识大模型评测

什么是大模型评测

通过系统性的方法和标准，对大型人工智能模型（如大语言模型、多模态模型等）的效果、能力、性能、可靠性、安全性等维度进行量化评估的过程，以此对模型的认知能力（如推理、创作）、任务表现（如问答、翻译）、安全伦理（如偏见控制、隐私保护）进行多维度量化分析；
其本质是通过标准化数据集与评估体系，设计针对性的任务和指标，衡量模型在不同场景下的表现，从而判断模型是否达到预期目标、发现潜在缺陷或优化方向。
flageval评测榜单：
主页：flageval评测
排行榜：https://flageval.baai.ac.cn/#/leaderboard

为什么需要评测

• 模型效果感知，能力边界测绘：明确模型表现、优势短板（如Claude - 3数学强但代码弱于GPT - 4）。
• 模型迭代优化：开发者通过评测定位语义、推理、生成等短板，推动算法优化（如GPT系列靠评测提升逻辑推理）。
• 商业落地筛选：企业对比模型在垂类场景（医疗、法律等）适用性（如金融模型评测风控准确性）。
• 学术研究推进：学术界用评测基准（GLUE、SuperGLUE）横向对比性能，推动技术边界（如BERT在GLUE突破促预训练发展）。
• 伦理与安全管控：检测偏见、隐私泄露、有害内容等风险（如歧视性回答），控风险、合规准入。
• 公平比较：统一标准横向对比性能，避免“宣传战”（如各类评测榜单）。

如何评测大模型？

流程：
评测目标 → 建立标准 → 准备评测集 → 确定指标 → 执行评测 → 产出报告 → 专项调优（闭环迭代）

关键步骤：
明确目标：通用能力 or 垂类适配（如电商重商品理解+客服对话）
评估标准：定义打分规则（如语义连贯5分，断续1分）
设计评测集：覆盖多维度（常识、多轮、多模态）
选择指标：分类→准确率；生成→BLEU/ROUGE
执行评测：自动化工具 + 人工评估（如专家打分诗歌：韵律30%+创意40%+情感30%）
分析报告：总结优劣，输出优化建议（如数学推理弱→强化符号计算）
专项评测&调优：对特定场景进行专项评测，比如大模型幻觉，鲁棒性，安全等，并不断进行模型优化及评测验证；

大模型评测对象全景表

评测对象	介绍	常见类型	评测重点
大模型 LLM	指经过大规模通用数据预训练、具备泛化能力的底层模型，是各类应用的基础。	- 通用大模型 (LLM)：如 GPT-4、LLaMA、PaLM 等，以文本为核心处理对象。- 多模态模型：如 CLIP（图文理解）、GPT-4V（文本 + 图像联合建模）、MUSICLM（文本 + 音频）。- 行业大模型（如医疗 BioGPT、法律 LawGPT，以及处理表格、知识图谱的模型，如 Google 的 TabNet）	- 用能力：语义理解、逻辑推理、知识记忆（如能否正确回答历史事件时间线）。- 模型效率：参数量、推理速度、能耗（如相同任务下，模型 A 比模型 B 推理速度快 20%）。
智能体 (Agents)	指基于大模型构建的、具备目标导向行为能力的系统，可自主决策、调用工具或与环境交互。	- 任务型智能体：如 AutoGPT（可自主调用搜索引擎、文件操作等工具完成任务）、Microsoft Copilot（代码生成 + 工具集成）。- 虚拟角色/对话型智能体：如 ChatGPT（具备多轮对话逻辑，可理解上下文）、企业客服机器人（结合知识库的垂类对话系统），游戏 NPC 等。- 物理世界交互智能体：如机器人控制智能体（结合视觉模型与大模型，控制机械臂完成抓取任务）	- 任务完成度：能否按步骤完成复杂目标（如“规划北京 3 日旅游行程并预订酒店”）。- 工具调用合理性：是否在恰当场景调用正确工具（如计算数学题时调用计算器 API 而非直接生成答案）。- 对话连贯性：多轮交互中是否保持上下文一致性（如前一轮询问“北京景点”，下一轮回答需关联该主题）。
模型应用与解决方案	指基于大模型构建的具体行业应用或端到端解决方案。	- AI 产品垂类应用：如智能客服、AI 编程助手 Copilot。- 行业解决方案：医疗诊断系统（如结合大模型的病历分析工具）、法律文书生成平台（如合同自动审核系统）。- 多模态应用：视频内容理解平台（如自动生成视频字幕并分类）、AR 辅助维修系统（图像识别 + 大模型）	- 场景适配性：在真实业务场景中的准确率（如医疗系统对肺炎 CT 的诊断符合率）。- 用户体验：响应速度、交互流畅度（如客服系统的平均回复延迟是否低于 500ms）。- 合规性：是否符合行业法规（如医疗应用需保护患者隐私，法律应用需确保条款引用准确性）。
模型组件与能力模块	大模型中的特定功能单元或经过微调的子模块，而非完整模型。	- 云服务平台（如 AWS Bedrock、百度文心千帆）- 推理框架/引擎：处理逻辑推断的组件（如数学推理专用模块、知识图谱推理器，MLC-LLM、TensorRT-LLM）- 硬件/适配器（Adapter）：如 NVIDIA H100、华为昇腾910，垂类场景微调时添加的轻量级模块（如医疗领域的 prompt 适配器）	- 框架兼容性：部署框架在不同硬件（如 GPU、TPU、边缘芯片）上的推理速度差异。- 性能：模块与其他系统集成后的性能影响（如添加适配器后，模型整体推理速度是否下降）。- 工具效率：量化工具对模型精度的损失程度（如 INT8 量化后，模型在 MNLI 数据集上的准确率下降是否低于 5%）。
大模型组件或插件等	围绕大模型的开发工具、部署框架、评估套件等生态组件	- Embedding 模块：负责将文本 / 图像转换为向量表示（如 Sentence-BERT 的文本嵌入模型）。- 模型插件：（如 ChatGPT 插件商店）、LoRA 微调模块- 评测套件：开源评测框架（如 LM-Eval、Hugging Face Evaluate）	- 插件调用安全性（避免越权操作）- 模块热插拔稳定性（如金融插件加载后不影响基础对话）- 专项能力：Embedding 的语义相似度精度（如相同主题文本的向量距离是否足够近）

注意点：一般是高级模型评测中低级模型或者RAG知识库

大模型评测指标

准确率：猜对的样本数 ÷ 总样本数；用在类别较均衡的简单分类任务。
精确率：预测为“正”的样本中，真正是正的比例；用在怕误判为正的场景，比如把正常邮件判成垃圾邮件。
F1分数：精确率和召回率的折中；用在类别不平衡时，比准确率更靠谱。
困惑度（PPL）：衡量模型预测下一个词有多“懵”，数值越低说明语言模型越稳；用在评测大模型本身的生成流畅度和基础能力。
ROUGE / ROUGE-L：看生成文本和参考答案有多少重叠内容；用在文本生成任务，比如自动摘要、机器翻译。

测试用例生成用哪个工具好？

我自己最喜欢用户的是manus，大家喜欢的可以去搜索下，manux比chatgpt等好用，也方便
积分每日300，某鱼可以2元买2000积分，基本可以用2个多月，用于测试用例生成
manux好用：manux网址

接口测试场景化case

实际测试考虑的场景很多，建议大学可以学习《google软件测试之道》,针对软件测试行业和测试思维，以及常见问题和分析均有大量说明，值得借鉴，但是对于AI系统的测试就不太适用啦，但是可以最借鉴作用

压测流程

压测需要是开发、运维、测试三类人员相互配合最终才能完成，但是一个优秀的测试工程师具备压测脚本开发能力（如jmeter或者python），一般用的python的框架，压测还分为https接口和websocket协议接口等等，尤其是AI智能客服这一类项目，实时聊天性强，监测指标一般是阿里云/腾讯云自带的云监控，部分接口调用可以通过压测python脚本的log日志处理，当然最全的数据指标还是需要采集或者用jmeter好一些的

BFF 给前端人员带来什么好处（前端中间件）

BFF 是一个只服务于某个前端应用的后端，负责把各种后端数据“拼好、裁好”，再一次性给到前端，让前端拿到的就是它真正需要的数据。

BFF 主要做什么？

职责	说明
接口聚合	调用多个下游服务，合并成一个接口返回
数据裁剪	只返回前端需要的字段，减少传输体积
格式转换	把后端“技术型数据”转成前端“展示型数据”
鉴权/兜底	统一处理登录态、权限、降级、mock
多端适配	Web、App、小程序各自一个 BFF

来个示例：

BFF 实战：前端视角的接口聚合层

BFF（Backend for Frontend）——为前端量身定制的后端，让前端只关心"怎么展示"，不再为"数据从哪来"头疼。

---

一、为什么需要 BFF？

前端常遇到的尴尬场景：

• 一个页面要调 五六个接口
• 后端返回字段又多又杂，前端自己过滤拼接
• Web / App / 小程序共用一套接口，互相将就
• 想改个字段名，得求后端排期

BFF 的核心价值：把后端数据"加工好"再给前端。

前端 → BFF → 微服务A / B / C

---

二、实战场景

首页需要展示：

• 用户名
• 年龄
• 最近 3 条订单

后端有两个独立服务：

服务	接口	返回
用户服务	GET /user/:id	含 email、role 等冗余字段
订单服务	GET /orders?userId=:id	返回全部订单

前端只想拿到：

{
  "name": "zhangsan",
  "age": 25,
  "recentOrders": [101, 102, 103]
}

---

三、BFF 实现（Node.js + Koa）

1. 初始化项目

mkdir bff-demo && cd bff-demo
npm init -y
npm install koa koa-router axios

2. BFF 核心代码

const Koa = require('koa')
const Router = require('koa-router')
const axios = require('axios')

const app = new Koa()
const router = new Router()

const userService = 'http://localhost:3001'
const orderService = 'http://localhost:3002'

// 根据生日计算年龄
function getAge(birthDate) {
  return new Date().getFullYear() - new Date(birthDate).getFullYear()
}

// BFF 聚合接口
router.get('/api/home/user-info', async (ctx) => {
  const userId = ctx.query.userId

  // 并行调用下游服务
  const [userRes, ordersRes] = await Promise.all([
    axios.get(`${userService}/user/${userId}`),
    axios.get(`${orderService}/orders`, { params: { userId } })
  ])

  const user = userRes.data
  const orders = ordersRes.data

  // 裁剪 + 转换，只返回前端需要的
  ctx.body = {
    name: user.username,
    age: getAge(user.birthDate),
    recentOrders: orders.slice(0, 3).map(o => o.orderId)
  }
})

app.use(router.routes())
app.listen(3000, () => {
  console.log('BFF running at http://localhost:3000')
})

3. 前端调用

fetch('http://localhost:3000/api/home/user-info?userId=1')
  .then(res => res.json())
  .then(data => console.log(data))

一次请求，直接拿到"刚好够用"的数据 ✅

---

四、对比：有 / 没有 BFF

维度	无 BFF	有 BFF
请求次数	多次	一次
数据处理	前端自己拼	后端加工好
多端适配	各端重复逻辑	各端独立 BFF
字段语义	birthDate	age
后端改字段	前端跟着改	BFF 兜底兼容

---

五、一句话总结

BFF 是前端的数据中间人，让前端少操心接口，多专注体验。

如果觉得有用，点个赞 👍 再走吧~