美团 LoHoSearch 搜索 Agent 评测：544 道题、61 次工具调用与真实成本
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
核对日期：2026-07-28。
先看关键数字
762 万个 Wikipedia 实体、2.65 亿条有向边、544 道人工核验题、11 个领域；75.5% 直接通过人工复核，22.3% 微调后接受，2.2% 丢弃。官方报告 GPT-5.5 为 34.74%；DeepSeek-V4-Flash 在 LoHoSearch 为 10.02%，正确轨迹平均工具调用从 BrowseComp 的 35 次升到 61 次。
这类基准最有价值的地方，不是再造一张总榜，而是把任务拉长以后，暴露模型在搜索、记忆、规划、导航和工具调用上的断点。分数来自发布方给定的环境和配置，适合用来决定是否值得复测，不适合直接替代你自己的任务验收。
它到底测了什么
公开结果至少要拆成四层看：题目或环境怎样构造、允许模型调用什么工具、一次任务能走多少步、最后如何判分。只比较最终百分比，会漏掉调用次数、重试、延迟和外部搜索费用。对生产团队来说，同样的准确率，如果一个方案要 60 次工具调用，另一个只要 20 次，预算和故障面完全不同。
544 道题是怎么来的
LoHoSearch 不是让模型随手编冷知识。团队先把英文 Wikipedia 页面当成实体，把正文链接当成有向边，再用 Wikidata P31 类型补充类别。随后从图中采样树结构和带交叉约束的图结构：树结构扩大候选空间，图结构再加入环形依赖与多条件咬合。自然语言问题生成后，还要经过自动验证、搜索 Agent 验证、去除多答案和易答题，最后人工复核。
这套流程解决了人工出题的一个老问题：出题人通常从自己知道的实体开始，很难精确控制“有多少候选”和“需要满足多少关系”。知识图谱可以直接量化搜索空间和结构复杂度。但自动造题也不是天然可靠，2.2% 严重问题被丢弃、22.3% 需要人工修改，说明人工复核仍然是数据质量的一部分。
34.74% 和 10.02% 应该怎么读
官方披露中，GPT-5.5 在 LoHoSearch 为 34.74%。DeepSeek-V4-Flash 从 BrowseComp 的 58.84% 降到 10.02%；图结构题只有 8.01%，树结构题为 11.89%。这说明模型并非完全不会搜索，而是在候选空间扩大、条件互相约束后更容易丢失中间证据。
重复采样能提高找到正确答案的概率：DeepSeek-V4-Flash 的 pass@N 从 N=1 的 9.3% 升到 N=16 的 38.3%。但真正选出最终答案的 best-of-N 只有 24.6%，远低于 pass@16 上界。模型偶尔能找到正确答案，却不总能识别哪一次才是正确的，这会把验证器和聚合器变成系统成本的一部分。
长程搜索首先是系统问题
正确轨迹平均工具调用从 35 次增到 61 次，中位数从 26 次增到 59 次。更多调用意味着更多页面失效、限流、重复内容、上下文压缩和账单波动。Discard-all + Verify 把 10.02% 提高到 16.82%，绝对提升 6.8 个百分点；同类策略在 BrowseComp 上能提升约 14 个百分点。简单摘要或清空上下文，解决不了长链条里“哪条证据支持哪个条件”的对应关系。
内部评测因此要单独记录搜索预算。建议至少保存：每题总调用数、唯一域名数、重复访问比例、最终引用可访问率、证据冲突数、输入输出 token、重试与墙钟时间。准确率上升 3 个点，如果换来三倍调用和两倍延迟，不一定值得上线。
怎么把公开结果变成自己的测试
先挑 20 到 60 个已有标准答案的任务，按单步、多步、冲突信息分层。锁定模型版本、工具、最大步数和预算，保存完整轨迹。除了成功率，还记录错误动作、无效搜索、引用是否可打开、恢复次数、耗时和总费用。公开榜单只能帮助选候选，是否上线仍由这组任务决定。
实际案例
一家 12 人研究团队每周做 40 次供应商尽调。先抽 60 个已有标准答案的问题，分成单条件、三条件和带冲突来源三组。每次记录网页请求数、搜索调用数、有效引用率、总耗时与模型费用。通过线是答案准确率不低于 80%、每个关键结论至少一条可打开来源、95 分位耗时低于 8 分钟。连续两轮出现来源打不开、循环搜索或成本超过人工基线 1.5 倍，就暂停自动化。
读结果时最容易犯的错
- 把发布方成绩写成独立复现。
- 把模型名称相同视为推理配置完全相同。
- 只看成功率，不看调用数、失败轨迹和成本。
- 用静态问答成绩推断动态环境里的持续行动能力。
- 在来源、版本或运行参数缺失时仍做采购结论。