# 通用景区知识图谱 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 分成四层。核心层级必须保持简单：

```text
ScenicArea（景区）
  └── Attraction（景点/入口/景区内可导航点）
        └── AttractionPath / RouteSegment（景点 → 景点）
```

也就是说，路径的 `from_id / to_id` 统一指向 `Attraction`，不再使用 `sub_attraction` 这种容易混乱的名字。自然景观、文化点、入口、码头、小吃城这类差异，通过 `Attraction.category / spot_type` 区分。

完整 Schema 分层如下：

1. 景区主体层：`ScenicArea`
2. 景点与设施层：`Attraction / Facility / TransitFacility`
3. 语义知识层：`Event / Concept / BusLine / RouteTemplate / Person / Organization`
4. 溯源与候选层：`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”的方案：

1. `event_category`：一级分类，用于聚合统计。
2. `event_subtype`：二级子类，用于精确查询。
3. `event_type`：兼容旧系统的展示别名，不作为主要查询字段。
4. `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 查询示例

```cypher
-- 某景区所有事件，按时间排序
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
```

```cypher
-- 查询所有名人到访事件
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
```

```cypher
-- 查询所有荣誉/文保类事件
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 随便造。建议：

1. 高频通用事实进入正式字段或正式关系。
2. 长尾事实进入 `Statement`。
3. LLM 发现新关系名时进入 `schema_gaps`，人工确认后再升级。

例如：

| 情况 | 存储方式 |
|---|---|
| 花溪公园门票 6 元 | `ScenicArea.ticket_price` 或 `HAS_TICKET_PRICE` |
| 戴安澜将军墓是爱国主义教育基地 | `Statement`，后续可升级为 `HAS_CONCEPT -> 红色教育` |
| 某景点有“九寺八庙五阁” | `Statement` 或拆为多个 `HAS_PART`，视证据质量决定 |

## 10. 抽取输出约束

DeepSeek 或多模型抽取必须输出同一结构：

```json
{
  "entities": [],
  "events": [],
  "concepts": [],
  "relations": [],
  "statements": [],
  "media_assets": [],
  "schema_gaps": [],
  "quality": {}
}
```

最低要求：

| 类型 | 必须有 |
|---|---|
| Entity | ID、名称、类型、说明、证据、来源 URL、置信度 |
| Event | 时间、事件名、类型、说明、证据、来源 URL、置信度 |
| Concept | 概念名、类型、说明、证据 |
| Relation | 关系名、Source、Target、说明 |
| Statement | 主语、谓词、宾语、证据、对象类型 |
| MediaAsset | URL、归属实体、来源章节、来源 URL |

媒体归属规则：

1. 如果媒体 `section/caption/alt` 与子实体名称一致，直接挂到该子实体。
2. 如果媒体只属于“基本信息、结构布局、主要景点”等总览小节，才挂到景区主体。
3. 入图时同时创建 `实体 -[:HAS_MEDIA]-> MediaAsset`，并把 URL 回填到实体 `photo_urls/cover_image_url`，方便知识抽屉和游客页面展示。

## 11. 入图流程

推荐流程：

```mermaid
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`。建议先做三步：

1. 用 5 个不同类型景点测试抽取：公园、自然山岳、古镇、红色遗址、城市地标。
2. 人工检查抽取是否能覆盖 80% 高频字段。
3. 再迁移线上 Schema，并写入 Entity Alignment 规则，避免“一个景点两个节点”。