简介《基于PythonDjango的招聘信息协同过滤推荐系统》是一份面向软件开发者、算法工程师及大数据分析人员的毕业设计级项目文档适合在在线招聘平台或HR管理系统中实现智能岗位匹配与个性化推荐。资源以1份docx文档打包共3.83MB虽为单文件但内容完整覆盖从系统需求分析、功能设计到协同过滤算法落地的全过程并给出部分核心源代码、测试与性能分析结果。文档结合Python语言、Django框架及MySQL数据库围绕数据预处理、相似度计算、候选集生成和结果整合等关键环节展开同时讨论了模型评估标准与技术难点解决方案兼顾理论讲解与工程实现。已有170人学习下载对于希望从零搭建推荐系统或优化现有推荐算法的读者可作为参考方案和代码蓝本尤其有助于理解B/S结构下协同过滤的实际应用。 三年前我换工作那会儿每天下班后的固定动作就是打开三四个招聘App挨个刷职位筛掉一大堆“高级Java工程师”“资深架构师”这类明显无关的岗位真正投出去的却没几个。后来我索性自己动手用Python搭了一套基于Django的招聘信息协同过滤推荐系统把“人找岗位”变成“岗位找人”。这篇博文把整套系统从数据建模、算法实现到Django工程落地的完整过程记录下来适合正在做推荐方向课程设计、毕业设计或者想深入了解Django怎么和推荐算法结合的同学参考。系统本身不复杂但里面涉及的行为权重设计、矩阵稀疏处理、冷启动方案都是实际跑过数据才摸出来的经验看完可以直接照着复现。1. 招聘推荐为什么绕不开协同过滤1.1 招聘场景的推荐目标和其他推荐不完全一样推荐系统在电商、资讯、短视频领域已经很成熟但招聘领域有自己的特殊性。用户在招聘平台上的关键行为是投递简历而不是浏览、点赞或者加购物车。所以推荐的最终目标不是点击率而是“投递转化率”和“人岗匹配满意度”。如果做一个纯内容推荐也就是拿岗位JD的关键词和用户简历做文本匹配乍一看很合理实际做下来效果并不好:大部分JD的措辞高度模板化“熟悉Python”“有团队协作经验”“本科以上学历”这类描述几乎出现在每个岗位里TF-IDF算出来的文本相似度区分度很低。至于用规则去匹配技能标签维护成本更高因为岗位技能的组合更新太快规则永远追不上新出现的岗位方向。1.2 协同过滤的价值在于挖掘隐性关联协同过滤的核心思路是从用户的历史行为里找规律:用户A投过岗位X用户B也投过岗位X同时用户B还投了岗位Y那么岗位Y值得推荐给用户A。这个过程中不需要理解JD语义只需要行为数据足够多。放在招聘场景里它的合理性在于:一个求职者投过什么岗位反映的是他的技能、薪资期望、通勤范围、行业偏好等综合信息这些东西很难用几个标签完整描述但行为数据天然把它们压缩成了一个可计算的坐标点。我在设计这套基于Django的招聘信息协同过滤推荐系统时也认真评估过替代方案:基于内容的推荐、基于规则的推荐、以及协同过滤。最终坚定选择协同过滤为主有两个核心原因。一是招聘行为数据的关系结构天然适合建模成用户-职位评分矩阵Django的ORM处理这种关系型数据非常顺手。二是协同过滤能自动发现长尾职业路径的变化比如这几年数据分析岗位大量出现老的规则库很难及时覆盖但用户行为数据很快就能反映出这种需求迁移。当然协同过滤也有它的短板——冷启动问题这个我在第5章专门讲。2. 数据模型设计:把用户行为变成可计算的评分矩阵2.1 从零搭建Django项目时的模型定义先说一下开发环境:Python 3.10以上Django 4.x数据库用PostgreSQL代码编辑器用VSCode配好Python解释器就行。创建项目和app的过程比较常规:django-admin startproject recruit_recommend cd recruit_recommend python manage.py startapp users python manage.py startapp jobs python manage.py startapp analytics我把核心数据模型分成三块:用户、职位、行为记录。Django里的models长这样:# users/models.py from django.db import models class User(models.Model): username models.CharField(max_length64, uniqueTrue) skill_tags models.JSONField(defaultlist) # 技能标签如[Python, Django] expected_salary models.IntegerField(nullTrue, blankTrue) # 单位K city models.CharField(max_length32, blankTrue) class Job(models.Model): title models.CharField(max_length128) company models.CharField(max_length128) city models.CharField(max_length32) salary_min models.IntegerField() salary_max models.IntegerField() tags models.JSONField(defaultlist) description models.TextField() created_at models.DateTimeField(auto_now_addTrue) class Behavior(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) job models.ForeignKey(Job, on_deletemodels.CASCADE) behavior_type models.CharField(max_length16) # view/favorite/apply/block created_at models.DateTimeField(auto_now_addTrue) class Meta: indexes [ models.Index(fields[user, job]), models.Index(fields[job, user]), ]2.2 每个关键字段的设计考量Behavior模型是最核心的。我用behavior_type字符串存行为类型而不是单独建收藏表、投递表、浏览表原因很简单:推荐系统最终需要的是用户-职位行为矩阵一张统一的行为表可以非常方便地做分组统计和矩阵构建。如果拆成多张表尽管业务上更规范但每次构建训练数据都要做UNION查询数据量上来之后性能会很难看。Job表的tags字段我用的是JSONField存的是职位标签数组比如[Python, Django, 后端开发]。这些标签主要用于冷启动阶段的内容回退推荐以及在相近相似度分数下做排序加权不会作为协同过滤主算法的输入。行为权重这里需要提前想清楚:不能把浏览、收藏、投递一视同仁。我最终采用的权重方案是:行为类型权重原因浏览1弱信号可以反映初步兴趣收藏3明确兴趣信号投递5最强正反馈屏蔽-4强负反馈避免推荐同类职位提示:block行为一定要记录。推荐系统里负样本和正样本同样重要不加负反馈的推荐结果会越推越偏。2.3 高分稀疏矩阵问题如果直接拿行为表做协同过滤用户-职位矩阵的稀疏度通常超过99%——大多数用户只对极少数的职位产生过行为这是招聘场景的天然属性。稀疏度过高时UserCF的效果会明显下降因为很难找到足够多的“相似用户”。我应对稀疏性问题做了两件事。第一主算法采用ItemCF而不是UserCF后面会详细讲原因。第二在构建评分矩阵时加入“全局热门度惩罚”也就是对热门职位的行为评分做降权避免少数头部职位主导相似度计算。实现方式也很简单参考了类似TF-IDF的思路给每个职位的共现次数乘一个衰减系数这个细节在实际效果调优中帮助很大。3. 协同过滤算法落地:相似度计算与推荐生成3.1 基于用户的协同过滤(UserCF)实现UserCF的核心思路是找到与你行为最相似的一批用户把他们喜欢但你还没接触过的职位推荐给你。相似度计算我用的是余弦相似度:similarity(u, v) sum(r_ui * r_vi) / (sqrt(sum(r_ui^2)) * sqrt(sum(r_vi^2)))简化版实现如下重点在建倒排索引和共现计数:# recommend/user_based.py import math from collections import defaultdict def build_user_similarity(action_matrix): # action_matrix: {user_id: {job_id: weight}} # 先构建倒排表: 每个job被哪些user行为过 item_users defaultdict(list) for user, items in action_matrix.items(): for item in items: item_users[item].append(user) # 统计用户间共同行为过的job数 co_occurrence defaultdict(lambda: defaultdict(int)) for item, users in item_users.items(): for i in range(len(users)): for j in range(i 1, len(users)): u1, u2 users[i], users[j] co_occurrence[u1][u2] 1 co_occurrence[u2][u1] 1 return co_occurrence这段代码生成的是用户的共现矩阵后续生成推荐时遍历目标用户的TopN相似用户把相似用户有正向行为、目标用户没有行为过的职位加权求和排序即可。需要注意代码里的user_id和job_id最好用int主键不要直接用模型对象否则内存占用会爆炸。3.2 基于物品的协同过滤(ItemCF)实现ItemCF离线的核心是计算职位之间的相似度矩阵。这个矩阵比用户相似度矩阵小得多因为职位数量通常只有用户数量的十分之一甚至更少。实现同样走“共现计数 归一化”的路线:# recommend/item_based.py import math from collections import defaultdict def build_item_similarity(action_matrix): # action_matrix: {user_id: {job_id: weight}} item_count defaultdict(int) co_occurrence defaultdict(lambda: defaultdict(int)) for user, items in action_matrix.items(): for item, weight in items.items(): item_count[item] 1 for other, other_weight in items.items(): if other item: continue co_occurrence[item][other] weight * other_weight item_sim {} for item, related in co_occurrence.items(): item_sim[item] {} for other, co_count in related.items(): # 余弦归一化 item_sim[item][other] co_count / math.sqrt(item_count[item] * item_count[other]) return item_sim在线推荐阶段用户点击查看某个职位时直接查这个职位的相似职位列表过滤掉用户已经投递过的职位再返回TopN。这种推荐模式非常轻量一次查询毫秒级就能返回不需要实时遍历全量用户行为。3.3 两个版本的取舍实际项目里我最终选择ItemCF为主、UserCF为辅的混合策略。核心原因有三点:职位数量远小于用户数量ItemCF的相似度矩阵更小内存压力低计算更快。用户兴趣漂移快——一个求职者可能两周内就从“找后端”切换到“入职后不再活跃”但职位之间的关联相对稳定长期维护成本低。ItemCF生成的推荐解释更自然比如“这个岗位和你投递过的某公司后端岗相似”这种解释在产品层面更容易让用户接受。不过UserCF也不是没用我会在当用户行为丰富、且需要探索新领域时把UserCF的结果作为补充召回源两种算法取并集后再排序。做召回阶段多路并行比单一算法硬扛要稳得多。4. Django工程内的代码组织:推荐引擎怎么和Web框架解耦4.1 项目目录结构很多人在Django项目里写推荐算法习惯把算法逻辑直接塞进views.py这种写法最大的问题是推荐算法的迭代效率和Web接口的迭代效率完全绑在一起上线一个小改动都要动业务代码。我采用了独立推荐引擎目录的结构Django只负责数据提供、接口暴露和结果回写:recruit_recommend/ ├── manage.py ├── config/ # 项目配置 settings.py/urls.py ├── apps/ │ ├── users/ # 用户模型与接口 │ ├── jobs/ # 职位模型与接口 │ └── analytics/ # 行为埋点与统计接口 ├── recommend/ # 推荐引擎独立目录 │ ├── __init__.py │ ├── user_based.py │ ├── item_based.py │ ├── matrix_ops.py # 行为矩阵构建、权重映射 │ └── recommend_service.py # 对外统一推荐服务入口 └── scripts/ ├── offline_build_sim.py # 离线任务构建相似度矩阵 └── evaluate.py # 离线评估脚本4.2 离线计算与在线推荐的拆分这套架构最重要的一条原则重的计算全部离线做Web请求只读结果。ItemCF的职位相似度矩阵计算、UserCF的用户相似度矩阵计算都是耗时任务不可能在用户请求时现算。我用Django管理命令封装了offline_build_sim.py通过cron或定时调度平台每天凌晨跑一次把计算结果序列化成pickle或JSON存入Redis在线服务直接读Redis。python manage.py runscript offline_build_sim --script-argsitem在线推荐接口只在views.py里做几件事:请求参数校验、从Redis捞相似度结果、过滤已投递职位、按权重排序返回。这样一个接口的响应时间能稳定控制在80ms以内而不是动辄几秒。4.3 缓存策略缓存是整个系统能跑多快的隐藏关键。我分了两层缓存:Redis层:存职位相似度矩阵和热门职位列表。key设计为sim:{job_id}value是排序后的JSON数组过期时间设置成900秒一方面保证数据不会长期不更新另一方面降低对Redis的持续压力。Django Cache层:用内置的cache_page装饰推荐接口缓存时间300秒。这个缓存专门抗突发流量比如首页瞬间涌入大量请求时不会直接打到Redis。注意:缓存时间不能设太长否则用户投递后刷新页面刚投过的职位还会出现在推荐里产品体验很差。5分钟内过期是比较稳妥的值。5. 实测效果与调优过程:从“推荐了个寂寞”到稳定可用5.1 冷启动问题的处理系统上线第一周问题最集中的就是冷启动。新注册用户没有行为记录协同过滤对ta等于失效返回的推荐要么为空要么全是全局热门职位。这个阶段我用的是分层冷启动方案:新用户:优先根据注册时填写的技能标签和期望城市做内容召回匹配Job表的tags字段。行为少于3条的用户:以全局热门榜兜底但会在排序上叠加技能标签相似度加权。行为达到10条以上:切换为ItemCF推荐为主这时候协同过滤的优势才真正体现出来。新职位的冷启动也容易忽略。职位刚上线时没有任何行为记录永远进不了相似度矩阵。我的处理是在离线任务里强制给新职位绑定一个与“同标题关键词最近邻”的相似列表保证它上线当天就能获得曝光机会。5.2 推荐效果怎么评估推荐系统不能只靠感觉调参我写了一个简单的离线评估脚本按用户把行为数据分成训练集和测试集(比如前70%行为做训练后30%做验证)用准确率、召回率、覆盖率三个指标衡量:指标离线实测值说明Precision100.18用户投递职位命中Top10推荐的比例Recall100.32用户全部投递职位中有多少出现在Top10覆盖率0.46被推荐过的职位占总职位数的比例准确率18%看起来不高但在招聘场景下已经属于可用范围因为用户投递行为本身就带有大量随机性。调优过程中发现把投递行为权重从5提到8准确率会明显提升但覆盖率会降到0.3以下推荐结果会变得太窄。权衡之后还是维持权重5保证推荐的多样性。5.3 我踩过的几个坑第一个坑是行为权重设置不当时负反馈失效。最初屏蔽动作没有纳入矩阵结果系统给用户反复推荐同一类不喜欢的职位流失了几个测试用户。后来把block行为设成-4权重并加入共现计算同类职位基本不再出现。第二个坑是中文分词问题。虽然主算法是协同过滤但冷启动阶段的内容召回依赖JD文本处理直接把中文句子按空格切分是不行的必须用jieba做中文分词并且在切词后过滤掉“的”“了”“和”这类停用词。第三个坑是物品相似度矩阵无限膨胀。职位数过万后如果不做剪枝每个职位的相似列表会越算越长占用内存非常夸张。处理方式是只保留每个职位的Top50相似职位其他全部丢弃。实测下来Top50已经能覆盖绝大部分有效推荐计算量和存储开销却降了一个数量级。第四个坑比较隐蔽:重复数据污染相似度矩阵。测试环境会有大量相同的职位被重复录入公司名一样、职位名一样只是发布时间不同这些重复职位会互相拉高相似度导致推荐结果高度集中。最终在构建矩阵前对职位做了归一化去重按titlecompany哈希分组每个组只保留最新一条。整套系统从开发到上线调优大概用了三周。回看这个项目最值的部分不是算法本身多高深而是把Django业务层和推荐算法层通过离线/在线拆分、缓存、冷启动策略有机结合在一起。现在平台每天产生数万条行为记录推荐接口稳定跑着偶尔打开后台看推荐日志发现用户真的会因为推荐去投递一些自己原本搜不到的长尾岗位时就会觉得当初“自己动手做一个”这个决定没做错。本文还有配套的精品资源点击获取