xuelong/bxh

Fork 0

Files

3452078359-xuexue 0594fc9f8c Polish project documentation and runtime config

2026-06-09 10:22:59 +08:00

4.9 KiB

Raw Blame History

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

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

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

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

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

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

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

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

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

正确流程

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，实体主键优先级：

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

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

例如：

ent_huaxi_park
  -> SAME_AS
amap:B035300A51

正式查询应优先查：

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

而不是只查：

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

对齐结果类型

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

字段冲突处理

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

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

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

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

同时写入 provenance：

source = amap / baike
confidence
evidence_quote
updated_at

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

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

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

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

推荐关系：

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

这样后续用户问：

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

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

Auto Schema 在这里应该做什么

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

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

例如：

NEAR_TRANSIT
NEARBY_ATTRACTION
HAS_OPENING_HOURS
HAS_SCENIC_LEVEL
ManagementChangeEvent

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

花溪公园当前修正结果

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

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

对应脚本：

scripts/align_huaxi_kg_with_existing_graph.py

4.9 KiB Raw Blame History Unescape Escape