W
AI-Wiki
SOURCE

CLI Guide - Hyper-Extract 摘要

文档概览

该来源页说明 Hyper-Extract 的命令行入口是 he，用于“直接从终端”执行知识抽取与后续交互。它把 CLI 的典型使用过程拆成四个阶段：

  1. Create：从文档创建 Knowledge Abstract，对应 he parse。
  2. Enhance：在已有 Knowledge Abstract 基础上增量补充内容并建立索引，对应 he feed 与 he build-index。
  3. Explore：对知识结果做可视化、检索、问答，对应 he show、he search、he talk。
  4. Save：把结果持久化到磁盘，对应 he dump。

文档的组织方式很明确：先给快速命令表，再给完整工作流图，再补充配置、抽取入口选择、语言支持和按场景划分的示例。

关键事实

he 是 Hyper-Extract 的命令行入口

  • 文档开头直接定义：Hyper-Extract CLI（he）提供“强大且易用”的接口，让用户可以在终端里直接做知识抽取。
  • 这意味着页面关注的是命令行层面的操作编排：输入文档、生成 Knowledge Abstract、继续补料、建立索引、搜索、对话、导出与清理。
  • 页面没有把重点放在模型后端切换、provider 接入或结构化输出兼容性的底层原理上；这些属于 Hyper-Extract Provider System、结构化输出兼容性 等相关主题。

快速命令表中的核心命令与用途

来源页给出一张 Quick Command Reference 表，列出命令、用途和常见参数。需要保留的命令与含义如下：

  • he parse：从文档中抽取知识。
    • 常见参数：-t 指定模板，-o 指定输出位置，-l 指定语言。
  • he show：可视化知识图谱。
    • 表中未列常见参数。
  • he export obsidian：导出到 Obsidian vault。
    • 常见参数：-o 输出位置、--name、-f 强制覆盖。
  • he search：在知识摘要中做语义搜索。
    • 常见参数：-n，用于指定 top-k 结果数量。
  • he talk：围绕知识摘要进行问答或聊天。
    • 常见参数：-i 交互模式，-q 直接传入查询问题。
  • he feed：向已有知识摘要增量添加文档。
    • 表中未列常见参数。
  • he info：显示知识摘要统计信息。
    • 表中未列常见参数。
  • he build-index：构建或重建搜索索引。
    • 常见参数：-f，表示强制重建。
  • he clean：删除某个 KA 的索引，或直接删除整个 KA。
    • 常见参数：-a 全部、-y 自动确认。
  • he list：列出模板或方法。
    • 常见参数/子目标：template 或 method。
  • he config：管理配置。
    • 常见操作：init、show、set。

其中，题目要求中的“h...”对应的就是这组管理与辅助命令链，包括 he clean、he list、he config 等，而不只是抽取和探索命令。

完整工作流分四阶段

文档用一个流程图把完整工作流写得非常清楚：

  • Create：Document --he parse--> Knowledge Abstract
  • Enhance（Optional）：
    • KA --he feed--> KA，表示在原有知识摘要上继续追加文档；
    • KA --he build-index--> IDX，表示从知识摘要生成搜索/问答所需索引。
  • Explore：
    • KA --he show--> Visualize，直接从 KA 可视化；
    • IDX --he search--> Search，搜索基于索引；
    • IDX --he talk--> Chat，对话同样基于索引。
  • Save：KA --he dump--> Disk，把结果落盘保存。

页面随后把流程图再文字化为 4 条步骤：

  1. Create — 用 he parse 从文档抽取知识。
  2. Enhance — 用 he feed 增量补充文档，用 he build-index 建索引。
  3. Explore — 用 he show 可视化，用 he search 搜索，用 he talk 聊天。
  4. Save — 用 he dump 持久化到磁盘。

这也是理解 Hyper-Extract CLI 工作流 的最核心来源之一。

搜索与对话依赖索引，he build-index 是前置步骤

  • 来源页在流程图里明确把 he search 与 he talk 的输入端画在 IDX 上，而不是直接画在 KA 上。
  • 这表示：搜索和对话都依赖索引。
  • 文末 Tips and Best Practices 又再次强调：Build the index — Required for search and chat functionality。
  • 因此，若只做了 he parse 但未执行 he build-index，则 he search 与 he talk 不应视为完整可用。
  • 相比之下，he show 是从 KA 直接进入可视化，不要求先经过索引步骤。

配置文件路径与配置命令

  • CLI 配置存放位置明确写为：~/.he/config.toml。
  • 配置管理命令为 he config。
  • 可用的管理动作包括：
    • he config init：初始化配置；
    • he config show：显示当前配置；
    • he config set：修改配置项。
  • 页面把它们归为配置管理，而不是抽取命令本身。

两类抽取入口：模板 -t 与方法 -m

来源页把抽取入口分成两大类：

模板（Templates）

  • 被标注为 Recommended for Most Users，即推荐多数用户优先使用。
  • 定义方式是“面向具体领域、开箱即用的配置”。
  • 示例命令：he parse doc.md -t general/biography_graph -l en。
  • 这说明模板入口强调任务类型与领域语义，例如传记图谱、概念图谱、合同义务抽取等。

方法（Methods）

  • 被标注为 Advanced，面向高级用户。
  • 定义方式是底层抽取算法入口，而不是面向领域的现成配置。
  • 示例命令：he parse doc.md -m light_rag。

因此，在 Hyper-Extract 抽取入口选择 的语境里，可以概括为：

  • 绝大多数场景先选 -t 模板；
  • 需要直接控制底层抽取策略时再选 -m 方法。

语言支持规则

文档对模板与方法的语言行为做了明确区分：

  • 模板支持多语言。
  • 可以通过 -l en 指定英文，通过 -l zh 指定中文。
  • 页面给出并列示例：
    • he parse doc.md -t general/biography_graph -l en
    • he parse doc.md -t general/biography_graph -l zh
  • method templates 始终使用英文 prompt。

这意味着：

  • 如果用户主要依赖模板做抽取，CLI 已内建多语言适配路径；
  • 如果用户转向方法级入口，则不能假定 prompt 会随 -l 切换为中文；来源页只明确说明 methods 使用英文 prompts。

重要细节

文中出现的启动示例

页面在 Getting Started 一节中直接给出一条解析示例：

  • he parse document.md -t general/biography_graph -o ./output/ -l en

从这条命令能提炼出几个具体细节：

  • 输入可以是单个文档文件，如 document.md；
  • 抽取时可以同时指定模板 -t；
  • 可以通过 -o ./output/ 指定输出目录；
  • 可以通过 -l en 指定输出/抽取语言环境为英文。

详细命令分组

页面在 Commands in Detail 中至少明确列出：

  • he parse —— 从文档抽取知识；
  • he feed —— 向已有知识摘要增加文档。

虽然截取内容里没有完整展开其余小节细目，但从页面结构可看出命令被归入“Exploration”“Management”等类别，和前面的快速命令表相互对应。

Obsidian 导出是明确支持的保存/输出形式

  • 在快速命令表中，he export obsidian 被单独列出，而不是笼统写“导出”。
  • 这说明 CLI 有明确的 Obsidian 输出目标。
  • 常见参数包括：
    • -o：输出路径；
    • --name：名称；
    • -f：强制覆盖。
  • 与工作流图中的 he dump 相比，he export obsidian 更像是面向特定外部知识库载体的导出命令。

he info、he clean、he list 的定位

  • he info 用于展示知识摘要统计信息，适合在完成抽取或增量补料后查看 KA 的总体状态。
  • he clean 用于清理索引，或者在带 -a 等参数时清理整个 KA；因此它不是简单的“删缓存”，而是可能影响整个知识摘要资产。
  • he list template 与 he list method 是模板/方法发现入口，适合在不知道可用抽取方案时先做枚举。

安装后验证与帮助系统

  • 页面有 Installation 小节，并在其下明确写到“Verify installation”，即安装后要验证 CLI 是否可用。
  • 获取帮助的方法包括：
    • he <command> --help：查看任意命令帮助；
    • he list template：列出所有模板；
    • he list method：列出所有方法；
    • 另有 FAQ 与 Troubleshooting 文档可查。

典型示例与适用场景

研究论文：general/concept_graph

来源页把研究类场景写成：

  • 抽取：he parse paper.md -t general/concept_graph -o ./paper_kb/ -l en
  • 提问：he talk ./paper_kb/ -q "What are the main contributions?"

这里保留了几个重要事实：

  • 研究论文场景推荐模板是 general/concept_graph；
  • 输出目录示例是 ./paper_kb/；
  • 后续问答直接针对该知识库目录进行；
  • 示例问题是“主要贡献是什么”，说明 he talk 面向的是知识摘要上的语义问答，而不是原文逐字检索。

不过按页面其他部分的规则，真正要稳定启用 he talk，前提仍是已建立索引；该依赖在 Tips 与流程图中比在单条示例中表达得更完整。

人物传记：general/biography_graph

来源页把传记场景写成：

  • 抽取：he parse biography.md -t general/biography_graph -o ./bio_kb/ -l en
  • 可视化：he show ./bio_kb/

这表明：

  • 人物传记推荐模板是 general/biography_graph；
  • 输出目录示例是 ./bio_kb/；
  • 后续常见动作是可视化人生事件，而不是先做搜索或聊天。

法律合同：legal/contract_obligation

来源页把法律文档场景写成：

  • 抽取：he parse contract.md -t legal/contract_obligation -o ./contract_kb/ -l en
  • 搜索：he search ./contract_kb/ "termination conditions"

这说明：

  • 法律合同义务抽取推荐模板是 legal/contract_obligation；
  • 输出目录示例是 ./contract_kb/；
  • 后续典型动作是查找特定条款，例如“termination conditions”（终止条件）。

同样需要注意，按页面通用规则，he search 依赖索引，因此在实际流程中应在搜索前执行 he build-index。

最佳实践与约束

来源页最后给出 4 条 Tips and Best Practices，含义都很具体：

  1. 优先使用模板处理领域任务：模板已针对特定场景优化，不建议多数用户一开始就直接选方法。
  2. 先构建索引：搜索和对话功能都要求索引存在，这是功能可用性的前置条件，不是可选优化项。
  3. 增量 feed：可以随着时间逐步加入文档，而不必每次全部重跑。
  4. 选择正确语言：对于非英文文档，语言参数选择会直接影响抽取质量。

这些建议与前文并不冲突，而是把若干隐含规则显式化：模板优先、索引必要、增量优于全量重做、语言要贴近原文。

与现有概念的关系

  • 与 Knowledge Abstract：CLI 的核心产物就是 KA，he parse 创建它，he feed 扩展它，he show/he search/he talk 围绕它展开，he dump 与 he export obsidian 则负责保存或导出它。
  • 与 Hyper-Extract CLI 工作流：本页是该工作流最直接的来源整理，明确了 Create → Enhance → Explore → Save 四阶段。
  • 与 Hyper-Extract 抽取入口选择：本页清楚区分模板 -t 与方法 -m，并给出“模板适合多数用户、方法面向高级用户”的选择原则。
  • 与 Hyper-Extract Provider System：CLI 页没有展开 provider 细节，只假定终端命令可用；真正的模型后端接入与兼容性约束应转到 provider 与结构化输出相关页面查看。

相关条目