You've already forked DataMate
feat(kg): 实现 Phase 3.1 前端图谱浏览器
核心功能： - G6 v5 力导向图，支持交互式缩放、平移、拖拽 - 5 种布局模式：force, circular, grid, radial, concentric - 双击展开节点邻居到图中（增量探索） - 全文搜索，类型过滤，结果高亮（变暗/高亮状态） - 节点详情抽屉：实体属性、别名、置信度、关系列表（可导航） - 关系详情抽屉：类型、源/目标、权重、置信度、属性 - 查询构建器：最短路径/全路径查询，可配置 maxDepth/maxPaths - 基于 UUID 的图加载（输入或 URL 参数 ?graphId=...） - 大图性能优化（200 节点阈值，超过时禁用动画） 新增文件（13 个）： - knowledge-graph.model.ts - TypeScript 接口，匹配 Java DTOs - knowledge-graph.api.ts - API 服务，包含所有 KG REST 端点 - knowledge-graph.const.ts - 实体类型颜色、关系类型标签、中文显示名称 - graphTransform.ts - 后端数据 → G6 节点/边格式转换 + 合并工具 - graphConfig.ts - G6 v5 图配置（节点/边样式、行为、布局） - hooks/useGraphData.ts - 数据钩子：加载子图、展开节点、搜索、合并 - hooks/useGraphLayout.ts - 布局钩子：5 种布局类型 - components/GraphCanvas.tsx - G6 v5 画布，力导向布局，缩放/平移/拖拽 - components/SearchPanel.tsx - 全文实体搜索，类型过滤 - components/NodeDetail.tsx - 实体详情抽屉 - components/RelationDetail.tsx - 关系详情抽屉 - components/QueryBuilder.tsx - 路径查询构建器 - Home/KnowledgeGraphPage.tsx - 主页面，整合所有组件 修改文件（5 个）： - package.json - 添加 @antv/g6 v5 依赖 - vite.config.ts - 添加 /knowledge-graph 代理规则 - auth/permissions.ts - 添加 knowledgeGraphRead/knowledgeGraphWrite - pages/Layout/menu.tsx - 添加知识图谱菜单项（Network 图标） - routes/routes.ts - 添加 /data/knowledge-graph 路由 新增文档（10 个）： - docs/knowledge-graph/ - 完整的知识图谱设计文档 Bug 修复（Codex 审查后修复）： - P1: 详情抽屉状态与选中状态不一致（显示旧数据） - P1: 查询构建器未实现（最短路径/多路径查询） - P2: 实体类型映射 Organization → Org（匹配后端） - P2: getSubgraph depth 参数无效（改用正确端点） - P2: AllPathsVO 字段名不一致（totalPaths → pathCount） - P2: 搜索取消逻辑无效（传递 AbortController.signal） - P2: 大图性能优化（动画降级） - P3: 移除未使用的类型导入 构建验证： - tsc --noEmit ✅ clean - eslint ✅ 0 errors/warnings - vite build ✅ successful
This commit is contained in:
289
docs/knowledge-graph/analysis/claude.md
Normal file
289
docs/knowledge-graph/analysis/claude.md
Normal file
@@ -0,0 +1,289 @@
|
||||
# Claude 知识图谱分析结果
|
||||
|
||||
## 分析时间
|
||||
2026-02-17
|
||||
|
||||
## 核心建议
|
||||
|
||||
### 1. 技术选型
|
||||
|
||||
**图数据库**：Neo4j（社区版或企业版）
|
||||
|
||||
**存储架构**：MySQL + Neo4j 双存储
|
||||
- **MySQL**：元数据主库，保持现有业务逻辑
|
||||
- **Neo4j**：图结构专用存储，支持复杂查询
|
||||
|
||||
**同步策略**：最终一致性 + 对账机制
|
||||
|
||||
### 2. 架构设计（复用现有基础设施）
|
||||
|
||||
**核心原则**：
|
||||
- 复用现有的服务架构
|
||||
- 最小化对现有系统的影响
|
||||
- 渐进式集成
|
||||
|
||||
**集成方式**：
|
||||
```
|
||||
现有服务 → MySQL（主库）
|
||||
↓ 同步
|
||||
Neo4j（图库）
|
||||
↓ 查询
|
||||
kg-service（新服务）
|
||||
```
|
||||
|
||||
### 3. 数据建模（Schema 先行 + 版本管理）
|
||||
|
||||
#### Schema 设计原则
|
||||
1. **先行设计**：明确定义实体和关系
|
||||
2. **版本管理**：支持 Schema 演进
|
||||
3. **向后兼容**：新版本兼容旧版本
|
||||
4. **文档化**：详细记录每个版本的变更
|
||||
|
||||
#### 实体属性设计
|
||||
```json
|
||||
{
|
||||
"id": "UUID",
|
||||
"name": "名称",
|
||||
"type": "类型",
|
||||
"description": "描述",
|
||||
"tenant_id": "租户ID",
|
||||
"schema_version": "1.0",
|
||||
"created_at": "创建时间",
|
||||
"updated_at": "更新时间"
|
||||
}
|
||||
```
|
||||
|
||||
#### 关系属性设计
|
||||
```json
|
||||
{
|
||||
"source": "源节点ID",
|
||||
"target": "目标节点ID",
|
||||
"type": "关系类型",
|
||||
"confidence": "置信度（0-1）",
|
||||
"source": "来源（manual/auto）",
|
||||
"valid_from": "生效时间",
|
||||
"valid_to": "失效时间"
|
||||
}
|
||||
```
|
||||
|
||||
### 4. 实施路线图（4 阶段）
|
||||
|
||||
#### 第 0 阶段：基础设施（1周）✅
|
||||
- 搭建 Neo4j
|
||||
- 创建基础服务
|
||||
- 定义 Schema
|
||||
|
||||
#### 第 1 阶段：核心功能（2-3周）
|
||||
- 实现同步机制
|
||||
- 实现基础查询
|
||||
- 集成到现有系统
|
||||
|
||||
#### 第 2 阶段：高级功能（3-4周）
|
||||
- 实现 GraphRAG
|
||||
- 实现可视化
|
||||
- 性能优化
|
||||
|
||||
#### 第 3 阶段：持续优化
|
||||
- 扩展功能
|
||||
- 优化性能
|
||||
- 提升体验
|
||||
|
||||
### 5. 挑战解决方案
|
||||
|
||||
#### 数据一致性
|
||||
**问题**：MySQL 和 Neo4j 数据可能不一致
|
||||
|
||||
**解决方案**：
|
||||
- **最终一致性**：允许短暂的不一致
|
||||
- **对账机制**：定期对比并修复
|
||||
- **事件驱动**：通过事件同步变更
|
||||
|
||||
**实现**：
|
||||
```java
|
||||
@Scheduled(cron = "0 0 2 * * *") // 每天凌晨 2 点
|
||||
public void reconcile() {
|
||||
// 1. 查询 MySQL 中的所有实体
|
||||
List<Dataset> datasets = datasetRepository.findAll();
|
||||
|
||||
// 2. 查询 Neo4j 中的所有实体
|
||||
List<GraphEntity> graphEntities = graphEntityRepository.findAll();
|
||||
|
||||
// 3. 对比并找出差异
|
||||
List<Diff> diffs = compare(datasets, graphEntities);
|
||||
|
||||
// 4. 修复差异
|
||||
for (Diff diff : diffs) {
|
||||
if (diff.getType() == DiffType.MISSING_IN_NEO4J) {
|
||||
syncToNeo4j(diff.getEntity());
|
||||
} else if (diff.getType() == DiffType.OUTDATED_IN_NEO4J) {
|
||||
updateNeo4j(diff.getEntity());
|
||||
}
|
||||
}
|
||||
|
||||
// 5. 记录日志
|
||||
log.info("Reconciliation completed: {} diffs fixed", diffs.size());
|
||||
}
|
||||
```
|
||||
|
||||
#### 性能优化
|
||||
**问题**：大规模图谱查询性能下降
|
||||
|
||||
**解决方案**：
|
||||
- **索引策略**：在高频字段上创建索引
|
||||
- **限制遍历深度**：最大 3 跳
|
||||
- **Redis 缓存**：缓存热点数据
|
||||
- **离线计算**：预计算常用子图
|
||||
|
||||
**索引创建**：
|
||||
```cypher
|
||||
// 实体 ID 索引
|
||||
CREATE INDEX entity_id IF NOT EXISTS FOR (n:Entity) ON (n.id);
|
||||
|
||||
// 租户 ID 索引
|
||||
CREATE INDEX entity_tenant_id IF NOT EXISTS FOR (n:Entity) ON (n.tenant_id);
|
||||
|
||||
// 复合索引
|
||||
CREATE INDEX entity_id_graph_id IF NOT EXISTS
|
||||
FOR (n:Entity) ON (n.id, n.graph_id);
|
||||
```
|
||||
|
||||
#### 前端可视化
|
||||
**问题**：大规模图谱难以可视化
|
||||
|
||||
**解决方案**：
|
||||
- **分层加载**：先加载核心节点，再加载周边
|
||||
- **子图裁剪**：只显示相关子图
|
||||
- **WebGL 渲染**：使用 WebGL 提升性能
|
||||
- **虚拟滚动**：只渲染可见区域
|
||||
|
||||
**推荐库**：
|
||||
- Cytoscape.js（功能丰富）
|
||||
- AntV G6（国产，文档友好）
|
||||
- vis.js（简单易用）
|
||||
|
||||
### 6. 最佳实践
|
||||
|
||||
#### 开发实践
|
||||
1. **API 规范一致**：遵循 RESTful 规范
|
||||
2. **复用现有模式**：使用现有的 DTO、ErrorCode
|
||||
3. **事件驱动解耦**：通过事件同步变更
|
||||
4. **Cypher 注入防护**：使用参数化查询
|
||||
|
||||
#### 运维实践
|
||||
1. **Neo4j 备份**：每天全量备份
|
||||
2. **监控告警**：Prometheus + Grafana
|
||||
3. **性能调优**：定期分析慢查询
|
||||
4. **容量规划**：根据数据增长预测资源需求
|
||||
|
||||
#### 部署实践
|
||||
1. **Docker 部署**：使用 docker-compose
|
||||
2. **Kubernetes 扩展**：使用 Helm Chart
|
||||
3. **灰度发布**：先在小范围验证
|
||||
4. **回滚机制**：支持快速回滚
|
||||
|
||||
### 7. 代码实现细节
|
||||
|
||||
#### 双重防御示例
|
||||
```java
|
||||
// Controller 层：格式校验
|
||||
@GetMapping("/{graphId}/entities/{entityId}")
|
||||
public GraphEntity getEntity(
|
||||
@PathVariable @Pattern(regexp = UUID_REGEX, message = "graphId 格式无效")
|
||||
String graphId,
|
||||
@PathVariable @Pattern(regexp = UUID_REGEX, message = "entityId 格式无效")
|
||||
String entityId
|
||||
) {
|
||||
return entityService.getEntity(graphId, entityId);
|
||||
}
|
||||
|
||||
// Service 层：业务校验
|
||||
public GraphEntity getEntity(String graphId, String entityId) {
|
||||
// 1. 校验 graphId 格式
|
||||
validateGraphId(graphId);
|
||||
|
||||
// 2. 查询实体（同时校验 graphId 和 entityId）
|
||||
return entityRepository.findByIdAndGraphId(entityId, graphId)
|
||||
.orElseThrow(() -> BusinessException.of(
|
||||
KnowledgeGraphErrorCode.ENTITY_NOT_FOUND
|
||||
));
|
||||
}
|
||||
|
||||
// Repository 层：数据访问
|
||||
@Query("MATCH (n:Entity {id: $id, graph_id: $graphId}) RETURN n")
|
||||
Optional<GraphEntity> findByIdAndGraphId(
|
||||
@Param("id") String id,
|
||||
@Param("graphId") String graphId
|
||||
);
|
||||
```
|
||||
|
||||
#### 查询限流示例
|
||||
```java
|
||||
public List<GraphEntity> getNeighbors(
|
||||
String graphId,
|
||||
String entityId,
|
||||
int depth,
|
||||
int limit
|
||||
) {
|
||||
// Clamp 参数到配置的最大值
|
||||
int actualDepth = Math.min(depth, properties.getMaxDepth());
|
||||
int actualLimit = Math.min(limit, properties.getMaxNodesPerQuery());
|
||||
|
||||
// 查询
|
||||
return entityRepository.findNeighbors(
|
||||
graphId, entityId, actualDepth, actualLimit
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### 8. 建议的下一步
|
||||
|
||||
**立即行动**：
|
||||
1. 实现 Relation 的完整功能
|
||||
2. 实现 MySQL → Neo4j 同步
|
||||
3. 补充单元测试
|
||||
|
||||
**短期目标**（1-2周）：
|
||||
1. 完成 MVP 功能
|
||||
2. 集成到现有系统
|
||||
3. 进行性能测试
|
||||
|
||||
**中期目标**（1-2月）：
|
||||
1. 实现 GraphRAG
|
||||
2. 实现可视化
|
||||
3. 上线第一个场景
|
||||
|
||||
## 与其他工具的对比
|
||||
|
||||
| 维度 | Claude | Codex | Gemini |
|
||||
|------|--------|-------|--------|
|
||||
| **技术选型** | Neo4j | Neo4j/JanusGraph | Neo4j |
|
||||
| **架构重点** | 复用现有基础设施 | 3个新模块 | GraphRAG 融合 |
|
||||
| **数据建模** | Schema先行+版本管理 | 10类实体+6类关系 | 灵活Schema+embedding |
|
||||
| **实现路径** | 4阶段 | 4阶段（0-3） | 3阶段（MVP优先） |
|
||||
| **独特优势** | 深度集成现有系统 | 详细的领域模型 | LangChain+RAG融合 |
|
||||
|
||||
## 关键洞察
|
||||
|
||||
1. **深度集成**：Claude 强调复用现有基础设施，最小化影响
|
||||
2. **最终一致性**：提出了实用的数据同步和对账方案
|
||||
3. **详细的代码示例**：提供了可直接使用的代码片段
|
||||
4. **运维实践**：关注生产环境的监控、备份、部署
|
||||
|
||||
## 建议采纳度
|
||||
|
||||
**强烈推荐**：
|
||||
- ✅ MySQL + Neo4j 双存储架构
|
||||
- ✅ 最终一致性 + 对账机制
|
||||
- ✅ 双重防御（Controller + Service）
|
||||
- ✅ 查询限流
|
||||
- ✅ 运维实践（备份、监控）
|
||||
|
||||
**可选**：
|
||||
- ⚠️ 事件驱动同步（可以先用定时任务）
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [总体方案](../README.md)
|
||||
- [架构设计](../architecture.md)
|
||||
- [Gemini 分析结果](./gemini.md)
|
||||
- [Codex 分析结果](./codex.md)
|
||||
201
docs/knowledge-graph/analysis/codex.md
Normal file
201
docs/knowledge-graph/analysis/codex.md
Normal file
@@ -0,0 +1,201 @@
|
||||
# Codex 知识图谱分析结果
|
||||
|
||||
## 分析时间
|
||||
2026-02-17
|
||||
|
||||
## 核心建议
|
||||
|
||||
### 1. 技术选型
|
||||
|
||||
**图数据库**：
|
||||
- **首选**：Neo4j（成熟稳定，社区活跃）
|
||||
- **备选**：JanusGraph（分布式场景）
|
||||
|
||||
**理由**：
|
||||
- Neo4j 的 Cypher 查询语言简洁强大
|
||||
- Spring Data Neo4j 集成良好
|
||||
- 丰富的图算法库
|
||||
- 适合中小规模图谱（< 1000万节点）
|
||||
|
||||
### 2. 架构设计（3 个新模块）
|
||||
|
||||
#### kg-ingestion (FastAPI)
|
||||
**职责**：知识抽取和预处理
|
||||
- 文本 → 实体 + 关系
|
||||
- 实体对齐和消歧
|
||||
- 置信度评分
|
||||
|
||||
#### kg-service (Spring Boot)
|
||||
**职责**：图谱查询和管理
|
||||
- 图查询 API
|
||||
- 权限控制
|
||||
- 缓存管理
|
||||
|
||||
#### kg-ui (React)
|
||||
**职责**：图谱可视化
|
||||
- AntV G6 可视化
|
||||
- 交互式查询
|
||||
- 编辑功能
|
||||
|
||||
### 3. 数据建模（10 类实体 + 6 类关系）
|
||||
|
||||
#### 核心实体（10 类）
|
||||
1. **Dataset**：数据集
|
||||
2. **Field**：字段
|
||||
3. **LabelTask**：标注任务
|
||||
4. **Workflow**：工作流
|
||||
5. **Job**：作业
|
||||
6. **Rule**：规则
|
||||
7. **User**：用户
|
||||
8. **Org**：组织
|
||||
9. **Model**：模型
|
||||
10. **Issue**：问题
|
||||
|
||||
#### 核心关系（6 类）
|
||||
1. **HAS_FIELD**：数据集包含字段
|
||||
2. **TRIGGERS**：触发关系
|
||||
3. **USES_RULE**：使用规则
|
||||
4. **ASSIGNED_TO**：分配给
|
||||
5. **PRODUCED_BY**：产生于
|
||||
6. **IMPACTS**：影响
|
||||
|
||||
### 4. 实施路线图（4 阶段）
|
||||
|
||||
#### 第 0 阶段：场景确定（1-2周）
|
||||
- 确定 2 个高价值场景
|
||||
- 定义核心实体和关系
|
||||
- 设计 Schema
|
||||
|
||||
#### 第 1 阶段：PoC（2-4周）
|
||||
- 搭建基础设施
|
||||
- 实现基础抽取
|
||||
- 验证技术可行性
|
||||
|
||||
#### 第 2 阶段：生产化（4-8周）
|
||||
- 完善功能
|
||||
- 性能优化
|
||||
- 集成到现有系统
|
||||
|
||||
#### 第 3 阶段：持续优化
|
||||
- 扩展实体和关系
|
||||
- 优化算法
|
||||
- 提升用户体验
|
||||
|
||||
### 5. 潜在挑战
|
||||
|
||||
#### 数据质量
|
||||
**问题**：元数据不完整或不准确
|
||||
|
||||
**解决方案**：
|
||||
- 数据清洗和标准化
|
||||
- 人工审核机制
|
||||
- 置信度评分
|
||||
|
||||
#### 性能瓶颈
|
||||
**问题**：大规模图谱查询性能下降
|
||||
|
||||
**解决方案**：
|
||||
- 索引优化
|
||||
- 查询限流
|
||||
- 缓存热点数据
|
||||
- 离线计算
|
||||
|
||||
#### 多租户隔离
|
||||
**问题**：不同租户的数据需要隔离
|
||||
|
||||
**解决方案**：
|
||||
- 所有节点包含 tenant_id
|
||||
- 查询时自动过滤
|
||||
- 权限控制
|
||||
|
||||
### 6. 最佳实践
|
||||
|
||||
#### Schema 设计
|
||||
- **先行设计**：明确定义实体和关系
|
||||
- **版本管理**：支持 Schema 演进
|
||||
- **文档化**：详细记录每个实体和关系
|
||||
|
||||
#### 查询优化
|
||||
- **限制深度**：最大 3 跳
|
||||
- **限制数量**：最大 1000 个节点
|
||||
- **使用索引**：在高频字段上创建索引
|
||||
- **缓存结果**：缓存热点查询
|
||||
|
||||
#### 安全性
|
||||
- **参数化查询**：防止 Cypher 注入
|
||||
- **权限控制**：基于角色的访问控制
|
||||
- **审计日志**：记录所有操作
|
||||
|
||||
### 7. 代码审查发现的问题
|
||||
|
||||
#### P0 - 严重问题
|
||||
1. **主应用未声明依赖**：已修复
|
||||
2. **Neo4j 凭据硬编码**：已修复
|
||||
3. **graphId 参数未校验**：已修复
|
||||
|
||||
#### P1 - 重要问题
|
||||
4. **异常处理不规范**：已修复
|
||||
5. **查询未限流**：已修复
|
||||
6. **异常码体系未对齐**：已修复
|
||||
|
||||
#### P2 - 中等问题
|
||||
7. **关系建模未打通**：待实现
|
||||
8. **列表接口缺分页**：待实现
|
||||
9. **Python 模块未接入路由**：待实现
|
||||
10. **密钥处理不规范**：待实现
|
||||
|
||||
#### P3 - 次要问题
|
||||
11. **Neo4j 镜像浮动 tag**：待修复
|
||||
12. **测试覆盖为空**：待补充
|
||||
|
||||
### 8. 建议的下一步
|
||||
|
||||
**立即行动**：
|
||||
1. 补充 P2 问题（关系功能、分页、Python 路由）
|
||||
2. 定义核心实体和关系模型
|
||||
3. 实现 MySQL → Neo4j 同步
|
||||
|
||||
**短期目标**（1-2周）：
|
||||
1. 完成 MVP 功能
|
||||
2. 补充单元测试
|
||||
3. 进行性能测试
|
||||
|
||||
**中期目标**（1-2月）：
|
||||
1. 集成到现有系统
|
||||
2. 实现 GraphRAG
|
||||
3. 上线第一个场景
|
||||
|
||||
## 与其他工具的对比
|
||||
|
||||
| 维度 | Codex | Gemini | Claude |
|
||||
|------|-------|--------|--------|
|
||||
| **技术选型** | Neo4j/JanusGraph | Neo4j | Neo4j |
|
||||
| **架构重点** | 3个新模块 | GraphRAG 融合 | 复用现有基础设施 |
|
||||
| **数据建模** | 10类实体+6类关系 | 灵活Schema+embedding | Schema先行+版本管理 |
|
||||
| **实现路径** | 4阶段（0-3） | 3阶段（MVP优先） | 4阶段 |
|
||||
| **独特优势** | 详细的领域模型 | LangChain+RAG融合 | 深度集成现有系统 |
|
||||
|
||||
## 关键洞察
|
||||
|
||||
1. **详细的领域模型**：Codex 提供了最详细的实体和关系定义
|
||||
2. **严格的代码审查**：发现了 12 个问题，确保代码质量
|
||||
3. **实用的最佳实践**：提供了具体的优化建议
|
||||
4. **分阶段实施**：强调先做 PoC，验证可行性
|
||||
|
||||
## 建议采纳度
|
||||
|
||||
**强烈推荐**：
|
||||
- ✅ 10 类实体 + 6 类关系的数据模型
|
||||
- ✅ 代码审查发现的问题修复
|
||||
- ✅ 最佳实践（查询优化、安全性）
|
||||
- ✅ 4 阶段实施路线
|
||||
|
||||
**可选**：
|
||||
- ⚠️ JanusGraph（如果需要分布式）
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [总体方案](../README.md)
|
||||
- [架构设计](../architecture.md)
|
||||
- [Gemini 分析结果](./gemini.md)
|
||||
- [Claude 分析结果](./claude.md)
|
||||
154
docs/knowledge-graph/analysis/gemini.md
Normal file
154
docs/knowledge-graph/analysis/gemini.md
Normal file
@@ -0,0 +1,154 @@
|
||||
# Gemini 知识图谱分析结果
|
||||
|
||||
## 分析时间
|
||||
2026-02-17
|
||||
|
||||
## 核心建议
|
||||
|
||||
### 1. GraphRAG 融合方案（独特贡献）
|
||||
|
||||
**创新点**：将知识图谱与现有 RAG 系统深度融合
|
||||
|
||||
**实现方案**：
|
||||
- 在 `rag-query-service` 中增加"混合检索"模式
|
||||
- 查询时同时检索 Milvus（向量）+ Neo4j（图结构）
|
||||
- 将 2-hop 子图的三元组文本化后作为 Context 喂给 LLM
|
||||
|
||||
**优势**：
|
||||
- 充分利用现有的 Milvus 向量检索能力
|
||||
- 结合向量相似度和图结构关系
|
||||
- 提供更丰富的上下文信息
|
||||
|
||||
### 2. LangChain 集成方案
|
||||
|
||||
**技术路径**：
|
||||
- 利用 LangChain 的 `LLMGraphTransformer` 实现自动抽取
|
||||
- 在 `runtime/datamate-python` 中实现
|
||||
- API: `POST /graph/extract`，输入文本，输出节点和边
|
||||
|
||||
**实现细节**：
|
||||
```python
|
||||
from langchain_experimental.graph_transformers import LLMGraphTransformer
|
||||
|
||||
transformer = LLMGraphTransformer(
|
||||
llm=llm,
|
||||
allowed_nodes=["Dataset", "Field", "Workflow"],
|
||||
allowed_relationships=["HAS_FIELD", "USES"]
|
||||
)
|
||||
|
||||
graph_documents = transformer.convert_to_graph_documents([document])
|
||||
```
|
||||
|
||||
### 3. 数据建模增强
|
||||
|
||||
**核心元模型**：
|
||||
- **Entity**：增加 `embedding` 字段（节点的向量表示）
|
||||
- **Document**：新增节点类型，用于溯源
|
||||
- **关系**：`(Entity)-[MENTIONED_IN]->(Document)`
|
||||
|
||||
**优势**：
|
||||
- 支持向量检索与图检索的混合
|
||||
- 方便溯源，追踪实体来源
|
||||
- 提升检索准确性
|
||||
|
||||
### 4. 实施路线图（3 阶段）
|
||||
|
||||
#### 第一阶段：基础设施与基础抽取 (MVP)
|
||||
1. 环境搭建：在 `deployment/docker/` 下新建 neo4j 目录
|
||||
2. Python 抽取器：利用 LangChain 的 LLMGraphTransformer
|
||||
3. 简单存储：直接存入 Neo4j
|
||||
|
||||
#### 第二阶段：图谱服务与 RAG 融合
|
||||
1. Java 服务：创建 `knowledge-graph-service`
|
||||
2. GraphRAG：在 `rag-query-service` 中增加"混合检索"模式
|
||||
- 查询时同时检索 Milvus 和 Neo4j（2-hop 子图）
|
||||
- 将三元组文本化后作为 Context 喂给 LLM
|
||||
|
||||
#### 第三阶段：可视化与高级功能
|
||||
1. 前端可视化：知识图谱浏览器
|
||||
2. 图谱编辑：Human-in-the-loop 修正
|
||||
|
||||
### 5. 潜在挑战与应对
|
||||
|
||||
#### 实体歧义
|
||||
**问题**：同名实体可能指代不同对象
|
||||
|
||||
**解决方案**：
|
||||
- 实体对齐步骤
|
||||
- 利用 LLM 或向量相似度合并
|
||||
- 人工审核机制
|
||||
|
||||
#### 信息过载（Super Nodes）
|
||||
**问题**：某些节点连接过多，查询性能下降
|
||||
|
||||
**解决方案**：
|
||||
- 限制跳数（最大 3 跳）
|
||||
- 限制最大边数（最大 1000 条）
|
||||
- 分页返回结果
|
||||
|
||||
#### 幻觉与错误抽取
|
||||
**问题**：LLM 可能产生不存在的实体或关系
|
||||
|
||||
**解决方案**：
|
||||
- 置信度评分
|
||||
- 人工审核
|
||||
- 对比多个模型的结果
|
||||
|
||||
### 6. 首要行动
|
||||
|
||||
**基础设施搭建**：
|
||||
1. 在 `deployment/docker/` 下创建 neo4j 目录
|
||||
2. 编写 docker-compose.yml
|
||||
3. 更新 Makefile 支持 Neo4j 的启动
|
||||
|
||||
**示例配置**：
|
||||
```yaml
|
||||
version: '3.8'
|
||||
services:
|
||||
neo4j:
|
||||
image: neo4j:latest
|
||||
ports:
|
||||
- "7474:7474"
|
||||
- "7687:7687"
|
||||
environment:
|
||||
- NEO4J_AUTH=neo4j/datamate123
|
||||
volumes:
|
||||
- neo4j_data:/data
|
||||
volumes:
|
||||
neo4j_data:
|
||||
```
|
||||
|
||||
## 与其他工具的对比
|
||||
|
||||
| 维度 | Gemini | Codex | Claude |
|
||||
|------|--------|-------|--------|
|
||||
| **技术选型** | Neo4j | Neo4j/JanusGraph | Neo4j |
|
||||
| **架构重点** | GraphRAG 融合 | 3个新模块 | 复用现有基础设施 |
|
||||
| **数据建模** | 灵活Schema+embedding | 10类实体+6类关系 | Schema先行+版本管理 |
|
||||
| **实现路径** | 3阶段（MVP优先） | 4阶段（0-3） | 4阶段 |
|
||||
| **独特优势** | LangChain+RAG融合 | 详细的领域模型 | 深度集成现有系统 |
|
||||
|
||||
## 关键洞察
|
||||
|
||||
1. **GraphRAG 是核心创新**：Gemini 提出的混合检索方案特别适合 DataMate 现有的 RAG 架构
|
||||
2. **LangChain 简化开发**：利用现成的 LLMGraphTransformer 可以快速实现抽取功能
|
||||
3. **向量 + 图结构**：embedding 字段的引入使得向量检索和图检索可以无缝结合
|
||||
4. **MVP 优先**：强调先做基础设施，再逐步扩展功能
|
||||
|
||||
## 建议采纳度
|
||||
|
||||
**强烈推荐**：
|
||||
- ✅ GraphRAG 融合方案
|
||||
- ✅ LangChain 集成
|
||||
- ✅ embedding 字段
|
||||
- ✅ Document 节点
|
||||
|
||||
**可选**：
|
||||
- ⚠️ 3 阶段实施路线（可与其他工具的 4 阶段结合）
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [总体方案](../README.md)
|
||||
- [架构设计](../architecture.md)
|
||||
- [Codex 分析结果](./codex.md)
|
||||
- [Claude 分析结果](./claude.md)
|
||||
Reference in New Issue
Block a user