# 知识库引入知识图谱（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。