简介这是一套面向高校学生与Python初学者的毕业设计级实战项目资源聚焦淘宝用户购物行为分析与预测融合Web开发、大数据处理与深度学习技术栈。资源包含629个文件涵盖110个Vue前端组件、70个Python核心脚本含Spark数据处理与深度学习模型、68个JS交互逻辑、48个PNG/JPG可视化图表及2个SQL数据库初始化文件整体压缩包30.56MB结构清晰模块分离明确。已有91人下载学习适用于毕设选题、课程设计或工程实训尤其适合需快速搭建全栈数据分析系统的开发者。资源提供完整可运行环境含Django后端服务、Vue前端界面、Spider爬虫数据采集模块、Spark分布式计算管道及MySQL 5.7数据库支持并附带安装.bat、运行.bat、初始化Hive数据库.bat等实用工具脚本显著降低部署门槛助力从零掌握电商用户行为建模全流程。1. 项目整体定位与技术选型1.1 这个毕设到底在做什么先把这个项目看明白。标题里的“基于深度学习的淘宝用户购物可视化与行为预测系统设计”本质上是把电商数据分析的完整链路走一遍先通过爬虫拿到商品和用户行为数据然后交给Spark做清洗和特征加工再用深度学习模型预测用户接下来的购买倾向最后用Django把分析结果和预测结果做成可视化页面展示出来。这个选题在毕业设计里属于典型的“全栈型数据项目”它不要求你在某个单点上钻得非常深但要求你把数据采集、数据清洗、分布式计算、模型训练、Web开发这条流水线打通。很多同学毕设选题要么纯算法只跑模型不管数据从哪来要么纯管理系统只有CRUD没有分析价值而这个题目正好卡在中间——既有算法含量又有工程落地答辩时能讲的东西非常多。从就业角度讲这个项目覆盖的技术栈和实际工作中“数据分析工程师”或“数据产品后端”的日常高度重合。Spark处理离线数据、Django提供接口服务、爬虫解决数据来源问题、深度学习解决预测问题每一块都能在简历上单独拎出来说。1.2 为什么是Python Spark Django这套组合先回答一个最常见的问题为什么不能只用Python一把梭爬虫和模型训练用Python是因为生态最成熟requests/Scrapy、TensorFlow/PyTorch都是Python的天下。Spark负责大数据量的离线处理。淘宝级别的行为日志是海量的单机Pandas根本扛不住。Spark的RDD和DataFrame API能把计算分布到多节点上处理千万级数据也就是几分钟的事。Django负责业务系统搭建。它有完整的ORM、Admin后台、模板引擎和用户认证体系做可视化后台管理系统比Flask这种微框架省心得多尤其是涉及到登录权限、分页、表单验证这些通用功能时Django几乎是开箱即用。这三个组件各管一段职责清晰爬虫是“数据入口”Spark是“数据加工厂”深度学习模型是“数据分析大脑”Django是“对外展示窗口”。数据流向是单向的爬虫采集 → 原始数据落库 → Spark读取并清洗 → 特征工程 → 模型训练和预测 → 预测结果写回数据库 → Django读取并渲染到前端页面。很多同学拿到这个题目以后第一反应是“三个东西我不会”但实际上每一块的入门门槛都不算高。难的是理解它们之间的数据流转关系以及每个环节应该在哪一层做哪些事。1.3 这套架构的优势和潜在代价先说说这个架构的几点明显优势。第一每个模块可以独立测试和替换。比如爬虫被反爬限制导致数据量不够你不需要动Spark和Django的代码只要把数据源换掉就行模型效果不好你也只需要在模型训练模块里调参不影响其他部分运行。第二答辩时的“可展示性”极强。整套系统跑起来以后可视化大屏上能直接看到用户画像、销量排行、预测结果比纯算法项目讲PPT更加直观。第三技术栈覆盖面广评审老师无论擅长哪个方向都可以找到提问角度你也可以在多个方向上展示工作量。但这套架构也有代价。最大的问题是环境配置复杂Spark需要Java环境Django需要Python虚拟环境深度学习框架又要装CUDA或CPU版本的TensorFlow/PyTorch这几个环境凑在一起很容易出现依赖冲突。实际情况是很多人花在“调通环境”上的时间比写代码还多。我的建议是在项目初期就把环境分成三层隔离——Python虚拟环境管Django和爬虫依赖Spark单独跑在已配置好的集群或本地伪分布式环境里模型训练可以先用CPU版跑通再考虑GPU加速。如果确实遇到环境怎么也调不通的情况用Docker把Spark和Django分别容器化是后期推荐的兜底方案。2. 爬虫设计与数据采集2.1 淘宝数据怎么拿才合规先说一个比较现实的问题。很多人一看到“淘宝爬虫”就觉得是要去破解淘宝的反爬机制实际上正规的毕业设计完全不需要这么做。淘宝的PC端页面有非常强的反爬体系验证码、滑块、IP封禁都是常态新手在这里耗上两周不一定有结果。更合理的方案是使用淘宝开放平台提供的API或者直接寻找公开的淘宝用户行为数据集。学术界有一个非常经典的公开数据集叫做“User Behavior Data from Taobao”包含用户ID、商品ID、商品类目ID、行为类型点击、加购、收藏、购买和时间戳是阿里天池平台对外开放的。这份数据完全满足行为预测模型的训练需求而且是正规渠道获取的不存在合规风险。如果老师明确要求必须展示爬虫能力更切实际的思路是爬取那些没有强反爬的页面或者利用官方API的沙箱环境来做数据抓取演示。你也可以自己构造一套模拟数据生成器让老师看到你的爬虫模块具备“采集-解析-清洗-入库”的完整链路能力同时实际训练模型时使用更规范的数据集。这个思路在答辩时非常实用因为老师的关注点更多是你对整个技术链条的掌握程度而不是你真的爬到了多少淘宝线上数据。2.2 爬虫模块的代码结构设计即使只用演示性质的数据源爬虫模块本身也值得认真设计。我建议至少包含以下几个部分请求层负责发起HTTP请求处理Headers、Cookies、代理IP。解析层用BeautifulSoup或Scrapy的Selector解析HTML或直接解析JSON接口。清洗层过滤无效字段、去重、处理缺失值。存储层将结构化数据写入MySQL或CSV文件。以Python爬虫为例核心逻辑如下import requests import pandas as pd from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def fetch_page(url): resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.text def parse_items(html): soup BeautifulSoup(html, html.parser) items [] for li in soup.select(.item): title li.select_one(.title).get_text(stripTrue) price li.select_one(.price).get_text(stripTrue) items.append({title: title, price: price}) return items df pd.DataFrame(parse_items(fetch_page(https://example.com))) df.to_csv(taobao_demo.csv, indexFalse, encodingutf-8-sig)注意几个细节编码统一用utf-8-sig带BOM这样Excel打开CSV不会乱码请求一定要设置超时否则遇到坏链接会卡死整个爬虫暂停间隔一定要随机化避免请求频率太规律被识别为机器行为。2.3 爬虫采集与训练数据的字段对齐爬虫采集的字段和后续模型训练需要的字段必须提前对齐这是很多新手忽略的问题。如果爬虫是演示性质、模型训练用的是公开数据集那么你必须在代码里做好字段映射。常见的映射关系是公开数据集字段含义在爬虫演示数据中的对应物user_id用户ID模拟用户编号item_id商品ID商品编号category_id商品类目商品分类名称behavior_type行为类型点击/收藏/加购/购买timestamp行为时间采集时间还有一点值得提醒公开数据集里的时间戳通常是Unix时间戳格式使用时需要转换成年月日和星期几等特征这些东西在后面做特征工程时都会用到。建议在数据采集层就一次性把时间字段处理干净不要在Spark任务里反复做格式转换能省不少事。3. Spark数据处理与特征工程3.1 Spark在这套系统里到底做了什么很多人对Spark的认知停留在“一个更快的大数据计算框架”但放到这个项目里它具体干的事情有三件第一读取爬虫落库后的原始行为日志数据做数据清洗。包括去重、过滤异常值、统一时间格式、关联商品维度表。第二做用户行为数据的聚合统计比如每个用户的点击次数、购买次数、行为序列长度、活跃天数等。这些统计结果一方面直接用于可视化展示另一方面作为模型训练的特征。第三做训练集和测试集的划分。Spark的randomSplit方法可以按比例把用户行为数据拆成训练集和测试集保证划分结果的随机性和可复现性。Spark的数据处理能力在这里其实是“降维打击”的——几十万条数据用Pandas也够用但放到Spark里跑一方面可以展示你对分布式计算框架的掌握另一方面后续如果数据量增长到千万级别你的系统不需要做迁移。这也就是为什么很多毕设题目会指定Spark而不是单纯用Pandas本质上是在考察你对大数据工具链的认知。3.2 Spark环境搭建的关键步骤环境搭建是很多同学的痛点。本地开发建议用Spark伪分布式模式也就是单机模拟集群不需要真的搭三台服务器。步骤大致如下安装Java JDK 8或11配置JAVA_HOME环境变量。解压Spark安装包配置SPARK_HOME。在Python中安装pyspark库确保版本和Spark版本匹配。启动pyspark交互式环境测试。export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export SPARK_HOME/opt/spark export PATH$PATH:$SPARK_HOME/bin pyspark --master local[4]local[4]表示使用本地4个线程模拟4个执行器开发调试完全够用。如果电脑内存小于16G建议不要开太多线程local[2]即可。3.3 用户行为特征的提取模型训练的好坏很大程度上取决于特征工程做得好不好。对于淘宝用户行为数据推荐构建以下几类特征频次特征用户总点击次数、总加购次数、总收藏次数、总购买次数。转化特征加购率、收藏率、购买转化率。时间特征用户活跃天数、最近一次行为距今天数、平均每天行为次数。商品类目偏好用户最常点击的商品类目、该类目占总行为的比例。序列特征用户最近N次行为的类型序列例如“点击→点击→收藏→购买”这种路径。用Spark实现这些特征非常方便核心是groupByagg操作from pyspark.sql import SparkSession from pyspark.sql import functions as F spark SparkSession.builder.appName(feature_engineering).getOrCreate() df spark.read.csv(hdfs://localhost:9000/user_behavior.csv, headerTrue, inferSchemaTrue) user_stats df.groupBy(user_id).agg( F.count(behavior_type).alias(total_actions), F.sum(F.when(F.col(behavior_type) buy, 1).otherwise(0)).alias(total_buys), F.sum(F.when(F.col(behavior_type) cart, 1).otherwise(0)).alias(total_carts), F.sum(F.when(F.col(behavior_type) fav, 1).otherwise(0)).alias(total_favs), F.sum(F.when(F.col(behavior_type) pv, 1).otherwise(0)).alias(total_pvs), F.datediff(F.to_date(F.lit(2024-01-01)), F.to_date(F.max(timestamp))).alias(days_since_last_action) )这里有一个非常实用的经验把“是否购买”作为预测目标时要注意样本不平衡问题。真实电商场景中购买行为的占比通常不到10%如果直接用原始数据训练模型模型会倾向于把所有样本预测为“不购买”这样准确率虽然很高但没有实际意义。常用的处理方式是对负样本做下采样或者在损失函数里给正样本更高的权重。我们在第4部分会详细展开。3.4 Spark执行过程中的调优经验跑Spark任务时最常见的坑有两个。第一个是OutOfMemory即执行器内存溢出。遇到这种情况优先检查是不是数据倾斜——某个用户的行为记录特别多导致一个分区的数据量远大于其他分区。解决办法是使用repartition或salting方案即在连接键上加随机前缀后分散到更多分区再聚合。第二个坑是频繁的shuffle操作导致任务变慢。groupBy、join、distinct都会触发shuffle如果数据量不大尽量先用filter缩小数据集再做聚合。还有一个经验容易被忽略Spark任务写完后要有意识地做数据完整性校验。比如统计处理前后的记录数是否一致关键字段是否有空值。把校验逻辑写成一个独立的检查脚本每次跑完流程之后自动执行一遍能省去很多调模型时才发现数据有问题的返工时间。4. 深度学习行为预测模型搭建4.1 行为预测问题的定义与建模用户行为预测本质上是一个二分类问题给定一个用户在某个时间窗口内的历史行为序列预测他在下一个时间窗口内是否会购买某类商品。把这个问题定义清楚比调模型参数更重要因为它直接决定了你怎么构造训练样本。我在项目里采用的是“固定窗口滑动”的建模方式。具体来说取用户最近7天的行为数据作为输入特征预测接下来1天内是否会发生购买行为。这样构造出来的样本集中每一条记录代表一个用户在某个时间点的行为状态。这样做的好处是样本量可以成倍增加——同一个用户在不同天可以切出多条样本。样本构造的伪代码如下def build_samples(behavior_df): samples [] for user_id, group in behavior_df.groupby(user_id): group group.sort_values(timestamp) for i in range(7, len(group)): history group.iloc[i-7:i] # 最近7天行为 target 1 if group.iloc[i][behavior_type] buy else 0 samples.append(extract_features(history), target) return samples这里有一点要特别注意在构造样本时不能使用未来信息。也就是说预测当天之前的历史行为可以用作特征但预测点之后的行为绝对不能混进特征里否则会造成“数据泄露”模型在训练集上表现极好一到真实场景就崩盘。这是深度学习项目里最容易犯的错误。4.2 模型结构怎么选择针对这个项目我推荐从简单到复杂尝试三种模型排列顺序也是我实际调试的顺序逻辑回归Logistic Regression作为基线模型验证特征和标签之间是否存在基本的线性关系。用sklearn直接跑几分钟出结果。LightGBM梯度提升树模型对表格型特征的效果通常优于深度学习模型特征重要性可解释性强答辩时方便讲“哪些特征对预测结果影响最大”。LSTM或GRU适合直接建模用户行为序列把“点击-收藏-加购-购买”这种序列关系学进去更贴合“深度学习”这个题目。如果说老师对“深度学习”有硬性要求那就必须上LSTM或GRU。我建议直接用GRU因为它的参数比LSTM少训练速度更快在小数据集上的效果与LSTM基本持平。用TensorFlow/Keras实现GRU的代码框架import tensorflow as tf from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Embedding, GRU, Dense, Dropout model Sequential([ Embedding(input_dim10000, output_dim128, input_length7), GRU(units64, return_sequencesFalse), Dropout(0.3), Dense(units32, activationrelu), Dense(units1, activationsigmoid) ]) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy])模型结构并不复杂。Embedding层负责把行为类型和商品类目映射成稠密向量GRU层学习行为序列的时序依赖关系最后一层sigmoid输出购买概率。关键点是序列长度设置——这里统一用7是因为我们的窗口是7天如果窗口改成14天这里的input_length也要对应调整。4.3 样本不平衡处理与评估指标前面提到过购买行为占比低的问题这里给出具体处理方案。第一种方案是负样本下采样假设正样本1万条负样本10万条从负样本里随机抽1万条组成2万条的新训练集。这样模型训练速度快正负样本均衡但代价是丢弃了大量负样本信息模型可能高估购买概率。第二种方案是损失函数加权计算正负样本比例把正样本的损失权重调大。Keras里可以用class_weight参数class_weight {0: 1.0, 1: 5.0} model.fit(X_train, y_train, class_weightclass_weight, epochs10, batch_size128)这样不丢弃样本模型能学到完整的负样本分布同时通过提高正样本的惩罚力度来缓解偏向问题。评估指标上不能用准确率作为唯一指标。因为即使把所有样本都预测为负类准确率也可能高达90%以上。建议同时关注AUC衡量排序能力对不平衡样本不敏感是最核心的离线指标。召回率预测为购买的用户中真正购买的比例。对于电商场景召回率稍微低一点可以接受因为本来就不是每个用户都会买。F1-Score精确率和召回率的调和平均适合在两类错误代价相近时使用。答辩的时候能解释清楚“为什么不用准确率”本身就是加分项。4.4 模型训练过程的实际操作训练过程中有几点实操经验值得记录第一训练集和测试集的划分要在“用户”维度上进行而不是在“样本”维度上。也就是说同一个用户的样本只能出现在训练集或测试集中不能两边都有。否则同一个用户的相似行为会同时出现在训练和测试里评估结果会虚高。from sklearn.model_selection import train_test_split unique_users df[user_id].unique() train_users, test_users train_test_split(unique_users, test_size0.2, random_state42) train_data df[df[user_id].isin(train_users)] test_data df[df[user_id].isin(test_users)]第二深度学习模型训练时要固定随机种子否则每次跑出来的结果都不一样后续调试没法对比。import random import numpy as np import tensorflow as tf random.seed(42) np.random.seed(42) tf.random.set_seed(42)第三保存模型时建议同时保存训练参数和数据预处理逻辑。这样后面做可视化展示时Django可以通过加载模型文件来对新数据做预测而不是每次预测都重新跑一遍训练流程。model.save(behavior_predict_model.h5) # 同时用joblib保存特征列名 import joblib joblib.dump(feature_columns, feature_columns.pkl)5. 可视化平台与Django后端实现5.1 可视化大屏到底展示什么可视化的设计不是随便堆图表而是围绕“用户购物行为”这个主题组织信息。我在项目中把可视化分为四个板块用户画像板块用户性别分布、年龄分布、地域分布如果数据有这些维度的话。商品分析板块热门商品Top10、商品类目销量占比、价格区间分布。行为分析板块用户行为类型分布点击/收藏/加购/购买占比、按小时统计的用户活跃度折线图、按星期统计的购买趋势图。预测结果板块模型预测购买概率Top10用户列表、预测购买概率分桶分布图。这四个板块基本覆盖了“描述性分析”和“预测性分析”两个层次答辩时可以分别讲述“我们从数据里看到了什么”和“我们能用模型预测什么”。5.2 Django项目的核心要点Django负责把模型分析结果呈现到网页上。这里不展开完整的Django教程只讲几个关键环节。首先是项目结构设计。建议在Django项目里创建两个app一个叫analysis负责读取Spark处理好的结果数据并提供图表API另一个叫users负责用户注册登录和权限管理。Django自带Admin后台也可以直接复用管理数据条目非常方便。其次是数据读取方式。Spark处理好的结果表存放在MySQL中Django通过ORM模型映射到数据库表。常用的表有from django.db import models class UserBehaviorStat(models.Model): user_id models.CharField(max_length64) total_pv models.IntegerField(default0) total_buy models.IntegerField(default0) buy_rate models.FloatField(default0.0) predict_score models.FloatField(default0.0)ORM模型建好之后执行python manage.py makemigrations和python manage.py migrate数据库表就自动创建好了不需要手写SQL。第三是图表渲染方式。推荐使用ECharts通过Django的JsonResponse把数据以JSON格式传给前端前端用JavaScript渲染图表。核心套路是from django.http import JsonResponse from .models import UserBehaviorStat def behavior_stats_api(request): stats UserBehaviorStat.objects.all()[:100] data { user_ids: [s.user_id for s in stats], buy_rates: [s.buy_rate for s in stats], } return JsonResponse(data)前端在页面中用fetch请求这个API拿到数据后塞给ECharts初始化实例。这种前后端分离的实现方式虽然简单但足够清晰答辩时也很好讲。5.3 模型预测结果怎么和Django打通模型的预测结果要进入Django展示中间涉及一个“离线预测写入”的步骤。我的做法是写一个独立的Python脚本定时从MySQL读取最新用户行为数据用训练好的模型做批量预测把预测分数写回数据库的predict_score字段。import joblib import pandas as pd from django_orm_setup import init_django init_django() from analysis.models import UserBehaviorStat model joblib.load(behavior_predict_model.pkl) feature_cols joblib.load(feature_columns.pkl) # 从数据库读取用户特征 df pd.DataFrame(list(UserBehaviorStat.objects.all().values())) X df[feature_cols] df[predict_score] model.predict_proba(X)[:, 1] # 批量写回数据库 for _, row in df.iterrows(): UserBehaviorStat.objects.filter(user_idrow[user_id]).update( predict_scorerow[predict_score])这里有个关键点Django的ORM需要在Django项目环境下运行才能访问数据库。单独跑脚本时必须设置DJANGO_SETTINGS_MODULE环境变量并调用django.setup()否则会报“AppRegistryNotReady”错误。import os, django os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings) django.setup()5.4 Django部署与运行时的常见坑本地运行时用Django自带开发服务器就够了python manage.py runserver 0.0.0.0:8000但有两个问题容易踩到。第一是跨域问题。如果你用前后端分离模式开发前端跑在某个端口Django跑在8000端口浏览器会阻止跨域请求。解决办法是使用django-cors-headers库安装后在MIDDLEWARE中添加对应配置。更简单的办法是直接用Django的模板系统渲染页面前端代码写在templates目录里这样就不存在跨域问题。对于毕设项目后一种方案更省事也更符合Django“全家桶”哲学。第二是静态文件的问题。页面引用的CSS、JS文件要放在static目录下并在settings.py里配置好静态文件路径。开发环境下Django会自动处理但部署到生产环境时需要额外收集静态文件到指定目录。6. 常见问题与排查技巧实录6.1 项目中最常遇到的五个问题这套系统涉及组件多问题自然也多。我把自己实际调试中遇到的经典问题整理成一张速查表这些问题在答辩前的自测阶段也很值得逐条检查问题现象可能原因解决方法Spark任务启动后一直卡住资源分配不足或Java版本不兼容检查JAVA_HOME切换JDK8将spark.executor.memory调小模型预测结果全是0样本不平衡导致模型偏向负类使用class_weight或对负样本做下采样Django页面图表不显示前端请求API失败或JSON格式错误打开浏览器开发者工具检查Network面板爬虫采集数据为空网页结构变化导致解析失败查看HTML源码更新CSS选择器数据库中文乱码表字符集不是utf8mb4建表时指定CHARACTER SET utf8mb46.2 深度排查的具体案例挑一个比较典型的案例细讲模型预测概率始终在0.5附近徘徊AUC也只有0.60左右。这种情况我排查过很多次最终定位到的原因通常是特征维度不够或者特征信息泄露。排查思路是这样的。先用LightGBM的特征重要性看哪些特征对预测贡献最大。发现排名靠前的特征全是时间类特征比如“最后一次行为距今天数”而真正的行为序列特征贡献很低——原因是构造序列特征时用的都是行为类型的数字编码但没有做EmbeddingGRU学到的东西有限。后来把特征改成“行为序列商品类目序列时间间隔序列”三通道输入AUC从0.60提升到了0.75左右。这个案例说明一个通用的排查方法模型效果不好先不要急着调参回到特征层面看有没有信息被浪费掉。深度学习的特征工程和传统机器学习一样重要。6.3 时间管理上的避坑建议给即将开始做这个毕设的同学一个时间分配的参考。我见过太多人在环境配置上耗费三周以上这是最大的坑。建议按以下节奏推进第一周搭好Python虚拟环境、Spark环境、Django项目骨架跑通一个“Hello World”级别的数据流。第二周实现爬虫和数据入库搞定公开数据集完成字段映射。第三周Spark清洗和特征工程产出用户行为特征表。第四至五周模型训练与调优完成离线评估。第六周Django可视化页面开发和接口对接。第七周整体联调、撰写论文、准备答辩PPT。这个节奏的前提是环境问题必须在一周内解决。解决不了就换方案比如用Docker替代手动安装或者直接用云服务器代替本地环境。7. 扩展方向与实战体会这个项目的可扩展性其实比想象中大很多。如果你还有余力可以考虑以下几个方向来增加亮点。第一个方向是引入实时计算。现在是Spark做离线批处理后面可以引入Kafka Spark Streaming实现用户行为数据的准实时分析和预测。用户在淘宝上刚点击了一个商品几分钟内系统就能更新他的购买概率这个能力放到答辩现场会非常有冲击力。当然这需要额外搭建消息队列环境工作量不小适合学有余力的人。第二个方向是模型升级。现在用GRU做行为序列建模可以考虑换成Transformer的编码器结构或者用阿里开源的BST模型Behavior Sequence Transformer。这个方向紧跟学术界前沿论文里也好写“我们对比了GRU和Transformer结构在用户行为建模上的效果差异”。第三个方向是完善系统功能。比如增加用户画像标签体系、商品推荐模块、行为路径漏斗分析等。这些功能不需要改动现有架构在Django里追加API和页面即可。最后分享一些个人的实际体会。做这类综合系统真正的难点不是某一个单独的技术点而是“数据流转的闭环”。爬虫拿到数据要懂清洗Spark洗完特征要懂怎么喂给模型模型预测完要懂怎么展示给用户。很多同学一开始会执着于把某个点做得很深比如花一个月调模型参数结果发现后面没时间做可视化最后展示效果大打折扣。我的建议是先把整条链路用最简单的方式跑通再回到每个环节去优化。先跑通能保证你在任何时间节点都有一个可以演示的成果这是毕设和真实项目中通用的原则。还有一点经验值得分享答辩时老师很少关心你的模型AUC是0.75还是0.80他们更关心的是“你为什么要选这个方案”、“你踩过什么坑”、“你是怎么解决的”。所以在做项目的过程中随手记录调试日志和问题解决过程比最后硬背论文有意义得多。这些素材正是答辩现场最真实、最有说服力的素材。本文还有配套的精品资源点击获取
