每年到这个时间点总有学弟学妹拿着差不多的题目来问我能不能用 Python 做弹幕情感分析能不能把大模型接进去能不能再加一个推荐系统和一个可视化大屏凑成一整套毕业设计。说实话这种题目现在很常见但能把每个模块真正打通的人并不多。我前前后后帮人调过不少类似的项目也踩过不少坑这篇就把 Python PySpark DeepSeek-R1 这套从数据处理、情感判断、视频推荐到可视化大屏的完整思路写透重点是讲清楚每一步为什么要这么干以及哪些地方不是你照着教程敲就能跑通的。如果你正在准备大数据方向的毕设或者想自己做一个 B 站弹幕情感分析相关的项目练手这篇文章可以直接当作选型和架构参考。它面向的不是那种只想交个报告的同学而是真的想把项目做完整、能上线演示、能扛住答辩追问的人。1. 为什么偏要选 PySpark DeepSeek-R1 这对组合1.1 选题背后真正的加分点是什么先聊一个很实际的问题B 站弹幕情感分析这个题目每年都有人做为什么有的人答辩能拿优有的人被当成普通增删改查项目差距不在情感分析这四个字而在你选择的技术栈能不能讲出完整的逻辑闭环。单纯用 Python 爬几万条弹幕再用 SnowNLP 或者 jieba 情感词典算个正负面得分这套东西太老了老师基本看一眼就知道是套模板。而这几年大模型、大数据框架恰好是热点把 PySpark 和 DeepSeek-R1 接进来本质上是给传统项目加了两个新的叙事层级一个是海量弹幕的分布式预处理一个是大模型驱动的情感判断。这两个词放进论文摘要里分量完全不同。但这里有个关键认知毕设不是越重越好而是要让每个组件都服务一个明确的业务问题。PySpark 不是为了显得高大上而硬加的它处理的是弹幕这种高并发、短文本、海量日志型数据的清洗和特征工程DeepSeek-R1 解决的则是传统情绪词典在讽刺、玩梗、反语面前几乎失效的难题。1.2 PySpark 在这个项目里的真实定位B 站弹幕的真实体量有多大一个热门视频可能就有几十万条弹幕全站热门视频加起来几千万甚至上亿条。用 Pandas 直接读 CSV 做处理内存十几 G 的笔记本直接卡死这就是 PySpark 的用武之地。PySpark 的核心是懒加载和分布式计算。你在代码里写df.filter(...)、df.withColumn(...)时它并不是立刻执行而是构建一个执行计划等到最终触发collect()、count()或者write时才真正跑。这意味着你可以用写单机 Pandas 的方式写出能横向扩展的数据处理代码。另一个实际好处是 PySpark 自带的pyspark.sql.functions里有大量针对文本处理的内置函数比如split、explode、regexp_replace、window时间窗口聚合清洗弹幕这种带时间戳、带用户名、带各种特殊符号的数据比用循环一次次处理干净得多。1.3 DeepSeek-R1 为什么适合做情感判断传统情感分析工具的问题用一句话概括就是它们不理解语境。这波操作我真的会谢——这句话按字面看是正向的实际在 B 站语境里九成是在吐槽。DeepSeek-R1 这类大模型对中文互联网用语的理解能力尤其是对反讽、缩写、流行梗的把握远超词典匹配和小规模微调模型。我自己的测试体验是把弹幕原文丢给 DeepSeek-R1让它输出{「情感倾向」: 「负面」, 「情感强度」: 0.8, 「原因」: 「...」}这样的结构化结果准确率比我之前用微调 BERT 高不少而且最难得的是它能在判断情感的同时给出理由这对毕设论文里的案例分析章节非常有用因为你终于能拿出具体的模型推理依据了。用一句话总结选型逻辑PySpark 负责管好数据DeepSeek-R1 负责读懂人心前面是大数据后面是 AI两个计算机毕设最愿意看到的关键词都占住了而且它们之间有个明确的数据流向关系不是硬拼盘。2. 弹幕数据的获取、清洗与存储2.1 弹幕从哪里来怎么拿得合法合理这里先说一个原则性问题。B 站弹幕获取优先考虑官方开放平台接口其次是一些研究机构放出的公开数据集。千万、千万不要大规模并发爬取全站这不光涉及平台风控放在论文里也不好看。答辩老师问到数据来源时你说通过官方开放接口获取并过滤掉明显隐私信息比我自己写爬虫爬了 100 万条体面得多。我这里给一个简单的弹幕获取思路B 站有公开的弹幕接口可以通过视频的 cid 参数拼出 XML 地址弹幕是量级很大的短文本里面每条有出现时间、弹幕模式、用户 hash、正文内容。拿到之后第一步不是分析而是落盘。建议直接用 PySpark 读进来以视频 ID 弹幕日期做分区存成 Parquet 格式后面每次处理都会感谢自己这个决定。2.2 弹幕里的脏数据比起普通文本要麻烦得多看几万条弹幕后你会有一个体会弹幕不是给人看的文本而是带着情绪的碎片化数据流。清洗阶段至少要解决这几个问题空弹幕与纯符号弹幕比如hhhhh、23333、这类对情感分析是噪声需要过滤掉。用户与链接很多弹幕会 某个 up 主带上网址和特殊指令需要正则替换。刷屏冗余同一个用户在短时间内反复发同样的内容应该做去重否则会影响情感标签的比例分布。繁体与异体字弹幕里有大量粤语、繁体甚至故意反写的字尽量先做一次统一的文本规范化。清洗操作全部写成一个 PySpark pipeline我贴一段关键结构给你参考from pyspark.sql import SparkSession from pyspark.sql.functions import col, regexp_replace, trim, length, lower spark SparkSession.builder.appName(bilibili_danmaku_etl).getOrCreate() df spark.read.format(parquet).load(hdfs:///data/danmaku/raw) df_clean df.filter(col(content).isNotNull()) \ .filter(col(content).cast(string).rlike([\u4e00-\u9fa5])) \ .withColumn(content, lower(col(content))) \ .withColumn(content, regexp_replace(col(content), \\S, )) \ .withColumn(content, regexp_replace(col(content), https?://\\S, )) \ .filter(length(col(content)) 2) \ .dropDuplicates([video_id, user_hash, content]) df_clean.write.mode(overwrite) \ .partitionBy(video_id, dt) \ .format(parquet) \ .save(hdfs:///data/danmaku/clean)这里有一个新手特别容易踩的坑dropDuplicates的去重粒度。如果只对弹幕正文去重会误删大量正常的重复表达比如哈哈哈哈和哈哈哈哈哈被当成同一条。一定要带上video_id和user_hash甚至最好再加上一个时间窗口做判断比如 10 秒内同一个人发的相同弹幕只保留第一条。2.3 时间窗口切分关系到后面所有分析的粒度清洗之后弹幕数据必须切时间窗口。B 站弹幕自带出现时间以视频播放的第几秒为基准这个时间戳是整个项目里最值得挖掘的维度。如果你只用全部弹幕加总来算情感那就把一个很有层次的数据集做成了平面数据。我的建议是做一个视频片段情感时序特征把每个视频按 30 秒或 60 秒切成时间片计算每个时间片内的弹幕情感均值、弹幕密度和热词。这样后面做推荐系统时视频和视频之间的相似度可以基于情感分布曲线来计算比单纯算一个平均分丰富得多。这部分最好也在 PySpark 里做窗口聚合。伪代码如下from pyspark.sql.window import Window from pyspark.sql.functions import floor, avg, count, collect_list w Window.partitionBy(video_id).orderBy(second) df_window df_clean.withColumn( time_slice, floor(col(second) / 30) * 30 ) # 每 30 秒一个切片 df_agg df_window.groupBy(video_id, time_slice) \ .agg( count(*).alias(danmaku_cnt), avg(sentiment_score).alias(avg_sentiment), collect_list(content).alias(slice_text_list) )这里再把别强调一次PySpark 的groupBy是 shuffle 操作如果数据量只有几千条感受不到问题但如果你真想用几十万条弹幕做窗口聚合分区键的选择、文件大小都会影响速度。毕设数据量下不用太焦虑但论文里最好提一句分区策略是影响 Spark 任务执行效率的关键因素显得你懂原理。3. DeepSeek-R1 接入情感判断的三种可行方式3.1 三种接入方式的对比真正动手接大模型时你会发现情感分析这个需求可以拆成很多层不同层级的做法成本差别很大。我把实际可行的三条路径列出来你可以根据自己手上的显卡资源和预算去选方案准确性成本技术亮点适合场景调用大模型云 API高按 token 计费毕设规模几十块内实现简单跑通快需要稳定出结果、时间紧的同学本地部署蒸馏版 R1 模型高需要 16G 以上显存或量化版本展示工程能力完全离线机器配置好想体现部署能力大模型标注 蒸馏训练小模型较高需要训练时间体现模型微调能力可作为论文创新点想深入做学术方向三条路线不冲突甚至可以串联先用方案一给一部分数据打标签再去微调一个小的文本分类模型做批量推理大模型变成了你的标注老师这就是目前工业界很流行的大模型蒸馏思路。3.2 设计一个能稳定输出结构化情感的 Prompt不管选哪条路线你都要面对一个问题DeepSeek-R1 不是天生就按你需要格式回答的。如果你直接把弹幕扔给它问这句话是正面还是负面它可能回你一整段分析文字导致下游没法接。我的做法是写一个严格约束输出格式的 Prompt下面是一个可以直接拿来用的模板你是一个擅长中文互联网弹幕文化的情感分析专家。 请判断下面这条弹幕的情感倾向。 要求 1. 只输出 JSON不要输出任何多余文字。 2. JSON 包含三个字段 - sentiment: 只能取 positive、neutral、negative - intensity: 一个 0 到 1 之间的小数代表情感强度 - reason: 一句话说明你判断的依据不超过 20 字 弹幕内容这里放入弹幕文本实际调用时文本拼接可以用 Python 的 f-string或在大模型 API 的 messages 里构造成 system user 格式。记得把 temperature 调到 0.2 以下情感分析这种任务不希望模型太有创造力。temperature 太高同一个句子跑三次可能得出三种不同结果这在毕设里是致命的评委只需要抽十条检查就会发现不稳定。3.3 批量推理的并发控制与断点续跑弹幕是批量的API 调用是有并发限制的。这块看起来简单真写好代码的人不多。我建议你这样处理把清洗好的弹幕数据用一个自增 id 标记。分批调用每批 20-50 条根据 API 限流调整。跑完一批就把结果 append 到本地 JSONL 文件同时记录处理到的批次号。万一中断了下次从断点继续不需要重新跑。示例代码片段import json import time def run_batch(df_iter, batch_size50): results [] for i, text in enumerate(df_iter): result call_llm(text) # 调用 DeepSeek-R1 API results.append({text: text, label: result}) if (i 1) % batch_size 0: save_to_jsonl(results) results [] time.sleep(1) # 控制请求速率这个模块值得在论文里单独开一节因为它是传统大数据处理和大模型 API 接入之间的桥梁也是很多团队实际落地时最头疼的稳定性问题。你能把这个讲清楚答辩老师基本就会认可你不是只跑通了 Demo。3.4 情感判断质量怎么核验模型标注完不等于完事了你得抽检。我的习惯是每个视频随机抽 50 条带上预测结果人工过一遍算一个简单的人工一致率。如果一致率能到 90% 以上说明情感判断这个环节是可靠的可信工具如果只有 70% 多那就要检查 Prompt或者把可能不是情感表达的弹幕先过滤掉比如纯刷屏的哈哈哈哈其实很难说清是不是正向情感这类就归到 neutral 里不要硬分。这里还有一个值得写进论文的经验情感分不一定要用三分类可以做一个连续分数。比如把 negative 记作 -1neutral 记作 0positive 记作 1再乘以 intensity 作为强度权重最后算每个视频的情感总分。连续分数比离散标签的区分度高很多尤其在推荐系统排序阶段两个视频可能一个 0.8 一个 0.2如果只是积极/消极两个档位就很难排序。4. 从弹幕情感分布到视频推荐策略4.1 视频推荐为什么能用到情感信号B 站推荐大家都很熟做毕设时不需要跟抖音那种量级的产品比但基本的推荐思路必须讲清楚。传统推荐看的是用户看了什么和视频内容主题的匹配情感分析能额外提供给推荐系统一层信号这个视频让人看完后的情绪体验是什么。你想一下用户 A 喜欢看那种让人热血沸腾的视频用户 B 喜欢睡前看治愈系内容。他们可能都看手工类视频但一个希望看到手艺人极限挑战一个是想听安静的木工制作过程。如果只按内容和类目推荐两个用户会收到几乎一样的结果。可一旦把弹幕情感加入画像视频之间的差异就分开了。4.2 视频情感画像与用户情感倾向每个视频可以表示成一个情感分布向量。比如把弹幕分成几个情感类别开心、感动、愤怒、惊讶、无感统计每个类别的占比这个视频就有一个五维或六维的情感向量。对应的用户看完一个视频后我们可以把该视频的情感向量按一定衰减系数累加到用户向量上。用户看得越多他的情感偏好画像越清晰。这里有个不错的细节观看行为本身是用户希望获得这种情感体验的隐含反馈信号。4.3 推荐算法不是越复杂越好很多毕设同学一上来就想写 DeepFM、写 Graph Embedding我的建议是千万别给自己挖坑。推荐系统的核心逻辑讲清楚效果演示起来说得通就够了。我实际采用的策略是两层混合第一层是候选召回根据视频类别、标签做粗筛筛出 100 个可能相关的视频。第二层是精细排序计算用户情感向量与候选视频情感向量的余弦相似度结合一个基础热度分播放量、弹幕量、近期互动加权求和得到最终排序分。排序公式大概是这样score 0.4 * similarity(user_vector, video_vector) 0.3 * popularity_score 0.3 * freshness_score权重大小可以自己拿几组数据调论文里给出一张不同权重下的推荐结果对比表就很有说服力。这种设计的好处是你能在 PPT 上画一个清晰的流程图每一步都解释得清不装深奥。4.4 冷启动问题怎么解决新视频没有弹幕情感向量全为零怎么推荐我的兜底方案很简单先用视频标题和简介做一次关键词级的粗粒度情感预测等弹幕积累到 200 条以上再切回弹幕情感画像。你可以在系统设计里把 200 条作为阈值这也体现了你考虑了数据生命周期。再看用户侧冷启动新用户没有观看历史推荐什么这时候直接推荐当日整体情感倾向正向且热度高的视频相当于把大家都觉得好的先推给你然后再逐步个性化是一个合理的默认策略。5. 可视化大屏的实现数据链路、图表布局与性能5.1 先想清楚大屏要展示什么可视化大屏在这个毕设里是个加分项但也特别容易做成花瓶。我见过太多人把几个 ECharts 图表拼在一起就说自己做了一个大屏内容之间毫无逻辑。大屏的核心不是炫而是让人一眼看懂全站视频情感态势。我做大屏时只保留五个核心指标总监控视频数、弹幕总量、参与用户数头部概览弹幕情感趋势曲线按时间片聚合看整体情绪变化情感分布饼图或环形图积极/中性/消极占比弹幕高频热词 Top20词云用于观察大家到底在聊什么好评榜 / 争议榜视频 Top10列表点击可看详情这五个指标覆盖了全貌、趋势、结构、内容、案例五个视角是一个完整的数据叙事。你可以在这个框架上加东西比如地图如果弹幕能定位到省份或者实时滚动的弹幕流但不要砍掉这五个。5.2 前端只把数据接起来别自己造轮子前端用 ECharts 就够了不需要上 Vue Element Plus 全家桶也行但如果你已经熟悉 Vue用它组织图表组件更舒服。我建议架构是PySpark 处理完数据后把聚合结果导出成 JSON 或写入 MySQL。FastAPI 写几个只读接口返回video_trend、sentiment_ratio、hot_words这些 JSON。Vue 页面用axios定时轮询接口再用 ECharts 渲染图表。有人问我为什么不用 WebSocket 做实时推送。道理很简单你的汇总数据是批处理算出来的本身就有一个刷新周期用 WebSocket 反而把简单的事搞复杂了。轮询 30 秒一次完全够用。这里想做得更专业一点可以在后端加一个简单的缓存字典接口被多次请求时不会重复查库性能会好看很多。5.3 大屏上最容易被发现的细节问题有几个小细节你必须提前处理否则演示现场会很尴尬图表刷新时闪动ECharts 的setOption里尽量保证 series 的 data 结构一致不要让图表先清空再填数据。level 的误差很多弹幕的情感强度用小数表示在大屏上要限制保留两位小数否则一排 0.800000001 会很掉价。空数据兜底某个视频没有弹幕时后端接口应该返回一个明确的空结构而不是把字段设为 null前端要做成暂无数据。轮询失败重试后端服务偶尔抖动前端最好做一个 3 次失败后的提示而不是一直转圈。6. 毕设答辩现场最容易被追着打的五个问题6.1 你的数据有多少这个量级真的需要 Spark 吗这是最常见的送命题。别慌回答的关键在于分布式框架解决了什么问题而不是我的数据量有多大。你可以这样答单机确实能处理几万条弹幕但毕设的数据链路设计始终以扩展到全站百万级弹幕为目标。PySpark 在这个项目中的核心意义不只是计算而是提供了一种标准化的分布式 ETL 框架使得弹幕分析可以平稳地从单个视频扩展到多个分区、多个时间片。这样一来将来接入增量数据不需要推翻重写。这个回答展示的是工程思维而不是数据体量攀比。6.2 DeepSeek-R1 的误判你怎么处理先承认大模型不是 100% 准确再说你做了人工抽检和兜底策略。你可以直接给数据随机抽取了 500 条弹幕人工比对一致性达到 91%对不确定的样本统一归类到中性避免强分带来的误差。这个逻辑严谨老师挑不出毛病。6.3 你的推荐效果怎么评估如果你没有做 AB 测试的环境就做离线模拟。把用户的历史观看记录按时间切成训练集和测试集用前 80% 的时间训练用户画像后 20% 的时间作为预测目标看推荐结果里有没有命中用户实际观看的视频。给出一个命中率比如 Top20 命中率约 35%就足以支撑你的推荐系统有效性结论。6.4 可视化大屏是实时数据还是离线数据老老实实说是准实时离线批处理 定时刷新。不要硬吹自己是实时很容易被追问细节。你可以解释弹幕积累本身有延迟情感分析任务是大模型推理对计算资源要求高工业界普遍采用分钟级或小时的批量处理而不是事件级实时。这句工业界也这样处理很管用。6.5 哪些代码是你自己写的这个问题考验真实性。大模型 API、开源 ECharts、甚至 PySpark 库确实都不是你自己写的但你要说清楚你做的工作是基于这些基础能力的系统设计与集成包括数据 Pipeline 的编排、情感分析 Prompt 的迭代优化、推荐排序策略的权重设计、数据链路的异常处理。这些都是实实在在的工程贡献。7. 做完这一整套我自己的几点体会这个项目做完我最深的感触是大模型接入大数据分析时真正的工程量往往不在模型本身而是在数据清洗、格式约束、批量并发和结果校验这些不性感的环节。弹幕情感分析看起来只是给文本贴个标签但它前面连着的是分布式数据管道后面连着的是推荐系统和可视化故事线你每往前走一步都会遇到一个设计决策而每个决策都需要你有自己的判断依据。如果你时间紧张我建议你优先保证数据清洗 情感判断 可视化大屏这条主线闭环这是项目演示效果最好的部分。推荐系统可以做得简单但必须有评估没有评估的推荐系统在论文里是一堆无根之木。最后再分享一个实用的小技巧所有情感分析结果和推荐结果都额外存一份带run_time字段的版本快照这样答辩时可以说该项目支持不同实验参数的离线对比分析一句轻描淡写的话含金量比吹十个特性都高。
Python+PySpark+DeepSeek-R1实现弹幕情感分析与推荐系统
每年到这个时间点总有学弟学妹拿着差不多的题目来问我能不能用 Python 做弹幕情感分析能不能把大模型接进去能不能再加一个推荐系统和一个可视化大屏凑成一整套毕业设计。说实话这种题目现在很常见但能把每个模块真正打通的人并不多。我前前后后帮人调过不少类似的项目也踩过不少坑这篇就把 Python PySpark DeepSeek-R1 这套从数据处理、情感判断、视频推荐到可视化大屏的完整思路写透重点是讲清楚每一步为什么要这么干以及哪些地方不是你照着教程敲就能跑通的。如果你正在准备大数据方向的毕设或者想自己做一个 B 站弹幕情感分析相关的项目练手这篇文章可以直接当作选型和架构参考。它面向的不是那种只想交个报告的同学而是真的想把项目做完整、能上线演示、能扛住答辩追问的人。1. 为什么偏要选 PySpark DeepSeek-R1 这对组合1.1 选题背后真正的加分点是什么先聊一个很实际的问题B 站弹幕情感分析这个题目每年都有人做为什么有的人答辩能拿优有的人被当成普通增删改查项目差距不在情感分析这四个字而在你选择的技术栈能不能讲出完整的逻辑闭环。单纯用 Python 爬几万条弹幕再用 SnowNLP 或者 jieba 情感词典算个正负面得分这套东西太老了老师基本看一眼就知道是套模板。而这几年大模型、大数据框架恰好是热点把 PySpark 和 DeepSeek-R1 接进来本质上是给传统项目加了两个新的叙事层级一个是海量弹幕的分布式预处理一个是大模型驱动的情感判断。这两个词放进论文摘要里分量完全不同。但这里有个关键认知毕设不是越重越好而是要让每个组件都服务一个明确的业务问题。PySpark 不是为了显得高大上而硬加的它处理的是弹幕这种高并发、短文本、海量日志型数据的清洗和特征工程DeepSeek-R1 解决的则是传统情绪词典在讽刺、玩梗、反语面前几乎失效的难题。1.2 PySpark 在这个项目里的真实定位B 站弹幕的真实体量有多大一个热门视频可能就有几十万条弹幕全站热门视频加起来几千万甚至上亿条。用 Pandas 直接读 CSV 做处理内存十几 G 的笔记本直接卡死这就是 PySpark 的用武之地。PySpark 的核心是懒加载和分布式计算。你在代码里写df.filter(...)、df.withColumn(...)时它并不是立刻执行而是构建一个执行计划等到最终触发collect()、count()或者write时才真正跑。这意味着你可以用写单机 Pandas 的方式写出能横向扩展的数据处理代码。另一个实际好处是 PySpark 自带的pyspark.sql.functions里有大量针对文本处理的内置函数比如split、explode、regexp_replace、window时间窗口聚合清洗弹幕这种带时间戳、带用户名、带各种特殊符号的数据比用循环一次次处理干净得多。1.3 DeepSeek-R1 为什么适合做情感判断传统情感分析工具的问题用一句话概括就是它们不理解语境。这波操作我真的会谢——这句话按字面看是正向的实际在 B 站语境里九成是在吐槽。DeepSeek-R1 这类大模型对中文互联网用语的理解能力尤其是对反讽、缩写、流行梗的把握远超词典匹配和小规模微调模型。我自己的测试体验是把弹幕原文丢给 DeepSeek-R1让它输出{「情感倾向」: 「负面」, 「情感强度」: 0.8, 「原因」: 「...」}这样的结构化结果准确率比我之前用微调 BERT 高不少而且最难得的是它能在判断情感的同时给出理由这对毕设论文里的案例分析章节非常有用因为你终于能拿出具体的模型推理依据了。用一句话总结选型逻辑PySpark 负责管好数据DeepSeek-R1 负责读懂人心前面是大数据后面是 AI两个计算机毕设最愿意看到的关键词都占住了而且它们之间有个明确的数据流向关系不是硬拼盘。2. 弹幕数据的获取、清洗与存储2.1 弹幕从哪里来怎么拿得合法合理这里先说一个原则性问题。B 站弹幕获取优先考虑官方开放平台接口其次是一些研究机构放出的公开数据集。千万、千万不要大规模并发爬取全站这不光涉及平台风控放在论文里也不好看。答辩老师问到数据来源时你说通过官方开放接口获取并过滤掉明显隐私信息比我自己写爬虫爬了 100 万条体面得多。我这里给一个简单的弹幕获取思路B 站有公开的弹幕接口可以通过视频的 cid 参数拼出 XML 地址弹幕是量级很大的短文本里面每条有出现时间、弹幕模式、用户 hash、正文内容。拿到之后第一步不是分析而是落盘。建议直接用 PySpark 读进来以视频 ID 弹幕日期做分区存成 Parquet 格式后面每次处理都会感谢自己这个决定。2.2 弹幕里的脏数据比起普通文本要麻烦得多看几万条弹幕后你会有一个体会弹幕不是给人看的文本而是带着情绪的碎片化数据流。清洗阶段至少要解决这几个问题空弹幕与纯符号弹幕比如hhhhh、23333、这类对情感分析是噪声需要过滤掉。用户与链接很多弹幕会 某个 up 主带上网址和特殊指令需要正则替换。刷屏冗余同一个用户在短时间内反复发同样的内容应该做去重否则会影响情感标签的比例分布。繁体与异体字弹幕里有大量粤语、繁体甚至故意反写的字尽量先做一次统一的文本规范化。清洗操作全部写成一个 PySpark pipeline我贴一段关键结构给你参考from pyspark.sql import SparkSession from pyspark.sql.functions import col, regexp_replace, trim, length, lower spark SparkSession.builder.appName(bilibili_danmaku_etl).getOrCreate() df spark.read.format(parquet).load(hdfs:///data/danmaku/raw) df_clean df.filter(col(content).isNotNull()) \ .filter(col(content).cast(string).rlike([\u4e00-\u9fa5])) \ .withColumn(content, lower(col(content))) \ .withColumn(content, regexp_replace(col(content), \\S, )) \ .withColumn(content, regexp_replace(col(content), https?://\\S, )) \ .filter(length(col(content)) 2) \ .dropDuplicates([video_id, user_hash, content]) df_clean.write.mode(overwrite) \ .partitionBy(video_id, dt) \ .format(parquet) \ .save(hdfs:///data/danmaku/clean)这里有一个新手特别容易踩的坑dropDuplicates的去重粒度。如果只对弹幕正文去重会误删大量正常的重复表达比如哈哈哈哈和哈哈哈哈哈被当成同一条。一定要带上video_id和user_hash甚至最好再加上一个时间窗口做判断比如 10 秒内同一个人发的相同弹幕只保留第一条。2.3 时间窗口切分关系到后面所有分析的粒度清洗之后弹幕数据必须切时间窗口。B 站弹幕自带出现时间以视频播放的第几秒为基准这个时间戳是整个项目里最值得挖掘的维度。如果你只用全部弹幕加总来算情感那就把一个很有层次的数据集做成了平面数据。我的建议是做一个视频片段情感时序特征把每个视频按 30 秒或 60 秒切成时间片计算每个时间片内的弹幕情感均值、弹幕密度和热词。这样后面做推荐系统时视频和视频之间的相似度可以基于情感分布曲线来计算比单纯算一个平均分丰富得多。这部分最好也在 PySpark 里做窗口聚合。伪代码如下from pyspark.sql.window import Window from pyspark.sql.functions import floor, avg, count, collect_list w Window.partitionBy(video_id).orderBy(second) df_window df_clean.withColumn( time_slice, floor(col(second) / 30) * 30 ) # 每 30 秒一个切片 df_agg df_window.groupBy(video_id, time_slice) \ .agg( count(*).alias(danmaku_cnt), avg(sentiment_score).alias(avg_sentiment), collect_list(content).alias(slice_text_list) )这里再把别强调一次PySpark 的groupBy是 shuffle 操作如果数据量只有几千条感受不到问题但如果你真想用几十万条弹幕做窗口聚合分区键的选择、文件大小都会影响速度。毕设数据量下不用太焦虑但论文里最好提一句分区策略是影响 Spark 任务执行效率的关键因素显得你懂原理。3. DeepSeek-R1 接入情感判断的三种可行方式3.1 三种接入方式的对比真正动手接大模型时你会发现情感分析这个需求可以拆成很多层不同层级的做法成本差别很大。我把实际可行的三条路径列出来你可以根据自己手上的显卡资源和预算去选方案准确性成本技术亮点适合场景调用大模型云 API高按 token 计费毕设规模几十块内实现简单跑通快需要稳定出结果、时间紧的同学本地部署蒸馏版 R1 模型高需要 16G 以上显存或量化版本展示工程能力完全离线机器配置好想体现部署能力大模型标注 蒸馏训练小模型较高需要训练时间体现模型微调能力可作为论文创新点想深入做学术方向三条路线不冲突甚至可以串联先用方案一给一部分数据打标签再去微调一个小的文本分类模型做批量推理大模型变成了你的标注老师这就是目前工业界很流行的大模型蒸馏思路。3.2 设计一个能稳定输出结构化情感的 Prompt不管选哪条路线你都要面对一个问题DeepSeek-R1 不是天生就按你需要格式回答的。如果你直接把弹幕扔给它问这句话是正面还是负面它可能回你一整段分析文字导致下游没法接。我的做法是写一个严格约束输出格式的 Prompt下面是一个可以直接拿来用的模板你是一个擅长中文互联网弹幕文化的情感分析专家。 请判断下面这条弹幕的情感倾向。 要求 1. 只输出 JSON不要输出任何多余文字。 2. JSON 包含三个字段 - sentiment: 只能取 positive、neutral、negative - intensity: 一个 0 到 1 之间的小数代表情感强度 - reason: 一句话说明你判断的依据不超过 20 字 弹幕内容这里放入弹幕文本实际调用时文本拼接可以用 Python 的 f-string或在大模型 API 的 messages 里构造成 system user 格式。记得把 temperature 调到 0.2 以下情感分析这种任务不希望模型太有创造力。temperature 太高同一个句子跑三次可能得出三种不同结果这在毕设里是致命的评委只需要抽十条检查就会发现不稳定。3.3 批量推理的并发控制与断点续跑弹幕是批量的API 调用是有并发限制的。这块看起来简单真写好代码的人不多。我建议你这样处理把清洗好的弹幕数据用一个自增 id 标记。分批调用每批 20-50 条根据 API 限流调整。跑完一批就把结果 append 到本地 JSONL 文件同时记录处理到的批次号。万一中断了下次从断点继续不需要重新跑。示例代码片段import json import time def run_batch(df_iter, batch_size50): results [] for i, text in enumerate(df_iter): result call_llm(text) # 调用 DeepSeek-R1 API results.append({text: text, label: result}) if (i 1) % batch_size 0: save_to_jsonl(results) results [] time.sleep(1) # 控制请求速率这个模块值得在论文里单独开一节因为它是传统大数据处理和大模型 API 接入之间的桥梁也是很多团队实际落地时最头疼的稳定性问题。你能把这个讲清楚答辩老师基本就会认可你不是只跑通了 Demo。3.4 情感判断质量怎么核验模型标注完不等于完事了你得抽检。我的习惯是每个视频随机抽 50 条带上预测结果人工过一遍算一个简单的人工一致率。如果一致率能到 90% 以上说明情感判断这个环节是可靠的可信工具如果只有 70% 多那就要检查 Prompt或者把可能不是情感表达的弹幕先过滤掉比如纯刷屏的哈哈哈哈其实很难说清是不是正向情感这类就归到 neutral 里不要硬分。这里还有一个值得写进论文的经验情感分不一定要用三分类可以做一个连续分数。比如把 negative 记作 -1neutral 记作 0positive 记作 1再乘以 intensity 作为强度权重最后算每个视频的情感总分。连续分数比离散标签的区分度高很多尤其在推荐系统排序阶段两个视频可能一个 0.8 一个 0.2如果只是积极/消极两个档位就很难排序。4. 从弹幕情感分布到视频推荐策略4.1 视频推荐为什么能用到情感信号B 站推荐大家都很熟做毕设时不需要跟抖音那种量级的产品比但基本的推荐思路必须讲清楚。传统推荐看的是用户看了什么和视频内容主题的匹配情感分析能额外提供给推荐系统一层信号这个视频让人看完后的情绪体验是什么。你想一下用户 A 喜欢看那种让人热血沸腾的视频用户 B 喜欢睡前看治愈系内容。他们可能都看手工类视频但一个希望看到手艺人极限挑战一个是想听安静的木工制作过程。如果只按内容和类目推荐两个用户会收到几乎一样的结果。可一旦把弹幕情感加入画像视频之间的差异就分开了。4.2 视频情感画像与用户情感倾向每个视频可以表示成一个情感分布向量。比如把弹幕分成几个情感类别开心、感动、愤怒、惊讶、无感统计每个类别的占比这个视频就有一个五维或六维的情感向量。对应的用户看完一个视频后我们可以把该视频的情感向量按一定衰减系数累加到用户向量上。用户看得越多他的情感偏好画像越清晰。这里有个不错的细节观看行为本身是用户希望获得这种情感体验的隐含反馈信号。4.3 推荐算法不是越复杂越好很多毕设同学一上来就想写 DeepFM、写 Graph Embedding我的建议是千万别给自己挖坑。推荐系统的核心逻辑讲清楚效果演示起来说得通就够了。我实际采用的策略是两层混合第一层是候选召回根据视频类别、标签做粗筛筛出 100 个可能相关的视频。第二层是精细排序计算用户情感向量与候选视频情感向量的余弦相似度结合一个基础热度分播放量、弹幕量、近期互动加权求和得到最终排序分。排序公式大概是这样score 0.4 * similarity(user_vector, video_vector) 0.3 * popularity_score 0.3 * freshness_score权重大小可以自己拿几组数据调论文里给出一张不同权重下的推荐结果对比表就很有说服力。这种设计的好处是你能在 PPT 上画一个清晰的流程图每一步都解释得清不装深奥。4.4 冷启动问题怎么解决新视频没有弹幕情感向量全为零怎么推荐我的兜底方案很简单先用视频标题和简介做一次关键词级的粗粒度情感预测等弹幕积累到 200 条以上再切回弹幕情感画像。你可以在系统设计里把 200 条作为阈值这也体现了你考虑了数据生命周期。再看用户侧冷启动新用户没有观看历史推荐什么这时候直接推荐当日整体情感倾向正向且热度高的视频相当于把大家都觉得好的先推给你然后再逐步个性化是一个合理的默认策略。5. 可视化大屏的实现数据链路、图表布局与性能5.1 先想清楚大屏要展示什么可视化大屏在这个毕设里是个加分项但也特别容易做成花瓶。我见过太多人把几个 ECharts 图表拼在一起就说自己做了一个大屏内容之间毫无逻辑。大屏的核心不是炫而是让人一眼看懂全站视频情感态势。我做大屏时只保留五个核心指标总监控视频数、弹幕总量、参与用户数头部概览弹幕情感趋势曲线按时间片聚合看整体情绪变化情感分布饼图或环形图积极/中性/消极占比弹幕高频热词 Top20词云用于观察大家到底在聊什么好评榜 / 争议榜视频 Top10列表点击可看详情这五个指标覆盖了全貌、趋势、结构、内容、案例五个视角是一个完整的数据叙事。你可以在这个框架上加东西比如地图如果弹幕能定位到省份或者实时滚动的弹幕流但不要砍掉这五个。5.2 前端只把数据接起来别自己造轮子前端用 ECharts 就够了不需要上 Vue Element Plus 全家桶也行但如果你已经熟悉 Vue用它组织图表组件更舒服。我建议架构是PySpark 处理完数据后把聚合结果导出成 JSON 或写入 MySQL。FastAPI 写几个只读接口返回video_trend、sentiment_ratio、hot_words这些 JSON。Vue 页面用axios定时轮询接口再用 ECharts 渲染图表。有人问我为什么不用 WebSocket 做实时推送。道理很简单你的汇总数据是批处理算出来的本身就有一个刷新周期用 WebSocket 反而把简单的事搞复杂了。轮询 30 秒一次完全够用。这里想做得更专业一点可以在后端加一个简单的缓存字典接口被多次请求时不会重复查库性能会好看很多。5.3 大屏上最容易被发现的细节问题有几个小细节你必须提前处理否则演示现场会很尴尬图表刷新时闪动ECharts 的setOption里尽量保证 series 的 data 结构一致不要让图表先清空再填数据。level 的误差很多弹幕的情感强度用小数表示在大屏上要限制保留两位小数否则一排 0.800000001 会很掉价。空数据兜底某个视频没有弹幕时后端接口应该返回一个明确的空结构而不是把字段设为 null前端要做成暂无数据。轮询失败重试后端服务偶尔抖动前端最好做一个 3 次失败后的提示而不是一直转圈。6. 毕设答辩现场最容易被追着打的五个问题6.1 你的数据有多少这个量级真的需要 Spark 吗这是最常见的送命题。别慌回答的关键在于分布式框架解决了什么问题而不是我的数据量有多大。你可以这样答单机确实能处理几万条弹幕但毕设的数据链路设计始终以扩展到全站百万级弹幕为目标。PySpark 在这个项目中的核心意义不只是计算而是提供了一种标准化的分布式 ETL 框架使得弹幕分析可以平稳地从单个视频扩展到多个分区、多个时间片。这样一来将来接入增量数据不需要推翻重写。这个回答展示的是工程思维而不是数据体量攀比。6.2 DeepSeek-R1 的误判你怎么处理先承认大模型不是 100% 准确再说你做了人工抽检和兜底策略。你可以直接给数据随机抽取了 500 条弹幕人工比对一致性达到 91%对不确定的样本统一归类到中性避免强分带来的误差。这个逻辑严谨老师挑不出毛病。6.3 你的推荐效果怎么评估如果你没有做 AB 测试的环境就做离线模拟。把用户的历史观看记录按时间切成训练集和测试集用前 80% 的时间训练用户画像后 20% 的时间作为预测目标看推荐结果里有没有命中用户实际观看的视频。给出一个命中率比如 Top20 命中率约 35%就足以支撑你的推荐系统有效性结论。6.4 可视化大屏是实时数据还是离线数据老老实实说是准实时离线批处理 定时刷新。不要硬吹自己是实时很容易被追问细节。你可以解释弹幕积累本身有延迟情感分析任务是大模型推理对计算资源要求高工业界普遍采用分钟级或小时的批量处理而不是事件级实时。这句工业界也这样处理很管用。6.5 哪些代码是你自己写的这个问题考验真实性。大模型 API、开源 ECharts、甚至 PySpark 库确实都不是你自己写的但你要说清楚你做的工作是基于这些基础能力的系统设计与集成包括数据 Pipeline 的编排、情感分析 Prompt 的迭代优化、推荐排序策略的权重设计、数据链路的异常处理。这些都是实实在在的工程贡献。7. 做完这一整套我自己的几点体会这个项目做完我最深的感触是大模型接入大数据分析时真正的工程量往往不在模型本身而是在数据清洗、格式约束、批量并发和结果校验这些不性感的环节。弹幕情感分析看起来只是给文本贴个标签但它前面连着的是分布式数据管道后面连着的是推荐系统和可视化故事线你每往前走一步都会遇到一个设计决策而每个决策都需要你有自己的判断依据。如果你时间紧张我建议你优先保证数据清洗 情感判断 可视化大屏这条主线闭环这是项目演示效果最好的部分。推荐系统可以做得简单但必须有评估没有评估的推荐系统在论文里是一堆无根之木。最后再分享一个实用的小技巧所有情感分析结果和推荐结果都额外存一份带run_time字段的版本快照这样答辩时可以说该项目支持不同实验参数的离线对比分析一句轻描淡写的话含金量比吹十个特性都高。