做课程教学评价系统，很多人第一反应是“搞个问卷打分不就行了”。但真正跑过教学管理的朋友都清楚，光靠学生打分和督导听课记录，很难回答“为什么这门课评价低”“教学效果到底受哪些因素影响”“同一个老师连续几个学期评分波动背后藏着什么”这类问题。我这次基于 python-django 搭了一套课程教学评价系统，核心思路就是把深度神经网络用在评价数据的挖掘和预测上，再用可视化大屏把结论直接怼到管理者和老师面前。

这套系统不是简单的“学生评分 + 排行榜”，而是把评价拆成了三个层次：第一层是常规的问卷采集与统计，第二层是对开放式评语做文本情感分析，第三层是用神经网络模型对“教学效果”做综合预测和归因分析。大屏则负责把这三层结果集中呈现，所有核心指标都在一块屏上动态刷新，方便教学管理者做决策。

如果你正在做教学评价、质量监测、教育数据分析相关的项目，或者准备在 django 生态里接深度学习的活，这篇内容基本覆盖了从需求拆解、模型设计、数据流搭建到大屏落地的完整路径，可以直接参考。

1. 项目背景与核心需求拆解

1.1 传统课程评价的痛点在哪

传统教学评价一般依赖三种数据来源：学生期末打分、督导随堂听课、同行教师互评。这些方式看似全面，实际存在几个硬伤。

第一，指标维度单一。学生打分往往是“满意、较满意、不满意”式的粗粒度评价，缺少对教学过程的具体描述。哪怕总分只有 70 分，你也说不清到底是“讲授不清晰”拉低的，还是“课堂互动不够”拖的后腿。第二，数据利用率极低。每学期积累几千条评语，基本躺在数据库里面吃灰，人工看不过来，也不可能有精力逐条归类。第三，评价结果滞后。等学期结束、分数汇总完，再反馈给任课老师，下一轮课早就排完了，谈不上实时改进。

当时我在梳理需求阶段，和几个负责教务的老师聊了一圈，得到一个很明确的信号：他们不想要一个“给老师排名”的系统，而是想要一个“帮助老师改进教学”的工具。排名只是表象，背后的原因诊断和趋势分析才是刚需。这个定位直接影响了我后面的所有技术选型。

1.2 深度神经网络在评价场景能做什么

把深度神经网络引入课程评价，不是赶时髦，而是要解决上面提到的两个核心问题：文本评语的自动分析和教学效果的多维预测。

先说文本分析。学生写的开放式评语是典型的短文本，包含大量口语化表达、网络用语、甚至错别字。传统的规则匹配或词典打分碰到这类文本基本歇菜，深度学习模型则可以捕捉上下文语义。我在系统里用了一个轻量级的文本分类模型，把评语自动归类到“教学质量”“课程内容”“课堂互动”“作业反馈”“学习收获”五个维度，同时输出情感极性（正向/中性/负向）。这样一来，几百条评语不再是一堆死文字，而是可以直接聚合、对比、筛选的结构化结果。

再说多维预测。课程评价数据其实是一个多特征输入的回归/分类问题：教师职称、教龄、课程类型、学生年级、班级规模、授课时段、到课率、作业提交率等，都在影响最终教学效果评分。传统统计方法只能做相关性分析，没法刻画特征之间的非线性组合作用。我采用了一个带有嵌入层和特征交叉能力的深度神经网络，以历史和当期数据为输入，预测课程综合评分区间，并输出各特征对评分的贡献权重。对教学管理者来说，这个输出的解释价值远高于一个孤零零的预测分数。

1.3 可视化大屏为什么是刚需

数据挖掘的结果如果不被人看到，价值就少了一大半。管理层讨论教学质量的时候，需要的不是一张 Excel 表和一个模型准确率，而是一眼就能看懂的全局视图。

大屏在这个项目里有三个不可替代的价值：一是把碎片数据集中化，学生评分、评语情感分布、到课率趋势、教师对比，全部放到一个逻辑视图里；二是把时间维度的变化直观呈现，同一门课、同一个老师连续几个学期的评价趋势，通过折线图一目了然；三是支持向下钻取，管理层从大屏上发现问题之后，可以直接点开某个教师的评价详情，逐条查看学生的文本反馈。

所以在设计之初，可视化大屏就不是“锦上添花的装饰”，而是系统对外输出价值的核心窗口，我甚至把大屏的数据接口设计放在业务接口开发之前。

2. 技术架构与方案选型

2.1 为什么选 Django 作为后端主框架

这个项目的后端选型，我几乎没有犹豫就定了 django。原因很实际。

首先是生态完整。django 自带 ORM、Admin 后台、认证体系、CSRF 防护、表单处理，对于课程评价这种典型的 CRUD + 权限管理场景，开发效率比用 Flask 或者 FastAPI 高很多。尤其后台管理，教务人员需要经常维护教师信息、课程信息、评价指标，django admin 稍微改改就能直接投入使用。

其次是和深度学习模型的集成没有想象中难。虽然模型训练我用的是 PyTorch，但推理服务没有直接耦合在 django 进程里，而是通过 django-rest-framework 暴露的 API 做调用。训练好的模型导出成 TorchScript 文件挂在独立推理服务上，django 这边只管拼装请求参数、解析返回结果。这样模型更新时不需要重启 Web 服务，也不会因为某个批处理任务把 Web 请求堵住，职责边界非常清楚。

还有一点不能忽略：团队里有人会 python，但没什么人懂前端工程化。django 的模板系统配合少量 JavaScript，加上开箱即用的分页、消息框架，让后端出身的人也能把完整功能搭起来，不至于被 node 生态的重型构建流程劝退。

2.2 深度神经网络模型的设计思路

模型这块，我走了两套并行方案，对应两类业务数据。

第一套是文本情感分析模型。输入是学生评语，输出是情感极性（正向、中性、负向）和维度标签（教学质量、课程内容、课堂互动、作业反馈、学习收获）。模型结构是这样的：嵌入层（Embedding）把分词后的评语转成向量序列，经过两层双向 LSTM 捕捉上下文语义，再接入一个全连接分类头。考虑到数据量不大（第一批标注样本只有约 8000 条），我没有上 BERT 这类大模型，而是用了一个预训练词向量加上浅层 LSTM，在标注数据上训练后 F1 值能做到 0.86 左右，已经能满足业务要求。

第二套是综合评分预测模型。输入特征包括：教师职称（编码）、教龄（归一化）、课程类型（编码）、学生年级（编码）、班级人数（归一化）、授课时段（编码）、前序学期评分（归一化）、作业提交率（归一化）等 12 个特征。网络结构是：全连接层 64 -> ReLU -> BatchNorm -> 全连接层 32 -> ReLU -> 输出层 1（回归），同时加了一个特征重要性打分模块，训练完成后导出每个特征对最终评分的贡献权重。这个模块的核心价值不是预测本身，而是给管理者提供“到底什么因素在影响评分”的解释依据。

2.3 可视化大屏的技术选型对比

大屏方案我对比了三条路线：纯 ECharts 自研、第三方大屏模板、开源可视化平台。

最终选择是 ECharts 自研 + 自定义布局。对比结果如下：

我做这块的经验是：如果项目时间充足，建议选 ECharts 自研，因为教学评价大屏的核心是“数据叙事逻辑”，而不是炫酷动效。一个好的布局顺序应该是先放核心数据卡片（综合评分、参评人数、预警课程数），再放趋势图、雷达图、词云、热力图，最后加上二级钻取的联动面板。每一块图表都要为某一个具体的业务问题服务，而不是为了占满屏幕。

前端框架我就用了原生 HTML + jQuery + ECharts，没有上 Vue 或 React。原因很简单：大屏页面是单页场景，交互复杂度有限，原生写法反而减少打包、路由等不必要的环节，部署也轻量。

3. 核心功能模块与数据流设计

3.1 系统整体模块划分

整个系统按业务边界拆成六个模块：基础信息管理、评价任务管理、数据采集与清洗、深度分析引擎、可视化大屏、系统配置与权限中心。模块之间通过数据表和 API 解耦，互不直接依赖实现。

基础信息管理维护教师、课程、学生、班级等主数据；评价任务管理负责创建学期评价任务、配置评价指标、设定参评范围；数据采集模块承接学生端问卷、督导端评分、评语文本的录入；深度分析引擎对接模型训练与推理服务；可视化大屏从分析引擎拉取聚合结果；权限中心区分管理员、教务人员、教师、学生四个角色，做到“不同角色看到不同数据范围”。

这里有一个设计上比较关键的点：分析引擎与业务库是物理分离的。业务库跑在 MySQL 上，分析引擎的中间结果和模型特征数据单独落在另一个库。为什么要分开？因为深度模型的批处理任务耗时长、I/O 密集，如果不隔离，一个模型训练或者大批量推断任务可能把在线业务拖垮。我用 Celery 定时触发分析任务，把结果写入分析库，大屏只读取分析库，不直接查业务大表，性能和稳定性都有保障。

3.2 评价数据采集与预处理

数据采集阶段最容易被低估，其实它决定整个模型效果的上限。我在这部分花的时间，占了整个项目开发周期的三分之一。

采集端设计了一张主评价表和若干张明细表。主评价表记录评价任务 ID、课程 ID、参评人 ID、总分、提交时间；明细表按维度拆分，包括教学质量、课程内容、课堂互动、作业反馈、学习收获五个评分维度，每个维度是 1~10 的整数分。评语文本单独存大字段，同时在采集入口做了关键词过滤和长度校验，防止空值和无意义文本干扰模型训练。

预处理流程我用管道方式组织，一共四步：无效数据剔除、文本分词与去停用词、特征编码与归一化、样本划分。特征工程里有一个容易犯的错：直接把教师职称、课程类型这类类别特征用 0、1、2、3 编码喂给神经网络。这种做法会引入错误的顺序关系，比如“副教授 = 1、教授 = 2”会误导模型认为教授比副教授大一个单位的量化数值。正确做法是使用 one-hot 编码，django 应用层把编码逻辑封装好，避免在 ORM 里混入这类业务规则。

3.3 神经网络模型训练与评价预测

模型训练是整个系统里最需要耐心的一环。我先把训练脚本单独拆出项目目录，用 PyTorch 实现。评语情感分类模型的训练数据来自教务科积累的历史评语，我一个人逐批清洗、去重、标注，最后花了不少时间才攒到 8000 条左右有效样本。数据量不大，所以训练非常快，用 GPU 跑一个 epoch 只需要几十秒，重点反而在验证和调参上。

损失函数和优化器的选择上，文本模型用的交叉熵损失加 Adam 优化器，学习率初始设置为 2e-3，每 3 个 epoch 衰减一次，衰减系数 0.8。评分预测模型用的平滑 L1 损失，目的是降低异常学期评分的梯度影响。训练完成后，两个模型都做了评估：文本模型在测试集上准确率 0.88、F1 值 0.86；评分预测模型平均绝对误差约 3.7 分（评分范围是 0~100），在业务上属于可接受水平。

预测流程上，模型推理不是请求来了才现算，而是借助 Celery 定时任务，每天凌晨对当天新增的评价数据批量推断，结果写回分析库。教学管理者第二天打开大屏，看到的就是前一晚更新完毕的完整分析结果，全程不需要人工干预。

3.4 大屏数据接口设计

大屏接口我统一走 REST API，格式保持与前端图表需求的字段一一对应，减少前端拼接逻辑。

比如综合评分卡片接口返回的核心字段是这样的：

{ "semester": "2024-2025-1", "avg_score": 86.4, "credit_count": 1560, "evaluate_count": 1528, "coverage_rate": 97.9, "alert_course_count": 3 }

趋势图、雷达图、词云等接口也都返回类似结构化的 JSON。设计接口的时候我特别强调一个原则：接口返回值要和 ECharts 的 option 保持接近但不相等。也就是说，接口只返回业务数据，不返回配色、字体、坐标轴等前端展示配置，这样前端调整样式时不需要重新改接口。如果前端需要做单位换算、千分位格式化，统一在前端处理，后端只给最原始的业务数值。

接口性能方面，给大屏单独开了一个只读账号，并设置了较短的缓存时间。Redis 缓存大屏聚合结果 2 分钟，避免每次刷新都穿透到 MySQL。后面的部署环节我会具体讲这个缓存策略。

4. 关键实现与实操记录

4.1 Django 项目骨架与数据模型搭建

项目创建我用的是标准的 django-admin 命令。考虑到模块划分清晰，我没有把所有 app 塞在同一个包里，而是建了一个微型的多 app 工程，每个 app 对应一个业务域。settings 里单独配置了 MySQL、Redis、Celery 的连接参数，生产环境和本地开发环境用独立的配置文件区分，靠环境变量切换。

数据模型核心表的结构我做了几张主要的，下面是课程评价主表的 Model 定义示例，写作时做了适当简化，但字段和约束关系是实际在用的：

from django.db import models class EvaluationTask(models.Model): name = models.CharField('评价任务名称', max_length=200) semester = models.CharField('学期', max_length=32) start_date = models.DateField('开始日期') end_date = models.DateField('结束日期') status = models.CharField('状态', max_length=16, default='pending') created_at = models.DateTimeField('创建时间', auto_now_add=True) class Meta: db_table = 'evaluation_task' indexes = [models.Index(fields=['semester', 'status'])]

class EvaluationRecord(models.Model): task = models.ForeignKey(EvaluationTask, on_delete=models.CASCADE, verbose_name='评价任务') course = models.ForeignKey('course.CourseInfo', on_delete=models.CASCADE, verbose_name='课程') teacher = models.ForeignKey('teacher.TeacherInfo', on_delete=models.CASCADE, verbose_name='教师') student = models.ForeignKey('student.StudentInfo', on_delete=models.CASCADE, verbose_name='学生') total_score = models.DecimalField('总分', max_digits=5, decimal_places=2) comment_text = models.TextField('评语', blank=True) submitted_at = models.DateTimeField('提交时间', auto_now_add=True) class Meta: db_table = 'evaluation_record' constraints = [ models.UniqueConstraint( fields=['task', 'course', 'teacher', 'student'], name='uniq_eval_task_course_teacher_student', ) ]

这条唯一约束很重要，它能从根上防止同一个学生对同一门课重复提交。实际的评价问卷在前端也做了防重，但后端这个约束才是最后一道防线，没有它，脏数据会直接污染模型训练样本。

4.2 模型训练的完整流程与参数细节

模型训练的工程目录我单独放在ml_service/下，和 django 项目根目录平级，避免相互干扰。目录结构大概是：

ml_service/ ├── train_text_clf.py ├── train_score_reg.py ├── export_model.py ├── preprocess/ │ ├── text_clean.py │ └── feature_build.py ├── models/ │ └── __init__.py └── saved_model/ ├── text_clf.pt └── score_reg.pt

训练流程分三步走。第一步，从 MySQL 导出数据，经过清洗、标注转换后保存为 JSONL 格式；第二步，执行训练脚本，模型指标和损失曲线写入 TensorBoard 日志；第三步，用export_model.py导出 TorchScript 模型，推到推理服务器。

这里有个参数选择的经验：训练文本分类模型时，序列最大长度我设为 64。短评语超过这个长度的很少，设太大反而会增加显存占用、拖慢训练速度。词向量维度用的 100 维，没有自己训练，直接用一个通用的开源中文词向量做初始化，效果在相似任务上验证过，性价比很高。

综合评分模型的归一化方法也值得提一句：所有连续特征用 Z-score 归一化，类别特征做 one-hot 后不再额外处理。归一化的均值、方差要在训练集上算好并保存下来，推理的时候必须用同一组参数，绝对不能拿全量数据重新算一遍，否则会出现训练和推理分布不一致的问题。

4.3 大屏图表渲染与动态刷新实现

大屏页面我采用了 16:9 的固定设计分辨率和 1920x1080 基准，页面内容用百分比定位，缩放适配通过 resize 事件统一处理。这样的好处是，不管屏幕是 1366 还是 3840，画面都能等比缩放，不会出现布局错位。

布局上分了三个区域：顶部是标题栏和全局统计数字；中间主区域左侧放课程评价综合排名，中间放趋势图和雷达图，右侧放评语情感分布和词云；底部是一条横向滚动栏，放置各院系的对比柱状图和预警课程列表。

ECharts 图表的初始化方式我这里给一个核心示例，以综合评分趋势图为例：

const trendChart = echarts.init(document.getElementById('trendChart')); function renderTrendChart(data) { trendOption = { tooltip: { trigger: 'axis' }, grid: { left: 60, right: 30, top: 40, bottom: 50 }, xAxis: { type: 'category', data: data.semesterList, }, yAxis: { type: 'value', name: '平均分', min: 60, max: 100, }, series: [{ data: data.avgScoreList, type: 'line', smooth: true, areaStyle: { opacity: 0.15 }, }], }; trendChart.setOption(trendOption); }

数据刷新我用的是setInterval定时轮询，间隔 30 秒。为什么不直接上 WebSocket？因为大屏场景对“实时性”没那么敏感，30 秒的延迟完全够用，反而轮询实现更简单、更稳定，也不容易出现前端连接断开后需要重连的维护问题。如果后续要做手机端实时预警推送，再上 WebSocket 也不迟。

每次轮询后的更新逻辑是：拿到接口返回的 JSON，对比上次数据是否有变化，如果有变化才调用setOption更新图表。这样避免了无谓的 DOM 操作，长时间挂屏时浏览器内存占用一直很稳定。

4.4 部署架构与性能优化

部署我用了常见的 单机 + nginx + uwsgi + mysql + redis 结构。深度学习推理服务单独跑在一个 Python 进程上，开放三个内部接口：评语情感分析、综合评分预测、特征归因分析。django 应用通过 requests 调用推理服务接口，而且加了简单的熔断逻辑：推理服务连续超时 3 次，后续请求直接走兜底规则，比如情感分析默认返回“中性”，保证教学管理者在极端情况下仍然能打开大屏看到基础统计数据。

性能调优主要做了三件事。第一件事是数据库索引优化，给evaluation_record的 task、course、teacher、submitted_at 字段建了联合索引，大屏按学期聚合查询时从原来的秒级降到了 200 毫秒左右。第二件事是 Redis 缓存，大屏接口全部走缓存，key 按业务维度拼接，比如课程排名缓存 5 分钟、趋势缓存 2 分钟、词云缓存 10 分钟。第三件事是大屏静态资源压缩，ECharts 按需引入模块，js 体积从我最初全量引入的 1.2MB 降到了 360KB，弱网环境下加载速度提升明显。

部署上线前还要特别留意服务器时区和 Django 的TIME_ZONE配置一致性。我踩过这个坑：服务器时区是 UTC，Django 里设置的却是本地时区，结果大屏上展示的“今日参评人数”每天延迟 8 小时才更新，排查了半天才反应过来是时区配置不一致，导致定时任务执行的起点偏移了。

5. 常见问题与排查技巧实录

5.1 评价数据样本不平衡怎么办

课程评价数据的分布天然是不平衡的。绝大多数评语是正向的，负向评语和中性评语占比很低。如果直接用原始数据训练文本分类模型，模型会偷懒到把一切都预测成“正向”，因为这样准确率也能轻松到 85% 以上，看起来很好看，实际没有任何业务价值。

我解决这个问题用了三层手段。

第一层是数据层面：对负向和中性样本做了简单的随机过采样，把比例从 1:20:5 调整到 1:4:4 左右。第二层是训练策略层面：在交叉熵损失里给每个类别加权，负向样本的权重设为 3.0，中性样本设为 1.5，让模型在损失计算时更关注少数类。第三层是评估指标层面：不看准确率，主要看宏平均 F1 值，避免被多数类的高准确率迷惑。

三层做完，负向评语识别的召回率从最初的不到 30% 提升到 74% 左右。从业务结果看，这个提升直接影响了“预警课程”的检出能力，漏报明显减少。

5.2 大屏加载慢和渲染卡顿的处理

大屏打开要白屏三五秒，这在汇报现场是灾难级的体验。问题通常出在三个位置：接口慢、资源大、渲染卡。

接口慢的问题，我用看请求耗时的方式直接定位。发现最慢的接口是“课程综合排名”接口，SQL 里 join 了教师表、课程表、加上子查询算平均分，还做了分页，数据量大时执行时间飙到 1.4 秒。优化方案是：把排名预计算写入一张独立的course_rank_summary表，由 Celery 每小时刷新，接口只查这张表，耗时降到 80 毫秒。

渲染卡的问题，主要来自词云和雷达图的频繁 setOption。我的处理办法是给图表设置lazyUpdate，并且只在数据变化时才更新图表实例。词云数据量控制在 100 个词以内，多余的高频词合并展示，渲染帧率稳定了很多。

5.3 前后端联调时接口字段不一致的坑

大屏联调阶段，几乎每天都会遇到字段对不上号的问题。后端返回的是semesterList，前端代码里写的却是semesters；后端字段是avg_score，图表配置里取的是score，换一个人写就换一套命名。

后来我定了一个硬性约定：所有大屏接口的字段名统一用 snake_case，前端 JavaScript 里直接使用这些小写字母和下划线的对象属性，不做任何驼峰转换。这个约定在项目里定死了，后端写接口时按这个规范，前端取数时也按这个规范，再没出过字段不一致的问题。

另外一个容易踩的坑是数值类型：MySQL 的 DECIMAL 字段经过 JSON 序列化后，到了前端可能变成字符串。我在 django 的 DRF Serializer 里统一配置了coerce_to_string=False，保证avg_score传给前端的是86.4而不是"86.4"，否则图表轴序或者 tooltip 展示很容易出诡异的表现。

5.4 推理服务偶尔不可用的兜底策略

深度学习推理服务不是 100% 可用。一个很现实的问题是，如果模型推理进程因为内存溢出崩了，django 还在跑，大屏数据接口就应该有降级方案。

我的实现是：django 调用推理服务时，用try...except包住，捕获超时异常和连接异常，然后读分析库里上一次成功运行的结果缓存。如果分析库中也完全没有数据，则返回一个“暂无分析数据”的占位结构，前端对应位置显示为灰色空状态。这样大屏永远不会有白屏情况，最多是没有最新分析结论，但基础统计和评分分布依然可见。

这个兜底逻辑同事们评价很高，因为在汇报演示的时候稳定性太重要了，宁可展示旧数据，也不能让屏幕卡在 loading 出不来内容。

6. 项目复盘与扩展建议

6.1 从实际使用中学到的几件小事

系统上线之后，我用了差不多半个学期去做回访和调优，有几个体会非常深刻。

第一件事：模型输出别追求“准确”，要追求“可用”。我做评分预测模型时，一开始总想把平均绝对误差降到 3 分以内，后来发现教务管理者真正关心的是趋势预警，误差在 5 分以内已经够用了。他们希望看到的是“这门课连续两学期下滑超过 8 分”这样的判断，而不是精确到 84.3 分还是 84.7 分。

第二件事：好的可视化是“让人一眼看到重点”。第一版大屏我塞了 13 个图表，信息密度非常高，结果使用者反馈“看不过来，不知道先看哪里”。后来精简成 8 个模块，并用颜色阈值区分综合评分等级——90 分以上绿色、75~90 蓝色、75 以下橙色预警——才真正起到辅助决策的作用。

第三件事：定时任务要留足缓冲时间。Celery 定时任务最初设定在凌晨 00:10 执行，结果遇到学期末参评扎堆，数据量暴涨到 40 万条，批处理任务跑了 2 个小时还没跑完，影响白天大屏数据更新。后来把时间改到凌晨 02:00，并给任务加上超时告警，问题就缓解了。任何带动批量计算的定时任务，都必须评估最坏情况下的执行时间。

6.2 后续还可以怎么扩展

这套系统目前已经跑通了“采集—分析—展示”的完整链路，但离真正的教学闭环还差两步，我觉得后续值得补上。

第一步是增加教师端个人分析报告。大屏解决的是管理层需求，教师本人需要的是更私密、更具体的改进建议，比如“您这门课在课堂互动维度的评分低于同类课程 8%，学生的负向评语主要集中于互动形式单一，建议增加分组讨论环节”。这类建议需要引入知识库匹配，把模型输出的维度标签和预警信息转化为自然语言建议。

第二步是引入归因分析的细粒度化。现在特征重要性只能到“课程类型”“班级规模”这个层级，后续可以继续做分学院、分课程类型的子模型，让每个二级学院有一个独立小模型来适配自身特点，而不是共用同一个全局模型。这样做会牺牲一部分样本量，但解释性和贴合度会明显提升。

我把这段经历写出来的意义，更多是给正在做类似项目的朋友一个完整参考。教学评价加深度神经网络，重点不在算法本身多复杂，而在于把技术工具落到真实的教学管理场景里，产出能被理解和信任的结果。我的建议是：先搞清楚业务方真正想要什么，再决定用什么算法、上什么大屏，顺序不能反，这样项目才能真正从“能演示”走向“能使用”。