本地商家检索怎么处理地域范围：行政区、距离和服务半径别混用

用户问“铁西附近有靠谱的眼镜店吗”，服务端收到的不是一个已经完整的地域过滤条件。“铁西”可能有歧义，“附近”没有给出距离，当前定位也不一定可用。直接套一个城市默认值，会让结果看上去完整，实际答错地方。

先把地域信息拆开，再决定能执行哪些过滤。下面是接口与测试样例设计，未在本文中部署或执行，不代表任何平台的内部检索实现。 三种范围不能共用一个字段 行政区回答“属于哪里”，距离回答“离指定点多远”，服务范围回答“能否为该位置提供服务”。注册地址落在某个区，不等于服务覆盖全区；线上咨询覆盖范围，也不等于存在本地门店。 一个请求可以同时包含行政区和距离要求，但必须知道每个条件从哪里来：用户明确输入、经授权的定位，还是系统候选解释。候选解释不能悄悄变成用户确认。 代码： regionText: 铁西附近 city: 未确认 location: 未提供 radius: 未指定 resolution: needsClarification 这些值是虚构输入，用来说明缺项该怎样表达。 缺少定位时不能伪造“最近” 没有坐标，可以返回需要确认城市的信息，也可以说明当前只能按已确认行政区筛选。不要输出“距离你最近”，更不能用门店登记顺序模拟距离排名。 对于明确写出“沈阳铁西”的请求，城市歧义消失，但“附近”仍然未必等于整个铁西区。可以让用户补一个商圈，或说明当前结果采用的区域范围。关键是让范围可见，而不是替用户做了选择却不说。 扩大范围必须可解释 本区没有足够候选时，系统可能需要检索邻近区域。扩展应该产生明确记录：原范围、扩展范围、触发原因，以及结果展示提示。不能为了凑满几家，把省内其他城市混进来。 服务商检索也一样。公司位于沈阳，只能证明登记或办公地点相关事实；是否接受辽宁其他城市项目，需要另有服务范围依据。 用边界样例验收 第一条仅写“铁西”，预期要求消歧；第二条明确城市但没定位，预期不计算距离；第三条范围内无匹配，预期说明空结果或显式扩展；第四条商家地址符合但服务不适用，预期不能仅凭地址进入候选。 还应检查输出是否保留筛选理由。每个候选满足了什么条件，哪些条件未知，比一个没有解释的综合分更适合排错。这里不提供虚构的精度数字，测试是否通过要由实际运行结果回答。 本文仅作工程说明，不代表搜索引擎、内容平台或大模型的实现规则。地域字段做对，能减少检索范围错误；它不等于商家已经获得收录、引用或推荐。 作者：答源经纬