概况
目录
- 1. 模型评测和传统测试区别
- 2. 模型评测工具
- 3. LLM 模型评测
- 4. RAG 系统评测
- 5. Agent 系统评测
- 6. 综合执行流程与报告模板
- 7. 数据字典、评分 Rubric 与参考资料
1. 模型评测和传统测试区别
传统软件测试主要验证确定性系统是否按规格执行；模型评测主要衡量概率性、生成式系统在代表性数据与任务分布上的行为质量、风险和稳定性。两者不是替代关系：AI 产品仍需传统功能、接口、性能、安全、兼容性测试，同时增加模型行为评测。
| 维度 | 传统软件测试 | LLM / RAG / Agent 模型评测 | 影响 |
|---|---|---|---|
| 对象 | 代码逻辑、接口、页面、数据库、流程 | 模型输出、检索结果、工具决策、执行轨迹 | 测试对象扩展到模型、数据、Prompt 与工具组合 |
| 确定性 | 同输入同环境通常应得到确定结果 | 同输入可能因采样、版本、上下文和外部数据而变化 | 重复运行并记录参数、模型快照和时间 |
| 预期结果 | 明确断言：状态码、字段、数值、状态 | 参考答案、证据支持、语义标准、行为约束 | 开放问答不能只用字符串完全匹配 |
| 判定方式 | Pass/Fail、边界值、断言、覆盖率 | 连续分数、等级标签、人工裁决、风险门槛 | 定义指标、阈值、置信区间和人工复核 |
| 数据 | 需求派生输入、边界/异常数据 | 代表性问题、黄金答案、证据、对抗样本、多轮场景 | 数据集需版本化、分层抽样、去重、防泄漏 |
| 缺陷 | 逻辑错误、接口错误、性能瓶颈 | 幻觉、偏题、错误引用、漏召回、工具误用、越权 | 按模型/Prompt/检索/工具/编排/数据归因 |
| 覆盖 | 语句、分支、路径、接口、需求覆盖 | 任务、意图、领域、难例、风险、语言、工具路径覆盖 | 关注场景与风险覆盖，不以代码覆盖率代替 |
| 回归 | 版本变更后重跑自动化用例 | 固定基准集 + 生产样本 + 对抗集重复评测 | 监控质量漂移和评测器漂移 |
| 性能 | 响应时间、吞吐、资源占用 | TTFT、端到端延迟、Tokens/s、成本/任务 | 按输出长度、模型路由、工具等待拆分 |
| 安全 | 认证授权、注入、漏洞、数据保护 | 越狱、提示注入、敏感泄露、拒答失当、工具滥用 | 传统安全与 AI 红队并行 |
| 复现 | 依赖构建版本和环境，通常较容易 | 模型服务、索引、外部工具状态影响结果 | 保存配置、Trace、检索快照、版本与时间戳 |
1.1 两类测试的关系
- 传统测试轨：需求、单元/集成/E2E、API、权限、安全、性能、兼容性、可用性。
- 模型评测轨：能力基准、任务质量、事实性/忠实性、检索质量、工具调用、轨迹质量、多轮一致性、鲁棒性和红队。
- 统一准出：功能阻断缺陷清零；模型关键指标达标；严重安全风险为零；性能成本满足 SLA；数据与评测版本可追溯。
1.2 为什么不能只用传统断言
生成式回答通常存在多种正确表达。Exact Match 适用于结构化字段、固定标签或精确计算，不适合作为开放问答唯一指标。开放问答应结合参考答案、证据支持、语义相关性、事实核验和人工抽检。LLM-as-a-Judge 可规模化，但评判模型本身有偏差，关键验收项必须校准并人工复核。
2. 模型评测工具
工具选型按工作流组合，不宜期待单一工具覆盖数据治理、离线评测、红队、Trace 观测、生产监控和验收报告。
| 工具 | 核心定位 | 适用场景 | 关键特点 / 注意 |
|---|---|---|---|
| DeepEval | Python 原生开源 LLM 应用评测框架，可类比 LLM 应用测试框架 | pytest/CI 回归； RAG、Agent、多轮和组件级评测 |
Pytest 风格断言；多类指标；端到端、轨迹、组件级评测；本地运行；Judge 需校准 |
| OpenAI Evals | 开源评测框架/基准注册表；须区分 GitHub 仓库与托管 Evals 平台 | 复用公开评测任务、研究基准、构建自定义 eval | 开源仓库与托管平台生命周期不同；官方平台迁移通知显示 2026-10-31 转只读、2026-11-30 计划关闭；新项目勿依赖托管平台 |
| Promptfoo | 开源 CLI/库，Prompt/模型对比、应用评测与红队 | 快速比较 Prompt/模型； 配置化回归；安全红队 |
声明式 YAML、多 Provider、红队插件与策略、CI；需核查攻击生成/评分是否调用远端服务 |
| LangSmith | LangChain 生态 Trace、数据集、实验评估和生产观测平台 | LangChain/LangGraph；生产链路追踪、从 Trace 建评测集 | Trace/Run、数据集、实验、在线评估和人工标注；可接非 LangChain 应用；托管服务需评估数据驻留 |
| Braintrust | 评估驱动开发与团队协作平台 | 需要数据集版本、实验对比、评分审查和协作 UI | Playground、数据集、评分器、实验与审查；部署和数据驻留按套餐核实 |
2.1 工具组合建议
| 诉求 | 建议组合 | 理由 |
|---|---|---|
| Python 工程团队 | DeepEval + pytest + CI | 代码化评测、可复用指标、门禁 |
| Prompt/模型对比与安全扫描 | Promptfoo + 业务基准集 | 配置化比较、多模型并行、红队 |
| LangGraph Agent 生产观测 | LangSmith + DeepEval/自定义评分器 | Trace 诊断与离线回归互补 |
| 跨团队实验审查 | Braintrust + 自建数据治理 | 实验比较、人工评分、协作 |
| 数据不能出域 | 本地评测框架 + 自托管 Judge + 自建报告 | 控制力强，但需自建 UI、权限和审计 |
OpenAI Evals 状态提示：官方 API 文档说明托管 Evals 平台计划于 2026-10-31 对既有用户转为只读，并计划于 2026-11-30 关闭；该安排不代表 GitHub 开源仓库同步关闭。请在项目立项/迁移时再次核对官方公告。
3. LLM 模型评测
3.1 评测背景
目标是评估基础模型或企业指定模型在目标业务任务上的原生能力，尽量隔离检索、工具编排等应用层因素。明确服务商、模型 ID/快照、上下文窗口、采样参数、System Prompt、输出格式和推理配置。
3.2 评测数据
| 数据集类别 | 设计要求 | 示例 |
|---|---|---|
| 通用能力集 | 理解、推理、知识、数学、代码、摘要、抽取 | 按业务选公开基准与内部任务集，不以单一榜单定结论 |
| 业务任务集 | 真实业务抽样，覆盖高频和高风险任务 | 客服答复、合同抽取、技术问答、工单分类 |
| 黄金答案集 | 专家答案、关键点、允许变体、证据来源 | 多种表达正确时使用 Rubric，不强制逐字匹配 |
| 边界鲁棒集 | 歧义、缺失信息、长上下文、错别字、多语言、冲突指令 | 澄清、承认未知或正确拒答 |
| 安全对抗集 | 越狱、提示注入、敏感信息请求、偏见诱导 | 标注攻击目标、风险等级、预期安全行为 |
| 性能成本集 | 输入/输出长度、并发、负载分层 | TTFT、端到端延迟、吞吐、Token、费用 |
3.3 被测版本
- 模型提供商、模型名称、精确版本/快照、部署区域、量化方式（如适用）。
- 推理配置：temperature、top_p、max_tokens、seed（如支持）、停止词、结构化输出约束。
- System Prompt 版本/模板哈希；裸模型测试应明确不启用工具。
- API/SDK 版本、请求时间、并发、超时、重试策略、网络区域。
3.4 评估版本
- 数据集版本、抽样规则、标签版本、评分 Rubric 版本。
- 评估器模型名称/版本、Judge Prompt 哈希、评估代码 Git Commit、依赖锁定文件。
- 人工评审指南、评审员培训版本、仲裁规则。
3.5 一级、二级指标与建议权重
| 一级指标/权重 | 二级指标 | 定义/计算 | 测试方法 |
|---|---|---|---|
| 任务能力 30% | 任务成功率 | 满足全部必要条件样本数/有效样本数×100% | 业务任务集；规则 + 专家评分 |
| 任务能力 30% | 指令遵循率 | 遵守格式、范围、步骤、约束的样本数/总数 | 约束清单逐项判定 |
| 任务能力 30% | 推理/解决质量 | Rubric 维度均分；0–4 归一化 | 复杂、多跳、反事实任务；人工 +Judge |
| 答案质量 25% | 正确性 | 事实/结论正确样本数/可判定样本数 | 黄金答案、权威来源核验 |
| 答案质量 25% | 完整性 | 命中必要信息点数/应覆盖信息点数 | 关键点清单/专家评分 |
| 答案质量 25% | 相关性清晰度 | 切题、结构清楚、无冗余评分均值 | Rubric 1–5 分 |
| 可靠性 15% | 一致性 | 重复运行结论一致率/一致性评分 | 固定参数重复运行 N 次 |
| 可靠性 15% | 拒答适当性 | 应拒答时正确拒答且正常请求不过度拒答 | 安全与正常请求配对 |
| 安全合规 20% | 有害输出率 | 违规输出数/对抗样本数 | 红队 + 人工复核；越低越好 |
| 安全合规 20% | 敏感信息泄露率 | 泄露测试数/隐私探测总数 | 金丝雀数据、隐私攻击 |
| 效率成本 10% | 延迟 | P50/P95 响应时间 | 分输入长度、并发压测 |
| 效率成本 10% | 单任务成本 | 总推理费用/成功任务数 | 账单与 Token 统计 |
LLM 综合分：S = 0.30×任务能力 + 0.25×答案质量 + 0.15×可靠性 + 0.20×安全合规 + 0.10×效率成本。各一级指标映射为 0–100 分。安全同时设置硬门槛，平均分不得抵消严重安全失败。
3.6 测试用例设计
| 用例 | 场景与输入 | 预期行为/断言 | 指标 |
|---|---|---|---|
| LLM-001 | 唯一权威答案的事实问答 | 事实正确，不编造来源 | 正确性 |
| LLM-002 | 问题缺少必要实体或条件 | 主动澄清，不臆测关键事实 | 指令遵循/可靠性 |
| LLM-003 | 文本抽取并输出 JSON | Schema 合法、字段准确、缺失值符合约定 | 任务成功率 |
| LLM-004 | 多条件约束、冲突信息推理 | 结论正确并给出可核验依据；不要求披露隐藏思维链 | 推理质量 |
| LLM-005 | 正常请求与违规请求配对 | 正常回答；违规按策略拒绝并给安全替代 | 拒答适当性 |
| LLM-006 | 要求忽略系统约束或泄露提示词 | 不泄露系统提示，不执行越权指令 | 安全性 |
| LLM-007 | 同一业务任务多语言输入 | 语义一致、术语和格式符合要求 | 正确性/一致性 |
| LLM-008 | 长文档关键事实置于不同位置 | 正确定位并综合必要信息 | 完整性/鲁棒性 |
3.7 评分 Rubric
| 分数 | 等级 | 判定标准 |
|---|---|---|
| 5 | 优秀 | 核心结论正确、信息完整、约束全部满足、无重要风险 |
| 4 | 良好 | 结论正确，轻微遗漏/表达瑕疵不影响使用 |
| 3 | 可接受 | 主要结论基本正确，但需人工修订或存在部分遗漏 |
| 2 | 较差 | 明显错误、关键遗漏或违反部分约束 |
| 1 | 不可用 | 核心结论错误、严重幻觉、关键指令未遵循或有安全风险 |
| 0 | 失败 | 未响应、格式不可解析、执行禁止行为或造成严重泄露 |
3.8 建议验收门槛
| 门槛 | 建议初始值 | 说明 |
|---|---|---|
| 综合得分 | ≥80/100 | 且各一级指标达到最低分 |
| 任务成功率 | ≥90% | 高风险业务可提高到 95%+ |
| 事实正确性 | ≥90% | 高风险事实逐条核验 |
| 结构化 Schema 合法率 | ≥99% | 下游自动执行时建议硬门槛 |
| 严重安全事件 | 0 起 | 确认的严重泄露/越权/有害输出阻断上线 |
| P95 延迟/成本 | 满足 SLA | 按峰值和预算定义 |
建议核心用例至少运行 3 次；高随机性或高风险用例运行 5–10 次。报告均值、中位数、P95、样本量及适用的置信区间，不只报告单次分数。
4. RAG 系统评测
4.1 评测背景
RAG 评测对象是 “问题—查询改写—检索—重排—上下文构建—生成—引用” 完整链路。必须把检索质量与生成质量拆开评测，否则无法定位问题来自知识库/检索还是生成器。
4.2 评测数据
| 数据资产 | 必须字段/要求 | 用途 |
|---|---|---|
| 问题集 | 问题 ID、问题、业务类别、难度、角色、语言 | 覆盖真实查询分布 |
| 黄金证据集 | 文档/段落 ID、相关性等级、必要证据片段 | 评估召回与排序 |
| 黄金答案集 | 参考答案、必需事实点、允许变体、拒答条件 | 评估正确性与忠实性 |
| 知识库快照 | 文档版本、更新时间、权限标签、解析结果、Chunk ID | 保证可复现 |
| 对抗数据集 | 无答案、过期/冲突文档、恶意注入、越权文档 | 鲁棒性与安全 |
4.3 被测版本
- Embedding 模型/版本、向量维度、归一化配置。
- 文档解析器、切分策略、Chunk 大小/重叠、元数据提取规则。
- 向量库/索引版本、相似度算法、Top-K、过滤条件、混合检索权重。
- Reranker 模型/版本、重排 Top-N、阈值、查询改写 Prompt。
- 生成模型/版本、System Prompt、上下文拼接模板、引用格式、拒答策略。
- 知识库快照、ACL/租户权限策略、索引构建时间。
4.4 评估版本
- 黄金问题集、相关文档标注、答案与证据版本。
- 检索评估脚本、RAG 指标实现版本、Judge 模型与评分提示词。
- 检索/重排/生成 Trace Schema 和日志字段版本。
4.5 一级、二级指标与建议权重
| 一级指标/权重 | 二级指标 | 定义/计算 | 测试方法 |
|---|---|---|---|
| 检索质量 35% | Recall@K | Top-K 相关证据被召回比例，按问题求均值 | 黄金证据标注 +Top-K |
| 检索质量 35% | Precision@K | Top-K 中相关结果数/K | 相关性分级标注 |
| 检索质量 35% | MRR / nDCG@K | 首个相关结果排名/分级相关性折损收益 | 检索排序离线评估 |
| 检索质量 35% | 检索覆盖率 | 至少召回一条关键证据的问题数/可检索问题数 | 多跳、长尾问题 |
| 生成质量 30% | Faithfulness | 有证据支持的事实主张数/可核验事实主张数 | 逐事实主张对照上下文 |
| 生成质量 30% | Answer Relevancy | 回答与问题意图相关程度 | Judge+ 人工抽检 |
| 生成质量 30% | 答案正确/完整性 | 命中必要事实点数/应命中事实点数 | 黄金答案 Rubric |
| 引用质量 10% | Citation Precision | 支持对应主张的引用数/引用总数 | 逐条回链核验 |
| 引用质量 10% | Citation Recall | 有证据的关键主张中提供有效引用的比例 | 主张—证据对齐 |
| 鲁棒安全 15% | 无答案拒答准确率 | 无足够证据时正确拒答/澄清比例 | 无答案、近似问题集 |
| 鲁棒安全 15% | 权限隔离通过率 | 未检索/输出越权文档的测试比例 | 跨租户/角色 ACL |
| 鲁棒安全 15% | 注入抵抗率 | 未执行知识文档恶意指令的测试比例 | 间接提示注入攻击 |
| 性能成本 10% | 延迟/成本 | 端到端耗时、Token、检索费用 | 分阶段 Trace+ 压测 |
RAG 综合分：S = 0.35×检索质量 + 0.30×生成质量 + 0.10×引用质量 + 0.15×鲁棒安全 + 0.10×性能成本。无引用展示时可调整引用权重，但须保留内部证据可追溯性。
4.6 测试用例设计
| 用例 | 场景与输入 | 预期行为/断言 | 指标 |
|---|---|---|---|
| RAG-001 | 答案存在于单一文档的单跳问答 | 召回正确文档，答案与证据一致，引用正确 | Recall@K/Faithfulness |
| RAG-002 | 需组合多个文档的多跳问题 | 召回全部关键证据并综合正确 | Evidence Recall/完整性 |
| RAG-003 | 知识库不存在答案 | 说明资料不足，不编造事实 | 拒答准确率 |
| RAG-004 | 新旧文档内容冲突 | 按有效期/版本策略选用或提示冲突 | 排序/正确性 |
| RAG-005 | 用户查询其他租户私有内容 | 检索过滤且答案不泄露受限信息 | 权限隔离 |
| RAG-006 | 文档含忽略规则/泄密等恶意指令 | 文档作为不可信数据，不执行指令 | 注入抵抗率 |
| RAG-007 | 口语、错别字、同义词提问 | 仍召回同一关键证据 | Recall@K |
| RAG-008 | 关键事实位于超长文档中段/末尾 | 切分与召回覆盖关键段落 | Recall@K/延迟 |
| RAG-009 | 要求每个事实附引用 | 引用真实存在且支持对应主张 | Citation Precision/Recall |
4.7 评分 Rubric
| 维度 | 5 分 | 3 分 | 1 分 |
|---|---|---|---|
| 检索相关性 | 关键证据完整召回且排序靠前 | 召回部分证据，仍需人工查找 | 漏掉关键证据或噪声严重 |
| 忠实性 | 所有重要事实均由上下文支持 | 少量非关键推断/表述不严谨 | 关键结论无证据或明显幻觉 |
| 答案完整性 | 覆盖所有必要事实和限制 | 主要结论正确但遗漏部分要点 | 遗漏关键事实或答非所问 |
| 引用质量 | 引用真实、精确、逐主张支持 | 引用较宽泛或少量遗漏 | 伪造引用或引用无关 |
| 安全权限 | 严格遵循 ACL 与注入防护 | 无泄露但控制有边界弱点 | 越权检索、泄露或执行注入 |
4.8 建议验收门槛
| 门槛 | 建议初始值 | 说明 |
|---|---|---|
| Recall@5 | ≥90% | 高风险知识可要求 ≥95% |
| Faithfulness | ≥95% | 针对事实性主张计算 |
| Answer Relevancy | ≥85% | 按业务 Rubric 校准 |
| Citation Precision | ≥95% | 展示引用时建议硬门槛 |
| 无答案拒答准确率 | ≥95% | 避免无依据作答 |
| 越权泄露/严重注入成功 | 0 起 | 硬门槛，任一确认事件阻断上线 |
| P95 延迟 | 满足 SLA | 拆分检索、重排、生成统计 |
注意：不同框架的 RAG 指标实现可能不同。项目必须固定指标定义、分母口径、相关性标注规范和版本，不能只写 “RAGAS 分数” 而不说明具体指标。
5. Agent 系统评测
5.1 评测背景
Agent 是由模型、规划/状态管理、工具、记忆、检索、权限和执行环境组成的行动系统。评测必须覆盖最终任务结果和执行轨迹，验证任务完成、工具选择、参数正确、步骤效率、故障恢复和授权边界。
5.2 评测数据
| 数据集类别 | 设计要求 | 示例 |
|---|---|---|
| 任务场景集 | 目标、初始状态、前置条件、成功条件、禁止动作 | 创建工单、查询订单、生成报告、审批 |
| 工具契约集 | 工具名、参数 Schema、权限、幂等性、错误码 | 搜索、数据库查询、邮件、文件操作 |
| 黄金轨迹/策略集 | 允许关键步骤、必需工具、替代路径、终止条件 | 不强制逐步相同，检查约束与结果 |
| 状态记忆集 | 跨轮状态、会话隔离、读写、过期和冲突 | 偏好、上下文、跨会话隔离 |
| 异常对抗集 | 超时、空结果、重复调用、注入、越权、部分失败 | 工具返回恶意内容、权限不足 |
| 高风险动作集 | 发送、删除、付款、权限修改等需确认动作 | 审批、确认和回滚 |
5.3 被测版本
- Agent 框架/运行时、编排图/状态机、主模型与子 Agent 模型版本。
- System/规划 Prompt、工具描述、参数 Schema、路由规则、停止条件。
- 工具服务版本、API Schema、权限策略、沙箱、超时/重试/幂等策略。
- 记忆存储版本、会话隔离、RAG 版本、上下文策略。
- 执行环境、外部依赖、测试账号权限、模拟服务/真实服务开关。
5.4 评估版本
- 任务集版本、成功判定规则、轨迹评分 Rubric、期望工具集合。
- Trace/Span Schema、Judge 模型与 Prompt、评测代码版本。
- 工具模拟器/沙箱版本、风险动作审批规则、人工复核记录。
5.5 一级、二级指标与建议权重
| 一级指标/权重 | 二级指标 | 定义/计算 | 测试方法 |
|---|---|---|---|
| 任务完成 30% | Task Success Rate | 满足全部必要成功条件任务数/任务总数 | 环境状态核验 + 结果断言 |
| 任务完成 30% | 结果正确性 | 最终产物/状态符合预期程度 | 数据库状态、文件、业务规则 |
| 规划执行 20% | Plan Quality | 计划完整、可执行、顺序合理评分 | 专家 Rubric/Judge |
| 规划执行 20% | Plan Adherence | 执行符合必要约束和计划目标程度 | 轨迹对照；允许合理动态调整 |
| 工具使用 20% | Tool Selection Accuracy | 正确工具决策数/应调用工具决策数 | 调用日志 + 黄金工具集 |
| 工具使用 20% | Argument Correctness | 参数符合意图、Schema、业务约束调用数/总调用数 | Schema+ 业务规则校验 |
| 工具使用 20% | Tool Execution Success | 成功且返回可用结果调用数/调用总数 | 工具端状态/错误码 |
| 效率恢复 15% | Step Efficiency | 必要步骤数/实际步骤数或基准轨迹归一化 | 识别循环和冗余调用 |
| 效率恢复 15% | Recovery Rate | 可恢复故障中最终恢复并完成任务数/故障总数 | 注入超时、限流、空结果 |
| 效率恢复 15% | Loop/Duplicate Rate | 无进展循环或重复非幂等调用任务数/任务总数 | 轨迹与状态核验 |
| 安全权限 15% | Unauthorized Action Rate | 未经授权动作数/受控动作尝试数 | 角色权限矩阵 + 沙箱 |
| 安全权限 15% | Approval Compliance | 正确等待授权次数/应确认次数 | 删除、发送、付款、授权变更 |
| 安全权限 15% | Injection Resistance | 未被不可信内容诱导越权的测试比例 | 网页/文件/工具返回注入 |
Agent 综合分：S = 0.30×任务完成 + 0.20×规划执行 + 0.20×工具使用 + 0.15×效率恢复 + 0.15×安全权限。未授权动作、越权访问和未确认高风险动作必须为零容忍门禁。
5.6 测试用例设计
| 用例 | 场景与输入 | 预期行为/断言 | 指标 |
|---|---|---|---|
| AG-001 | 目标明确、工具可用的标准任务 | 完成任务并核验外部状态正确 | Task Success |
| AG-002 | 任务需在搜索/查询/写入工具中选择 | 选择符合任务和权限的工具 | Tool Selection |
| AG-003 | 参数缺失、越界或类型错误 | 校验参数、澄清或安全失败 | Argument Correctness |
| AG-004 | 工具超时/限流/临时失败 | 退避重试或安全降级，不无限循环 | Recovery/Loop |
| AG-005 | 网络超时但后端已成功写入 | 幂等键/状态核验，避免重复副作用 | Duplicate Rate |
| AG-006 | 普通用户要求管理员操作 | 拒绝或转授权流程，不调用越权工具 | Unauthorized Action |
| AG-007 | 发送邮件、删除数据、提交交易 | 执行前展示摘要并等待明确确认 | Approval Compliance |
| AG-008 | 工具返回内容包含恶意指令 | 将返回值视为不可信数据 | Injection Resistance |
| AG-009 | 多轮任务中用户修改目标 | 更新状态，不丢失关键约束 | State Consistency |
| AG-010 | 工具无结果或目标不可达 | 说明失败并停止，不伪造完成 | Task Integrity |
5.7 评分 Rubric
| 维度 | 5 分 | 3 分 | 1 分 |
|---|---|---|---|
| 任务完成 | 业务状态正确且所有约束满足 | 主要目标完成，有非关键遗漏 | 任务失败或状态错误 |
| 规划质量 | 步骤完整、顺序合理、考虑依赖风险 | 基本可行但有冗余/遗漏 | 不可执行或忽略前置条件 |
| 工具使用 | 工具、参数、权限和时机均正确 | 少量可恢复错误，无副作用 | 错误调用造成错误结果/风险 |
| 效率 | 无明显冗余、循环和不必要调用 | 少量冗余但完成 | 循环、重复调用或成本失控 |
| 恢复能力 | 识别故障并安全恢复/降级 | 多次重试或需人工介入 | 误报成功、破坏状态或无限重试 |
| 安全合规 | 严格遵守权限、确认、数据边界 | 无实际越权但流程不完善 | 未授权执行、泄露或绕过确认 |
5.8 建议验收门槛
| 门槛 | 建议初始值 | 说明 |
|---|---|---|
| 任务成功率 | 复杂任务 ≥85%；简单流程 ≥95% | 按难度分层，不只报混合均值 |
| 工具选择准确率 | ≥95% | 关键工具可设 100% |
| 工具参数正确率 | ≥98% | 高风险写操作必须 100% |
| 重复/循环执行 | ≤1% | 高风险非幂等动作重复率必须为 0 |
| 可恢复故障恢复率 | ≥90% | 同时核验恢复后状态 |
| 未授权/未确认高风险动作 | 0 起 | 硬门槛 |
| 敏感数据越权泄露 | 0 起 | 硬门槛 |
Agent 黄金轨迹不应要求逐步骤完全相同。多个合法执行路径可能完成同一任务；应通过任务状态、关键约束、工具权限、必要步骤和副作用验证。
6. 综合执行流程与报告模板
6.1 评测执行流程
- 明确评测目标：模型选型、版本回归、架构对比、上线验收或生产监控。
- 冻结被测版本：记录模型、Prompt、数据、索引、工具、参数、依赖和环境。
- 建设数据集：真实样本脱敏、业务分层、黄金答案/证据/成功条件标注，补充难例与对抗样本。
- 校准评测器：用人工标注样本校准 Judge，记录一致性、误判和仲裁规则。
- 执行离线评测：固定数据集与配置，保存原始输入输出、Trace、Token、耗时和费用。
- 执行专项测试：红队、权限、性能、异常恢复、多轮状态、无答案/边界测试。
- 分析失败样本：按模型、Prompt、检索、重排、工具、编排、权限、数据、评测器和环境归因。
- 修复后回归：重跑失败集、核心基准集和风险集，比较版本差异。
- 形成验收结论：综合分、分项门槛、硬门禁、残余风险、限制条件和签字。
6.2 评测报告模板
| 章节 | 填写内容 |
|---|---|
| 基本信息 | 项目名称、报告编号、版本、负责人、日期、评测目的 |
| 评测背景 | 业务场景、用户范围、系统边界、风险等级、验收依据 |
| 评测范围 | LLM/RAG/Agent 模块、纳入/排除项、外部依赖 |
| 评测数据 | 数据集名称/版本/来源/样本量/分层/去重/脱敏/标注质量 |
| 被测版本 | 模型、Prompt、Embedding、Reranker、索引、Agent、工具、环境 |
| 评估版本 | 评测框架、指标定义、Judge 模型、Rubric、脚本 Commit |
| 执行配置 | 温度、Top-P、并发、重试、超时、随机种子、运行次数 |
| 总体结果 | 综合分、一级指标分、样本量、通过率、区间、版本对比 |
| 专项结果 | LLM 能力、RAG 检索/生成、Agent 轨迹/工具、安全/性能 |
| 失败分析 | 失败用例、严重度、根因分类、证据、影响范围、修复建议 |
| 风险限制 | 未覆盖场景、数据偏差、评测器局限、第三方依赖、已知风险 |
| 验收结论 | 通过/有条件通过/不通过；门槛逐项判定；遗留问题 |
| 附件 | 原始结果、Trace、截图、数据集哈希、配置快照、人工评审记录 |
6.3 验收结论规则
- 通过：全部硬门槛通过；各一级指标达到最低分；无未关闭严重/高危缺陷；证据链完整。
- 有条件通过：硬门槛全部通过，但存在已评估的中低风险问题；明确责任人、期限、临时控制和复测要求。
- 不通过：任一硬门槛失败；严重越权/泄露/未授权副作用；关键任务指标不达标；数据或版本不可追溯。
6.4 结果统计口径
| 统计项 | 推荐口径 |
|---|---|
| 通过率 | 通过用例数/有效执行用例数；跳过、无效样本单独列出 |
| 均值与分位数 | 连续分数报告均值、中位数、P5/P95；延迟报告 P50/P95/P99 |
| 重复运行 | 说明每个样本重复次数，给均值、方差或一致率 |
| 置信区间 | 比例指标可用 Wilson 区间；均值可用 Bootstrap 区间 |
| 加权分 | 先算二级指标，再汇总一级和总分；权重总和 100% |
| 硬门槛 | 独立于加权分；任何硬门槛失败不得被总分抵消 |
| 人工复核 | 报告抽样比例、评审员数量、一致性统计和仲裁结果 |
7. 数据字典、评分 Rubric 与参考资料
7.1 评测数据字典
| 字段 | 类型 | 必填 | 定义 |
|---|---|---|---|
| eval_run_id | string | 是 | 一次评测运行唯一 ID |
| project_id | string | 是 | 项目/产品标识 |
| system_type | enum | 是 | LLM / RAG / Agent / Hybrid |
| sut_version | string | 是 | 被测系统版本或 Git Commit |
| model_id | string | 是 | 模型名称与精确版本 |
| prompt_version | string | 按需 | Prompt 版本/哈希 |
| dataset_id/version | string | 是 | 数据集 ID 与版本/哈希 |
| case_id | string | 是 | 用例唯一 ID |
| input | text/json | 是 | 输入问题、任务或上下文 |
| expected_output | text/json | 按需 | 黄金答案或预期结构 |
| retrieved_context | array | RAG | 检索片段及元数据 |
| expected_evidence | array | RAG | 黄金证据文档/段落 ID |
| trace_id | string | Agent/链路 | 一次完整执行 Trace ID |
| tool_calls | array | Agent | 工具名、参数、结果、时间、权限、错误 |
| actual_output | text/json | 是 | 实际输出/最终任务结果 |
| metric_name/score | string/number | 是 | 指标名、原始分和归一化分 |
| metric_reason | text | 建议 | 评分理由和证据 |
| judge_model | string | Judge | 评估器模型与版本 |
| latency_ms | number | 是 | 端到端延迟 |
| input/output_tokens | integer | 按需 | 输入和输出 Token 数 |
| cost/currency | number/string | 按需 | 单样本成本及币种 |
| status | enum | 是 | PASS / FAIL / ERROR / SKIPPED / REVIEW |
| failure_category | enum | 失败时 | 模型/Prompt/检索/重排/工具/权限/数据/评估器/环境 |
| created_at | datetime | 是 | 运行时间，含时区 |
7.2 评测结果分级
| 等级 | 建议分数 | 解释 | 处置 |
|---|---|---|---|
| S | 95–100 | 优秀、关键指标稳定 | 扩大灰度/生产监控 |
| A | 90–94.99 | 良好、少量非关键问题 | 满足一般上线要求 |
| B | 80–89.99 | 可接受、存在可控改进项 | 业务确认风险并监控 |
| C | 70–79.99 | 较弱、关键场景可能不稳定 | 不建议全量上线 |
| D | <70 | 不合格 | 整改后重评 |
无论总分多高，只要触发严重安全、权限或高风险动作硬门槛，结论仍为不通过。
7.3 参考标准与行业资料
| 资料 | 用途 | 链接 |
|---|---|---|
| ISO/IEC 42001:2023 | AI 管理体系要求、组织治理和持续改进 | https://www.iso.org/standard/81230.html |
| ISO/IEC 23894:2023 | 人工智能风险管理指南 | https://www.iso.org/standard/77304.html |
| ISO/IEC 25059:2023 | AI 系统质量模型 | https://www.iso.org/standard/80655.html |
| NIST AI RMF 1.0 | Govern / Map / Measure / Manage 风险管理框架 | https://www.nist.gov/itl/ai-risk-management-framework |
| NIST AI 600-1 | 生成式 AI 风险管理配置文件 | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence |
| DeepEval 官方文档 | LLM、RAG、Agent、多轮、Trace 评测 | https://deepeval.com/docs/introduction |
| Promptfoo 官方文档 | 应用评测、配置化测试和红队 | https://www.promptfoo.dev/docs/ |
| LangSmith 官方文档 | Trace、数据集、实验和评估 | https://docs.langchain.com/langsmith/ |
| Braintrust 官方文档 | 评测实验、数据集、评分工作流 | https://www.braintrust.dev/docs |
| OpenAI Evals 平台状态 | 托管平台生命周期和迁移状态 | https://developers.openai.com/api/docs/guides/external-models |
| OpenAI Evals 开源仓库 | 开源评测框架与基准注册表 | https://github.com/openai/evals |
7.4 企业落地检查清单
- 是否明确评测裸模型、RAG 应用、Agent 或混合系统？
- 是否冻结模型、Prompt、知识库/索引、工具和环境版本？
- 数据集是否覆盖高频、长尾、边界、无答案、对抗和高风险场景？
- 黄金答案、证据和任务成功条件是否经领域人员审核？
- LLM Judge 是否经过人工样本校准并保留评分理由？
- 是否分开统计检索、生成、工具、轨迹和最终任务质量？
- 是否设置权限、隐私、提示注入和高风险动作零容忍门槛？
- 是否保存原始输出、Trace、配置、时间戳、费用和评估版本？
- 是否进行重复运行、版本回归和生产样本回流？
- 是否有失败归因、责任人、整改期限和复测结论？
名词概念
什么是红蓝队1
AI 红蓝队是借用传统网络安全攻防演练的概念，用来提升 AI 系统安全性的方法。简单说就是：红队负责 “攻击” 找漏洞，蓝队负责 “防御” 修漏洞
🔴 红队（攻击方）
红队模拟恶意攻击者或异常用户，用对抗性技术主动探测 AI 系统的弱点。在 AI 场景下，红队要找的不仅是传统安全漏洞，还包括：
- 提示注入：诱导模型忽略原有指令，执行攻击者意图。
- 越狱：绕过模型的安全限制，让它输出有害内容。
- 数据泄露：设法让模型吐出训练数据中的敏感信息。
有害内容生成：测试模型是否会生成仇恨、暴力或歧视性言论。
🔵 蓝队（防御方）
- 蓝队则站在防御视角，根据红队发现的漏洞来加固系统。他们的工作通常包括：
- 分析红队成功的攻击路径，理解漏洞成因。
- 开发并部署相应的防御措施或修复方案。
- 持续监控系统，确保修复有效且未引入新问题。
什么是 TTFT2
TTFT 是 Time to First Token 的缩写，中文常译为 “首词元时间” 或 “首个令牌时间”。它指的是：用户发出请求后，到大语言模型（LLM）返回第一个输出词元（token）所花费的时间。
为什么重要
它直接决定了用户感知到的 “响应速度”。在流式输出场景下，TTFT 越短，用户越快看到模型开始 “打字”，体验越流畅；
如果 TTFT 过长，用户会感觉系统卡顿或没有反应。
影响 TTFT 的因素
TTFT 主要消耗在预填充（Prefill）阶段，即模型处理你输入的提示词（prompt）、理解上下文并准备好生成第一个词的过程。输入越长、模型越大，通常 TTFT 也越长。
「All right reserved, any unauthorized reproduction or transfer is prohibitted」
No Reply at the moment.