# 知识抽取入图前的实体对齐与发布策略

## 为什么不能直接把抽取结果写成新节点

城市知识图谱已经有高德 API 采集来的 POI 骨架数据，包括：

- `element_id / place_id`
- 名称、地址、类别、评分、开放时间
- 经纬度
- 公交站、地铁站、线路等交通节点
- 原图谱已有的 `LOCATED_IN / HAS_TAG / STOPS_AT` 等关系

百科、网页、小红书、抖音抽取出来的知识，通常是语义知识，例如：

- 历史事件
- 文化概念
- 景点组成
- 票价、面积、美誉、建议游玩时长
- 周边景点

如果直接把抽取结果写成 `ent_huaxi_park` 这种新节点，就会丢掉原 POI 的空间能力和交通关系，形成两个“花溪公园”：

```text
高德花溪公园：有经纬度、评分、交通关系
百科花溪公园：有历史、事件、概念、属性
```

这不是生产级图谱。正确做法是：**高德 POI 作为 Anchor，非结构化抽取结果作为 Evidence 和 Knowledge Patch。**

## 正确流程

```text
1. 高德/API 数据入图
   -> 形成 Anchor Layer
   -> Place 节点带坐标、地址、类别、评分、交通关系

2. 百度百科/网页/小红书/抖音采集
   -> 保存为 Evidence

3. kg_schema_v1 抽取
   -> Entity / Event / Concept / Relation / Statement / SchemaProposal

4. Entity Alignment
   -> 把抽取实体和已有图谱实体做对齐
   -> exact match / possible match / new candidate / conflict

5. Conflict Resolution
   -> 无冲突且分数 >= 0.8：自动发布
   -> 模型不一致、低分、实体歧义、字段冲突：人工审核

6. Publish
   -> 把事件、概念、属性、关系挂到已有 Anchor 节点
   -> 保留 evidence_quote、confidence、source
```

## Anchor 优先规则

对于城市 KG，实体主键优先级：

```text
1. 高德 element_id / place_id
2. 官方数据源 ID
3. 已有图谱 canonical id
4. LLM 抽取 temp_id
```

LLM 生成的 `temp_id` 只用于本次抽取内部引用，不能直接当作生产主键。

例如：

```text
ent_huaxi_park
  -> SAME_AS
amap:B035300A51
```

正式查询应优先查：

```cypher
MATCH (p:Place {element_id:'amap:B035300A51'})-[r]->(m)
RETURN p,r,m
```

而不是只查：

```cypher
MATCH (p {id:'ent_huaxi_park'})-[r]->(m)
RETURN p,r,m
```

## 对齐结果类型

| 类型 | 含义 | 是否自动发布 |
|---|---|---|
| `SAME_AS` | 基本确定是同一实体 | 是 |
| `POSSIBLE_MATCH` | 很可能相关，但名称/类型存在歧义 | 不直接合并，进入人工或低风险关系 |
| `RELATED_TO` | 相关但不是同一实体 | 可发布关系，不合并节点 |
| `NEW_CANDIDATE` | 图谱中不存在的新实体 | 分数 >= 0.8 可候选发布 |
| `CONFLICT` | 与已有高可信字段冲突 | 人工审核 |

## 字段冲突处理

字段不能简单覆盖。按来源权重和语义含义处理：

```text
高德 open_time = 08:30-18:30
百科 opening_hours = 全天开放；收费时段8:30-18:00
```

这不是马上覆盖，而应保留为：

```text
p.open_time = 高德开放时间
p.kg_opening_hours = 百科抽取开放时间
```

同时写入 provenance：

```text
source = amap / baike
confidence
evidence_quote
updated_at
```

如果两个来源表达同一字段但明显冲突，再创建人工审核项。

## 交通关系必须来自已有图谱或空间计算

百科不会可靠提供公交/地铁网络。交通可达应来自：

```text
高德 POI 坐标
公交/地铁站点 POI
公交线路 STOPS_AT 关系
空间距离计算
路线时间 API 或缓存
```

推荐关系：

```text
(:Place)-[:NEAR_TRANSIT {distance_m, station_type}]->(:Place)
(:BusLine)-[:STOPS_AT {seq}]->(:Place)
(:Place)-[:NEARBY_ATTRACTION]->(:Place)
```

这样后续用户问：

```text
我怎么去花溪公园？
花溪公园附近有什么公交地铁？
我到青岩古镇能不能顺路去花溪公园？
```

系统能先从目的地 POI 找附近交通节点，再结合线路和路线时间回答。

## Auto Schema 在这里应该做什么

Auto Schema 不是替代已有业务脑子，也不是让模型随便改图谱。它应该做：

```text
抽取中发现新类型/关系/字段
  -> 形成 Schema Proposal
  -> 统计来源数量、证据数量、置信度
  -> 人工或规则审核
  -> 版本化升级 schema
```

例如：

```text
NEAR_TRANSIT
NEARBY_ATTRACTION
HAS_OPENING_HOURS
HAS_SCENIC_LEVEL
ManagementChangeEvent
```

这些可以进入 proposal，但事实数据不需要等待 schema 审核全部完成，稳定关系可以先以候选关系入图。

## 花溪公园当前修正结果

当前已把 `kg_schema_v1` 抽取结果对齐回高德锚点：

```text
canonical: amap:B035300A51
name: 花溪公园
lat/lng: 保留高德坐标
kg_description / kg_opening_hours / kg_scenic_level: 来自百科抽取
HAS_EVENT: 9
HAS_CONCEPT: 6
HAS_PART: 7
NEAR_TRANSIT: 7
NEARBY_ATTRACTION -> 青岩古镇: 已对齐到 amap:B035300ESE
```

对应脚本：

```text
scripts/align_huaxi_kg_with_existing_graph.py
```