1. 为什么毕业设计选这个题就业推荐系统不是简单是稳1.1 一个Python毕设题目的自我修养每年毕业季我都会被问到一个问题毕设选什么题目能又好过又不掉头发 说实话选基于Python的大学生就业信息推荐系统这个方向的人非常多但它真的不是某些人说的烂大街所以没含金量。恰恰相反这个题目在答辩老师眼里的评价往往是贴合实际、技术栈完整、有明确的应用价值。你想想看一个毕设题目最怕什么最怕老师问你你这个东西解决了什么问题的时候你只能说这是个XX管理系统能增删改查。就业推荐系统天然自带一个清晰的业务场景学生注册后填写自己的专业、技能、求职意向系统从采集到的招聘数据里筛选出匹配的岗位推荐给他。这个逻辑一句话能讲清楚三句话能画出架构图五句话能把算法聊明白这在答辩现场是巨大的优势。另外这个题目的技术栈覆盖面也好看Python爬虫、数据清洗、数据库设计、推荐算法、Web开发、前端页面全都能摆上台面。就算你只做了七十分写进论文里的工作量看起来也像九十分。对于大多数学校要求系统要有一定复杂度的评审标准来说这个选题属于性价比的天花板。1.2 评审老师最在意的几个点我在帮不少学弟学妹改过这类项目之后总结出答辩老师大概率会问的四个问题你把这个项目做完心里一定要有数推荐算法用的是什么为什么选它只要你能说出TF-IDF做文本特征 余弦相似度计算匹配度再用协同过滤做补充就比大多数只会调库的同学强了。数据从哪来不要只说爬的招聘网站要能说清楚爬了哪些字段、怎么清洗、存到哪。用户画像和职位画像是怎么构建的这是推荐系统的灵魂后面我会详细展开。系统有什么不足不要回答没有不足要说冷启动问题还没完全解决、数据量还不够大这是老师最想听到的诚实答案。把这四点捋顺你的毕设已经成功了一半。剩下的一半就是今天这篇文章要讲的核心——怎么把系统真正做出来。2. 整体架构设计先画好图再动手写代码2.1 技术选型实战Flask Jinja2 SQLite 够不够用很多同学上来就纠结Web框架选Django还是Flask数据库选MySQL还是SQLite推荐算法用surprise库还是自己写我的建议是如果你的目标是毕业设计Flask SQLite 是最稳的组合。原因很实在Flask足够轻量你不需要花两周去理解Django的ORM、Admin后台和中间件机制。对毕设来说能跑通、能讲清楚比什么都重要。SQLite零配置一个文件就是整个数据库拷贝到任何电脑上都能直接跑。如果你用MySQL评委老师想现场跑一下你的系统还得先装数据库、配账号密码平白给自己增加变数。算法部分自己写核心代码比直接调用现成库更有工作量可展示性。你可以用scikit-learn或者自己手写TF-IDF但相似度计算的核心逻辑一定要自己实现这是论文里能写公式、能贴代码的地方。至于前端别花太多精力。用Flask自带的Jinja2模板引擎渲染页面套一套Bootstrap的样式功能完整的页面效果就已经足够体面了。非要上Vue全家桶你大概率会在前后端联调上浪费两个星期。2.2 数据流与模块划分从爬虫到推荐结果的全链路整个系统的数据流我建议你一开始就画清楚。我的设计是这样的数据采集模块从招聘网站爬取职位信息包括职位名称、公司、薪资、城市、学历要求、技能标签、职位描述。数据清洗与存储模块对爬取到的文本做分词、去停用词、提取技能关键词存入SQLite数据库。用户画像模块用户注册时填写专业、学历、掌握技能、期望城市、期望薪资同时通过点击、收藏行为动态补充画像。推荐引擎模块加载职位画像和用户画像计算相似度输出Top-N推荐列表同时用协同过滤对结果做补充排序。Web展示模块登录注册、职位列表、推荐结果页、用户行为记录接口。模块之间用Python函数和SQLite作为接口逻辑清晰又不至于过度设计。你画架构图的时候就按这个分层画答辩PPT直接能用。3. 招聘数据采集与清洗推荐系统的燃料3.1 目标网站分析与爬虫实现推荐系统好不好用七成取决于数据质量。我当时选了某大型招聘网站的公开页面作为采集目标没有动用任何付费接口。你要是自己做建议也选信息结构清晰、不需要登录就能访问职位列表页的网站。核心爬虫代码不复杂用requestsBeautifulSoup就能完成。下面是我当时采集列表页和详情页的核心逻辑import requests from bs4 import BeautifulSoup import time import random headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def get_job_list(page): 抓取指定页码的职位列表页返回职位详情页链接列表 url fhttps://example.com/jobs?page{page} # 示意URL实际以目标网站为准 resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) links [] for item in soup.select(.job-card): # 具体选择器按实际页面调整 link item.get(href) if link and link.startswith(http): links.append(link) return links def fetch_job_detail(job_url): 抓取职位详情页返回结构化字段 resp requests.get(job_url, headersheaders, timeout10) if resp.status_code ! 200: return None soup BeautifulSoup(resp.text, html.parser) job_name soup.select_one(.job-name).text.strip() company soup.select_one(.company-name).text.strip() salary soup.select_one(.salary).text.strip() city soup.select_one(.city).text.strip() education soup.select_one(.edu).text.strip() desc soup.select_one(.job-desc).text.strip() return { job_name: job_name, company: company, salary: salary, city: city, education: education, description: desc }这里要特别提醒每个详情页请求之间务必加time.sleep(random.uniform(1, 3))否则请求频率太高很快会被封。我当时一开始没加延时抓了两百多个页面就被限流了后面学乖了才稳定抓到上万条数据。3.2 字段清洗与技能标签抽取原生的职位描述文本是不能直接用于推荐的原因是它包含大量负责参与根据这类没有区分度的词汇会严重干扰相似度计算。我做清洗的核心步骤是去HTML标签和特殊符号把 \n、\u3000、nbsp 等全部清掉。使用jieba分词中文职位描述必须分词然后用一个自定义停用词表去掉无意义虚词。正则匹配技能词这是关键技巧。因为技能标签Python、Java、MySQL、数据分析等对推荐结果的影响远大于普通描述词我维护了一个技能词典在文本中用正则做匹配命中就直接作为高权重特征。技能词典的示例SKILLS [Python, Java, C, MySQL, Redis, Flask, Django, 爬虫, 数据分析, 机器学习, 深度学习, TensorFlow, PyTorch, Linux, Docker, Kubernetes, Spring, Vue, React] def extract_skills(text): skills set() for skill in SKILLS: if re.search(skill, text, re.IGNORECASE): skills.add(skill) return list(skills)这一步做完职位数据就从一段描述文本变成了结构化字段 技能标签的形式推荐算法后续才有得算。3.3 数据库表结构怎么设计才不留隐患数据库设计别偷懒表结构直接决定了后期代码的复杂度。我最终用的是四张核心表表名核心字段用途userid, username, password_hash, major, education, city, skills, expected_salary, create_time存用户信息和画像jobid, job_name, company, salary_min, salary_max, city, education, description, skills, create_time存爬取的职位数据user_behaviorid, user_id, job_id, behavior_type, create_time记录浏览、点击、收藏行为recommendationid, user_id, job_id, score, rank, create_time保存推荐结果便于展示和复盘需要注意的几个细节密码字段一定要存哈希别用明文答辩老师很可能会看你的数据库设计salary_min和salary_max拆成两个整数字段不要存15-25K这种字符串否则后续薪资匹配没法做user_behavior表一定要有因为协同过滤算法全靠它喂数据。4. 推荐算法核心从TF-IDF到协同过滤的工程化落地4.1 为什么这个场景不用深度学习直接说结论毕业设计做就业推荐用深度学习是给自己找麻烦。你可能会看到很多论文用Word2Vec、BERT做文本表示但那是研究型硕士的玩法本科毕设的核心诉求是完整实现一个可运行的推荐链路不是在某个公开数据集上刷SOTA。用传统方法的好处是每个环节都可解释TF-IDF能说清楚为什么这个词权重高余弦相似度能说清楚两个文本在向量空间中的距离。答辩现场你能在白板上写出公式老师就很难在算法深度上继续追问。深度学习模型是黑盒回答起来反而被动。4.2 基于内容的推荐构建用户画像与职位画像基于内容的推荐核心思想就一句话找到和用户画像最相似的职位推荐给他。所以画像的一致性非常重要。职位画像我在清洗阶段已经构建了它长这样{ job_id: 1024, title_vector: [0.12, 0.0, 0.34, ...], skill_list: [Python, 爬虫, MySQL], city: 上海, salary_min: 12000, salary_max: 20000, education: 本科 }用户画像的结构类似由两部分合并静态画像注册时填写的专业、学历、技能、期望城市、期望薪资。动态画像根据用户在user_behavior表中点击、收藏的职位反向提取这些职位的技能标签加权合并到用户画像中。合到一起后我需要将双方的文本特征向量化。这里我用jieba.analyse.extract_tags提取文本关键词再用TF-IDF加权构建特征向量然后用余弦相似度算匹配分。4.3 相似度计算与Top-N推荐代码实现相似度计算我刻意没有直接调现成库而是自己实现了完整逻辑这部分代码是论文里的核心亮点你完全可以参考import math from collections import Counter import jieba.analyse def build_text_vector(text, top_k20): 提取文本的TF-IDF关键词构建权重向量 tags jieba.analyse.extract_tags(text, topKtop_k, withWeightTrue) return dict(tags) # {word: weight} def cosine_similarity(vec1: dict, vec2: dict): 手写余弦相似度计算 common_words set(vec1.keys()) set(vec2.keys()) if not common_words: return 0.0 dot sum(vec1[w] * vec2[w] for w in common_words) norm1 math.sqrt(sum(v * v for v in vec1.values())) norm2 math.sqrt(sum(v * v for v in vec2.values())) if norm1 0 or norm2 0: return 0.0 return dot / (norm1 * norm2)但是这里有个问题如果只用职位描述的文本相似度会出现薪资和城市完全不匹配但文本关键词撞了一大堆的离谱推荐。所以我还加了规则过滤和加权构成最终的匹配分计算公式score 0.55 * 文本相似度 0.25 * 技能重合度 0.20 * 硬条件匹配分硬条件匹配分包括城市相同加0.1学历要求小于等于用户学历加0.05期望薪资落在职位薪资区间内加0.05。这套加权逻辑不复杂但在实际推荐效果上远比纯文本相似度靠谱。4.4 用户协同过滤给系统加上行为反馈维度只靠内容推荐有个致命缺点如果用户的简历写得比较模糊文本特征的区分度就不够。这时候需要协同过滤来用脚投票——和你行为相似的同学他们喜欢的职位大概率也适合你。因为要毕业设计的可控性我没有上复杂模型用的是基于用户的协同过滤UserCF步骤如下从user_behavior表取出所有用户对职位的浏览/点击/收藏记录。计算用户之间的皮尔逊相关系数或余弦相似度找出与当前用户最相似的K个用户。在这K个用户喜欢的职位里排除当前用户已经看过的按出现频次和交互权重排序得到协同过滤推荐列表。这个模块不需要太大权重放在内容推荐结果的后面做个混合加权就够了。我当时给协同过滤设了0.25的权重虽然它的输出只占总推荐的三四分之一但很好地缓解了冷启动和简历信息不完整的问题。5. 系统功能落地注册登录、职位浏览、推荐展示5.1 用户偏好采集的交互设计很多毕设系统在推荐功能上失败不是算法不好而是根本没有采集到用户偏好数据。你想用户如果只是注册登录然后看推荐列表系统没有他的任何行为记录推荐就变成了根据注册信息猜猜不准是必然的。所以我做了三个简单但有效的处理注册信息尽可能结构化技能标签用复选框而不是让用户自己输入。这样数据库里存的就是统一的技能词不需要再做一遍映射。职位列表页埋行为记录用户在职位列表里点击某个职位时页面会通过Ajax请求把{user_id, job_id, behavior_typeclick}发送到后台接口后台写进user_behavior表。加入喜欢/不喜欢按钮这个交互能极大提升协同过滤的效果用户在推荐卡片上点感兴趣或者不感兴趣系统直接拿到正负反馈比隐性点击行为更可靠。5.2 推荐结果的展示策略推荐系统做完了前端怎么展示也是有讲究的。我当时踩过一个坑把Top-N推荐结果一次全展示出来用户一打开页面看到20条职位3秒就关掉了。后来改成分段式展示第一段0-5名标注为你精准推荐这是基于内容推荐算出的高置信结果。第二段6-10名标注和你相似的同学在看这是协同过滤的补充结果。第三段热门职位兜底给冷启动用户看。每张职位卡片上展示职位名称、公司、薪资区间、城市、学历要求以及3-5个技能标签。职位详情页再把完整描述和推荐理由展示出来推荐理由那一栏就写你的技能【Python】【爬虫】与职位要求匹配度较高这个细节在答辩演示时特别加分评委一看就理解你的系统逻辑了。6. 踩坑实录那些让你通宵的Bug与答辩陷阱6.1 反爬识别与封IP的应对方案爬虫被封是几乎每个人都会遇到的事。我第一次爬的时候用的是一段网上抄的并发采集代码速度快到没朋友然后十分钟后所有请求全部返回403。后面总结出来的经验是限速比伪装更重要。把并发改成串行每两次请求之间睡1~2秒一天也能稳定抓上几千条。User-Agent别只用默认的。把自己浏览器的UA复制过来用再随机从几个常见浏览器UA里切换。别贪。如果你只是想做一个能跑通的毕设演示爬5000条数据完全够用了不追求海量。另外提醒一下采集数据时不要在论文里写具体网站名也不要讨论绕过验证码的方法。所有答辩表述统一用通过网络爬虫采集公开招聘信息的说法即可避免涉及合规问题。6.2 推荐结果看起来不准的排查思路我一做完系统就自己做了一轮测试我把自己模拟成2024届计算机科学与技术专业、会Python和Java、想去上海的毕业生结果推荐列表里居然出现了北京的会计岗位。排查链路是这样的先看算法日志发现内容推荐的相似度分数其实排得很靠前问题是硬性条件的权重太小被文本相似度带偏了。调整权重比例把城市匹配和薪资匹配的权重从0.2加到0.35效果好了很多。又发现技能重合度计算有Bug——职位技能是从技能词典正则匹配的但用户的技能标签是注册时直接选的两边如果有同义词比如机器学习和ML就算不上重合。这个问题只能用维护同义词映射表来缓解。我想说的是推荐系统不是写完就完事的它需要你以真实用户的身份去走一遍完整流程。这一步做和不做答辩时的感受天差地别。6.3 无文档源码项目的自救清单这个项目标题里写着无LW文档说直白点就是网上流传的源码包没有配套论文需要你自己写。这反而给了你一个机会源码可以借鉴但论文和系统理解必须是你自己的。那你拿到一套别人的源码之后应该按什么顺序去啃给你一份我常用的源码读盘清单先跑起来安装依赖、启动服务、看功能页面。跑不起来的项目直接弃用别浪费时间。画出表结构把SQLite文件打开看看有哪些表、哪些字段这是理解系统的捷径。找到推荐核心的入口函数搜索recommend、similarity、score这类关键词直接定位算法实现。重写至少一个模块比如把别人写死的爬虫代码改成自己的目标网站把算法参数按自己的数据重调一遍。删掉所有拼凑感代码很多人下载的源码里有大段注释掉的代码、无用的import、测试垃圾数据这些都得清干净否则导师看一眼就知道是网上抄的。这个过程走完你对系统的理解深度会完全不一样后面写论文、准备答辩都顺理成章。回到最开始说的毕设选题没有完美答案但基于Python的大学生就业信息推荐系统绝对是一个下限很高、上限也不低的题目。它难不在算法有多顶天立地而在你能不能把一个数据流完整跑通——从爬虫到清洗从画像到推荐从后端到前端。这个过程里踩到的每一个坑都会变成你论文里的系统测试与分析章节和答辩现场的底气。如果你正准备做这个题别慌按顺序来三周完全够用。 Python就业推荐系统毕业设计：爬虫、TF-IDF与协同过滤完整实现
1. 为什么毕业设计选这个题就业推荐系统不是简单是稳1.1 一个Python毕设题目的自我修养每年毕业季我都会被问到一个问题毕设选什么题目能又好过又不掉头发 说实话选基于Python的大学生就业信息推荐系统这个方向的人非常多但它真的不是某些人说的烂大街所以没含金量。恰恰相反这个题目在答辩老师眼里的评价往往是贴合实际、技术栈完整、有明确的应用价值。你想想看一个毕设题目最怕什么最怕老师问你你这个东西解决了什么问题的时候你只能说这是个XX管理系统能增删改查。就业推荐系统天然自带一个清晰的业务场景学生注册后填写自己的专业、技能、求职意向系统从采集到的招聘数据里筛选出匹配的岗位推荐给他。这个逻辑一句话能讲清楚三句话能画出架构图五句话能把算法聊明白这在答辩现场是巨大的优势。另外这个题目的技术栈覆盖面也好看Python爬虫、数据清洗、数据库设计、推荐算法、Web开发、前端页面全都能摆上台面。就算你只做了七十分写进论文里的工作量看起来也像九十分。对于大多数学校要求系统要有一定复杂度的评审标准来说这个选题属于性价比的天花板。1.2 评审老师最在意的几个点我在帮不少学弟学妹改过这类项目之后总结出答辩老师大概率会问的四个问题你把这个项目做完心里一定要有数推荐算法用的是什么为什么选它只要你能说出TF-IDF做文本特征 余弦相似度计算匹配度再用协同过滤做补充就比大多数只会调库的同学强了。数据从哪来不要只说爬的招聘网站要能说清楚爬了哪些字段、怎么清洗、存到哪。用户画像和职位画像是怎么构建的这是推荐系统的灵魂后面我会详细展开。系统有什么不足不要回答没有不足要说冷启动问题还没完全解决、数据量还不够大这是老师最想听到的诚实答案。把这四点捋顺你的毕设已经成功了一半。剩下的一半就是今天这篇文章要讲的核心——怎么把系统真正做出来。2. 整体架构设计先画好图再动手写代码2.1 技术选型实战Flask Jinja2 SQLite 够不够用很多同学上来就纠结Web框架选Django还是Flask数据库选MySQL还是SQLite推荐算法用surprise库还是自己写我的建议是如果你的目标是毕业设计Flask SQLite 是最稳的组合。原因很实在Flask足够轻量你不需要花两周去理解Django的ORM、Admin后台和中间件机制。对毕设来说能跑通、能讲清楚比什么都重要。SQLite零配置一个文件就是整个数据库拷贝到任何电脑上都能直接跑。如果你用MySQL评委老师想现场跑一下你的系统还得先装数据库、配账号密码平白给自己增加变数。算法部分自己写核心代码比直接调用现成库更有工作量可展示性。你可以用scikit-learn或者自己手写TF-IDF但相似度计算的核心逻辑一定要自己实现这是论文里能写公式、能贴代码的地方。至于前端别花太多精力。用Flask自带的Jinja2模板引擎渲染页面套一套Bootstrap的样式功能完整的页面效果就已经足够体面了。非要上Vue全家桶你大概率会在前后端联调上浪费两个星期。2.2 数据流与模块划分从爬虫到推荐结果的全链路整个系统的数据流我建议你一开始就画清楚。我的设计是这样的数据采集模块从招聘网站爬取职位信息包括职位名称、公司、薪资、城市、学历要求、技能标签、职位描述。数据清洗与存储模块对爬取到的文本做分词、去停用词、提取技能关键词存入SQLite数据库。用户画像模块用户注册时填写专业、学历、掌握技能、期望城市、期望薪资同时通过点击、收藏行为动态补充画像。推荐引擎模块加载职位画像和用户画像计算相似度输出Top-N推荐列表同时用协同过滤对结果做补充排序。Web展示模块登录注册、职位列表、推荐结果页、用户行为记录接口。模块之间用Python函数和SQLite作为接口逻辑清晰又不至于过度设计。你画架构图的时候就按这个分层画答辩PPT直接能用。3. 招聘数据采集与清洗推荐系统的燃料3.1 目标网站分析与爬虫实现推荐系统好不好用七成取决于数据质量。我当时选了某大型招聘网站的公开页面作为采集目标没有动用任何付费接口。你要是自己做建议也选信息结构清晰、不需要登录就能访问职位列表页的网站。核心爬虫代码不复杂用requestsBeautifulSoup就能完成。下面是我当时采集列表页和详情页的核心逻辑import requests from bs4 import BeautifulSoup import time import random headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def get_job_list(page): 抓取指定页码的职位列表页返回职位详情页链接列表 url fhttps://example.com/jobs?page{page} # 示意URL实际以目标网站为准 resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) links [] for item in soup.select(.job-card): # 具体选择器按实际页面调整 link item.get(href) if link and link.startswith(http): links.append(link) return links def fetch_job_detail(job_url): 抓取职位详情页返回结构化字段 resp requests.get(job_url, headersheaders, timeout10) if resp.status_code ! 200: return None soup BeautifulSoup(resp.text, html.parser) job_name soup.select_one(.job-name).text.strip() company soup.select_one(.company-name).text.strip() salary soup.select_one(.salary).text.strip() city soup.select_one(.city).text.strip() education soup.select_one(.edu).text.strip() desc soup.select_one(.job-desc).text.strip() return { job_name: job_name, company: company, salary: salary, city: city, education: education, description: desc }这里要特别提醒每个详情页请求之间务必加time.sleep(random.uniform(1, 3))否则请求频率太高很快会被封。我当时一开始没加延时抓了两百多个页面就被限流了后面学乖了才稳定抓到上万条数据。3.2 字段清洗与技能标签抽取原生的职位描述文本是不能直接用于推荐的原因是它包含大量负责参与根据这类没有区分度的词汇会严重干扰相似度计算。我做清洗的核心步骤是去HTML标签和特殊符号把 \n、\u3000、nbsp 等全部清掉。使用jieba分词中文职位描述必须分词然后用一个自定义停用词表去掉无意义虚词。正则匹配技能词这是关键技巧。因为技能标签Python、Java、MySQL、数据分析等对推荐结果的影响远大于普通描述词我维护了一个技能词典在文本中用正则做匹配命中就直接作为高权重特征。技能词典的示例SKILLS [Python, Java, C, MySQL, Redis, Flask, Django, 爬虫, 数据分析, 机器学习, 深度学习, TensorFlow, PyTorch, Linux, Docker, Kubernetes, Spring, Vue, React] def extract_skills(text): skills set() for skill in SKILLS: if re.search(skill, text, re.IGNORECASE): skills.add(skill) return list(skills)这一步做完职位数据就从一段描述文本变成了结构化字段 技能标签的形式推荐算法后续才有得算。3.3 数据库表结构怎么设计才不留隐患数据库设计别偷懒表结构直接决定了后期代码的复杂度。我最终用的是四张核心表表名核心字段用途userid, username, password_hash, major, education, city, skills, expected_salary, create_time存用户信息和画像jobid, job_name, company, salary_min, salary_max, city, education, description, skills, create_time存爬取的职位数据user_behaviorid, user_id, job_id, behavior_type, create_time记录浏览、点击、收藏行为recommendationid, user_id, job_id, score, rank, create_time保存推荐结果便于展示和复盘需要注意的几个细节密码字段一定要存哈希别用明文答辩老师很可能会看你的数据库设计salary_min和salary_max拆成两个整数字段不要存15-25K这种字符串否则后续薪资匹配没法做user_behavior表一定要有因为协同过滤算法全靠它喂数据。4. 推荐算法核心从TF-IDF到协同过滤的工程化落地4.1 为什么这个场景不用深度学习直接说结论毕业设计做就业推荐用深度学习是给自己找麻烦。你可能会看到很多论文用Word2Vec、BERT做文本表示但那是研究型硕士的玩法本科毕设的核心诉求是完整实现一个可运行的推荐链路不是在某个公开数据集上刷SOTA。用传统方法的好处是每个环节都可解释TF-IDF能说清楚为什么这个词权重高余弦相似度能说清楚两个文本在向量空间中的距离。答辩现场你能在白板上写出公式老师就很难在算法深度上继续追问。深度学习模型是黑盒回答起来反而被动。4.2 基于内容的推荐构建用户画像与职位画像基于内容的推荐核心思想就一句话找到和用户画像最相似的职位推荐给他。所以画像的一致性非常重要。职位画像我在清洗阶段已经构建了它长这样{ job_id: 1024, title_vector: [0.12, 0.0, 0.34, ...], skill_list: [Python, 爬虫, MySQL], city: 上海, salary_min: 12000, salary_max: 20000, education: 本科 }用户画像的结构类似由两部分合并静态画像注册时填写的专业、学历、技能、期望城市、期望薪资。动态画像根据用户在user_behavior表中点击、收藏的职位反向提取这些职位的技能标签加权合并到用户画像中。合到一起后我需要将双方的文本特征向量化。这里我用jieba.analyse.extract_tags提取文本关键词再用TF-IDF加权构建特征向量然后用余弦相似度算匹配分。4.3 相似度计算与Top-N推荐代码实现相似度计算我刻意没有直接调现成库而是自己实现了完整逻辑这部分代码是论文里的核心亮点你完全可以参考import math from collections import Counter import jieba.analyse def build_text_vector(text, top_k20): 提取文本的TF-IDF关键词构建权重向量 tags jieba.analyse.extract_tags(text, topKtop_k, withWeightTrue) return dict(tags) # {word: weight} def cosine_similarity(vec1: dict, vec2: dict): 手写余弦相似度计算 common_words set(vec1.keys()) set(vec2.keys()) if not common_words: return 0.0 dot sum(vec1[w] * vec2[w] for w in common_words) norm1 math.sqrt(sum(v * v for v in vec1.values())) norm2 math.sqrt(sum(v * v for v in vec2.values())) if norm1 0 or norm2 0: return 0.0 return dot / (norm1 * norm2)但是这里有个问题如果只用职位描述的文本相似度会出现薪资和城市完全不匹配但文本关键词撞了一大堆的离谱推荐。所以我还加了规则过滤和加权构成最终的匹配分计算公式score 0.55 * 文本相似度 0.25 * 技能重合度 0.20 * 硬条件匹配分硬条件匹配分包括城市相同加0.1学历要求小于等于用户学历加0.05期望薪资落在职位薪资区间内加0.05。这套加权逻辑不复杂但在实际推荐效果上远比纯文本相似度靠谱。4.4 用户协同过滤给系统加上行为反馈维度只靠内容推荐有个致命缺点如果用户的简历写得比较模糊文本特征的区分度就不够。这时候需要协同过滤来用脚投票——和你行为相似的同学他们喜欢的职位大概率也适合你。因为要毕业设计的可控性我没有上复杂模型用的是基于用户的协同过滤UserCF步骤如下从user_behavior表取出所有用户对职位的浏览/点击/收藏记录。计算用户之间的皮尔逊相关系数或余弦相似度找出与当前用户最相似的K个用户。在这K个用户喜欢的职位里排除当前用户已经看过的按出现频次和交互权重排序得到协同过滤推荐列表。这个模块不需要太大权重放在内容推荐结果的后面做个混合加权就够了。我当时给协同过滤设了0.25的权重虽然它的输出只占总推荐的三四分之一但很好地缓解了冷启动和简历信息不完整的问题。5. 系统功能落地注册登录、职位浏览、推荐展示5.1 用户偏好采集的交互设计很多毕设系统在推荐功能上失败不是算法不好而是根本没有采集到用户偏好数据。你想用户如果只是注册登录然后看推荐列表系统没有他的任何行为记录推荐就变成了根据注册信息猜猜不准是必然的。所以我做了三个简单但有效的处理注册信息尽可能结构化技能标签用复选框而不是让用户自己输入。这样数据库里存的就是统一的技能词不需要再做一遍映射。职位列表页埋行为记录用户在职位列表里点击某个职位时页面会通过Ajax请求把{user_id, job_id, behavior_typeclick}发送到后台接口后台写进user_behavior表。加入喜欢/不喜欢按钮这个交互能极大提升协同过滤的效果用户在推荐卡片上点感兴趣或者不感兴趣系统直接拿到正负反馈比隐性点击行为更可靠。5.2 推荐结果的展示策略推荐系统做完了前端怎么展示也是有讲究的。我当时踩过一个坑把Top-N推荐结果一次全展示出来用户一打开页面看到20条职位3秒就关掉了。后来改成分段式展示第一段0-5名标注为你精准推荐这是基于内容推荐算出的高置信结果。第二段6-10名标注和你相似的同学在看这是协同过滤的补充结果。第三段热门职位兜底给冷启动用户看。每张职位卡片上展示职位名称、公司、薪资区间、城市、学历要求以及3-5个技能标签。职位详情页再把完整描述和推荐理由展示出来推荐理由那一栏就写你的技能【Python】【爬虫】与职位要求匹配度较高这个细节在答辩演示时特别加分评委一看就理解你的系统逻辑了。6. 踩坑实录那些让你通宵的Bug与答辩陷阱6.1 反爬识别与封IP的应对方案爬虫被封是几乎每个人都会遇到的事。我第一次爬的时候用的是一段网上抄的并发采集代码速度快到没朋友然后十分钟后所有请求全部返回403。后面总结出来的经验是限速比伪装更重要。把并发改成串行每两次请求之间睡1~2秒一天也能稳定抓上几千条。User-Agent别只用默认的。把自己浏览器的UA复制过来用再随机从几个常见浏览器UA里切换。别贪。如果你只是想做一个能跑通的毕设演示爬5000条数据完全够用了不追求海量。另外提醒一下采集数据时不要在论文里写具体网站名也不要讨论绕过验证码的方法。所有答辩表述统一用通过网络爬虫采集公开招聘信息的说法即可避免涉及合规问题。6.2 推荐结果看起来不准的排查思路我一做完系统就自己做了一轮测试我把自己模拟成2024届计算机科学与技术专业、会Python和Java、想去上海的毕业生结果推荐列表里居然出现了北京的会计岗位。排查链路是这样的先看算法日志发现内容推荐的相似度分数其实排得很靠前问题是硬性条件的权重太小被文本相似度带偏了。调整权重比例把城市匹配和薪资匹配的权重从0.2加到0.35效果好了很多。又发现技能重合度计算有Bug——职位技能是从技能词典正则匹配的但用户的技能标签是注册时直接选的两边如果有同义词比如机器学习和ML就算不上重合。这个问题只能用维护同义词映射表来缓解。我想说的是推荐系统不是写完就完事的它需要你以真实用户的身份去走一遍完整流程。这一步做和不做答辩时的感受天差地别。6.3 无文档源码项目的自救清单这个项目标题里写着无LW文档说直白点就是网上流传的源码包没有配套论文需要你自己写。这反而给了你一个机会源码可以借鉴但论文和系统理解必须是你自己的。那你拿到一套别人的源码之后应该按什么顺序去啃给你一份我常用的源码读盘清单先跑起来安装依赖、启动服务、看功能页面。跑不起来的项目直接弃用别浪费时间。画出表结构把SQLite文件打开看看有哪些表、哪些字段这是理解系统的捷径。找到推荐核心的入口函数搜索recommend、similarity、score这类关键词直接定位算法实现。重写至少一个模块比如把别人写死的爬虫代码改成自己的目标网站把算法参数按自己的数据重调一遍。删掉所有拼凑感代码很多人下载的源码里有大段注释掉的代码、无用的import、测试垃圾数据这些都得清干净否则导师看一眼就知道是网上抄的。这个过程走完你对系统的理解深度会完全不一样后面写论文、准备答辩都顺理成章。回到最开始说的毕设选题没有完美答案但基于Python的大学生就业信息推荐系统绝对是一个下限很高、上限也不低的题目。它难不在算法有多顶天立地而在你能不能把一个数据流完整跑通——从爬虫到清洗从画像到推荐从后端到前端。这个过程里踩到的每一个坑都会变成你论文里的系统测试与分析章节和答辩现场的底气。如果你正准备做这个题别慌按顺序来三周完全够用。