TL;DR: AI 助手会编造看似合理但实际错误的地址，网络足迹稀少且不一致的独立房源受影响最严重。解决方法是通过 Schema.org Place 标记、经过验证的坐标以及一个规范的外部标识符，发布一份明确的 ground truth，然后在该业务出现的每一个平台上保持这份事实的一致性。
向 ChatGPT 询问波尔图一家三星级酒店的地址，它多半会给出一个街道名称、门牌号和邮政编码。回答听起来很有把握。对于大型连锁酒店，答案通常是正确的。而对于两条街之外的那家独立精品酒店，答案有相当的概率是错的。
这不是罕见的边缘情况。它是语言模型生成文本方式下可预测的输出，并且对于任何依赖特定位置被找到的业务都有直接后果。
位置幻觉的机制
语言模型不存储地址数据库，它存储的是 token 上的统计分布。当被问及一个地址时，它会预测一串看起来像是那个城市、那类场所的地址的 token 序列。
如果训练数据中真实地址多次、一致且在权威来源中出现过，预测就会收敛到正确字符串。如果地址出现得很少、不一致，或根本没有出现，模型就会插值：它会挑一个听起来适合该街区的街道、一个符合该街区的门牌号、一个匹配本地模式的邮政编码。
输出在语法上有效、在地理上合理，并且经常完全错误。
网络足迹稀少或不一致的场所风险最高。一处只挂在单个预订平台上的度假租赁，能给模型提供的依据远少于一家在数百个来源中以同一地址出现的连锁酒店。
一个实例
一个示例查询（房源名称和地址均为虚构）：「波尔图的 Casa do Vale 民宿地址是什么？」
一个典型的幻觉回答：
Casa do Vale 位于 Rua de Santa Catarina 142, 4000-442 Porto, Portugal。
本例中的正确地址：
Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal。
街道错了、邮政编码错了、城市的一侧也错了。这个幻觉地址把客人送到了距实际民宿三公里外的购物区。错误并非随机。Rua de Santa Catarina 是波尔图最著名的商业街，在训练数据中关于波尔图住宿的查询里大量出现。模型退回到了该城市最强的统计先验。
为什么结构化数据会改变结果
一个带有格式正确的 Place 或 LodgingBusiness JSON-LD 块的列表页面，给了模型可以提取而非虚构的内容。
{
"@context": "https://schema.org",
"@type": "LodgingBusiness",
"name": "Casa do Vale",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua do Vale 38",
"postalCode": "4200-512",
"addressLocality": "Porto",
"addressCountry": "PT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 41.1621,
"longitude": -8.5937
},
"identifier": {
"@type": "PropertyValue",
"propertyID": "wikidata",
"value": "Q00000000"
}
}
该块中有三个特性对减少幻觉至关重要：
- 结构化字段。 模型无需解析句子，街道、邮政编码、城市和国家都是独立的键。
- 与地址匹配的坐标。 爬虫可以验证经纬度是否落在邮政编码所覆盖的多边形范围内，不匹配时数据会被标记为低置信度。
- 稳定的外部标识符。 Wikidata 或 Google Place ID 把列表链接到一个规范实体。模型可以对照权威来源核对地址，而不是依赖训练数据中的频率。
当这三项条件都成立时，提取取代生成，幻觉答案的概率显著下降。
NAP 一致性层
列表页面上的 schema 是必要的，但还不够。AI 系统会把地址与其他公开来源交叉核对：Google Business Profile、OpenStreetMap、Yelp、Tripadvisor、预订平台以及开放网络。当这些来源互相矛盾时，置信度会下降，模型更可能回避或虚构。
这就是为什么跨平台的 Name、Address、Phone（NAP）一致性比任何单一信号都更能预测引用率。一条 schema 完美但在 Google Business Profile 上地址冲突的列表依然会表现不佳。机制详见 AI 搜索中的 NAP 一致性。
哪些措施最能降低幻觉风险
以下四项措施最能见效：
1. 在地址旁发布经过验证的坐标。 书面地址是一个字符串，坐标则是可核验的事实。MapAtlas Geocoding 可在规模化场景下把原始地址转换为精确的经纬度，并标记无法干净解析的输入。
2. 把位置事实包装进 JSON-LD。 Place、LodgingBusiness、Hotel、Restaurant 和 LocalBusiness 类型都接受 address、geo 和 identifier 字段。缺失字段正是模型开始猜测的地方。
3. 对齐到规范标识符。 将列表链接到 Wikidata QID 或 Google Place ID，这为 AI 系统提供了可用于去重的主键。
4. 用附近上下文做增强。 幻觉不只发生在地址字段，模型也会虚构附近的地标、公交站点和步行时间。由 MapAtlas GeoEnrich 生成的经过验证的邻近数据也能锚定这些声明。位置相关 FAQ 是暴露此类数据的有效载体。
虚构地址的业务代价
AI 助手浮现的错误地址不仅让模型尴尬，它还会把真实的客人送到错误的地方。下游影响会叠加：
- 一次取消的预订，甚至更糟，无故未到。
- 一条提及错误地点的差评，随后成为下一代模型的训练数据。
- 列表未来的引用置信度下降，因为公开网络上现在已经存在矛盾信号。
其中的不对称性很关键。即便列表本身无辜，幻觉地址也会伤害它。解决办法不是直接纠正模型（这不可行），而是让事实足够明确，使模型没有理由去生成。
如何检查自己的暴露风险
免费的 MapAtlas AEO Checker 会针对列表评估 29 项结构化信号，包括地址 schema、坐标是否存在、NAP 一致性和外部标识符。通过这些检查的列表在 AI 答案中被错误呈现的可能性显著更低；未通过的则是模型不得不猜测的那些。
位置幻觉并不是某个助手特有的小毛病。它是在一个同一家商家在数十个来源中地址略有差异的开放网络上训练所产生的可预测后果。解决办法是以 AI 系统可提取的格式发布唯一的事实真相，并在其他所有表示该业务的地方保持一致。
延伸阅读：
常见问题
什么是 AI 地址幻觉？
AI 地址幻觉指的是大型语言模型返回一个看似合理的具体街道地址、邮政编码或坐标，但与被描述的商家、地标或房产的真实位置并不对应。这不是小幅度的四舍五入误差。模型合成了一个不存在的地址、属于另一家场所的地址，或把真实街道与错误城市组合在一起。对于列表而言，这种情况尤其有害，因为用户可能在意识到答案是伪造之前就已经前往了错误的地点。
AI 助手为什么会虚构地址？
语言模型通过预测最可能的下一个 token 来生成文本，而不是查找事实。当一个地址在训练数据中出现得少、在整个网络上不一致，或被屏蔽爬取时，模型会用一个统计上合理的字符串来填补空缺：一个听起来适合该城市的街道名称、一个符合该地区模式的邮政编码、一个感觉典型的门牌号。在没有结构化的权威来源作为锚点时，模型没有任何机制去区分记忆中的事实和生成的内容。
在实际使用中，位置幻觉的发生频率有多高？
并不存在一个可靠的统一比率。它会因模型、语言、查询类型以及底层数据的新鲜度而变化。但规律是一致的：场所公开的结构化、一致的数据越少，模型虚构的内容就越多。连锁酒店和知名地标在众多权威来源中以同一地址出现，通常能得到正确回答。表现最差的是长尾列表，例如独立度假租赁、精品酒店和小型餐厅，因为模型几乎没有可提取的已验证数据，只能自行填补空缺。
Schema.org 结构化数据能否减少幻觉？
在数据经过验证并在各来源之间保持一致的前提下，可以。发布一个带有准确地理坐标、经过校验的邮政地址，以及对 Wikidata 或 Google Place ID 等权威标识符交叉引用的 Place 或 LodgingBusiness JSON-LD 块，能为模型提供一个可以提取并引用的权威锚点。不一致的 schema，例如坐标与书面地址不符，往往会降低置信度而非提高置信度。
如何审计自己的列表的幻觉风险？
通过 mapatlas.eu/ai-seo-checker 把列表 URL 输入到免费的 MapAtlas AEO Checker 中。该检查器评估 29 项 AI 系统用于锚定位置事实的结构化信号，包括地理坐标、Place schema、跨平台 NAP 一致性，以及附近上下文字段是否存在。缺失这些信号的页面幻觉风险评分较高，因为模型必须靠猜测而不是提取。
