面向长文档本体构建的增量式上下文感知融合方法

点击视频，快速了解全文核心干货

面向长文档本体构建的增量式上下文感知融合方法

亚信科技（中国）有限公司

本体（Ontology）作为语义网与知识工程的核心构件，是对特定领域概念、属性及其关系的规范化、形式化描述，为数据互操作、知识推理与智能问答奠定基础。然而，传统本体构建高度依赖领域专家的手工建模与反复校验，周期长、人力成本高，严重制约了大规模知识工程的落地效率。

近年来，大语言模型（LLM）凭借强大的文本理解与结构化抽取能力，为自动化本体构建提供了新的技术路径。通过精心设计的提示策略，LLM可直接从非结构化文本中识别概念、抽取关系并生成形式化定义，显著降低人工参与成本。

但现实中的知识来源往往呈现多格式（PDF、Word、HTML、Excel、PPT、Markdown、扫描件等）、大体量的特点，单份文档动辄数万字，多文档聚合后更是远超主流LLM的上下文窗口限制。如何在上下文受限的条件下，实现多源异构文档的高效理解、信息融合与本体迭代，已成为当前LLM驱动本体工程面临的核心挑战。

（一）核心结论速览

一句话总结：针对长文档本体构建的上下文溢出问题，本文提出四种迭代式构建方案，实验表明——中等规模场景优选全局增量式，大规模场景优选渐进式披露或检索式增量，追求极致速度可选独立片段式。

1.方案选型速查表

2.关键实验结论

全局增量式：场景一（60 chunks）Fuzzy F1 达 0.63（最优），但场景二（680 chunks）因超出128K上下文窗口而直接不可用。

检索式增量：场景一 Fuzzy F1 0.60（接近最优），场景二 Graph F1 0.29（最优），上下文降低 38%，为跨规模最稳健方案。

渐进式披露：场景二 Fuzzy F1 0.33、Continuous F1 0.29（均为最优），上下文稳定在 ~11K tokens，大规模场景首选。

独立片段式：上下文最低（~6K tokens），但场景二 Graph F1 仅 0.23，精度换速度特征明显。

（一）问题场景描述

基于多格式文档（PDF、Word、HTML、Excel、PPT、Markdown、扫描件等），利用LLM进行的本体构建场景中，典型的迭代流程是：借鉴RAG（知识检索增强）工程经验，在预处理阶段将文档切分为chunk块，然后遍历这些块，在每次迭代中，LLM的提示词包括当前chunk块、已经构建的完整本体内容、本体构建业务补充信息、构建要求等。随着迭代进行，已构建的完整本体越来越大，最终很容易超过主流LLM的最大上下文限制。这一问题也限制了在较大业务场景中使用LLM进行本体的构建。

（二）核心挑战分析

上下文溢出问题：每次迭代都需要传递完整本体，token消耗呈线性增长。第N次迭代的Prompt长度 ≈ 初始化信息长度 + N × 单chunk本体增量 + 构建的辅助信息长度。根据实验验证，随着迭代次数的增加，已构建本体内容呈线性增长：

•第1次迭代：本体内容 ≈ 0 tokens

•第10次迭代：本体内容 ≈ 5K tokens

•第100次迭代：本体内容 ≈ 50K tokens

•第1000次迭代：本体内容 ≈ 500K tokens

而目前国内外主流LLM的上下文限制通常是32K-128K，无法支持多次迭代过程的本体构建。

LLM长上下文处理能力限制：当上下文长度超过一定阈值后，LLM推理存在两个核心问题：一是注意力衰减，模型对远距离token的注意力权重显著下降，导致早期注入的本体信息被"遗忘"；二是上下文过载引发的幻觉，模型在信息密度过高的上下文中容易产生看似合理实则失真的本体定义。这两个问题在长文本场景下尤为突出，直接影响本体构建的准确性。

信息冗余问题：当前chunk可能只与本体的一小部分相关，却需要传递全部内容，造成大量无效token消耗。例如，一个关于"网络故障诊断"的chunk与本体中"财务管理"分支完全无关，但全量传递时这些无关信息仍占据宝贵的上下文空间。

一致性与效率冲突：盲目全量输入虽能保持全局视角，但易引发概念冲突（如不同chunk对同一概念的定义不一致），同时处理大规模文档集时的API调用成本与响应延迟呈指数级增长，不可控。

文档-本体匹配缺失：chunk孤立处理时，LLM缺乏对全局文档主题的整体视野，难以判断当前chunk应当聚焦本体的哪些分支进行更新，从而生成大量冗余或错误的Delta（增量变更），降低构建效率并引入噪声。

针对上述五大核心挑战，本文借鉴以下几个经典理论，并将其映射为具体的技术实现路径。

（一）上下文溢出与LLM能力限制问题

理论依据：Retrieval-Augmented Generation（RAG）范式（Lewis et al., 2020）。RAG通过外部向量存储与图数据库，将知识检索与文本生成分离，仅检索与当前查询相关的知识子集注入上下文，而非加载全部知识库。

技术映射：在本体构建过程中，将已构建的全局本体存储于向量数据库存储系统中。每次迭代时，不直接传递完整本体，而是基于当前chunk的语义特征检索最相关的本体子图及相关联的对象和关系，将Prompt中的本体上下文长度从O(N)降为O(1)（与迭代次数无关，仅与检索窗口大小相关）。

（二）迭代全量更新问题

理论依据：Map-Reduce分布式计算模型及Delta更新思想。Map-Reduce将复杂的大数据任务分解为可并行处理的Map子任务，再通过Reduce阶段聚合结果；Delta更新则只记录和传递变更部分，避免全量重计算。

技术映射：一方面，在独立片段式本体生成方案中，每个chunk的局部本体生成可视为独立的Map任务，多个chunk可并行处理，最终通过Reduce阶段的聚合策略合并为全局本体。另一方面，所有增量式方案均采用Delta更新机制——每轮迭代仅输出对当前局部本体切片的新增、修改或删除操作，而非重写完整本体，显著降低每轮输出的token开销。

（三）文档-本体不匹配问题

理论依据：文档主题建模（Topic Modeling, Blei et al., 2003）与嵌入相似度匹配（Sentence-BERT, Reimers & Gurevych, 2019）。主题建模能够从文档集合中自动发现抽象主题分布；Sentence-BERT则通过双塔编码器架构生成高质量的句子嵌入，支持高效的语义相似度计算。

技术映射：在Pre-processing阶段，为每个文档片段生成元数据JSON（包含核心主题、领域标签、关键概念列表）。在后续检索时，这些元数据作为过滤条件与相似度计算的辅助特征，实现"文档驱动"的精准匹配——即当前chunk只与本体中语义相关的分支进行交互，避免无关信息的干扰。

针对上述存在的问题，结合可验证并且在业界内广泛实施的理论和实践技术，本文从文档智能解析与语义感知切分、迭代式本体构建方案两个维度展开技术实现。在文档预处理层面，通过分层语义感知切分策略解决传统固定长度切分导致的语义断裂问题；在本体构建层面，通过四种迭代式方案的对比验证，探索上下文受限条件下的最优构建范式。

（一）文档智能解析与语义感知切分

当前问题根源在于忽略文档内在结构与语义连贯性。传统基于固定token长度的切分方法，极易将表格与其描述文字、段落间的逻辑关联切断，导致LLM在后续本体构建时缺乏完整的语义上下文。本方案采用"结构解析 + 语义感知切分"的分层策略，确保同一语义单元不被拆分，同时为后续的本体构建提供精准的引导信息。

 1.优化目标：

实现语义完整切分：确保同一语义单元不被拆分，复杂结构信息零丢失。

实现精准引导抽取：辅助信息真正驱动LLM聚焦核心、过滤噪声。

实现闭环可控构建：全流程自动化校验、融合、迭代，输出高质量、可溯源本体。

2.通用切分框架（适用于所有文档类型）

（1）结构解析层（预处理）

提取层次化目录/标题树（TOC、H1-H6、Slide标题）。

识别逻辑单元：段落、表格、图片、列表、页眉页脚。

使用多模态LLM（或专用工具如MinerU + LayoutLM）解析文档，输出结构化中间表示（JSON格式：{section_title, content, type, parent_section}）。

（2）语义连贯性切分层（核心改进）

嵌入聚类切分：

对每个逻辑单元计算embedding（使用bge-m3或类似模型），当相邻段落embedding余弦相似度 < 0.75(根据小规模试验验证后确定) 或跨越标题层级时，强制新chunk。

表格/图片特殊处理：

表格：先用TableGPT或VLM转为Markdown + 描述性标题，再与上下文段落合并为一个chunk（避免表格与解释文字分离）。

图片：OCR + 多模态描述（Vision LLM生成"图片语义摘要"），摘要与正文段落强制合并成一个chunk。

长图/PPT：先转为单页PDF，再按"幻灯片"作为最小语义单元（而非固定chunk size）。

（3）Chunk大小动态调整

基础大小：1000-4000 token（根据模型上下文窗动态调整）。

规则：同一标题下的所有内容必须保持在同一或相邻chunk，禁止跨标题切分同义内容。

（4）文档类型专项优化

（二）迭代式本体构建方案

在文档完成语义感知切分后，需要选择合适的本体构建策略从chunk序列中逐步构建全局本体。本研究设计并验证了四种迭代式构建方案，分别从上下文管理、更新粒度、整合策略等维度进行差异化设计。

1.全局增量式本体生成

（1）核心思路

全局增量式本体生成采用顺序累积的思路。系统先从第一个文档片段生成初始本体，之后每处理一个新片段，都直接基于当前已经形成的全局本体继续补充和修正。每一轮都显式维护一份不断演化的整体结构，因此更容易保持跨片段的一致性，也更适合需要持续累积全局语义信息的场景。

（2）实现过程

Step 1 — 初始化阶段

取第一个chunk C₁，构造Prompt：

任务：基于以下文档片段构建初始本体。 文档内容：{C₁内容} 构建要求：识别核心概念、属性及概念间关系；输出格式为JSON-LD兼容的结构。 输出：初始本体 O₁

LLM输出初始本体 O₁，包含概念集 V₁、关系集 E₁ 和属性定义 A₁。

Step 2 — 迭代更新阶段（第k轮，k ≥ 2）

对于第k个chunk Cₖ，构造Prompt：

任务：基于当前全局本体和新的文档片段，生成本体增量（Delta）。 当前全局本体：{Oₖ₋₁ 完整内容} 新文档片段：{Cₖ 内容} 操作要求：1. 新增：Cₖ中引入的新概念、新关系 2. 修正：与Oₖ₋₁中已有概念定义冲突的部分 3. 合并：识别并合并重复或近义概念 输出格式：{ "add": [...], "modify": [...], "merge": [...] }

LLM输出Delta Δₖ，系统将其应用至 Oₖ₋₁ 得到更新后的本体 Oₖ = Oₖ₋₁ ⊕ Δₖ。

Step 3 — 一致性校验

每10轮迭代执行一次全局一致性检查：通过嵌入相似度检测近义概念（阈值0.85），触发合并建议。

（3）关键设计点：

完整本体传递：每轮Prompt包含当前全局本体的完整序列化表示（通常为Turtle或JSON格式），确保LLM具备全局视野。

Delta机制：LLM输出结构化的增量操作而非重写完整本体，降低输出token开销。

冲突解决策略：当新chunk与现有本体存在定义冲突时，优先采纳置信度更高的定义（通过LLM的自评估分数判断）。

（4）适用场景

小规模文档集（总chunk数 < 200）、本体复杂度中等、对全局一致性要求高的场景。

2.独立片段式本体生成

（1）核心思路

独立片段式本体生成采用"先分治、后整合"的思路。系统先把文档拆成多个片段，并为每个片段单独生成局部本体，各片段之间在生成阶段完全独立、可并行处理；随后再通过聚合阶段的加权、剪枝和重建等步骤得到最终全局本体。优势在于流程清晰、模块化程度高、可充分利用并行计算资源，但对后期整合质量依赖较强。

（2）实现过程

Step 1 — 局部本体生成（Map阶段）

对于每个chunk Cᵢ（i = 1, 2, ..., n），独立构造Prompt：

任务：基于以下文档片段生成本地本体。 文档片段：{Cᵢ 内容} 构建要求：1. 提取该片段中出现的所有概念、属性、关系 2. 为每个概念提供局部上下文定义 3. 标注置信度分数（0-1），表示该定义在该片段中的确定性 4. 标注来源位置（该片段中的行号/段落范围） 输出格式：{"concepts":[...],"relations":[...], "confidence_scores": {...} }

所有chunk的处理相互独立，可在多线程/多进程中并行执行，得到局部本体集合 {L₁, L₂, ..., Lₙ}。

Step 2 — 概念对齐（Alignment）

构建跨片段的概念相似度矩阵。对于来自不同局部本体的任意两个概念 u ∈ Lᵢ 和 v ∈ Lⱼ，计算综合相似度：

Sim_align(u,v)=α·EmbedSim(u,v)+β·NameSim(u,v)+γ·ContextSim(u, v)

其中：

•EmbedSim：概念定义的句向量余弦相似度（权重 α=0.5）

•NameSim：概念名称的编辑距离相似度（权重 β=0.2）

•ContextSim：概念所在上下文的相似度（权重 γ=0.3）

基于相似度矩阵，使用层次聚类（阈值0.80）将跨片段的等价概念聚为一类，形成等价概念簇。

Step 3 — 全局本体聚合（Reduce阶段）

对每个等价概念簇，通过加权投票策略生成全局概念定义：

其中权重 wᵢ 与该片段中概念的置信度及片段整体质量评分正相关。关系聚合同理，但额外检查跨簇关系的domain-range一致性。

Step 4 — 全局结构重建

将聚合后的概念和关系组织成有向图结构，执行以下优化：检测并消除冗余关系；识别并补全隐式关系；生成层次化分类结构（基于is-a关系的传递闭包）。

（3）关键设计点

完全并行化：Map阶段各chunk的处理零依赖，可线性扩展至集群规模。

多维度对齐：不仅依赖名称匹配，而是融合嵌入语义、名称相似度、上下文主题的三维对齐策略。

置信度加权：局部本体的每个定义都带有置信度分数，全局聚合时高置信度定义享有更高权重。

（4）适用场景

大规模文档集（总chunk数 >200]）、计算资源充足、可接受一定精度损失以换取处理速度的场景。

3.检索式增量本体生成

（1）核心思路

检索式增量本体生成同样按片段顺序推进，但它不会在每一轮都暴露完整全局本体，而是先围绕当前片段检索出最相关的局部本体切片，再在这部分局部上下文上执行增量更新，最后回写到全局本体中。核心思路是把"全局维护"和"局部推理"分离，用更小、更聚焦的上下文来降低噪声，从而提高当前片段处理时的针对性。

（2）实现过程：

Step 1 — 多维索引构建

在首次迭代前，将初始本体（或空本体）构建为多维索引结构：

•向量索引：将每个概念的文本定义编码为嵌入向量，存入向量数据库。

•关系索引：基于本体对象关系构建关系树，支持通过某个对象快速查找关联的其他对象，在内存中维护。

•倒排索引：记录每个概念来源的chunk编号列表，支持快速定位相关上下文。

Step 2 — 相关本体切片检索（第k轮，k ≥ 1）

对于当前chunk Cₖ，执行多路检索：

•语义检索：将 Cₖ 编码为查询向量 qₖ，在向量索引中根据设置的相似度阈值检索Top-K（默认K=10）最相似的概念定义，得到概念集合 Vₖˢᵉᵐ。

•关系扩展：对 Vₖˢᵉᵐ 中的每个概念，在关系索引中查询其一跳邻居（直接关联的概念和关系），得到扩展集合 Vₖᵉˣᵗ 和关系集合 Eₖʳᵉˡ。

•融合形成切片：合并上述结果，形成局部本体切片 Sₖ = (Vₖ, Eₖ)，其中 Vₖ = Vₖˢᵉᵐ ∪ Vₖᵉˣᵗ，Eₖ=Eₖʳᵉˡ 。

Step 3 — 局部增量更新

构造聚焦式Prompt：

任务：基于检索到的相关本体切片和新文档片段，生成局部更新。 相关本体切片（已按相关性排序）：{Sₖ 序列化内容} 新文档片段：{Cₖ 内容} 操作说明： 1. 仅在提供的本体切片范围内进行新增、修改操作2. 若新片段引入与切片无关的新概念，可标记为"待审核"并附加上下文 3. 保持与全局本体的引用一致性（使用相同的URI/标识符）输出：局部Delta

LLM输出局部增量 Δₖˡᵒᶜᵃˡ。

Step 4 — 全局回写

将 Δₖˡᵒᶜᵃˡ 应用至全局本体 Oₖ₋₁：执行新增概念的插入操作；执行已有概念定义的合并/更新操作；将"待审核"项存入审核队列，供后续人工或自动审核处理。更新索引结构（向量索引、倒排索引、关系索引同步更新）。

（3）关键设计点

多路召回融合：语义相似度 + 关系扩展 + 层级补全三路召回，确保检索的全面性。

索引实时更新：每轮迭代后全局索引实时更新，保证后续检索能看到最新本体状态。

（4）适用场景

中大型文档集（总chunk数 > 200）、本体结构复杂且分支间关联度低、需要严格控制上下文长度的场景。

4.渐进式披露增量本体生成

（1）核心思路

渐进式披露（Progressive Disclosure）是一种交互与信息呈现原则，指优先只向用户展示当前完成任务所必需的内容，把次要、复杂或进阶的信息暂时隐藏，等需要时再逐步展开。渐进式披露增量本体生成进一步强调上下文的分层组织。系统首先维护一份轻量级的本体元数据摘要，用来概括已有概念、层级和关系模式；处理新片段时，模型先依据这份高层摘要判断当前需要关注哪些概念，再按需加载对应的局部细节，最后完成本轮更新。相比直接检索局部切片，这种方法更强调"先看全局导航信息，再看局部细节"，目标是在控制上下文规模的同时保留结构上的可解释性。

（2）实现过程：

Step 1 — 双层本体表示

系统同时维护两份数据结构：

•全局摘要层（Summary Layer）：轻量级元数据结构，包含：

概念清单（概念名称 + 描述，无详细定义）

概念层级树（is-a关系的骨架结构）

关系类型清单（关系名称 + domain-range类型约束）

•全局详细层（Detail Layer）：完整的本体定义，包含每个概念的详细描述、属性定义、关系约束、示例等。仅在按需加载时进入Prompt上下文。

Step 2 — 高层相关性判断（第k轮，k ≥ 1）

对于当前chunk Cₖ，首先仅将摘要层与 Cₖ 一起输入LLM：

任务：基于本体摘要判断当前片段需要关注的概念分支。本体摘要：{Summary Layer 内容} 新文档片段：{Cₖ 内容} 判断要求： 1. 列出该片段可能涉及的概念名称（从摘要中选择）2. 判断每个概念需要的操作类型：新增 / 细化定义 / 添加关系 输出：{ "relevant_concepts": [{"name": ..., "action": ..., "detail_fields": [...]}] }

LLM输出相关概念列表 Rₖ = [{name, action, detail_fields}]。

Step 3 — 按需加载与局部更新

根据 Rₖ 中的指示，从Detail Layer中精确加载需要的详细信息：

•对于"细化定义"操作的概念：加载该概念的完整当前定义。

•对于"添加关系"操作的概念对：加载两个概念的骨架定义 + 两者间现有关系。

加载完成后，构造包含摘要层 + 按需加载细节 + 当前chunk的Prompt，执行与检索式增量方案类似的局部更新流程。

Step 4 — 摘要层同步更新

当Detail Layer发生以下变更时，Summary Layer同步更新：

•新增概念：在层级树中插入新节点。

•新增关系类型：在关系清单中追加条目。

•概念合并/删除：更新层级树结构。

（3）关键设计点

大小可控的摘要层：无论本体多大，摘要层的token始终可控，确保每轮Prompt的基础长度可控。

两层联动机制：摘要层不仅用于导航，还承担"变更传播"职责——Detail Layer的任何结构性变更都会实时反映到摘要层。

智能按需加载：LLM在第一阶段即决定需要加载哪些细节字段，避免加载无关信息。

（4）适用场景

超大规模本体构建（概念数 > 10000）、本体结构层次清晰、需要在可控上下文内维持全局可解释性的场景。

（一）验证场景

本文结合本体平台实际支撑的业务场景，进行效果的验证。场景包括以下：

场景一：OSS异常分析

此场景包括8个Excel文档，面向4G/5G核心网运维管理（OSS），涵盖配置管理（CM）、性能管理（PM）与故障管理（FM）三大子域，面向AMF、MME、SMF、UPF等关键核心网元。文档包含网元配置参数、性能指标定义、故障码体系、告警规则等专业内容。领域本体需要覆盖网元类型、性能指标、故障分类、告警级别、关联规则等核心概念，预期构建中等规模本体（约100个概念、约200个关系）。

场景二：OSS核心网告警分析

此场景包括10个原始文档，涵盖Markdown、Excel、PDF、TXT四种格式类型。主要围绕电信运营商5G核心网的智能故障分析运维体系展开，用于支撑AI智能体执行指标表象→聚类分析→信令关联→告警回溯→日志核查，实现从业务性能劣化到根因定位的自动化闭环分析。

（二）本体评估指标体系

为全面评估各方案构建的本体质量，本文建立了包含上下文效率、结构保真度 (Lo A, Jiang A Q, Li W, et al. 2024)、语义保真度三个维度的综合评估体系。

1.上下文效率指标

平均上下文长度：衡量各方案在迭代过程中的平均Prompt长度（tokens），反映上下文资源消耗效率。理想情况下，该指标应与迭代次数解耦或弱相关。

2.结构保真度指标

假设真实本体图为 G=(V,E)，模型生成的本体图为 G'=(V',E')。

（1）Literal F1（字面 F1）

只有当生成图中的一条边和真实图中的一条边在节点名称上都完全一致时，才算匹配。

字面精确率（Literal precision）：

字面召回率（Literal recall）：

然后取精确率和召回率的调和平均数，得到 Literal F1。

•优点：简单、直观，容易理解。

•缺点：对表达内容非常敏感，比如同义词表达、大小写变化、词形变化都会被误判成不匹配。

（2）Fuzzy F1（模糊 F1）

由于字面 F1 只看字面一致，但本体评估更关心的是语义相似性，因此提出模糊 F1。不要求两个节点名字完全一样，只要它们的语义相似度足够高，就认为能够匹配。

定义节点相似度函数 NodeSim(u, u') 表示节点 u 和 u' 的句向量余弦相似度。

模糊精确率（Fuzzy precision）：

模糊召回率（Fuzzy recall）：

再取调和平均数得到 Fuzzy F1。

•优点：更能反映语义正确性，比如同义词或近义表达不会被过度惩罚。

•缺点：匹配不再是完全一一对应。

（3）Continuous F1（连续 F1）

由于模糊 F1 可能会让多个边同时匹配上，导致一些结构明显不同的图也拿到很高分。为了解决这个问题，可考虑连续 F1，用最优一对一边匹配来比较两个图。

对于真实图中的边 (u,v) 和生成图中的边 (u',v')，它们的相似度定义为两端节点相似度的较小值：

然后在两个图的边之间做最高得分的一对一匹配，这等价于求解线性分配问题，采用匈牙利算法（Hungarian algorithm）进行计算。设最优匹配总得分为 s_cont。

连续精确率（Continuous precision）：

连续召回率（Continuous recall）：

再取调和平均得到 Continuous F1。

•优点：通过一对一最优边匹配避免了模糊 F1 里"一条边可重复模糊匹配多条边"的问题，因此更严格，也更适合做超参数调优的参考。

•缺点：需要求解线性分配问题，计算开销更大；并且仍然依赖文本嵌入相似度，结果会受嵌入模型影响。

3.图结构保真度指标

（1）Graph F1（图 F1）

前面几个指标主要看边，而更大范围内的图结构也是评估考虑的一个方面。这关注的不只是某条边对不对，而是一个概念在它的局部邻域里和其他概念是怎样组织在一起的。这个维度考虑使用图 F1，先用预训练文本嵌入得到每个节点的表示，再通过简单的图卷积（取 K=2）把图结构信息融入节点表示中，得到图感知节点嵌入。之后比较 G 和 G' 中节点嵌入的余弦相似度，并像连续 F1 那样做最高得分的一对一节点匹配。设最优节点匹配总得分为 s_graph。

图精确率（Graph precision）：

图召回率（Graph recall）：

再取调和平均数得到 Graph F1。

•优点：不仅仅比较单条边，还结合图卷积后的图感知节点表示来评估节点及其局部邻域结构，因此更能反映整体结构的相似性。

•缺点：计算和实现都更复杂，并且解释性不是很直观。

（三）实验结果及结论

1.实验配置说明

实验基于Deepseek-v3.2（128K上下文窗口）模型进行，温度统一设置为0.1。文档预处理统一采用语义感知切分策略，切分后场景一产生约60个chunk，场景二产生约680个chunk。人工构建的本体作为质量评估的参考值（Ground Truth）。

实验时，每个场景独立运行N次(这里N取3)，然后取平均值作为最终指标值。

2.场景一实验结果

表格中obj表示对象类型数量，rel表示对象属性数量。

3.场景二实验结果

注：

1. "不支持"表示该方案因超出模型最大上下文限制而无法完成本体构建。场景二中，全局增量式生成在第约170轮迭代时上下文长度超过128K阈值，导致后续迭代无法正常进行。

   
   

2. 关于对象及关系数量差异的说明：实验表格中四种自动化方案的 obj/rel 数量均高于人工构建的 Ground Truth（如场景一中人工 obj:96 vs 方案 112~144）。该差异主要源于方案倾向于过度生成——LLM在缺乏全局约束的情况下，易从文档中抽取大量细粒度概念及冗余关系（如将同一概念的不同表述识别为独立对象、为弱关联实体建立关系），而人工构建时专家会基于领域知识进行抽象合并与剪枝。这一过度生成现象在所有自动化方案中普遍存在，其中独立片段式因缺乏全局统一视角，过度生成最为显著（场景一 obj:144，超出人工 50%）。后续可加入后处理阶段的冗余检测与概念合并策略加以抑制。

4.实验结论分析

从以上两个场景的实验结果，可以得出以下结论：

（1）全局增量式本体生成在中等规模场景质量最优，但存在模型上下文窗口限制瓶颈

在场景一（中等规模本体，约60个chunk）中，全局增量式生成在四项指标上均领先于其他方案。这说明直接维护并持续修正全局本体，虽然上下文开销最大（平均16,500 tokens），但在保持概念表达和整体结构一致性方面仍然最具优势。LLM在完整全局本体的上下文中能够更好地识别跨chunk的概念关联和冲突，从而做出更准确的合并与修正决策。

然而，在场景二（大规模本体，约680个chunk）中，全局增量式生成由于LLM上下文的限制，在第约170轮迭代后超出128K上下文窗口，无法支持更大规模的本体构建。这验证了其线性增长的上下文消耗最终会成为不可逾越的瓶颈，限制了该方法的可扩展性。

（2）检索式增量生成是质量与效率的综合平衡方案

检索式增量生成在场景一中各项指标接近全局增量式（Fuzzy F1 0.60 vs 0.63，Graph F1 0.50 vs 0.52，Literal F1 0.14 vs 0.17），同时平均上下文长度（~10,200 tokens）较全局增量式降低约38%。在场景二中，该方案能够正常完成构建，且在 Graph F1（0.29）上表现最优，其他指标（Fuzzy F1 0.32、Continuous F1 0.26、Literal F1 0.08）也处于前列。这说明它在控制上下文规模的同时，仍能较好地兼顾局部更新效果与全局结构稳定性。其多路检索机制有效弥补了不暴露完整全局本体带来的信息损失，是跨规模场景下鲁棒性较好的方案。

（3）渐进式披露增量生成在大规模场景表现稳健且可扩展性良好

渐进式披露增量生成在场景二中整体表现最优：Literal F1（0.08）、Fuzzy F1（0.33）和 Continuous F1（0.29）三项指标均为最高，Graph F1（0.28）与检索式方案（0.29）基本持平。其平均上下文长度在场景二中控制在~11,200 tokens，在场景一中仅~8,700 tokens。其双层表示机制（摘要层 + 详细层）有效控制了上下文规模，使Prompt长度与本体总规模解耦，展现出良好的可扩展性。但在场景一中，其各项指标（Fuzzy F1 0.58、Graph F1 0.49）略逊于检索式方案，说明"先看全局导航信息，再看局部细节"的思路在大规模场景下收益更明显，而在中等规模场景下摘要层的信息压缩可能带来一定的细节精度损失。

（4）独立片段式本体生成在精度上存在明显短板，但并行效率突出

独立片段式本体生成在场景一中各项指标明显落后（Fuzzy F1 0.41，Graph F1 0.40），在场景二中虽然能够完成构建且上下文开销最低（~6,100 tokens），但Graph F1仅为0.23，Fuzzy F1仅0.25，质量差距显著。这说明"先独立生成、再统一聚合"的路线更容易损失跨片段的全局结构信息。后期聚合阶段的对齐和合并操作难以完全恢复生成阶段缺失的全局视角，导致概念层级结构和跨片段关系的不完整。不过，其Map阶段完全并行、上下文开销最小的特点，使其在对实时性要求高、可接受一定精度损失的场景中仍具应用价值。

（一）总结

本文围绕"基于LLM从海量多格式文档中自动化构建本体"这一核心问题，系统性地分析了上下文溢出、LLM长文本处理能力限制、信息冗余、一致性与效率冲突、文档-本体匹配缺失五大核心挑战，并从理论依据、技术实现、实验验证、未来优化四个层面展开了深入研究。

理论层面，本文借鉴了RAG范式的检索增强思想、Map-Reduce分布式计算的分解-聚合框架、文档主题建模的语义匹配方法，以及TF-IDF与语义相似度结合的多维相关性度量理论，为技术方案的设计提供了学术基础。通过将经典理论映射到本体构建的具体场景，实现了从抽象理论到工程实践的有效转化。

技术层面，本文提出了"语义感知切分 + 迭代式构建"的两阶段技术框架。在文档预处理阶段，设计了分层语义感知切分策略，通过结构解析层、语义连贯性切分层、动态大小调整层的三级处理，有效解决了传统固定长度切分导致的语义断裂问题，并针对不同文档类型（Excel、PDF、Word、PPT、图片等）提供了专项优化方案。在本体构建阶段，设计并实现了四种迭代式构建方案——增量式本体生成、独立片段式本体生成、检索式增量本体生成、渐进式披露增量本体生成——分别从全局维护、并行分治、检索聚焦、分层导航四个维度探索了上下文受限条件下的最优构建范式，并为每种方案提供了完整的算法流程、Prompt设计策略和状态维护机制。

实验层面，本文在两个真实业务场景（OSS异常分析、OSS核心网告警分析）中进行了全面的效果验证，建立了涵盖上下文效率（平均上下文长度）、结构保真度（Literal F1 / Fuzzy F1 / Continuous F1）和图结构保真度（Graph F1）的三维评估体系。实验结果表明：（1）全局增量式本体生成在中等规模场景质量最优，但存在不可逾越的规模瓶颈；（2）检索式增量生成是质量与效率的综合平衡方案；（3）渐进式披露增量生成在大规模场景表现稳健且可扩展性良好；（4）独立片段式本体生成在精度上存在明显短板，但并行效率突出。

（二）未来研究展望

展望未来，基于LLM的本体构建技术将在以下几个方向持续演进：

从单模态到多模态的本体构建。随着多模态大模型能力的快速进步，融合文本、图像、表格、视频等多种信息源的本体构建将成为下一个前沿。未来的本体将不再局限于文本概念的描述，而是包含视觉特征、时序模式、空间关系等多维语义，形成真正的"多模态知识图谱"。如何实现跨模态概念的统一表示与对齐，如何处理模态间的信息冗余与冲突，将是该方向的核心挑战。

从静态本体到动态本体的演进。当前的本体构建方法主要面向静态文档集合，输出相对稳定的本体结构。然而，真实世界的知识是持续演化的——新概念不断涌现，已有概念的定义和关系随时间变化。未来的本体构建系统需要具备持续学习（Continual Learning）能力，能够从流式文档输入中自动检测本体漂移（Ontology Drift），触发增量更新，同时避免对已有知识的灾难性遗忘。这要求新的概念生命周期管理机制和版本控制策略。

从自动化到自适应的智能化升级。未来的本体构建系统将不再是"一刀切"的固定流程，而是能够根据输入数据的特征（领域、规模、质量、格式分布）自动选择最优的处理管道。通过元学习（Meta-Learning）和神经架构搜索（NAS），系统可以在不同场景间自动迁移和适配，实现真正的"零配置"本体构建。同时，系统将与领域专家形成深度协作关系，通过持续的人机交互不断优化自身的构建策略。

从孤立本体到本体生态的构建。单一领域的本体往往难以满足复杂应用的需求。未来的研究将更多地关注跨领域本体的自动对齐与融合，构建大规模的互联本体网络（Ontology Network）。这要求新的跨本体映射技术、分布式本体存储与查询机制，以及本体级别的隐私保护和安全共享方案。

从技术工具到工程平台的转化。本文的研究主要聚焦于核心算法和单点技术，而工业级的本体工程还需要完善的平台能力支撑——包括可视化编辑与审核界面、版本管理与回溯机制、质量监控与告警系统、API服务与集成能力等。将本文的技术成果产品化为端到端的工程平台，是实现大规模商业化落地的关键路径。

总之，基于LLM的本体构建技术正处于快速发展与深度应用的交汇点。随着大语言模型能力的持续增强、多模态技术的日益成熟、以及工程实践的不断积累，自动化本体构建必将在知识图谱、智能问答、数据治理、企业数字化转型等领域发挥越来越重要的作用。