Files
bxh/docs/kg-redesign/scenic_spot_schema_v0_2.md

414 lines
24 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 通用景区知识图谱 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 规则,避免“一个景点两个节点”。