AI-Wiki

定义

Auto-Types 是 Hyper-Extract 三层架构中的第一层，表示“知识最终要以什么数据结构输出”。它不是某一种抽取模型，也不是某个行业模板，而是一组预先定义好的强类型知识结构，用来约束抽取结果的组织方式、字段形态和标识方法。

README 将 Hyper-Extract 描述为一个把高度非结构化文本转成持久化、可预测、强类型 Knowledge Abstract 的框架；其中 Auto-Types 正是这种“强类型”的结构基础。它的作用，是把“从文本里抽东西”从自由文本生成，提升为“输出到明确的数据结构里”。

在 Hyper-Extract 三层架构中的位置

README 在架构说明中明确给出三层分工：

Auto-Types：8 种强类型数据结构
Methods：抽取算法，如 KG-Gen、GraphRAG、LightRAG、Hyper-RAG、Cog-RAG 等
Templates：80+ 预设配置，覆盖 6 个领域，支持零代码使用

因此，Auto-Types 负责回答的是“结果长什么样”；Methods 回答“怎么抽”；Templates 回答“给定某类任务时，默认怎么配”。

这也是理解 Hyper-Extract 的关键边界：Auto-Types 不直接决定你用哪个大模型、哪种 RAG 流程或哪个行业词表；它先规定输出容器和数据语义骨架，再由其他层补足抽取策略与场景配置。

README 列出的 8 种知识结构

README 明确列出 Auto-Types 包含以下 8 种强类型结构：

Model
List
Set
Graph
Hypergraph
Temporal Graph
Spatial Graph
Spatio-Temporal Graph

README 还特别强调，这些结构覆盖了从简单到复杂的连续范围：

简单场景可以输出为集合类结构，如 List、Set；
需要固定字段对象时可以输出为 Model；
需要实体—关系表达时可以使用 Graph；
需要多元关系时可以使用 Hypergraph；
需要时间维度时可以使用 Temporal Graph；
需要空间维度时可以使用 Spatial Graph；
同时涉及时间与空间时可以使用 Spatio-Temporal Graph。

这使得 Hyper-Extract 的知识表示并不局限于传统知识图谱，而是形成一个统一的抽取框架：同一套系统既能处理简单清单，也能处理复杂的时空关系网络。

Auto-Types 管的是“输出结构”，不是“抽取算法”

Auto-Types 的核心职责是定义输出结构，而不是定义具体抽取算法。

例如，README 在能力矩阵里把 Hyper-Extract 与 GraphRAG、LightRAG、KG-Gen、ATOM 等系统做对比时，强调的是它支持 Knowledge Graph、Temporal Graph、Spatial Graph、Hypergraph、Domain Templates、Interactive CLI、Multi-language 等能力。其中 GraphRAG、LightRAG、KG-Gen 本身在 Hyper-Extract 架构里被归到 Methods 一层，而不是 Auto-Types。

换句话说：

如果你说“我要输出 Graph 还是 Set”，这是 Auto-Types 的问题；
如果你说“我要用 GraphRAG 还是 KG-Gen 来抽”，这是 Methods 的问题；
如果你说“我要直接套 general/biography_graph 还是 finance/earnings_graph 这样的现成配置”，这是 Templates 的问题。

Auto-Types 也不是业务模板。它不会直接告诉系统“传记应该抽哪些字段”“财报里有哪些风险因素”，而只是规定结果应该是模型、集合、图、超图还是时空图等结构。

强类型体现在哪里

README 给了一个 Graph 类型的模板示例，最能说明 Auto-Types 的“强类型”不是抽象口号，而是落实到字段、类型和标识规则上。

该示例的核心配置包括：

type: graph：先明确输出结构是 Graph；
entities 下定义实体字段；
relations 下定义关系字段；
identifiers 下定义实体和关系如何唯一标识。

其中实体字段被定义为：

name: name，type: str
name: type，type: str
name: description，type: str

关系字段被定义为：

name: source，type: str
name: target，type: str
name: type，type: str

标识规则则写为：

entity_id: name
relation_id: '{source}|{type}|{target}'

这说明所谓“强类型”，至少体现在几层约束上：

1. 结果不是随便写，而是必须落到预定义字段

实体不能只生成一段描述性文本，而要拆成 name、type、description 这些明确字段；关系也不能只是“某某和某某有关”，而要明确 source、target、type。

2. 字段本身带有类型声明

示例里这些字段都声明为 str。这意味着输出不是松散 JSON，而是有字段名和字段类型约束的结构。README 前文也提到从 Pydantic Models 到各类图结构，进一步说明其目标是可验证、可预测的数据对象。

3. 标识符规则是结构的一部分

entity_id: name 表示实体以 name 作为唯一标识来源；relation_id: '{source}|{type}|{target}' 表示一条关系的身份由源实体、关系类型、目标实体共同拼接而成。这样做的意义是，关系不是一段不可追踪的自然语言，而是可以被索引、比较、去重和合并的结构化记录。

4. 结构先行，内容后填

这个 graph 模板示例表明，模板真正依赖的是 Auto-Types 先定义出的结构语义：什么叫实体、什么叫关系、字段如何命名、如何唯一标识。抽取引擎之后做的，是把原文内容填进这个骨架，而不是临场自由发挥一个格式。

与 Methods、Templates 的分工

README 的三层架构可以理解为一条清晰的职责链：

Auto-Types：规定数据结构

它决定知识输出采用 Model、List、Set、Graph、Hypergraph、Temporal Graph、Spatial Graph 还是 Spatio-Temporal Graph。这一层关心的是结构表达能力。

Methods：规定抽取方法

README 列出的抽取算法包括 KG-Gen、GraphRAG、LightRAG、Hyper-RAG、Cog-RAG 等，并在核心特性里提到“10+ Extraction Engines”。这一层关心的是如何从文本中得到这些结构化结果。

Templates：规定预设任务配置

README 说明有 80+ YAML Templates，覆盖 Finance、Legal、Medical、TCM、Industry、General 六大领域，并强调 zero-code setup。模板把语言、名称、结构类型、字段设计、标签、描述等配置预先写好，方便直接使用。这一层关心的是场景落地与开箱即用。

三者关系可以概括为：

Auto-Types 提供“容器类型”；
Methods 提供“抽取手段”；
Templates 提供“现成方案”。

如果缺少 Auto-Types，系统就容易退化为“模型生成一些看起来像知识的文本”；如果只有 Auto-Types 而没有 Methods 和 Templates，结构虽清楚，但落地成本高、自动化弱。Hyper-Extract 的设计价值就在于把这三层拼成一个统一体系。

价值：从简单集合到复杂时空关系的统一抽取框架

Auto-Types 的最大价值，不是单独发明了某一种图，而是把多种知识结构放进同一个抽取框架中。

README 反复强调其支持范围从简单 Collections（Lists/Sets）和 Pydantic Models，一直到 Knowledge Graphs、Hypergraphs、Spatio-Temporal Graphs。对使用者而言，这意味着：

面对简单任务，不必过度建模成复杂图谱；
面对复杂任务，也不必被限制在普通二元关系图；
同一套 CLI、API、模板机制和知识抽象流程，可以在不同复杂度之间切换；
知识输出天然更适合后续搜索、可视化、增量演化与导出。

README 的功能表也从侧面说明了这一点：Hyper-Extract 相比对照系统，除了支持 Knowledge Graph 和 Temporal Graph，还额外支持 Spatial Graph、Hypergraph，以及领域模板。换言之，它不是只做一种“图抽取”，而是试图把知识表示层本身做成可扩展的统一底座。

这也是 Knowledge Abstract 能够“持久、可预测、强类型”的前提：不是每次都让模型临时定义输出，而是先用 Auto-Types 把结果空间界定清楚，再在这个空间里做抽取和演化。

边界与注意点

理解 Auto-Types 时，有几个边界不要混淆：

它不是某个具体模型能力；真正依赖结构化输出能力的是底层 LLM 提供的 json_schema 或 Function Calling。
它不是模板总和；模板只是把某个 Auto-Type 针对某类任务具体化。
它不是图专属概念；List、Set、Model 同样属于 Auto-Types。
它不是只面向检索增强生成；README 中的 GraphRAG、LightRAG 等只是可选方法层，而不是结构层本身。

因此，把 Auto-Types 译解为“图谱模板”或“抽取算法集合”都不准确。更准确的理解是：它是 Hyper-Extract 用来组织知识输出的类型系统。