# 城市 POI 证据抽取约束 v0.1

## 1. 证据优先

- 每个事实必须来自原文 Markdown 或高德 POI anchor 字段。
- 证据中没有出现的字段不能编造。
- 只能用短引文作为 `source_spans.quote`，不能把整篇文章复制进抽取结果。
- 百度百科原文可作为公开百科证据，但仍需和高德 POI、官方文旅/机构网站、点评/社媒证据交叉验证。

## 2. 实体对齐

先判断证据是否指向当前高德 POI：

- 名称一致或别名一致。
- 地址/区县/城市一致。
- 类别一致或可解释为同一业务场景。
- 如果百科词条跳到同名词条或更大区域，必须标记为 `entity_match=false` 或 `needs_review=true`。

禁止因为文本中出现一个地点名就新建重复 POI。新实体只可作为 `Facility`、`Area`、`Organization`、`Person`、`Route`、`ProductOrService` 等附属实体进入候选层。

## 3. 字段写入

- 高德字段：名称、坐标、地址、区县、typecode 是 anchor，不被百科/社媒直接覆盖。
- 软字段：历史、特色、服务、路线、价格提示、开放时间、适用人群等可以由证据补充。
- 冲突字段：如果不同来源有矛盾，写入 `conflict` 或人工审核，不自动覆盖。
- 时效字段：营业时间、价格、电话、评分等必须带来源时间；旧百科内容只能作为低时效证据。

## 4. Schema Proposal

发现稳定但 schema 中没有的字段/关系时：

```json
{
  "proposal_type": "field|relation_type|entity_type|event_type|concept_type",
  "name": "字段或关系名",
  "reason": "为什么城市 KG 需要它",
  "examples": ["来自原文的短证据"],
  "confidence": 0.0
}
```

proposal 只进入候选区，不能直接升级生产 schema。

## 5. 场景抽取优先级

1. 先抽通用字段：名称、别名、地址、区县、类别、开放时间、价格、联系方式、官方网站/来源。
2. 再抽场景字段：例如景点的门票/路线/历史，美食的招牌菜/口味，医疗的科室/急诊。
3. 最后抽关系：位于、邻近、包含设施、运营单位、提供服务、相关事件、适合人群。
4. 不确定内容进入 `uncertain` 或 `schema_proposals`，不进入正式事实。