You've already forked DataMate
Jerry Yan
afcb8783aa
核心功能： - 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
202 lines
4.9 KiB
Markdown
202 lines
4.9 KiB
Markdown
# 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)
|