Hyper-Extract Incremental Merge Behavior
定义
Hyper-Extract Incremental Merge Behavior 是 he feed 命令在增量更新已有知识抽取结果时执行的合并规则集合。
它发生的前提非常明确：目标路径必须已经是一个现有的知识抽取目录，也就是已经先通过初始抽取生成过知识结果；he feed 不是从零创建知识库，而是把新文档加到已有知识状态之上。
其核心不是“用新结果覆盖旧结果”，而是：
- 先读取当前已有知识状态；
- 再处理新输入文档；
- 然后对新旧实体和关系做智能去重与合并；
- 最后写回更新后的元数据，包括更新时间戳。
因此，这一机制本质上是 he feed - Hyper-Extract 摘要 在增量场景中的知识图合并行为，也是 Hyper-Extract CLI Workflow 中“先构建、后追加、再检索/问答”的关键中间环节。
在命令流程中的语境
he feed 的命令形式是：
he feed KA_PATH INPUT [OPTIONS]
其中：
KA_PATH是现有知识抽取目录的路径；INPUT是要追加处理的新文件路径，或-表示从标准输入读取。
he feed 的描述强调，它会在不丢失现有数据的情况下向已有知识抽取结果中加入新文档。其处理流程可概括为四步：
- 读取现有知识状态；
- 从新文档抽取知识；
- 智能合并新旧数据并处理重复项；
- 更新元数据并记录新的时间戳。
这说明增量合并不是附属行为，而是 he feed 的中心语义。
合并规则
页面明确给出了四类场景下的合并行为。
相同实体：合并，并组合描述
规则原意是：Same entity → Merged, descriptions combined。
也就是说，当新文档里抽取到的实体与现有知识图中的某个实体被判断为同一对象时，系统不会保留两个重复节点，也不会直接用新节点替换旧节点，而是把它们合并为同一个实体，并把描述信息进行组合。
这条规则适合处理同一对象在不同材料中的互补描述。例如一个人物、概念、机构、方法或发明在第一份文档中只出现基本定义，在第二份文档中补充了性质、经历、用途或背景信息，合并后应保留这些互补描述，而不是只留下其中一边。
相同关系：用最新信息更新
规则原意是：Same relation → Updated with latest information。
这表示当系统识别到新文档中的某条关系与已有图中的关系属于同一关系时，会以最新信息更新该关系，而不是简单并列保留两条重复边。
这里的重点有两个：
- 它不是完全无条件地累积每一条重复关系；
- 对关系的重复，更偏向“更新”而不是“描述拼接”。
因此，如果某篇文档的新版本对已有关系给出了更近、更新或修正后的内容，增量合并会倾向让图中的该关系反映最新状态。
新实体：追加到已有知识图
规则原意是：New entities → Added to knowledge abstract。
也就是如果新文档中出现的实体在现有知识图里还不存在，它们会被直接加入到现有知识抽取结果中，扩展节点集合。
这保证了知识库可以随着文档输入持续增长，而不是只能围绕一开始那批节点打补丁。
新关系：追加，并连接现有或新实体
规则原意是：New relations → Added connecting existing/new entities。
当新文档抽取出的关系在当前图中尚不存在时，这些关系会被加入，并把相关节点连接起来；这些被连接的节点既可能都是新加入的实体，也可能是一端是旧实体、另一端是新实体，或者两端都是已有实体但此前尚未建立这条关系。
这意味着增量合并不仅会增加“点”，也会增加“边”，从而改变现有知识图的结构与连通性。
这一机制要解决什么问题
Hyper-Extract Incremental Merge Behavior 的目的，是在不丢失已有数据的前提下，让知识抽取结果能够跨多次输入持续累积。
它主要解决三类问题：
- 持续累积：知识库不是一次性产物，可以随着更多文档逐步扩展；
- 重复对象处理：同一实体或关系在多份文档中重复出现时，不会机械地产生大量重复节点和边；
- 信息更新：后续文档，尤其是新版本文档，可以把较新的关系信息写入现有图。
因此，它特别适合把“分批到达的信息”组织成一个持续演化的知识图，而不是每次都重新从零抽取。
典型适用场景
文档给出的适用场景包括“随时间构建知识抽取结果”“为已有文档追加更新”“合并多个来源的信息”。结合示例，可以归纳出以下几类典型用法。
同一文档的新版本
例如研究资料先有 paper_v1，之后出现 paper_v2。这时可以先做初始抽取，再把新版本喂给已有目录。这样做的价值在于：
- 旧版已经抽取出的概念和关系不会整体丢失；
- 与旧版相同的部分会被识别并合并；
- 新版新增或修正的关系可以更新到图中。
这正是“相同关系用最新信息更新”的典型场景。
相关补充材料
如果主文档之外还有补充说明、更新说明、附录、发明清单、补充背景等材料，可以逐份执行 he feed。这样知识图会逐渐吸收补充材料中的新增实体与关系，而不是要求把所有文本一次性拼成一个超大输入。
多篇论文的汇总
文档中的研究流程示例展示了：初始论文之后，可以继续加入 related work 一类材料。这样做适合把一篇主论文、它的新版本、以及相关工作文档汇总为一个研究知识图，用于后续统一浏览、检索和问答。
传记分阶段累积
文档中的人物示例则采用“早年 → 职业阶段 → 晚年”的分阶段写法。先从早年材料建立知识图，再追加职业阶段，最后追加晚年内容。对人物、组织或事件年表类资料，这种增量合并尤其自然，因为不同时期往往描述的是同一批核心实体，但关系和事件会持续扩展。
操作细节与命令特征
输入可以是文件，也可以是标准输入
INPUT 除了可以是文件路径，也可以传 -，表示从 stdin 读取。例如可以把新内容通过管道送入 he feed。这说明增量合并不依赖必须落地成单独文件，新文本流同样可以触发同样的合并逻辑。
可以连续多次追加
文档直接给出多次连续执行 he feed 的写法，也给出了循环遍历多个文件逐个追加的方式。这说明该机制设计上就是为了支持多轮增量更新，而不是只追加一次。
会更新时间戳
增量合并完成后，元数据会记录新的更新时间。这是判断一次 feed 是否真正写入成功的重要信号之一，也是后续验证步骤的一部分。
约束、边界与效果条件
仅适用于已有知识抽取目录
he feed 的前提是目标目录已经是有效的知识抽取目录。如果目录无效，命令会报“不是有效知识抽取目录”之类的错误。检查时应确认目录中存在必要的数据与元数据文件。
这也界定了该机制的边界：它不是初次抽取命令；初始构建应由其他命令先完成，之后才能谈增量合并。可参见 Hyper-Extract Knowledge Base Directory 了解该目录作为持久化对象的角色。
最佳效果依赖兼容模板
文档的最佳实践和错误处理都强调：增量追加works best with the same template type。也就是说，虽然可以通过 --template 或 -t 覆盖模板，但从合并质量看，最好保持与原有知识图兼容、最好相同类型的模板。
原因很直接：模板决定抽取出的实体类型、关系类型和图结构偏好。如果前后使用的模板类型差异很大，即使能追加，实体和关系的对应方式也可能变得不稳定，进而降低“同实体识别”“同关系更新”的质量。
因此，这里的边界不是“不同模板绝对不能用”，而是“兼容模板、尤其同模板类型，合并效果最好”。
最佳效果依赖语言一致
文档也强调应保持语言一致，必要时可以用 --lang 或 -l 覆盖语言，但最佳实践是让增量追加与原有知识图使用一致语言。
一致语言会改善合并质量，尤其体现在：
- 同一实体是否能稳定识别为同一个对象；
- 相同关系是否更容易被视为同一关系；
- 描述合并时是否更少出现跨语言重复或割裂。
因此，语言不一致并不一定完全阻止执行，但会显著影响增量合并的质量边界。
对搜索与问答的影响有后续步骤
文档建议在 feed 之后执行 he build-index ./ka/，以便搜索和对话使用更新后的内容。这说明增量合并首先更新的是知识抽取结果本身；若要让后续检索与问答能力完整反映新内容，通常还需要重建索引。
如何验证增量合并是否生效
文档给出了明确的验证方式，重点是通过 he show 观察知识图变化，并检查若干可见指标。
使用 he show 查看图谱变化
在研究示例和人物示例中，每次关键追加后都可以执行 he show。这使 he show 成为观察增量合并结果最直接的方法。可结合 Hyper-Extract CLI Retrieval and QA 理解它在浏览知识图中的作用。
关注节点数增加
如果新文档引入了此前不存在的实体，增量合并后节点数应增加。这是“New entities → Added”是否发生的直接证据。
关注边数增加
如果新文档引入了新的关系，或者把已有实体与新实体连接起来，边数应增加。这是“New relations → Added connecting existing/new entities”生效的直接信号。
关注时间戳更新
即使新增内容主要表现为对已有关系的更新，而不是明显增加大量节点或边，元数据中的更新时间戳仍应发生变化。因此，时间戳是判断本次 feed 已完成写回的重要依据。
综合来看，可用以下思路确认增量合并是否生效：
- 先执行一次
he show记录当前图状态； - 执行
he feed追加新文档； - 再次执行
he show比较节点数、边数和可见结构变化； - 同时确认更新时间戳已经刷新。
与整体工作流的关系
在整个 CLI 工作流中，这一机制位于“初始抽取”之后、“检索/问答/索引更新”之前或之间。
典型顺序是：
- 先做初始抽取，建立第一个知识图；
- 在后续拿到新文档时反复执行
he feed； - 用
he show检查图谱变化； - 需要搜索和对话能力时再重建索引并继续使用相关命令。
因此，Hyper-Extract Incremental Merge Behavior 不是孤立规则，而是 Hyper-Extract CLI Workflow 中支撑“知识库持续演化”的核心机制。