每年的秋招春招毕业生就像在打一场信息战。招聘信息推荐系统这个词听起来高大上真正要解决的问题却非常朴素在海量岗位里把合适的学生和合适的岗位连接起来。我之前用Python完整实现过一个面向高校毕业生的招聘信息推荐系统从岗位数据采集、薪资清洗、技能标签抽取到基于内容的召回、协同过滤排序最后用FastAPI把推荐结果暴露成接口。这套流程跑下来我对推荐系统的理解比看十篇论文都深。这篇文章就把关键设计决策、核心代码和踩过的坑一次性写清楚适合正在做推荐系统毕设、或者准备转行推荐算法方向的读者参考。1. 毕业生招聘推荐到底在解决什么问题1.1 信息过载下的匹配误差先说说为什么需要这样一个系统。一个毕业生在秋招季面对的信息源可能包括学校就业网、学院群转发的招聘简章、主流招聘APP推送、企业官网校招入口。每一条信息都真实有效但组合在一起就变成了噪音。更麻烦的是岗位描述的表达方式差异太大。同样是招后端工程师A公司写“精通Python熟悉Django/Flask”B公司写“掌握一门主流后端语言”C公司直接写“会写脚本就行”。如果毕业生只盯着“Python”关键词过滤B公司的岗位大概率会被漏掉而C公司这类描述模糊的岗位又很难判断是否适合。这也是为什么简单的关键词搜索解决不了匹配问题。关键词搜索本质上是字符串层面的contains判断但招聘匹配需要的是意图层面的判断。毕业生的隐性需求可能是“能用Python做数据分析”“能进大型互联网公司”“城市希望在杭州”这些东西靠关键词很难表达完整。推荐系统的任务就是把这部分隐性需求通过用户画像和岗位画像的匹配显性化。1.2 明确系统的输入输出边界设计系统的第一步不是写代码而是定义边界。我这次的项目只做“给毕业生推荐岗位”这个单侧推荐不做给HR推荐简历也不做双方匹配的双向系统。输入是用户侧属性和行为数据包括用户画像专业、学历、掌握的技能、期望城市、期望薪资范围。用户行为浏览记录、投递记录、收藏记录。输出是TopK岗位列表每个岗位还要带上推荐理由。这里的推荐理由对毕业生来说非常重要因为用户需要知道自己为什么被推荐“因为你有Python和数据分析技能”比“系统觉得你可能喜欢”可信得多。还要做的一个关键决策是采用离线优先架构。每天定时跑一次推荐引擎把结果写入缓存用户请求时直接读缓存。毕业生求职的行为反馈周期本来就是天级别的谈不上实时推荐离线批量计算完全够用实现成本低出了问题也容易排查。2. 数据从哪里来合法采集、字段设计与清洗实操2.1 数据源选择与采集节奏数据是推荐系统的燃料。这个项目里我用了两部分数据一部分是公开的脱敏样例数据用于快速验证算法另一部分是从学校就业信息网公开的岗位公告里采集的结构化内容。如果你没有真实数据可用建议不要硬爬那些反爬严密的商业招聘网站风险大且容易被封。更靠谱的方式是直接找公开数据集很多高校开源了自己的就业信息数据或者自己写一个模拟岗位生成器先把推荐链路跑通。如果一定要做爬虫验证记得遵守这几个原则请求前看robots.txt请求间隔不要低于1秒不要并发开高线程不要绕过登录验证。我实际用的是requests加BeautifulSoup单线程顺序抓取一天大概能抓几千条公开页面足够实验了。2.2 数据表结构设计推荐系统需要的数据无非三类岗位信息、用户信息、用户行为。我用MySQL建了三张核心表结构如下CREATE TABLE jobs ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, company VARCHAR(100) NOT NULL, city VARCHAR(50), salary_min FLOAT, salary_max FLOAT, degree_required VARCHAR(20), skill_tags VARCHAR(255), job_desc TEXT, published_at DATETIME, INDEX idx_city (city), INDEX idx_company (company) ); CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, major VARCHAR(50), degree VARCHAR(20), skills VARCHAR(255), expected_city VARCHAR(50), expected_salary_min FLOAT, expected_salary_max FLOAT ); CREATE TABLE user_actions ( user_id INT NOT NULL, job_id INT NOT NULL, action_type VARCHAR(20) NOT NULL, created_at DATETIME, PRIMARY KEY (user_id, job_id, action_type) );这里我刻意把skill_tags设计成逗号分隔的字符串而不是单独一张标签表。原因是第一版推荐系统涉及的技能维度有限直接用字符串字段最简单后续如果需要做标签管理再拆成关联表也不迟。user_actions表是协同过滤的基础action_type记录浏览、投递、收藏三类动作投递的权重远高于浏览。2.3 薪资字符串清洗真实招聘数据里最坑人的就是薪资字段。我抽样看了一下格式五花八门“15-25K”“15-25K·13薪”“1-1.5万/月”“面议”“8k-12k”。如果不对这个字段做清洗后面所有关于薪资的过滤和画像构建都会出错。我写了一个解析函数把字符串统一转成数字范围单位Kimport re def parse_salary(text): if not text or 面议 in text: return None, None text text.strip().lower().replace( , ) # 情况一15-25k match re.search(r([\d.])\s*[-~]\s*([\d.])\s*k, text) if match: return float(match.group(1)), float(match.group(2)) # 情况二1-1.5万 match re.search(r([\d.])\s*[-~]\s*([\d.])\s*万, text) if match: return float(match.group(1)) * 10, float(match.group(2)) * 10 # 情况三固定值 match re.search(r([\d.])\s*k, text) if match: val float(match.group(1)) return val, val return None, None这个函数看起来简单但在实际清洗时帮我避免了很多脏数据。这里的要点是先把所有单位统一成“K”后面做用户期望薪水和岗位薪水的区间重叠判断才不会出现单位和量级错误。2.4 技能标签抽取技能标签是内容推荐的核心特征。我一开始想用jieba全量分词再用TF-IDF抽关键词但实际效果并不好。因为岗位JD是很短的文本一个岗位描述可能就3到5句话TF-IDF里的IDF几乎不提供区分度。更好的做法是维护一个技能词典直接在JD文本里做包含匹配。技能词典覆盖Python、Java、C、数据分析、机器学习、MySQL、Redis、Docker、Spring、Hadoop这类高频技能词然后对每一条JD抽取命中的技能集合SKILL_SET [python, java, c, 数据分析, 机器学习, mysql, redis, docker, spring, hadoop, flink, spark, go, html, css, javascript] def extract_skills(jd_text): text jd_text.lower() skills [] for skill in SKILL_SET: if skill in text: skills.append(skill) return skills这里有个细节容易踩坑直接判断skill in text会把“java”误匹配到“javascript”因为后者的字符序列包含“java”。我在设置词典时会为易冲突的技能名写独立的匹配规则简单粗暴但有效。比如判断“java”时先排除“javascript”的出现或者用正则边界匹配。3. 推荐算法选型为什么我把基于内容放在主位3.1 三种候选方案对比推荐算法候选方案很多但都逃不过数据条件和成本约束。我把当时认真考虑的方案放在一起做了个对比方案需要的数据冷启动友好度稀疏性敏感度实现成本基于内容推荐岗位描述、用户画像友好不依赖行为矩阵低协同过滤UserCF/ItemCF用户行为历史差非常敏感中深度学习Word2Vec/BERT大量行为和文本一般对数据量要求高高最终我选择“基于内容为主、协同过滤为辅”的混合策略。原因有三个第一毕设或MVP阶段不会有大量用户行为数据协同过滤冷启动会非常难受第二基于内容推荐可以用岗位JD和用户画像直接算不依赖历史行为新用户也能推荐第三深度学习模型效果虽然可能更好但对数据量和调试成本要求高如果只有几万条数据训练出来的模型很容易过拟合得不偿失。3.2 用户画像和岗位画像的构建画像的本质是把人或者岗位表示成一个向量。内容推荐的相似度计算就是在向量空间里找最近的邻居。用户画像我从两个地方拼出来一是用户注册时填写的专业、技能、期望城市、薪资期望二是用户行为历史反推出来的技能偏好。对毕业生场景第一版可以只使用前者这样新注册用户也能直接参与推荐。岗位画像要简单得多从jobs表的skill_tags字段就可以直接得到技能向量。由于技能特征本身是离散且稀疏的我用0/1向量表示每个岗位是否包含某个技能再加两个连续特征城市是否匹配、月薪水平取薪资范围中位数并做归一化。import numpy as np SKILL_SET [python, java, c, 数据分析, 机器学习, mysql, redis, docker, spring, hadoop] def build_job_vector(job): vec np.zeros(len(SKILL_SET) 2) for skill in job[skill_tags].split(,): skill skill.strip().lower() if skill in SKILL_SET: vec[SKILL_SET.index(skill)] 1.0 salary_mid (job[salary_min] job[salary_max]) / 2 vec[-1] salary_mid / 100.0 return vec很多人做内容推荐一上来就用TF-IDF向量化全文但在这个场景下反而会把最关键的技能信号淹没在一堆无关的停止词里。技能词典抽取的向量虽然看起来“简陋”但特征极其精准而且可解释性很强推荐理由直接就是命中了哪些技能。3.3 相似度计算与TopK生成向量建好之后相似度计算就是标准的余弦相似度from sklearn.metrics.pairwise import cosine_similarity def recommend_by_content(user_vec, job_matrix, top_k10): # user_vec: 1 x dimjob_matrix: n_jobs x dim sims cosine_similarity(user_vec, job_matrix)[0] top_indices sims.argsort()[::-1][:top_k] return top_indices, sims[top_indices]为什么用余弦相似度而不是欧氏距离因为这里的特征大部分是0/1稀疏特征余弦相似度只关心方向不关心向量长度两个向量面临维度差异时表现更稳定。比如两个岗位都包含Python和MySQL第三个岗位包含更多技能余弦相似度不会因为后者“更长”而显著降低相似度。3.4 用协同过滤做个性化补充当用户积累了一定的浏览和投递行为之后协同过滤的优势就出来了。它能发现内容是冷的、但行为模式很相似的同学。我实现的是UserCF先构建用户-岗位交互矩阵计算用户之间的相似度再找到相似用户投递过的岗位作为候选。import numpy as np def user_cf_recommend(interaction_matrix, user_id, top_k20): user_vec interaction_matrix[user_id] sims cosine_similarity([user_vec], interaction_matrix)[0] sim_users sims.argsort()[::-1][1:6] # 取最相似的5个用户 cand_scores np.zeros(interaction_matrix.shape[1]) for u in sim_users: cand_scores sims[u] * interaction_matrix[u] # 排除自己已经交互过的岗位 cand_scores[user_vec 0] 0 return cand_scores.argsort()[::-1][:top_k]这里的权重就是sims[u]相似的人贡献更大的推荐权重。要注意的是协同过滤的交互矩阵非常稀疏如果用户行为太少算出来的相似用户可能全是0向量这时候我会设置一个阈值只有行为数大于5的用户才参与协同过滤否则直接用内容推荐结果。4. 系统实现从算法脚本到可调用服务4.1 整体流程设计我把系统设计成离线优先的批处理架构主流程分成四步每天凌晨触发数据同步任务把新增岗位和用户行为写入MySQL。定时任务对所有活跃用户重新计算用户画像并生成每个用户的TopK推荐列表。推荐结果写入Redis缓存Key设计成rec:user:{user_id}Value直接存JSON数组。FastAPI服务接收到用户请求时先从Redis读缓存缓存为空再临时计算。这个流程的好处是不用为每一个用户请求实时跑一遍向量化和相似度毕竟高校毕业生的岗位推荐不是抢购秒杀不需要毫秒级实时更新。离线计算结果完全可以满足需求而且出现问题时还能回看历史推荐快照。4.2 分层召回、粗排、重排工业界推荐系统常说的“召回-粗排-精排”在这个小项目里也可以简化实现。我的做法是先召回再粗排最后重排。召回阶段拿到三个候选池内容推荐Top50、协同过滤Top20、热门岗位Top10做并集。粗排阶段用硬性规则过滤比如岗位薪资范围和用户期望薪资必须有重叠、岗位城市必须匹配、岗位学历要求不能高于用户学历。这些规则看起来不起眼但能过滤掉大量明显不合适的岗位让后续打分更集中在有效候选上。重排阶段用加权分数排序final_score 0.7 * content_sim 0.2 * cf_score 0.1 * popularity同时加一条限制同一个公司最多只能出现2个岗位否则一排下来全是头部大厂岗位学生体验会很差。这个限制本质上是多样性约束成本很低但价值很高。4.3 FastAPI接口实现我想让系统能够被前端调用最好用的还是FastAPI。写一个简单的推荐接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI(title招聘推荐系统) class RecRequest(BaseModel): user_id: int top_k: int 10 app.post(/recommend) def recommend(req: RecRequest): result redis_get(frec:user:{req.user_id}) if result is None: result on_demand_compute(req.user_id, req.top_k) redis_set(frec:user:{req.user_id}, result, ex3600) return {code: 0, data: result}启动命令也很简单uvicorn main:app --reload。这样前端或者其他服务就能通过HTTP接口拿到推荐结果整个项目也从“算法脚本”变成了一个可以被演示和集成的服务。4.4 环境与依赖管理我当时用的Python版本是3.9依赖项都锁了版本避免出现“昨天还能跑今天报错”的尴尬pandas2.0.3 numpy1.24.3 scikit-learn1.3.0 jieba0.42.1 fastapi0.104.1 uvicorn0.24.0 requests2.31.0 redis5.0.1无论你是Windows、macOS还是Linux建议都先用虚拟环境隔离依赖。我在Ubuntu服务器上部署时遇到过系统自带的Python3.6版本太老导致scikit-learn装不上的问题后来直接用python3.9 -m venv venv建虚拟环境再用pip install -r requirements.txt一次性装好。5. 冷启动、稀疏性和评测上线前必须过的三道坎5.1 冷启动处理冷启动是所有推荐系统都躲不开的问题。对毕业生场景来说新用户注册时会填写专业、技能、期望城市和薪资这就给了一个非常完整的初始画像。因此新用户可以直接走基于内容的推荐不需要任何行为历史。我给新用户设计的推荐理由也很有说头“因为你有Python和数据分析技能推荐这份数据分析工程师岗位”用户体验比无理由推荐好很多。新岗位的冷启动相对好办因为岗位信息本身自带画像内容推荐可以直接覆盖。再加入一个热门岗位池把新发布的岗位按类目放到热门池里曝光几天积累第一批行为数据协同过滤就能慢慢生效了。5.2 稀疏矩阵处理假设系统里有500个用户、3000个岗位每个用户平均只投递过2个岗位那么交互矩阵的非零元素占比是1000/1500000约0.067%。这种极端稀疏的矩阵UserCF算出来的用户相似度基本就是一堆0。我的处理方式是优先用ItemCF也就是把相似度计算从“用户-用户”转成“岗位-岗位”。岗位之间的相似度通过“同时被哪些用户投递”来计算在交互稀疏时往往比UserCF更稳。另外也可以用矩阵分解降维比如scikit-learn里的TruncatedSVD把交互矩阵压缩到低维空间再算相似度。要注意的是SVD并不能让数据变多它只是把高维稀疏空间映射到低维稠密空间让相似度计算在数学上更稳定不能盲目依赖。提示如果你只用几千条数据做测试矩阵分解的效果可能比不过简单的ItemCF不一定非要追求复杂算法。5.3 离线评测怎么做推荐系统上线前必须知道自己的模型到底有几斤几两。我的做法是把用户行为按9:1划分成训练集和测试集用训练集计算每个用户的TopK推荐再用测试集评估PrecisionK 推荐列表中被用户实际交互的岗位数 / K。RecallK 推荐列表中被用户实际交互的岗位数 / 测试集中用户交互的总岗位数。Coverage 推荐结果包含的不同岗位数 / 全部岗位数。Diversity 推荐结果中不同技能标签的平均熵用来衡量结果多样性。我当时在模拟数据上跑出来的对比结果大概是这样模型Precision10Recall10CoverageDiversity基于内容0.210.340.230.58ItemCF0.160.280.190.62混合推荐0.280.410.310.55混合推荐的Precision和Recall都明显更好Coverage也更健康。这说明内容推荐和协同过滤在这个场景下是互补的不是替代关系。6. 实测效果、踩坑记录与可扩展方向6.1 参数调节K值怎么选推荐列表长度K是个超参数我的实测结论是K小精确率高适合只想看最匹配岗位的用户K大覆盖率高但后排的推荐质量下降明显。我默认设为10因为毕业生一天能认真看的岗位也就两三个方向Top10足够。如果这个系统以后做成了校内就业平台想给每个岗位曝光机会可以把K调到20并配合热门池打散。6.2 踩过的坑这个项目最大的花絮基本都集中在数据清洗和工程实现上我这里列几个最典型的问题。第一个是薪资单位混用。我最初只写了K单位的分支结果遇到“1-1.5万”的岗位整行salary_min为1年薪变1K推荐排序直接乱掉。后来统一先判断字符中是否有“万”有就先乘以10再处理。第二个是技能词误匹配。“javascript”的JD会把“java”这个技能也命中因为java in javascript返回True。这个问题我在系统里用正则边界解决比如判断\bjava\b但对“C”这种带符号的词正则写法要另外处理。最好还是维护一个更严格的技能匹配映射表。第三个是矩阵内存。我把1万用户和5000岗位的交互矩阵直接存成numpy二维数组float64类型内存占用一下到了400MB。换成scipy.sparse.csr_matrix之后内存直接降到几十MB级别。这个坑在数据量小时完全察觉不到数据一多就立刻爆炸。第四个是爬虫去重。同一家公司的同一个岗位会在不同平台重复出现我只按公司名加岗位名去重忽略了不同发布时间导致推荐列表中同一岗位反复出现。最后给jobs表加了唯一索引并以后一周内的最新一条为准。第五个是surprise库在Windows下安装失败。一开始想用surprise实现SVD编译时一直报错后来换成scikit-learn的TruncatedSVD问题少了很多。如果你也用Windows尽量避免需要编译的ML库直接用常见的wheel包更省心。6.3 可以继续扩展的方向第一版尽管跑通了但我很清楚它的天花板在哪里。如果要让推荐结果更上一层楼有几个方向可以尝试。第一是语义召回。当前技能词典的匹配方式只能理解字面含义理解不了“熟悉Linux环境”和“掌握Shell命令”之间的相似性。用Word2Vec或者BERT把岗位描述和用户简历编码成句向量再做向量近似检索召回的灵活性和准确性都会有明显提升。第二是实时反馈。等系统接入真正的线上流量之后用户点击、收藏、投递行为是持续产生的每天批处理的更新间隔太长了。可以在用户行为产生时通过消息队列发动作消息增量更新用户的画像和协同过滤模型实现分钟级甚至秒级的反馈循环。第三是更完整的分层推荐架构。这个项目的召回、粗排、重排很简单线上效果说明够用。但如果数据量上来了可以进一步把粗排换成轻量排序模型把重排加入更多业务规则形成一条真正工业级的推荐管道。项目做完之后我最大的体会是推荐系统这个题目算法的权重远没有数据工程和评测闭环高。很多人一上来就想着用BERT、用深度学习结果连基础的薪资字段都洗不干净推荐出来的岗位学生根本不敢投。如果你也在做类似的毕设或者练手项目建议先把基于内容和协同过滤这套经典方案跑通把离线评测指标搭好再考虑上复杂模型。这一套流程走完你收获的不是一个能出效果的项目而是一整套做推荐系统的思维方式。