SpringBoot+爬虫+Hadoop+AI大模型：招聘推荐系统毕设全实践

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

一个毕业设计题目能同时把SpringBoot、爬虫、Hadoop、AI大模型这几个词串在一起，第一眼看上去像是把近几年的热点技术全塞进了一个项目里。但等你真把这个题目做下来，会发现它其实是一个很聪明的组合——既覆盖了传统后端开发的完整链路，又引入了大数据处理和智能推荐这两个加分项。我当初就是冲着这个题目的综合性选的它，前后做了将近三个月，踩了不少坑，也积累了一整套可以直接复用的实现思路。这篇就把整个项目的拆解过程、核心实现和避坑经验完整记录下来，给正在纠结选题或者准备复现类似系统的同学一个参考。

先说清楚这个项目到底在做什么。它本质上是一个垂直领域的招聘信息聚合平台，通过爬虫从公开渠道采集兼职岗位数据，存到MySQL和Hadoop里做存储与离线分析，后端用SpringBoot提供接口服务，前端展示岗位列表和详情，最后由AI大模型根据用户的浏览行为、偏好标签和历史交互数据生成个性化推荐结果。整个系统最核心的价值在于：解决兼职信息分散、筛选成本高的问题，同时通过推荐算法提升匹配效率。对于毕设而言，这个题目能同时展示你在后端开发、数据处理、算法应用三个维度的能力。

1. 项目整体设计与思路拆解

1.1 为什么选这个方向：痛点、热点与可完成性的平衡

选毕业设计题目，最忌讳的是两种极端：一种是纯管理系统，前后端加一张表，做完之后自己都觉得没底气；另一种是纯算法研究，理论推导写了一大堆，但系统落地能力展示不出来。这个题目好就好在它恰好落在中间——业务的复杂度适中，但技术链条特别完整。

从痛点角度看，兼职信息的获取渠道非常分散：学校群、招聘网站、本地论坛、公众号，想找一个靠谱的兼职得同时刷五六个平台。把这些信息聚合到一个平台上，本身就解决了真实需求。从技术角度看，这个题目的技术栈覆盖面非常广，SpringBoot管后端接口，爬虫管数据采集，Hadoop管数据存储与离线分析，AI大模型管智能推荐，每一个环节都有实打实的代码和配置可以展示，论文也有足够的素材写。

但要注意一个关键点：

这个题目不是要求你从零训练一个大模型，而是把大模型作为推荐系统的一个增强组件来使用

。这一点想明白之后，项目的可完成性就大大提升了。你不需要GPU服务器，不需要训练数据集，只需要调用成熟的API或者本地部署开源模型，把推荐逻辑和Prompt写好，就能实现"AI赋能"的效果。论文里的表述可以写成"基于大模型语义增强的个性化推荐方法"，听起来很专业，实现起来却在可控范围内。

1.2 整体架构与模块划分

整个系统的架构可以从数据流向的角度来理解，一共分为五层：

第一层是数据采集层，负责从公开网站上爬取兼职岗位信息，包括岗位名称、薪资、工作地点、发布时间、公司名称、岗位描述等字段。爬虫跑完之后，原始数据会先进入一个临时存储区，经过清洗、去重、字段标准化之后才入库。

第二层是数据存储层，MySQL存业务数据，Hadoop的HDFS存爬虫采集的原始文件和离线分析的结果数据，Hive负责做数据仓库的查询分析。这里要注意的是，MySQL和Hadoop是互补关系，不是替代关系：在线业务用MySQL保证查询性能，离线分析把数据同步到Hadoop去跑MapReduce或者Hive SQL。

第三层是后端服务层，SpringBoot对外提供RESTful接口，处理用户注册登录、岗位搜索、浏览记录、收藏、推荐请求等业务逻辑。这一层是系统的中枢，既要对接MySQL，也要通过API调用大模型服务。

第四层是算法推荐层，这一层实现了两种推荐策略的融合：基于协同过滤的传统推荐算法负责从历史行为中找相似用户和相似岗位，大模型负责对候选岗位做语义理解和个性化打分。简单来说，协同过滤解决"找得到"的问题，大模型解决"推得准"的问题。

第五层是前端展示层，用Vue或Thymeleaf实现用户界面，包括岗位列表、搜索筛选、岗位详情、个人中心、推荐结果页面。

1.3 技术选型背后的具体权衡

很多人在技术选型上容易犯一个错误：什么新用什么，完全不考虑毕设场景。实际上，选型的第一原则是"能在答辩时讲清楚原理"，第二原则是"能跑得起来"。

具体到项目的技术选型，我是这么权衡的：

SpringBoot版本选了2.7.x，没用最新的3.x。主要原因在于3.x是基于Jakarta EE的，很多网上教程里的依赖写法是旧的javax命名空间，遇到问题你搜解决方案时会发现大量过时信息。2.7.x兼容性最好，教程最丰富，作为毕业设计完全够用。

Hadoop选了3.3.x，配置伪分布式模式。很多学校课程里教的是Hadoop 2.x，但2.x在Mac和Windows上的兼容性问题比较多。3.3.x的配置过程和2.x差别不大，但稳定性好很多。对于单机毕设来说，伪分布式模式和完全分布式在功能演示上没有本质差别，你只需要在答辩时说明"生产环境可以扩展到完全分布式集群"即可。

爬虫框架我最终用了Requests + BeautifulSoup，而没有上Scrapy。原因很直接：这个项目的爬虫只需要采集几个特定网站的几个列表页和详情页，规则固定，数据量也就上万条，Scrapy的异步框架、中间件体系在这里属于杀鸡用牛刀，反而增加了调试成本。当然，如果你论文里需要写"基于Scrapy框架的分布式爬虫系统"，那可以换，但要做好被问细节的准备。

AI大模型这块，我用的是国内主流大模型的API接口，同时也在本地跑了一个轻量开源模型做对比实验。为什么不完全依赖本地模型？因为毕设机器的算力通常不支持跑太大的模型，而API调用延迟低、效果好、代码也相对简单。答辩时的解释口径是：系统支持两种模式，默认使用API方式，本地模型作为降级方案。

1.4 这个方案的优势与劣势

这个方案最大的优势是

每层都有可独立演示的成果

：爬虫跑完你能看到数据库里多了上万条真实数据，Hadoop分析完你能出一个统计图表，推荐模块能根据当前用户的行为实时返回不同的结果。每一层都有视觉反馈，这在答辩演示环节是非常加分的。

劣势也客观存在：技术栈太宽，意味着每一个技术点你都不可能挖得太深。所以论文里要有明确的主次之分——我的策略是把推荐算法作为核心创新点，数据和存储作为支撑，爬虫作为数据来源，SpringBoot作为业务承载。答辩时老师问任何一个环节，你都能对上，且不至于被追问到答不出来。

2. 核心细节解析与实操要点

2.1 数据采集层：爬虫设计、反爬应对与合规边界

爬虫模块是整个项目的数据源头，其重要性不言而喻。如果你的爬虫跑不通，后面所有环节都是空谈。我当时的采集目标是一些公开的招聘信息发布平台和论坛的兼职板块，采集字段包括岗位名称、薪资范围、工作地点、经验要求、学历要求、公司名称、岗位描述、发布时间、原始链接。

爬虫的具体实现方案如下：

首先是页面分析。用浏览器开发者工具观察目标页面的HTML结构，找出列表页中每个岗位卡片对应的标签和class名，然后构造请求。列表页通常需要翻页处理，观察URL参数规律，用循环控制页码即可。详情页的URL一般能从列表页中提取到，对每个详情链接发送一次请求，解析出完整字段。

import requests
from bs4 import BeautifulSoup

headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def parse_list_page(url):
resp = requests.get(url, headers=headers, timeout=10)
resp.encoding = "utf-8"
soup = BeautifulSoup(resp.text, "html.parser")
items = []
for card in soup.select("div.job-card"):
title = card.select_one("a.job-title").text.strip()
salary = card.select_one("span.salary").text.strip()
detail_url = card.select_one("a.job-title")["href"]
items.append({"title": title, "salary": salary, "detail_url": detail_url})
return items

其次是反爬应对。这里我踩过比较深的坑是：请求频率太高导致IP被临时封禁。解决方案有三层：第一层是User-Agent轮换，准备一个UA池，每次请求随机取用；第二层是请求间隔控制，用

time.sleep(random.uniform(2, 5))

模拟人工访问节奏；第三层是重试机制，遇到429或者503状态码时，等待一段时间后重新请求。

但更重要的不是技术，而是

合规边界

。一定要清楚：爬虫只能采集公开非敏感数据，必须遵守目标网站的robots协议，请求频率不能对目标服务器造成压力，采集到的数据不能用于商业用途，更不能采集任何个人隐私信息。毕设场景下，你还要在论文中明确说明数据来源的合法性和用途限定。我当时在论文里单独写了一节"数据采集合规性说明"，指导老师对这个细节的评价很高。

2.2 数据清洗与字段标准化

爬虫采集到的原始数据是脏乱差的，直接入库会出各种问题。常见的问题有这么几类：薪资字段格式不统一，有的是"100元/天"，有的是"3000-5000元/月"，有的是"面议"；工作地点有的精确到区，有的只到城市；岗位描述里可能有HTML标签残留；同一岗位可能被多个页面重复采集。

我设计了一套清洗流程：先去HTML标签，再按规则解析薪资字段，统一换算成"最低薪资、最高薪资、薪资周期、是否面议"四个字段；地点字段通过维护一个城市字典来做映射；重复数据用"标题+公司+地点"作为唯一键去重。清洗完成后，写一个数据质量统计脚本，输出记录总数、字段完整率、重复率等指标。这些数字后面写论文的时候直接用得上，比如"数据有效率从原始的82%提升到清洗后的97%"。

import re

def parse_salary(salary_str):
if "面议" in salary_str:
return None, None, "面议"
nums = re.findall(r"\\d+", salary_str)
if len(nums) == 0:
return None, None, "未知"
if "天" in salary_str:
period = "日薪"
elif "月" in salary_str:
period = "月薪"
elif "时" in salary_str:
period = "时薪"
else:
period = "未知"
if len(nums) == 1:
return int(nums[0]), None, period
return int(nums[0]), int(nums[1]), period

清洗完的数据，一份写入MySQL的业务表，另一份导出为CSV文件，后续上传到HDFS用于离线分析。

2.3 Hadoop伪分布式环境搭建与数据落地

Hadoop这部分是很多人的心理障碍，因为配置文件多、环境变量杂、启动报错五花八门。我当时是花了一天半把环境搭通的，这里把关键步骤和要点梳理一下。

首先是JDK版本匹配。Hadoop 3.3.x要求JDK 8以上，我用的是JDK 8，这个组合最稳。然后是SSH免密登录配置，伪分布式模式下NameNode和DataNode在同一台机器上，但Hadoop启动脚本仍然会通过SSH连接本机，所以需要生成密钥并配置到authorized_keys里。

配置文件要改的核心是core-site.xml、hdfs-site.xml和mapred-site.xml。core-site.xml里设置NameNode的地址和临时目录，hdfs-site.xml里设置副本数——伪分布式环境下副本数必须设为1，因为只有一个DataNode，默认的3个副本会导致启动时一直处于副本等待状态，日志里全是

Copying

相关的WARN。这个坑特别典型，我当时看到日志里数据块一直显示

UNDER_REPLICATED

，查了半天才找到原因。

讲一下数据怎么落进去。我写了一个简单的数据导入流程：先把清洗后的CSV文件从本地用

hdfs dfs -put

命令上传到HDFS的指定目录，然后在Hive里建外部表指向这个目录，这样就能直接写SQL做统计分析了。如果不想装Hive，也可以用MapReduce直接处理CSV，但MapReduce写起来效率低不少，而且Hive在答辩时展示效果更好——直接在命令行里敲

SELECT

语句就能出结果。

# 上传数据到HDFS
hdfs dfs -mkdir -p /user/hadoop/jobdata
hdfs dfs -put /home/ubuntu/data/job_clean.csv /user/hadoop/jobdata/

# 启动Hive并执行分析
hive
CREATE EXTERNAL TABLE job_info(
title STRING,
salary_min INT,
salary_max INT,
salary_period STRING,
city STRING,
company STRING,
publish_time STRING
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
STORED AS TEXTFILE
LOCATION '/user/hadoop/jobdata';

SELECT city, COUNT(*) AS cnt FROM job_info GROUP BY city ORDER BY cnt DESC LIMIT 10;

2.4 SpringBoot核心服务与接口设计

后端服务是整个平台的中枢，我按职责把模块拆成了用户模块、岗位模块、收藏模块、浏览记录模块和推荐模块。业务上有一个容易被忽略但很重要的设计：

用户画像的实时更新

。

用户在平台上每次搜索、浏览、收藏、投递，都应该实时反映到画像数据上。比如用户搜索了"家教"，浏览了三个"教育培训"类的岗位，收藏了一个"周末兼职"的岗位——这些行为累计起来就会形成用户标签权重。标签体系是我自己设计的，包括领域偏好、时间偏好、地点偏好、薪资期望四个维度。画像数据存放在MySQL里，用一个user_profile表维护，每次行为触发时更新对应维度的权重值。

接口设计上遵循RESTful风格，核心接口包括注册登录、岗位分页查询、条件筛选、岗位详情、收藏/取消收藏、获取推荐列表。这里要给一个提醒：

接口参数校验和异常处理一定要做完整

。毕设答辩时老师会翻你的代码，try-catch里只打日志不返回统一结果、参数没有校验直接查库，这些都会被看出来。

推荐接口是系统的核心，内部逻辑分三步：先从MySQL查用户画像和最近行为记录，然后调用协同过滤算法从岗位库中筛选出候选集合，最后把候选岗位信息拼接成Prompt发送给大模型，让大模型结合用户画像给出最终排序和推荐理由。返回结果中除了岗位列表，还包含推荐理由字段，这个字段是展示系统智能感的关键——"因为你近期浏览了多个教育培训类岗位，为你推荐这份周末家教兼职"，比干巴巴的岗位列表有说服力得多。

3. 实操过程与核心环节实现

3.1 从零搭建的完整时间线与实施顺序

一个完整的毕设项目，如果顺序搞反了，后期返工成本极高。我的建议是分五个阶段推进：

第一阶段做环境和基础工程。搭建SpringBoot项目骨架，配置MySQL数据库，搭好Hadoop伪分布式环境。这一阶段的目标是把所有环境问题暴露在最前面，而不是做到一半才发现Hadoop起不来。

第二阶段做爬虫和数据采集。目标是把数据量凑够，清洗后导入MySQL。这个阶段占总时间大约四分之一，但也是最容易失控的——网站改版、反爬加强、字段解析出错，都会消耗大量时间。我当时的经验是：优先保障数据量，先把采集链路跑通，再回头优化字段完整度。

第三阶段做业务功能。用户模块、岗位模块、搜索筛选、收藏、浏览记录，这些都是标准CRUD，难度不大，但要注意代码结构，Controller、Service、Mapper分层要清晰。

第四阶段做推荐引擎。先实现协同过滤的基础版本，跑通之后再接入大模型做增强。这个阶段是论文创新点的核心来源，花的时间最长，需要反复调试Prompt。

第五阶段做前端对接和联调。页面这里我用的是Vue3 + Element Plus，通过Axios调用后端接口。如果前端基础一般，也可以直接用Thymeleaf做服务端渲染，省掉跨域和打包的麻烦。

3.2 数据集的构建、扩增与质量保障

题目要求"上万数据集"，这个数字看起来很夸张，实际操作下来其实不难。我的数据集由三个来源构成：爬虫采集的真实数据、公开数据集补充、程序生成的模拟数据。

爬虫采集的部分是核心，大概占60%左右。这里不要贪多，集中采三到四个公开网站，把每个网站列表页和详情页的规则吃透，比广撒网效果好得多。公开数据集可以从一些开源数据平台找招聘相关的脱敏数据集，做字段映射后合并进来。程序生成的部分，我写了一个模拟数据生成器，基于真实数据的字段分布规律，随机生成补充数据。生成的逻辑是：先从已有数据中随机抽取一批"种子岗位"，再对这些岗位的标题、薪资、地点做规则变换，生成新的记录。这样既保证了数据量，又保持了字段的内在一致性。

关于数据集建设，我建议你输出一份完整的数据集说明文档，包括字段字典、数据量、来源说明、清洗规则、质量报告。这个文档不仅写论文时能直接引用，答辩时老师问"你的数据从哪来的"，你翻出文档就能讲得头头是道。

3.3 个性化推荐引擎的实现细节

推荐引擎是整个项目的灵魂，也是技术含量最高的部分。我把它拆成了三个子模块：用户画像构建模块、协同过滤推荐模块、大模型智能排序模块。

用户画像构建的核心是行为权重计算。我给不同行为设了不同权重：搜索3分、浏览1分、收藏5分、投递简历8分。每个岗位挂在特定的标签下，行为发生时把权重累加到对应的用户标签维度上。标签体系用两级结构，一级是行业（教育、IT、餐饮、零售、文员等），二级是具体技能要求。

协同过滤这里要注意冷启动问题。新用户没有任何行为数据，协同过滤直接失效。我的方案是用大模型做冷启动推荐：当用户画像为空时，直接让用户选择感兴趣的方向，然后把用户的选择描述发给大模型，让大模型帮忙生成推荐候选。这其实就是把大模型当作一个知识和推理引擎在用了。

大模型排序模块的Prompt设计值得好好展开。我当时测试了多个Prompt版本，最终效果比较好的是下面这种结构：

你是一名资深的兼职招聘顾问。请根据用户的行为偏好和画像数据，对候选的兼职岗位进行排序和评分。

用户画像：
– 所在城市：北京
– 偏好的领域：教育培训、IT互联网
– 可工作时间：周末
– 期望日薪：200元以上

候选岗位列表：
1. 周末家教（北京海淀区，300元/天，教育培训）
2. 餐厅服务员（北京朝阳区，150元/天，餐饮服务）
3. 数据标注兼职（远程，200元/天，IT互联网）

请根据用户画像对上述岗位进行匹配度评分（0-100分），按分数从高到低排序，并给出每个岗位的推荐理由。理由中需要引用用户画像中的具体信息。最后以JSON格式返回结果。

这个Prompt的关键点是：把用户画像中的数据全部注入到Prompt里，让大模型基于具体数据做判断，而不是泛泛地"为用户推荐优质岗位"。返回JSON格式是为了方便后端解析，避免回复多个格式。实际测试下来，大模型给出的排序结果和人工判断的匹配度相当高，推荐理由也足够自然，完全能支撑论文里"基于大模型语义理解的个性化推荐"这个表述。

3.4 前后端集成与系统整体效果

前端我用Vue3 + Element Plus做了几个核心页面：首页的岗位广场（支持分页和条件筛选）、岗位详情页、用户个人中心、推荐结果页。推荐结果页用卡片形式展示岗位，每张卡片上除了岗位基本信息，还有一个专门的推荐理由区域，用蓝色背景突出显示。

前后端联调过程中最常见的问题就是跨域。我的解决方式是在SpringBoot里配置全局CORS策略，允许本地前端的地址跨域访问。这个配置在开发阶段很实用，但如果后期要部署到同一台服务器上，可以考虑用Vue的代理方式，或者直接把前端构建产物放进SpringBoot的静态目录里，这样就不用担心跨域了。

系统整体跑通之后，建议录一段完整的演示视频作为答辩备份：从注册登录开始，展示搜索筛选、浏览记录、收藏操作，然后切到另一个账号或者清空Cookies后重新登录，展示推荐结果的变化。这段视频在答辩现场如果出现网络故障或者环境问题时会救你一命。

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

4.1 Hadoop与大数据模块的踩坑记录

Hadoop相关的问题在毕设里出现频率最高，而且报错信息往往让人迷惑。我这里把几个典型问题整理成表格。

根本原因

解决办法

其中权限问题是最容易混淆的。如果你用的是root用户操作Hadoop，经常会遇到权限报错，原因是HDFS默认权限控制。对于单机学习场景，直接把权限检查关掉是最省事的方案，虽然不算最佳实践，但对于毕设来说完全够用。论文里可以写"在实际生产环境中需要配置完善的多用户权限管理机制，本系统为简化部署采用单用户模式"。

4.2 爬虫稳定性与数据质量问题

爬虫最大的坑是"昨天还能跑，今天就跑不了"。目标网站改版、接口参数变化、添加了新的反爬机制，都可能导致采集失败。我维护爬虫稳定性的核心手段是：

模块化解析规则

。把所有网站的解析逻辑提取成独立的解析函数，网站改版时只需要改对应函数里的选择器，不用动整个爬虫。另外，爬虫要有断点续采能力——记录已经采集过的页面URL，下次启动时跳过已采集的，避免重复劳动。

数据质量方面，我建议在入库前加一轮自动校验：必填字段为空则丢弃该条记录；薪资格式解析失败则标记为"未知"，而不是直接丢弃；重复记录优先保留字段更完整的那条。清洗程序运行完输出一份质量报告，按数据源统计采集量、有效量、去重量，这些数字是论文中数据章节的重要素材。

4.3 AI大模型接入的常见坑

大模型接入在实现上并不复杂，就是HTTP请求，但有几个细节需要注意。一个是上下文长度限制，候选岗位数量多时，Prompt可能超过模型的单次最大token数。我的方案是把候选岗位压缩成"编号+标题+标签"的精简格式，而不是把完整岗位描述塞进去。另一个是超时和重试机制，API调用可能因为网络波动而失败，必须设置合理的超时时间并做好降级处理——失败时直接返回协同过滤的结果，不影响用户体验。

还有一个容易被忽视的问题：

接口返回内容的稳定性

。大模型的输出有概率出现格式不符合预期的情况，比如要求返回JSON却返回了自然语言。我在解析时做了兜底逻辑——正则提取JSON片段，提取失败就使用正则表达式从文本中解析岗位编号，再提取不出来就让推荐结果回退到协同过滤排序。这套降级机制保证推荐接口的可用率始终在95%以上。

4.4 论文写作与答辩演示的要点

论文方面，创新点不要写太多，两到三个就够，但每个要站得住。我论文的核心创新点写的是：一是构建了融合多渠道数据的兼职信息聚合模型；二是设计了一种基于协同过滤与大模型语义增强的混合推荐算法；三是实现了数据采集、存储、分析、推荐的全链路系统。每个创新点都要有对应的实现细节和数据支撑，不能只堆概念。

答辩演示的顺序非常重要，我踩过一个坑：有一次演示时先打开了推荐页面，结果因为冷启动问题推荐的岗位不够精准，被老师追问了很长时间。后来我调整了演示策略：先演示用户注册和行为数据积累过程，明确展示浏览和收藏操作，让画像数据有积累的时间，再打开推荐页面，这时候推荐结果的解释性就强很多。记住，

演示时你要讲的是一个完整的故事，而不是一个功能清单

。

提示：答辩时最有含金量的问题通常不是"怎么实现的"，而是"为什么用这个方案"和"如果遇到XX情况会怎样"。提前把每个技术选型的备选方案和取舍理由准备好，包括为什么不直接用MySQL做分析、为什么不自己训练模型、为什么不用Scrapy，这些问题在答辩前过一遍，现场会从容很多。

我个人在实际操作中最深刻的体会是：这个项目表面上是个毕业设计，实际上是把一个真实产品的最小闭环走了一遍。从数据采集到数据清洗，从业务开发到算法优化，从环境搭建到部署演示，每一个环节遇到的问题都是真实的工程问题，解决这些问题积累下来的经验，比最终的分数更有价值。如果让我重来一次，我会在爬虫阶段多花点时间做数据源扩展，在推荐阶段多做几组对比实验——前者能让数据集更有说服力，后者能强化论文的实验章节。但整体架构和节奏我认为是合理的，你可以在这个思路上根据自己的情况调整。