Spatial AI 准确性评估

Spatial AI 准确性衡量一个位置感知系统是否能正确理解请求、识别正确地点、使用经过授权且最新的数据、正确计算地理关系、只对符合条件的选项进行排序、解释证据，并且只执行有效操作。即使回答非常流畅，也仍然可能把用户带到错误的门店。单一模型分数无法揭示这些问题。因此，benchmark 必须在进入生产环境之前，直接测试产品承诺完成的实际任务。

下面的内容会分别讨论决策链、一个平均分可能掩盖的各类 gate、值得预先构建的失败案例，以及研究 benchmark 与产品评估之间的边界。相关内容包括基于业务数据进行 Grounding 的 Spatial AI和企业 Spatial AI 试点。在某些情况下，正确地拒绝回答，比给出一个看似合理的推荐更准确。

Spatial AI 准确性评估要点

• 对整条链路评分： 意图、grounding、资格判断、空间计算、排序、解释、操作和结果。
• 在模型之外核验事实： 地点身份、营业时间、库存、权限和路线都应由权威系统提供。
• 纳入困难案例： 模糊请求、过时数据、未授权请求，以及有意设计为无解的请求。
• 各 gate 分开判断： 低风险层的高分不能抵消权限失败。
• 与实际任务绑定： 离线测试案例和生产结果回答的是不同问题，两者都需要。

Spatial AI 准确性是什么意思？

客户可能会问：回家路线附近，哪家门店还有某件商品，而且在自己到达时仍然营业？这一句话里包含多个彼此独立的问题：用户真正想要什么、哪些门店实际存在、库存是否最新、营业时间是否覆盖到达时间、路线实际上能到达哪些分店、哪些业务规则会排除候选项，以及剩余候选项应该如何排序和解释。最后一句话表达得再流畅，也不能证明每个步骤都正确。评估必须拆分这些层，因为地点解析错误并不能靠重写 ranking prompt 修复，过期库存源也不能靠更换语言模型解决。

按顺序测试整条链路：理解约束、验证数据源、移除无效选项、计算地理关系、对剩余候选项排序、用证据解释结果、仅在允许时执行操作，并衡量任务是否完成。

为什么一个总分还不够？

整体百分比很容易比较，也很容易被误用。一个示意 scorecard 可能显示总体准确率为 92%，但意图识别是 99%、路由是 98%、解释是 96%，授权却只有 75%。这些数字只是示例，并不是 Kaleidr 的结果。平均值仍然看起来很高，但系统却可能暴露用户不应访问的数据，或基于这些数据执行操作。关键维度需要各自独立的生产 gate。低风险任务上的优秀表现，不能抵消权限失败、无效目的地、不支持的操作或虚构的可用性。

高总体分数可能掩盖一个薄弱 gate。图中的百分比只是示意，不代表 Kaleidr 的实测表现。

NIST 的 AI Risk Management Framework playbook 指出，测量应从最重要的风险开始，同时也应记录哪些风险不会被测量。同一页面还说明 AI RMF 1.0 正在更新，playbook 之后也会随之修订 (NIST, 2026)。NIST 的 TEVV-Athlon framework 初始公开草案 NIST AI 200-2 于 2026 年 8 月 7 日发布，并开放意见征集至 2026 年 10 月 6 日。该框架把评估描述为证明一个系统是否达到个人或组织目标的证据，并要求根据实际需求定制测量方式，包括现实世界中的影响 (NIST, 2026)。这是一份征求意见的草案，并不是 Kaleidr 的控制清单。对于位置感知产品，真正相关的上下文是产品实际做出的地理决策。

应该如何测试意图、地点和资格？

首先是意图。用户要求在酒店和场馆之间找一家无障碍咖啡店，而且需要在早上 7 点前营业，这并不等于“酒店附近的咖啡店”。对于每个测试查询，都应保存预期的结构化理解：类别、地理关系、起点、终点、无障碍要求和时间。然后测量系统提取了哪些约束、凭空增加了哪些约束，以及遗漏了哪些约束。如果系统识别出类别，却忽略时间窗口，就不能算正确理解了任务。

地点语言本身具有歧义。Springfield、Terminal 2、Main Street，以及“我们的 Austin 门店”，都可能对应不止一个实体。测试集中应包含同名城市、相同分店名称、多个航站楼、改名地点、缩写、多语言名称、没有明确边界的街区，以及位于行政边界上的地址。评分应基于 canonical place ID，而不是名称字符串匹配。选错了相隔一个街区的咖啡店，以及选到了另一个城市的目的地，两者都是错误，但严重程度并不相同。

资格判断回答的是“这个地点是否可以作为候选项”。排序回答的是“一个有效地点应该排多高”。一个门店即使是最近的 pin，也可能已经关门、缺货、位于服务范围外、完全约满，或者因政策原因不能推荐。这些候选项应该先从集合里移除，再对剩余候选项排序。资格 precision 等于返回的合格地点数除以所有返回地点数。在高风险 workflow 中，少量不合格推荐带来的影响可能比平均排序质量更重要。库存、营业时间、权限和政策继续由拥有这些数据的系统管理。基于业务数据进行 Grounding 的 Spatial AI也为产品本身划定了相同边界。

先过滤资格条件。最近的地点并不自动等于有效地点。

应该如何检查地理计算和数据新鲜度？

如果空间引擎能够计算某个值，就不应该让语言模型成为该计算的 source of truth。point-in-polygon、路线距离、行程时间、是否位于服务区域内、空间包含关系，以及沿路线的顺序都属于这一类。应通过权威地理数据和可信工具生成预期答案，再将应用结果与该答案比较。“这个点是否位于这个多边形内？”以及“系统是否返回 branch ID 172？”这类问题适合精确匹配。坐标、预计行程时间和不同分辨率绘制的边界，则适合使用预先声明的容差。不要在测试结束后才决定，一个错误结果“已经足够接近”。

新鲜度是一个不同于历史正确性的问题。坐标和门店身份可能相对稳定，但营业时间、库存、交通和临时关闭会不断变化。应跟踪多少决策使用了超出新鲜度阈值的数据，以及多少时间敏感字段具有已知更新时间。缺失数据并不等于“不可用”。如果状态未知，系统却自信地回答“是”或“否”，即使地点本身真实存在，也属于失败。

什么时候“没有结果”才是准确答案？

客户可能会要求寻找一个 10 分钟内可达、并且晚上 9 点后仍有某件商品的地点，但实际上并不存在这样的地点。较弱的系统会静默放宽约束，然后返回一个 20 分钟外的门店。grounded 系统则会明确说明，没有任何经过验证的选项满足所有条件。benchmark 应包括有意设计为无解的任务，并分别跟踪正确返回“没有结果”的比例，以及错误推荐率。2025 年的 GeoBenchX 是一个针对工具调用 agent 的多步骤地理空间 benchmark，同时包含可解和有意无解的任务，从而能够测量拒绝准确性 (Krechetova and Kochedykov, 2025)。该论文评估的是研究型 agent。GeoBenchX 并不对 Kaleidr 评分，产品团队仍然需要为自己的任务设计专属的无解案例。

有时，“没有有效结果”本身就是正确答案。返回超出指定时间或距离的地点，是错误推荐，而不是有帮助的 fallback。

应该如何对排序、解释和操作评分？

先移除无效候选项，再进行排序。最近并不自动等于最佳。如果产品这样定义目标，行程时间、路线偏离、可用性、无障碍条件、价格、营业时间窗口和业务优先级都可以纳入目标函数。常用指标包括：第一名结果有多大比例可接受、前 K 个结果中有多大比例至少包含一个可接受选项、与人工审核或政策排序的一致程度，以及相对于已知最佳合格选项的 regret。不要把 engagement 当作排序质量。排序应该与客户最终需要执行的实际操作连接起来。

比如“营业到晚上 10 点、商品有货、会让路线多 6 分钟”这样的解释，只有在每一个陈述都能追溯到系统实际使用过的证据时才算准确。应核验地点身份、库存可用性、营业时间、是否真的计算了路线，以及文本是否与排序决策一致。文字写得很漂亮，也仍然可能是错的；简短而不够流畅的表达，也可能是对的。可以衡量解释中经过验证的事实陈述占全部事实陈述的比例。

操作本身也是答案的一部分。移动地图、添加 marker、请求路线、更改 filter、开始预订，这些操作即使对应的文字回答正确，也可能执行错误。应跟踪该操作是否属于应用允许的 action vocabulary、目标与参数是否正确，以及用户是否有权执行。正确的文本搭配错误的地图操作，仍然是一次失败交互。

benchmark 中应包含哪些失败案例？

如果测试集只包含团队已经知道如何解决的干净样例，就会高估可靠性。应纳入：模糊名称、重复分店、位于服务区域边缘的地址、无解请求、刚刚关闭的门店、与地点不匹配的库存、距离很近但会让路线大幅绕行的 pin、到达前就关门的营业时间、用户无权查看的私有设施、与英文名称不同的本地名称、未知营业时间、与 first-party 数据冲突的公共来源、试图操纵模型的检索文本，以及不可用的 routing 或业务数据服务。目标是重现生产环境中真正会遇到的决策。

试图操纵模型的检索文本属于 prompt injection 案例。OWASP 将 LLM01:2025 Prompt Injection 描述为用户输入或检索输入以非预期方式改变模型行为的情况，包括对关键决策产生影响，并指出 retrieval-augmented generation 并不能完全消除这一弱点 (OWASP, 2025)。这类案例应与权限问题一起归入测试集的安全类别，而不是等到后面再作为安全附录补充。

贴近生产的测试案例应覆盖地理歧义、运营状态、系统行为和安全。缺少这些案例的 benchmark 会高估可靠性。

为什么必须在运行前定义 ground truth？

每个测试案例都需要记录足够多的真实信息，以明确“正确”到底意味着什么：查询、用户上下文、授权数据源、预期意图、必需约束、canonical 地点、合格候选集合、预期空间关系、最佳结果、可接受替代项、预期操作、“没有结果”为何正确、容差，以及系统出错时的严重程度。必须在系统运行之前写好这些记录。根据模型输出再去调整答案标准，并不属于评估。

GISAgentBench 是 2026 年发布的一个由从业者任务构建的 benchmark，包含 349 个多步骤 GIS 任务。该研究认为，很多 GIS agent benchmark 缺少 ground-truth 输出，而使用代码相似度、trajectory matching 或 model judge 之类的替代信号，这可能会把一个相似 workflow 错当成正确结果。GISAgentBench 的每个任务都包含精确的 ground-truth 输出文件 (Pothuri et al., 2026)。只要问题是 deterministic 的，就应使用代码或权威记录，例如坐标、空间包含关系、canonical ID、营业或关闭状态、权限，以及调用了哪个 API action。只有真正主观的问题，例如解释是否易于理解，才应交给人工审核或经过校准的模型辅助审核。评估方法必须与所测试 truth 的类型匹配。

团队应该如何解读分段结果？

平均值可能掩盖某个地理区域的薄弱表现。应按国家、市场、语言、城市与乡村覆盖、数据提供商、地点类别、分店密度、查询复杂度和路线类型拆分结果。假设整体 valid-result rate 是 95%，而一个刚上线的市场只有 78%。这组数字只是一个假设示例，并不是 Kaleidr 的测量结果。平均值在数学上可以正确，却仍然可能是一个错误的扩张决策依据。应查看错误发生的位置，并将每个失败案例归类为：解释、entity resolution、grounding、资格判断、空间计算、新鲜度、排序、解释文本、操作、安全或恢复。分类可以告诉团队应该修改哪一层。routing 错误不是解释问题。

先对失败进行分类，再修改模型。分开的类别可以防止低频但严重的错误被一个大平均值掩盖。

生成式系统的多次运行也会出现波动。对于重要案例，应记录平均值、观察到的最差一次运行，以及失败重复出现的频率。一个查询如果 9 次安全、1 次错误，与每次都给出同样安全答案的查询，风险完全不同。当 prompt、模型、retrieval、ranking、数据提供商、工具或覆盖范围变化时，都应重新运行测试集。评估应该成为 release management 的一部分，而不是上线前的一次性报告。

生产 scorecard 应该包含什么？

每个维度都应有自己的指标和自己的 gate。意图可以使用 constraint extraction。地点身份可以使用 canonical-place accuracy。授权和安全可以使用 unauthorized-access rate，并且对受保护数据不容许任何未授权访问。资格判断、空间计算、新鲜度、排序、无结果处理、解释、操作和结果也都需要独立阈值，由产品负责人在运行前设定。不要从另一个应用复制所谓通用 cutoff。普通餐厅推荐和带有安全后果的路由决策，并不共享同一个 error budget。

关键维度要独立测量。这个 scorecard 上的状态标签只是 placeholder，不是 Kaleidr benchmark 分数。

团队应该如何决定是否扩张？

使用独立 gate，而不是一个混合总分。当有效、grounded 且空间上正确的结果在接近生产的条件下仍然稳定，关键错误类别已经被控制，有明确的人负责运营数据，并且目标结果得到改善时，再扩张。如果任务本身有价值，而某个可修复层仍然薄弱，就继续迭代。如果试点混合了太多地理区域、数据源或任务，导致无法判断哪里失败，就缩小范围。如果团队无法指出权威数据、无法控制关键失败、无法定义任务，或无法证明比当前 workflow 更好，就应停止。企业 Spatial AI 试点提供的是一个有限范围的测试，而 scorecard 则把该测试变成决策。

Kaleidr 在评估体系中处于什么位置？

Kaleidr Enterprise 将自身描述为 location-intelligence infrastructure，包含 inference API、ranking system、analytics 和 deployment support，也提供 chat、editing、tiles 和可嵌入 viewer，供 host 在已有地图旁添加这些能力 (Kaleidr, 2026)。host 应用继续保留自己拥有的业务系统，包括库存、权限、客户状态、预订和其他私有运营记录。空间工具负责可以计算的操作。语言模型层解释意图、协调受支持的能力，并说明 grounded 结果。Kaleidr 的公开 Analytics 页面 Map Engagement and Location Analytics 描述 reach、views、engagement、受众位置与活动、每张地图的 sessions 和 interactions、地点比较以及空间模式 (Kaleidr, 2026)。这些报告描述的是地图和地点行为。已完成的预订、订单和 qualified lead 仍然留在记录这些结果的 host 系统中。

语言模型不是库存、权限或路线的 source of truth。各层之间的 checkpoint 可以帮助定位究竟是哪一部分失败。

哪些错误会掩盖一个薄弱的 benchmark？

如果只测试没有歧义、没有缺失数据、也没有无解请求的 happy path，就会高估可靠性。只根据答案措辞与参考答案有多相似来评分，会漏掉“说法不同但判断正确”的结果，也可能奖励“地点错误但写法像参考答案”的结果。对仍包含不合格地点的集合进行排序，会掩盖资格判断错误。让模型去判断空间引擎本来可以直接计算的距离，是用语言流畅度代替计算。忽略新鲜度，就是把昨天的营业时间当作今天的。把更多地图交互当成更高准确性，会混淆兴趣、成功，有时甚至是困惑。看到结果之后再修改容差，就不再是 benchmark。只测模型本身，也会忽略 retrieval、数据、工具、权限、ranking 和 interface。生产行为来自完整组装后的产品。

研究 benchmark 仍然可以作为能力探针。GeoBenchLLM 于 2026 年 8 月提交，并被 CIKM 2026 接收，它使用公开 datasets 中的 geo-related task 来评估语言模型，包括地理空间与时间理解 (Rodrigues et al., 2026)。GeoAI benchmark 往往覆盖遥感、GIS workflow、影像或地理空间模型任务。而产品 benchmark 可能还需要业务数据 grounding、权限、实时可用性、排序、地图操作和客户结果。一个公开 benchmark 无法代替所有产品自己的实际任务。

衡量的是决策链，而不只是模型。八个阶段是评估框架，不是公布的分数。

如何让评估成为 release gate？

在扩张之前先构建测试集，并包含失败案例。对于可以由工具或记录回答的 deterministic truth，应把它放在语言模型之外。关键维度要使用独立 gate 追踪。系统变化后重新运行评估，并将离线结果与本来应该改善的生产结果连接起来。真正有用的问题是：这个系统能否利用正确的数据、地理、权限和操作，完成产品承诺的位置依赖决策？团队能否证明这一点？

查看 Kaleidr Enterprise，了解如何在产品已经运行的系统旁加入位置感知 AI，并定义一个聚焦的试点。查看 Kaleidr Analytics，了解受众如何使用该试点中的地图和地点。业务结果以及是否扩张的决定，仍然由 host 负责。

常见问题

如何衡量 Spatial AI 准确性？

测量位置决策的各个阶段：意图、地点解析、授权、资格判断、地理计算、新鲜度、排序、解释、操作，以及用户或业务结果。不要把整条链压缩成一个模型分数。

这和语言模型准确率一样吗？

不一样。语言模型只是其中一个组件。地点数据库、业务记录、空间引擎、routing、ranking、权限和应用状态，都可能影响最终结果是否正确。

语言模型应该计算距离吗？

当产品需要距离或移动关系时，应使用地理工具或 routing tool。模型可以判断什么时候需要计算，也可以解释结果，但实际计算应由空间服务完成。

benchmark 应该包含不可能的问题吗？

应该。意图设计为无解的任务可以检查系统是否会返回 grounded 的“没有结果”，而不是虚构地点或静默丢弃某个约束。

评估应该多久运行一次？

在生产上线前运行，并在模型、prompt、数据提供商、ranking、空间工具、权限或覆盖范围发生变化时再次运行。生产行为需要持续监控。上线当天的一份报告并不等于完整的 release process。

一个 benchmark 能比较所有系统吗？

研究 benchmark 可以比较一个明确声明的能力。生产评估必须反映该应用自己的地理任务、数据、风险、工具和结果。GeoAI benchmark 与产品 benchmark 不能互相替代。

参考资料

1. National Institute of Standards and Technology. AI RMF Playbook, Measure. Notes that the AI RMF 1.0 is being updated and that the playbook will be revised afterward. Accessed September 29, 2026. https://airc.nist.gov/airmf-resources/playbook/measure/
2. National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
3. Krechetova, Varvara, and Denis Kochedykov. GeoBenchX: Benchmarking LLMs in Agent Solving Multistep Geospatial Tasks. arXiv:2503.18129, submitted March 23, 2025, revised October 22, 2025. https://arxiv.org/abs/2503.18129
4. Pothuri, Abhinav, Zhe Jiang, Zelin Xu, and Di Yang. GISAgentBench: A Practitioner-Sourced Benchmark for Evaluating LLM Agents on GIS Tasks. arXiv:2608.01645, submitted August 3, 2026. https://arxiv.org/abs/2608.01645
5. Rodrigues, Rodrigo Ferreira, Karim Radouane, Jose G. Moreno, and Lynda Tamine. GeoBenchLLM: A Comprehensive Benchmark for Evaluating LLMs on Geo-Related Tasks. arXiv:2608.07411, submitted August 7, 2026. Accepted at CIKM 2026. https://arxiv.org/abs/2608.07411
6. OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Accessed September 29, 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
7. Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 29, 2026. https://kaleidr.com/enterprise
8. Kaleidr. Map Engagement and Location Analytics. Accessed September 29, 2026. https://kaleidr.com/analytics
9. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
10. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling

@misc{nist_rmf_playbook_measure_2026,
  title  = {AI RMF Playbook, Measure},
  author = {{National Institute of Standards and Technology}},
  year   = {2026},
  note   = {Accessed September 29, 2026. Page states the playbook will be updated after the AI RMF revision},
  url    = {https://airc.nist.gov/airmf-resources/playbook/measure/}
}

@techreport{nist_ai_200_2_2026,
  title       = {The TEVV-Athlon Framework for Evaluating AI Systems},
  author      = {{National Institute of Standards and Technology}},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 200-2},
  year        = {2026},
  note        = {Initial public draft, announced August 7, 2026},
  url         = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}

@misc{krechetova_geobenchx_2025,
  title  = {GeoBenchX: Benchmarking LLMs in Agent Solving Multistep Geospatial Tasks},
  author = {Krechetova, Varvara and Kochedykov, Denis},
  year   = {2025},
  note   = {arXiv:2503.18129, revised October 22, 2025},
  url    = {https://arxiv.org/abs/2503.18129}
}

@misc{pothuri_gisagentbench_2026,
  title  = {GISAgentBench: A Practitioner-Sourced Benchmark for Evaluating LLM Agents on GIS Tasks},
  author = {Pothuri, Abhinav and Jiang, Zhe and Xu, Zelin and Yang, Di},
  year   = {2026},
  note   = {arXiv:2608.01645, submitted August 3, 2026},
  url    = {https://arxiv.org/abs/2608.01645}
}

@misc{rodrigues_geobenchllm_2026,
  title  = {GeoBenchLLM: A Comprehensive Benchmark for Evaluating LLMs on Geo-Related Tasks},
  author = {Rodrigues, Rodrigo Ferreira and Radouane, Karim and Moreno, Jose G. and Tamine, Lynda},
  year   = {2026},
  note   = {arXiv:2608.07411, submitted August 7, 2026, accepted at CIKM 2026},
  url    = {https://arxiv.org/abs/2608.07411}
}

@misc{owasp_llm01_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 29, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{kaleidr_enterprise_accuracy_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 29, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_analytics_accuracy_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 29, 2026},
  url    = {https://kaleidr.com/analytics}
}