Python爬虫+LSTM歌曲评论情感分析与Django可视化系统-北京尧图网络

每年一到毕业设计选题季就有大量同学在“做个能演示的应用型项目”和“搞个带算法的研究型课题”之间纠结。如果你希望题目本身不是纸上谈兵做出来的东西又能直接打开浏览器给老师现场演示那“基于Python爬虫技术实现歌曲评论数据分析与可视化设计 LSTM情感分析 Django展示”这个方向几乎是把所有加分项都占满了。它包含一条从数据采集、处理、分析、建模到Web系统交付的完整链路涉及requests爬虫、XPath解析、pandas清洗、jieba分词、pyecharts可视化、LSTM深度学习模型以及Django后端集成。认真做下来论文里有数据、系统里有功能、答辩时有图表无论起点是零基础还是有点Python底子都能在一个学期内把它跑通。下边就按我实际动手做过的一个版本把整个系统的架构、核心代码、模型训练和调试经验完完整整过一遍。1. 项目整体拆解一个毕业设计到底包含哪些模块1.1 为什么是“爬虫 LSTM Django”这个组合先说结论这个组合不是随便拼起来的它恰好覆盖了毕业设计评审里最关心的四个维度——数据获取能力、数据分析能力、算法建模能力、工程落地能力。很多同学喜欢单独做一个爬虫项目比如抓取新闻标题存到Excel里那在答辩时很容易被问“你的算法在哪里”。反过来如果只做一个LSTM情感分析又会被追问“你的数据从哪来”总不能说是网上下载的现成数据集那工作量看起来就单薄了。把这个项目拆开看爬虫负责拿到真实、有时效性、带用户行为的歌曲评论数据LSTM负责从这些文本里挖掘情感倾向Django则把所有结果整合成一个可视化的Web系统。老师打开浏览器既能看爬虫抓了多少数据、评论点赞Top10是什么也能输入一句新评论让模型判断情感极性还能看到词云、趋势曲线、情感分布饼图。这种“看得见摸得着”的完整度比单纯贴一堆代码截图要有说服力得多也是毕设拿高分的关键。还有一个很现实的考量这套技术栈对机器环境要求不高。LSTM模型用小规模的Embedding 单层/双层LSTM就能训练出可用的效果不需要像BERT那样必须上GPU也不需要几百G的预训练文件。也就是说哪怕你手头只有一台普通笔记本CPU跑上十几分钟也能完成一轮训练这在中西部普通院校的毕设环境下特别重要。选型时别总想着“越新越好”LSTM虽然不像Transformer那么热门但它在短文本分类任务上依然稳健答辩时也好解释。1.2 系统功能模块与数据流向整个系统可以拆成五个模块数据是单向流动的逻辑非常清晰。数据采集模块用requests请求评论接口拿到JSON后解析出昵称、评论内容、点赞数、评论时间等字段数据清洗模块把重复评论、空内容、HTML实体这些脏数据去掉写入CSV或SQLite数据分析模块负责分词、停用词过滤、词频统计和时间趋势聚合LSTM模型模块使用清洗后的文本训练情感二分类器最后Django把分析结果和模型预测统一渲染到页面上。这个数据流设计的核心好处是“每一层都可以单独测试”。我在实际开发时就是先单独跑爬虫把数据文件落盘再写分析脚本最后才做Django页面。如果一开始就把所有代码混在同一个文件里出了问题都不知道是网络请求挂了、编码乱了还是数据库没写入。分层之后每一层都能用print或者DataFrame.head()快速验证排查效率会高很多。下面用一张表说清楚每个模块的职责、依赖和产出物方便你直接对照着规划自己的工作量和论文章节。模块核心职责主要依赖库产出物数据采集请求评论接口、解析JSON、翻页抓取requests、json、timeraw_comments.csv数据清洗去重、过滤空值、清理HTML标签和表情符pandas、reclean_comments.csv数据分析分词、词频统计、时间趋势、点赞排行jieba、pandas、collections统计结果表可视化生成词云、折线图、饼图、柱状图pyecharts、wordcloudHTML图表文件LSTM模型文本情感分类训练与预测torch、numpy、sklearnlstm_model.pthDjango展示聚合数据与模型渲染Web页面django可运行的Web系统1.3 技术选型背后的坑与考量先讲版本问题。Python一定要装3.8或以上建议3.10别用2.x也别用最新3.12之前太激进的版本因为torch和tensorflow对Python版本的兼容性往往滞后半年。Django我推荐用3.x不要直接上5.x除非你熟悉新版的路由和异步特性。PyTorch选CPU版本就够了毕竟毕设数据量不大CPU训练也完全能跑。安装时候直接用pip装比较省事注意装完以后用python -c import torch; print(torch.version)验证一下能正常输出版本号再继续。再说为什么不用Scrapy而用requests。Scrapy是专业爬虫框架功能强大但学习曲线陡峭项目里还会涉及中间件、Pipeline等概念对毕设来说杀鸡用牛刀而且出问题时不好调试。requests是把HTTP请求的细节暴露在你面前请求头、参数、响应内容都一清二楚对初学者来说反而是最好的教学工具。还有个必须想清楚的问题爬虫的目标站点选择。我当时选的是网易云音乐因为它的评论接口返回的是结构化JSON字段齐全并且接口参数里有加密字段这本身就能作为论文里的技术点来讲。QQ音乐、酷狗音乐也有类似接口但有的需要处理特殊签名逻辑有的评论内容反爬策略更严格对毕设来说没必要增加额外风险。选网易云的好处是歌曲ID容易获取评论内容质量较高情感表达丰富很适合做情感分析语料。2. 数据采集层requests XPath 拿下歌曲评论2.1 先搞清楚评论是怎么加载的别直接在网页源码里找很多新手犯的第一个错误是直接用requests请求歌曲页面HTML然后用XPath去提取评论结果发现页面源码里根本没有评论数据。原因很简单主流音乐平台的评论都是前端异步加载的页面HTML里只有壳真正的评论内容由JavaScript在页面渲染完成后通过XHR请求接口获取。我的做法是打开浏览器开发者工具切到Network面板在XHR请求列表里找包含comment、resource、get这类关键字的请求点进去看Preview这就是评论接口的JSON返回。评论接口的请求体里通常会有params、encSecKey之类的加密字段直接把请求地址放到requests里裸跑一定失败。针对毕设项目我不建议你把精力耗在破解加密逻辑上那是一个深坑前人已经踩了无数次。更聪明的做法是用浏览器开发者工具从网络面板里复制一个真实发出的请求把它处理成一个POST请求模板包含完整的请求头和请求体参数然后在代码里只替换歌曲ID、分页游标和随机时间戳。也就是说你不去自己生成加密参数而是站在浏览器已经帮你生成好的请求参数之上工作。这样实现简单、稳定而且合规性上风险也更小。顺带说一下XPath的用处。虽然评论数据走的是JSON接口但歌曲的标题、歌手名、所属专辑这些基础信息还是在页面HTML里的这时候就要用requests获取页面配合lxml库的XPath来抽字段。XPath里text()函数很常用比如取出一个节点下的所有文本可以写//div[classname]//text()这在处理歌单列表、歌曲详情时特别方便。爬虫项目里requests负责取数据XPath负责精确挖字段两者配合才完整。2.2 评论分页与字段解析的完整代码实现下面这段代码是我实际用的评论抓取函数核心逻辑就三步拼接参数、发起请求、解析数据。这里需要你提前准备好两个东西一个是歌曲ID比如周杰伦《晴天》的ID是186016另一个是从浏览器里复制出来的完整请求模板我把它简化成headers和data两个变量你用自己的模板替换即可。import requests import json import time import random import pandas as pd def get_comment(song_id, total_pages5): # 从浏览器开发者工具中复制的请求头至少包含 user-agent、referer、cookie headers { User-Agent: Mozilla/5.0 ... Safari/537.36, Referer: https://music.163.com/, Cookie: 你的浏览器Cookie } # 从浏览器复制并简化后的请求体模板 base_data { params: xxx, encSecKey: xxx } all_rows [] cursor -1 # 第一页游标 for page in range(total_pages): # 把歌曲id和游标拼进请求体 data dict(base_data) data[params] data[params].replace({song_id}, str(song_id)) data[params] data[params].replace({cursor}, str(cursor)) resp requests.post( https://music.163.com/weapi/comment/resource/comments/get, headersheaders, datadata, timeout10 ) result resp.json() comments result.get(comments, []) if not comments: break for c in comments: all_rows.append({ song_id: song_id, user: c[user][nickname], content: c[content], liked: c[likedCount], time: time.strftime(%Y-%m-%d %H:%M:%S, time.localtime(c[time] // 1000)), comment_id: c[commentId] }) # 网易云评论接口用data.cursor作为下一页游标 cursor result.get(cursor) # 控制请求间隔避免对服务端造成压力 time.sleep(random.uniform(1, 2)) return pd.DataFrame(all_rows) df get_comment(186016, total_pages3) df.to_csv(raw_comments.csv, indexFalse, encodingutf-8-sig) print(df.head())有几个细节要强调。第一time.sleep一定要写哪怕你觉得自己的爬虫只抓几十页无所谓突然高频访问很容易触发服务端的风控机制一旦返回验证码或者开始拒绝请求整个抓取流程就断了。第二encoding要用utf-8-sig这样生成的CSV文件用Excel打开才不会是乱码。第三每次请求前把page间隔随机化不要每次sleep固定值更接近真人操作习惯。2.3 XPath抓取歌曲信息与数据清洗细节评论抓回来之后还需要歌曲的基础信息做关联。这里我直接用requests获取歌手页面的HTML再用XPath抽取歌曲名和播放链接。简单案例如下注意lxml里的tostring可能带着html标签直接用text()函数就能拿到纯文本。import requests from lxml import html def get_song_info(song_id): url fhttps://music.163.com/song?id{song_id} resp requests.get(url, headersheaders) tree html.fromstring(resp.text) title tree.xpath(//title/text())[0].strip() # 网易云页面标题格式是歌曲名 - 歌手 - 网易云音乐 - 网易云音乐 return title.split( - )[0]数据清洗这步很容易被低估。我第一版模型直接拿原始评论去训练效果差得一塌糊涂后来才发现数据里全是坑。比如评论里有换行符、HTML转义字符、表情符号还有大量重复内容同一首歌反复刷同一句这些都要在清洗阶段处理掉。我的清洗脚本主要做四件事去掉URL和HTML标签把nbsp这类实体转成空格去重时以comment_id为准最后把内容长度小于2的词条直接过滤因为过短的文本没有情感信息。import pandas as pd import re df pd.read_csv(raw_comments.csv) df df.drop_duplicates(subsetcomment_id).copy() df[content] df[content].fillna() def clean_text(text): text re.sub(r[^], , text) # 去HTML标签 text re.sub(rhttps?://\S, , text) # 去URL text text.replace(nbsp;, ).replace(amp;, ) text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9\s], , text) # 去表情符和特殊符号 return text.strip() df[clean_content] df[content].apply(clean_text) df df[df[clean_content].str.len() 2] df.to_csv(clean_comments.csv, indexFalse, encodingutf-8-sig)关于合规性多说一句爬虫技术本身是中性工具做毕设时一定要把请求频率控制在合理范围内尊重目标站点的服务条款只采集有限的公开评论数据用于学习和研究不要拿去商用也不要尝试触碰任何非公开信息。这既是安全底线也是论文里“技术伦理与规范”这个小节的素材。3. 数据分析与可视化让评论变成会说话的图表3.1 分词、词频统计和关键词提取数据干净之后第一件事就是分词和词频统计因为评论表达很口语化中文文本没有空格作为天然分隔符必须用分词工具把它切成词粒度。jieba是Python生态里最常用的分词库简单高效。分词时一定要配合停用词表把“我们”“真的”“一个”“这么”这类没有情感信息的高频虚词去掉否则词云里全是“的”“了”“我”没有任何业务含义。我整理了一个基础的处理流程先加载全网通用停用词表再往表里手动加一些歌曲评论场景特有的词比如“哈哈哈哈”“啊啊啊”这类拟声词以及“每天”“循环”这类行为词它们对情感判断帮助不大。然后在分词结果上做词频统计用collections.Counter直接计算TopN最后分别输出到字典和表格文件。如果你想做得更细一点还可以用jieba.analyse提取TF-IDF关键词得到的结果会更有区分度。import jieba from collections import Counter df pd.read_csv(clean_comments.csv) stopwords set() with open(stopwords.txt, r, encodingutf-8) as f: for line in f: stopwords.add(line.strip()) words [] for content in df[clean_content]: for w in jieba.cut(content): w w.strip() if w and w not in stopwords and len(w) 1: words.append(w) counter Counter(words) top_words counter.most_common(50)为什么停用词过滤对毕业设计这么重要因为它直接影响可视化的第一观感。老师打开你的词云图如果看到的是满屏“真的”“今天”“还是”会觉得你的项目很业余反过来如果出现的是“感动”“青春”“回忆”“泪目”一眼就能看出这首歌曲的情感基调这本身就构成了你的分析结论。别小看这一步很多论文的“数据分析与讨论”章节核心论点就是从这些高频词里提炼出来的。3.2 用pyecharts排出六张核心图表可视化是整个项目里最讨好老师的一环但很多人做得不够好原因不外乎两类一类是只给静态图没交互、没联动另一类是图表类型选得不对明明想看分布却画了折线图。我的建议是做一个图表矩阵每个维度各司其职然后统一集成到Django页面里。分析维度图表类型说明评论时间趋势折线图观察歌曲发布后的热度变化点赞TOP10横向柱状图展示高赞评论内容高频词词云图直观呈现核心主题词情感分布饼图正面/负面/中性占比评论长度分布箱线图或直方图分析用户表达习惯用户活跃时段柱状图评论时间按小时聚合pyecharts的用法非常友好几个核心类就够覆盖以上所有图表配置项用链式写法。下面这段是点赞Top10横向柱状图的代码注意宽度、高度、主题色等配置要统一不然每个图表风格都不一样看起来像没做完。from pyecharts import options as opts from pyecharts.charts import Bar data df.nlargest(10, liked)[[user, liked, clean_content]] bar ( Bar() .add_xaxis(data[clean_content].apply(lambda x: x[:10] ...).tolist()) .add_yaxis(点赞数, data[liked].tolist()) .reversal_axis() .set_series_opts(label_optsopts.LabelOpts(positionright)) .set_global_opts(title_optsopts.TitleOpts(title高赞评论TOP10), xaxis_optsopts.AxisOpts(name点赞数)) ) bar.render(output/hot_comments.html)词云图单独说一句。pyecharts虽然是ECharts封装但词云功能得配合wordcloud库单独生成或者用pyecharts的WordCloud组件。用wordcloud库时最关键的是指定中文字体路径否则所有字都会变成方框。Windows上可以指定simhei.ttfLinux上可以用wqy-microhei.ttc。如果你在本地跑通以后要部署到服务器记得把字体文件也打包进去这是一个很容易被忽视的部署坑。3.3 前端可视化性能与美观的小经验数据量大了以后直接渲染会卡。比如一首歌抓了上万条评论如果Django直接把原始数据传到前端去画图和统计浏览器会卡到闪白。正确做法是在后端做聚合只把聚合结果交给前端。时间趋势图按月、按周或按小时聚合点赞榜只传Top10情感分布只传三个百分比这样前端数据量永远很小页面秒开。美观方面有一个快捷技巧pyecharts所有图表的背景色、主题色统一设置一次。答辩前把整套系统的配色调整为一致的深色调比如背景用#1e1e1e主色用青色或橙色录演示视频的时候画面会非常统一观感远胜于默认的白色背景加五颜六色图标。统计图表是演示的第一印象很少有人会花时间仔细读你的模型代码但大家都会扫一眼网页长什么样页面好不好看直接决定老师的第一判断。4. LSTM情感分析模型让机器判断评论是喜是悲4.1 训练数据从哪来怎么标注最省力LSTM是监督学习模型必须有带标签的数据才能训练。这里最大的难题不是建模而是标签从哪来。三种常见思路第一自己标注从清洗后的评论里随机抽1000到2000条人工标记为正面或负面第二使用开源语料做预训练典型的是酒店评论、电商评论、微博情感数据集用这些预训练后再用自己的歌曲评论做微调第三结合评论点赞数和内容特征做弱标签比如出现“笑死”“好听”归为正面“难听”“失望”归为负面但需要人工复核。我的建议是“开源语料预训练手工标注小数据集微调”两条腿走路。自己标注1000条这不仅是工作量也是你论文里能写“数据标注过程”这个章节的证据。开源语料可以让初始模型快速收敛手标数据则保证模型真正适应歌曲评论这种口语化文本。两部分合起来你训练集大概有两到三千条这个规模对LSTM来说已经够了。标注的时候要注意一致性规则。我自己定了三条包含明显褒义词、表达喜爱或回忆美好经历的算正面包含贬义词、吐槽、负面情绪的算负面剩下模棱两可的全部剔除不强行打标签。宁可数据少一点也不要标签质量差因为标签错了模型再训练也白搭。最终正负样本尽量均衡如果正面条数明显多可以通过欠采样或者给loss加权来缓解。4.2 文本预处理和词向量构建LSTM吃的是数值不是字符串。所以文本要先分词再映射成ID最后转成定长向量。分词工具还是用jieba接着把每个词映射到词表索引然后截断或补齐到固定长度max_len。歌曲评论普遍较短我实测max_len设为64就能覆盖绝大多数样本太长了反而浪费计算资源。词向量有两种做法。最简单的做法是用torch.nn.Embedding随机初始化然后让它在训练过程中自己学习词的语义词表大小设为5000到10000之间。另一种做法是加载腾讯开源的word2vec预训练词向量替换掉随机权重理论上效果会更好但需要额外下载文件、解析格式调试成本高一点。对毕设来说随机Embedding已经能出结果你可以把“用预训练词向量改进效果”写进论文的展望部分。下面这段是把文本转为ID序列的核心逻辑重点在于词表的构建与保存训练完以后预测新评论时要用同一个词表映射。import pickle from collections import Counter all_texts df[clean_content].tolist() vocab_counter Counter() for text in all_texts: for w in jieba.cut(text): vocab_counter[w] 1 vocab {w: i2 for i, (w, cnt) in enumerate(vocab_counter.items()) if cnt 2} vocab[PAD] 0 vocab[UNK] 1 def text_to_ids(text, max_len64): ids [] for w in jieba.cut(text): if w in vocab: ids.append(vocab[w]) else: ids.append(vocab[UNK]) if len(ids) max_len: return ids[:max_len] return ids [vocab[PAD]] * (max_len - len(ids))注意vocab的索引从2开始因为0和1必须留给和两个特殊token。这个细节非常重要如果从1开始把0也当成普通词模型训练时会把填充位置和真实词混在一起最后准确率莫名其妙地低。4.3 LSTM模型结构设计与训练过程模型结构其实很简单核心是Embedding层加LSTM层加全连接层。LSTM的作用可以这样理解评论是一个词接着一个词的序列LSTM能够维护一个内部状态一边读新词一边更新记忆当它读完整个句子时内部状态里就压缩了“这句话大致的情感倾向”。这比简单的词袋模型多了一个“顺序关系”所以它能捕捉“不是一般的难听”和“一般不是难听”这两种完全不一样的情感。我的模型设定是Embedding维度128LSTM隐藏层维度128层数2dropout设为0.5最后一层线性映射到2类。训练时使用Adam优化器初始学习率1e-3配合nn.utils.clip_grad_norm_做梯度裁剪避免RNN常见的梯度爆炸问题。import torch import torch.nn as nn class SentimentLSTM(nn.Module): def __init__(self, vocab_size, embed_size128, hidden_size128, num_layers2, num_classes2, dropout0.5): super().__init__() self.embedding nn.Embedding(vocab_size, embed_size, padding_idx0) self.lstm nn.LSTM(embed_size, hidden_size, num_layers, batch_firstTrue, dropoutdropout) self.fc nn.Linear(hidden_size, num_classes) self.dropout nn.Dropout(dropout) def forward(self, x): emb self.embedding(x) # (batch, seq_len, embed_dim) out, (hn, cn) self.lstm(emb) last_hidden hn[-1] # 取最后一层的最后时刻隐藏状态 out self.dropout(last_hidden) return self.fc(out)训练步骤用几行代码概括把数据切成batch进入模型计算交叉熵loss反向传播更新参数。需要重点说明的是我在优化器里加了weight_decay参数这就是L2正则化在PyTorch里的落地方式。很多同学在网上搜“深度学习l2正则化pytorch代码”其实答案就是optimizer torch.optim.Adam(model.parameters(), lr1e-3, weight_decay1e-5)。L2正则化的作用是约束权重不要长得太大配合dropout一起用能显著减少过拟合。optimizer torch.optim.Adam(model.parameters(), lr1e-3, weight_decay1e-5) loss_fn nn.CrossEntropyLoss() for epoch in range(30): model.train() for x_batch, y_batch in train_loader: optimizer.zero_grad() logits model(x_batch) loss loss_fn(logits, y_batch) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() # 每轮记录train_loss和val_acc训练完之后一定要保存模型和词表两个文件一个都不能少。我习惯把模型存成lstm_model.pth把词表存成vocab.pkl。预测新评论时的流程是加载词表分词映射成ID调用模型forward拿softmax后的概率判断正负。注意加载模型时要先实例化模型对象再load_state_dict而且vocab_size要和你训练时的词表大小保持一致否则加载会报错。4.4 模型效果分析与常见优化方案一组比较正常的指标是准确率85%到90%F1值0.83左右。如果你的准确率低于75%先检查训练集和验证集的标签是否合理再看词表构建是否正确最后再调参。歌曲评论里反讽、谐音梗、网络流行语特别多比如“这也太好听了吧”在大模型眼里可能是正面但在某些语境里是反话这种是LSTM的天然弱点很难彻底解决。想让模型更上一个台阶可以从三个方向入手。第一把LSTM换成双向LSTM或者GRU双向结构能同时看到词的前后信息对短文本分类有帮助代价是参数量翻倍。第二加入词性特征或表情符号特征比如评论里出现“”通常代表一种轻松或反讽的情绪可以把这些特征拼进LSTM的输入。第三直接引入BERT等预训练模型做对比实验用现成的中文预训练权重做微调准确率一般能超过LSTM五个点以上但这需要GPU论文里作为对比模型提一下就很加分。关于“如何调整多个loss间的比例”这个话题如果你的模型里不只有情感分类还有辅助任务比如同时预测评论是否为疑问句、是否含负面词那就会有两个loss。最简单的方案是把两个loss相加高级一点可以给每个loss分配可学习的权重让网络自己学出各任务的重要程度。但毕业设计阶段一个交叉熵loss就够了多任务设计放在论文讨论部分更合适不要一开始就把系统复杂度抬上去。5. Django整合把爬虫、图表、模型包成一个能演示的系统5.1 Django项目结构和基础配置Django在这个项目里的定位是“展示壳”它的职责是把前面所有成果装进一个Web界面里。项目结构用官方脚手架就能生成关键是别把所有代码堆在一个文件里。我的目录结构大致是这样的music_analysis/ ├── manage.py ├── analysis/ # 主应用 │ ├── views.py # 视图函数 │ ├── urls.py # 路由 │ ├── models.py # 数据库模型可保留空模型 │ ├── templates/ # HTML模板 │ └── static/ # 静态文件js/css/图片 ├── crawler/ # 爬虫与数据处理脚本 ├── ml_model/ # LSTM模型与词表 └── output/ # pyecharts生成的HTML图表settings.py里要配置三件事把analysis注册进INSTALLED_APPS配置templates路径配置static静态文件路径。数据库直接用默认的SQLite就行不需要装MySQL因为主要数据用CSV文件读取SQLite只是用来保存歌曲信息和分析结果。需要注意的是Django版本和Python版本对应关系Django 3.2配合Python 3.8到3.10都没有问题如果遇到runserver启动报错先看版本对不对。5.2 核心页面与视图逻辑首页面板、歌曲详情、情感预测页我设计了三个核心页面。首页是数据总览显示歌曲总数、评论总数、正负情感占比以及一张评论时间趋势图歌曲详情页展示选中的歌曲的评论Top10、词云和情感分布情感预测页是一个带输入框和按钮的页面用户输入一句评论后端调用LSTM模型输出情感概率。视图逻辑并不复杂关键是把数据准备好再传给模板。以情感预测为例前端表单POST提交后Django视图接收文本调用模型预测函数返回正面概率和负面概率模板里直接渲染两个数字和一个动态进度条。代码大致长这样import torch import pickle from django.shortcuts import render _model None _vocab None def load_model(): global _model, _vocab if _model is None: _vocab pickle.load(open(ml_model/vocab.pkl, rb)) _model SentimentLSTM(vocab_sizelen(_vocab)) _model.load_state_dict(torch.load(ml_model/lstm_model.pth, map_locationcpu)) _model.eval() return _model, _vocab def predict_view(request): if request.method POST: text request.POST.get(comment, ) text_ids text_to_ids(text, max_len64) with torch.no_grad(): logits model(torch.tensor([text_ids])) probs torch.softmax(logits, dim-1).numpy()[0] return render(request, predict.html, { text: text, positive: round(float(probs[1]), 4), negative: round(float(probs[0]), 4) }) return render(request, predict.html)这里最大的坑是模型加载。千万不要在视图函数里每请求一次就load一次模型否则页面响应会慢到你怀疑人生。我的办法是用模块级全局变量加懒加载第一次请求时加载后续请求直接复用内存里的模型对象。这个细节在答辩时被问“你的模型是怎么和Web结合的”时可以很骄傲地讲出来。5.3 模板渲染图表与静态文件处理pyecharts生成的HTML文件本质上是完整的独立页面最简单粗暴也最稳定的嵌入方式是用iframe。把output目录里的hot_comments.html放到服务器可以访问的路径下模板里写iframe src/static/output/hot_comments.html width100% height500/iframe注意iframe的src要指向能被Django静态文件服务处理的路径也就是把output目录放到static目录下或者在urls里专门加一条静态文件路由否则页面会是404。我踩过一次这个坑本地文件能用上到Django里怎么都打不开最后发现是静态文件路径没配好。除了iframe也可以用pyecharts的render_embed方式直接嵌入HTML代码但那样代码会比较乱大图表嵌入后模板文件会非常庞大不推荐。模板里还需要注意一个Django特性当你要输出后端传来的JavaScript配置变量时必须加safe过滤器否则Django会转义掉所有引号导致图表JS直接报错。前端渲染的饼图如果突然白屏八成就是这个原因。5.4 答辩演示的技巧和注意事项答辩现场最怕的不是模型训练不好而是演示流程翻车。我的经验是提前准备好一套固定的演示路径启动Django打开首页翻到歌曲详情页切换几个图表到预测页输入两句评论一句明显正面、一句明显负面分别看模型输出。整个流程控制在五分钟以内不要现场爬数据爬虫脚本提前跑好数据已经在库里了现场只展示运行日志即可。演示环境一定要在自己的笔记本上跑通过再说。很多同学习惯在开发环境用runserver到答辩当天临时换电脑或者换网络各种依赖缺失、路径不对二十分钟都没启动起来。建议答辩前一晚把虚拟环境、依赖清单、数据文件、模型文件全部检查一遍最好用一个干净的requirements.txt在你答辩用的那台机器上重新装一遍所有依赖确保从零环境也能跑起来。6. 从零到一实施路线与高频问题排查6.1 推荐8周实施路线毕设项目最怕最后两周一赶代码是临时拼的论文是凑的答辩没底气。我给一个比较均衡的8周计划适合同时还要上课、实习的同学参考周数任务里程碑第1周环境搭建跑通requests请求和目标站点的评论接口能在命令行抓取一页评论第2周实现评论分页采集、数据清洗落盘CSV获得3000条以上干净评论第3周完成分词、词频统计和六张核心图表图表HTML文件生成第4周标注情感数据构建词表得到1500条以上训练样本第5周训练LSTM模型调整参数准确率达到85%以上第6周Django项目搭建首页与详情页集成图表系统可以浏览第7周实现情感预测页打磨交互和样式全部功能跑通第8周论文撰写、录制演示视频、准备答辩完整交付这里要特别说明标注数据的第4周看起来工作量不大但实际上非常枯燥。我建议你从第2周拿到数据之后就开始随手标注每次标50条一周下来自然就攒够了不要等第4周集中做那个时候你已经被分词和图表搞得头大了容易敷衍。6.2 高频问题排查速查表这个项目我前前后后调试了将近一个月踩过的坑都整理在下面这张表里。遇到了问题先对照排查大概率能省下一下午时间。问题现象可能原因解决方案评论接口返回错误码请求头缺失、Cookie过期浏览器里重新复制一次完整请求模板CSV用Excel打开乱码编码用了utf-8改为utf-8-sig保存词云图显示方框缺少中文字体指定simhei.ttf或wqy-microhei.ttcLSTM的loss不下降学习率不合理或词表映射错误把lr调到1e-3检查0和1是否被占用模型过拟合训练准确率高、验证差数据少、模型大增加dropout加weight_decay减小隐藏层Django模板图表空白iframe路径错误或静态文件没配检查output目录是否在static下predict页面响应很慢每次请求都加载模型用模块级全局变量只在首次加载数据库没有数据没有把CSV导入提前写好数据导入脚本先导入再启动系统6.3 论文和答辩里可以深入展开的技术点最后聊一下怎么把这个项目写出深度。除了基本功能之外有四个技术点可以作为论文的创新点或讨论点展开第一评论接口的参数加密设计你可以从“前端安全设计与反爬策略”的角度分析这部分内容可以引出“如何在前端防止爬虫、防止查看页面源码”等安全话题站在应用安全的角度写论文里的相关研究背景但要注意只做技术分析和合规学习不讨论任何绕过手段第二LSTM和BERT在短文本情感分类上的效果对比哪怕你只跑了LSTM也可以用公开数据上BERT的基准结果做对比第三评论文本的时序特征把每条评论的时间戳和情感得分结合画出“歌曲口碑时间线”这个想法比较新颖而且不增加太多开发量第四数据增强解决小样本问题对歌曲评论做同义词替换、随机删除、随机交换等操作扩大训练集这些都属于深度学习模型训练里的常规操作写出来既是工作量也是加分项。项目做到最后模型代码、爬虫脚本、Web页面是三个看得见的交付物但真正值钱的是你在这个过程中建立起来的一条“数据到价值的完整认知”。爬虫只是起点分析才是核心LSTM只是工具关键在于你有没有把数据讲成一个有逻辑的故事。我个人做完这个项目的体会是最花时间的不是LSTM公式也不是爬虫代码本身而是数据清洗和前后端联调。评论里混杂表情符、英文梗、谐音梗清洗规则一遍遍改图表数据格式对不上浏览器打开一片空白这些都是正常的。遇到问题就按接口返回逐层排查不要急躁。如果学有余力把LSTM换成BERT做一组对比实验或者把评论时间属性和情感得分结合成一条“歌曲口碑时间线”曲线这个项目完全可以再往深走一步。不过在毕业设计阶段先把爬虫数据真真实实拿到手、把模型效果量化出来、把Django页面完整串起来已经能拿到一个相当不错的成绩。最后分享一个小技巧答辩前把pyecharts所有图表统一成深色主题页面观感会立刻提升一个档次老师点开系统的第一眼印象也会好很多。

Python爬虫+LSTM歌曲评论情感分析与Django可视化系统

相关推荐

第三次实验作业分水岭：像做项目一样拆解与执行

ASP+Access库存管理系统源码解析：从环境搭建到踩坑避坑

2026年6大MaaS平台开发者体验横评：TaoToken统一Key接入实测谁最适合你的AI项目？

更多资讯

Hadoop MapReduce伪分布式实战：从WordCount到避坑指南

DeepSeek八大行业调参实战：从医疗到制造的参数链路与避坑指南

Win10 F1/F2/F3音量键失灵的底层原因与修复方案

瑞芯微RK3588开发实战：资料获取与软硬件调试全攻略

RibbonWorkbench 可视化编辑 Dynamics 365 命令栏实战指南

NeurIPS时间序列论文解读：基础模型、上下文学习与VLM成主流

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

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

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

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

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