24 KiB
24 KiB
通用景区知识图谱 Schema v0.3
生成时间：2026-05-28
适用范围：百度百科景区词条、高德 POI、人工录入材料、后续互联网补充材料
状态：抽取测试版，暂不直接替换线上 Schema
版本说明：v0.3 在 v0.2 的媒体/交通规则基础上，重点升级 Event 层，新增一级分类、二级子类、标准起止时间和子类专属 details。
1. 结论
当前 guiyang_new2 已经能演示花溪公园的基础知识，但还不是成熟的景区通用 Schema。
它目前有 Place / Area / Event / Concept / Literal / BusLine / ScenicSpot / NaturalFeature / Facility / CulturalSite / MemorialSite 等标签，也有 HAS_EVENT / HAS_CONCEPT / HAS_PART / NEAR_TRANSIT / NEARBY_ATTRACTION 等关系。这个结构可以支撑一个景点 Demo，但不足以稳定承接多个景区的百科知识，尤其是梵净山、青岩古镇、遵义会议会址、织金洞、黄果树瀑布这类差异很大的景区。
我建议把景区 Schema 分成四层。核心层级必须保持简单：
ScenicArea（景区）
└── Attraction（景点/入口/景区内可导航点）
└── AttractionPath / RouteSegment（景点 → 景点）
也就是说，路径的 from_id / to_id 统一指向 Attraction，不再使用 sub_attraction 这种容易混乱的名字。自然景观、文化点、入口、码头、小吃城这类差异，通过 Attraction.category / spot_type 区分。
完整 Schema 分层如下：
- 景区主体层：
ScenicArea - 景点与设施层：
Attraction / Facility / TransitFacility - 语义知识层：
Event / Concept / BusLine / RouteTemplate / Person / Organization - 溯源与候选层：
MediaAsset / SourceDocument / Statement / SchemaGap
这样既能保存百度百科中的通用字段，也能承接后续“景点 URL、照片、交通、人物、事件、荣誉、自然资源、文化概念”等细节。
2. 当前 Schema 评估
2.1 已有优点
| 能力 | 当前情况 |
|---|---|
| 基础实体 | 有 Place 和 Area |
| 事件 | 有 Event，花溪公园已有 9 个历史事件 |
| 概念 | 有 Concept，可表达自然公园、生态公园、人文公园等 |
| 景点 | 有 HAS_PART，但目前只沉淀了少量子节点 |
| 交通 | 有 BusLine / NEAR_TRANSIT / STOPS_AT |
| 空间查询 | 主要在 guiyang_spatial_v1，有 H3 与高德 POI 数据 |
2.2 主要不足
| 问题 | 影响 |
|---|---|
ScenicSpot 只有 2 个节点 |
景区语义层还没有真正成体系 |
Literal 事实过散 |
地址、门票、开放时间等不易统一检索和更新 |
| 景点字段不足 | 无法稳定保存景点 URL、照片、简介、位置、证据 |
| 事件字段不足 | 事件需要保留发生时间、规范时间、参与人物、事件地点、证据 |
无 MediaAsset |
多张照片只能混在属性里，不利于轮播、展示和溯源 |
无 SourceDocument |
无法精确知道事实来自哪个网页、哪个章节、什么时候抓取 |
| 缺少 SchemaGap 机制 | LLM 抽到新字段时容易乱造关系名，后期查询会困难 |
| 景区与空间 POI 未统一 | 百度百科抽取知识和高德 POI 空间点需要 Entity Alignment 合并 |
当前景区知识承载能力约为 40%。适合演示，不适合直接作为后续多景区长期入图 Schema。
3. 设计目标
这个版本目标不是一次性穷尽所有景区，而是先覆盖 80% 高频事实：
| 数据来源 | 要覆盖的内容 |
|---|---|
| 百度百科基本信息 | 中文名、外文名、地理位置、开放时间、景点级别、门票、著名景点、邻近景点、建议游玩时长、适宜季节 |
| 百度百科正文 | 历史沿革、地理环境、主要景点、文化事件、名人到访、交通线路、饮食住宿 |
| 高德 POI | 经纬度、行政区、地址、评分、电话、营业时间、照片、分类 |
| 人工材料 | 新增景点 URL、照片、补充说明、运营信息 |
4. 核心节点
| 节点 | 作用 | 示例 |
|---|---|---|
ScenicArea |
景区主体 | 花溪公园、梵净山、青岩古镇 |
Attraction |
景区内部可游览、可搜索、可导航的点位。自然景观、文化点、入口和官方推荐服务点都优先落在这里，用 category/spot_type 区分 |
百步桥、麟山、金顶、蘑菇石、大门、码头、花溪小吃城 |
Facility |
服务设施 | 游客中心、停车场、售票处、厕所、码头、摆渡车 |
TransitFacility |
周边交通设施 | 地铁站、公交站、火车站、客运站 |
BusLine |
公共交通线路 | 90路、89路、109路、地铁1号线 |
Area |
行政区或地理区域 | 贵州省、贵阳市、花溪区 |
Person |
关联人物 | 徐霞客、陈毅、周恩来、刘剑魂 |
Organization |
管理或建设单位 | 景区管理处、文旅局、保护区管理局 |
Event |
历史/建设/保护/荣誉事件 | 1937 年花溪正式辟建为公园 |
Concept |
主题概念 | 历史文化、自然生态、红色旅游、夜游 |
RouteTemplate |
游览路线或推荐玩法 | 一日游路线、景区内部游览路线 |
MediaAsset |
图片/视频 | 景点照片、高德照片、导览图、全景图。它不是景点实体本身，必须通过 owner_entity_id/HAS_MEDIA 挂到最具体实体，并用 media_role 区分用途 |
SourceDocument |
来源文档 | 百度百科词条、人工上传文件 |
Statement |
候选事实层 | 长尾属性、待审核事实、新关系候选 |
5. 景区主体字段
ScenicArea 建议字段：
| 字段 | 说明 |
|---|---|
entity_id |
稳定 ID，入库前由 Entity Alignment 生成 |
name / canonical_name / aliases / foreign_name |
名称、规范名、别名、外文名 |
scenic_category |
自然景区、古镇、遗址、公园、博物馆、红色景区等 |
scenic_level |
A/AAAA/AAAAA 等 |
description |
简介 |
reputation |
美誉，例如“高原明珠” |
country/province/city/district/address/location_text |
行政和地址信息 |
lng/lat/adcode/h3_r6-h3_r10 |
空间能力字段 |
climate/area_size/altitude/terrain/water_system |
自然地理字段 |
opening_hours/ticket_price/suggested_duration/best_season |
游客决策字段 |
famous_spots_text/nearby_attractions_text |
原文列表保留 |
cover_image_url/photo_urls |
普通展示照片 |
guide_map_urls/route_map_urls/panorama_urls |
导游图、路线图、全景图等功能型媒体 |
source_name/source_url/crawl_time/last_updated |
来源和更新时间 |
confidence/review_status |
抽取置信度和审核状态 |
6. 景点字段
Attraction 必须能保存你后续补到的 URL、照片、开放时间、额外收费和建议游览时长。游客会作为景点游览、搜索或导航终点的桥、亭、山、洲、湖、旧居、纪念墓、入口大门、码头、官方推荐小吃城等，优先归入 Attraction，再用 category/spot_type 区分；不要因为名字像设施就归为 Facility。
| 字段 | 说明 |
|---|---|
entity_id |
景点稳定 ID |
name |
景点名称 |
parent_name |
所属景区 |
category |
统一分类，例如 natural_feature、cultural_site、entrance_gate、viewpoint、service_place |
spot_type |
桥、亭、山、湖、古建筑、纪念地、观景点等 |
description |
简介 |
location_text/lng/lat |
可选位置 |
source_url |
景点来源 URL，没有独立页面时继承来源网页 URL |
cover_image_url/photo_urls |
景点封面图和多张照片 URL。若图片小节名或说明命中景点，例如“百步桥”，图片必须回填到该子实体 |
evidence_quote/source_section |
证据和来源章节 |
confidence/review_status |
置信度和审核状态 |
7. 事件字段
Event 不能只显示“类型”。景区后期会问“某景区有哪些荣誉”“某年发生了什么”“徐霞客到访过哪些景区”“哪些景区有影视取景”等问题，所以事件必须同时具备时间查询能力和类型查询能力。
本版采用“统一 Event 节点 + 两级分类 + 弹性 details”的方案：
event_category：一级分类，用于聚合统计。event_subtype：二级子类，用于精确查询。event_type：兼容旧系统的展示别名，不作为主要查询字段。details：保存子类专属字段，避免把所有子类型拆成大量互不兼容的节点模型。
这样比“纯继承多个 Event 子类”更适合当前 FalkorDB/前端展示/LLM 抽取链路：查询优先走属性，未来如果图数据库支持多 Label，再额外打 Event + event_category + event_subtype 标签做索引优化。
7.1 Event 通用字段
| 字段 | 说明 |
|---|---|
event_id |
事件 ID |
name |
事件名称 |
event_category |
一级分类：HISTORICAL / HONOR / CULTURAL / NATURAL / OPERATIONAL / TRANSPORTATION |
event_subtype |
二级子类：FAMOUS_VISIT / AWARD / RENAMING / CONSTRUCTION 等 |
event_type |
兼容旧系统的展示类型，例如 VisitEvent，不建议作为长期查询主字段 |
occurred_at_text |
原文时间，例如“1937年”“1960年4月30日” |
occurred_at_norm |
兼容旧字段，保留原规范时间 |
start_time_norm |
规范开始时间，允许 YYYY / YYYY-MM / YYYY-MM-DD |
end_time_norm |
区间事件的规范结束时间 |
date_granularity |
year / month / day / range / unknown，避免把 1940-03 强行伪造成某一天 |
dynasty / century |
可选，支持按朝代/世纪聚合 |
description |
事件说明 |
location_name |
事件发生地点 |
participants |
参与人物或机构 |
details |
子类专属字段，例如荣誉名称、颁发方、影视作品名、到访人物、维护原因 |
evidence_quote/source_url/source_section |
溯源 |
前端知识抽屉展示时可以只展示“发生时间：1937年”，底层保留 occurred_at_norm 用于排序和时间查询。
7.2 Event 两级分类
| 一级分类 | 适用范围 | 常见二级子类 |
|---|---|---|
HISTORICAL 历史事件 |
始建、更名、营造、重修、名人到访、居住创作、纪念事件 | FOUNDING / RENAMING / CONSTRUCTION / REBUILD / FAMOUS_VISIT / RESIDENCE_OR_CREATION / MEMORIAL |
HONOR 荣誉认定 |
景区评级、文保认定、官方荣誉、保护名录 | AWARD / PROTECTION_LISTED |
CULTURAL 文化活动 |
节庆、演艺、影视取景、展览、民俗活动 | FESTIVAL / PERFORMANCE / FILMING / EXHIBITION / CULTURAL_ACTIVITY |
NATURAL 自然生态 |
季节景观、生态观测、水文、地质、气候观测 | SEASONAL / NATURAL_OBSERVATION |
OPERATIONAL 运营维护 |
开闭园、维护停业、施工、运营调整 | MAINTENANCE / OPENING_OR_CLOSURE |
TRANSPORTATION 交通事件 |
交通开通、线路变化、接驳调整 | TRANSPORT_CHANGE |
7.3 details 字段策略
details 不是让 LLM 随便塞内容，而是按 event_subtype 限定推荐字段：
| 二级子类 | 推荐 details 字段 |
|---|---|
AWARD |
award_name / awarded_by_name / award_level / batch |
PROTECTION_LISTED |
protection_level / listed_by / batch |
FAMOUS_VISIT |
visitor_names / visit_purpose / work_produced |
RESIDENCE_OR_CREATION |
person_names / work_produced / residence_reason |
FILMING |
work_title / work_type / director_names / actor_names / release_year |
FESTIVAL |
recurrence / organizer_names / expected_visitors |
NATURAL_OBSERVATION |
measured_metric / measured_value / measured_unit / measurement_org |
MAINTENANCE |
maintenance_reason / affected_areas / fully_closed |
7.4 查询示例
-- 某景区所有事件，按时间排序
MATCH (s:ScenicArea)-[:HAS_EVENT]->(e:Event)
WHERE s.name = '花溪公园'
RETURN e.name, e.event_category, e.event_subtype, e.start_time_norm
ORDER BY e.start_time_norm
-- 查询所有名人到访事件
MATCH (e:Event)
WHERE e.event_subtype = 'FAMOUS_VISIT'
RETURN e.name, e.participants, e.start_time_norm, e.location_name
ORDER BY e.start_time_norm
-- 查询所有荣誉/文保类事件
MATCH (e:Event)
WHERE e.event_category = 'HONOR'
RETURN e.name, e.event_subtype, e.details, e.start_time_norm
ORDER BY e.start_time_norm DESC
7.1 媒体与照片字段
图片不要只用一个 photo_urls 混装。建议分两类：
| 类型 | 存储方式 | 说明 |
|---|---|---|
| 普通展示照片 | entity.photo_urls / cover_image_url，同时保留 MediaAsset(media_role=poi_photo/scenic_photo/attraction_photo) |
用于前端轮播和详情展示 |
| 功能型媒体 | MediaAsset(media_role=guide_map/route_map/panorama)，并回填到 guide_map_urls / route_map_urls / panorama_urls |
导游图、导览图、线路图、全景图，不与普通照片混用 |
| 景点照片 | 挂到具体 Attraction |
例如“百步桥”小节图片必须挂到百步桥，不默认挂到花溪公园；自然景观/文化点通过 Attraction.category 区分 |
| 未命中实体的泛景色图 | 进入待审核或暂不入图 | 避免主景区被大量无归属照片污染 |
7.2 交通与到达字段
百科里的“交通线路/交通指引”不要硬造不存在的乘车点和路线模板。系统已经有全市公交图谱时，百科只负责识别“哪些线路可达景区”，再与已有 BusLine 对齐：
| 节点/关系 | 存储内容 |
|---|---|
BusLine |
公交/中巴/大巴线路号，例如 90路、89路、109路、201路 |
ScenicArea -[:ACCESSIBLE_BY]-> BusLine |
景区可由某线路经过或到达 |
BusLine -[:STOPS_AT]-> TransitFacility |
由高德/公交图谱提供，不从百科交通段硬造 |
ScenicArea -[:NEAR_TRANSIT]-> TransitFacility |
由空间距离或公交站点数据计算，不从百科起点列表硬造 |
RouteTemplate |
只用于景区内部游览路线或人工策划玩法，不用于普通百科公交段 |
7.3 景区内部通行路径字段
百科、攻略、导览图和运营人员实测里经常出现“从 A 到 B，步行/观光车/摆渡船 X 分钟，费用 Y 元”这类事实。它不是事件，也不是普通描述，应该作为景区内部路径网络保存。这个网络只解决景区内部明确点位之间的到达问题；城市级“附近有什么餐饮/酒店/医疗”仍然走 H3/POI 召回。
| 节点/关系 | 存储内容 |
|---|---|
Attraction |
景区内部路径端点。百步桥、东舍、大门、码头、花溪小吃城等都在这层，用 category/spot_type 区分 |
RouteSegment |
一段固定通行路段，保存起点、终点、方式、时间、费用、季节、是否双向和实测来源 |
TransportMode |
到达方式字典，例如步行、观光车、摆渡船、索道、景区电梯，用于统一图标和默认是否免费 |
PathSchedule |
非步行路径的班次，例如观光车每 15 分钟一班、摆渡船 08:30-17:00 每 30 分钟一班 |
ScenicArea -[:HAS_PART]-> Attraction |
景区包含某个景点、入口或官方推荐服务点 |
ScenicArea -[:HAS_ROUTE_SEGMENT]-> RouteSegment |
景区拥有某条已知通行路段 |
RouteSegment -[:USES_TRANSPORT_MODE]-> TransportMode |
路段使用某种到达方式 |
RouteSegment -[:SEGMENT_STARTS_AT]-> Attraction |
路段起点，等价于 attraction_path.from_id |
RouteSegment -[:SEGMENT_ENDS_AT]-> Attraction |
路段终点，等价于 attraction_path.to_id |
RouteSegment -[:HAS_SCHEDULE]-> PathSchedule |
非步行路径具有班次或开放时段 |
Attraction -[:SCENIC_PATH_TO {transport_mode, duration_min, duration_max, cost_fen, cost_text, cost_in_ticket, is_bidirectional, segment_id}]-> Attraction |
快速查询边，保存到达方式、时间和费用 |
到达方式建议统一枚举：walk 步行、sightseeing_bus 观光车、shuttle_boat 摆渡船、cableway 索道、elevator 景区电梯、escalator 扶梯、bike 骑行、other 其他。费用用 cost_fen 保存整数分，展示用 cost_text；免费或含在门票内可用 cost_fen=0 且 cost_in_ticket=true。如果上下坡、单行车或船线导致正反向耗时不同，就不要设双向，分别存两条有方向的路径。
示例：花溪公园大门 -[:SCENIC_PATH_TO {transport_mode:"walk", duration_min:25, duration_max:30, cost_fen:0, cost_in_ticket:true, segment_id:"seg_huaxi_gate_to_snack_city"}]-> 花溪小吃城。用户问“从大门到小吃城走多久”或“从百步桥到东舍怎么走”时，系统先做实体对齐，再在 SCENIC_PATH_TO/RouteSegment 上按时间或距离算路径。
景点本身也要能表达独立运营信息：
| 字段 | 说明 |
|---|---|
open_time / close_time |
景点独立开放时间。没有独立开放时间时为空，继承景区主体 |
extra_ticket_fen / extra_ticket_text |
景点额外收费。免费或含在景区票内用 0，未知不要编造 |
ticket_included |
是否包含在景区大门票内 |
visit_duration_min |
建议游览时长，便于路线规划和问答 |
is_active |
是否仍开放或可游览 |
RouteSegment 建议字段：
| 字段 | 说明 |
|---|---|
from_entity_id / to_entity_id |
起点和终点，可指向入口、景点、设施或官方推荐服务点 |
transport_mode |
到达方式枚举 |
duration_min / duration_max / duration_text |
通行时间 |
distance_m |
路段距离，运营采集或地图测算后补充 |
cost_fen / cost_text / cost_in_ticket |
通行费用，单位分，展示保留原文 |
is_bidirectional |
正反向是否一致；上坡下坡、单行观光车要拆两条 |
season_start / season_end |
季节性开放月份 |
weather_restrict |
天气限制，例如雨天停运、大风停航 |
sort_order |
同一对点多种方式的推荐排序 |
route_geometry / route_steps |
后期运营实测路线轨迹和分步说明 |
PathSchedule 只给非步行方式使用：
| 字段 | 说明 |
|---|---|
schedule_type |
fixed 固定时刻或 interval 间隔发车 |
interval_min |
每 N 分钟一班 |
first_at / last_at |
首班、末班时间 |
capacity |
每班运力 |
note |
运营说明 |
8. 核心关系
| 关系 | Source | Target | 说明 |
|---|---|---|---|
LOCATED_IN |
景区/景点/设施 | 区域/景区 | 位于某行政区或景区内 |
HAS_PART |
景区 | 景点/自然景观/文化点/设施 | 景区包含组成部分 |
PART_OF |
景点/设施 | 景区 | 反向归属 |
HAS_NATURAL_FEATURE |
景区 | 自然景观 | 景区具有自然资源 |
HAS_CULTURAL_SITE |
景区 | 文化点位 | 景区具有文化遗迹 |
HAS_FACILITY |
景区 | 设施 | 景区具有服务设施 |
HAS_EVENT |
景区/人物/机构 | 事件 | 关联历史、建设、到访、保护、荣誉事件 |
EVENT_AT |
事件 | 景区/景点/区域 | 事件发生地点 |
INVOLVES |
事件 | 人物/机构/景区 | 事件参与方 |
PARTICIPATED_IN |
人物/机构 | 事件 | 人物或组织参与某事件，便于“徐霞客到访过哪些景点”这类查询 |
AWARDED_BY |
事件 | 机构 | 荣誉、评级、文保认定由某机构颁发或公布 |
ORGANIZED_BY |
事件 | 机构 | 节庆、演艺、展览等文化事件由某机构举办 |
PRECEDED |
事件 | 事件 | 事件先后关系，用于历史时间线和流程查询 |
PART_OF_EVENT |
事件 | 事件 | 子事件属于大型事件或阶段性事件 |
ASSOCIATED_WITH_PERSON |
景区/事件 | 人物 | 名人、建设者、游历者、纪念对象 |
MANAGED_BY |
景区 | 机构 | 管理或运营关系 |
HAS_CONCEPT |
景区/景点/事件 | 概念 | 主题标签和语义概念 |
HAS_ROUTE |
景区 | 路线 | 景区内部游览路线或人工策划玩法 |
ROUTE_STARTS_AT |
路线 | 交通设施/区域 | 路线起点或乘车点 |
ROUTE_ENDS_AT |
路线 | 景区/景点 | 路线终点 |
ROUTE_USES_LINE |
路线 | 交通线路 | 可乘坐的公交/中巴/大巴/地铁线路 |
ACCESSIBLE_BY |
景区/景点 | 公交线路 | 景区可由某公交/中巴/大巴线路经过或到达，入图前与已有 BusLine 对齐 |
STOPS_AT |
交通线路 | 交通设施 | 线路停靠站点 |
NEARBY_ATTRACTION |
景区 | 景区/景点 | 周边联动景点 |
HAS_ENTRANCE |
景区 | 景点 | 景区具有某入口或门区，目标仍是 Attraction(category=entrance_gate) |
NEARBY_SERVICE |
景区/景点 | 景点 | 官方材料明确推荐、可接入游览路径的服务点，目标仍是 Attraction(category=nearby_service) |
HAS_ROUTE_SEGMENT |
景区 | 路段 | 景区拥有某段内部通行路径 |
USES_TRANSPORT_MODE |
路段 | 到达方式 | 路段使用某种交通/移动方式 |
SEGMENT_STARTS_AT |
路段 | 景点 | 路段起点，等价于 attraction_path.from_id |
SEGMENT_ENDS_AT |
路段 | 景点 | 路段终点，等价于 attraction_path.to_id |
HAS_SCHEDULE |
路段 | 班次 | 观光车、摆渡船、索道等路段的班次 |
SCENIC_PATH_TO |
景点 | 景点 | 景区内部可通行边，关系属性保存方式、耗时、费用和是否双向 |
HAS_SPECIALTY |
景点/景区 | 小吃/特产 | 服务型景点或景区具有某类地方风味 |
NEAR_TRANSIT |
景区 | 交通设施 | 周边公交、地铁、车站 |
HAS_MEDIA |
景区/景点 | 媒体 | 图片、视频。优先挂到最具体的景点/文化点/自然景观 |
MENTIONED_IN |
实体/事件/事实 | 来源文档 | 溯源 |
SAME_AS |
实体 | 实体 | 实体对齐，防止重复景点 |
IN_H3_R9 |
有经纬度实体 | GeoCell | 空间召回 |
9. Statement 策略
正式关系不能让 LLM 随便造。建议：
- 高频通用事实进入正式字段或正式关系。
- 长尾事实进入
Statement。 - LLM 发现新关系名时进入
schema_gaps，人工确认后再升级。
例如：
| 情况 | 存储方式 |
|---|---|
| 花溪公园门票 6 元 | ScenicArea.ticket_price 或 HAS_TICKET_PRICE |
| 戴安澜将军墓是爱国主义教育基地 | Statement，后续可升级为 HAS_CONCEPT -> 红色教育 |
| 某景点有“九寺八庙五阁” | Statement 或拆为多个 HAS_PART，视证据质量决定 |
10. 抽取输出约束
DeepSeek 或多模型抽取必须输出同一结构：
{
"entities": [],
"events": [],
"concepts": [],
"relations": [],
"statements": [],
"media_assets": [],
"schema_gaps": [],
"quality": {}
}
最低要求：
| 类型 | 必须有 |
|---|---|
| Entity | ID、名称、类型、说明、证据、来源 URL、置信度 |
| Event | 时间、事件名、类型、说明、证据、来源 URL、置信度 |
| Concept | 概念名、类型、说明、证据 |
| Relation | 关系名、Source、Target、说明 |
| Statement | 主语、谓词、宾语、证据、对象类型 |
| MediaAsset | URL、归属实体、来源章节、来源 URL |
媒体归属规则：
- 如果媒体
section/caption/alt与子实体名称一致，直接挂到该子实体。 - 如果媒体只属于“基本信息、结构布局、主要景点”等总览小节，才挂到景区主体。
- 入图时同时创建
实体 -[:HAS_MEDIA]-> MediaAsset，并把 URL 回填到实体photo_urls/cover_image_url，方便知识抽屉和游客页面展示。
11. 入图流程
推荐流程：
flowchart TD
A["百度百科/高德/人工材料"] --> B["统一 LLM 深度抽取"]
B --> C["输出 Entity/Event/Concept/Relation/Statement/Media"]
C --> D["Entity Alignment 合并已有 POI/景区"]
D --> E["Schema Lint 检查关系名和字段"]
E --> F["低置信/冲突进入人工审核"]
F --> G["发布到正式图谱"]
G --> H["空间字段写入 H3/PostGIS 索引"]
12. 当前替换建议
不要直接用这版覆盖线上 guiyang_new2。建议先做三步：
- 用 5 个不同类型景点测试抽取：公园、自然山岳、古镇、红色遗址、城市地标。
- 人工检查抽取是否能覆盖 80% 高频字段。
- 再迁移线上 Schema，并写入 Entity Alignment 规则，避免“一个景点两个节点”。