WideSearch：评测LLM智能体广度信息搜集能力的基准测试集

1. 项目概述当AI智能体遇上“大海捞针”式信息搜集大家好我是Ryan在字节跳动Seed团队负责大模型智能体相关的研究与工程落地。今天想和大家深入聊聊我们最近开源的一个新玩意儿——WideSearch。如果你正在研究或应用LLM智能体Agent特别是那些需要从互联网上大规模、自动化搜集信息的场景比如市场竞品分析、舆情监控、学术文献普查那么这个项目很可能就是你一直在找的“标尺”和“试金石”。简单来说WideSearch是一个专门用于评测智能体“广度信息搜集”能力的基准测试集。我们团队在日常工作中发现很多真实世界的任务难点不在于问题的深度而在于其令人望而生畏的广度。想象一下老板让你整理出过去一年内所有A轮融资的AI初创公司名单及其核心产品或者你需要为一场行业会议搜集所有演讲嘉宾近三年的公开言论和背景资料。这类任务逻辑清晰但手动操作极其耗时、枯燥且易出错。这正是智能体可以大显身手的地方但问题也随之而来我们如何知道一个智能体完成这类“大海捞针”任务的好坏它找全了吗它找到的信息准确吗它会不会自己“编造”一些不存在的内容现有的主流评测集比如要求模型从一篇长文中找出特定事实的“DeepSearch”或者要求撰写深度分析报告的“DeepResearch”它们关注的是“找得深”或“写得好”。而WideSearch瞄准的则是“找得全”。它模拟的就是上面提到的那些场景给你一个宽泛的查询例如“列出所有在2024年发布了新款折叠屏手机的厂商及型号”要求智能体必须自主规划搜索策略、执行多次搜索、从海量网页中提取关键信息并最终汇总成一个结构化的列表。这其中的挑战截然不同幻觉编造不存在的信息、遗漏漏掉关键条目、信息冗余与去重成为了核心的失败模式。WideSearch就是为了系统性地暴露和度量这些失败而生的。2. 核心设计思路为什么“广度搜索”是块难啃的骨头在动手构建WideSearch之前我们花了大量时间拆解“广度信息搜集”这个任务本身。这不仅仅是把“深搜”任务的数量乘上100倍那么简单其内在逻辑和评价体系都发生了根本性变化。2.1 “宽”与“深”的本质区别我们可以用一个简单的类比来理解传统的“深搜”任务好比让你在一座结构清晰的图书馆里找到某一本特定书籍中关于“光合作用”的详细定义。你知道目标明确路径相对固定。而“广搜”任务则是让你跑遍全城所有书店、图书馆、报刊亭把市面上所有提到“新能源”这三个字的书籍、杂志、报纸的封面标题和出版社都记录下来。后者的核心矛盾从“精准定位”变成了“全面覆盖”和“高效遍历”。在技术实现上这带来了几个独特的挑战搜索策略的复杂性智能体不能只进行一次搜索。它需要像人类一样思考如何拆解问题。例如对于“折叠屏手机”任务一个聪明的策略可能是先搜索“2024 折叠屏手机 发布”得到一个初步厂商列表如华为、三星、小米然后针对每个厂商再搜索“华为 2024 折叠屏 型号”进行确认和补充。糟糕的策略会导致大量无效遍历或关键遗漏。信息提取与聚合的噪音网络信息鱼龙混杂。智能体需要从新闻稿、评测文章、电商页面、论坛帖子等不同来源中准确地提取出“厂商”和“型号”这两个关键实体并忽略那些重复的、模糊的如“某厂商即将发布”、或无关的信息如手机壳广告。评估的客观性难题我们如何判断智能体输出的“华为 Mate X5, 小米 MIX Fold 4, 三星 Galaxy Z Fold6”这个列表是完整和准确的我们需要一个尽可能客观的“标准答案”Ground Truth来对照。但网络信息瞬息万变今天的“标准答案”明天可能就过时了。因此构建一个稳定、可复现的评估集本身就是一大挑战。2.2 WideSearch的解题框架基于以上分析我们为WideSearch设计了核心的评测框架任务形式每个评测样本是一个(Query, Ground Truth List)对。Query是一个开放式的信息搜集指令Ground Truth List是一个经过人工严格校验的、结构化的信息项列表例如[{brand: 华为, model: Mate X5}, {brand: 小米, model: MIX Fold 4}, ...]。智能体工作流被测的智能体需要接收Query然后自主完成“规划 - 搜索 - 提取 - 汇总”的完整循环。它需要决定搜什么关键词、搜几次、如何解析网页、如何合并去重直到自己认为已经“找全了”或达到预设的停止条件如搜索次数上限。评估指标我们不再使用简单的准确率。针对“广度”特性我们引入了信息检索领域的经典指标并加以适配召回率 (Recall)智能体找到的条目中有多少是标准答案里有的这是衡量“找得全”的核心指标。召回率低说明漏了很多。精确率 (Precision)智能体找到的条目中有多少是正确且属于本任务的精确率低说明它掺入了很多无关或错误的信息。F1分数召回率和精确率的调和平均数是综合性能的体现。幻觉率 (Hallucination Rate)智能体输出的条目中有多少是“无中生有”、在标准答案和可信网络源中均不存在的这是衡量可靠性的关键。这个框架迫使智能体必须在“全面”和“准确”之间做出权衡而我们的评测集则能清晰地揭示出不同智能体架构或模型在这方面的能力差异。3. 数据集构建与评估细节解析构建一个高质量的评测集其工作量和技术含量不亚于设计算法本身。WideSearch数据集的构建过程本身就是一个如何定义和约束“广度搜索”任务的范例。3.1 数据收集与清洗确保“标准答案”的权威性我们首先需要定义任务的领域和范围。WideSearch V1.0 聚焦于几个信息更新相对有序、易于验证的领域消费电子手机、笔记本、影视娱乐电影、奖项、企业产品云服务、SaaS工具。选择这些领域是因为它们有较为权威的信息源如厂商官网、知名科技媒体、IMDb、官方奖项网站便于我们构建可靠的Ground Truth。构建一个样本的流程如下问题设计我们设计诸如“List all smartphones released by major manufacturers in 2024 with a periscope telephoto lens”这样的问题。问题必须具有明确的“可枚举”答案空间。人工搜集与验证由专业的标注员扮演“完美智能体”使用多种搜索关键词组合遍历主流信息源穷举所有符合条件的条目并记录下每个条目的权威出处链接。结构化整理将搜集到的信息转换为标准化的JSON格式形成最终的Ground Truth List。这个过程会进行多轮交叉校验以确保列表的完备性和准确性。对抗性过滤我们还会特意加入一些容易导致智能体混淆的“干扰项”。例如在搜索2024年手机时2023年底发布但年初仍在热销的机型是否算入我们会根据任务定义做出清晰界定并观察智能体能否理解这种时间边界。注意网络信息的动态性是我们面临的最大挑战。因此WideSearch数据集附带了一个“数据快照”版本包含了我们构建Ground Truth时参考的核心网页的静态存档以确保评测结果在不同时间点的可复现性。这对于学术研究至关重要。3.2 评估脚本的设计超越字符串匹配如果只是简单地将智能体的输出列表与标准答案列表进行字符串匹配那将非常脆弱且无法处理同义词、不同表述格式等问题。为此我们设计了一套更鲁棒的评估流程标准化处理对智能体输出的每个条目和标准答案的每个条目都进行统一的清洗如小写化、去除特殊符号、统一品牌别名等。基于大模型的模糊匹配对于清洗后仍不能精确匹配的条目我们会调用一个高性能的LLM如GPT-4作为“裁判”判断两个条目是否在语义上指向同一个实体。例如智能体输出“Apple iPhone 15 Pro”标准答案是“iPhone 15 Pro (Apple)”裁判模型应能判断为匹配。证据追溯与幻觉判定我们要求智能体在输出每个条目时最好能附带其信息来源的URL或摘要。评估时我们会检查该证据是否真实支持该条目。如果智能体输出了一个条目但无法提供有效证据或证据内容与条目不符则这个条目会被标记为“疑似幻觉”并结合人工抽查进行最终判定。这套评估机制虽然计算成本更高但能极大地提升评测的公平性和准确性尤其是对于开放式生成任务。4. 实战如何让你的智能体在WideSearch上跑起来看完了设计理念我们来点实际的。如何利用WideSearch来评测或提升你自己的智能体下面我将结合代码库带你走一遍核心流程并分享一些我们趟过的坑。4.1 环境搭建与配置要点首先把项目克隆到本地并准备好Python环境。我们强烈建议使用虚拟环境。git clone https://github.com/ByteDance-Seed/WideSearch.git cd WideSearch # 使用我们提供的脚本安装依赖它已经处理好了版本兼容性问题 sh prepare-env.sh # 激活虚拟环境 source .venv/bin/activateprepare-env.sh脚本主要做了三件事1) 创建Python虚拟环境2) 安装torch及其对应的CUDA版本如果你有GPU3) 安装其他必要的包如langchain,openai,playwright用于网页自动化等。实操心得playwright的安装可能需要单独处理浏览器驱动。如果脚本运行后网页工具仍报错可以尝试在虚拟环境中手动运行playwright install chromium。另外网络环境可能导致某些包下载缓慢建议配置好pip镜像源。4.2 核心改造点实现你的搜索工具WideSearch框架将“搜索”和“解析网页”抽象成了工具Tool这是你需要对接的核心。代码位于src/agent/tools.py。框架预置了一个SimpleSearchTool的接口但你需要根据自己可用的搜索API来实现它。例如你可以接入Serper API、Google Search API或者如果你有相关权限可以使用Bing Search API。# 你需要实现类似这样的一个类 class MyCustomSearchTool(BaseTool): name web_search description Searches the web for current information. Input should be a search query string. def _run(self, query: str) - str: 实际调用搜索API并返回格式化文本的逻辑 # 1. 调用你的搜索API (例如: requests.get(https://api.serper.dev/search, params{q: query})) # 2. 从API返回的JSON中提取前N个结果的标题、链接和摘要snippet # 3. 将这些信息格式化成一段清晰的文本供LLM阅读和分析 formatted_results fSearch results for {query}:\n for i, result in enumerate(search_results): formatted_results f{i1}. [{result[title]}]({result[link]})\n{result[snippet]}\n\n return formatted_results为什么返回格式化文本而不是结构化数据这是为了最大化通用性。不同的LLM对于结构化JSON的阅读理解能力差异很大而纯文本格式是最稳妥的。我们的经验是将标题、链接和摘要用清晰的标记如[标题](链接)和换行分隔能让大多数LLM很好地提取关键信息。4.3 配置模型与运行评测接下来在src/utils/config.py中配置你要测试的LLM。框架支持OpenAI API格式的兼容接口。# 在config.py中你可以定义多个模型配置 MODEL_CONFIGS { gpt-4o: { api_base: https://api.openai.com/v1, # 或你的代理地址 api_key: your-api-key-here, model_name: gpt-4o, temperature: 0.1, # 广度搜索任务要求低随机性高确定性 request_timeout: 60, }, your-local-llm: { api_base: http://localhost:8000/v1, # 例如使用Ollama或vLLM搭建的本地服务 api_key: EMPTY, model_name: qwen2.5-7b-instruct, temperature: 0.1, } }配置完成后就可以运行主评测脚本了。我们提供了一个批处理脚本可以高效地跑多个测试样本。python3 scripts/run_infer_and_eval_batching.py \ --trial_num3 \ # 每个样本运行几次取平均以消除随机性 --model_config_namegpt-4o \ # 使用上面配置的模型 --response_root./results/responses \ # 原始回答保存路径 --result_save_root./results/evaluation \ # 评估结果保存路径 --stageboth # 同时执行推理和评估脚本会遍历WideSearch数据集中的所有问题让智能体逐一解答并将输出结果与标准答案进行比对最终生成一份包含Recall、Precision、F1、Hallucination Rate等指标的详细报告通常是CSV和JSON格式。5. 实验结果分析与典型问题排查在我们内部的测试中即使是当前顶尖的模型和智能体框架在WideSearch任务上也远未达到完美。以下是一些共性的发现和问题以及相应的调试思路。5.1 实验结果揭示的智能体短板从我们已公开的测试结果见项目README中的图表可以看出一些趋势召回率是普遍瓶颈大多数智能体只能找到60%-80%的标准答案条目。漏掉的原因往往是搜索策略不够“广”没有尝试足够多的关键词变体或者在遍历列表时过早停止。幻觉依然存在即使在温度参数调低的情况下仍有约5%-15%的输出条目属于幻觉。这些幻觉常常是“合理的错误”比如混淆了相似的产品型号或将概念产品当作已发布产品。多智能体协作未必更优我们尝试了让一个“规划智能体”指挥多个“搜索-提取智能体”并行工作的模式。理论上这能扩大搜索覆盖面但实践中带来了更高的协调开销和信息整合难度其综合表现F1有时反而不如一个设计精良的单智能体。5.2 常见问题与调试指南在你自己运行WideSearch时可能会遇到以下问题问题1智能体陷入搜索循环长时间不停止。原因停止条件Stop Condition设置不合理。例如智能体设定“直到连续3次搜索没有新发现为止”但网络搜索存在波动可能某次搜索结果恰好没新东西但下次又有。解决修改智能体的规划逻辑。采用更保守的停止策略比如“针对查询Q执行固定5轮不同关键词的搜索后无论有无新发现都停止汇总”。也可以在配置中强制设置最大搜索次数上限。问题2精确率极低输出大量无关信息。原因信息提取Information Extraction工具或提示词Prompt不够精准。LLM从搜索结果片段中提取实体时把背景介绍、广告信息都抓了进来。解决强化提取步骤的指令。在Prompt中明确要求“请严格从提供的文本中提取符合‘品牌’和‘型号’格式的具体产品名称。忽略任何猜测性、未来时态如‘即将发布’或模糊的描述。”进阶方案实现一个专门的“过滤工具”。在提取后增加一个校验步骤让另一个LLM实例或规则判断提取出的条目是否确实是一个具体的、已存在的产品。问题3评估分数与人工判断不符。原因可能是标准化处理或模糊匹配环节出了问题。例如品牌“Apple”被标准化为“apple”但型号“iPhone 15 Pro”和“iPhone15 Pro”因空格问题被算作不同条目。解决检查src/evaluation/目录下的评估脚本。可以尝试调整文本清洗的正则表达式规则或者审查“裁判模型”的判定Prompt是否足够清晰。最好的方法是人工抽查一批被判定为“不匹配”的条目对看看问题出在哪里。问题4运行速度非常慢。原因这是广度搜索任务的天然特性。每个问题可能触发多次网络搜索和LLM调用串行执行耗时很长。解决利用好run_infer_and_eval_batching.py脚本的批处理能力。它内部已经实现了一定程度的并行化。此外可以考虑使用更快的LLM API端点。对搜索工具进行缓存避免对相同关键词的重复请求。如果测试集很大可以分批运行并使用--stage参数分别执行推理和评估。6. 超越评测将WideSearch思想融入实际产品WideSearch不仅仅是一个学术评测集。它的设计理念和发现可以直接指导我们构建更实用的信息搜集型智能体产品。这里分享几个我们正在尝试的方向1. 混合搜索策略引擎单一的搜索策略很难通吃所有任务。我们正在开发一个策略选择器根据查询的模糊程度、预期答案数量级等因素动态选择搜索策略。例如精确列举型如“列出Python 3.12的新特性”使用官方文档、百科类站点作为优先源。开放搜集型如“搜集用户对某产品的负面评价”需要更广的爬取和基于情感分析的过滤。 WideSearch中的不同任务类别正好可以用来训练和评估这个策略选择器。2. 实时可信度验证模块针对幻觉问题我们在智能体的输出流水线中增加了一个“实时验证”步骤。当智能体提取出一个信息条目时会立即用该条目作为关键词进行一次快速的“反向搜索”检查是否有高权威源直接证实该信息。如果没有则对该条目打上低可信度标签或在最终输出中予以备注。这个模块的阈值调节就可以利用WideSearch的幻觉率指标来优化。3. 人机协同的迭代搜集模式完全自主的智能体在复杂任务上仍有局限。我们探索的模式是智能体先进行首轮广搜输出一个初步的、附带置信度的列表。人类专家可以快速浏览这个列表进行“去伪”删除幻觉和“补漏”补充几个智能体遗漏的关键词。然后智能体基于人类的反馈启动第二轮更精准的搜索。WideSearch可以用来评估这种模式下智能体需要多少轮次或多少人类反馈就能达到接近完美的召回率。构建一个真正可靠的广度信息搜集智能体我们还有很长的路要走。WideSearch是我们迈出的第一步它像一面镜子清晰地照出了当前技术的优势与边界。希望这个开源项目不仅能帮助社区公平地比较不同模型和框架更能激发大家对于“如何让AI更可靠地处理大规模、开放性任务”这一核心问题的更多思考与创新。