WebArena成功率指标

CH-20-04-025·约 18 分钟·AI评测与基准测试·更新 2026-08-12

如果你是一家外卖平台的考核主管，要决定一批新骑手能不能上岗，你会怎么做？大多数人会设计一场“路考”：给每位骑手发 10 张订单，每张订单写明要求——去哪家店取餐、几点前送到、需不需要签收。骑手跑完回来，你逐张判断“合格”或“不合格”，最后算出一个合格率。这个合格率，就是 WebArena 里“成功率指标”的核心思想。 WebArena 是一座由 4 个风格真实的网站构成的“虚拟城市”：线上购物、开源论坛、协作编程、内容管理系统。被测的 AI 智能体就像实习骑手，需要在网页上完成客服、下单、发帖、改文档等任务。成功率 = 圆满完成的任务数 ÷ 任务总数。但真正的考核远比按一个按钮复杂：什么样的结果才算“合格”？任务做了一半算几分？绕了远路要不要扣分？多考几天、取哪个数才公平？这篇文章就用“骑手实习考核”这条线，把这些细节一单接一单地讲清楚。

岗位关联

掌握成功率指标的完整设计逻辑，你就能看懂各类 Agent 基准测试报告，并在自己的评测体系中设计出科学、可信的量化指标。

可视化演示
成功率定义
任务分类
判定机制
部分完成
路径效率
统计策略
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示WebArena如何使用Docker容器化的真实网站环境评测AI Agent的网页交互能力，包括多网站组合任务和成功率指标。

本节配有交互动效（进入视口后自动加载，约 3KB）。

真实网站测试环境 Docker容器：每个网站独立隔离运行多网站组合：电商+论坛+CMS+GitLab Agent交互：导航、点击、输入、提交 Env = Docker(ECOM, FORUM, CMS, GIT) 真实网站环境提供端到端评测

成功率定义

考核主管的第一件事，不是发订单，而是把“合格”这两个字白纸黑字地写进制度里：顾客收到餐、餐品完整、没有超时，才算合格。只要有一项不满足，这张订单就是不合格。写清楚判定标准，后续所有统计才有意义。WebArena 的考核设计者做的第一件事，同样是定义任务与判定标准。

WebArena 原版评测集包含 812 个任务，分布在 4 个“虚拟站点”上：线上购物（Shopping）、开源论坛（Reddit）、软件协作平台（GitLab）、内容管理系统（CMS）。每个任务由三部分组成：起始状态、目标任务描述（相当于订单上的“顾客要求”）、以及用来判断任务是否成功的判定函数。智能体被要求只通过操作网页来完成这些任务，像骑手只通过骑车送餐一样。

成功率是一个二值加总的指标：每个任务只有成功（1）和失败（0）两个结果，不存在“半成功”。对所有任务的成功结果求和，再除以任务总数，就得到成功率：

在实际报告中，WebArena 的成功率通常按站点分别统计，再汇报总平均。这就像考核主管不仅看骑手总合格率，还会分别看“雨天合格率”“晚高峰合格率”——因为不同站点的任务难度差异很大，混在一起算会掩盖真实水平。理解了成功率这一张“成绩单”怎么算出来的，接下来要问的是：这些订单到底长什么样？

\displaystyle \text{SR} = \frac{1}{N}\sum_{i=1}^{N}\mathbb{1}[\text{pass}(x_i^{\text{final}}, g_i) = 1]

成功率 = 判定为成功的任务数 ÷ 任务总数。这个 0 到 1 之间的数字，就是智能体在整场“路考”中的合格率。

任务总数 N评测集中全部任务的个数，相当于考核表上的订单总量。
$\displaystyle N$
最终状态 x_final智能体操作结束后网页呈现的最终状态（页面内容、URL、数据记录等）。
$\displaystyle x_i^{\text{final}}$
判定函数 pass(·)根据最终状态与任务目标 g_i 输出 1 或 0 的裁判函数。
$\displaystyle \text{pass}(x_i^{\text{final}}, g_i) \in \{0, 1\}$
指示函数 \mathbb{1}[\cdot]当中括号内的条件成立时取 1，不成立取 0，把判定结果变成可累加的数字。
$\displaystyle \mathbb{1}[\text{pass}(\cdot) = 1]$

任务分类

外卖订单千差万别：有的是“去 A 店取一份无糖冰美式”，有的是“从超市代买 5 样商品”，还有的是“把文件送到前台并让前台签字”。骑手面对的每一种订单，验收方式都不一样。WebArena 的任务同样可以按“验收方式”分成几大类。

第一类是信息检索类任务，例如“查一下某件商品的价格”或“找到某位用户的主页链接”。这类任务像“口头回报”：骑手不需要把东西交给谁，只要回来说对信息即可，判定时看最终答案是否包含目标信息。第二类是操作执行类任务，例如“把商品加入购物车并完成结算”或“在论坛发布一个新帖子”。这类任务像“必须亲手交付”：光说不算，系统里必须真的发生状态变化。

第三类是内容生成类任务，例如“在评论区发表一段包含指定关键词的评论”或“在 CMS 里创建一篇标题为 Hello 的页面”。这类任务像“代写留言条”：最终产出的文本内容必须满足要求。第四类是组合任务，例如“预订一家价格最低且评分不低于 4.0 的酒店”，需要同时满足多个条件。组合任务的判定不是看某一条，而是看所有条件是否同时成立：

理解任务分类，是为了理解“什么才算合格”的不同形态——这自然引出一个关键问题：判定到底由谁来下、怎么下？是拿参考答案硬比，还是检查系统里真实发生了的变化？

\displaystyle \text{pass}_i = c_1(x_i) \land c_2(x_i) \land \cdots \land c_m(x_i)

一个组合任务只有当所有验收条件全部满足时才判成功，任何一条不满足，整单失败。

验收条件 c_j(·)任务的第 j 个验收条件，如“URL 正确”“页面包含关键词”“数据库记录已生成”。
$\displaystyle c_j(x_i) \in \{0, 1\}$
逻辑与 \land表示“并且”，所有条件必须同时为真。
$\displaystyle c_1 \land c_2 \land \cdots \land c_m$
合取结果 pass_i只有当全部条件都成立时结果才为 1，否则为 0。
$\displaystyle \text{pass}_i = 1 \iff \forall j,\; c_j(x_i) = 1$

判定机制

顾客验收外卖的方式各有不同：有的顾客拿着小票逐行对比，少一包蘸料都拒收；有的顾客当场拆开包装试用，东西能用就行；还有的订单争议太大，要请经验丰富的店长亲自鉴定。WebArena 的判定机制，正是这三种验收方式的写照。

第一种是精确匹配，相当于“对照小票打勾”：智能体最终产生的文本或 URL，需要与评测者预先写好的参考字符串完全一致，才能判成功。这种判定简单直接，但非常严格——表达方式稍有不同就可能判错。第二种是功能验证，相当于“当场开箱试用”：评测脚本检查网页的 DOM 状态、地址栏 URL、数据库记录或文件系统变化，确认操作是否真实生效。例如“发布帖子”这个任务，功能验证会检查帖子是否真的出现在站点上，而不是只看智能体说过什么。

第三种是人工判定，相当于“店长鉴定”：在 WebArena 的人工评估子集中，由人类评估者根据任务描述和智能体的完整操作轨迹给出二值评分。人工判定成本高，但能捕捉语义等价等自动判定容易漏掉的情况，因此常被用来校验自动判定的可靠性。对于需要“宽松匹配”的检索类任务，常用关键词覆盖率作为判定依据：

有了判定机制，骑手每张订单都能得到明确的“合格/不合格”。但对于失败的任务，我们还想知道：骑手到底完成了多少？是走到一半就放弃了，还是最后一步才出错？这就轮到“部分完成度”出场了。

\displaystyle \text{coverage}(x, r) = \frac{\text{命中参考关键词的个数}}{参考关键词总数}

覆盖率衡量智能体的输出覆盖了参考答案中的多少关键信息，覆盖比例越高，判定越接近成功。

参考关键词集合 r评测者预先写好的目标关键词，相当于验货清单。
$\displaystyle r = \{k_1, k_2, \dots, k_m\}$
命中个数智能体输出 x 中实际包含的参考关键词数量。
$\displaystyle |\{k \in r : k \in x\}|$
归一化覆盖命中个数除以关键词总数，得到 0 到 1 的覆盖率。
$\displaystyle \frac{\text{命中个数}}{m} \in [0, 1]$

部分完成

想象一位骑手接了一单“取餐并配送”的订单：他骑到了店门口、取了餐、也骑到了顾客楼下，结果发现忘带了收据，顾客拒收。这张订单按规则判为失败，但作为主管，你会觉得他和“出门就撞车”的骑手不一样——他完成了大部分环节。为了捕捉这种差异，考核表引入了一个额外指标：部分完成度。

部分完成度不改变“成功/失败”的最终判定，而是给失败任务打“过程分”，帮助我们分析失败发生在哪一环。具体做法是：把复杂任务像拆订单一样拆成 K 个子任务（里程碑），例如“打开正确页面”“填完表单”“点击提交”“出现确认页”；智能体每到达一个里程碑，就获得相应的部分得分。每个子任务按重要程度赋予权重，权重和为 1：

部分完成度是一把“诊断尺”：当智能体的成功率不高时，它能告诉我们失败是“压根没开始”还是“差最后一步”。但就算订单最后都送达了，还有一个维度的差异值得记录——有的骑手笔直一条路，有的骑手绕了三圈还闯了红灯。这个维度，叫路径效率。

\displaystyle \overline{P} = \frac{1}{N}\sum_{i=1}^{N}\sum_{j=1}^{K} w_j\, r_{ij}, \qquad \sum_{j=1}^{K} w_j = 1

部分完成度是先按子任务权重汇总单个任务的过程得分，再对所有任务求平均，反映智能体在失败任务中平均完成了多少进度。

子任务完成度 r_ij第 i 个任务中第 j 个子任务的完成比例，取值在 0 到 1 之间。
$\displaystyle r_{ij} \in [0, 1]$
子任务权重 w_j每个子任务对最终结果的相对重要性，所有子任务权重之和为 1。
$\displaystyle w_j \ge 0, \quad \sum_{j=1}^{K} w_j = 1$
单任务加权分数对一个任务内部的子任务完成度做加权求和。
$\displaystyle P_i = \sum_{j=1}^{K} w_j\, r_{ij}$
整体平均聚合对所有 N 个任务的过程得分再取平均，得到整体部分完成度。
$\displaystyle \overline{P} = \frac{1}{N}\sum_{i=1}^{N} P_i$

路径效率

两位骑手都准时把餐送到了，成功率上都是满分。但一个骑手只用 8 分钟抄近路直达，另一个骑手在城区里绕了 40 分钟，还因为走错路重复点了三次“确认送达”。作为主管，你会觉得第二位骑手虽然这单成功了，但效率堪忧，高峰期会拖垮整个团队。路径效率指标就是用来记录这种差异的。

路径效率衡量的是智能体完成任务的“操作成本”。WebArena 里，智能体的一步就是一次网页操作（点击、输入、跳转），完成同一个任务所需的最少步数叫最短步数，智能体实际执行的步数叫实际步数。实际步数越多，说明操作越冗余——重复点击、无效刷新、来回导航都是典型的冗余操作。同时，智能体的动作序列通常有步数上限，防止它陷入死循环。路径效率定义为最短步数与实际步数的比值：

成功率、部分完成度、路径效率，这三把尺子分别回答“能不能完成”“完成了多少”“完成得是否高效”。最后一个问题是：这些数字本身可信吗？骑手今天状态好、任务又简单，合格率会不会虚高？这就要靠统计策略来把关了。

\displaystyle \text{Eff} = \frac{1}{N}\sum_{i=1}^{N} \min\!\left(1, \frac{s_i^{\min}}{s_i^{\text{agent}}}\right)

路径效率越接近 1，说明智能体的操作越接近最优路径；绕路越多，效率得分越低，但成功率不会因此改变。

最短步数 s_min完成第 i 个任务理论上最少需要的操作步数。
$\displaystyle s_i^{\min}$
实际步数 s_agent智能体实际执行的操作总数，通常会设置一个最大步数上限。
$\displaystyle s_i^{\text{agent}} \le s_i^{\max}$
比值与上限截断当实际步数小于最短步数时比值超过 1，此时截断为 1，避免分数异常。
$\displaystyle \min\!\left(1, \frac{s_i^{\min}}{s_i^{\text{agent}}}\right)$
任务间平均对各任务的效率得分求平均，得到整体路径效率。
$\displaystyle \frac{1}{N}\sum_{i=1}^{N} \min\!\left(1, \frac{s_i^{\min}}{s_i^{\text{agent}}}\right)$

统计策略

假设骑手只考了一天，10 张订单全是附近的奶茶店，合格率高达 90%。可第二天换成远距离小区和写字楼，合格率立刻掉到 60%。作为主管，你会明白：单日单次的考核结果充满偶然性，不能只看一个数字就下结论。WebArena 的评测同样面临这个问题——大语言模型驱动的智能体带有随机性，同样的任务跑两次，结果可能不同。

为了让成功率统计可靠，评测者会采用一套统计策略。第一是多次运行：让智能体把整个任务集重复跑若干轮，报告平均成功率，而不是只跑一次。第二是固定随机种子：通过固定采样种子，让相同配置下的运行结果可以复现，便于团队之间对比。第三是报告置信区间：成功率本质上是二值结果的样本比例，其估计误差可以用置信区间来表达。当任务数 N 足够大时，95% 置信区间可用正态近似计算：

在对比两个智能体时，光看点估计还不够，还要看置信区间是否重叠、多次运行的结果是否稳定。这套方法也确保了不同团队、不同时间跑出来的成绩可以放在一起比较。至此，骑手考核的完整流程已经成型：定义合格 → 看清订单类型 → 确定验货方式 → 记录过程分 → 统计效率 → 评估偶然性。一张科学的智能体成绩单，就这样一单一单地打出来了。

\displaystyle \text{CI}_{95\%} = \hat{p} \pm 1.96\sqrt{\frac{\hat{p}(1-\hat{p})}{N}}

置信区间给出了真实成功率的大致波动范围。例如 N=100、\hat{p}=0.7 时，95% 置信区间约为 (0.61, 0.79)，说明真实水平大概率落在这个区间内。

点估计 \hat{p}样本成功率，即本评测中成功任务数 S 与总任务数 N 之比。
$\displaystyle \hat{p} = \frac{S}{N}$
标准误 SE伯努利比例的标准差估计，衡量 \hat{p} 的抽样波动幅度。
$\displaystyle \text{SE} = \sqrt{\frac{\hat{p}(1-\hat{p})}{N}}$
临界值 1.96标准正态分布下 95% 置信水平对应的双侧分位数。
$\displaystyle z_{0.975} = 1.96$
区间估计用点估计加减临界值与标准误的乘积，得到置信区间的上下界。
$\displaystyle \left[\hat{p} - 1.96\,\text{SE},\; \hat{p} + 1.96\,\text{SE}\right]$

AI 应用场景

智能体版本升级的回归门禁

阶段：模型迭代与质量保障

解决的问题：Agent 团队每天更新提示词、更换模型版本，人工回归成本高且容易漏掉旧任务的行为变化。用 WebArena 风格的成功率做自动化门禁，成功率显著下降时自动拦截发布。

具体案例：某网页操作智能体团队在每次发版前，跑 200 个取自购物与 CMS 站点的回归任务。平均成功率低于上一版本 2 个百分点即阻止合并，同时对失败任务计算部分完成度，快速定位是“检索环节”还是“操作环节”劣化。

RAG 系统的端到端任务评测

阶段：评测体系搭建

解决的问题：RAG 问答系统常用检索命中率、生成准确率等中间指标，但这些指标无法直接回答“用户问题是否真的被解决了”。把客户服务场景建模成网页任务，用成功率衡量端到端效果。

具体案例：将“在知识库中找到退款政策并回答用户”建模为人工客服任务，用功能验证判断最终回答是否包含退款条件与时效信息，用部分完成度区分失败发生在检索阶段还是生成阶段。

Agent 框架横向选型对比

阶段：基准测试与技术选型

解决的问题：市面上多个 Agent 框架各有宣传数据，缺乏统一、可信的对比口径。用同一评测集、同一统计策略横向对比，避免“各说各话”。

具体案例：评测组在 WebArena 的 4 个站点各选 50 个任务，每个框架重复运行 5 次，报告平均成功率与 95% 置信区间，同时附上路径效率，输出一份选型对比报告供技术负责人决策。

Python 演示

python87 行

# -*- coding: utf-8 -*-"""WebArena 风格成功率指标：模拟评测一个网页智能体。"""import random  class Task:    """一个网页任务：目标描述 + 验收关键词 + 理论最短步数。"""     def __init__(self, task_id, goal, keywords, min_steps):        self.task_id = task_id        self.goal = goal        self.keywords = keywords        self.min_steps = min_steps  class DummyAgent:    """模拟智能体：以 capability 概率成功，步数随随机性波动。"""     def __init__(self, name, capability):        self.name = name        self.capability = capability     def execute(self, task):        rnd = random.random()        if rnd < self.capability:            output = " ".join(task.keywords)        else:            output = task.keywords[0] if task.keywords else ""        steps = max(1, int(task.min_steps * (1 + rnd * 0.7)))        return {"output": output, "steps": steps}  def judge_pass(output, keywords):    """功能判定的简化版：所有验收关键词都出现在输出中才成功。"""    return all(kw in output for kw in keywords)  def partial_score(output, keywords):    """部分完成度：命中关键词占全部关键词的比例。"""    if not keywords:        return 0.0    hits = sum(1 for kw in keywords if kw in output)    return hits / len(keywords)  def path_efficiency(steps, min_steps):    """路径效率：最短步数 / 实际步数，比值上限截断为 1。"""    return min(1.0, min_steps / max(steps, 1))  def evaluate_once(agent, tasks):    """跑一轮评测，返回成功率、部分完成度、路径效率三个指标。"""    succ = 0    partial_sum = 0.0    eff_sum = 0.0    for task in tasks:        result = agent.execute(task)        if judge_pass(result["output"], task.keywords):            succ += 1        partial_sum += partial_score(result["output"], task.keywords)        eff_sum += path_efficiency(result["steps"], task.min_steps)    n = len(tasks)    return {        "success_rate": succ / n,        "partial_score": partial_sum / n,        "path_efficiency": eff_sum / n,    }  def main():    random.seed(42)    tasks = [        Task("T1", "在购物站购买一张周三的电影票", ["电影票", "订单号"], 3),        Task("T2", "在论坛发布标题为Hello的帖子", ["Hello", "发布"], 3),        Task("T3", "在CMS中把页面标题改为Q3营收", ["Q3营收", "页面"], 4),    ]    agents = [DummyAgent("AgentA", 0.7), DummyAgent("AgentB", 0.5)]    for agent in agents:        rows = [evaluate_once(agent, tasks) for _ in range(5)]        avg_sr = sum(r["success_rate"] for r in rows) / len(rows)        avg_pe = sum(r["path_efficiency"] for r in rows) / len(rows)        print("%s: 平均成功率=%.2f 平均路径效率=%.2f"              % (agent.name, avg_sr, avg_pe))  if __name__ == "__main__":    main()

目的：模拟一次 WebArena 风格的评测流程——用功能判定计算成功率，同时统计部分完成度与路径效率，并通过 5 轮运行对比两个智能体的平均表现。

random.seed(42)固定随机种子，让多次评测结果可复现，对应统计策略中的“随机种子”环节。
judge_pass` 中的 `all(kw in output for kw in keywords)实现“功能判定”：所有验收关键词必须全部出现在输出中才算成功。
partial_score` 里的 `hits / len(keywords)部分完成度定义为关键词命中比例，对应子任务进度的简化计算。
path_efficiency` 的 `min(1.0, min_steps / max(steps, 1))最短步数除以实际步数并截断到 1，防止效率分数异常超过上限。
evaluate_once` 循环中的 `succ / n一轮运行的成功率，即成功任务数与任务总数之比。
for _ in range(5)每台智能体评测 5 轮取平均，体现“多次运行”的统计策略。

常见误区

误区“WebArena 成功率从 70% 提到 75%，说明新模型全面超越了旧模型，一个数字就够了，不用看别的指标。”

正解成功率只回答“能不能完成”，不回答“完成得多好”。就像骑手 10 单全部合格，可能是因为 10 单都是顺路的奶茶店单。完整的评测结论要结合部分完成度、路径效率、站点分组和置信区间一起看。成功率提升 5 个百分点，可能只是把简单任务从“刚好失败”变成了“刚好成功”，需要进一步分析提升来源。

为何常见：二值成功率最简单直观，容易被媒体和汇报材料当作唯一卖点，导致人们养成了“只看一个数字”的习惯。

误区“智能体把这个任务完成了 80% 的步骤，那这个任务就算 0.8 个成功。整体成功率也按这种方式累加就行。”

正解部分完成度是“过程信号”，不是“结果信号”。预订酒店到最后一步提交失败，用户实际没有订到房间，这个任务就是失败。WebArena 的成功率按最终状态判定，严格二值；部分完成度只用于诊断失败发生在哪个环节，绝不能替代成功率。

为何常见：人类习惯用“完成比例”来理解做事的推进程度，容易把“过程进度”和“结果成败”混为一谈。

误区“智能体有随机性，多跑几次，取成绩最好的一次作为它的真实水平，这样才不埋没它的能力。”

正解取最大值会系统性高估能力——运气好的一次不能代表平均水平，就像骑手状态最好的一天不能代表日常表现。科学做法是报告多次运行的平均成功率，同时给出方差或置信区间，并固定随机种子保证可复现。如果确实想看上限，应单独标注“最佳成绩”而不是伪装成“真实水平”。

为何常见：竞赛选拔中“取最好成绩”是常见规则，这种直觉被错误迁移到了模型能力评估上。

误区“字符串完全一致才是硬标准，机器判定绝不会错，比功能验证和人工判定都更可靠。”

正解精确匹配对语义等价表达极不友好——“2024 年 3 月”和"March 2024"语义相同但字符串不同，会被误判为失败；它也无法验证操作在系统中是否真实生效。因此 WebArena 大量使用功能验证来检查 DOM 状态、数据库记录等真实变化，并保留人工判定子集来校验自动判定的质量。

为何常见：字符串比较实现简单、结论确定，容易让人把“客观一致”误解为“准确合理”。

面试题

Q1. WebArena 成功率指标的核心含义是什么？

单选题 · easy

A.智能体完成全部任务的耗时占比
B.智能体成功完成任务的占比← 正确答案
C.智能体所有动作的正确率
D.网页加载成功的比例

答案：B。成功率是 WebArena 中智能体成功完成的任务数占任务总数的比例，选项 B 正确。A 是时间效率，C 是动作级准确率，D 描述的是网页本身，都与成功率无关。

Q2. WebArena 任务判定中，检查“帖子是否真的发布在论坛上”属于哪种方式？

单选题 · easy

A.精确匹配与功能验证← 正确答案
B.人工访谈与问卷调查
C.代码覆盖率与内存分析
D.图像生成与语义分割

答案：A。检查发布结果是否真实生效，属于通过系统状态变化来判定的功能验证，因此选 A。B、C、D 描述的都不是 WebArena 的判定机制。

Q3. 某次评测 50 个任务成功 35 个，成功率是多少？

单选题 · easy

A.0.60
B.0.70← 正确答案
C.0.75
D.0.80

答案：B。成功率 = 成功任务数 ÷ 任务总数 = 35 ÷ 50 = 0.70，故选 B。其余选项对应错误的除法结果。

Q4. 关于部分完成度指标，下列说法正确的有哪些？

多选题 · mid

A.反映失败任务的完成进度← 正确答案
B.可替代成功率作为最终指标
C.通过子任务拆解量化← 正确答案
D.与路径效率含义相同

答案：AC。部分完成度通过把任务拆成子任务并加权打分，反映失败任务完成了多少进度，A 和 C 正确。它只是诊断工具，不能替代成功率，B 错误；它衡量进度，路径效率衡量操作成本，D 错误。

Q5. 路径效率得分的核心计算思想是什么？

单选题 · mid

A.实际步数除以最优步数
B.最优步数除以实际步数← 正确答案
C.成功任务数除以总任务数
D.检索命中数除以全部文档数

答案：B。路径效率 = 最短步数 ÷ 实际步数，越接近 1 越高效，故选 B。A 把分子分母搞反了；C 是成功率；D 是检索覆盖率。

Q6. 为了提高 WebArena 成功率估计的可靠性，正确做法有哪些？

多选题 · mid

A.多次运行取平均← 正确答案
B.固定随机种子复现← 正确答案
C.报告95%置信区间← 正确答案
D.只报告最高一次结果

答案：ABC。多次运行取平均、固定随机种子、报告置信区间都是标准的统计策略，A、B、C 正确。只报告最高一次结果会高估真实水平，D 错误。

Q7. 置信区间公式中系数 1.96 对应的置信水平与假设是什么？

单选题 · hard

A.90%置信水平，正态分布近似
B.95%置信水平，正态分布近似← 正确答案
C.99%置信水平，均匀分布近似
D.95%置信水平，指数分布近似

答案：B。1.96 是标准正态分布双侧 95% 置信水平的分位数，因此选 B。90% 对应约 1.645，99% 对应约 2.576，且假设是正态近似而非均匀或指数分布。

Q8. 下列哪类 WebArena 任务最适合用“功能验证”判定？

单选题 · mid

A.查找某商品的价格
B.在CMS发布一篇博文← 正确答案
C.计算一道数学题
D.翻译一段英文文本

答案：B。发布博文涉及系统状态的真实变化，适合用功能验证检查页面和数据库记录，选 B。A 适合用信息匹配判定，C、D 适合用内容精确匹配判定。

Q9. 精确匹配判定方式存在哪些局限？

多选题 · hard

A.忽略语义等价的不同表达← 正确答案
B.对格式差异过于敏感← 正确答案
C.无法验证操作真实生效← 正确答案
D.运行速度一定比人工慢

答案：ABC。精确匹配把“March 2024“和”2024 年 3 月”视为不同，对格式敏感，且只看文本无法确认操作在系统中是否生效，A、B、C 正确。自动匹配通常比人工快，D 错误。

Q10. 与正态近似相比，Bootstrap 方法估计成功率的置信区间时，最主要的优势是什么？

单选题 · extreme

A.不依赖大样本可精确估计
B.不依赖正态分布且适合小样本← 正确答案
C.一定比正态近似区间更窄
D.不需要生成任何随机数

答案：B。Bootstrap 通过对样本反复重采样来估计抽样分布，不依赖正态假设，适合任务数不多的小样本场景，故选 B。它并非不依赖样本量，也不保证区间更窄，且必须依赖随机重采样。