新网页游戏测试,网页游戏开测表

大模型集体“挂科”，全新中文网页检索测试：GPT-4o准确率仅6.2%

你以为大机型已经可以轻松“上网”了吗？

新的基准测试集BrowseComp-ZH直接打了主流AI的脸。

BrowseComp-ZH是港科大（广州）、北大、浙大、阿里、字节跳动、NIO等机构联合发布的全新基准测试集，集体失败了20多个国内外主流大型机型：

GPT-4o在测试中准确率仅6.2%；大多数国内/国际型号精度跌破10%；甚至是目前表现最好的OpenAI DeepResearch，也仅得42.9%。

目前，BrowseComp-ZH的所有数据已开源发布。

研究团队直言：

为什么我们需要中文网页能力测试？如今的大机型越来越擅长“使用工具”：可以连接搜索引擎、调用插件、“阅读网页”。

但很多评价工具只是建立在英文语境下，很少考虑中文语境、中文搜索引擎、中文平台生态。

然而，中国互联网信息碎片化严重，搜索条目多样，语言表达复杂。

驾驭中文网络世界有多难？举几个例子你就明白了：

信息碎片化，分散在百度百科、微博、地方政府网站、视频账号等多个平台。

常见的语言结构包含遗漏、暗示和隐喻，关键词搜索常常“偏离目标”。

搜索引擎本身质量良莠不齐，信息“下沉”或“丢失”的情况屡见不鲜。

因此，“翻译”英文测试集根本不够。

需要从中文语境原生设计，才能真正衡量大模型是否能在中文网页上“看得懂”、“搜得到”、“推得准”。BrowseComp-ZH是怎么炼成的？研究团队采用“逆向设计法”：从一个明确的、可验证的事实答案（如某种绘画流派、机构、影视剧标题）出发，反向构造出多个约束条件的复杂问题确保以下三点：

三大搜索引擎Baidu/Bing/Google无法在首屏直接命中答案

很多主流的大模型在搜索模式下都无法直接正确回答问题。

经人工验证，问题结构清晰，只有一个答案。

最终他们打造了289道高难度中文多跳检索题目，涵盖影视、艺术、医学、地理、历史、科技等11大领域。

大模型集体“翻车”？DeepResearch勉强破四成，绝大多数连10%都不到在BrowseComp-ZH的考验下，众多国内外主流大机型集体“翻车”：

尽管这些模型在对话理解和表达生成方面表现出了强大的实力，但在面对中文互联网上复杂的检索任务时，准确率普遍低得惊人：

大多数模型的准确率低于10%，只有少数可以超过20%。

OpenAI DeepResearch以42.9%排名第一，距离“及格”还很远

研究人员指出，这一结果表明：模型不仅需要会“查资料”，更要会“多跳推理”与“信息整合”可以真正在中文互联网上找到答案。

四大发现，揭示中文网页任务的“模型死角”1. 仅靠记忆不行，得真本事单纯依靠参数记忆（不搜索）的模型准确率往往低于10%，说明“记忆”是不可靠的。

2. 有推理的模型，表现更好DeepSeek-R1 (23.2%) 比14.5%DeepSeek-V3 (8.7%) 高。 Claude-3.7 也比Claude-3.5 高12.2%。推理能力成为一个关键变量。

3. 搜得多 搜得准，多轮策略才是王道人工智能搜索产品以多轮检索能力综合胜出：

深度研究：42.9%

豆袋深度搜索：26.0%

困惑研究模型：22.6%

相比之下，仅检索一次的模型（例如Kimi 和Yuanbao）的准确率低至个位数。

4. 搜索功能“翻车”？接入反而变差最典型的反例是DeepSeek-R1。开启搜索功能后，精度范围为23.2%断崖式跌至7.6%。

研究指出，该模型未能有效地将网页检索信息与现有知识结合起来，反而被误导。

数据集开放！欢迎模型开发者挑战BrowseComp-ZH的所有数据均已开源发布。

研究人员希望此次基准测试能够成为推动LLM在中文信息环境下实施的试金石，帮助打造真正“能用中文上网”的Agent。

接下来，他们计划扩大样本规模，扩展问答格式，对模型推理路径和失败案例进行深入分析。

论文地址：https://arxiv.org/abs/2504.19314

代码地址：https://github.com/PALIN2018/BrowseComp-ZH

Caddy对WASM压缩加速，测试Godot的Html5游戏

我尝试了网友的戈多游戏，还不错。我将其导出到html5：https://i.scwy.net/num_chomp/

但是Godot的导出比较大，包括游戏引擎运行的基础环境。这个H5导出后70多MB，一个wasm文件47MB。这对于网页来说有点灾难。

有网友谈到重新编译并导出模板以简化流程。我很懒，但我还有机会再试一次。

我使用Caddy 作为“服务提供者”。据AI介绍，它可以压缩WASM文件（据说高达80%）。浏览器支持边下载边流式解压并执行。所以我找到了启用此功能的方法。

原生Caddy不支持Brotli压缩，需要自己编译。

这里需要使用xcaddy，这是caddy专用的编译工具。

xcaddy 构建 使用github.com/ueffel/caddy-brotli

或

sudo apt install libbrotli-dev

CGO_ENABLED=1

xcaddy 构建 使用github.com/dunglas/caddy-cbrotli

后者调用官方C库，性能更好，但需要cgo支持。我用的是前者，毕竟只是一个小网站。

然后在配置文件中设置如下示例：

示例.com {

编码{

br 11 # Brotli 最高压缩级别

压缩包

minimum_length 1400 # 只压缩大于1400字节的文件

}

}

测试结果：确实有效！

但即便如此，仍然存在： 1、第一次加载可能需要刷新2、测试时加载时间超过1分钟（40MB）

在测试过程中，我们发现由于文件较大，传输一段时间后就会超时。于是继续修改Caddy配置文件：

{

服务器{

超时{

read_body 10m # 关键！上传大文件时，读取请求体的超时时间（默认15s）

read_header 10s # 读取请求头的超时时间（适当延长）

写10m#键！下载大文件时，向客户端写入响应的超时时间（默认30s）

idle 10m # 空闲连接保持时间（防止长期占用）

}

}

响应前先进行编码

}