古诗词知识图谱+情感分析+智能问答毕设全攻略-北京尧图网络

每年到毕业设计开题那段时间总有人抱着知识图谱情感分析智能问答大模型写诗这几个词来找我觉得随便拎一个出来都够写一篇论文最后拼成一个大而全的题目之后又不知道怎么落地。我见过不少类似的项目源码拿回来能跑通但一问到实体抽取怎么做图谱为什么这么设计问答意图怎么匹配就哑火答辩自然很难看。这篇就把这套中华古诗词知识图谱可视化情感分析智能问答 AI自动写诗的毕设项目从题目拆解到技术选型、再到每个模块的实操细节和踩坑记录完整过一遍。适合打算用这个方向做毕设、但又担心做不完答不上来演示翻车的同学。我会尽量把每一步的选择理由和背后的原理讲清楚遇到可以直接复用的代码和 Cypher 语句也会贴出来。1. 题目拆解与技术选型这个毕设到底考什么1.1 一个题目背后的五座大山先把这个标题拆开看它其实不是一个项目而是四个功能模块加一个展现层知识图谱构建与可视化把古诗词里的诗人、作品、朝代、地名、意象、词牌等实体抽出来建立关系网络再用图数据库存储和前端图表展示。古诗词情感分析输入一首诗模型判断它是豪放、婉约、旷达还是愁绪满怀。古诗词智能问答用自然语言提问比如李白写过哪些关于月的诗系统返回答案。AI大模型自动写诗给主题或首句系统自动生成五言、七言甚至藏头诗。可视化大屏把统计图表、关系图、词云整合到一个 Web 页面里作为演示主界面。毕设打分通常看三样工作量、技术难度、创新点。这个题目刚好三样都占数据量够大、技术栈够全、每块都有独立算法模型。但也正因为模块多最容易出问题的地方不是不会做而是不知道做到什么程度算完。所以第一步不是写代码而是先定边界。1.2 技术栈选型不是越新越好是能完成就好很多同学一上来就想上最新框架结果光配环境就花了两周。这里我给一套经过验证的、兼顾开发效率和答辩深度的技术组合模块技术选型为什么选它后端框架Flask轻量、生态成熟、和深度学习模型对接方便不用像 Spring 那样折腾一堆配置前端Vue 3 ECharts Element PlusECharts 的 graph 类型做关系图非常顺手词云、折线图、柱状图都有现成组件图数据库Neo4j关系查询用 Cypher 一句话搞定自带可视化答辩时还能直接在浏览器里展示图谱关系型数据库MySQL存诗词原文、用户信息、问答日志这些结构化数据情感分析BERT-base-Chinese 微调中文语义理解好古诗词这种短文本用 BERT 比用 TF-IDF 加机器学习靠谱得多命名实体识别HanLP 词典正则人工校对毕设阶段不需要自己训练 NER 模型用词典匹配覆盖高频实体剩下的交给规则自动写诗大模型 API 格律检查自己从零训练生成模型不现实调通用大模型 API 配合诗歌 prompt 是当前最稳的方案数据获取Python 爬虫公开数据集古诗文类公开资源很多重点在清洗不在爬取这套选型的核心逻辑是每个环节都用够用且能讲清楚的方案把节省下来的时间花在调优和写文档上。比如 NER 部分如果你的开题里写了基于 BERT-BiLSTM-CRF 的命名实体识别那确实得训练一个模型但如果只是毕设题目里带了一句知识图谱用词典加正则完全说得过去关键是让评委看到你理解了实体抽取的难点在哪。1.3 模块协作与数据流结构整个系统的数据流大概是这样的爬虫脚本从古诗文类网站抓取原始文本清洗后存进 MySQL实体和关系抽取程序从 MySQL 里读取诗词数据产出三元组写入 Neo4j情感分析模型接收前端上传的诗词文本返回情感类别问答模块解析用户自然语言转换成 Cypher 查询从 Neo4j 取答案写诗模块把主题词拼进 prompt调用大模型 API 后经过格律校验返回前端。四个模块看起来独立实际上共用同一套数据底座和用户请求入口这也是毕设答辩时最值得讲的一点数据层、算法层、应用层是解耦的。2. 知识图谱构建从原料到三元组的全过程2.1 数据来源与清洗思路古诗词数据有两个来源一是直接从公开数据集下载整理好的 JSON二是自己写爬虫去古诗文类网站抓。我更推荐拿公开数据集打底再用爬虫补充。原因很简单公开数据集通常已经按朝代-作者-篇名-正文-注释结构化好了省去大量清洗工作。拿到数据后第一件事是去重和字段规整。诗词数据最常见的脏数据包括同一首诗在不同数据集里标点不同作者名有别名李白和李太白都在库里体裁字段混乱五绝五言绝句七律混用。处理建议是写一个清洗管道pipeline每一步做一件事按标题作者正文前 20 字计算 MD5去重。统一作者名建一个别名字典比如把李太白青莲居士映射到标准名李白。规范化体裁字段映射成五绝/七绝/五律/七律/词/曲/乐府/其他八类。剔除乱码和疑似非诗词文本。清洗完的数据存 MySQL大概几万首诗的规模就足够撑起整个项目的可视化和问答了不需要贪多。量太大反而会让 Neo4j 的渲染变慢演示时关系图卡成 PPT那体验就糟了。2.2 实体与关系设计古诗词领域的本体建模知识图谱的灵魂不是有多少数据而是实体和关系设计得合不合理。古诗词领域的核心实体我建议至少包含这六类Poet诗人属性有 name、dynasty、style如豪放、婉约、birth_death 等。Work作品属性有 title、content、type体裁、rhyme韵部等。Dynasty朝代属性有 name、start_year、end_year。Place地名如长安洛阳江南。Image意象如明月孤舟杨柳酒。Cipai词牌名如水调歌头念奴娇。关系设计上不需要太复杂守住用户能问出什么问题就设计什么关系这条原则(Poet)-[:CREATED]-(Work)谁写的(Poet)-[:LIVED_IN]-(Dynasty)诗人所属朝代(Work)-[:BELONGS_TO]-(Dynasty)作品朝代(Work)-[:USES]-(Image)作品用了什么意象(Work)-[:MENTIONS]-(Place)作品提到哪里(Work)-[:USES_CIPAI]-(Cipai)词作品用了什么词牌这里有个细节同一个作品通常会出现多个意象创建一个意象实体节点而不是把明月夜这种文本直接当关系属性这样后面做找所有写过明月的诗和李白一样爱写月的诗人这类问答时图遍历效率会高很多。实体抽取我采用的是 HanLP 自定义词典加正则。比如把明月、孤鸿、寒鸦、长亭放进自定义词典再把地点词典准备好分词后做匹配。对于诗人、朝代、词牌这些实体直接在前端知识库其实就是 MySQL 里的维度表里维护不需要 NLP 模型来抽。全集大概几百个高频意象就够用了不必追求把所有词都抽干净。2.3 Neo4j 数据导入与查询性能数据入 Neo4j 有两个阶段初始化导入用 Cypher 的 LOAD CSV增量插入用 Python 驱动。如果数据量在几万到十几万节点内LOAD CSV 是最省事的方式。先把清洗后的数据导出成三个 CSVpoets.csv、works.csv、images.csv再写导入脚本。份量比较关键的是 work 与 image 的关系因为一首诗对应多个意象需要先建一个 work_image_rel.csvwork_title,work_author,image_name 将进酒,李白,酒将进酒,李白,黄河将进酒,李白,明月静夜思,李白,明月然后执行导入LOAD CSV WITH HEADERS FROM file:///works.csv AS row CREATE (w:Work {title: row.title, content: row.content, type: row.type})LOAD CSV WITH HEADERS FROM file:///work_image_rel.csv AS row MATCH (w:Work {title: row.work_title, author: row.work_author}) MERGE (i:Image {name: row.image_name}) MERGE (w)-[:USES]-(i)注意Work 节点如果只有 title 字段同名作品会撞车所以先把标题作者作为唯一标识去重或者加上 constraintCREATE CONSTRAINT work_unique IF NOT EXISTS FOR (w:Work) REQUIRE (w.title, w.author) IS UNIQUE;查询环节我最常用的几个 Cypher 模板可以提前准备好// 某位诗人写了哪些作品 MATCH (p:Poet {name: 李白})-[:CREATED]-(w:Work) RETURN w.title, w.type LIMIT 50; // 哪些作品使用了明月意象 MATCH (w:Work)-[:USES]-(i:Image {name: 明月}) RETURN w.title, w.author LIMIT 100; // 某位诗人最常使用的 10 个意象 MATCH (p:Poet {name: 苏轼})-[:CREATED]-(w:Work)-[:USES]-(i:Image) RETURN i.name, COUNT(*) AS cnt ORDER BY cnt DESC LIMIT 10;用这些模板做问答系统的基础查询层效果非常稳。需要提醒的是不要把整首诗的文本放到图数据库的节点属性里去做全文检索Neo4j 擅长的是关系遍历全文搜索交给 MySQL 的 LIKE 或者 Elasticsearch 更合理。实操里我把正文内容存在 MySQLNeo4j 节点上只保留标题和作者通过 work_id 关联回去。2.4 前端可视化关系图、词云与统计面板可视化是毕设演示的门面评委第一眼看的就是这个页面。建议做一个三栏布局的主页左侧是统计概览用 ECharts 展示各朝代诗词数量分布南丁格尔玫瑰图和诗人作品数量 Top10横向柱状图。中间是核心的诗人-作品-意象关系图用 ECharts 的 graph 类型const option { tooltip: {}, series: [{ type: graph, layout: force, roam: true, label: { show: true }, force: { repulsion: 300, edgeLength: 80 }, data: nodes, // [{id, name, category, symbolSize}] links: edges // [{source, target}] }] };右侧是词云和情感分布。关系图这里有个性能坑如果一次把几万个节点全渲染浏览器必卡。解决方法是按选中诗人-他的作品-这些作品的高频意象这三个层次动态加载默认只展示一两位代表性诗人用户可以点击节点展开更多。这样既保证了演示流畅又能让用户感受到这是一个可以无限探索的大图。节点大小用 degree 控制关系越多的诗人节点越大视觉上很有冲击力答辩时可以直接指着最大那个节点说这是苏轼和他关联的作品和意象数量最多。3. 古诗词情感分析当 NLP 遇到诗词3.1 情感体系怎么设计二分类还是多分类古诗词情感分析和普通文本情感分析最大的区别是不能只分积极/消极。举头望明月低头思故乡你说它是消极还是积极都对都不对。所以我在这个项目里用的是更符合诗词审美的五分类体系豪放洒脱如大江东去浪淘尽千古风流人物婉约柔情如衣带渐宽终不悔为伊消得人憔悴旷达乐观如莫听穿林打叶声何妨吟啸且徐行愁绪忧思如寻寻觅觅冷冷清清凄凄惨惨戚戚闲适恬淡如采菊东篱下悠然见南山这个设计有两个好处一是答辩时可以直接用名家名句做例子评委一听就懂二是五分类比二分类更能体现你对任务的理解深度如果还能解释为什么把豪放和旷达分开那就更有说服力了。实际标注时你会发现这两个类别边界确实模糊比如人生得意须尽欢既豪放又旷达最后我给出的处理方式是按创作背景和整体基调取主导情感模型输出概率最高的前两类都展示给用户让用户可以自己判断。3.2 数据集与标注策略古诗词情感分析最大的难题是缺标注数据。公开的中文情感分析数据集基本都是现代句子直接拿来训练再预测古诗词效果会很差。我自己是这么解决的第一步找了几百首公认的代表作人工标注情感类别。不需要太多2000 首左右就能出一个能看的效果因为古诗词本身语言高度凝练模式比较集中。第二步利用 BERT 模型做半监督扩充。先用手工标注的 2000 条训练一个初版模型拿去预测整个数据集把置信度高于 0.9 的样本挑出来作为伪标注加入训练集再把模型重新训练一遍。这样能把有效训练数据扩到 8000 条以上。第三步对模型明显分错的少数样本做微调比如春风得意马蹄疾被分成闲适而不是豪放加入训练集后重新训。这里我踩过的坑是直接使用网站自带的诗词分类标签比如把诗仙诗圣对应的风格当成情感标签效果并不好。因为诗圣是后人评价不代表每首诗的情绪。教育类网站上的注释里偶尔会有一句此诗表达了作者的思乡之情可以用正则把这句抽出来作为弱标注但准确率不高只能当辅助信号。3.3 模型方案对比词典法、机器学习、BERT 哪个适合毕设这个模块一定要在文档里写清楚你对比过哪些方案为什么选了 BERT这是答辩的高频问题。先看词典法把愁、恨、悲、喜、狂这些情感词做成字典统计命中次数。优点是零训练成本、可解释性强。缺点也很明显——古诗词大量使用意象表达情感梧桐更兼细雨里面没有一个明确的情绪词但读者都能感受到低沉。词典法对这类文本基本失灵。再看传统机器学习把 TF-IDF 或 Word2Vec 特征喂给 SVM、朴素贝叶斯。效果比词典法好一点点但对情感在词之间组合关系里的表达还是很弱。最后是 BERT 微调直接取 CLS 位置的输出接一个全连接分类层做 5 分类。我用的参数是bert-base-chinese最大长度 128学习率 2e-5batch size 16训练 5 个 epoch早停 patience2。在验证集上准确率大概 82% 左右可能不如现代文本那么高但这已经在古诗词情感这个任务上够用了——毕竟人工标注之间的一致性本身也只有八成多。训练代码的结构很简单from transformers import BertForSequenceClassification, BertTokenizer model BertForSequenceClassification.from_pretrained( hfl/chinese-roberta-wwm-ext, num_labels5) tokenizer BertTokenizer.from_pretrained(hfl/chinese-roberta-wwm-ext)注意直接用 bert-base-chinese 也完全可以但我试下来 hfl 的中文 RoBERTa 在古诗上略好一点可能是因为它的词表对中文适配更细。如果在设备上加载不了就换回 bert-base-chinese顶多掉两三个点不影响整体效果。3.4 情感分析服务的工程化封装模型训练好只是第一步要接到 Web 端还需要封装成推理服务。我在 Flask 后端里单独开了一个接口 /api/sentiment请求时带着诗词文本进来返回情感类别和五个类别的概率分布。一个实际经验模型第一次加载非常慢CPU 上可能要 10 秒如果每次请求都重新加载模型体验会很差。解决办法是在 Flask 进程启动时就加载模型放到全局变量里请求只做 forward。如果并发量不大这个方案足够。想要更稳一点可以用简单缓存同一首诗短时间内重复查询就返回之前的结果不用重复推理。这个模块答辩时最容易加分的点是可解释性——除了返回类别还返回模型关注了哪些词。做法是把 transformer 最后一层的注意力权重取出来取每个 token 的平均 attention颜色越深的词表示模型判断情感时越依赖它。前端用 span 颜色渐变展示出来效果非常惊艳而且实现只需要几十行代码。4. 智能问答与自动写诗两个门面功能的实战实现4.1 问答系统从自然语言到 Cypher 的转换问答模块看起来高级实际上可以做得很务实。我的实现分三步意图识别、槽位提取、查询生成。意图识别用规则加正则就能覆盖 90% 的场景无需训练模型。预设这几类意图查询诗人作品李白写过哪些诗杜甫的边塞诗有哪些查询作品详情将进酒的内容是什么静夜思是什么体裁查询诗人信息苏轼是哪个朝代的李白字号是什么查询意象相关写过明月的诗人有哪些哪些诗用了杨柳意象查询朝代相关初唐四杰有哪些代表作品槽位提取就是通过实体词典把李白将进酒明月这些词从问句里切出来。我之前维护了一份实体别名表比如诗仙李太白都映射到标准实体李白这对提升问答命中率很有帮助。然后每种意图对应一段 Cypher 模板用提取到的主实体把问句模板和查询模板拼起来。比如问李白写过哪些诗解析结果是意图singer_works实体李白。对应查询MATCH (p:Poet {name: 李白})-[:CREATED]-(w:Work) RETURN w.title, w.type LIMIT 50;回答生成的时候不要把一堆诗名直接甩给用户而是拼成李白一生创作了大量诗歌按体裁统计五言绝句 82 首、七言绝句 60 首……其中最著名的有《静夜思》《望庐山瀑布》……这种带统计信息的句子比干巴巴列作品名更体现系统的智能感。这里有一个真实的教训问答效果差的根子往往不在 NLU而在图里压根没有那层关系。比如用户问李白和杜甫合作过哪些诗你的知识图谱里没有诗人-合作-诗人这类关系那再牛的 NLP 也回答不了。所以设计知识图谱本体的时候就要反推问答需求先列出 50 个预期问题再看图结构能不能支撑支撑不了就补关系或换问题。4.2 自动写诗从规则模板到大模型调用的路径写诗模块是三个模块里最容易被卷出新意的也是最容易翻车的地方。先说结论纯规则拼接把意象词、动词、押韵词随机组合生成的诗只能算打油诗生成器拿去答辩大概率被评委问蒙自己微调一个生成模型又需要大量数据和高性能显卡毕设周期扛不住。最均衡的方案是调用通用大模型 API 诗歌领域 Prompt 约束格律后处理。把写诗接口设计成两类自由写诗用户输入主题词比如梅花秋夜思乡系统生成一首七言律诗。藏头诗用户输入五个或七个字系统把这几个字分别作为每句诗的开头生成一首符合格律的诗。藏头诗在前端展示时可以把每句开头的字高亮视觉效果很抓人。Prompt 设计上我做了两版建议用下面这种结构化写法你是一位精通古典诗词创作的诗人。请以秋夜为主题写一首七言律诗。要求 1. 符合七律的格式八句四联每句七字。 2. 押平水韵中间两联需要工整对仗。 3. 使用古典诗词常见意象不要出现现代词汇。 4. 整体情感基调为清冷孤寂。只输出诗歌正文不要输出解释。调用大模型后返回的文本往往需要后处理检查每句是不是七个字、总句数是不是八句、有没有出现明显重复的字或词。如果有问题就重新生成一遍最多重试三次。这种生成-校验-重试的循环是实现里最值得写进文档的细节。4.3 生成质量差的兜底策略大模型 API 不是每次都靠谱最常见的失败模式是生成四句就停了七律变成七绝、某句八个字、中间两联完全不对仗、出现岁月静好这种现代网络语。我的兜底策略有三层第一层是 Prompt 重试换一种表述重新生成比如补充你写的每一句都必须是严格的七个汉字。第二层是规则校验与提示。如果模型生成的是六句或十句前端仍然展示但标注模型生成格式异常已做截断处理这样至少演示不会中断。这个策略不太优雅但胜在稳定。第三层是冷启动模板。当用户输入的主题词命中了我们预置的意象模板库时直接从库里拼一首规则诗作为默认结果。比如主题梅花就有一首预制的模板诗这样万一 API 超时页面也能秒出结果。写诗模块要想在答辩时有亮点不要只展示生成了一首诗而要展示评价一首诗。我额外加了一个简单的格律分析子功能把生成的诗逐句拆开显示每句几个字、哪些字押韵、中间两联是否对齐。用诗词格律检查工具库来判断平仄和押韵把检查结果可视化出来。这个功能直接把写诗从一个黑盒输出变成了可分析、可评价的工具型应用评委对这个印象很好。5. 毕设全流程踩坑实录这些问题你必须提前知道5.1 数据与编码的坑爬虫、去重、字体古诗词数据第一坑就是繁体简体混合。很多公开数据集里有繁体字BGE 模型编码时会把繁体字拆成更细的 token导致情感分析效果波动。我的做法是入库前统一用工具转成简体但要保留一些必要的繁体地名和专有名词。第二个坑是去重时只按标题去重导致乌衣巷这种重名诗被误删不同作者的同名诗非常多。正确做法是按作者标题联合去重。第三个坑是前端展示用字。ECharts 默认字体对生僻字支持一般像龘这种古诗词里偶尔出现的字会显示成方框。我后来引了一个开源的中文字体包体积大一点但演示的时候不会在评委面前显示出乱码框非常值。5.2 模型训练与推理的坑显存、过拟合、接口超时BERT 微调在 8G 显存的显卡上能跑但 batch size 只能开到 816。如果你的机器没有 GPU用 CPU 训练也不是不行就是特别慢一个 epoch 可能要一个多小时。我当时的做法是先在一小部分数据上调试代码确认没 bug再全量训练。如果设备实在太弱就退而求其次用 TextCNN——它比 BERT 小得多效果在古诗情感分类上也能到 75% 左右足够交差。推理接口的性能问题也很容易被忽视。如果你把大模型 API 的调用放在同步接口里用户点击写诗后要干等十几秒页面没有任何反馈大概率会被当成卡死。解法是前端先显示正在构思中的动效后端做成异步任务加状态轮询写诗完成后再推送到前端。这个交互细节写进答辩 PPT 里是加分项它说明你考虑了真实用户体验而不只是调了个 API。5.3 前后端联调与演示现场的坑前后端联调最常见的三个问题跨域、编码、时间同步。Flask 后端记得配置 CORS前端请求里把 Content-Type 统一设成 application/json图片和词云接口注意用 UTF-8 编码。所有这些最好在开发第一天就配置好不要到最后联调才想起来。演示现场翻车基本都出在这几件事上现场没网。知识图谱还能用大模型写诗直接废了。所以写诗接口要做超时降级没网时返回模板诗。Neo4j 服务没启动。启动脚本要写成一键启动不要现场手敲命令。关系图渲染太慢。演示前先手动加载一两个核心诗人的子图别一上来就让浏览器渲染全量数据。情感分析模型首次加载慢。演示前先跑一次接口把模型预热后面就快了。5.4 给答辩准备的三个加分设计最后分享三个我从这个项目里总结出来的、投入不大但非常提升答辩观感的点。一是把数据规模量化。在系统首页放一行小字收录诗人 XXX 位、作品 XXX 篇、意象 XXX 个、关系 XXX 条。数字不用太大但一定要真实。评委听到具体数字比听到我们收集了很多诗词有说服力得多。二是准备一两段模型翻车的案例。比如故意找一首模型判错情感的诗词现场演示时问评委您觉得这首诗是什么情感让评委先说再展示模型结果然后解释为什么会分错、模型内部注意力放在哪些词上。这比一味展示准确性显得更诚实、更专业。三是把为什么用 Neo4j 而不是 MySQL这个问题的答案背熟。答案的核心是关系遍历的复杂度差异MySQL 做多层 JOIN 查询诗人-作品-意象会指数级变慢Neo4j 只遍历邻居节点查询速度和图的深度相关而不是和全图规模相关所以两个诗人之间有几度关联所有共用了同一个意象的诗人这类问题在图数据库里是秒回。这套项目做完之后我对毕设选题偏大这件事有了完全不同的看法。题目大不可怕怕的是没有把大题目拆成一条可执行的主线。知识图谱负责数据底座和可视化门面情感分析展示算法功力问答系统把数据变成了服务写诗模块跟上了大模型热点——四个模块串起来正好是一个完整的数据闭环。如果你准备照着这个方向做建议从数据清洗开始一天不要贪多先把 500 首高质量的诗词理清楚后面的所有模型和界面都有了立得住的根基。

古诗词知识图谱+情感分析+智能问答毕设全攻略

相关推荐

AI教材生成全流程：从大纲到低查重的原创性工程

KnowRob数据层实战：地图、日志与模型的组织与导入

OpenClaw Token成本优化：分层路由机制实战解析

更多资讯

大模型岗位竞争激烈？收藏这份程序员转型AI应用开发指南，轻松入行！

遇到的报错

水面无人船双IMU融合方案：JY61P+HWT101CT实现姿态监测与防侧翻控制

小白程序员必看：从骑手助手到AgenX智能体，大模型落地实践全解析

锂电隔膜五年预测报告：从技术选型角度读懂需求与产能周期

CNN人脸识别从零搭建：数据清洗到模型推理全流程实战指南

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？