1. 项目背景与核心挑战在人力资源领域简历筛选一直是个让人头疼的活。想象一下HR每天要面对上百份简历每份都得仔细看生怕错过合适的人选。这种传统的人工筛选方式效率低不说还容易因为个人偏好导致判断偏差。我曾经见过一个案例某公司因为HR对985高校的执念错过了一位GitHub上有多个高星项目的候选人。更糟的是关键词匹配这种老方法已经跟不上时代了。现在的技术术语五花八门同一个技能可能有十几种叫法。比如Python Web开发可能被写成Django后端、Flask全栈或者FastAPI微服务但传统系统很可能因为关键词不匹配就把这些简历过滤掉了。2. 系统设计思路2.1 传统RAG方案的局限性最开始我考虑直接用现成的RAG(检索增强生成)方案。这法子简单粗暴把简历转成向量存起来查询时找最相似的。但实测下来问题一大堆语义泛匹配太不精准。有次搜索5年Java经验结果返回的全是3年Python经验的简历只因为描述方式相似。硬性条件没法处理。比如要求必须本科学历但向量搜索可不管这个。解释性太差。系统告诉你这份简历匹配度80%但说不清为什么匹配。2.2 我们的改进方案经过多次迭代我们设计了一个三阶段筛选漏斗语义初筛先用向量检索找出50份可能相关的简历硬性过滤用规则引擎筛掉不符合硬指标的比如学历、年限精细评分对剩下的简历从6个维度打分排序这个设计最大的优点是平衡了召回率和准确率。第一阶段广撒网确保不错过任何潜在人选第二阶段严格把关剔除明显不合格的最后阶段精细评估找出最匹配的候选人。3. 关键技术实现3.1 简历解析与信息提取处理PDF简历是个技术活。我们试过各种解析工具最后选择了LlamaParse因为它能很好地保留文档结构输出Markdown格式。比如这样## 工作经历 - **高级Java工程师** | 某科技公司 (2019-2023) - 负责分布式系统架构设计 - 使用Spring Cloud微服务框架更关键的是元数据提取。我们定义了一个结构化模型用LLM从文本中提取关键信息class CandidateMetadata: name: str skills: List[str] # 最多10个核心技能 education: str # 学历标准值本科/硕士等 work_years: int # 工作年限 # 其他字段...这里有个实用技巧对技能名称做归一化处理。比如把JS、JavaScript、ECMAScript都映射到标准名称JavaScript。3.2 向量索引构建我们用ChromaDB做向量存储每个文档包含原始文本和提取的元数据。索引时特别注意对长简历做分块处理每块不超过512个token为每份简历生成唯一的指纹哈希避免重复处理元数据单独存储方便后续过滤document Document( textresume_text, metadata{ skills: [Python, Django], education: 硕士, # 其他元数据... } ) index VectorStoreIndex.from_documents([document])3.3 查询理解模块HR的查询可能是自然语言比如找3-5年经验的Python后端熟悉Django最好有云计算经验。我们用LLM将其解析为结构化条件{ min_years: 3, max_years: 5, required_skills: [Python, Django], preferred_skills: [云计算], education: 本科及以上 }这里有个细节我们会维护一个技能同义词库确保查询中的技能名称与简历中的标准化名称匹配。4. 核心筛选算法4.1 三阶段筛选流程语义初筛用查询文本生成向量从向量库检索Top50相似简历相似度阈值设为0.65低于的直接淘汰硬性过滤def hard_filter(candidate, requirements): if candidate.work_years requirements.min_years: return False if requirements.education 本科 and candidate.education 专科: return False # 其他硬性条件... return True综合评分行业匹配度(35%)完全匹配100分相关50分技能匹配度(35%)必须技能每个20分优先技能每个10分其他维度(30%)薪资、学历、地点等4.2 评分算法细节我们设计了细粒度的评分规则。以技能匹配为例def calc_skills_score(candidate, requirements): score 0 # 必须技能 for skill in requirements.required_skills: if skill in candidate.skills: score 20 # 优先技能 for skill in requirements.preferred_skills: if skill in candidate.skills: score 10 # 额外技能奖励 extra_skills set(candidate.skills) - set(requirements.all_skills) score len(extra_skills) * 5 # 每个额外技能5分 return min(score, 100) # 百分制封顶薪资匹配算法更复杂些要处理各种表达方式20K → 200001.5万 → 15000面议 → 特殊处理5. 结果展示与解释最终输出不是简单排序而是包含详细解释的评估卡片候选人张三 匹配度87/100 【关键评估维度】 ✓ 技能匹配 (35/35) - 精通Python、Django符合要求 - 熟悉AWS优先技能加分 ✓ 行业经验 (30/35) - 5年互联网后端开发要求3-5年 ⚠️ 薪资注意 (8/10) - 期望25K岗位预算20-25K在范围内但偏高 【LLM综合评价】 张三是位经验丰富的Python后端工程师完全满足技术要求。 建议面试时确认薪资期望是否可协商。这种展示方式帮助HR快速理解候选人的优劣势比传统的关键词匹配直观多了。6. 实战优化技巧在实际部署中我们总结了几条宝贵经验缓存策略简历解析结果按内容哈希缓存元数据提取结果缓存24小时向量索引每周全量更新每日增量更新性能优化硬性过滤先用数据库查询缩小范围向量搜索限制在过滤后的子集进行评分计算使用批量处理评估指标召回率确保不错过合格候选人准确率尽量减少误匹配HR满意度收集用户反馈持续优化特殊处理对全栈这类模糊标签做细化解析处理精通/熟悉/了解等程度副词识别和管理简历中的夸大描述7. 典型问题排查在开发过程中我们踩过不少坑这里分享几个典型案例问题1技能匹配不准现象Python开发者匹配到大量Java简历原因两类简历都提到后端开发语义相似解决在语义搜索阶段加入技能关键词boost问题2学历误判现象专升本被错误归类为专科原因LLM对复杂学历描述理解不准解决细化prompt添加示例few-shot问题3薪资范围匹配错误现象15-20K与18K不匹配原因系统将范围视为字符串而非数值解决开发专门的薪资解析模块8. 扩展应用场景这个框架不仅适用于简历筛选稍加改造就能用于其他匹配场景人才库挖掘定期扫描现有员工简历识别适合新项目的内部候选人岗位推荐反向为求职者推荐合适职位基于简历内容智能生成求职建议面试准备根据简历和JD生成定制化面试问题预测候选人可能存在的知识盲区未来还可以整合更多AI能力比如自动生成个性化面试邀请基于过往面试记录的偏见检测候选人职业发展潜力预测