简介这是一套面向Python算法学习与课程设计的简历智能推荐系统完整项目适合希望掌握NLP文本处理、机器学习建模与推荐系统实战的开发者。项目围绕简历与职位描述的匹配度分析涵盖文本预处理、特征工程、分类模型训练及在线学习优化等核心模块可帮助理解从数据清洗到模型部署的完整流程。资源包含337个文件以html页面、py源码、pkl模型、doc论文文档、pdf及hdf5训练数据等为主整体127.43MB目录结构清晰便于按模块对照学习。已有485人学习使用适合课程设计、毕业设计或算法入门参考。通过该项目可获得可运行的算法源码、模型权重、训练测试数据及结题论文材料节省从零搭建环境与整理资料的时间提升对智能推荐算法的工程化理解。1. 简历智能推荐算法把“简历匹配岗位”从玄学变成可量化计算做招聘系统或者人才库管理时最耗人力的环节不是筛选简历而是“初筛”——HR每天要从几百份简历里挑出可能匹配的候选人。如果简历量上千光靠关键词搜索根本不够因为关键词搜的是“字面匹配”搜不到“这个人其实很适合这个岗位”的语义匹配。基于Python实现简历智能推荐算法核心就是做两件事一是把简历和岗位描述转成机器能计算的向量二是用相似度计算把“匹配程度”量化成分数按分数排序推荐。这个方案适合有Python基础、想给招聘系统加智能排序功能的开发者也适合HR系统集成商做MVP验证。它不是要做成千人千面的复杂推荐系统而是先把“人岗匹配”这条主链路跑通。2. 数据预处理简历文本清洗与结构化提取的四个关键环节2.1 简历格式杂乱的根源PDF、Word、HTML 混合输入真实场景中简历来源五花八门前程无忧导出的Word、智联的HTML、BOSS直聘的PDF、甚至图片版简历。如果直接对所有格式做文本解析会得到大量乱码和空行。常见做法是统一转成纯文本后再进NLP管道转换顺序建议是import subprocess import os def convert_to_text(file_path: str) - str: ext os.path.splitext(file_path)[1].lower() if ext .pdf: # pdfplumber 对扫描版无效但对付电子版PDF足够 import pdfplumber with pdfplumber.open(file_path) as pdf: return \n.join(page.extract_text() or for page in pdf.pages) elif ext .docx: import docx doc docx.Document(file_path) return \n.join([p.text for p in doc.paragraphs]) elif ext .doc: # 老版 .doc 需要先转成 docxWindows 上可用 win32com # 这里用 antiword 做 Linux 下的兜底 result subprocess.run( [antiword, file_path], capture_outputTrue, textTrue ) return result.stdout if result.returncode 0 else elif ext .html: from bs4 import BeautifulSoup with open(file_path, r, encodingutf-8) as f: return BeautifulSoup(f.read(), html.parser).get_text() return def preprocess_resume(raw_text: str) - str: # 压缩空行、去掉不可见字符、统一空格 import re text re.sub(r\r\n?, \n, raw_text) text re.sub(r[ \t], , text) text re.sub(r\n{3,}, \n\n, text) return text.strip()这段代码的逻辑是按扩展名分流处理。pdfplumber 对扫描版PDF无能为力所以在注释里先声明了边界docx 是Python解析最好的格式直接遍历段落即可.doc 是老格式Linux 环境最常见的兜底是用 antiword 命令行工具html 用 BeautifulSoup 提取正文文本。最后统一做正则清洗把换行和空格规范掉。参数说明re.sub(r[ \t], , text)里的[ \t]匹配连续空格和Tab替换成单空格能避免后续分词时出现空token\n{3,}把三个以上连续换行压成两个这样段落之间保留清晰分隔但又不会因为空行太多导致切分出错。2.2 结构化信息提取用正则和规则解析教育经历与工作经历简历文本清洗完之后下一步是抽出结构化字段。这个环节决定推荐效果的上限——如果连“工作年限”都抽错后面算相似度再准也没用。常见做法是用正则匹配关键锚点比如“教育背景”“工作经历”“项目经验”这些小标题然后按段落切分。import re def extract_sections(text: str) - dict: # 用常见小标题做锚点将简历切成多个区块 section_patterns { education: r(教育背景|教育经历|学历|EDUCATION), work: r(工作经历|工作经验|工作背景|WORK EXPERIENCE), project: r(项目经验|项目经历|项目实践|PROJECT), skills: r(专业技能|技能清单|个人技能|SKILLS), self_eval: r(自我评价|个人评价|SUMMARY) } sections {} for key, pattern in section_patterns.items(): match re.search(pattern, text, re.IGNORECASE) if match: start match.start() # 从当前位置找到下一个锚点作为区块结束位置 rest text[start len(match.group()):] next_starts [] for other_key, other_pattern in section_patterns.items(): if other_key ! key: other_match re.search(other_pattern, rest, re.IGNORECASE) if other_match: next_starts.append(other_match.start()) if next_starts: end start len(match.group()) min(next_starts) else: end len(text) sections[key] text[start:end].strip() return sections def extract_years_from_work(work_section: str) - int: # 从工作经历中提取总年限匹配 2018.06 - 2021.09 这类格式 date_pattern r(20\d{2})[./年-]\s*\d{0,2}[./月-]? years re.findall(date_pattern, work_section) if len(years) 2: try: start_year int(years[0]) end_year int(max(years)) return end_year - start_year 1 except ValueError: return 0 return 0这里的切分方法不是用NLP做段落识别而是用“锚点 找下一个锚点”的方式切分。这个思路在简历这种强格式化文本上非常稳因为简历的小标题用词相对固定即便候选人写的是英文简历上面这段也做了大小写不敏感匹配。extract_years_from_work的坑在于如果候选人写的是“2018.06 至今”max(years)取出来的是 2018算出来的年限会变成 1 年。这个逻辑现实中要加“至今”的当前年份兜底否则工作五六年的人会被算成刚毕业。经验是遇到“至今”就把当前年份代入再去减起始年份。2.3 中文分词与停用词jieba 的自定义词典一定要加招聘领域词简历文本分词和通用文本分词最大的区别在于专有名词多——Java、Spring Boot、TensorFlow、PMP、CET-6 这些词如果被切碎后面的向量化会直接失真。jieba 默认词典切“Spring Boot”会切成“Spring/Boot”两个词切“C”可能变成“C//”这对匹配是灾难。import jieba def load_skill_dict(skill_list_path: str): # 每行一个技能词格式Java工程师 3 nz jieba.load_userdict(skill_list_path) def segment_resume(text: str) - list: # 去掉标点和停用词返回 token 列表 import string stopwords set([的, 了, 是, 我, 有, 和, 就, 不, 在, 也]) tokens [] for token in jieba.cut(text): token token.strip() if not token: continue if token in stopwords: continue if token in string.punctuation: continue tokens.append(token) return tokens # 使用示例 skill_dict [ Spring Boot, Spring Cloud, TensorFlow, PyTorch, 自然语言处理, 推荐算法, JVM调优, C, C# ] with open(skill_dict.txt, w, encodingutf-8) as f: for s in skill_dict: f.write(f{s} 3 nz\n) load_skill_dict(skill_dict.txt) print(segment_resume(熟练使用Spring Boot和C有推荐算法落地经验))自定义词典的格式是“词 词频 词性”3 nz表示词频设为3、词性为专有名词。这里的关键是词频不能设太高否则会过度干预 jieba 的隐马尔可夫模型把一些普通词错误合并。真正做项目时技能词典要维护成动态文件每次从岗位JD里抽取高频技能词自动追加。比如看了100个Java岗位JD发现“微服务”出现的频率很高就把它加进词典。这个词典是推荐系统的底层资产后续做规则权重、做技能标签提取都靠它。3. 文本向量化与相似度计算TF-IDF、Word2Vec、BERT 的选型对比3.1 TF-IDF 适合冷启动但词汇鸿沟问题明显向量化是推荐算法的核心前置步骤选什么方法直接决定推荐效果的天花板。最常见的入门方案是 TF-IDF它统计词频并做逆文档频率加权——在所有简历里频繁出现的词比如“工作”“经验”会被降权而出现次数少但带有区分度的词比如“Kubernetes”“PyTorch”会被加权。from sklearn.feature_extraction.text import TfidfVectorizer import jieba def tokenize(text: str) - list: return segment_resume(text) def build_tfidf_matrix(resumes: list, jds: list): corpus resumes jds vectorizer TfidfVectorizer( tokenizertokenize, max_features5000, min_df1, max_df0.8, ngram_range(1, 2) ) matrix vectorizer.fit_transform(corpus) return vectorizer, matrix长短不一的简历和JD放进同一个向量空间TF-IDF 找到的是词面的共现关系。max_features 设置成 5000 是为了控制维度否则简历一多特征数动辄几万维训练速度慢且容易过拟合。max_df0.8 表示在 80% 以上的文档里都出现的词会被忽略这类词通常是“简历”“姓名”“电话”这种无区分度的信息。但 TF-IDF 有硬伤词汇鸿沟。JD 里写“熟练运用 Java、Spring Boot”简历里写“有三年 Java 后端开发经验常用 Spring 全家桶”TF-IDF 只能匹配上 Java 一个词“Spring Boot”和“Spring 全家桶”在词面上不同相似度算出来很低。这时候就需要换用 Word2Vec 或 BERT 这类语义向量模型。3.2 Word2Vec 把词汇映射成语义空间但需要自己训练语料用 Word2Vec 做简历推荐的常见路径是先拿大规模招聘文本JD 简历语料训练一个领域词向量模型然后把简历里每个词的向量取平均得到整篇简历的句子向量最后用余弦相似度衡量人岗匹配程度。这里的关键是语料不是算法——训练一个百万级别token的语料word2vec 的向量质量就已经能感知“Spring Boot”和“Spring Cloud”是兄弟词。from gensim.models import Word2Vec from gensim.models.word2vec import LineSentence # 假设语料每行是一份简历/JD的文本 sentences list(LineSentence(open(corpus.txt, r, encodingutf-8))) model Word2Vec( sentences, vector_size128, window5, min_count2, workers4, epochs10, sg1 ) model.save(resume_w2v.model) # 简历向量 所有词向量的加权平均 import numpy as np def sentence_vector(tokens: list, model: Word2Vec, dim: int 128) - np.ndarray: vecs [] for token in tokens: if token in model.wv: vecs.append(model.wv[token]) if not vecs: return np.zeros(dim) return np.mean(vecs, axis0) tokens segment_resume(熟练使用Spring Boot和C有推荐算法落地经验) vec sentence_vector(tokens, model)sentence_vector这里用的是简单平均实际效果其实一般因为“招聘”“简历”这种高频词会稀释真正实词的语义。优化做法是加 TF-IDF 权重——高频词降权低频实词提权但代价是计算速度变慢。Window5 意味着看每个词前后各 5 个词作为上下文min_count2 表示出现次数少于 2 次的词直接丢弃sg1 表示用 skip-gram在语料不大时比 CBOW 效果更稳。Word2Vec 的最明显问题是“一词一词孤立训练”完全不考虑句子顺序也没有上下文动态调整。“Python”和“python”会被训练成两个完全不同的向量除非做了小写归一化。另外训练结果高度依赖语料质量如果拿通用中文语料训练模型根本不知道“Spring Boot”和“Spring Cloud”是相关的。3.3 BERT/句向量方案效果最好但显存和推理速度要提前评估团队如果有 GPU 资源且简历量不算巨大直接用预训练中文 BERT 模型做句向量是效果最优解。常见做法是用sentence-transformers库加载中文预训练模型把简历段落直接编码成 768 维向量。这里注意不是把整篇简历扔进 BERTBERT 有 512 token 限制简历动辄 2000 到 3000 字直接扔进去会被截断。from sentence_transformers import SentenceTransformer # 加载中文模型第一次运行会联网下载权重 model SentenceTransformer(shibing624/text2vec-base-chinese) def encode_resume(text: str, max_len: int 256) - list: # 把简历按段落切分每段单独编码再取平均避免截断 paragraphs [p for p in text.split(\n\n) if len(p) 20] vecs [] for para in paragraphs[:8]: # 最多编码8个段落 vec model.encode(para, max_lengthmax_len) vecs.append(vec) if not vecs: return model.encode(text[:max_len]) return np.mean(vecs, axis0) # 面试代码时最后会把所有简历向量保存成 .npy 文件 # np.save(resume_vectors.npy, vectors)把简历切成段落再编码本质上是用“分段编码 平均”来绕过 512 token 限制这样既保留语义信息又不会因截断丢内容。但切分粒度不对时效果反而更差——比如一段话里混杂了教育经历、工作经历、技能清单平均向量会互相稀释。业内更稳的做法是先做结构化提取把每段归到技能/工作经历/项目经验等类别下再按类别拼成几个短文本分块编码。BERT 方案的实际边界在于一条 GPU 显存 8G 的机器批量编码 1000 份简历大概需要几分钟单看还好。但如果系统是实时推荐用户提交岗位 JD 后要秒级返回匹配候选人BERT 的推理速度就是瓶颈。生产环境常见的折中是简历离线批量编码存缓存JD 在线编码做相似度检索。4. 推荐算法核心链路基于内容的召回规则与余弦相似度排序4.1 召回策略先用规则锁定候选池再算相似度避免全量计算如果公司有 10 万份简历每来一个新 JD 都全量算余弦相似度耗时太高。推荐系统的常见架构是“召回 排序”两阶段召回阶段用简单规则把范围缩小到几百份排序阶段再用相似度模型精排。import numpy as np def recall_by_rule(jd_skills: list, resume_skills: list, top_k: int 100) - bool: 召回规则JD技能与简历技能至少命中2个或技能命中率达到30%以上。 返回 True 表示简历进入候选池。 if not jd_skills: return True hit set(jd_skills) set(resume_skills) if len(hit) 2: return True if len(jd_skills) 0 and len(hit) / len(jd_skills) 0.3: return True return False def recommend(resume_vecs: np.ndarray, jd_vec: np.ndarray, resume_skills: list, jd_skills: list, top_k: int 20): candidate_indices [] for idx, skills in enumerate(resume_skills): if recall_by_rule(jd_skills, skills): candidate_indices.append(idx) if not candidate_indices: candidate_indices np.arange(len(resume_vecs)) # 候选池内算余弦相似度 candidate_vecs resume_vecs[candidate_indices] scores cosine_similarity(candidate_vecs, jd_vec.reshape(1, -1)).flatten() ranked_indices np.argsort(scores)[::-1][:top_k] return [candidate_indices[i] for i in ranked_indices], scores召回规则的阈值是经验值不是理论最优。命中2个技能的阈值对“Java Spring Boot”这种强技能对比较友好对“PPT Excel”这种弱技能则不友好。如果发现召回率太低推荐结果里优质候选人比例少优先调低召回阈值如果发现候选池太大、排序压力高优先调高阈值。这阶段有一个隐藏工程点技能标签要归一化。简历里写“Java”和“JAVA”写“SpringBoot”和“Spring Boot”如果没做归一化规则召回直接漏掉。经验是维护一份同义词表统一映射后再做技能匹配。4.2 相似度计算余弦相似度、BM25、混合加权怎么选候选池缩小后排序阶段要选相似度算法。最常见的是余弦相似度它不看距离的绝对大小、只看方向夹角对文本长度不敏感适合简历这种长短差异很大的场景。BM25 是传统信息检索里的排序函数对关键词匹配的权重建模更细但需要把简历和 JD 当成查询文档语义能力弱于向量模型。from sklearn.metrics.pairwise import cosine_similarity def hybrid_score(cosine_score: float, bm25_score: float, rule_hit_num: int) - float: 混合打分策略 1. 余弦相似度反映语义匹配 2. BM25得分反映词面匹配 3. 规则命中数是硬信号 # 归一化项bm25_score 原始值可能非常大做一次 log1p 压缩 norm_bm25 np.log1p(max(bm25_score, 0)) return 0.5 * cosine_score 0.3 * norm_bm25 0.2 * min(rule_hit_num / 5.0, 1.0)权重 0.5 / 0.3 / 0.2 是拍脑袋定的一套初始值。项目上线后一般会用标注好的历史成功入职数据做日志损失回归把三个权重拟合出来。在数据量不大的冷启动阶段这套经验权重够用前提是别把权重的意义反过来——余弦相似度是主信号规则命中数是加分项而不是决定项。BM25 的计算在 Python 里用rank_bm25库最方便但注意它需要单独分词处理而且词典要跟向量模型共用一份否则词表割裂会导致评分不可比。4.3 相似度阈值与排序展示动态阈值比固定阈值更贴近业务推荐列表返回后产品上要决定“哪些简历展示给 HR”。如果直接用相似度排序输出 Top 20但排名第 1 的只有 0.45 分这个推荐结果就是垃圾——HR 连续看了几周低分推荐就会对整个系统失去信任。常见做法是设一个阈值低于阈值的简历直接不展示。def dynamic_threshold_by_jd(jd_text: str, jd_skills: list) - float: 动态阈值逻辑 1. JD 写得越具体阈值越高因为具体 JD 的语义向量更有区分度 2. 硬技能数量越多阈值越高 if len(jd_skills) 6: return 0.6 if len(jd_text) 500: return 0.55 return 0.45动态阈值的逻辑来自一个很现实的观察JD 写得越笼统向量越容易被“沾边”的简历蹭到高分。写“熟悉主流编程语言”这种 JD任何程序员简历都能拿高分而写“精通 Java有高并发调优经验熟悉 Spring Cloud 微服务”的 JD语义空间里和真正的匹配者距离较近。这个阶段如果结合秒级返回的需求工程上会用 faiss 建立向量索引通过近似最近邻检索替代暴力余弦计算把全量扫描的复杂度从 O(N) 降到接近 O(log N)。但注意 faiss 索引是近似结果跟精确余弦相似度比会有 5% 左右的精度损失简历量大时这个取舍是值得的。5. 推荐效果评估与避坑跑通上线前必须盯住的 5 个细节5.1 评估指标HR 反馈率比 AUC 更接近业务真实目标推荐系统的折腾方向一旦跑偏常见表现是团队沉迷于优化离线 AUC但 HR 用起来还是觉得“推荐的什么玩意儿”。原因是离线指标和线上业务目标之间有偏差——线上目标本质是“HR 看中某份简历并发起沟通”离线 AUC 只衡量“正样本得分是否高于负样本”两者不是一回事。from sklearn.metrics import ndcg_score, precision_score, recall_score # 模拟一份评估给出一批 JD 的真实命中简历ID # hits {jd_001: [3, 7, 12], ...} def evaluate_recommendation(recommended_lists: dict, ground_truth: dict, k: int 10): precisions [] recalls [] for jd_id, rec_list in recommended_lists.items(): true_set set(ground_truth.get(jd_id, [])) rec_set set(rec_list[:k]) precisions.append(len(rec_set true_set) / k) recalls.append(len(rec_set true_set) / len(true_set) if true_set else 0) return { precision10: round(sum(precisions) / len(precisions), 4), recall10: round(sum(recalls) / len(recalls), 4) }上线初期建议直接用 HR 的正面操作作为标注——HR 点击了某份简历的完整查看、下载了这份简历、发起了面试邀约都算正反馈。这种方式是隐式反馈不需要 HR 额外打标但噪声也大HR 可能点开了但发现不匹配或者只是误触。稳妥的做法是并行记录“下载简历”和“发起沟通”两个动作后者置信度更高。5.2 避坑一分词器把“Python”和“python”当成两个词这里有一个我踩过的比较典型的坑。现象简历里写“熟悉 Python 和 java”JD 里写“Python/Java 开发”相似度得分出奇低。原因分词和向量化阶段没有做大小写归一化Python和python被映射到不同的 tokenjava和Java词向量也完全不一致。解决分词前统一text.lower()并且在自定义词典里就写成小写形式。另一个藏在后面的细节是 jieba 对英文的大小写切割不一样统一转小写后要重新跑一遍分词验证。5.3 避坑二TF-IDF 训练时混入薪资、电话、邮箱等噪声现象向量召回的 Top 推荐里出现“薪资要求完全不符”的简历。原因简历里的“15K”“20K”“电话 138xxxx”“邮箱”等内容被当成普通文本进了 TF-IDF 词表而且这些长数字串在文档里区分度高IDF 权重反而更大把真正的技能词给淹没了。解决在预处理阶段用正则把这些信息直接替换成占位符或者直接删除数字型薪资统一归一到“薪资区间”字段单独存不参与向量计算。def clean_noise(text: str) - str: import re text re.sub(r1[3-9]\d{9}, [电话], text) text re.sub(r\d{2,4}[./-]\d{1,2}[./-]\d{1,2}, [日期], text) text re.sub(r\d{2,}K|\d{2,}千|\d{2,}万, [薪资], text) text re.sub(r\b\w\w\.\w\b, [邮箱], text) return text这段正则里的\d{2,}K会把“10K-15K”里的两段都替换成 [薪资]可能把薪资区间信息丢掉。这类字段如果面试评估时需要保留就应该单独解析出来存结构化字段而不是在清洗阶段一把梭。踩坑经验就是清洗要分两路一路给向量模型用一路留给人看的简历详情页。5.4 避坑三Word2Vec 训练语料太小导致向量空间里全是零向量一个小团队内部跑实验时的坑只用 200 份真实简历做 Word2Vec 训练min_count 设为 5结果发现大部分词都被过滤了一份 300 字的简历里只剩下三十几个词有向量其余全部落回np.zeros(dim)。原因min_count 阈值相对语料规模太高200 份简历的高频词根本撑不起语义空间。解决语料低于 5 万条时min_count 设为 1 或 2同时引入外部通用语料扩大覆盖面。5.5 避坑四JD 里的“优先条件”语义被重点匹配反而干扰排序JD 里经常写“有金融行业经验优先”“211/985 优先”“会 Go 语言优先”。这些“优先”词在向量空间里和核心要求混在一起导致推荐系统把“会 Go”当成了和“精通 Java”同等重要的信号。现象是推荐的候选人都很契合加分项但硬性条件反而匹配不够。解决解析 JD 时把“优先”“加分项”“熟悉以下任意一种”等从句单独拆出来降低权重参与计算核心要求全权重匹配。做法可以简单粗暴JD 文本里出现“优先”的段落单独归到一个jd_bonus字段向量相加时乘以 0.3 的权重。6. 离线批量计算加向量检索把推荐服务从脚本升级成接口6.1 简历向量离线构建与存储文件存储换 SQLite原型阶段建议用np.save保存向量矩阵但当简历量超过 3 万份时npy 文件加载到内存占用的空间已经上万兆操作和更新时间都快不可控。常见做法是换 SQLite 存向量 BLOB配合索引加快查询。import sqlite3 import numpy as np import pickle def init_db(db_path: str): conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS resume_vectors ( resume_id TEXT PRIMARY KEY, vector BLOB NOT NULL, skills TEXT, update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() return conn def store_vector(conn: sqlite3.Connection, resume_id: str, vector: np.ndarray, skills: list): blob pickle.dumps(vector) # float32 数组转 BLOB skills_str ,.join(skills) conn.execute( INSERT OR REPLACE INTO resume_vectors (resume_id, vector, skills) VALUES (?, ?, ?), (resume_id, blob, skills_str) ) conn.commit() def load_all_vectors(conn: sqlite3.Connection) - dict: cur conn.execute(SELECT resume_id, vector, skills FROM resume_vectors) result {} for resume_id, blob, skills_str in cur.fetchall(): result[resume_id] { vector: pickle.loads(blob), skills: skills_str.split(,) if skills_str else [] } return result用 BLOB 存储向量的好处是查询结果可以直接 pickle 反序列化进内存省去重算环节。注意 pickle 有向下兼容问题Python 3.6 版本序列化的对象在 3.9 版本能读反过来不保证。团队统一 Python 版本能避免这类问题。6.2 用 FastAPI 包一层推荐接口返回排序结果和匹配分项简历推荐功能最终要对接招聘系统常见做法是用 FastAPI 包一层接口输入 JD 文本输出候选人列表和匹配分数明细。推荐服务最好像下面这样把“规则召回分数”“语义相似度分数”“混合分数”都返回方便前端展示解释性文案——“技能匹配度 80%语义相似度 0.62”。from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleResume Recommendation Service) class JDRequest(BaseModel): jd_text: str top_k: int 20 class RecommendResponse(BaseModel): resume_id_list: list scores: list details: list app.post(/recommend, response_modelRecommendResponse) def recommend(jd_request: JDRequest): # 1. 解析JD文本 tokens clean_noise(jd_request.jd_text) jd_tokens segment_resume(tokens) jd_skills extract_skills_from_text(tokens) # 2. 编码JD向量 jd_vec encode_resume(tokens) # 3. 召回 排序 ranked, scores recommend_by_vectors(jd_vec, jd_skills) # 4. 构造解释信息 details build_explain_details(ranked, jd_skills) return RecommendResponse( resume_id_listranked, scoresscores, detailsdetails )接口参数top_k在真实生产环境里会暴露一个实际问题招聘方如果需要在不同页面加载更多推荐结果这个参数不能无限调大因为向量检索的返回耗时和演示分页存在矛盾。常见的做法是接口固定返回前 50 个候选前端分页只做展示不做重新查询。接口服务化之后的性能瓶颈通常在向量编码环节。encode_resume每次调用都要跑一次模型如果同时来 10 个请求且没加并发锁显存可能直接被打爆。经验是包装一层缓存同一个 JD 文本哈希后如果 24 小时内有缓存直接复用向量。6.3 最后一步用回测脚本验证推荐效果是否值得上线推荐系统上线做 AB 测试前建议先跑一轮离线回测来检查模型是否值得投入。做法是把历史已入职数据作为样本取入职前 HR 最终选择的候选人将其简历作为正样本然后对这批正样本计算推荐排序里的位置。def backtest_position(ranked_list: list, actual_hired_id: str) - int: 返回实际入职候选人在推荐列表中的排名位置。 位置大于50说明推荐系统给了很低的排序模型大概率有问题。 if actual_hired_id in ranked_list: return ranked_list.index(actual_hired_id) 1 return len(ranked_list) 1如果实际入职的人连前 50 都没进通常是两个原因一是 JD 文本太短向量化后失去区分度二是简历结构化不充分技能实体没有被正确抽出来。先用这份历史数据做回测能省掉大量试错时间。线上真实反馈积累到 500 条以上时再把回测换成语义预训练微调或者模型权重调优这是算法迭代的主轴。我自己的习惯是每一个候选人的推荐详情页都把“技能命中列表”和“匹配分数构成”一起展示这样既能帮 HR 理解推荐原因又方便我们排查是召回环节还是排序环节出问题。代码写完跑出第一批推荐结果后第一件事不是看分数高不高而是看排名前 10 有没有“完全文不对题”的简历。如果有先回查噪音清洗和技能词典再调整量模型。这套带动静态阈值和混合权重的方法做完一轮效果一般能比纯关键词搜索提升明显的初步筛选效率。希望帮到你。本文还有配套的精品资源点击获取
简介这是一套面向Python算法学习与课程设计的简历智能推荐系统完整项目适合希望掌握NLP文本处理、机器学习建模与推荐系统实战的开发者。项目围绕简历与职位描述的匹配度分析涵盖文本预处理、特征工程、分类模型训练及在线学习优化等核心模块可帮助理解从数据清洗到模型部署的完整流程。资源包含337个文件以html页面、py源码、pkl模型、doc论文文档、pdf及hdf5训练数据等为主整体127.43MB目录结构清晰便于按模块对照学习。已有485人学习使用适合课程设计、毕业设计或算法入门参考。通过该项目可获得可运行的算法源码、模型权重、训练测试数据及结题论文材料节省从零搭建环境与整理资料的时间提升对智能推荐算法的工程化理解。1. 简历智能推荐算法把“简历匹配岗位”从玄学变成可量化计算做招聘系统或者人才库管理时最耗人力的环节不是筛选简历而是“初筛”——HR每天要从几百份简历里挑出可能匹配的候选人。如果简历量上千光靠关键词搜索根本不够因为关键词搜的是“字面匹配”搜不到“这个人其实很适合这个岗位”的语义匹配。基于Python实现简历智能推荐算法核心就是做两件事一是把简历和岗位描述转成机器能计算的向量二是用相似度计算把“匹配程度”量化成分数按分数排序推荐。这个方案适合有Python基础、想给招聘系统加智能排序功能的开发者也适合HR系统集成商做MVP验证。它不是要做成千人千面的复杂推荐系统而是先把“人岗匹配”这条主链路跑通。2. 数据预处理简历文本清洗与结构化提取的四个关键环节2.1 简历格式杂乱的根源PDF、Word、HTML 混合输入真实场景中简历来源五花八门前程无忧导出的Word、智联的HTML、BOSS直聘的PDF、甚至图片版简历。如果直接对所有格式做文本解析会得到大量乱码和空行。常见做法是统一转成纯文本后再进NLP管道转换顺序建议是import subprocess import os def convert_to_text(file_path: str) - str: ext os.path.splitext(file_path)[1].lower() if ext .pdf: # pdfplumber 对扫描版无效但对付电子版PDF足够 import pdfplumber with pdfplumber.open(file_path) as pdf: return \n.join(page.extract_text() or for page in pdf.pages) elif ext .docx: import docx doc docx.Document(file_path) return \n.join([p.text for p in doc.paragraphs]) elif ext .doc: # 老版 .doc 需要先转成 docxWindows 上可用 win32com # 这里用 antiword 做 Linux 下的兜底 result subprocess.run( [antiword, file_path], capture_outputTrue, textTrue ) return result.stdout if result.returncode 0 else elif ext .html: from bs4 import BeautifulSoup with open(file_path, r, encodingutf-8) as f: return BeautifulSoup(f.read(), html.parser).get_text() return def preprocess_resume(raw_text: str) - str: # 压缩空行、去掉不可见字符、统一空格 import re text re.sub(r\r\n?, \n, raw_text) text re.sub(r[ \t], , text) text re.sub(r\n{3,}, \n\n, text) return text.strip()这段代码的逻辑是按扩展名分流处理。pdfplumber 对扫描版PDF无能为力所以在注释里先声明了边界docx 是Python解析最好的格式直接遍历段落即可.doc 是老格式Linux 环境最常见的兜底是用 antiword 命令行工具html 用 BeautifulSoup 提取正文文本。最后统一做正则清洗把换行和空格规范掉。参数说明re.sub(r[ \t], , text)里的[ \t]匹配连续空格和Tab替换成单空格能避免后续分词时出现空token\n{3,}把三个以上连续换行压成两个这样段落之间保留清晰分隔但又不会因为空行太多导致切分出错。2.2 结构化信息提取用正则和规则解析教育经历与工作经历简历文本清洗完之后下一步是抽出结构化字段。这个环节决定推荐效果的上限——如果连“工作年限”都抽错后面算相似度再准也没用。常见做法是用正则匹配关键锚点比如“教育背景”“工作经历”“项目经验”这些小标题然后按段落切分。import re def extract_sections(text: str) - dict: # 用常见小标题做锚点将简历切成多个区块 section_patterns { education: r(教育背景|教育经历|学历|EDUCATION), work: r(工作经历|工作经验|工作背景|WORK EXPERIENCE), project: r(项目经验|项目经历|项目实践|PROJECT), skills: r(专业技能|技能清单|个人技能|SKILLS), self_eval: r(自我评价|个人评价|SUMMARY) } sections {} for key, pattern in section_patterns.items(): match re.search(pattern, text, re.IGNORECASE) if match: start match.start() # 从当前位置找到下一个锚点作为区块结束位置 rest text[start len(match.group()):] next_starts [] for other_key, other_pattern in section_patterns.items(): if other_key ! key: other_match re.search(other_pattern, rest, re.IGNORECASE) if other_match: next_starts.append(other_match.start()) if next_starts: end start len(match.group()) min(next_starts) else: end len(text) sections[key] text[start:end].strip() return sections def extract_years_from_work(work_section: str) - int: # 从工作经历中提取总年限匹配 2018.06 - 2021.09 这类格式 date_pattern r(20\d{2})[./年-]\s*\d{0,2}[./月-]? years re.findall(date_pattern, work_section) if len(years) 2: try: start_year int(years[0]) end_year int(max(years)) return end_year - start_year 1 except ValueError: return 0 return 0这里的切分方法不是用NLP做段落识别而是用“锚点 找下一个锚点”的方式切分。这个思路在简历这种强格式化文本上非常稳因为简历的小标题用词相对固定即便候选人写的是英文简历上面这段也做了大小写不敏感匹配。extract_years_from_work的坑在于如果候选人写的是“2018.06 至今”max(years)取出来的是 2018算出来的年限会变成 1 年。这个逻辑现实中要加“至今”的当前年份兜底否则工作五六年的人会被算成刚毕业。经验是遇到“至今”就把当前年份代入再去减起始年份。2.3 中文分词与停用词jieba 的自定义词典一定要加招聘领域词简历文本分词和通用文本分词最大的区别在于专有名词多——Java、Spring Boot、TensorFlow、PMP、CET-6 这些词如果被切碎后面的向量化会直接失真。jieba 默认词典切“Spring Boot”会切成“Spring/Boot”两个词切“C”可能变成“C//”这对匹配是灾难。import jieba def load_skill_dict(skill_list_path: str): # 每行一个技能词格式Java工程师 3 nz jieba.load_userdict(skill_list_path) def segment_resume(text: str) - list: # 去掉标点和停用词返回 token 列表 import string stopwords set([的, 了, 是, 我, 有, 和, 就, 不, 在, 也]) tokens [] for token in jieba.cut(text): token token.strip() if not token: continue if token in stopwords: continue if token in string.punctuation: continue tokens.append(token) return tokens # 使用示例 skill_dict [ Spring Boot, Spring Cloud, TensorFlow, PyTorch, 自然语言处理, 推荐算法, JVM调优, C, C# ] with open(skill_dict.txt, w, encodingutf-8) as f: for s in skill_dict: f.write(f{s} 3 nz\n) load_skill_dict(skill_dict.txt) print(segment_resume(熟练使用Spring Boot和C有推荐算法落地经验))自定义词典的格式是“词 词频 词性”3 nz表示词频设为3、词性为专有名词。这里的关键是词频不能设太高否则会过度干预 jieba 的隐马尔可夫模型把一些普通词错误合并。真正做项目时技能词典要维护成动态文件每次从岗位JD里抽取高频技能词自动追加。比如看了100个Java岗位JD发现“微服务”出现的频率很高就把它加进词典。这个词典是推荐系统的底层资产后续做规则权重、做技能标签提取都靠它。3. 文本向量化与相似度计算TF-IDF、Word2Vec、BERT 的选型对比3.1 TF-IDF 适合冷启动但词汇鸿沟问题明显向量化是推荐算法的核心前置步骤选什么方法直接决定推荐效果的天花板。最常见的入门方案是 TF-IDF它统计词频并做逆文档频率加权——在所有简历里频繁出现的词比如“工作”“经验”会被降权而出现次数少但带有区分度的词比如“Kubernetes”“PyTorch”会被加权。from sklearn.feature_extraction.text import TfidfVectorizer import jieba def tokenize(text: str) - list: return segment_resume(text) def build_tfidf_matrix(resumes: list, jds: list): corpus resumes jds vectorizer TfidfVectorizer( tokenizertokenize, max_features5000, min_df1, max_df0.8, ngram_range(1, 2) ) matrix vectorizer.fit_transform(corpus) return vectorizer, matrix长短不一的简历和JD放进同一个向量空间TF-IDF 找到的是词面的共现关系。max_features 设置成 5000 是为了控制维度否则简历一多特征数动辄几万维训练速度慢且容易过拟合。max_df0.8 表示在 80% 以上的文档里都出现的词会被忽略这类词通常是“简历”“姓名”“电话”这种无区分度的信息。但 TF-IDF 有硬伤词汇鸿沟。JD 里写“熟练运用 Java、Spring Boot”简历里写“有三年 Java 后端开发经验常用 Spring 全家桶”TF-IDF 只能匹配上 Java 一个词“Spring Boot”和“Spring 全家桶”在词面上不同相似度算出来很低。这时候就需要换用 Word2Vec 或 BERT 这类语义向量模型。3.2 Word2Vec 把词汇映射成语义空间但需要自己训练语料用 Word2Vec 做简历推荐的常见路径是先拿大规模招聘文本JD 简历语料训练一个领域词向量模型然后把简历里每个词的向量取平均得到整篇简历的句子向量最后用余弦相似度衡量人岗匹配程度。这里的关键是语料不是算法——训练一个百万级别token的语料word2vec 的向量质量就已经能感知“Spring Boot”和“Spring Cloud”是兄弟词。from gensim.models import Word2Vec from gensim.models.word2vec import LineSentence # 假设语料每行是一份简历/JD的文本 sentences list(LineSentence(open(corpus.txt, r, encodingutf-8))) model Word2Vec( sentences, vector_size128, window5, min_count2, workers4, epochs10, sg1 ) model.save(resume_w2v.model) # 简历向量 所有词向量的加权平均 import numpy as np def sentence_vector(tokens: list, model: Word2Vec, dim: int 128) - np.ndarray: vecs [] for token in tokens: if token in model.wv: vecs.append(model.wv[token]) if not vecs: return np.zeros(dim) return np.mean(vecs, axis0) tokens segment_resume(熟练使用Spring Boot和C有推荐算法落地经验) vec sentence_vector(tokens, model)sentence_vector这里用的是简单平均实际效果其实一般因为“招聘”“简历”这种高频词会稀释真正实词的语义。优化做法是加 TF-IDF 权重——高频词降权低频实词提权但代价是计算速度变慢。Window5 意味着看每个词前后各 5 个词作为上下文min_count2 表示出现次数少于 2 次的词直接丢弃sg1 表示用 skip-gram在语料不大时比 CBOW 效果更稳。Word2Vec 的最明显问题是“一词一词孤立训练”完全不考虑句子顺序也没有上下文动态调整。“Python”和“python”会被训练成两个完全不同的向量除非做了小写归一化。另外训练结果高度依赖语料质量如果拿通用中文语料训练模型根本不知道“Spring Boot”和“Spring Cloud”是相关的。3.3 BERT/句向量方案效果最好但显存和推理速度要提前评估团队如果有 GPU 资源且简历量不算巨大直接用预训练中文 BERT 模型做句向量是效果最优解。常见做法是用sentence-transformers库加载中文预训练模型把简历段落直接编码成 768 维向量。这里注意不是把整篇简历扔进 BERTBERT 有 512 token 限制简历动辄 2000 到 3000 字直接扔进去会被截断。from sentence_transformers import SentenceTransformer # 加载中文模型第一次运行会联网下载权重 model SentenceTransformer(shibing624/text2vec-base-chinese) def encode_resume(text: str, max_len: int 256) - list: # 把简历按段落切分每段单独编码再取平均避免截断 paragraphs [p for p in text.split(\n\n) if len(p) 20] vecs [] for para in paragraphs[:8]: # 最多编码8个段落 vec model.encode(para, max_lengthmax_len) vecs.append(vec) if not vecs: return model.encode(text[:max_len]) return np.mean(vecs, axis0) # 面试代码时最后会把所有简历向量保存成 .npy 文件 # np.save(resume_vectors.npy, vectors)把简历切成段落再编码本质上是用“分段编码 平均”来绕过 512 token 限制这样既保留语义信息又不会因截断丢内容。但切分粒度不对时效果反而更差——比如一段话里混杂了教育经历、工作经历、技能清单平均向量会互相稀释。业内更稳的做法是先做结构化提取把每段归到技能/工作经历/项目经验等类别下再按类别拼成几个短文本分块编码。BERT 方案的实际边界在于一条 GPU 显存 8G 的机器批量编码 1000 份简历大概需要几分钟单看还好。但如果系统是实时推荐用户提交岗位 JD 后要秒级返回匹配候选人BERT 的推理速度就是瓶颈。生产环境常见的折中是简历离线批量编码存缓存JD 在线编码做相似度检索。4. 推荐算法核心链路基于内容的召回规则与余弦相似度排序4.1 召回策略先用规则锁定候选池再算相似度避免全量计算如果公司有 10 万份简历每来一个新 JD 都全量算余弦相似度耗时太高。推荐系统的常见架构是“召回 排序”两阶段召回阶段用简单规则把范围缩小到几百份排序阶段再用相似度模型精排。import numpy as np def recall_by_rule(jd_skills: list, resume_skills: list, top_k: int 100) - bool: 召回规则JD技能与简历技能至少命中2个或技能命中率达到30%以上。 返回 True 表示简历进入候选池。 if not jd_skills: return True hit set(jd_skills) set(resume_skills) if len(hit) 2: return True if len(jd_skills) 0 and len(hit) / len(jd_skills) 0.3: return True return False def recommend(resume_vecs: np.ndarray, jd_vec: np.ndarray, resume_skills: list, jd_skills: list, top_k: int 20): candidate_indices [] for idx, skills in enumerate(resume_skills): if recall_by_rule(jd_skills, skills): candidate_indices.append(idx) if not candidate_indices: candidate_indices np.arange(len(resume_vecs)) # 候选池内算余弦相似度 candidate_vecs resume_vecs[candidate_indices] scores cosine_similarity(candidate_vecs, jd_vec.reshape(1, -1)).flatten() ranked_indices np.argsort(scores)[::-1][:top_k] return [candidate_indices[i] for i in ranked_indices], scores召回规则的阈值是经验值不是理论最优。命中2个技能的阈值对“Java Spring Boot”这种强技能对比较友好对“PPT Excel”这种弱技能则不友好。如果发现召回率太低推荐结果里优质候选人比例少优先调低召回阈值如果发现候选池太大、排序压力高优先调高阈值。这阶段有一个隐藏工程点技能标签要归一化。简历里写“Java”和“JAVA”写“SpringBoot”和“Spring Boot”如果没做归一化规则召回直接漏掉。经验是维护一份同义词表统一映射后再做技能匹配。4.2 相似度计算余弦相似度、BM25、混合加权怎么选候选池缩小后排序阶段要选相似度算法。最常见的是余弦相似度它不看距离的绝对大小、只看方向夹角对文本长度不敏感适合简历这种长短差异很大的场景。BM25 是传统信息检索里的排序函数对关键词匹配的权重建模更细但需要把简历和 JD 当成查询文档语义能力弱于向量模型。from sklearn.metrics.pairwise import cosine_similarity def hybrid_score(cosine_score: float, bm25_score: float, rule_hit_num: int) - float: 混合打分策略 1. 余弦相似度反映语义匹配 2. BM25得分反映词面匹配 3. 规则命中数是硬信号 # 归一化项bm25_score 原始值可能非常大做一次 log1p 压缩 norm_bm25 np.log1p(max(bm25_score, 0)) return 0.5 * cosine_score 0.3 * norm_bm25 0.2 * min(rule_hit_num / 5.0, 1.0)权重 0.5 / 0.3 / 0.2 是拍脑袋定的一套初始值。项目上线后一般会用标注好的历史成功入职数据做日志损失回归把三个权重拟合出来。在数据量不大的冷启动阶段这套经验权重够用前提是别把权重的意义反过来——余弦相似度是主信号规则命中数是加分项而不是决定项。BM25 的计算在 Python 里用rank_bm25库最方便但注意它需要单独分词处理而且词典要跟向量模型共用一份否则词表割裂会导致评分不可比。4.3 相似度阈值与排序展示动态阈值比固定阈值更贴近业务推荐列表返回后产品上要决定“哪些简历展示给 HR”。如果直接用相似度排序输出 Top 20但排名第 1 的只有 0.45 分这个推荐结果就是垃圾——HR 连续看了几周低分推荐就会对整个系统失去信任。常见做法是设一个阈值低于阈值的简历直接不展示。def dynamic_threshold_by_jd(jd_text: str, jd_skills: list) - float: 动态阈值逻辑 1. JD 写得越具体阈值越高因为具体 JD 的语义向量更有区分度 2. 硬技能数量越多阈值越高 if len(jd_skills) 6: return 0.6 if len(jd_text) 500: return 0.55 return 0.45动态阈值的逻辑来自一个很现实的观察JD 写得越笼统向量越容易被“沾边”的简历蹭到高分。写“熟悉主流编程语言”这种 JD任何程序员简历都能拿高分而写“精通 Java有高并发调优经验熟悉 Spring Cloud 微服务”的 JD语义空间里和真正的匹配者距离较近。这个阶段如果结合秒级返回的需求工程上会用 faiss 建立向量索引通过近似最近邻检索替代暴力余弦计算把全量扫描的复杂度从 O(N) 降到接近 O(log N)。但注意 faiss 索引是近似结果跟精确余弦相似度比会有 5% 左右的精度损失简历量大时这个取舍是值得的。5. 推荐效果评估与避坑跑通上线前必须盯住的 5 个细节5.1 评估指标HR 反馈率比 AUC 更接近业务真实目标推荐系统的折腾方向一旦跑偏常见表现是团队沉迷于优化离线 AUC但 HR 用起来还是觉得“推荐的什么玩意儿”。原因是离线指标和线上业务目标之间有偏差——线上目标本质是“HR 看中某份简历并发起沟通”离线 AUC 只衡量“正样本得分是否高于负样本”两者不是一回事。from sklearn.metrics import ndcg_score, precision_score, recall_score # 模拟一份评估给出一批 JD 的真实命中简历ID # hits {jd_001: [3, 7, 12], ...} def evaluate_recommendation(recommended_lists: dict, ground_truth: dict, k: int 10): precisions [] recalls [] for jd_id, rec_list in recommended_lists.items(): true_set set(ground_truth.get(jd_id, [])) rec_set set(rec_list[:k]) precisions.append(len(rec_set true_set) / k) recalls.append(len(rec_set true_set) / len(true_set) if true_set else 0) return { precision10: round(sum(precisions) / len(precisions), 4), recall10: round(sum(recalls) / len(recalls), 4) }上线初期建议直接用 HR 的正面操作作为标注——HR 点击了某份简历的完整查看、下载了这份简历、发起了面试邀约都算正反馈。这种方式是隐式反馈不需要 HR 额外打标但噪声也大HR 可能点开了但发现不匹配或者只是误触。稳妥的做法是并行记录“下载简历”和“发起沟通”两个动作后者置信度更高。5.2 避坑一分词器把“Python”和“python”当成两个词这里有一个我踩过的比较典型的坑。现象简历里写“熟悉 Python 和 java”JD 里写“Python/Java 开发”相似度得分出奇低。原因分词和向量化阶段没有做大小写归一化Python和python被映射到不同的 tokenjava和Java词向量也完全不一致。解决分词前统一text.lower()并且在自定义词典里就写成小写形式。另一个藏在后面的细节是 jieba 对英文的大小写切割不一样统一转小写后要重新跑一遍分词验证。5.3 避坑二TF-IDF 训练时混入薪资、电话、邮箱等噪声现象向量召回的 Top 推荐里出现“薪资要求完全不符”的简历。原因简历里的“15K”“20K”“电话 138xxxx”“邮箱”等内容被当成普通文本进了 TF-IDF 词表而且这些长数字串在文档里区分度高IDF 权重反而更大把真正的技能词给淹没了。解决在预处理阶段用正则把这些信息直接替换成占位符或者直接删除数字型薪资统一归一到“薪资区间”字段单独存不参与向量计算。def clean_noise(text: str) - str: import re text re.sub(r1[3-9]\d{9}, [电话], text) text re.sub(r\d{2,4}[./-]\d{1,2}[./-]\d{1,2}, [日期], text) text re.sub(r\d{2,}K|\d{2,}千|\d{2,}万, [薪资], text) text re.sub(r\b\w\w\.\w\b, [邮箱], text) return text这段正则里的\d{2,}K会把“10K-15K”里的两段都替换成 [薪资]可能把薪资区间信息丢掉。这类字段如果面试评估时需要保留就应该单独解析出来存结构化字段而不是在清洗阶段一把梭。踩坑经验就是清洗要分两路一路给向量模型用一路留给人看的简历详情页。5.4 避坑三Word2Vec 训练语料太小导致向量空间里全是零向量一个小团队内部跑实验时的坑只用 200 份真实简历做 Word2Vec 训练min_count 设为 5结果发现大部分词都被过滤了一份 300 字的简历里只剩下三十几个词有向量其余全部落回np.zeros(dim)。原因min_count 阈值相对语料规模太高200 份简历的高频词根本撑不起语义空间。解决语料低于 5 万条时min_count 设为 1 或 2同时引入外部通用语料扩大覆盖面。5.5 避坑四JD 里的“优先条件”语义被重点匹配反而干扰排序JD 里经常写“有金融行业经验优先”“211/985 优先”“会 Go 语言优先”。这些“优先”词在向量空间里和核心要求混在一起导致推荐系统把“会 Go”当成了和“精通 Java”同等重要的信号。现象是推荐的候选人都很契合加分项但硬性条件反而匹配不够。解决解析 JD 时把“优先”“加分项”“熟悉以下任意一种”等从句单独拆出来降低权重参与计算核心要求全权重匹配。做法可以简单粗暴JD 文本里出现“优先”的段落单独归到一个jd_bonus字段向量相加时乘以 0.3 的权重。6. 离线批量计算加向量检索把推荐服务从脚本升级成接口6.1 简历向量离线构建与存储文件存储换 SQLite原型阶段建议用np.save保存向量矩阵但当简历量超过 3 万份时npy 文件加载到内存占用的空间已经上万兆操作和更新时间都快不可控。常见做法是换 SQLite 存向量 BLOB配合索引加快查询。import sqlite3 import numpy as np import pickle def init_db(db_path: str): conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS resume_vectors ( resume_id TEXT PRIMARY KEY, vector BLOB NOT NULL, skills TEXT, update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() return conn def store_vector(conn: sqlite3.Connection, resume_id: str, vector: np.ndarray, skills: list): blob pickle.dumps(vector) # float32 数组转 BLOB skills_str ,.join(skills) conn.execute( INSERT OR REPLACE INTO resume_vectors (resume_id, vector, skills) VALUES (?, ?, ?), (resume_id, blob, skills_str) ) conn.commit() def load_all_vectors(conn: sqlite3.Connection) - dict: cur conn.execute(SELECT resume_id, vector, skills FROM resume_vectors) result {} for resume_id, blob, skills_str in cur.fetchall(): result[resume_id] { vector: pickle.loads(blob), skills: skills_str.split(,) if skills_str else [] } return result用 BLOB 存储向量的好处是查询结果可以直接 pickle 反序列化进内存省去重算环节。注意 pickle 有向下兼容问题Python 3.6 版本序列化的对象在 3.9 版本能读反过来不保证。团队统一 Python 版本能避免这类问题。6.2 用 FastAPI 包一层推荐接口返回排序结果和匹配分项简历推荐功能最终要对接招聘系统常见做法是用 FastAPI 包一层接口输入 JD 文本输出候选人列表和匹配分数明细。推荐服务最好像下面这样把“规则召回分数”“语义相似度分数”“混合分数”都返回方便前端展示解释性文案——“技能匹配度 80%语义相似度 0.62”。from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleResume Recommendation Service) class JDRequest(BaseModel): jd_text: str top_k: int 20 class RecommendResponse(BaseModel): resume_id_list: list scores: list details: list app.post(/recommend, response_modelRecommendResponse) def recommend(jd_request: JDRequest): # 1. 解析JD文本 tokens clean_noise(jd_request.jd_text) jd_tokens segment_resume(tokens) jd_skills extract_skills_from_text(tokens) # 2. 编码JD向量 jd_vec encode_resume(tokens) # 3. 召回 排序 ranked, scores recommend_by_vectors(jd_vec, jd_skills) # 4. 构造解释信息 details build_explain_details(ranked, jd_skills) return RecommendResponse( resume_id_listranked, scoresscores, detailsdetails )接口参数top_k在真实生产环境里会暴露一个实际问题招聘方如果需要在不同页面加载更多推荐结果这个参数不能无限调大因为向量检索的返回耗时和演示分页存在矛盾。常见的做法是接口固定返回前 50 个候选前端分页只做展示不做重新查询。接口服务化之后的性能瓶颈通常在向量编码环节。encode_resume每次调用都要跑一次模型如果同时来 10 个请求且没加并发锁显存可能直接被打爆。经验是包装一层缓存同一个 JD 文本哈希后如果 24 小时内有缓存直接复用向量。6.3 最后一步用回测脚本验证推荐效果是否值得上线推荐系统上线做 AB 测试前建议先跑一轮离线回测来检查模型是否值得投入。做法是把历史已入职数据作为样本取入职前 HR 最终选择的候选人将其简历作为正样本然后对这批正样本计算推荐排序里的位置。def backtest_position(ranked_list: list, actual_hired_id: str) - int: 返回实际入职候选人在推荐列表中的排名位置。 位置大于50说明推荐系统给了很低的排序模型大概率有问题。 if actual_hired_id in ranked_list: return ranked_list.index(actual_hired_id) 1 return len(ranked_list) 1如果实际入职的人连前 50 都没进通常是两个原因一是 JD 文本太短向量化后失去区分度二是简历结构化不充分技能实体没有被正确抽出来。先用这份历史数据做回测能省掉大量试错时间。线上真实反馈积累到 500 条以上时再把回测换成语义预训练微调或者模型权重调优这是算法迭代的主轴。我自己的习惯是每一个候选人的推荐详情页都把“技能命中列表”和“匹配分数构成”一起展示这样既能帮 HR 理解推荐原因又方便我们排查是召回环节还是排序环节出问题。代码写完跑出第一批推荐结果后第一件事不是看分数高不高而是看排名前 10 有没有“完全文不对题”的简历。如果有先回查噪音清洗和技能词典再调整量模型。这套带动静态阈值和混合权重的方法做完一轮效果一般能比纯关键词搜索提升明显的初步筛选效率。希望帮到你。本文还有配套的精品资源点击获取
