从文本到知识图谱：两条技术路线与三个开源实践方案

在检索增强生成（RAG）技术遍地开花的今天，大多数知识库系统仍然停留在「切块、向量化、召回、生成」的线性流程中。这种方式在处理与原文表述相近的简单问题时游刃有余，但面对跨段落关系推理、实体别名识别、事件时序分析等复杂场景时，往往显得力不从心。知识图谱的出现，为解决这些问题提供了一条新的思路——它不仅存储孤立的文本片段，更通过节点与边的结构，记录了「谁与谁有关、通过什么关系关联、这种关联出现在哪里」。

自由发现型：让模型自主探索概念关系

将文本转化为知识图谱并非新鲜事物，但其核心挑战始终在于：如何让这张图在后续检索、问答和知识建模时依然可信可用。当前业界主要探索出两条互补的技术路线，适用于不同的业务场景和成熟度阶段。

本体约束型：用结构化框架指导抽取过程

第一条路线以自由发现为核心思想。它不预先设定实体类型和关系枚举，而是让大语言模型在阅读文本后，自主识别其中的重要概念及其语义关联。这种方法的基本流程是：首先将语料切分为多个文本块并分配唯一标识；随后让本地模型从每个文本块中抽取概念和语义关系，标记为第一类权重（W1）；接着对同一文本块中共同出现的概念增加「上下文邻近关系」，标记为第二类权重（W2）；最后合并同一节点对、累加权重，将结果交给图分析工具进行处理。 这种方案的突出优势在于启动速度快，特别适合面对没有固定结构的文章、论文和专业资料。它的核心价值在于探索性——先让模型「看见」知识之间的关系，再由领域专家判断哪些实体类别和关系值得进一步建模。不过需要警惕的是：模型可能将未明确出现的概念补全，也可能把同一对象拆分成多个名字，上下文邻近关系还容易被误读为存在事实关联。

三个开源项目各司其职

第二条路线则反其道而行之，强调在抽取之前先定义要观察什么。用户需要预先构建实体标签和关系类型的本体（Ontology），模型则被约束在这一框架内进行抽取。例如，一个用于人物与地点的知识库可以定义 Person、Place 两种实体类型，以及「居住于」「访问」等预置关系；临床研究场景则可以替换为化合物、用途、效果和反应等专业概念。 这种方法通过 Pydantic 模型定义 Ontology，将语料切分为约 200-500 token 的文本块，逐块生成子图后再汇总为完整图谱。边模型携带的 metadata 可以记录页码、章节、文章名等来源信息，order 字段则支持按文本块顺序观察关系的演变过程。这对于书籍、长篇报告和时间线类材料尤为有价值。 本体约束的代价是 schema 设计本身需要领域知识积累——关系定义过宽会失去约束意义，过窄又会遗漏有用信息。更务实的做法是先用小样本建立初始本体，再用实际抽取结果反向迭代修订。

五条实践建议与常见陷阱

在具体工程实现层面，三个开源项目分别解决了知识图谱生命周期的不同环节。 **knowledge_graph** 是轻量级的概念图谱实验场，专注于让用户在本地快速验证想法。它使用 Mistral 7B 等开源模型进行文本抽取，通过 Ollama 提供本地模型服务，NetworkX 进行图分析，Pyvis 生成可交互的可视化结果。项目提供 Docker 启动方式，便于个人机器上快速复现。对于想理解文本建图原理、验证图增强生成（GRAG）效果的开发者来说，这是理想的起点。但需要清醒认识到，它本质上是研究型原型，不涵盖完整的知识库生命周期管理。 **llm_wiki** 则将视野从「生成一张图」扩展到「建立持续运营的知识库」。它采用「原始来源、Wiki 内容、Schema 规则」三层架构，围绕导入（Ingest）、查询（Query）、校验（Lint）三个核心操作组织工作流。最具特色的设计是将一次导入拆分为两个阶段：先由 LLM 阅读来源形成结构化分析，再根据分析结果生成 Wiki 页面。这种拆分让「理解来源」和「改写知识库」分离，便于追踪和人工复核。系统还提供增量缓存、持久化导入队

如有侵权，请联系删除。