简历智能推荐算法实战：从TF-IDF到语义向量

简介这套基于Python的简历智能推荐算法资源面向计算机相关专业课程设计及毕业设计人群完整实现了从简历与职位描述的文本预处理、特征构造到分类模型训练与推荐排序的全流程方案。资源共337个文件约127.43MB内容涵盖Python源码、训练所得模型.pkl、.hdf5、checkpoint、论文文档.doc/.docx、HTML辅助文档、数据集train_data/test_data及图表等代码与文档分层清晰便于直接运行、复现及扩展。目前已有485人学习使用。借助其中包含的完整代码、预训练模型及毕设论文材料读者可以快速掌握TF-IDF、词嵌入、CNN/Bi-LSTM等模型的实际应用理解推荐系统的构建细节并以现成素材支撑自己的项目答辩或报告撰写。1. 简历智能推荐算法为什么我们不用关键词搜索做招聘系统的技术人迟早会被业务方提一个需求简历库里有上万份简历能不能给每个职位自动推Top 10用关键词搜索其实也能做但效果就是三个字——不好用。候选人写“精通Java”JD里写“熟悉Java”搜索词匹配不上候选人在“xx科技有限公司”做过3年和职位要求的“电商行业经验”对不上号更麻烦的是一份简历能匹配多个岗位靠人来筛,效率上不去。简历智能推荐算法要解决的就是这件事把简历和职位描述JD变成计算机能算的表示然后算相似度、排序、输出推荐结果。它不是让人工智能自动写评语也不是做语义问答而是先解决“人岗匹配”这个检索问题。适合谁两类人一是做招聘平台、HR系统的后端工程师二是想拿真实场景练手Python文本挖掘和推荐系统的同学。前者看重工程落地后者看重思路可复现。这篇文章按我自己的实现路径来从数据特征、核心代码、工程化到排错一步步拆给你看。2. 核心设计思路人岗匹配为什么不能直接拼关键词在做简历推荐之前先想清楚一个问题简历和JD的匹配本质是什么它本质上是计算一段文本和另一段文本之间的相似度。听起来简单但这里有个足够让所有新手翻车的设计分叉是把简历当成一个整体去和JD整体比较还是拆分出技能项、工作年限、学历、城市逐项比较这两种做法的算法选型完全不同。2.1 整体匹配还是分项匹配这是个算法选型问题整体匹配的做法是把整份简历和整个JD各当作一段长文本用TF-IDF、Word2Vec或者BERT之类的模型算出两个向量再算余弦相似度。最大优点是实现简单pip装完sklearn就能做最大缺点是噪音太多。一份简历里“沟通能力强、抗压能力好”这种自我评价占了很大篇幅而JD里真正决定匹配度的是“3年以上Python开发经验”“熟悉Flask”这种硬性描述。把这两种文本整体去比自我评价会严重干扰相似度计算。分项匹配的做法是把简历按结构拆开基本信息、工作经历、项目经历、技能列表、教育背景JD也拆开岗位职责、任职要求、加分项。然后按维度分别算相似度最后加权求和。这样做的工程成本高一些但解释性好——你推荐完一份简历能给业务方一个明确的说法“这个人是因为技能匹配度0.9、经验匹配度0.6所以排在前面”而不是丢一个黑匣子分数出来。我的建议很直接如果是第一次做不要一上来就上BERT先做整体匹配跑通流程再往分项匹配迭代。原因有两个第一简历结构千奇百怪分项解析本身就是个大坑解析错了后面全错第二整体匹配虽然在精度上有上限但它的分数分布能帮你快速判断数据质量。我自己的经验是整体匹配的代码量不到分项匹配的三分之一但能覆盖60%以上的场景需求。2.2 中文简历的分词与停用词一个容易被低估的环节简历智能推荐算法处理的是中文文本中文和英文最大的区别是词与词之间没有空格必须先分词。分词的好坏直接影响后续所有环节。常见的分词工具有jieba、HanLP、LTP其中jieba最轻量、最好上手适合第一版。但是直接拿默认词库对简历做分词效果其实一般——简历里充满了人名、公司名、产品名、专业术语比如“全栈工程师”“K8s”“Docker”这些词在默认词库里要么被切碎要么根本识别不出来。我一般会在jieba默认词库的基础上追加一个自定义领域词典把常见的技术栈、职位名称、行业术语加进去。词典文件格式一行一个词然后在代码里用jieba.load_userdict(dict.txt)加载。另外停用词表要注意不要直接套用网上通用的中文停用词表——那个表会把“经验”“工作”“负责”这种简历核心动词和名词干掉的生产环境会出大问题。停用词表里真正该放的是“我们”“通过”“由于”这类高频无意义词。分词之后还有一个很多人容易忽略的步骤把“熟练掌握Python”和“Python熟练”这种同一个意思但不同词序的文本归一化。这个问题比较麻烦后面章节细说。2.3 向量化的两个方向稀疏向量与稠密向量分词之后下一步是把文本变成向量。这里有两个技术路线稀疏向量和稠密向量。稀疏向量最典型的是TF-IDF和BM25。TF-IDF的原理是统计词频并给高频常见词降权实现简单、计算快、可解释。但它的缺点非常明显词汇鸿沟——如果JD里写“Java”简历里写“JVM调优”TF-IDF算出来的相似度是0因为两个字面完全不同的词没有任何交集。这是纯字面匹配的天然缺陷不是调参能救的。稠密向量的思路是用预训练语言模型把文本映射成一个低维稠密向量语义相近的句子在向量空间里距离更近。“Java”和“JVM调优”即使字面不一样向量方向上也是接近的。常见工具包括Word2Vec、fastText、Sentence-BERT等。代价是需要下载预训练模型推理时间变长而且分数解释性变差。实际项目中我采取的方案是两者结合TF-IDF做初筛召回语义向量做精排。先算一遍稀疏向量快速捞回简历池里最相关的200份再用稠密向量对这200份做精细排序。这样既控制算力成本又规避了纯TF-IDF的词汇鸿沟。后续章节我会给出这两步的完整代码实现。3. 从零实现简历推荐核心数据清洗、特征提取与相似度计算这一章直接上可运行的代码。环境依赖是Python 3.8以上、pandas、jieba、scikit-learn、numpy这些都能用pip install直接装。建议不要一上来就追求大而全先让代码在本地100份简历上跑通再考虑扩大规模。我下面按“数据清洗 → 特征提取 → 相似度计算 → 召回精排”四步来写。3.1 简历数据清洗处理文本中的“垃圾字符”从招聘网站导出的简历文本通常带着一堆杂质HTML标签、备注符号、特殊分隔符、邮箱电话、全角半角混排。直接用这种文本做分词词表里会出现大量“”“ ”这类垃圾词拉低相似度计算质量。清洗的原则是宁可多删不可漏删但注意不要误删关键信息。import re def clean_text(text: str) - str: # 去掉HTML标签和实体 text re.sub(r[^], , text) text re.sub(rnbsp;|amp;, , text) # 将全角字符转为半角中文标点除外 text .join( chr(ord(c) - 0xFEE0) if 0xFF01 ord(c) 0xFF5E else c for c in text ) # 去掉URL、邮箱、电话号码 text re.sub(rhttps?://\S, , text) text re.sub(r\w\w\.\w, , text) text re.sub(r1[3-9]\d{9}, , text) # 去掉多余空白 text re.sub(r\s, , text).strip() return text if __name__ __main__: sample p姓名张三 nbsp; 电话13800138000/pp邮箱zhangsantest.com/p print(clean_text(sample))这段代码的清理逻辑分四层第一层用正则去掉HTML标签和实体这是解析网页简历最基础的清洗第二层把全角字符转成半角因为后面分词器对全角和半角字符的处理方式不一样全角逗号“”如果不转成“,”会在分词时造成割裂第三层去掉URL、邮箱、手机号这些信息对技能匹配没有贡献但对词频统计有干扰第四层压缩连续空白符为分句和分词做准备。注意电话正则1[3-9]\d{9}只匹配大陆手机号如果简历里有座机或分机需要再加规则。这块不追求一次到位生产环境是不断在清洗规则里补充新样本的。3.2 分词与自定义词典加载让“Python开发”不被切开清洗完文本下一步做分词。我推荐用jieba因为它对中文分词的默认效果在同级别工具里算好的而且支持自定义词典。下面代码里的关键点有两个一是加载自己整理的领域词典技术栈、岗位名、常见项目名词二是用cut_for_search而不是cut做分词——cut_for_search是搜索引擎模式词切得更碎、召回更全面。import jieba import jieba.analyse # 加载自定义领域词典每行一个词UTF-8编码 jieba.load_userdict(/data/user_dict.txt) # 示例词典内容 # 全栈工程师 # 分布式架构 # 自然语言处理 # K8s # 高并发 def tokenize(text: str) - list[str]: words jieba.cut_for_search(text) stopwords set() with open(/data/stopwords.txt, r, encodingutf-8) as f: for line in f: stopwords.add(line.strip()) return [w for w in words if w.strip() and w not in stopwords and len(w) 1] if __name__ __main__: sample 参与设计高并发分布式架构负责NLP算法落地 print(tokenize(sample))load_userdict的路径在生产环境建议用配置文件或环境变量注入不要硬编码。分词后做了一个停用词过滤和单字过滤len(w) 1这条规则能去掉大量“的”“了”“是”之类的单字。注意单字过滤是双刃剑——如果JD里写“JAVA”分词后可能是单个“JAVA”也可能被拆成“JAVA”一个词一般不会被拆成单字所以这条规则比较安全。但如果简历里出现“C#”这种特殊写法分词器切成“C”和“#”就会被误删这种情况要放到自定义词典里去兜底。分词质量直接影响后面所有步骤这里有个省力的排查技巧先用代码随机抽20份简历把分词结果打印出来人工扫一遍重点关注技术栈是否被正确切分人名地名是否被错误合并。扫描一轮比调三天参数都有效。3.3 TF-IDF向量化与余弦相似度推荐算法的最小可用版本分词做完向量化就是一个TfidfVectorizer调用的事。下面代码实现了“简历库建立索引 → 输入JD → 输出Top-N简历”的完整流程。这里我故意不用sklearn的cosine_similarity函数而是用矩阵乘法自己算原因放在代码后面讲。import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer import numpy as np class ResumeRecommender: def __init__(self, max_features5000, ngram_range(1, 2)): self.vectorizer TfidfVectorizer( max_featuresmax_features, ngram_rangengram_range, sublinear_tfTrue ) self.resume_vectors None self.resume_ids None def fit(self, resumes: list[str], resume_ids: list[str]): 将简历语料转成TF-IDF向量矩阵 self.resume_ids resume_ids self.resume_vectors self.vectorizer.fit_transform(resumes) def recommend(self, jd_text: str, top_n: int 10, min_score: float 0.1) - list[tuple[str, float]]: 输入JD文本返回简历ID列表及相似度分数 jd_vector self.vectorizer.transform([jd_text]) # 余弦相似度 向量内积 / (模长乘积) # 用稀疏矩阵乘法一次性算完所有简历的相似度 scores self.resume_vectors.dot(jd_vector.T).toarray().ravel() # 计算模长进行归一化TF-IDF矩阵行向量模长不为1 row_norms np.sqrt(np.asarray(self.resume_vectors.multiply(self.resume_vectors).sum(axis1)).ravel()) scores scores / (row_norms * np.linalg.norm(jd_vector.toarray()) 1e-9) # 按分数降序排序 ranked_indices np.argsort(scores)[::-1] results [] for idx in ranked_indices: if scores[idx] min_score: continue results.append((self.resume_ids[idx], float(scores[idx]))) if len(results) top_n: break return results if __name__ __main__: resumes [ 5年Python开发经验精通Flask和Django熟悉MySQL, 高级Java工程师熟悉Spring Boot和微服务架构有高并发经验, 数据挖掘工程师熟练掌握Python和Pandas了解Spark ] recommender ResumeRecommender() recommender.fit(resumes, ids[R1, R2, R3]) jd 负责Python后端服务开发熟练使用Flask框架优先 for rid, score in recommender.recommend(jd): print(f{rid}: {score:.4f})这段代码里最值得说的两个参数。第一个是sublinear_tfTrue它把词频从tf替换成1log(tf)作用是让“Python”出现20次和出现25次对特征权重的影响差距变小——一个人反复写“Python”不代表他更匹配。第二个是ngram_range(1, 2)它让向量化时同时考虑单个词和相邻两个词组合比如“分布式架构”会被当成一个整体特征捕获而不是拆成“分布式”和“架构”两个独立词。代价是特征维度变多训练时间变长所以我又加了max_features5000来限制字典规模。为什么不用cosine_similarity函数因为它在数据量大时会一次性生成一个(n_resumes, n_resumes)的稠密矩阵一万份简历就是1亿个浮点数内存直接爆炸。我用矩阵乘法一次算出JD和所有简历的相似度向量(n_resumes, 1)内存开销小一个量级。1e-9是防止某一份简历向量全为0导致除零错——这种情况真的会发生空文本或全停用词清洗后的文本就是全0向量。3.4 用Sentence-BERT做语义精排解决词汇鸿沟问题纯TF-IDF的局限前面说了字面不重叠语义相关的词匹配不上。改进思路是用预训练语义模型给简历和JD各算一个稠密向量在语义空间算相似度。这里不需要自己训练模型直接用huggingface/transformers库加载中文Sentence-BERT模型。第一版不需要微调直接用预训练向量就能看出效果差异。from sentence_transformers import SentenceTransformer import numpy as np class SemanticRescorer: def __init__(self, model_name: str paraphrase-multilingual-MiniLM-L12-v2): # 多语言模型对中文支持良好模型体积约120MB self.model SentenceTransformer(model_name) def embed(self, texts: list[str]) - np.ndarray: # normalize_embeddingsTrue 让所有向量模长为1余弦相似度退化为点积 return self.model.encode(texts, normalize_embeddingsTrue, show_progress_barFalse) def rescore(self, jd_text: str, resume_texts: list[str]) - list[float]: jd_vec self.embed([jd_text])[0] resume_vecs self.embed(resume_texts) # 向量已归一化点积即余弦相似度 scores resume_vecs jd_vec return scores.tolist() if __name__ __main__: rescorer SemanticRescorer() jd 我们是一个电商平台需要处理大促期间的高并发流量 resumes [ 熟悉分布式缓存和消息队列参与过双11大促保障, 负责过公司官网的日常开发和维护 ] scores rescorer.rescore(jd, resumes) for i, s in enumerate(scores): print(f简历{i}: {s:.4f})注意这个例子JD里没有出现“分布式”“消息队列”“大促”这些词但候选简历1的语义向量会和JD更接近。这就是语义模型相对TF-IDF的核心价值。normalize_embeddingsTrue这一步非常关键如果不做归一化点积结果会受向量模长影响——长文本的向量模长普遍更大导致排序偏差。第一个坑是首次运行会从HuggingFace下载模型网络环境不好可能需要配置镜像第二个坑是这个模型是按句子级别编码的如果直接把5000字的简历塞进去模型会截断文本效果大打折扣。常见做法是只把工作经历和技能描述拼成一段不超过512字符的核心文本再编码而不是整篇简历一股脑喂进去。4. 工程化落地从简历解析到推荐结果的可解释输出前面的代码在100份简历上跑得通直接上生产一定会被各种非技术问题打爆。工程化落地阶段核心工作不在算法而在数据管道和系统设计。我总结成三块简历文本解析、JD关键信息抽取、推荐结果的解释性输出。每一块都有具体的坑踩过一个能省一周调试时间。4.1 简历格式解析PDF与Word文件的文本抽取真实业务场景里简历以PDF、Word.doc/.docx、图片为主。纯文本简历反而是少数。不同格式的解析方案完全不同PDF用pdfplumberWord用python-docx图片用OCR。最省事的方案是接入第三方文件转换API把PDF和Word统一转成HTML或纯文本后再抽取内容如果必须本地处理下面这段是相对稳定的方案组合。import pdfplumber from docx import Document def extract_text_from_pdf(pdf_path: str) - str: # 注意pdfplumber提取的文本带坐标信息不适合直接拼接 all_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 只提取页面中的文字块忽略页眉页脚 text page.extract_text(layoutTrue) if text: all_text.append(text) return \n.join(all_text) def extract_text_from_docx(docx_path: str) - str: # python-docx 只支持 .docx不支持老版 .doc doc Document(docx_path) lines [] for para in doc.paragraphs: if para.text.strip(): lines.append(para.text) # 表格里的信息如技能清单、学历信息不能丢 for table in doc.tables: for row in table.rows: row_text .join(cell.text.strip() for cell in row.cells if cell.text.strip()) if row_text: lines.append(row_text) return \n.join(lines)pdfplumber的extract_text(layoutTrue)按版面位置还原文本适合两栏式简历但两栏简历会读出左右两栏交错的文本。.doc老格式用python-docx打不开常见的办法是调用本机WPS或LibreOffice命令行转格式。图片简历只能走OCRpaddleocr对中文简历的效果不错但需要安装PaddlePaddle框架首次安装的依赖冲突比较头疼。解析这块我的建议是第一版只支持.pdf和.docx两种格式其他格式统一提示“简历格式暂不支持”把长尾格式排在后面处理。4.2 JD结构解析任职要求怎么拆出关键条件JD不像简历那么长但它的信息密度高而且是结构化文本。一个典型的JD包含岗位名称、岗位职责、任职要求、加分项四段。可以按“第几条”“对候选人要求”“加分项”之类的关键词做段落粗分。粗分之后关键的抽取工作是三个维度硬性条件学历、工作年限、技能关键词、软性能力沟通、抗压。技能关键词最适合用规则抽取——维护一个技能词库把“Python”“Java”“K8s”等词和JD文本做子串匹配命中即标记。import re SKILL_TERMS [ Python, Java, Go, C, K8s, Docker, MySQL, Redis, Kafka, Flask, Django, Spring, Hadoop, Spark ] def extract_skills_from_jd(jd_text: str) - list[str]: skills set() for term in SKILL_TERMS: # 用正则做词边界匹配避免Java把JavaScript误命中 pattern r(?![A-Za-z]) re.escape(term) r(?![A-Za-z]) if re.search(pattern, jd_text, re.IGNORECASE): skills.add(term) return sorted(skills) def extract_work_experience_requirement(jd_text: str) - int | None: # 匹配3年以上、五年及以上等表述统一转成数字年份 pattern r([一二三四五六七八九十\d])\s*年(?:以上|及以上|以上经验|工作经验) match re.search(pattern, jd_text) if not match: return None num_map {一: 1, 二: 2, 三: 3, 四: 4, 五: 5, 六: 6, 七: 7, 八: 8, 九: 9, 十: 10} raw match.group(1) if raw.isdigit(): return int(raw) return num_map.get(raw, None) if __name__ __main__: jd_text 岗位要求Python开发熟练使用Flask3年以上后端开发经验熟悉Docker者优先 print(extract_skills_from_jd(jd_text)) print(extract_work_experience_requirement(jd_text))(?![A-Za-z])和(?![A-Za-z])这两个断言是防止“Java”匹配到“JavaScript”、“Ruby”匹配到“RubyGems”。技能词库的维护是个长期活建议定期看搜索热词和招聘网站高频词做增补。年限抽取的正则覆盖了“X年以上”“X年以上经验”“X年工作经验”“X年以上工作经验”四种表述但“本科3年经验”这种复合表述会失效需要额外做规则扩展——不过第一版够用了。4.3 推荐分数的解释性输出让业务方愿意信任这个系统算法跑出来的推荐结果如果只给一个相似度分数业务方是不敢用的——他们不知道这个分数含义。要让推荐结果在真实场景中被接受必须在输出时附带理由。常见做法是把技能匹配、工作年限匹配、学历匹配、文本相似度四个维度的得分单独算出来推荐结果卡片上展示为“技能匹配度0.8年限符合学历本科整体相似度0.75”这样业务方能一眼看出这份简历为什么被推荐。import json def explain_result(resume: dict, jd_skills: list[str], sim_score: float) - str: matched_skills set(resume.get(skills, [])) set(jd_skills) skill_match len(matched_skills) / max(len(jd_skills), 1) # 假设resume里已有work_years字段 years_match 0.5 if resume.get(work_years) is not None: years_match 1.0 if resume[work_years] 3 else 0.3 reason { 匹配技能: sorted(matched_skills), 技能覆盖率: round(skill_match, 2), 年限匹配: years_match, 文本相似度: round(sim_score, 2), 推荐理由: f匹配了{len(matched_skills)}项核心技能 } return json.dumps(reason, ensure_asciiFalse) if __name__ __main__: resume {skills: [Python, Docker, Django], work_years: 4} jd_skills [Python, Docker, Flask] rec explain_result(resume, jd_skills, sim_score0.72) print(rec)解释性输出这块工程上建议结构化存储推荐原因方便后续做A/B测试和推荐结果复盘。这一步是算法系统从“做出来了”到“能上线”的分水岭。业务方对推荐系统的信任不是靠准确率指标建立起来的是靠“这个推荐理由说得对”建立起来的。5. 简历推荐算法避坑指南4个让系统翻车的典型问题算法本身的代码逻辑出问题反而不常见真正让推荐系统翻车的往往是数据和工程上的细节。我在下面列了4个踩过坑的问题都是真实会发生的按“现象→原因→解决”写。5.1 现象所有简历相似度分数都接近0.8没有区分度某次测试无论JD怎么换所有简历的相似度都稳定在0.7到0.85之间排序结果几乎随机。排查了很久最终发现问题出在文本清洗环节——数据处理时忘了移除“自我评价”段落。候选人的“勤奋踏实、沟通能力好、抗压能力高”这些套话几乎相同在整篇简历的向量里占据了大头把真实技能差异的文本比例稀释了。另一个原因自定义词典加了很多泛化行业词如“技术”“方向”“负责”这些词在所有简历里都高频却没有进停用词表。解决两件事。第一过滤自我评价段落或者至少给它降低权重第二重新整理停用词表把“负责”“熟练”“了解”“使用”这类在技术简历里出现频率极高但对区分度毫无贡献的动词加进去。处理之后相似度分布恢复到0.1到0.8之间排序有了层次。这个教训是看相似度分数分布是诊断推荐系统是否健康的第一步。5.2 现象分词把“C”切成了“C”“”“”技能匹配率骤降技能匹配模块运行了半个月发现命中“C”这个关键词的简历始终是0而候选简历里明明很多人写了“C”。打印分词结果一看jieba把“C”切成了“C”和“”。原因是加号字符不是单词字符默认分词器不认识这个组合词。类似的问题还有“C#”“.NET”“Node.js”。解决两步。第一步把这些特殊写法全部加进自定义词典一行一个词第二步清洗阶段做字符归一化把“C”统一替换成“CPLUSPLUS”把“C#”替换成“CSHARP”把“.NET”替换成“DOTNET”分词完成后再替换回来。这样做的好处是避免分词器反复踩同一个坑而且替换后的文本对其他词的分词没有副作用。5.3 现象冷启动新JD推荐出来的全是“老油条”简历测试人员拿一个全新岗位的JD去跑推荐输出前10名全是8年以上工作经验的资深候选人而实际业务方想招的是1-3年经验的初级岗位。原因在余弦相似度的缺陷经验年限高的简历通常文本更长、技能词更多向量模长更大相似度天然偏高。但这并不是真正的匹配度。解决分项匹配里必须把工作年限作为一个硬性过滤条件而不是软性加权项。实现上用规则先过滤年限不符合要求的简历直接不进候选集再做相似度排序。类似地学历要求和城市要求也建议做硬规则原因很简单这些字段是结构化数据用规则判断是100%准确的交给文本相似度反而不靠谱。5.4 现象Python环境里装包频繁报错推荐代码跑不起来这不是算法问题但它在所有踩坑记录里出现的频率最高。现象是pip install sentence-transformers装完导入时报错“cannot be resolved against python helper roots”或者和numpy版本冲突。最著名的坑是transformers库要求numpy1.20但老环境里numpy是1.19一装就把环境搞坏了还有Python 3.8以下对typing的语法支持不全。解决第一用虚拟环境隔离项目依赖不要直接装系统Python。Python 3.10及以上配合python -m venv venv创建虚拟环境再pip install。第二先装核心依赖再装算法库顺序是numpy→pandas→scikit-learn→jieba→transformers每装一个跑一次import验证出了错能迅速定位是哪个库的问题。第三把Python版本锁在3.9到3.11之间太新的版本有些库的wheel还在适配过程中我的习惯是3.10.x最稳。6. 从能跑到好用推荐质量评估和三个优化技巧代码能跑、App能出推荐结果这只是起点。真正让推荐系统产生业务价值靠的是持续评估和迭代。最后一章分享评估方法和三个投入产出比最高的优化方向。6.1 用线上反馈数据评估推荐效果推荐系统上线后一定要记录曝光和点击。衡量指标有三个PV点击率推荐列表里被点开的比例、采纳率HR把推荐简历纳入流程的比例、转化率推荐进来的候选人最终被录用的比例。这三个指标是递进关系其中“点击率”受展示位置影响大“采纳率”更接近推荐质量本身。我不建议用A/B测试直接比较两版算法因为简历推荐场景的数据量通常不足以让差异显著——更好的方式是做“在线切换后在同样的时间段内对比采纳率”。离线评估可以用标注数据找三份JD每份配100份简历人工标注“高匹配/中匹配/低匹配”三等然后算排序结果和人工标注之间的排序相关性。这个工程不复杂但非常有价值——它能让你在改完参数后半小时内知道效果变好还是变坏不用等线上数据积累。6.2 三个性价比最高的调优方向第一个方向是简历内容分层加权。同样是文本相似度工作经历和技能列表的权重应当高于自我评价和教育背景。实现方式有两种简单做法是分词前把不同段落拼成不同重复次数规范做法是分段落分别向量化再加权合并。推荐第二个代码改动不大但效果提升显著。第二个方向是JD技能词的动态扩展。技能词库不要只依赖人工维护可以每周从新岗位JD里做一次词频统计把高频词加入候选词表人工审核后进词典。这样系统对新岗位的适应性会越来越强。第三个方向是相似简历去重。同一个候选人可能投了多份格式不同的简历推荐结果里出现“同一个人占两个位置”的情况很常见。用姓名电话做指纹归一化计算前先合并。6.3 微小但重要的候选集裁剪技巧一种有效但很容易被忽略的做法计算相似度前先根据城市、薪资期望等结构化字段做一次粗筛。假设JD明确要求“北京海淀”那简历里写“可远程/不限城市”的候选人排在后面对业务毫无意义。粗筛可以砍掉60%的候选集精排阶段的计算量直接下降一个量级。另外相似度阈值min_score不要设死我的习惯是看一段时间的分布后动态调整——如果某周召回数量偏低就是阈值设太高了适当回落。最后说一个判断自己有没有做好的笨办法每周手动检查一次推荐列表把“看起来明显不该推荐”的case挑出来分析是哪一步让系统翻了车——是分词、向量化、还是排序权重。做满一个月你对自己这个系统的边界会非常清楚然后你就改。这也是我到现在还保持的习惯虽然不能保证推荐系统永远准确但能确保它在每次改版后不偷偷变傻。希望帮到你。本文还有配套的精品资源点击获取