最近咨询这个方向的同学特别多——Django + DeepSeek 大模型 + 知识图谱 + 古诗词情感分析。乍一看像把几个热门词堆在了一起，实际做起来才会发现，这几个技术栈其实是能串成一条完整逻辑链的：数据从哪来、知识怎么组织、语义怎么理解、推荐怎么做、结果怎么展示，环环相扣。这种题目既避开了纯网页开发那种“增删改查”的平淡感，又不需要你从零训练模型，正好踩在大模型应用落地的主流路子上。
这篇内容适合两类人看：一类是正在选毕设题目、想做个有技术含量又不至于做不完的同学；另一类是已经选了类似题目、但还没想清楚模块之间怎么衔接的同学。我不讲虚的，直接把项目拆开揉碎，讲清楚每个模块为什么这么设计、实际动手时有哪些坑、以及答辩时怎么把亮点讲明白。
1. 项目概述与技术选型思路
1.1 这个毕设到底在做什么
从功能上看，这个项目其实由四条主线构成。
第一条线是古诗词数据的采集与治理。古诗词数据本身是典型的非结构化文本，需要把朝代、作者、诗名、体裁、正文、注释、翻译这些信息抽取出来，做成标准化字段。这一层是后面所有功能的地基——知识图谱需要实体关系，情感分析需要正文文本，推荐系统需要标签和作者信息，可视化需要朝代体裁分布。很多同学上来就急着调大模型接口，忽略数据清洗，结果后期做图谱时才发现诗句有乱码、作者名字前后不一致、体裁分类混乱，回头补数据比重新做一遍还痛苦。
第二条线是知识图谱的构建与存储。做图谱不是把数据塞进数据库就完事了，你得先想清楚本体设计：这个领域有哪些实体类型，有哪些关系类型。古诗词领域核心实体无非是作者、作品、朝代、体裁、主题，核心关系也就是“作者写了作品”“作品属于朝代”“作品采用体裁”“作品涉及主题”。把这几组关系定义清楚，图谱的骨架就有了。至于存储用图数据库还是关系数据库，这是后面要做的决策。
第三条线是情感分析。这既是项目的技术亮点，也是答辩时最能讲出东西的部分。古诗词的情感表达非常含蓄，讲究借景抒情、托物言志，传统的文本分类模型很难处理好“感时花溅泪”这种委婉曲折的情感。引入 DeepSeek 大模型，本质上是借助大模型的语义理解能力去替代传统情感分类模型，结合精心设计的 Prompt 来输出结构化情感结果。
第四条线是推荐与可视化。推荐系统要吃两路输入：一路是知识图谱里的实体关联，告诉你哪些诗词在知识层面有联系；另一路是情感分析的结果，帮助你判断用户的偏好倾向。可视化是用图表把这套系统中的数据关系和情感分布呈现出来，让评委一眼看出你做了哪些工作。
1.2 为什么选 Django 这一层做后端
关于后端框架，很多人在 Django 和 FastAPI 之间犹豫。毕设场景下我强烈建议用 Django，理由很务实。
Django 自带 Admin 后台，这是一个被严重低估的效率工具。诗词数据入库后，Admin 后台直接提供搜索、过滤、分页编辑能力，不需要你自己从头写一套管理界面。演示的时候也可以顺手展示后台管理能力，也算一个小的功能点。
Django 的 ORM 在面对复杂关系查询时非常顺手。知识图谱要做的核心操作是“查某个实体的所有关联实体”，用 ORM 的 related_name 反向查询一次就能拿到结果，不需要写一堆联表 SQL。而且 Django 的迁移系统可以在数据结构调整时自动生成迁移脚本，对频繁改表结构的开发阶段来说，省心不少。
Django 自带用户认证和 Session 管理。推荐系统必然涉及用户偏好记录，如果要用 Flask 或 FastAPI，这些基础设施都要自己接，Django 则开箱即用。你可能觉得这不就是调个包嘛，但实际开发节奏里，这些基础能力的差距会被不断放大，最终影响整体进度。
1.3 为什么用 DeepSeek 而不是自己训练模型
传统自然语言处理课上学到的情感分析方案，一般是用开源的预训练模型做微调。这个方案在通用领域是可行的，但在古诗词场景下有两个绕不开的问题。
第一个问题是标注数据从哪来。微调需要大量带情感标签的古诗词数据，网上的标注集很少，标注质量也无从考证。你自己去标注几百条，时间成本太高，而且主观性很强——不同人对一首诗的情感判断可能截然不同，这样的标注集训练出来的模型说服力不够。
第二个问题是领域迁移效果。古诗词的语言和现代汉语差别巨大，词汇、语法、修辞方式都很不一样，通用模型直接拿来预测，效果通常不太理想。
DeepSeek 这类大模型恰好解决了这两个问题。它的零样本理解能力很强，你不需要准备任何标注数据，写一个高质量的 Prompt，把诗词原文传进去，就能获得比较结构化、可解释的情感判断。这个思路和当前业界大模型落地的常见方式一致——不是重新训练，而是通过提示工程激发大模型已有的知识能力。实际使用下来，DeepSeek 的 API 成本也很低，日常调试完全无压力，这对预算有限的学生来说也是个重要的现实考量。
2. 核心功能模块拆解
2.1 古诗词知识图谱的构建
知识图谱是这个项目最容易做砸的地方。做砸的原因通常不是技术难，而是很多人一上来就高价上全套图数据库方案，最后花在环境配置和中间件调优上的时间比做功能还多。
我的建议很直接：如果用不到真正的分布式图计算能力，就用关系数据库来存储图谱结构。你可能觉得不用 Neo4j 就算不上“知识图谱项目”，但我要告诉你的是，知识图谱的本质是“用图结构组织数据”，而你完全可以用关系表来描述图。一张实体表存节点，一张关系表存边，这就是最朴素的图存储。
实体表设计大概长这样：自增主键、实体名称、实体类型、实体的简介或描述字段。关系表则是：起点实体 ID、终点实体 ID、关系类型、附加属性。这种设计天然支持图谱查询——你想知道某个作者写了哪些作品，只需要查关系表里 from_entity_id 等于该作者 ID 且 relation_type 为“创作”的记录。这种查询用 Django ORM 写非常简单，对答辩讲解也很友好，因为它逻辑清晰、容易说清楚。
那么什么时候才真的需要图数据库？如果你的数据量到了百万级并且要做多跳关系推理，比如查“跟该作者同朝代且同主题的其他作者”，图数据库的优势才会明显。毕设级别的数据量撑不起这个场景，硬上 Neo4j 只会让你多一个需要维护的中间件，并增加部署环境的不确定性。
关于数据获取，我的建议是自己写采集脚本，配合手工校验，目标是拿到干净、字段统一的数据。不要迷信网上传的“全量古诗词数据集”，很多数据集扒下来之后你会发现存在错别字、地域名缺失、繁体简体混杂等一堆问题。采集过程本身就是毕设里值得写进论文的工作量，“数据爬取与清洗”这一章可以写上好几页。
2.2 情感分析模块设计与 Prompt 工程
情感分析模块是整个项目的智能核心，也是你可以在论文里写最多创新点的地方。
先明确情感分类的粒度。很多相似项目只做了三分类：正向、负向、中性。如果仅限于此，答辩时很难站住脚，因为大家都知道三分类太粗了。古诗词的情感非常细腻，至少要增加到“情感类型 + 情感强度 + 核心意象”三个输出维度。
以那首写了“国破山河在”的五言律诗为例。简单判断负向没用，你要的是这样的结构化结果：
- 情感类型：忧国伤时
- 情感强度：强
- 核心意象：城池荒芜、山河破碎、人烟稀少
- 情感解读：诗人目睹国家战乱后的衰败景象，表达深沉的忧国之情
这套结构化结果的生成质量，取决于你怎么写 Prompt。我在实际调试中总结了一个非常重要的经验：不要让模型直接给出情感标签，而是先引导它“扮演”一位精通古诗词的文学评论者，让它先分析诗歌的内容、意象和创作背景，再给出结构化判断。这样做有两个好处：一是准确度明显提升，二是在你拿不到大模型推理过程的情况下，模型给出的解读可以作为系统展示的“情感分析解释”文本，让用户看到的不是冷冰冰的标签，而是有逻辑的分析。
在 Prompt 中你要明确要求输出 JSON 格式，并定义好各字段的取值范围，比如情感类型限定在几个固定的枚举值中。这样前端拿到数据后能直接渲染，不需要做复杂的字符串解析。还要注意把温度参数调低，把随机性压到最小，保证演示时前后调用结果一致。
2.3 推荐策略与可视化方案
推荐模块的设计要讲究“讲得通”。我推荐的做法是知识图谱关联推荐加情感偏好过滤的混合策略，这个组合既好实现又好讲。
知识图谱关联推荐的逻辑很直观：用户在看某首作品，系统找图谱中与该作品有关联的其他作品。比如用户在看某位诗人的作品，那同作者的其他作品天然就是强关联；进一步地，通过“主题”这个中间节点，可以找到其他诗人写的同主题作品。这个链条是：作品A—涉及→主题T，作品B—涉及→主题T，因此作品A与作品B存在“同主题”关联。这就是用图谱做推荐最自然的思路。
情感偏好过滤则是从用户侧出发。用户在系统里注册或反馈“喜欢/不喜欢”时，系统记录用户对不同情感类型的偏好权重。推荐排序时，把用户偏好权重乘到图谱关联得分上，得到最终推荐排序。这样实现的推荐系统逻辑清楚，数据流完整，也容易在论文里画出示意图。
可视化模块重点是这三个图：知识图谱的力导向图、情感分布的雷达图、作者朝代体裁的统计图。前端图表库直接用 ECharts 就够了，不需要引入重型可视化框架。特别提醒：力导向图的节点数量一定要控制，最好预置几个精选子图，每个图控制在二十到三十个节点以内。一旦所有节点全量铺开，页面会卡到没法演示。
3. 实操过程与核心实现
3.1 环境搭建与项目骨架
下面按最常见的 Windows + PyCharm + Anaconda 环境来讲，适配大部分同学的实际条件。
Python 建议用 3.10 或 3.11。Django 选择 4.2 及以上，注意新版本中某些包的依赖要求，提前确认。还需要安装大模型调用的官方 Python 库。
conda create -n poetry python=3.11 conda activate poetry pip install django==4.2 psycopg2-binary requests pip install openai这里有个绝大多数人不知道的细节：DeepSeek 的接口协议是兼容 OpenAI 格式的，所以直接用 openai 这个库，然后指定 base_url 为 DeepSeek 的地址就可以正常调用，官方也推荐这种用法。不需要额外安装特殊的第三方包，维护成本低得多。
项目结构建议用 Django 的 startproject 创建根项目后，手动建一个 apps 目录，里面放五个应用。每个应用职责单一：用户和偏好、诗词数据管理、知识图谱、情感分析、推荐逻辑。这样做的好处是各模块边界清晰，写论文时“系统架构”那一章的结构也可以直接参照。
3.2 数据建模与入库
诗词数据表的核心字段至少包括：标题、作者、朝代、体裁、正文、注释、翻译、主题标签。作者不要直接存字符串，一定要单独建作者表并用外键关联，因为后面知识图谱需要把你作品节点和作者节点通过关系边连接起来，没有独立主键就没办法建关系。
知识图谱的数据建模用一对极简的实体关系表来实现。实体表记录实体名称和实体类型，关系表记录起点、终点和关系类型。你可以建一个 Django management command，在初始化时从诗词表的数据自动生成实体和关系记录。这个自动生成过程比较顺的逻辑是：从诗词表里读取作者、朝代、体裁字段，为每个字段值创建对应的实体，再对每首诗创建“作者—创作—作品”“作品—属于—朝代”“作品—采用—体裁”等关系记录。
数据入库时还有一个容易忽略的问题：繁体字与简体字。古诗词数据集里繁体字非常常见，必须统一转成简体再入库，同时在搜索功能里做好同义字处理。如果不做这一层，会出现搜索某个简体关键词永远搜不到某首含繁体字形态的著名作品的情况。
3.3 DeepSeek 接口集成
集成代码并不长，但它涉及两个容易踩坑的点。
第一个坑是请求超时。大模型接口在网络高峰期响应很慢，如果不在请求时设置超时时间，服务端线程会一直被挂起。一定要设置 read timeout，建议 30 秒以上，同时在前端用异步加载提示，避免用户等待时页面无反应。
第二个坑是输出校验。大模型虽然是强约束生成，但仍然存在小概率输出不符合预期的情况。拿到响应后要对 JSON 里的关键字段做验证，发现字段缺失时重试一次，仍然不行就降级返回预设的默认结果。这步是容错设计，不能省。
下面是一个可直接参考的情感分析函数骨架：
import json from openai import OpenAI client = OpenAI( api_key="your_api_key", base_url="https://api.deepseek.com" ) def analyze_poem_emotion(poem_text, poem_title=""): prompt = f""" 你是一位研究古诗词的文学评论家。请阅读以下诗歌，先分析其表达的思想情感，再输出结构化结果。 诗歌标题：{poem_title} 诗歌正文：{poem_text} 要求： 1. 先简要分析诗歌中最关键的意象和整体氛围； 2. 以 JSON 格式输出，字段固定为 emotion_type、emotion_intensity、core_imagery、explanation； 3. emotion_type 只能从 忧国忧民、思乡怀人、山水田园、壮志豪情、离愁别绪、人生感悟、其他 中取值； 4. emotion_intensity 取值区间是 1 到 5 的整数。 """ response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一名严谨的古诗词研究助手。"}, {"role": "user", "content": prompt} ], temperature=0.2, response_format={"type": "json_object"} ) content = response.choices[0].message.content return json.loads(content)需要注意的一个细节是温度系数。这里设置为 0.2，目的是保证多次调用同一首作品时结果基本稳定。你在论文里也可以专门写一小节对比不同温度系数下的情感分析一致性，这本身就是一个加分的小实验。
3.4 推荐逻辑的落地
推荐模块的实时计算逻辑可以按以下步骤来做。
第一步，获取当前作品在知识图谱中的所有关联实体。用 Django ORM 查询关系表，找出起点或终点是当前作品 ID 的记录即可。
第二步，根据关联实体计算候选集。把第一步中关联实体连接的所有其他作品取出，计作候选池。注意要把当前作品本身排除掉。
第三步，给候选池中的每个作品计算关联得分。这里用一套简单清晰的加权规则：同作者计 3 分，同主题计 2 分，同朝代计 1 分。这个权重关系在论文里可以解释成“作者个人风格的影响力大于时代背景的影响”。多个条件可以叠加。
第四步，接入用户偏好。从用户表里读取该用户的情感偏好向量，对候选作品的情感类型做加权，最终按加权总分从高到低排序，取前十个作为推荐结果。
这个逻辑用 Django ORM 写不会超过一百行代码，但运行效果和可解释性都很好。答辩时你可以说“本系统的推荐算法基于知识图谱路径计数加权，同时融合用户情感偏好”，这比单纯说“用了协同过滤”要更能体现你自己的设计思考。
4. 常见问题与排查技巧
4.1 API 调用环节的坑
先讲一个发生频率最高的问题：API 调用直接超时，前端页面卡死。如果你用的同步请求，一旦接口没响应，Django 的 worker 就被占住了。解决方案是设置合理的超时时间，加上超时重试机制。如果要提升到更优，可以用 Django 的异步视图配合异步 HTTP 请求库，不过对毕设来说超时重试已经够用了。
另一个容易被忽略的问题是 API Key 的安全。前端页面不要直接暴露任何密钥，所有大模型调用必须发生在后端。这一点在答辩时如果被问到也要能答上来。把 API Key 配置在环境变量里而不是写死在代码中，也可以显出良好的工程素养。
4.2 数据质量与查询性能
诗词数据清洗的坑主要体现在文本内容本身。古诗词网站扒下来的数据经常出现重复投稿、标点混乱、个别字因字符集原因显示为问号。我的建议是不要盲目相信爬虫数据，入库前写几道清洗规则：去掉空白字符、统一标点为中文标点、简繁转换、去除重复行。经过清洗后再入库，后面做情感分析和全文搜索的准确率都会明显提升。
当数据量到五千条以上时，搜索功能会逐渐变慢。如果用了 MySQL，注意给经常搜索的字段加索引。如果涉及全文搜索，建议直接引入分词组件，并在自定义词典中加入古诗词领域词汇，避免“烽火”“断肠”这类常见意象词在分词时被错误切散。
4.3 答辩演示的实操建议
我看到太多人在现场演示时翻车，基本都是同一个原因：现场网络不稳定，调大模型接口卡住了。为了解决这个问题，强烈建议在系统里加上一个本地模拟开关。
本地模式的具体实现是：写一个接口适配层，当检测到环境变量为演示模式时，不再调用真实大模型，而是从一个预先写好的情感分析结果表里读取结果。这个模拟结果表可以在项目开发过程中逐渐积累——每调用一次成功的大模型接口，就把结果缓存下来。这样在无网络环境下演示，系统依然可以正常运行，而且提前缓存的文本还是真实调用产生的，不是乱写的假数据。
答辩时记得准备 5 到 10 首不同类型的诗词作为测试用例，分别覆盖豪放、婉约、忧国、思乡、山水田园等常见题材。这个动作看似简单，实际上能证明你的系统在不同类型文本上的稳定性。演示时先跑一遍图谱查询，再跑一遍情感分析，最后展示推荐列表，按这个顺序串流程是最顺的。
5. 一些想单独说的经验
我个人在实际操作中的体会是，这类项目最大的难点不在某一个技术点上，而在于把大模型能力和知识图谱串成一个逻辑完整、能自圆其说的故事。很多同学做着做着就陷入“每天调接口、改页面”的流水线状态，忽略了从论文和答辩角度，整个系统的设计逻辑才是真正能拉开差距的地方。
拿论文的“系统设计”章节来说，我非常建议你自己画一张模块关系图，把五个应用的职责和它们之间的数据流标注清楚。这张图是整个论文的眼睛，评委大概率会盯着它问问题。如果你能对着图把“用户点了哪首诗、系统查了什么表、调了什么接口、返回了什么数据、最终怎么渲染到页面上”这条链路讲清楚，答辩就已经成功了大半。
最后再分享一个实用技巧：如果是团队协作或者想要后续复用，可以考虑在项目里用 Git 做版本管理，每次功能完成时打一个标签。这不只是工程习惯问题，更关键的是——当你在答辩前夜不小心改坏了代码时，一条回滚命令就能保住整套演示环境，这种安全感在毕业季比什么都值钱。项目后续的扩展方向也很明确：把推荐升级成基于向量检索的语义推荐，或者把情感分析的维度继续细化，比如引入创作背景信息做更深的分析，这些在毕设结论里提一句就很有前瞻性。
