ATLAS-Bench：本地搜索智能体的工具使用新基准

本地搜索是LLM智能体支撑日常决策和长期计划的基础能力——它需要在给定时间和地点找到满足用户需求的地点。然而，现有基准对搜索结果是否满足硬性要求、是否考虑偏好、是否基于地点属性和评论做出事实与体验判断，覆盖都十分有限。近期发布的ATLAS-Bench试图填补这一空白。

为什么本地搜索需要专门的基准

本地搜索任务看似简单，实则包含多层判断：用户提出的条件里，有些是必须满足的硬性约束（如营业时间、无障碍设施），有些只是偏好（如“安静一点”）；有些是可验证的客观事实（如是否提供停车位），有些则依赖评论中的主观体验（如服务态度）。一个合格的智能体不仅要找到地点，还要区分这些条件、检索地点属性和评论、给出有证据支撑的推荐，或者在无解时明确报告“没有地点满足全部硬性要求”。

现有基准很少同时考察这几个维度，导致模型在真实场景中的表现难以被准确衡量。ATLAS-Bench的出发点正是把“约束满足”和“证据支撑”拆开评估。

硬性约束与偏好在本地搜索中对应约束满足问题（Constraint Satisfaction Problem, CSP）的两种处理方式。硬性约束是不可协商的布尔条件，例如“现在营业”“有轮椅通道”，任一条件不满足即视为推荐无效；偏好则是可权衡的软条件，例如“环境安静”“评分高”，通常以打分或排序方式处理。区分二者的意义在于评估口径：对硬约束应逐条核验通过率，对软约束则看排序质量。若模型把偏好误当硬约束，会过度过滤导致推荐覆盖率下降；反之把硬约束当偏好，则会给出实际不可用的地点。

基准构成：1,200条查询与三大区域

ATLAS-Bench包含横跨三个区域的1,200条查询，这些查询由平台上的真实搜索事件扩展而来，借助地点属性、评论和现有用户画像构造。每条查询都明确区分硬性要求与偏好、事实条件与主观判断，并附带支撑证据和逐条检查标准。

查询质量通过迭代式断言检查和跨模型评审来验证，避免出现歧义或不可判定的样本。这种构造方式让评估不只看最终推荐是否“看起来合理”，而是能逐条核对约束是否被满足。

ATLASBox：标准化评估环境

与基准配套的是ATLASBox，一个标准化评估环境，内置搜索工具和固定的兴趣点（POI）知识库。给定查询、时间戳和位置后，智能体需要检索地点属性和评论，推荐有证据支持的选项，或报告无地点满足全部硬性要求。

评估维度覆盖三个方面：答案质量、轨迹质量和执行成本。轨迹质量的引入意味着不仅看结果，也看智能体的搜索过程是否合理，这对工具使用类智能体的诊断尤为重要。

**轨迹质量（trajectory quality）**指智能体从接收查询到给出答案之间的一系列中间动作是否合理，包括工具调用顺序、检索参数是否切题、是否重复无效搜索、是否在证据不足时继续查证等。与只评判最终答案的端到端评估不同，轨迹评估能定位失败环节：是没检索到相关评论，还是检索到了却未正确使用。常用做法是将智能体动作序列与参考轨迹或规则化检查表比对，统计有效检索比例、冗余调用次数等指标，从而把“结果错”进一步区分为“过程错”与“判断错”。

14种配置下的模型表现

研究评估了11个模型的14种配置。结果显示，GPT-6-Luna在返回推荐中的约束满足率最高，达到71.5%，事实准确率为95.6%。但在“对可满足查询至少返回一个可接受推荐”这一指标上，它落后于GLM-5.3——后者为85.3%，GPT-6-Luna为67.3%。

这组对比揭示了一个核心矛盾：模型可以在单条推荐上做到较高的约束满足和事实准确，却可能在部分查询上干脆不给推荐，导致整体可用性下降。换句话说，严格满足个体要求与跨查询提供可用推荐之间存在张力，这正是本地搜索智能体面临的真实挑战。

约束满足率与推荐覆盖率是两个方向相反的指标。约束满足率衡量已返回推荐中满足全部硬性要求的比例，分母是推荐数；推荐覆盖率衡量可满足查询中至少给出一个可接受推荐的比例，分母是查询数。一个模型可以通过“只在对很有把握时才推荐”来拉高前者，但会牺牲后者，表现为大量查询无结果。因此二者需联合解读：高满足率加低覆盖率往往意味着过度保守，而高覆盖率加低满足率则意味着草率推荐。理想状态是在覆盖率接近上限的同时保持高满足率。

对智能体开发的启示

ATLAS-Bench的价值在于把评估焦点从“答案对不对”推进到“约束是否满足、证据是否充分、过程是否合理”。对于构建本地搜索类应用的团队，这意味着需要同时优化两件事：一是对硬性约束的严格校验能力，二是避免过度保守导致“宁可不说也不出错”的倾向。基准中答案质量、轨迹质量和执行成本的联合评估，也为工具调用策略的取舍提供了可量化的参照。