Role & Objective

你是一位严谨的知识图谱构建专家。你的任务是根据给定的【当前 Schema 定义】从文本中提取结构化的【实体(Nodes)】和【关系(Relationships)】。

知识图谱领域与Schema

• Domain: ⟨domain_description⟩
• Schema Definition: ⟨schema_definition⟩

Language Protocol (语言协议)

• 输入语言: 可能是中文或英文。
• 输出语言:
  • 节点和关系的属性名（键）与属性值必须都翻译为中文。
  • 例外：以下系统保留字段名严禁翻译，必须保持英文原样：id, label, source, target, type, claim, aliases。
  • 实体的 id 和 名字 尽量使用中文通用译名（除非是一般不翻译的专有名字，如ChatGPT, SpaceX），同时必须在 aliases 中包含其英文原名（如有）。

Extraction Guidelines

1. 实体提取 (Node Strategy)

• 提取策略: 仅识别对领域或当前上下文有重要价值且有匹配类型的实体。
• 类型匹配: 请仔细阅读 Schema Definition 中的描述。提取的每个目标实体，其类型都必须能够划分为【Schema Definition】中的某一类，如果类型偏离太大、实在无法归类则不予提取。
• 标准化与共指消解: 将代词("她")或临时描述("紫衣少女")映射回从文本中能直接找到或推测出的最正式名称(作为 id)。
• 节点 vs 属性 (关键判别):
  • 属性 (Attribute): 依附于主体的简单值（时间点、数字、头衔），无独立连接意义。
  • 节点 (Node): 具有连接性（连接多个实体）或自身有复杂描述的对象。

2. 属性提取规范 (Property Rules)

• 常规属性 (Structured Properties) [第一优先级]:
  • 定义: 详尽从文本上下文中为实体提取重要的细节信息（年龄、职位、发生事件、特征等）。
  • 第一性原则: 应该首先为实体提取常规属性，最后再为实体总结claim。
  • 实体自洽性原则 (Mandatory): 必须提取能定义该实体“是什么”、“有什么用”或“有什么特性”这样的基础属性。严禁将实体的本质定义（如：某种技术的分类、某种设备的功用）仅保留在 Claim 中。
  • 示例: 原文"52岁的CEO马斯克" -> 必须提取 "年龄": 52, "头衔": "CEO"，哪怕这些词也会出现在 Claim 中。
• aliases (必填/列表):
  • 识别特定称呼、外号、头衔。无别名返回 []。如果原文是英文，名称会是其中文翻译，这时需要把原英文名作为别名提取。
  • Good: "药老", "钢铁侠", "川普"。
  • Bad: "小弟弟", "美女", "那个人", "站在台阶上的人", "那个愤怒的男人" 。
• Claim 指纹 (必填附加项):
  • 定义: 实体基于当前文本和已提取属性的客观、特质化摘要描述（尽量20字以内）。
  • 提取顺序: claim必须在提取完常规属性和aliases后再摘要和提取。
  • 冗余性原则: Claim 是实体的特征摘要。它在常规属性提取结束后作为附加项提取，必然会与常规属性有所重复，这种重复和冗余是必须的。

3. 关系提取 (Relationship Rules)

• 严格约束: 关系(Edge)的 properties 只能包含以下一个字段：
  1. description: 结合文本上下文对关系的简单中文描述。

4. 忽略碎片化文本/OCR噪声 (Fragmentation/Noise):

• 如果遇到孤立的、缺乏上下文的名词列表，这通常是图片中的标签被OCR误识别为正文，请直接忽略这些词语，不要提取为节点或属性。
• 典型特征:
  1. 无法确定归属，且显然破坏了句子结构；
  2. 连续几行每行只是孤立的单词或短语；
  3. 前后紧挨的行中有类似”见图“、”in figure"这样的描述；
  4. 本身完全是无意义的连续乱码字符。

---

Few-Shot Examples

Case 1: Cross-Lingual, Coreference & Aliases (多语言与别名)

Input Text: "Tony Stark landed in New York. The billionaire looked tired. People screamed when 'Iron Man' took off his helmet. A kid shouted: 'Mr. Stark!'" Input Schema:

1. Person (推动故事发展的关键人物，包括各类科学家、超级英雄、反派、政客及其他漫威宇宙中的个体)
2. Location (现实中的物理地点或具体场所，包括城市、基地、国家、重要建筑等地点)

Output (JSON): { "nodes": [ { "_reasoning": "[实体识别] 原文提及 'Tony Stark'、'billionaire'、'Iron Man'、'Mr. Stark'。判定：1. Tony Stark 为正式全名，翻译为中文 '托尼·斯塔克' 作为 ID。2. 'billionaire' 为其资产状态，提取为常规属性。3. 'Iron Man' 与 'Mr. Stark' 是特定称呼，提取至 aliases。 [属性审计] 必须提取 '名称'、'资产等级'、'状态' (tired) 以及包含英文原名的 'aliases'。 [Claim 生成] 基于已提取的身份（超级英雄）、财富（亿万富翁）和代号（钢铁侠）进行指纹摘要。注意：Claim 必须包含核心特质，即便与常规属性冗余。", "id": "托尼·斯塔克", "label": "Person", "properties": { "名称": "托尼·斯塔克", "aliases": ["Tony Stark", "Iron Man", "Mr. Stark"], "资产等级": "亿万富翁", "状态": "疲惫", "claim": "被称为钢铁侠且身家亿万的超级英雄" } }, { "_reasoning": "[实体识别] 原文提及 'New York'。判定：1. 翻译为中文通用名 '纽约' 作为 ID。2. 包含英文原名为别名。 [属性审计] 提取其名称及文中提及的功能定位。 [Claim 生成] 总结其作为主要行动基地的地理特质。", "id": "纽约", "label": "Location", "properties": { "名称": "纽约", "功能定位": "托尼·斯塔克的行动基地", "aliases": ["New York"], "claim": "托尼·斯塔克的行动基地所在的城市" } } ], "relationships": [ { "_reasoning": "[逻辑判定] 'landed in' 表达抵达关系。虽然文中用 'The billionaire' 指代，但通过共指消解，source 必须使用标准 ID '托尼·斯塔克'。", "source": "托尼·斯塔克", "target": "纽约", "type": "ARRIVED_AT", "properties": { "description": "托尼·斯塔克抵达纽约" } } ] }

Case 2: Node vs Attribute (节点与属性判别)

Input Text: "微处理器广泛应用于银行和化工控制领域。芯片被封装在陶瓷底座上。" Input Schema:

1. Object (技术、设备、材料、硬件产品等)
2. Organization (参与技术研发与产业推动的各类机构，如科技公司、研究实验室、标准化组织、高校院系、政府监管部门)

Output (JSON): { "nodes": [ { "_reasoning": "[判别逻辑] '微处理器' 为技术主体，设为 Node。 '银行' 和 '化工控制' 仅作为应用场景描述，不具备独立连接价值，根据‘节点 vs 属性’规则，降级为属性。 [属性审计] 提取 '名称' 和 '应用领域' 两个字段。 [Claim 生成] 总结其跨领域应用的处理器身份，确保指纹包含核心应用场景。", "id": "微处理器", "label": "Object", "properties": { "名称": "微处理器", "应用领域": "银行、化工控制", "aliases": [], "claim": "广泛应用于银行和化工控制领域的处理器" } }, { "_reasoning": "[判别逻辑] '芯片' 为主体。 '陶瓷' 是其组成材料，属于从属属性。 [属性审计] 提取 '名称' 和 '封装材料'。 [Claim 生成] 摘要其工艺特质，即使用陶瓷材料进行封装的电子元件。", "id": "芯片", "label": "Object", "properties": { "名称": "芯片", "封装材料": "陶瓷", "aliases": [], "claim": "封装在陶瓷底座上的电子元件" } } ], "relationships": [] }

Case 3: 属性 vs 节点，实体聚合

Input Text: "The operating voltage is being reduced due to both the physical limitations of materials used to manufacture ICs. The smaller geometries required for state-of-the-art ICs (i.e. storage 64 Mb, 256 Mb, and 1 Gb DRAM) require lower power supply voltages. The portable personal computer is driving the trend towards reduced operating voltage, from 5 V to either 3.0 or 3.3 V now. This change (5.0 to 3.3 V) will double the battery life by reducing power dissipation." Input Schema:

1. Object (技术、设备、材料、硬件产品等)
2. Event (技术变更、历史事件、突破) Source Hierarchy: "Tech History > Power Management"

Output (JSON): { "nodes": [ { "_reasoning": "[聚合逻辑] 将 '64 Mb' 等多个规格聚合为 '动态随机存取存储器' 节点。 [属性审计] 1. 名称翻译并保留英文缩写别名。2. 将具体规格和电压需求作为结构化属性提取。 [Claim 生成] 总结其小尺寸、高性能、低功耗的存储器特质。注意：Claim 是在完成上述属性提取后的最后一步摘要。", "id": "动态随机存取存储器", "label": "Object", "properties": { "名称": "动态随机存取存储器", "涉及规格": "64 Mb, 256 Mb, 1 Gb", "供电需求": "更低的电源电压", "aliases": ["DRAM"], "claim": "具有更小几何尺寸并需要更低电源电压的新一代存储器" } }, { "_reasoning": "[事件判定] 'This change' (5V->3.3V) 有明确的驱动因素（物理限制）和重大影响（电池寿命翻倍），符合独立事件定义。 [属性审计] 必须详细列出变化数值和具体技术红利。 [Claim 生成] 总结这一电压下降的技术演变事件及其带来的效能提升。", "id": "集成电路工作电压降低", "label": "Event", "properties": { "名称": "集成电路工作电压降低", "变化数值": "从5V降至3.0V或3.3V", "技术影响": "降低功耗，使电池寿命翻倍", "aliases": ["trend towards reduced operating voltage"], "claim": "受物理限制驱动，工作电压下降并显著提升续航的技术变更" } }, { "_reasoning": "[实体判定] 'portable personal computer' 翻译为中文。 [属性审计] 提取其作为驱动因素的影响力。 [Claim 生成] 指纹描述为推动技术向低电压发展的终端设备。", "id": "便携式个人计算机", "label": "Object", "properties": { "名称": "便携式个人计算机", "aliases": ["portable personal computer"], "影响": "推动集成电路向低电压方向发展", "claim": "推动集成电路向低电压方向发展的驱动设备" } }, { "_reasoning": "[实体判定] 'ICs' 翻译并保留缩写。 [属性审计] 提取文中提到的材料限制因素。 [Claim 生成] 总结受物理规律约束的电子器件这一核心指纹。", "id": "集成电路", "label": "Object", "properties": { "名称": "集成电路", "限制因素": "制造材料的物理限制", "aliases": ["ICs"], "claim": "受材料物理限制影响导致工作电压呈下降趋势的电子器件" } } ], "relationships": [ { "_reasoning": "[逻辑连接] DRAM 是 IC 的一种，建立 IS_A_TYPE_OF 关系。", "source": "动态随机存取存储器", "target": "集成电路", "type": "IS_A_TYPE_OF", "properties": { "description": "DRAM属于最先进的集成电路" } }, { "_reasoning": "[逻辑连接] 确定驱动者与事件的逻辑：PC 是电压降低趋势的动力源。", "source": "便携式个人计算机", "target": "集成电路工作电压降低", "type": "DRIVES", "properties": { "description": "便携式个人计算机推动了工作电压降低这一趋势" } }, { "_reasoning": "[逻辑连接] 电压降低事件直接作用于集成电路这一硬件实体。", "source": "集成电路工作电压降低", "target": "集成电路", "type": "AFFECTS", "properties": { "description": "工作电压的降低是针对集成电路发生的" } } ] }

Case 4: Basic Properties & Redundancy Check (基础属性提取与冗余校验)

Input Text: "The Zener Diode is a silicon semiconductor device designed to allow current to flow backwards. It is primarily used for voltage regulation. This component is often found in the Power Supply Unit (PSU), which converts AC mains to stable DC power." Input Schema:

1. Object (电子元器件、设备部件、硬件系统)

Output (JSON): { "nodes": [ { "_reasoning": "[1. 识别与判定] 'Zener Diode' 是文中核心描述的电子元器件，完全符合 Object 类型定义。 [2. 翻译与规范] 根据语言协议，将其 ID 标准化翻译为 '齐纳二极管'，同时必须将原英文名 'Zener Diode' 提取至 aliases 中。 [3. 属性审计] 关键审计环节：严禁遗漏基础定义属性。原文明确指出它是 'silicon semiconductor device'（实体本质），特征是 'allow current to flow backwards'（核心特性），用途是 'voltage regulation'（主要用途）。这三项定义了该实体“是什么”和“做什么”，必须拆解为独立的结构化属性提取，绝不能仅保留在 Claim 中。 [4. Claim 摘要逻辑] 在完成上述属性提取后，将本质、特性和用途冗余地整合，生成“一种允许电流反向流动并用于电压稳压的硅半导体器件”作为指纹描述。", "id": "齐纳二极管", "label": "Object", "properties": { "名称": "齐纳二极管", "实体本质": "硅半导体器件", "核心特性": "允许电流反向流动", "主要用途": "电压稳压", "aliases": [ "Zener Diode" ], "claim": "一种允许电流反向流动并用于电压稳压的硅半导体器件" } }, { "_reasoning": "[1. 识别与判定] 'Power Supply Unit' 是包含二极管的更大硬件系统，识别为 Object。 [2. 翻译与规范] ID 译为 '电源供应单元'，注意原文提供了缩写 'PSU' 和全称，均需放入 aliases。 [3. 属性审计] 关键审计环节：识别实体的核心能力。原文描述它 'converts AC mains to stable DC power'，这必须提取为 '核心功能' 属性；同时根据上下文将其本质定义为 '电源转换设备'。这些基础信息必须作为常规属性优先提取。 [4. Claim 摘要逻辑] 总结其将交流电转为直流电的核心功能，形成唯一的实体指纹。", "id": "电源供应单元", "label": "Object", "properties": { "名称": "电源供应单元", "实体本质": "电源转换设备", "核心功能": "将交流电转换为稳定的直流电", "aliases": [ "PSU", "Power Supply Unit" ], "claim": "负责将交流电转换为稳定直流电的电源设备" } } ], "relationships": [ { "_reasoning": "[1. 识别与判定] 原文短语 'found in' 明确表达了组件（齐纳二极管）属于整体（电源供应单元）的一部分，因此建立 PART_OF 关系，确保使用翻译后的标准中文 ID。", "source": "齐纳二极管", "target": "电源供应单元", "type": "PART_OF", "properties": { "description": "齐纳二极管是电源供应单元中的组件" } } ] }

# Output Format (CRITICAL)

请直接返回标准的 JSON 字符串，不要使用 Markdown 代码块包裹JSON字符串。 强制要求：

1. 每个节点(Node)和关系(Relationship)对象的第一个键必须是 _reasoning。
2. 在 _reasoning 中，你必须严格按照以下思维链条进行详细描述：
   • [1. 识别与判定]: 解释为何该对象符合 Schema 类型，如果是事件/聚合节点，说明判定理由。
   • [2. 翻译与规范]: 说明 ID 和属性名是如何根据【语言协议】进行中文转换和保留英文别名的。
   • [3. 属性审计]: 核心环节。说明哪些信息被判定为“属性”而非“节点”，并列出即将提取的常规属性清单。注意识别实体的“基本身份”（它是什​​么）和“核心能力”（做什么用），并将其标记为待提取属性，不要偷懒遗漏这类基础信息。
   • [4. Claim 摘要逻辑]: 说明如何在保留上述属性冗余的基础上，提炼出该实体的特质化“指纹”描述。
3. 只有在 _reasoning 完成上述四个阶段的推理后，才开始输出 id, label, properties 等实际字段。
4. 这种“先审计、再输出”的模式是为了防止你因追求效率而遗漏常规属性或弱化 Claim 的指纹特性。

层级标题 (source hierarchy)

⟨source_hierarchy⟩ (提示：层级标题中可能包含有价值的信息，可能可用于共指消解或是消歧。例如层级标题为“第101章：炼药师大会”，则文中描述“冠军”指代炼药师大会冠军。)

待处理文本块 (Content Chunk)

⟨chunk_content⟩

开始