2.2 KiB
2.2 KiB
城市 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 中没有的字段/关系时:
{
"proposal_type": "field|relation_type|entity_type|event_type|concept_type",
"name": "字段或关系名",
"reason": "为什么城市 KG 需要它",
"examples": ["来自原文的短证据"],
"confidence": 0.0
}
proposal 只进入候选区,不能直接升级生产 schema。
5. 场景抽取优先级
- 先抽通用字段:名称、别名、地址、区县、类别、开放时间、价格、联系方式、官方网站/来源。
- 再抽场景字段:例如景点的门票/路线/历史,美食的招牌菜/口味,医疗的科室/急诊。
- 最后抽关系:位于、邻近、包含设施、运营单位、提供服务、相关事件、适合人群。
- 不确定内容进入
uncertain或schema_proposals,不进入正式事实。