1. 项目概述当文学经典遇上知识图谱与LLM去年在整理余华作品研究资料时我深刻体会到传统检索方式的局限——明明记得某个情节片段却找不到出处想对比不同作品中的人物关系需要反复翻阅纸质书。这促使我萌生了构建一个智能问答系统的想法而知识图谱与大型语言模型(LLM)的结合恰好提供了完美的技术解决方案。这个毕业设计项目实现了对《余华长篇小说全集》的深度语义理解与智能问答。系统以Neo4j图数据库构建知识图谱作为结构化知识底座通过LangChain框架集成LLM的推理能力最终用Flask搭建了轻量级Web应用。实测表明对于许三观卖血次数与时间间隔这类复杂查询系统能在秒级返回准确答案并可视化展示人物关系网络。2. 核心架构设计2.1 技术栈选型考量选择Flask而非Django主要基于三点考量首先毕业设计场景下需要快速迭代Flask的轻量级特性更合适其次系统主要提供API服务不需要Django的全套Admin功能最重要的是当需要扩展RAG(检索增强生成)功能时Flask与LangChain的集成更加灵活。LangChain框架的引入解决了三个关键问题一是统一了不同LLM(如GPT-3.5、ChatGLM)的调用接口二是提供了现成的文本分块、向量化工具三是其Agent机制支持了多跳查询——比如先查人物关系再结合时间线推理答案。2.2 知识图谱构建流程数据采集阶段采用了混合策略结构化数据从豆瓣读书API获取作品元数据(出版时间、ISBN等)半结构化数据维基百科人物关系表经OpenIE工具处理非结构化数据原著文本通过BiLSTM-CRF模型进行实体识别知识融合环节最易出错。我们发现不同来源对福贵的标注存在徐福贵富贵等变体最终采用基于编辑距离的实体对齐算法阈值设定为0.85时F1值最优。3. 关键实现细节3.1 图数据库建模实践Neo4j的schema设计经历了三次迭代// 初始版本 (:Book)-[:CONTAINS]-(:Character) (:Character)-[:FRIEND]-(:Character) // 优化后版本 (:Book {publish_year:int}) (:Character {gender:string, age_range:string}) (:Event {type:string, chapter:int}) (:Character)-[r:RELATION {type:string}]-(:Character) (:Character)-[:PARTICIPATE]-(:Event)特别增加了事件节点类型来捕捉卖血丧子等关键情节这对后续实现时序查询至关重要。比如查询许三观最后一次卖血时的年龄系统会先定位事件节点再通过关系追溯到人物属性。3.2 LangChain应用技巧在实现多文档问答时我们对比了三种分块策略固定512字符分块导致87%的情节被割裂按章节分块无法处理跨章节查询语义分块(使用BERT嵌入聚类)效果最佳但耗时较长最终采用混合方案先按章节粗分再对超过1024字符的章节用TextTiling算法细分。配合Cohere的embedding模型在RTX 3090上实现每秒处理5页文本的速度。4. 典型问题解决方案4.1 歧义消除挑战当用户询问家珍的丈夫时系统需要区分《活着》中的徐福贵和《许三观卖血记》中的许三观。我们的解决方案是构建对话上下文感知模块记录最近提到的作品对模糊查询自动触发澄清提问您指的是《活着》中的家珍吗在知识图谱中增加同名人物区分属性4.2 性能优化记录初期在普通云服务器上复杂查询响应时间达8-12秒。通过以下优化降至2秒内对高频查询路径建立预计算视图将Gremlin查询改为Cypher对LLM响应实现流式传输使用Redis缓存常见问题的向量索引5. 效果评估与改进方向在200个测试问题上系统表现如下问题类型准确率典型错误案例事实型查询92%混淆相似事件发生时间分析型问题78%对隐喻解读过于表面化跨作品对比85%忽略时代背景差异未来可扩展三个方向一是增加情感分析模块理解作品基调二是引入Diffbot自动更新知识图谱三是开发对比阅读功能如比较余华与莫言笔下的农民形象。关键教训一定要在构建知识图谱前明确定义边界。初期试图纳入所有余华作品导致图谱过于复杂后来限定为6部长篇后效果显著提升。建议按最小可行图谱原则启动项目。
1. 项目概述当文学经典遇上知识图谱与LLM去年在整理余华作品研究资料时我深刻体会到传统检索方式的局限——明明记得某个情节片段却找不到出处想对比不同作品中的人物关系需要反复翻阅纸质书。这促使我萌生了构建一个智能问答系统的想法而知识图谱与大型语言模型(LLM)的结合恰好提供了完美的技术解决方案。这个毕业设计项目实现了对《余华长篇小说全集》的深度语义理解与智能问答。系统以Neo4j图数据库构建知识图谱作为结构化知识底座通过LangChain框架集成LLM的推理能力最终用Flask搭建了轻量级Web应用。实测表明对于许三观卖血次数与时间间隔这类复杂查询系统能在秒级返回准确答案并可视化展示人物关系网络。2. 核心架构设计2.1 技术栈选型考量选择Flask而非Django主要基于三点考量首先毕业设计场景下需要快速迭代Flask的轻量级特性更合适其次系统主要提供API服务不需要Django的全套Admin功能最重要的是当需要扩展RAG(检索增强生成)功能时Flask与LangChain的集成更加灵活。LangChain框架的引入解决了三个关键问题一是统一了不同LLM(如GPT-3.5、ChatGLM)的调用接口二是提供了现成的文本分块、向量化工具三是其Agent机制支持了多跳查询——比如先查人物关系再结合时间线推理答案。2.2 知识图谱构建流程数据采集阶段采用了混合策略结构化数据从豆瓣读书API获取作品元数据(出版时间、ISBN等)半结构化数据维基百科人物关系表经OpenIE工具处理非结构化数据原著文本通过BiLSTM-CRF模型进行实体识别知识融合环节最易出错。我们发现不同来源对福贵的标注存在徐福贵富贵等变体最终采用基于编辑距离的实体对齐算法阈值设定为0.85时F1值最优。3. 关键实现细节3.1 图数据库建模实践Neo4j的schema设计经历了三次迭代// 初始版本 (:Book)-[:CONTAINS]-(:Character) (:Character)-[:FRIEND]-(:Character) // 优化后版本 (:Book {publish_year:int}) (:Character {gender:string, age_range:string}) (:Event {type:string, chapter:int}) (:Character)-[r:RELATION {type:string}]-(:Character) (:Character)-[:PARTICIPATE]-(:Event)特别增加了事件节点类型来捕捉卖血丧子等关键情节这对后续实现时序查询至关重要。比如查询许三观最后一次卖血时的年龄系统会先定位事件节点再通过关系追溯到人物属性。3.2 LangChain应用技巧在实现多文档问答时我们对比了三种分块策略固定512字符分块导致87%的情节被割裂按章节分块无法处理跨章节查询语义分块(使用BERT嵌入聚类)效果最佳但耗时较长最终采用混合方案先按章节粗分再对超过1024字符的章节用TextTiling算法细分。配合Cohere的embedding模型在RTX 3090上实现每秒处理5页文本的速度。4. 典型问题解决方案4.1 歧义消除挑战当用户询问家珍的丈夫时系统需要区分《活着》中的徐福贵和《许三观卖血记》中的许三观。我们的解决方案是构建对话上下文感知模块记录最近提到的作品对模糊查询自动触发澄清提问您指的是《活着》中的家珍吗在知识图谱中增加同名人物区分属性4.2 性能优化记录初期在普通云服务器上复杂查询响应时间达8-12秒。通过以下优化降至2秒内对高频查询路径建立预计算视图将Gremlin查询改为Cypher对LLM响应实现流式传输使用Redis缓存常见问题的向量索引5. 效果评估与改进方向在200个测试问题上系统表现如下问题类型准确率典型错误案例事实型查询92%混淆相似事件发生时间分析型问题78%对隐喻解读过于表面化跨作品对比85%忽略时代背景差异未来可扩展三个方向一是增加情感分析模块理解作品基调二是引入Diffbot自动更新知识图谱三是开发对比阅读功能如比较余华与莫言笔下的农民形象。关键教训一定要在构建知识图谱前明确定义边界。初期试图纳入所有余华作品导致图谱过于复杂后来限定为6部长篇后效果显著提升。建议按最小可行图谱原则启动项目。
