所有文章 企业版

面向客户意图的地点排序 API

作者 The Kaleidr Team · 发布于 2026年8月26日 · 17 分钟读完

候选地点先经过授权和严格资格审查，再由空间、意图、新鲜度和业务信号生成可解释的地图排序结果。

地点排序 API 针对具体客户决策，结合空间上下文、客户意图、业务规则和数据新鲜度，对符合条件的地点进行排序。授权、可用性、必需服务和服务区域等硬性约束应当作为筛选条件，而不是分数。语言模型可以把请求解释为结构化要求；地理空间系统和业务系统提供排序器要组合的事实。

下文涵盖检索与排序、供应商排序模式、硬性筛选、地理特征、意图边界、特征设计、身份验证、Kaleidr 当前公开接口以及评估方法。相关阅读包括位置智能客户体验地图、什么是位置智能 API？、位置感知预订、带地图聊天的 AI 门店定位器以及如何构建地图感知型 AI 助手。

地点排序要点

  • 先判断资格，再计算分数： 授权、可用性、必需能力和服务区域应直接移除无效地点，而不是仅仅降低分数。
  • 空间特征必须匹配任务： 直线距离、出行时间、路线绕行、区域包含关系和多锚点适配回答的是不同问题。
  • 意图是结构化输入： 语言模型解释偏好；地点、库存和路线系统仍是事实的权威来源。
  • 理由优于不透明分数： 客户和运营人员需要可核查的信号，例如出行时间、营业状态和所需服务。
  • 衡量决策，而不只是点击： 候选召回率、约束违规、过期数据和下游结果都属于质量契约。

候选地点先经过授权和严格资格审查，再由空间、意图、新鲜度和业务信号生成可解释的地图排序结果。

什么是地点排序 API？

地点排序 API 回答：对于当前客户、当前任务和当前状态，哪些有效地点应当优先显示。搜索或检索 API 通常负责寻找候选，例如某个城市附近的餐厅、当前视口内的门店或路线沿途的酒店。完成授权和硬性资格检查后，排序再决定剩余地点的先后顺序。生产级位置智能通常需要“检索、筛选、排序”三个阶段；无效记录即使得分很高，也只是产品缺陷。

有用的输出是与地图同步的有序列表，而不是单个不透明数字。每项结果应包含地点标识、排名位置以及少量源自真实信号的理由。“发现”负责取得合格记录，“比较”展示出行关系、服务匹配度和新鲜度，“行动”则可以是地图高亮、路线、预订或取货跳转以及保存地点。

为什么排序不同于最近地点搜索？

如果客户明确要求最近的合格地点，而且其他条件已经满足，那么按距离排序是合理策略。但最近的门店可能不提供取货、已经关门、缺货、需要大幅绕行或位于服务区域之外，此时单纯距离排序就会失败。更稳健的流程是先确认地点有效、服务符合要求、当前可用，再计算出行关系和偏好，最后排序。距离只是一个信号，而不是整个决策。

这一区分也影响产品语言。门店定位器、预订候选清单、通勤型房产搜索和活动场地设施指南在界面上都可能表现为“附近”，底层需要的空间特征却不同。硬性规则应放在资格判断中，只对剩余候选排序。

当前搜索供应商如何给地点排序？

地图搜索 API 已提供多种模式，说明检索阶段也不存在通用顺序。Google Places Nearby Search (New) 为 rankPreference 记录了 POPULARITY 和 DISTANCE 两个选项（Nearby Search (New)）。Text Search (New) 针对适用的类别查询提供 RELEVANCE 或 DISTANCE，并建议在城市名等非类别查询中不设置 rankPreference（Text Search (New)）。这些设置只能排序供应商的候选集，不了解主系统的私有库存、票务规则或预订窗口。

Mapbox Search Box 的 rank_strategy 支持 distance 或 relevance，还支持邻近偏置、路线感知搜索和可选 ETA（Search Box API）。输入路线后，建议项可包含以米计的 added_distance 和以分钟计的 added_time，这表示绕行而不是原始距离。Google Places 也能通过 searchAlongRouteParameters 让 Text Search 偏向路线折线（Search along route）。供应商排序适合候选检索；产品排序则从主系统补充自身事实开始。

地点排序 API 应优化哪项决策？

不要从“需要一个 AI 排序模型”出发，而应先定义有序列表要改善的决策。零售要决定客户应去哪家合格门店；预订要选择最符合行程的可用选项；房产搜索要匹配位置要求；酒店服务要找出适合客人请求的获准合作方；活动要判断下一场会议前最相关的展商或设施；履约市场要选择地理匹配最佳且能够完成请求的服务商。

决策决定候选集、硬性约束、空间与业务特征、标签和评估指标。通勤型房源排序需要多个锚点的出行时间；取货排序要先检查当前库存和营业状态；路线沿途设施需要绕行量而非直线距离。用一句可测试的话写清任务。“相关性”过于模糊，同一个目录对两个合理客户可能需要完全相反的顺序。

地点排序 API 应采用什么流程？

稳健流程包括请求解释、候选检索、授权、硬性资格检查、特征计算、排序、理由生成、地图与列表展示以及结果衡量。无效地点必须在打分前离开候选集，以免方便但未授权、已关闭或超出服务区的记录占据前列。然后只为通过筛选的地点附加出行时间、绕行、偏好匹配、新鲜度和业务策略。理由必须从同一组信号推导，而不是另外生成一段文字。

大目录通常分阶段控制成本：检索返回有限候选；低成本预排序使用近似距离、类别和粗粒度可用性；出行时间矩阵、路线绕行和深度丰富等昂贵计算只用于短名单。截断规模由应用决定。应分别测量各阶段延迟，因为路线或库存查询经常比所谓“AI”更占预算。

硬性资格筛选先移除无效地点，再由较柔性的排序信号比较剩余候选。

为什么硬性筛选必须先于排序信号？

硬性筛选是二元判断：候选要么可参与，要么必须排除。常见门槛包括有效上架、所需服务、当前库存、可预订房间、位于服务区域内、持票权限、在请求时段营业以及用户有权查看记录。排序信号只比较通过者：出行时间、绕行、距离、价格匹配、类别匹配、声明偏好、新鲜度、业务优先级和历史转化。把规则写成“不可用减 20 分”仍可能让无效地点胜出。

必须满足的无障碍要求、权限、法定服务区、库存和能力都遵循同一模式。缺失数据不等于零分。如果候选有出行时间和营业时间，但没有评分，把评分设为零会把未知误当作差。更安全的策略是中性默认值、特征专用回退、低置信度标记，或仅在该字段本身是硬性要求时排除。缺失数据策略应写入排序策略版本。

排序应使用哪些地理信号？

地点没有普适排名。网络出行不重要时，直线距离是低成本近似；预约、门店、酒店和房产通勤更适合用出行时间；公路旅行、配送停靠和上门服务更适合用路线绕行。Mapbox 的 added_time 和 added_distance 展示了这种产品形态（Search Box API）。包含关系回答地点是否在配送区、学区或活动区域内。多锚点适配则同时考虑多个关键地点，例如酒店相对机场、会场和办公室的位置。

多锚点策略可以取平均出行时间、最小化最差路段，或要求每个锚点都低于阈值后再按价格排序。同一特征向量会产生不同胜者。选择函数应基于客户决策，而不是公式是否整齐；地图和列表必须使用同一策略版本和顺序。

当产品分别优化直线距离、出行时间、路线绕行或多个地理锚点时，同一组合格地点会得到不同排名。

客户意图应如何进入排序？

自然语言请求经常混合硬性约束和偏好。“找一家靠近会场、安静，而且去机场顺路的咖啡馆”包含实体类型、隐含营业时段、适合交谈的偏好、近距离锚点和路线约束。结构化解释应将必需字段与偏好分开，让资格检查继续充当门槛。语言模型解释请求，地点系统解析候选，路线服务计算路线关系，排序器组合经验证的信号。

不要让意图模型成为事实层。模型声称咖啡馆营业、商品有库存、房间可预订或绕行需要 11 分钟，都不能成为排序特征，除非经批准的系统提供了这个值。OWASP Top 10 for LLM Applications 2025 将仅因模型提议就执行已连接功能称为 LLM06:2025 Excessive Agency。和地图感知型助手一样，模型提出结构化排序要求；确定性代码或受控排序器组合授权特征；主系统验证地图动作。

个性化可以使用客户明确声明的步行、停车、安静环境、保存类别或偏好街区。客户应能编辑、重置或忽略这些偏好。不要在缺乏合法依据时推断敏感属性；派生特征足够时，也不要记录敏感原始输入。NIST Privacy Framework 把隐私视为企业风险管理问题。AI 地图工作流中的私有位置数据讨论了同样的主系统目录边界。

如何组合并解释排序特征？

特征应与任务相关、可获得、足够新鲜、正确归一化、获得许可且可测试。米、类似星级的评分、货币和偏好分数不能直接相加。应把每个信号转换为可比较的匹配值，并把归一化函数视为产品策略。由出行匹配、意图匹配、新鲜度和业务匹配构成的透明加权和，往往比学习模型更适合作为第一版，因为团队能检查、调试、解释和有意识地调整它。示例权重是策略，不是证据。

不要把内部 87.4 分直接展示为意义。更好的理由是“步行 12 分钟”“请求时段营业”“提供所需服务”或“符合所选偏好”。优先合作方、忠诚度、容量、推广库存、合同排名和运营平衡可以调整顺序，但应与地理相关性分开。商业展示影响列表时，应遵守适用披露规则。

新鲜度是一等特征，因为营业时间、库存、活动房间、入口状态和供应商可用性都会失效。关键事实过期后应重新验证或排除。热门程度本身是反馈循环，应谨慎使用。如果五家几乎相同的分店或过于集中的地图簇无法满足客户需要，可以在第二阶段加入结果多样性和地理覆盖。

供应商排序与产品排序有何不同？

排序器无法恢复检索阶段从未返回的地点。候选召回率必须和排序质量分别评估。Google 的 rankPreference 以及 Mapbox 的 rank_strategy、邻近和路线字段，只是在供应商索引上排序（Nearby Search (New)、Text Search (New)、Search Box API）。主系统可以取得有限候选集，以库存或资格信息丰富它们、计算路线，再按产品任务重新排序。

应当在用户上下文、任务上下文和当前状态下排序 place，而不是抽象地给 place 一个静态顺序。预排序、排序和重排序的目的，是只在可能改变决策的地方使用昂贵特征。

排序请求应如何验证身份和设计结构？

架构层请求可以包含任务、起点、候选标识、硬性要求、偏好和结果上限。响应可以返回有序 placeId 以及可检查理由。这是设计示例，不是 Kaleidr 已记录的路由。应优先传递候选 ID，并在授权后端丰富数据，而不是从浏览器发送完整私有记录。用户向主系统验证身份，主系统取得获准候选，排序只在该集合上运行。

Kaleidr 在浏览器中使用 publishable keys，在可信后端操作中使用 server keys（Auth & Scopes）。Publishable key 会交换为短时、绑定来源的会话；server key 留在后端。私有库存、票务状态和排序凭据不应因为结果要显示在地图上就进入页面源代码。路线供应商支持时，应批量发出出行时间或矩阵请求，而不是每个候选一次请求。

Kaleidr 当前如何定位排序功能？

Kaleidr Enterprise 目前将平台描述为面向现代空间产品的位置智能基础设施，包含推理 API、排序系统和分析能力（Location Intelligence APIs and Map SDK）。该供应商页面是 Kaleidr 自身产品定位的权威来源，但不能替代实时端点列表。

当前公开 Platform API 参考在 https://api.kaleidr.com/inference-api/b2b/v1/ 下记录了聊天、路线、POI 丰富和设计路由。已记录的端点包括 POST /chat/control/stream、POST /chat/control/route、GET /retrieval/poi/enrich，以及 design scope 下的设计端点（Endpoints）。参考文档没有记录专用公开 /rank 路由。自定义排序应视为 Enterprise 集成要求；除非当前部署合同明确提供，否则不要实现 POST /rank。

这些公开推理接口仍可为排序流程提供对话意图、路线计算和 POI 丰富，但它们是输入，不是独立排序器。Kaleidr Enterprise 仍是组织级空间推理、合同和部署支持的产品入口（Location Intelligence APIs and Map SDK）。编码任何假设路径前，先确认支持的集成方式。

排序策略先离线评估召回率、约束、质量和地理偏差，再在线衡量客户结果和诊断故障，之后进入下一策略版本。

如何评估地点排序质量？

离线评估需要冻结的任务集：查询、起点、硬性规则和偏好信号。应衡量候选召回率、资格准确率、Top-K 质量、约束满足率、解释正确性和地理偏差。成对标签“对该任务，A 是否应排在 B 前？”通常比完美绝对分数更容易收集，之后训练学习型排序器时也仍然有用。约束满足不可妥协：如果客户要求营业、支持取货且位于区域内，头部结果违反任何一项都是失败，即使点击率很高。

在线指标可包括选中地点、打开路线、开始预订或取货、保存列表、咨询或重新查询。点击会受到位置偏差影响，不能证明首项就是最佳合格选项。应持续展示无结果、硬性规则违规、数据过期、各阶段延迟和必需特征缺失等诊断。结果应进入带版本和回滚路径的策略更新。空间分析地图产品 KPI 指南同样强调完成任务，而非原始交互。

新鲜度测试也必须纳入：20 分钟前关闭的门店、已禁用的场地入口、无效列表或售罄库存，不应凭借昨天的互动继续排在前列。历史热门程度不能抵消当前资格失败。

产品团队应预期哪些失败模式？

错误 结果 更好的做法
先排序再检查资格 无效地点排在前列 先筛选硬性约束
把最近当作最佳 忽略任务上下文 使用决策所需的空间特征
把必需规则写成权重 无效选项仍可能胜出 将必需能力保留为硬性筛选
让语言模型编造事实 排序失去依据 从权威系统读取营业时间、库存和路线
把缺失当作零 稀疏记录受到惩罚 定义缺失数据策略
只依赖供应商顺序 产品上下文丢失 使用主系统事实重新排序
只优化点击 位置偏差伪装成质量 衡量结果和约束违规
隐藏所有理由 信任和调试能力崩溃 展示可检查信号
忽略排序版本 实验无法追踪 版本化策略并支持回滚
假设 Kaleidr 有 /rank 路由 集成目标并不存在 确认当前 Enterprise 合同

移动端体验需要足够大的点击目标、易读理由，以及模型或昂贵特征超时时仍能使用的地图。直接搜索必须继续可用；输入门店名的客户不应被迫进行对话。缓存基础几何和标签，并以可控方式降级丰富数据。测试歧义名称、颠倒起点、关闭地点和过期库存，直到地图、列表和理由能同步更新。

将地点排序 API 集成到产品中

生产模式是：检索、授权、筛选硬性约束、计算空间特征、排序、解释并衡量。距离、热门程度和语义相关性都可能有用，但没有一个始终正确。排序策略应反映客户要做的决定，并在地图上提供可检查理由。

了解 Kaleidr Enterprise，讨论位置智能 API、排序系统和部署支持。编码集成路径之前，请查看 Kaleidr 开发者文档中的当前推理、检索、身份验证和 SDK 接口。

常见问题

什么是地点排序 API？

它在应用硬性资格规则之后，利用地理、业务和客户上下文信号，为具体任务排列候选地点。

地点排序等同于最近地点搜索吗？

不等同。最近地点搜索主要按距离排列；地点排序还可考虑出行时间、路线绕行、可用性、资格、偏好、新鲜度和业务规则。

不可用地点是否只应降低分数？

如果可用性是硬性要求，应在排序前移除不可用地点，而不是给予仍可能被其他信号抵消的惩罚。

检索与排序有什么区别？

检索寻找候选地点，排序排列有效候选。排序系统无法恢复检索从未返回的相关地点。

产品能否使用供应商排序后再重排序？

可以。地点供应商可按相关性、热门程度、距离、邻近或路线提供候选；应用随后可丰富、筛选并按具体业务任务重排。

排序应使用哪种空间信号？

使用与客户决策匹配的信号：简单邻近可用直线距离，真实便利性更适合出行时间，路线沿途用绕行，服务区域用包含关系。

什么是多锚点排序？

它相对于多个重要地点评估候选，例如同时考虑酒店与机场和会场的关系。

语言模型应该计算排序分数吗？

语言模型可以解释自然语言偏好。确定性代码或受控排序模型应组合经验证的特征；出行时间、库存和可用性必须来自权威系统。

如何解释地点排序？

返回与真实信号相关的简短理由，例如出行时间、支持取货或在请求时段营业，而不是裸露内部原始分数。

如何评估地点排序？

评估候选召回率、硬性约束满足率、Top-K 质量、标签集支持时的 NDCG 或 MRR，以及下游客户结果。

Kaleidr 是否有公开的地点排序端点？

Kaleidr Enterprise 描述了提供排序和分析的排序系统与位置智能 API。当前公开 Platform API 参考没有记录独立 /rank 端点；请确认支持的 Enterprise 集成。

参考资料

@misc{google_nearby_search_2026_08_26,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{google_search_along_route_2026_08_26,
  title  = {Search along route},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/search-along-route}
}

@misc{google_text_search_2026_08_26,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{kaleidr_auth_scopes_2026_08_26,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_endpoints_2026_08_26,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_enterprise_2026_08_26,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 26 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{mapbox_search_box_2026_08_26,
  title  = {Search Box API},
  author = {{Mapbox}},
  note   = {Accessed 26 August 2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 26 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

相关内容

将您的地图变成增长引擎