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

每年到毕业设计开题那段时间，总有人抱着"知识图谱""情感分析""智能问答""大模型写诗"这几个词来找我，觉得随便拎一个出来都够写一篇论文，最后拼成一个大而全的题目之后又不知道怎么落地。我见过不少类似的项目，源码拿回来能跑通，但一问到"实体抽取怎么做""图谱为什么这么设计""问答意图怎么匹配"就哑火，答辩自然很难看。

这篇就把这套"中华古诗词知识图谱可视化 + 情感分析 + 智能问答 + AI自动写诗"的毕设项目，从题目拆解到技术选型、再到每个模块的实操细节和踩坑记录，完整过一遍。适合打算用这个方向做毕设、但又担心"做不完""答不上来""演示翻车"的同学。我会尽量把每一步的选择理由和背后的原理讲清楚，遇到可以直接复用的代码和 Cypher 语句也会贴出来。

1. 题目拆解与技术选型：这个毕设到底考什么

1.1 一个题目背后的五座大山

先把这个标题拆开看，它其实不是一个项目，而是四个功能模块加一个展现层：

• 知识图谱构建与可视化：把古诗词里的诗人、作品、朝代、地名、意象、词牌等实体抽出来，建立关系网络，再用图数据库存储和前端图表展示。
• 古诗词情感分析：输入一首诗，模型判断它是豪放、婉约、旷达还是愁绪满怀。
• 古诗词智能问答：用自然语言提问，比如"李白写过哪些关于月的诗"，系统返回答案。
• AI大模型自动写诗：给主题或首句，系统自动生成五言、七言，甚至藏头诗。
• 可视化大屏：把统计图表、关系图、词云整合到一个 Web 页面里，作为演示主界面。

毕设打分通常看三样：工作量、技术难度、创新点。这个题目刚好三样都占：数据量够大、技术栈够全、每块都有独立算法模型。但也正因为模块多，最容易出问题的地方不是"不会做"，而是"不知道做到什么程度算完"。所以第一步不是写代码，而是先定边界。

1.2 技术栈选型：不是越新越好，是能完成就好

很多同学一上来就想上最新框架，结果光配环境就花了两周。这里我给一套经过验证的、兼顾开发效率和答辩深度的技术组合：

这套选型的核心逻辑是：每个环节都用"够用且能讲清楚"的方案，把节省下来的时间花在调优和写文档上。比如 NER 部分，如果你的开题里写了"基于 BERT-BiLSTM-CRF 的命名实体识别"，那确实得训练一个模型；但如果只是毕设题目里带了一句"知识图谱"，用词典加正则完全说得过去，关键是让评委看到你理解了实体抽取的难点在哪。

1.3 模块协作与数据流结构

整个系统的数据流大概是这样的：爬虫脚本从古诗文类网站抓取原始文本，清洗后存进 MySQL；实体和关系抽取程序从 MySQL 里读取诗词数据，产出三元组写入 Neo4j；情感分析模型接收前端上传的诗词文本，返回情感类别；问答模块解析用户自然语言，转换成 Cypher 查询，从 Neo4j 取答案；写诗模块把主题词拼进 prompt，调用大模型 API 后经过格律校验返回前端。

四个模块看起来独立，实际上共用同一套数据底座和用户请求入口，这也是毕设答辩时最值得讲的一点：数据层、算法层、应用层是解耦的。

2. 知识图谱构建：从"原料"到"三元组"的全过程

2.1 数据来源与清洗思路

古诗词数据有两个来源：一是直接从公开数据集下载整理好的 JSON，二是自己写爬虫去古诗文类网站抓。我更推荐拿公开数据集打底，再用爬虫补充。原因很简单：公开数据集通常已经按"朝代-作者-篇名-正文-注释"结构化好了，省去大量清洗工作。

拿到数据后第一件事是去重和字段规整。诗词数据最常见的脏数据包括：同一首诗在不同数据集里标点不同；作者名有别名（"李白"和"李太白"都在库里）；体裁字段混乱（"五绝""五言绝句""七律"混用）。

处理建议是写一个清洗管道（pipeline），每一步做一件事：

1. 按标题+作者+正文前 20 字计算 MD5，去重。
2. 统一作者名，建一个别名字典，比如把"李太白""青莲居士"映射到标准名"李白"。
3. 规范化体裁字段，映射成"五绝/七绝/五律/七律/词/曲/乐府/其他"八类。
4. 剔除乱码和疑似非诗词文本。

清洗完的数据存 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 是最省事的方式。

先把清洗后的数据导出成三个 CSV：poets.csv、works.csv、images.csv，再写导入脚本。份量比较关键的是 work 与 image 的关系，因为一首诗对应多个意象，需要先建一个 work_image_rel.csv：

work_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 字段，同名作品会撞车，所以先把"标题+作者"作为唯一标识去重，或者加上 constraint：

CREATE 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 更合理。实操里我把"正文内容"存在 MySQL，Neo4j 节点上只保留标题和作者，通过 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-5，batch size 16，训练 5 个 epoch，早停 patience=2。在验证集上准确率大概 82% 左右，可能不如现代文本那么高，但这已经在古诗词情感这个任务上够用了——毕竟人工标注之间的一致性本身也只有八成多。

训练代码的结构很简单：

from transformers import BertForSequenceClassification, BertTokenizer model = BertForSequenceClassification.from_pretrained( "hfl/chinese-roberta-wwm-ext", num_labels=5) 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 只能开到 8～16。如果你的机器没有 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 首高质量的诗词理清楚，后面的所有模型和界面都有了立得住的根基。