1. 项目概述
这个养老志愿服务系统是一个融合知识图谱和人工智能技术的创新平台,旨在为老年人提供精准的志愿服务匹配。系统采用"后端微内核+多端前端"的架构设计,通过构建养老领域的知识图谱,结合图数据库和智能推荐算法,实现了从传统标签匹配到语义推理的升级。
作为开发者,我在重构过程中面临七大核心挑战,包括知识图谱本体设计、多源异构数据融合、GraphRAG算法重构等。系统最终实现了从"推荐系统"到"养老志愿认知服务平台"的转变,具备更强的语义理解能力和推荐解释性。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构解析
2.1 整体架构设计
系统采用分层架构设计,分为五个主要层次:
- 基础设施层:混合存储架构(MySQL+Neo4j+Redis+MinIO)
- 数据中台层:本体管理中心和多源融合引擎
- 智能服务层:GraphRAG引擎和可解释性模块
- 业务应用层:管理端、老人端和志愿者端
- 网关与安全层:统一鉴权和访问控制
这种架构设计确保了系统的高扩展性和灵活性,各层之间通过明确定义的接口进行通信。
2.2 后端微内核架构
后端采用Snowy框架的插件化微内核架构:
- snowy-web-app:轻量级主启动模块
- snowy-common:基础通用层
- snowy-plugin-*:业务插件层
核心业务逻辑集中在snowy-plugin-biz模块中,包含活动管理、老人档案、志愿者管理等子模块。这种设计使得各功能模块可以独立开发和部署。
3. 核心模块实现
3.1 知识图谱本体管理中心
原系统的dict模块被改造为知识图谱本体管理中心,主要实现了:
- 实体类型定义:扩展BizDictEnum为OntologyClass,定义了老人、志愿者、活动等本体类
- 关系类型定义:新增RelationTypeEnum,定义了20+种关系类型
- 约束规则引擎:新增ConstraintRuleService,将业务规则转化为SWRL规则
技术突破点在于从扁平枚举到层级本体的转变,支持推理机自动推导隐含关系。例如,系统可以自动推断"医护服务"是"医疗服务"的子类。
3.2 实体层改造
原系统的实体层(BizOld, BizVolunteer等)进行了重大改造:
- 实体链接能力:新增kgId字段作为知识图谱全局唯一ID
- 多版本管理:新增EntityVersion嵌套类记录多数据源信息
- 动态属性容器:将固定字段改造为Map<String, Object>
这种改造使得实体能够更好地表达多态性,例如志愿者可以同时具有"服务者"和"社区邻居"两种角色。
3.3 GraphRAG引擎实现
原系统的推荐算法从简单的相似度计算升级为GraphRAG引擎:
-
检索器-生成器分离:
- GraphRetrieverService:负责从Neo4j检索候选子图
- LlmReasoningService:负责生成推荐理由
- RerankService:负责基于约束条件重排序
-
混合检索策略:
- 向量检索:使用Neo4j Vector Index
- 图遍历检索:使用Cypher进行多跳查询
- 标签过滤检索:保留硬约束快速剪枝
-
LLM Prompt工程:将知识图谱子图序列化为自然语言
这种架构使得推荐质量从简单的"匹配"升级到"推理",显著提升了推荐的准确性和可解释性。
4. 关键技术实现细节
4.1 多源数据融合
系统需要处理来自政务平台、社区登记和网络爬虫的异构数据。我们实现了:
- 实体对齐:基于kgId实现跨数据源的实体匹配
- 冲突解决:采用投票机制解决属性值冲突
- 质量评估:基于信息完整性和时效性进行数据质量评分
具体实现中,我们在BizOld实体中增加了dataSourceType字段标识数据来源,并通过EntityVersion记录不同版本的属性值。
4.2 实时事件处理
原系统的用户行为处理是日级批处理,改造后实现了秒级实时反馈:
- 事件驱动架构:使用Kafka消息队列处理用户行为事件
- 流式计算引擎:Flink实时计算兴趣权重和标签热度
- 增量图谱更新:通过Neo4jIncrementalUpdater实时更新图谱
例如,老人浏览医疗活动后,系统会立即执行Cypher查询增强该老人与医疗标签的连接权重。
4.3 可解释性引擎
新增explainability模块实现了推荐结果的可解释性:
-
溯源服务层:
- traceRetrievalPath:返回检索路径
- generateExplanation:生成自然语言解释
-
证据链存储:在BizActivityRec中新增evidenceChain字段,存储JSON格式的推理过程
-
前端解释组件:展示图谱路径可视化和文字解释
这种设计满足了老年人对AI系统的信任需求,也符合算法透明性的监管要求。
5. 系统部署与配置
5.1 开发环境配置
系统开发环境配置如下:
- 后端环境:JDK1.8、Maven3.6.3、SpringBoot
- 前端环境:Node.js、Vue.js
- 数据库环境:MySQL8.3、Neo4j4.2.9
- AI环境:大语言模型相关依赖库
各服务端口配置:
- 后端服务:http://127.0.0.1:82
- 管理前端:http://localhost:81/
- 老人端:http://192.168.1.101:5173/
- 志愿者端:http://192.168.1.101:5174/
5.2 数据库设计
系统使用混合存储策略:
-
MySQL表结构:
- BIZ_ACTIVITY:活动信息表
- BIZ_OLD:老人信息表
- BIZ_VOLUNTEER:志愿者信息表
- BIZ_ACTIVITY_REC:推荐记录表
-
Neo4j图模型:
- 节点类型:老人、志愿者、活动、技能等
- 关系类型:需要服务、具备技能、可服务等
关键设计是在MySQL表中增加KG_ID字段,实现与Neo4j节点的映射。
6. 开发经验与挑战
6.1 技术难点突破
-
知识图谱本体设计:
- 需要深入理解养老领域的实体和关系
- 解决方案:与领域专家合作构建本体模型
-
性能优化:
- 图查询可能面临性能瓶颈
- 解决方案:使用Neo4j索引和查询优化
-
LLM集成:
- 生成式推荐存在不可控风险
- 解决方案:设计严格的Prompt模板和结果过滤
6.2 开发实践建议
- 增量开发:从简单场景开始,逐步增加复杂度
- 测试策略:重视图谱查询的单元测试
- 监控设计:建立推荐效果评估指标体系
7. 系统效果与展望
系统实现了以下创新价值:
- 知识表示:从标签向量升级为亿级三元组
- 推荐逻辑:从相似度计算到图推理+LLM生成
- 交互方式:从点击按钮到自然语言对话
- 可信度:从黑盒输出到白盒可追溯
未来可考虑的方向包括:
- 引入更多实时数据源
- 优化LLM的Prompt工程
- 扩展更多养老服务场景
