KnowledgeBase/docs/3.0/knowledge_graph_analysis.md

知识库引入知识图谱（Knowledge Graph）分析与实施建议

基于项目当前技术栈（前端 React/Vite，后端 NestJS，使用 Elasticsearch、TypeORM 和 Langchain），如果要在现有的知识库（Knowledge Base）中引入知识图谱（Knowledge Graph）功能，通常是为了向 GraphRAG（图检索增强生成）演进。这能极大地提升系统处理复杂查询（如跨文档、多跳推理关联）的能力。

以下是针对现有项目的架构分析与实施建议：

一、 核心价值与应用场景

将知识图谱引入知识库后，您可以实现：

1. 更精准的 RAG (GraphRAG)：传统的向量检索（如 Elasticsearch 密集向量）擅长捕捉语义相似性，但在“找出A与C之间的所有中间联系”等多跳逻辑推理上表现不佳。图谱可以弥补这一短板。
2. 可视化探索：允许用户在前端以节点和边的形式，直观地浏览知识库中概念之间的关系。
3. 知识融合：将分布在多篇独立文档（PDF/Word等）中的碎片化信息，通过实体（Entity）统一串联成网状结构。

二、 技术选型建议

考虑到后端已经深度集成了 @langchain/core 和 @langchain/openai，强烈建议最大限度复用 Langchain 的生态体系。

1. 图数据库 (Graph Database) 选型：

   • 优选：Neo4j。它是目前与大模型和 Langchain 集成最成熟的图数据库。Langchain 原生支持 Neo4j（通过相关的扩展包），并且可以直接用 Cypher 语言进行图查询。
   • 备选：Memgraph 或 NebulaGraph。
   • 当前栈复用：如果不希望引入新的数据库组件，您也可以先用关系型数据库（当前用的 TypeORM 控制的底层数据库）建立三元组表 (head, relation, tail) 作为简化版的图存储，但查询效率和图算法能力远不及原生图引擎。

2. 实体/关系提取 (Knowledge Extraction)：

   • 方案：利用 LLM（目前已接入的大语言模型）。使用 Langchain 构建信息抽取链（Extraction Chain），通过 Prompt 指导模型从文本分块（Chunks）中提取 [实体1] -> [关系] -> [实体2] 的三元组。
   • 工具：可以使用 Langchain 提供的 LLMGraphTransformer 工具。

3. 前端可视化组件：

   • 推荐：react-force-graph （轻量、支持 2D/3D、适合 React）。
   • 备选：vis-network 或 ECharts 的关系图组件。

三、 架构演进与实施步骤

建议分几个阶段进行，逐步迭代：

第一阶段：数据管道升级（建图）

在当前的文件上传、解析和切分（Text Splitters）流程中，在存入 Elasticsearch 向量库的同时，增加一条图谱构建分支：

1. 文本分块 (Chunking)：复用现有的切分逻辑。
2. 实体抽取 (Extraction)：将 Chunk 发送给 LLM，提示词例如：“从以下文本中提取关键实体（如人名、机构、技术、概念）及它们之间的关系，以 JSON 格式输出。”
3. 实体消歧与对齐 (Entity Resolution)：比如“Apple”和“苹果公司”应指向同一个节点。可以结合向量空间中相似度，将意思相近的实体进行合并。
4. 存入图数据库：将提取出的 Node（实体）和 Edge（关系）写入 Neo4j。并将源文档的 Chunk ID 作为属性附加在 Node 或 Edge 上，以此实现“图谱与原文档内容的双向链接”。

第二阶段：检索融合 (Hybrid RAG)

改造当前的问答（Chat/Search）接口，引入混合检索（Hybrid Retrieval）：

1. 用户输入问题后，首先利用 LLM 解析问题中的核心实体。
2. 图检索：从图库中查询这些实体，获取相关的连通子图（例如周围 2 度的节点和边）。
3. 向量检索：同时在 Elasticsearch 中进行传统的语义相似度检索。
4. 上下文组装：将图谱中查到的关系路径（如：A -> 属于 -> B -> 包含 -> C）转化为自然语言，与向量检索拿到的文本片段拼在一起，作为 prompt 提供给 LLM 回答。

第三阶段：前端图谱可视化

1. 提供一个单独的“知识图谱”视图页面。
2. 后端提供 /api/knowledge-graph/nodes 接口，根据当前知识图（或特定过滤条件下的子图）返回节点和链接数据。
3. 前端使用 react-force-graph 渲染：
   • 点击某个节点，可以展开查询关联节点。
   • 关联节点可以溯源，显示出“该关系是由哪份知识库文档的哪一句话提取出来的”。

四、 项目需要做出的具体改动评估

1. 依赖层 (server/package.json)：
   • 需要新增类似 neo4j-driver、@langchain/community 等依赖。
   • Docker 环境：docker-compose.yml 中需要引入 Neo4j 容器。
2. 知识处理流 (server/src/knowledge-base/ 等目录)：
   • 需要新增一个专门处理图操作的服务（如 graph.service.ts）。
   • 需要修改当前的导入任务（import-task），让其支持异步地调用大模型进行耗时的实体抽取操作（这部分成本较高且较慢，建议通过事件驱动或消息队列异步处理）。
3. 前端展示 (web/components/)：
   • 设计新的 UI 组件（如 GraphViewer.tsx）。

五、 核心建议与避坑指南

1. Token 成本与耗时控制：从全文中提取高质量图谱极耗费 Token，且速度慢。建议初期只对高价值核心文档开启图谱提取，并且采用批处理异步任务。
2. 模型能力要求：信息抽取高度依赖模型的指令遵循（Instruction Following）能力。如果使用的是私有部署的小模型，可能会出现实体抽取格式混乱的问题；建议使用如 GPT-4o, Claude 3.5 Sonnet 等强模型进行图谱提取。
3. 本体论 (Ontology) 建设：完全开放域的“自由抽取”会导致图谱非常混乱（如“今天”也成了一个无意义节点）。建议在业务初期，预定义好希望提取的实体类型（如：只提取 [产品], [故障], [解决方案], [组件] 四类），在 Prompt 中强制 LLM 遵守这一 Schema。