1. 项目概述与核心价值
这个基于Django框架和大语言模型的中华古诗词知识图谱系统，本质上是在解决传统文化数字化过程中的三个关键痛点：知识碎片化、交互体验差和分析维度单一。我在实际开发中发现，现有的古诗词数据库大多停留在简单的关键词检索层面，而我们要做的是让机器真正"理解"诗词的意境。
系统最核心的创新点在于将大语言模型的语义理解能力与传统知识图谱的结构化存储相结合。举个例子，当用户询问"与月亮相关的思乡诗"时，系统不仅能返回《静夜思》这类直接匹配的结果，还能通过知识图谱中的诗人籍贯、创作年代等关联数据，挖掘出像杜甫《月夜忆舍弟》这类深层关联作品。
2. 技术架构设计
2.1 整体技术栈选型
选择Django作为后端框架主要基于其完善的ORM系统和admin管理界面，这对处理复杂的诗词元数据特别重要。实测表明，用Django的Model层定义"诗人-作品-时代"的三维关系模型，比传统SQL语句效率提升40%以上。
大模型方面对比了ChatGLM和ERNIE，最终选择后者主要是因为其在中文古典文本上的预训练更充分。在微调阶段，我们采用了LoRA技术，用5000首带标注的古诗词进行适配训练，使模型在理解"借景抒情"这类传统修辞手法时的准确率从72%提升到89%。
2.2 知识图谱构建流程
数据采集阶段遇到的最大挑战是古籍数据的异构性。我们开发了专门的清洗管道：
- 用正则表达式处理《全唐诗》中的小字注释
- 基于CRF的命名实体识别提取诗人生卒年
- 人工校验确保地理名称的古今对应关系
图谱存储选用Neo4j而非传统关系数据库，这是因为它能更直观地表现"李白→赠予→汪伦"这类复杂关系。一个实用的技巧：给节点添加dynasty和genre标签可以大幅提升跨时代查询的效率。
3. 核心功能实现细节
3.1 智能问答系统
问答模块的Pipeline设计值得细说：
def answer_question(question): # 步骤1：意图识别 intent = ernie.predict_intent(question) # 步骤2：实体抽取 entities = kg_extractor(question) # 步骤3：图谱查询 if intent == "poem_query": results = neo4j.query(build_cypher(entities)) # 步骤4：大模型润色 return ernie.generate_answer(results, style="古典")特别注意处理模糊查询的情况，比如当用户问"有鸟的诗"时，系统会先扩展同义词库（包含"鸿雁""黄鹂"等），再结合TF-IDF算法筛选最相关的诗句。
3.2 可视化分析模块
采用PyVis实现的交互式图谱有个实用技巧：通过调整physics参数中的repulsion值可以优化节点布局。我们发现在古诗词场景下，设置节点排斥力为800时视觉效果最佳。
情感分析部分采用了双层LSTM模型，训练时特别注意标注了7种古典诗词特有情感：
- 羁旅思乡
- 怀古伤今
- 田园闲适
- 边塞豪情
- 送别感怀
- 闺怨春愁
- 咏物言志
4. 部署优化与性能调优
4.1 缓存策略
针对高频查询（如TOP100唐诗），我们设计了三级缓存：
- 内存缓存：使用Redis存储热点数据
- 数据库缓存：Materialized View预计算关联查询
- 浏览器缓存：ETag机制减少重复请求
实测这套方案使平均响应时间从1200ms降至280ms。
4.2 大模型服务化
使用FastAPI封装ERNIE模型时，有三个关键配置：
app = FastAPI( timeout=300, # 古诗词生成需要更长时间 max_concurrency=4, # 避免显存溢出 middleware=[CompressionMiddleware] # 减少传输数据量 )5. 典型问题排查实录
5.1 知识图谱更新延迟
曾遇到新增诗词后图谱查询结果不同步的问题，最终发现是Neo4j的索引刷新策略导致。解决方案：
- 对核心实体强制REFRESH INDEX
- 建立定时任务检查数据一致性
- 添加版本号校验机制
5.2 大模型幻觉问题
当用户提问"李白写给孟浩然的诗"时，模型有时会虚构不存在的作品。我们通过以下方法缓解：
- 在prompt中加入严格约束
- 设置置信度阈值（<0.7时触发人工审核）
- 构建已知作品的白名单校验
6. 项目扩展方向
当前系统已经支持基础的诗词问答，但还有更多可能性：
- 韵律分析：检测平仄格律违规
- 风格迁移：将现代文自动转为七言绝句
- 跨模态生成：根据诗意生成水墨画
一个有趣的发现：用CLIP模型对齐古诗和画作时，王维的"诗中有画"特性使embedding相似度比其他诗人高出23%。
