基于深度学习的淘宝用户购物行为预测与可视化系统实现

简介本资源是一套面向计算机专业本科生的毕业设计级实战项目聚焦电商用户行为分析与预测适用于深度学习、数据可视化及Web系统开发的学习与实践。项目基于Python构建融合TensorFlow深度学习建模、Django前后端开发、MySQL数据存储与Navicat数据库管理完整覆盖从淘宝用户行为数据采集含spider爬虫模块、清洗建模、预测分析到交互式可视化展示的全流程可直接用于课程设计、毕设答辩或求职项目复现。压缩包共630个文件含68个核心Python脚本含模型训练与API逻辑、110个Vue前端组件、70个JS交互文件、48个PNG与43个JPG图表资源以及SQL建库脚本、部署说明文档含bat一键运行/安装脚本和详细数据库设计Word文档整体31.91MB。已有61人下载学习提供开箱即用的完整工程结构、清晰模块划分django3jf982vi主应用独立爬虫文档体系及调试排错指引显著降低环境配置与功能验证门槛。1. 项目拆解这套淘宝用户购物可视化与行为预测系统到底做了什么选这个题目的同学第一眼看到的一般是“python 深度学习 淘宝用户购物可视化与行为预测 MySQL”这一串关键词很容易被吓住但其实这个题目的核心任务非常清晰。把它拆开来看就是三件事把淘宝用户行为数据存到MySQL里用深度学习模型预测用户接下来的购买行为再把这些分析结果用可视化页面展示出来。我见过不少毕业设计标题写得很泛而这个题目最大的优势是“链路完整”。它不是一个纯算法模型项目也不是一个纯网页展示项目它是从数据处理到模型训练再到前端展示的完整闭环。答辩的时候你可以很自然地讲一条线用户行为日志进入MySQL经过清洗之后变成特征特征送进深度学习模型做预测预测结果再回到数据库最后由可视化大屏呈现给运营人员看。这套系统适合三类人来参考借鉴第一类是想把这个题目直接作为毕业设计或课程设计主体项目的同学第二类是已经选了电商数据分析方向但还不知道系统怎么落地的同学第三类是工作中要用Python做用户行为分析想快速搭一套可演示原型的开发工程师。如果你属于其中任何一种这条思路都能帮你省掉至少两周的摸索时间。下面所有内容都会围绕这个系统的完整实现过程展开重点讲清楚每个设计选择的理由以及在真实场景里最容易踩的坑。我默认你手里已经有一份“淘宝用户行为数据集”或者类似电商行为日志数据如果没有可以用公开的UserBehavior数据集大约一亿条用户行为记录字段为user_id、item_id、category_id、behavior_type、timestamp先做采样和预处理这个流程后面会细讲。2. 总体架构与技术选型先定方向再写代码动手写代码之前一定要先想清楚系统的整体结构。我见过太多同学拿到题目就急着跑模型结果数据格式改了又改数据库表重建了好几次模型训练脚本和Web展示代码混在一起最后自己都分不清哪个文件是干嘛的。架构设计多花一天后面能省出两周。2.1 模块划分三层结构最稳妥我实现这套系统时代码结构从一开始就按三层来划分后面维护和写论文都很省力。第一层是数据层负责数据的导入、清洗、存储核心组件是MySQL和Python的ETL脚本第二层是模型层负责特征工程和深度学习模型的训练、评估、预测核心组件是深度学习框架和scikit-learn第三层是展示层负责把预测结果和数据统计结果可视化核心组件是Flask加ECharts。为什么我不建议把模型训练和网站展示混在一起写因为毕业设计要提交代码也需要写说明书如果所有逻辑都堆在几个脚本里不仅自己调试痛苦答辩被追问的时候也很难讲清楚。分层之后每一层都有明确的边界数据层出问题查数据层模型层出问题查模型层展示层出问题查接口和前端排错效率完全不一样。以这个项目为例我会建议你把目录结构组织成这样data目录放原始数据和特征文件sql目录放建表和初始化脚本model目录放特征工程和训练代码web目录放Flask应用和静态页面docs目录放说明文档。这样答辩时老师问起某个文件的位置你顺手就能指出来印象分会高不少。2.2 技术栈选择的几个关键决定先说是深度学习框架。TensorFlow和PyTorch二选一我建议按照你自己的熟悉度来。如果之前课程里学过TensorFlow那直接用TensorFlow 2.xKeras接口写起来也顺手如果更习惯PyTorch那么Dataset、DataLoader这些用起来也不会太吃力。两者在这个项目上没有本质差别重要的是你被答辩老师问到“为什么选这个框架”时能说出理由比如TensorFlow生态成熟、Keras API适合快速搭建PyTorch调试方便、更贴近学术前沿。然后是Web后端。Flask在这里是个非常稳的选择因为除了把MySQL数据包装成JSON接口之外几乎不需要复杂功能。FastAPI性能更好、自带Swagger文档但毕业设计场景下Flask的代码更简单、更容易让初学的同学看懂。如果做实时刷新大屏Flask加AJAX轮询就够用了没必要上WebSocket后者会引入会话管理和并发问题纯属给自己找麻烦。再说MySQL。在这个项目里MySQL主要存三类数据原始行为流水、清洗后的特征中间表、模型预测结果的回写表。你要注意一点训练用的特征不要每次从MySQL现算否则模型迭代几百个epoch时数据库会成为瓶颈。正确做法是先把特征导出成pandas的DataFrame再存成NPY或Parquet文件训练时直接读文件速度能快好几倍。2.3 数据流闭环一条线串起所有模块整体数据流是淘宝用户行为日志进入ETL脚本清洗清洗后的结构化数据写入MySQL特征工程脚本从MySQL读取数据构造序列和统计特征保存为本地文件深度学习模型用本地特征文件做离线训练训练完成后对目标用户做预测预测结果回写MySQL的predict_result表Flask后端查询MySQL把统计数据和预测结果封装成JSON接口前端ECharts获取JSON数据渲染成可视化大屏。这个闭环里最容易丢的环节就是“预测结果回写”。我之前审过一个项目模型训练完预测结果打印在控制台里就结束了页面上的预测模块完全拿不到数据最后只能临时改成静态假数据。答辩老师问“预测结果在哪里”场面非常尴尬。为了让系统闭环你一定要在数据库设计阶段就预留一张预测结果表并且让可视化页面有对应的展示区域。这个细节直接决定系统是“完整可运行”还是“半成品”。3. 数据层设计把淘宝行为日志变成可用的数据资产数据层是整个项目的地基。很多同学喜欢把精力放在模型调参上但真实情况是如果MySQL表设计不合理、数据清洗逻辑有漏洞后面每一步都会出问题。模型数据丢了几个用户可视化页面统计数字对不上这些问题排查起来比写代码痛苦得多。3.1 核心表结构与字段设计MySQL表不用设计得太多四张核心表就够了user_behavior用户行为流水表、item_info商品信息表、user_feature用户特征表、predict_result预测结果表。字段设计上我给出一个可以直接用的版本。user_behavior表是最核心的表字段包括user_id、item_id、category_id、behavior_type、timestamp、create_time。behavior_type字段建议用0到3的整数编码0表示点击1表示加购2表示收藏3表示购买。用整数编码而不是存中文字符串是为了后续特征工程方便也节省存储空间。timestamp存Unix时间戳查询时用FROM_UNIXTIME转换成人可读的时间。字段类型的选择有个容易忽略的点user_id和item_id一定要用BIGINT不要用INT因为电商平台的ID很快就超过21亿的INT上限。behavior_type用TINYINT就够了timestamp用INTcreate_time用DATETIME商品价格用DECIMAL(10,2)。这些细节看起来小但等数据量上来之后字段类型错误会导致索引失效甚至数据溢出。索引的设计非常重要这一步被很多同学忽略等数据量大的时候会直接卡死。user_behavior表在user_id和timestamp上建联合索引因为后面最频繁的查询就是“取出某个用户在某段时间内的行为序列”。predict_result表在user_id上建索引因为可视化页面要按用户ID查预测结果。索引不要建太多否则写入变慢毕业设计数据量下四张表的索引控制在6个以内就够了。3.2 数据清洗行为序列怎么构造数据清洗的核心目标有两个去掉脏数据和构造用户行为序列。最典型的脏数据是timestamp溢出、user_id为空、behavior_type不在0到3范围以及重复记录。我的处理脚本会按字段逐条校验不合规的丢弃并记录日志不直接改原数据。这样做的好处是答辩时可以汇报“共处理了XX条数据剔除XX条无效记录有效占比XX%”这些数字本身就是研究数据成果论文里直接能用。构造用户行为序列是数据层的核心产出。我按user_id分组组内按timestamp升序排列然后把behavior_type序列连成一个list。举个例子一个用户当天的行为序列是[0, 0, 2, 0, 1, 0]0代表点击、2代表收藏、1代表加购这个序列就是后面深度学习模型的输入。这里有个细节购买行为往往在点击、加购和收藏之后所以序列顺序非常关键绝对不能打乱。排序用时间戳升序是最稳妥的不要用数据库自增ID排序因为导入数据时ID顺序和时间顺序不一定一致。构造序列时还需要设定一个时间窗口。常用做法是取用户最近7天或14天的行为超过窗口的数据舍弃。窗口太长会让序列稀疏信息密度低太短则可能覆盖不到完整的决策周期。我个人实测下来的经验是14天窗口配合“最后7天是否购买”作为标签预测效果整体最稳定而且从业务逻辑上也讲得通一个用户过去两周的行为很大程度决定了他接下来一周买不买。3.3 分层存储别让MySQL成为训练瓶颈做完特征工程后数据量会膨胀很多。假设原始行为数据有500万条构造出的用户序列可能只有5万条因为按用户聚合次数大幅减少但每条序列长短不一保存方式需要重新考虑。我的做法是MySQL只存结构化数据和最终预测结果中间的特征矩阵用pickle或numpy保存成本地文件。训练脚本直接读文件速度快也不挤占MySQL的资源。等模型预测完成再统一把预测结果写回MySQL的predict_result表供可视化后端查询。这个分层存储策略在真实项目里非常重要如果每轮训练都去MySQL现算特征一次全量训练可能要跑两三个小时而读文件只需要几分钟。这里要补充一个实践建议写ETL脚本时一定要加断点续跑的设计用日志文件记录处理到哪个用户、哪一天的数据。因为电商行为数据集很大清洗一次可能跑十几分钟到半小时如果中途报错要从头跑非常崩溃。加上断点续跑每次启动脚本先读取上次进度失败修复后能接着跑这个功能在数据量大的时候能救你一命。4. 行为预测模型深度学习建模的核心环节模型部分是整个系统里最有技术含量、也最容易被问倒的环节。答辩时老师会盯着模型结构、数据标签定义、评估指标这三个问题反复追问。如果这些概念没有想清楚很容易被问住。4.1 预测目标定义预测什么、用什么标签行为预测可以定义成两种问题一种是用户级别的“未来N天内是否购买”一种是行为序列级别的“下一个动作是点击还是购买”。实操中我强烈建议先做用户级别的二分类任务因为标签好定义、结果好评估、答辩讲起来也直观。具体做法是取用户在时间窗口T内比如第1到14天的行为序列作为特征标签取用户在T1到T7天内是否发生过购买行为。如果发生过标签为1否则为0。这样整个问题变成一个标准的二分类问题可以先用逻辑回归、XGBoost这些传统模型做基线再用深度学习模型提升效果。我在项目里同时训练了两个模型做对比一个XGBoost作为baseline一个基于LSTM的深度模型作为主模型。论文里“对比实验”章节直接填这两组结果答辩时还能解释为什么深度学习在序列建模上更占优势因为LSTM能捕捉点击到加购到购买的时序依赖而XGBoost只能看到统计特征。4.2 特征工程哪些特征真正有用特征可以分成三类每类的作用和构造方式都不一样。第一类是用户基础统计特征比如总点击次数、总加购次数、总收藏次数、总购买次数、活跃天数、点击到购买的转化率。这些特征计算简单、解释性强XGBoost和深度学习都能直接用。统计特征在预测任务里非常重要一个很久没登录的用户和一个每天高强度浏览的用户购买概率天然不同。第二类是行为序列特征按时间顺序排列的行为编码序列这是深度学习模型的输入主体。序列长度不固定需要在训练前做padding或截断。padding的方向有讲究我建议把最近的行为放在序列末尾padding时在开头补0这样LSTM读取序列到最后时正好读到用户最近的行为记忆更清晰。如果反向padding模型读到序列末尾时信息已经很滞后效果会偏差。第三类是时间特征比如用户大部分行为发生在白天还是晚上、工作日还是周末、最后一次行为距离预测时间的间隔。这些特征对购买行为有很强的信号。我实测下来“最后一次活跃距今间隔”与购买概率呈明显负相关间隔越长购买概率越低。这个特征加进去模型AUC能提升不少。特征不是越多越好。我的经验是先跑一版基线把特征重要性排序拿出来看一眼把排名靠后的特征直接删掉。否则进入深度学习模型后特征太多会显著增加训练时间而模型效果几乎不涨还容易过拟合。4.3 模型架构Embedding加BiLSTM加Attention主模型我用了Embedding、BiLSTM和Attention的组合这是一个比较中庸但很稳妥的方案既不是简单到没亮点也不至于复杂到答辩时解释不清。流程是这样的行为序列先过一个Embedding层把0到3的行为编码映射成低维向量然后输入BiLSTM让模型从两个方向学习行为序列的上下文关联BiLSTM输出的每个时间步的隐藏状态再接一个Attention层让模型自动关注行为序列中更关键的动作比如加购和收藏通常比点击更重要最后把Attention加权后的向量与用户统计特征拼接经过全连接层输出二分类概率。这里我们来说说为什么用Attention。用户的点击量通常远大于购买量一条几十步的序列里可能只有一两个加购和购买动作。如果不加AttentionLSTM最后一步的隐藏状态很容易被大量“点击”行为稀释。加上Attention之后模型会学着给加购、收藏这些高价值行为分配更高权重。我在小样本数据集上测试时加上Attention能提升AUC大约2到4个百分点这个提升在论文里非常值得写。模型结构定义好之后有几个关键超参数要注意。Embedding维度设8到16就够因为行为类型只有4种维度太大浪费参数量且容易过拟合。LSTM隐藏层维度设64到128序列最大长度设50到100Dropout设0.3到0.5。优化器用Adam初始学习率0.001配合早停机制当验证集loss连续3个epoch不降就停止训练防止过拟合。4.4 训练细节样本不平衡、评估指标和实验记录淘宝用户行为数据天然是极度不平衡的大部分用户一段时间内不会购买购买用户占比可能只有5%到15%。如果不处理模型会学会“全预测0”也能拿到很高准确率但实际没有任何意义。处理方法有两种一是欠采样把未购买用户样本随机抽掉一部分让正负样本比例接近1比1或者1比2二是过采样用SMOTE等方法合成正样本。考虑到深度学习模型对数据量比较敏感我建议先欠采样到1比2甚至1比3既能保证模型看清购买行为的模式又不至于丢掉太多信息。评估指标上不要只盯着准确率。这个场景下我主要看AUC、F1和召回率。AUC能评价模型对正负样本的排序能力F1能看出模型在样本不平衡时的综合表现召回率则反映模型到底能抓住多少真正会购买的用户。对推荐业务场景来说召回率低意味着大量潜在购买用户被漏掉哪怕精确率高也没有商业价值。模型训练过程中我在每个epoch结束后记录训练loss、验证loss、AUC并画成曲线保存下来。这不仅是调参的依据也是论文实验部分必须放的核心实验图。答辩时拿出这几张曲线图讲“模型在epoch 12时验证AUC最高之后开始过拟合”比空口说“效果不错”有说服力得多。我推荐用matplotlib把训练曲线画出来保存成PNG图片后期写论文直接引用。5. 可视化大屏落地从MySQL数据到ECharts页面可视化是整个系统最直观的部分也是答辩时最抓眼球的部分。但可视化不仅仅是画几张图那么简单它背后需要后端接口、数据库查询和前端图表联动。很多同学在模型上花了大把时间最后可视化页面却很粗糙拉低了整体完成度。5.1 Flask后端API设计可视化后端我推荐用Flask原因是逻辑简单适合学生项目。API设计上规划四个核心接口就够了。第一个是GET /api/overview返回总用户数、总商品数、总行为数、总购买数等统计卡片数据用于大屏顶部的核心指标展示。第二个是GET /api/behavior_trend接收一个时间范围参数返回不同行为类型在时间上的趋势数据用于折线图。第三个是GET /api/behavior_distribution返回点击、加购、收藏、购买四种行为的占比用于饼图或环形图。第四个是GET /api/predict接收user_id参数返回指定用户的购买概率预测结果用于预测卡片。每个接口的返回格式统一为JSON包含code、message和data三个字段。统一格式的好处是前端只需要写一个请求封装出错时能快速从message里定位问题。实现时要注意MySQL查询结果不能直接返回给前端要在Flask视图中把游标查询结果转成Python列表和字典再用jsonify序列化。这里容易踩的坑是datetime和numpy类型不能直接JSON序列化需要先转成字符串或浮点数否则接口会直接报错。5.2 ECharts可视化组件配置可视化大屏我一般用ECharts做主体直接在HTML里引入echarts.min.js不需要额外安装npm包对毕业设计项目来说部署成本最低。ECharts的图表类型非常丰富而且中文文档齐全遇到问题检索很方便。大屏布局通常用栅格方式划分顶部放标题和全局统计中间放核心的图表区域底部放行为趋势和用户画像卡片。我常用的图表类型有这几个折线图展示行为趋势饼图展示行为占比漏斗图展示“点击到加购到收藏到购买”的转化链路散点图或热力图展示用户活跃时间分布再配合一个表格展示预测结果列表。漏斗图是这个项目的一个亮点因为它直接对应用户行为转化的业务逻辑。用ECharts的funnel类型把点击到购买的转化率画出来运营人员一眼就能看到哪个环节流失最严重。这个图做出来会明显提升大屏的完整度答辩时值得重点讲。不过要注意漏斗图的数据是四类行为的去重人数不是行为总数否则漏斗图会失真。图表配置上有个很实用的技巧ECharts的series绑定的是JavaScript数组而Flask接口返回的是JSON字符串所以前端要先把字符串转成对象再传给setOption。如果你用axios发请求数据是自动解析过的但手写fetch时一定要记得做JSON.parse很多人卡在这里半天图表不显示。5.3 前后端联调跨域、刷新和加载优化前后端联调阶段最常见的三个问题跨域、定时刷新和加载速度。跨域问题在毕业设计场景下一般不会遇到因为Flask的render_template直接返回前端页面前后端同源。但如果你把前端独立部署到别的端口浏览器就会拦截请求并报CORS错误解决办法是安装flask-cors扩展一行代码app CORS(app)就能解决。定时刷新方面大屏如果做成实时数据可以通过setInterval定时轮询后端接口比如每5秒刷新一次行为趋势图。这种方式实现简单、稳定性高适合数据更新频率不高的场景。如果数据量大建议改成手动刷新按钮避免请求频繁把数据库拖垮。加载速度优化方面MySQL大表查询慢的时候优先检查索引是否生效用EXPLAIN命令看执行计划。我实测过一个案例user_behavior表没有索引时统计接口要跑6秒加上联合索引后缩短到0.3秒。这个优化前后的对比非常直观写进论文里是很好的性能分析素材。6. 实测踩坑记录从训练到部署的问题排查手册这套系统从开发到部署我踩过的坑不少而且大部分都是文档里不会写的问题。下面把最常见的问题和解决办法整理出来你在实现过程中遇到类似情况可以直接对照排查。6.1 MySQL连接与数据存储的坑如果你用Python连接MySQL首选PyMySQL因为它是纯Python实现不用编译安装很省事。但要注意如果你用的是MySQL 8.x默认认证插件是caching_sha2_password早期版本的PyMySQL可能连不上报错信息是Authentication plugin。解决办法是升级PyMySQL到1.0以上版本或者在创建MySQL用户时明确指定mysql_native_password。两种方式都行但升级PyMySQL更省事。中文乱码是另一个高频问题。建表时统一指定utf8mb4字符集连接参数里加上charsetutf8mb4就能避免中文显示异常。如果从MySQL导出CSV文件后打开也是乱码记得用utf-8-sig编码保存Excel才不会显示乱。这个小细节很多人不注意等到写文档要导数据时才发现非常耽误时间。还有一个经常被忽视的点MySQL的DATETIME和timestamp字段存的是UTC还是本地时间。我建议项目里统一用北京时间写入应用层不要做转换否则预测结果和可视化页面的时间对不上排查起来非常浪费时间。特别是在做行为趋势分析时时间偏移几个小时折线图上的高峰时段就完全错位了。6.2 深度学习训练中的典型问题第一个问题是显存不足也就是OOM。这个问题在小显存显卡上特别常见解决办法就是把batch_size调小从128降到64或32序列最大长度截短比如从100截到50Embedding维度调小。如果还不行检查是不是有别的进程占了显存用nvidia-smi看一眼。千万别为了速度强行撑大batch_size模型跑不起来才是最大的问题。第二个问题是过拟合。训练集AUC很高验证集AUC却很低说明模型把训练数据背下来了。解决办法是增大Dropout、加L2正则、减少隐藏层维度同时把数据切分成训练、验证、测试三份严禁直接用测试集调参。测试集必须最后才碰这是深度学习的基本纪律。第三个问题是预测结果全是0或者全是1。出现这种情况九成是样本不平衡加阈值设置问题。模型输出的概率可能集中在0到0.1之间默认0.5阈值就把所有样本判成0。处理方法有两个先对样本做欠采样平衡再设置预测阈值时用验证集上F1最高的那个阈值而不是固定用0.5。计算最优阈值很简单用sklearn的precision_recall_curve遍历一遍就能找到。6.3 可视化页面的显示问题页面图表不显示第一件事是打开浏览器开发者工具看Console报错。常见的报错是Uncaught SyntaxError原因是Flask返回的JSON字符串里带了HTML标签或者注释前端在JS里直接嵌入了接口返回值导致语法错误。解决办法是把JSON数据放在变量里通过JSON.parse解析不要用模板字符串直接拼接。第二个问题是图表中文乱码。ECharts本身对中文支持很好乱码通常是页面的meta标签没设置charsetutf-8或者从数据库查出来的数据本身就是乱码。页面记得写数据入库时统一utf8mb4基本不会出问题。第三个问题是图表数据不刷新。如果你用了浏览器缓存页面刷新后还是旧数据可以在fetch请求里加上cache: no-store或者在URL后面加一个时间戳参数tDate.now()强制绕过缓存。这个方案简单有效适合所有浏览器。6.4 答辩前要准备的材料清单代码之外毕业设计要提交的东西通常还有开题报告、任务书、中期报告、毕业论文、答辩PPT、演示视频和源代码压缩包。材料清单看起来多但真正会让评委扣分的往往是源代码本身比如项目能不能跑起来、数据库初始化脚本有没有、README写不写运行步骤。我的建议是答辩前按下面几件事逐项过一遍。第一全新环境能不能跑通。找一台没装过项目依赖的电脑按README从零开始配置Python环境、导入MySQL、启动Flask、打开页面任何一步缺依赖都把它补到文档里。这一步能提前暴露所有环境问题别等到答辩现场才发现少装了某个包。第二演示数据要准备好。提前导入一份规模合适的数据集比如10万到50万条行为记录保证可视化页面有明显的数据图形预测接口能输出合理结果。不要现场导入大数据集加载太慢会让答辩体验很差甚至会让评委怀疑系统性能不行。第三把核心代码模块的注释补全。答辩时老师会翻代码重要的函数和模型结构处写清楚注释能显示你对代码的掌控力。注释不要写废话要写清这个函数输入是什么、输出是什么、为什么这么写。第四准备一份模型评估结果记录表包含基线模型和深度学习模型在AUC、F1、召回率上的对比。答辩时这张表一拿出来就说明你真的做过实验而不是照搬网上代码。我一般还会在表下面写一行小字备注说明训练集和验证集的数据量方便老师核对。第五提前录一份演示视频。即使现场环境出了问题也可以先放视频再补讲至少不会冷场。视频要注意画面清晰和操作流畅录制时先把页面加载好不要录到没数据的空白页。7. 最后分享一点我的实际体会这个题目我从头到尾做过不止一次每次都会在三个地方多花时间数据清洗和数据流设计、样本不平衡处理、前后端联调中的接口数据格式。这三处听起来都很基础但恰恰是决定项目能否顺利交付的关键。模型结构反而是相对固定的部分网上资料多照着主流方案做基本不会出大错。如果你真的要把这套系统当毕业设计做我建议先不要追求模型效果有多高而是先把从MySQL到可视化的数据链路彻底打通让页面能显示真实数据模型能输出预测结果。链路通了之后再回头优化模型效果、增加图表类型、丰富交互功能每一步都看得见进展答辩底气就会足很多。很多同学一上来就钻模型调参结果到交代码前一周才发现可视化页面还没搭数据接口也还没接好整个人都慌了。最后再分享一个小技巧训练模型时把每个epoch的AUC和loss输出存到日志文件同时用matplotlib画成曲线保存成图片。答辩演示的时候把这几张图放进PPT配合“我在第几轮发现过拟合、怎么调整、效果怎么变化”这样的真实经历讲绝对比放一堆理论术语要打动评委。这也是我在实际操作中受益最多的一个习惯推荐你试一试。本文还有配套的精品资源点击获取