从文档到知识图谱：基于 Ollama + RAG 的实体/关系自动抽取实战
一、整体思路：RAG + 实体抽取 + 图谱
你要做的方向可以概括成一句话：
用 RAG 先把“该看的文档片段”找出来，再用本地大模型从这些片段里抽实体和关系，最后把它们变成一个可视化的知识图谱。
这跟你之前做“代码知识库问答”是平行的另一个分支，只不过对象从“代码 + git diff”换成了“普通文档 + 实体/关系”。
可以拆成 4 步：
文档入库 + 向量检索（RAG 部分）：
- 用 embedding 模型（比如
nomic-embed-text）对文档做分块向量化，存到向量库（Chroma/FAISS 等）。 - 后面无论是“全量抽取”还是“按查询抽取”，都先通过 RAG 把最相关的片段拿出来。
- 用 embedding 模型（比如
实体抽取（NER + 概念抽取）：
- 用本地大模型（Qwen3.5）对这些片段做结构化信息抽取，识别：
- 人物、组织、地点、时间、产品、技术名词、业务概念……
- 用本地大模型（Qwen3.5）对这些片段做结构化信息抽取，识别：
关系抽取（RE）：
- 同样用大模型，在“已识别实体 + 文本片段”的上下文下，让模型输出
- 谁和谁是什么关系：属于、依赖、创建于、位于、由……提出等。
- 同样用大模型，在“已识别实体 + 文本片段”的上下文下，让模型输出
图谱构建 + 可视化：
- 用 NetworkX/Neo4j 存储成图结构；
- 用 PyVis 或 Neo4j Bloom 可视化；
- 再往上可以接一个 Streamlit 小界面做交互查询。
我们先来看下效果：
使用地址：https://ai.multikb.com
二、核心架构设计（面向实现 & 写文）
可以画成一个很直观的图（文里用 ASCII 就够用）：
原始文档（TXT/MD/PDF）
│
▼
文本分块 + Embedding
│
▼
向量库（Chroma）
│
├─ 全量抽取模式：直接遍历所有 chunk
│
└─ 按查询抽取模式：根据用户问题先检索相关 chunk（RAG）
│
▼
本地 Qwen3.5 抽取实体 & 关系
│
▼
知识图谱（NetworkX/Neo4j）
│
▼
Streamlit/PyVis 可视化 & 查询
你文章里可以主推两种使用模式：
- 离线全量抽取模式：
- 用于“读完一整份白皮书/规范/书籍，生成一张全景知识图谱”；
- 在线按需抽取模式（RAG 加持）：
- 用户提一个问题 / 选一个主题，系统先 RAG 找相关段落，再从这些段落中抽实体和关系 → 得到“围绕问题的一个局部知识子图”。
三、关键技术点 & 实现建议
1. RAG：为什么要先做检索再抽取？
- 文档一多，直接对“全文”做实体/关系抽取：
- 成本高：每次调用大模型 token 爆炸；
- 容易乱：没聚焦到主题，提到的边会非常多，很难用。
- 加一层 RAG 有几个好处：
- 限制上下文：只对当下问题相关的 chunk 抽取；
- 提高质量：小上下文内做抽取，模型更不容易“乱联想”；
- 更贴合业务：比如“帮我画出‘支付流程’的概念图”，检索阶段就可以限定到“支付相关的段落”。
实现上你可以沿用你之前代码知识库那套：
- embedding：
nomic-embed-text（Ollama） - 向量库：ChromaDB
- 分块策略：按句子/段落 + 长度上限（如 500～1000 字符）
2. 实体抽取 Prompt 设计（大模型调用）
建议把抽取格式强制限定为 JSON 数组，这点你已经在代码里实践过了。一个典型 Prompt 结构：
你是一个专业的信息抽取助手，请从以下文本中识别出所有实体。 要求： 1. 尽量识别：人物、组织、地点、时间、产品/项目名称、技术名词、业务概念等； 2. 每个实体输出：name, type, description 三个字段； 3. 仅返回 JSON 数组，不要任何额外解释。 示例输出格式： [ {"name": "阿里云", "type": "组织", "description": "阿里巴巴集团旗下的云计算服务提供商"}, {"name": "杭州", "type": "地点", "description": "阿里云总部所在地"}, ... ] 下面是待分析文本： <插入 chunk 文本>在实现层面，你已经有了类似的EntityExtractor类：
- 按 chunk 调用
ollama.chat(...) - 用正则
$$.*$$提取 JSON 段 json.loads解析、失败就丢弃- 再对所有实体做合并去重（按 name 小写）
3. 关系抽取 Prompt 设计
关系抽取的 Prompt 可以在“已知实体列表”的基础上做约束，减少模型乱造关系：
你是一个专业信息抽取助手，请从以下文本中识别出“实体之间的关系”。 文本中已识别的实体有（可能不全，仅供参考）： 阿里云, 杭州, 马云, 阿里云智能集团, 阿里云研究院 要求： 1. 每条关系输出 4 个字段：source, target, relation, description； 2. relation 尽量用简短动词或短语，比如："位于", "创立", "子公司", "属于", "提出", "依赖", "使用" 等； 3. 仅返回 JSON 数组，不要任何多余文字。 文本： <插入 chunk 文本>你的代码里已经把这块封装成extract_relations(text, entities)，这完全可以复用到新方向上。
四、图谱构建：从实体/关系到图
你已经用 NetworkX + PyVis 做了一个轻量级知识图谱实现，这非常适合 CSDN 文章和小团队内部工具：
- 节点（Node）：实体
- 属性：
name,type,description
- 属性：
- 边（Edge）：关系
- 属性：
source,target,relation,description
- 属性：
构建逻辑：
G = nx.DiGraph() # 节点 for e in entities: G.add_node( e["name"], type=e["type"], description=e.get("description", "") ) # 边 for r in relations: if r["source"] in G and r["target"] in G: G.add_edge( r["source"], r["target"], relation=r["relation"], description=r.get("description", "") )可视化部分你已经用 PyVis 实现了：
- 不同实体类型用不同颜色；
- 悬浮节点可看描述；
- 边上可以展示关系类型。
后续如果你想做“更专业一点”的：
- 可以把 NetworkX 层直接换成 Neo4j：
- 节点 → Neo4j Node
- 边 → Neo4j Relationship
- 然后用 Neo4j Bloom/cypher 查询做更复杂的分析。
五、实践层面的几点建议
先做“非严格 RAG 版”
- 第一篇可以不强调 RAG 的检索流程，直接“对整篇文档实体/关系抽取 + 画图”，读者更容易理解；
- 第二篇再写“RAG + 图谱”（比如：针对问题只抽取相关子图）。
文档选择
- 选结构相对清晰的文本：公司介绍、产品手册、技术白皮书的一章；
- 太口语化、太乱的文本抽关系会很难看。
图谱呈现尽量简单直观
- 不要一次塞几百个节点；
- 示例里控制在几十个节点以内，这样截图效果最好。