1. 项目概述1.1 核心需求解析这个题目我盯了很久知识图谱情感分析智能问答大模型写诗四个模块绑在一起横跨了知识图谱、NLP、数据可视化、深度学习四条技术栈。说实话这类题目在计算机毕业设计里属于“一看就懂、一写就懵”的典型。很多同学拿到题目第一反应是兴奋——中华古诗词、知识图谱、AI写诗听着就有档次。但真正动手后才发现每个模块独立拿出来都够写一篇论文凑在一起就是一个系统工程。我当时拿到这个方向后先做了一件事把题目拆成了三个核心问题。第一知识图谱怎么来、怎么存古诗词的数据散落在各种公开语料里需要清洗、结构化、抽实体关系最终灌进图数据库。这里牵扯到本体设计、实体对齐、关系抽取这些知识图谱的常见脏活累活。第二可视化怎么做知识图谱不能只给个数据表得有图谱展示、统计图表、查询界面这是这类题目拿高分的关键卖点也是工作量最直观的展示窗口。第三智能问答和写诗模块怎么体现“智能”这两个模块直接决定了答辩时评委问你“你的系统到底能做什么”的底气。更细节的工作量还有毕业论文初稿的排版与绘图、PPT的设计、以及答辩前能不能把整个流程讲顺。如果你准备选这个题目下面我从技术拆解到实操细节把整份方案讲透。1.2 技术栈与系统定位后端首选Spring Boot前端用Vue配上Element UI组件库或者直接上Vue3 ECharts图数据库选用Neo4j知识图谱构建部分采用Python爬虫 CSV py2neo导入情感分析模块采用BERT微调方案问答模块采用基于词典和规则的方案写诗模型采用中文GPT-2的预训练版本。这套组合的技术分工非常明确Python负责数据处理、模型训练和构建图谱数据Java负责对外提供Web服务Vue负责界面呈现和用户交互。前后端分离数据流向是MySQL存业务数据、Neo4j存图谱关系、模型文件存本地。系统定位上它属于“展示型功能型”混合毕业设计图谱可视化承担展示功能情感分析和自动写诗承担交互功能问答系统承担联动功能。懂了这层定位你就知道工作量该怎么分配视觉冲击力要足、功能要有真东西、技术上不能都是调包。2. 知识图谱建设与数据管线2.1 本体设计与实体关系建模知识图谱的第一层是“本体”也就是图的schema决定你的图里有哪些节点、哪些关系。古诗词领域我设计的本体包含四个核心实体朝代存储朝代的名称、起止年份、简介。诗人存储姓名、字号、生卒年、籍贯、代表作品数量。诗词存储题目、正文、译文、注释、赏析。词牌/曲牌存储词牌名、别名、格式说明、代表词人。关系层面核心关系有七条(朝代)-[:拥有诗人]-(诗人) (诗人)-[:创作]-(诗词) (朝代)-[:流行词牌]-(词牌) (诗人)-[:擅长]-(词牌) (诗词)-[:使用词牌]-(词牌) (诗词)-[:描写季节]-(季节) (诗词)-[:表达情感]-(情感)如果你想把图谱做厚还可以加“诗歌意象”实体比如“明月”“杨柳”“孤舟”建立(诗词)-[:包含意象]-(意象)这部分后面接可视化会很好看但必然增加爬取和标注工作量。我的建议是毕业设计阶段先保证四实体七关系扎实落地。2.2 数据采集与清洗实践这个体量的数据不可能纯用爬虫从零抓也没必要。我当时先找了一份公开的古诗词语料——大概几万首TXT格式的文本——再配合百科类站点做诗人信息和朝代信息的补充录入。这里有一个容易踩的坑网上流传的语料集格式五花八门有的按“作者-标题-正文”三段式有的直接是整本书的章节文本。乱爬的数据清洗能洗到怀疑人生。我的建议是数据管线分三步走规则初筛按“标题、作者、正文”切片用正则把脏字符、换行符、空格清干净。半自动校正这个环节别全用程序找一批规则处理不了的数据自己肉眼过一遍人工修正。结构化入库清洗后的数据整理成CSV分成诗词表、诗人表、朝代表、关系表四份文件后续读到Neo4j只用写个循环。实际操作中你会发现大量作品的朝代会因为“作者生卒年跨代”产生歧义比如某诗人经历了两个朝代该归哪个我最终按“主要活动时期”维度处理在诗人表里新增一个active_dynasty字段专门记录避免清洗时反复纠结。2.3 数据导入Neo4j的两种方式把CSV灌进Neo4j有两条路。第一种写PYTHON脚本用py2neo。优点是灵活可以在导入前顺便做关系去重和数据合法性校验。缺点是数据量大时批量提交要控制事务尺度比如每500条提交一次否则内存容易爆。核心代码大致长这样from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, password)) # 批量创建朝代节点 tx graph.begin() for i, row in dynasty_data.iterrows(): node Node(Dynasty, namerow[name], start_yearint(row[start_year]), end_yearint(row[end_year])) tx.merge(node, Dynasty, name) if i % 500 0: tx.commit() tx graph.begin() tx.commit()第二种直接用Neo4j自带的neo4j-admin import命令或者LOAD CSV批量导入。优点是速度极快缺点是CSV格式要求严格建立关系时需要先匹配节点调试成本高一些。对毕业设计来说我推荐第一种代码你能写进论文里当“系统实现”章节答辩的时候也更好解释。2.4 图谱质量校验图谱建好后强烈建议跑几条验证语句确认数据没废# 查看全部实体类型分布 MATCH (n) RETURN labels(n), count(*) LIMIT 20 # 检查诗人到诗词的映射关系 MATCH (p:Poet)-[:CREATED]-(c:Poem) RETURN p.name, count(c) ORDER BY count(c) DESC LIMIT 10 # 查找连接不到任何诗词的孤立诗人 MATCH (p:Poet) WHERE NOT (p)-[:CREATED]-(:Poem) RETURN p.name LIMIT 20跑完如果发现大量“孤立节点”多半是关系文件里诗人名和诗人节点名没对齐常见原因是繁体简体并存或者字号和姓名混用导致表里两个字段对不上。建议导入前做人名归一化统一表字段。3. 古诗词可视化的实现思路3.1 图谱可视化框架选型知识图谱可视化是这个项目最容易“出图”的部分。方案有三类ECharts关系图上手快简单地配置data和links就能出图适合展示局部关系比如某个诗人的社交圈、某个朝代的诗人网络。D3.js力导向图自由度高缩放、拖拽、颜色分级都能定制视觉效果精致但开发周期长。Neo4j自带Bloom给评委演示用可以但很难嵌到你的系统里。我最终采用的是D3.js力导向图嵌入Vue。D3做好节点和连线的渲染后封装成组件接收图谱JSON数据。至于为什么不用ECharts是因为ECharts面对大量节点时交互性能明显下降而力导向效果的微调空间也更小。D3绘制图谱时有两个经验节点的颜色编码建议按实体类型区分朝代用暖色调诗人用冷色调诗词用中性色这样图谱截图放在论文里一眼就能看出结构层次。布局算法的迭代次数先设300轮采样看效果再调整。中心节点选高频诗人比如苏轼、李白、杜甫让力导向图以他们为核心展开视觉中心不容易散。3.2 统计可视化补充除了图谱本身页面还应该有统计模块让整体内容丰富一层。我当时做了四个图表历朝历代作品数量分布折线图柱状图诗人作品Top20排行横向柱状图词牌使用频率词云词云图诗歌意象/情感分布雷达图雷达图这些图表的数据来源直接从Neo4j聚合查询出来写成接口返回JSON。做的时候注意一点统计口径要提前想好。比如“诗人作品Top20”有些诗人名下重复收录了同一首诗需要在Cypher查询里去重MATCH (p:Poet)-[:CREATED]-(c:Poem) RETURN p.name, count(DISTINCT c.title) AS cnt ORDER BY cnt DESC LIMIT 20count(DISTINCT ...)这个细节如果漏掉答辩时评委一追问你就会卡壳。3.3 前端交互设计页面交互上核心逻辑围绕“点击-聚焦-展开”设计。用户点击图谱中的某个诗人节点时右侧面板同步展示该诗人信息卡片生卒年、字号、代表作、名句同时触发局部动态重绘让该诗人的相邻节点和关系连线高亮其余节点变暗。这样做有两个好处一是直观呈现知识图谱“基于关系探索”的核心理念二是局部刷新性能压力小页面不会因为节点太多直接卡死。搜索框的设计也很关键。我建议支持三种模式按诗人搜、按作品搜、按名句搜。三种模式走三个接口但在前端统一收口。4. 古诗词情感分析的落地做法4.1 情感分类体系设计“古诗词情感分析”这个模块不少同学以为就是“正面/负面”二分。但古诗词的情感维度远比现代文本复杂“愁”和“思”比“负面”两个字精准得多。我的方案是五分类体系悲愁、喜悦、思乡怀人、闲适隐逸、豪迈愤懑。在前期标注阶段给每首诗分配一到两个主要情感标签以主要情感为准入模型。这里要提醒一句古诗词里有很多“以乐景写哀情”的复杂情况如果一首诗的多重情感纠缠太深标注时直接按主流赏析观点归类就行别追求绝对精确。4.2 基于BERT的情感分析模型数据集方面公开的古诗词情感标注数据很少我当时用已有人工标注的古诗词赏析语料加上自己清洗标注的样本凑了大几千条数据。类别结构大致是悲愁占比约三成思乡怀人约两成其余三类各占一成多样本不均衡比较明显。模型用“BERT-base-Chinese”微调预训练权重加载后在输出层加一个带Dropout的全连接分类头接五分类Softmax。训练参数直接给个能跑通的配置from transformers import BertForSequenceClassification, BertTokenizer tokenizer BertTokenizer.from_pretrained(bert-base-chinese) model BertForSequenceClassification.from_pretrained( bert-base-chinese, num_labels5 ) # 训练参数参考 batch_size 16 learning_rate 2e-5 epochs 5 max_length 128 optimizer AdamW(model.parameters(), lrlearning_rate)像我这种几千条小数据集跑在单张消费级显卡上一个epoch大概几分钟到十几分钟实验中取验证集F1最高的那个checkpoint用于部署。需要特别注意的是样本不均衡问题。五分类里悲愁类占比接近三分之一如果不做处理模型很容易学成“偷懒分类器”——看到诗句就倾向预测悲愁。我的做法有两点一是类别加权给样本少的类别更高的loss权重二是对小类别做了简单的过采样。这些细节在论文里都是可以大写特写的亮点。4.3 特征可视化与结果展示情感分析模块上线后页面上应该能对“单首诗词”和“全局分布”两种粒度进行展示。单首诗词的情感分析交互是用户在输入框粘贴/输入一首诗后端调用FastAPI部署的模型服务返回五个情感类别的概率分布前端用比例条或雷达图展现。全局分布则展示整个数据集的情感比例我延用了上一章的雷达图/饼图方案还加了一个“情感随时间演变”的分析视角——把不同朝代的情感倾向均值画成时序图用来展示“宋词偏婉约、唐诗偏豪迈”这类肉眼可见的统计学结论。这一步拓展了情感分析的深度答辩时非常加分。4.4 模型部署与服务化训练好的模型需要一个独立服务暴露给后端调用我当时选择用FastAPI做推理接口服务逻辑很简单接收文本分词编码forward返回概率分布。启动命令如下uvicorn sentiment_service:app --host 0.0.0.0 --port 8001Java后端通过HTTP调用这个服务。这里实话实说如果为了省事直接把推理逻辑写进Spring Boot改Python后端再把模型加载进来也完全可以不过FastAPI方案更整洁文档里解释“采用微服务思路”也更好写。5. 智能问答系统的实现逻辑5.1 知识问答与意图识别设计问答系统是这个项目里“交互感”最强的功能。古诗词领域的问答需求大致分两类事实型问答“李白写了多少首诗”“苏轼的代表作有哪些”“《静夜思》的作者是谁”。关联型问答“杜甫和李白是什么关系”“唐朝有哪些著名诗人”“带有‘月’字的诗有哪些”。第一类靠知识图谱查询就能答第二类需要简单的语义解析再加图谱匹配。我们当时采用了规则词典模板匹配的混合方案不用上复杂的意图分类模型。实现上先对用户输入做分词和高频词提取然后匹配一组问题模板例如模板“A写了哪些诗” → 识别A为诗人实体 → 查询(诗人: A)-[:CREATED]-(诗词)模板“A和B是什么关系” → 识别实体A和B → 查两者之间最短路径模板“包含XX词的诗有哪些” → 识别XX为关键词 → 全文模糊搜索5.2 实体链接与Cypher查询转换问答系统最核心的难点不在问答模板本身而在于实体链接——用户输入“李白”你到底能不能在图谱里定位到“李白”节点。我当时用的策略是“名称别名字典映射”对每位诗人建立一条实体映射记录包括姓名、字、号、别称。例如用户输入“李太白”“青莲居士”系统都能链接到李白节点。实体识别完成后将用户问题转换成一条Cyhper查询交给图谱执行拼装结果返回。举个例子用户输入“苏轼最著名的词是哪几首” 识别意图查询作品 识别实体苏轼映射为苏东坡 模板匹配结果MATCH (p:Poet {name: 苏轼})-[:CREATED]-(c:Poem) WHERE c.title CONTAINS 水调歌头 OR c.title CONTAINS 念奴娇 RETURN c.title, c.content LIMIT 5这里有个很现实的细节你这个模板库要想覆盖用户五花八门的问法几页模板基本不够后面越写越多。做的时候注意模板的优先级排序同一个用户问题可能同时命中多个模板时要有明确的优先规则否则答非所问。5.3 问答系统的边界与兜底方案实话说纯模板匹配的问答系统遇到没见过的问法就是一堆bug。一定要设计兜底回复逻辑我当时设计了三层兜底第一层尝试通过子串匹配找到高相似度历史问题基于已有问答对的相似度检索。第二层用图谱模糊查询比如用户输入含某个诗人的名字但问题模板没匹配上就返回该诗人的代表作列表。第三层直接返回预设的引导话术提示用户换一种问法。答辩阶段评委大概率会对问答系统抽查问几个比较刁钻的问题。这块实现扎实你就能有底气说“我们采用规则与图谱查询相结合覆盖了高频问题对低频问题有兜底策略”。6. AI大模型写诗模块的实践经验6.1 模型选型与预训练权重自动写诗是这套系统里“大模型”味道最浓、但实现门槛相对可控的模块。常规做法是拿一个中文GPT-2模型来微调而不是从头训练。我当时用了一个开源的中文古代诗歌GPT-2预训练模型做底座然后在收集好的全唐诗数据集上继续微调。这里有个关键认知所谓“大模型”其实是一个特定领域的Rewind参数量一般在几亿规模单张显卡可以拿下。用到的库主要是transformers和pytorch。生成阶段参考的配置如下from transformers import GPT2LMHeadModel, GPT2Tokenizer model_name uer/gpt2-chinese-poem tokenizer GPT2Tokenizer.from_pretrained(model_name) model GPT2LMHeadModel.from_pretrained(model_name) # 设定生成参数 sample_output model.generate( input_idsmodel_input[input_ids], max_length64, do_sampleTrue, top_p0.95, temperature0.85, repetition_penalty1.2, num_return_sequences3, )6.2 输入输出与Prompt设计这个模型的输入是前几句诗词或者用户给定主题输出是后续续写。操作逻辑一般是用户在界面输入开头一两句或者选择“以‘秋’为题”后端生成后返回给前端展示。要让生成的诗词看起来有点样子Prompt设计很关键。限定主题式“秋日山行风景如画。” 生成五言/七言诗。续写式用户输入上联系统生成下联或后续几句。模仿风格式“仿李白风格描写月亮。”其中“模仿风格式”需要提示词带上风格关键词微调后模型会表现出一定的风格倾向但不稳定。如果论文里需要展示效果建议多跑几次预先生成几个不错的样例存进结果表里演示时优先展示优质结果。6.3 质量评估与结果审查自动写诗模块最大的隐患是模型生成结果质量不稳定经常出现重字或者平仄不对更离谱的会整句不押韵。我的做法是加结果清洗模块生成后先做规则校验比如句长、重复字查重、韵脚匹配。这里必须提醒如果你没有读好平水韵或者词林正韵别强行按韵书校验容易把生成结果全毙掉。退而求其次检查“句末字是否在同一韵部集合”即可按常见韵部做个宽松检查或者干脆只做重字检查和句长统一。展示端可以做一个“生成多句候选”样式一次给用户返回3句让用户自己挑选这样既掩盖了模型的随机性又提升了交互感。我实操中觉得这是一个性价比极高的设计肉眼可见地提高了演示流畅度。7. 常见问题与避坑指南7.1 年代格式不统一导致查询失效由于语料来源不同年代字段一会儿是“唐朝”一会儿是“唐代”还有“南唐”“初唐”各种叫法如果用原文做朝代节点导入图谱里会出现一堆名称不同但实际指向同一朝代的结构。解决办法是建一个朝代别名映射表导入前做统一文本替换。7.2 Neo4j大关系集会卡死渲染前端图谱加载几千个节点和上万条关系直接崩溃。我的做法是前端只加载必要视图默认展示全部朝代节点Top50诗人每个诗人的少量代表作控制节点总数在800个以内。用户点击诗人节点后才动态拉取和该节点相关的局部关系。7.3 情感分析模型在古白话上效果差BERT是拿现代汉语预训练的用在古诗词上效果会有折扣。微调时建议加入古诗词特有的专有词汇和意象词必要时冻结前几层参数防止灾难性遗忘。另外输入诗词原文时去掉题注赏析等噪声字段情感预测更稳定。7.4 写诗模型重复生成同一句GPT-2小模型非常容易出现循环重复问题主要原因是重复惩罚设置不当。我的经验值是repetition_penalty设在1.1到1.3之间太低没用太高生成内容会破碎。同时可以把no_repeat_ngram_size设为3禁止同一三连词重复出现。7.5 画布上节点拖不动D3力导向图在数据更新时经常出现节点坐标重置的问题拖拽后位置复原。关键是在更新数据时调用node.force(charge)调整物理参数并且设置dragSubject为当前组件的筛选数组。8. 论文与答辩准备的几个要点论文写作上开头一定要把“为什么做中华古诗词知识图谱”这一个点讲透。题目既然给了这么多模块就不能只是“我做了个网站”。建议论文里的工作量划分这样写第一章绪论交代背景和现状第二章相关技术BERT、知识图谱、GPT-2第三章需求分析与总体设计第四章系统详细设计与实现第五章系统测试与展示第六章总结与展望。答辩的时候有一条经验值得分享不要把大模型写诗模块包装成“通用大模型”措辞严谨点说清楚是“面向古诗词领域的生成式语言模型微调”否则评委问“你这模型有几亿参数”你还能圆一旦问“那你处理多轮对话吗”就会露怯了。实物演示环节建议准备两条演示路径主路径检索台选择朝代→点击诗人→展示作品列表→点击单首作品→情感分析比例条展示→复制诗句→进入写诗模块→生成续写→展示结果。一条流水线贯穿四个模块。备路径知识图谱全局效果搜索问答展示一个多轮问答对话记录。主路径一定要反复自己走一遍尽量把每个环节的点击延迟控制在2秒以内预先把演示数据和生成示例准备好。答辩现场临时生成写诗结果一旦模型抽风生成出一堆乱码后续节奏就全乱了。9. 项目复盘与个人心得这个题目我从拿到手到完整落地前后大约用了一个半月。现在回头复盘“知识图谱情感分析问答写诗”这四个模块看起来多实际上它们各自的技术路线都不算冷门真正的难点是模块之间怎么串起来、数据怎么流、系统怎么控制复杂度。我的心得有几个第一凡事先定数据格式。图谱数据结构、模型推理返回格式、前端展示数据结构五张表定清楚后面接缝处不会再翻工。所有模块对接都围绕JSON来聊天模块独立性就强。第二多写工具脚本少动手改数据。比如清洗语料、生成实体映射、校验图谱孤点这些活儿看着不显眼但都是体力劳动能写脚本绝不用手工。第三功能完整度优先于炫技。很多同学喜欢在某个模块上钻牛角尖比如把问答意图识别搞成深度学习模型分类最后准确率还不高。像这种小规模数据量场景规则匹配往往比模型更稳效果也更可控。第四答辩时你真正的护城河不是模型在榜单上刷到多高而是你把系统的每个环节都跑通了、能解释清楚每个设计决策的原因。最后如果你也打算做这个方向给一条最实在的建议拿到题目先别急着动手查资料先把系统架构图画清楚把每个模块的数据接口定义出来再开始写代码。这个项目不难在某个技术点而难在工程协调把结构想透了剩下的就是按部就班填代码了。