智能简历匹配系统：突破传统筛选困境，实现高效精准的AI招聘解决方案

简历筛选在招聘流程里是核心环节，传统方法极度依赖人工，效率低还易遗漏，本文会尝试去设计以及实现一个基于LLM的智能简历匹配系统，借助多维度多层次的评估，领会真实的招聘需求，达成自然语言交互的、智能化的、可量化的简历筛选过程。

01

挑战与系统目标

传统人力资源管理（或者人力资源管理系统）在进行简历匹配以及筛选这一行为的时候，严重依靠人工去进行筛选是这样的模式。除此之外，还出现了下面几点需要面对的难题：

跟着大模型也就是LLM与AI所处时代的来临，有希望借由自动化的候选人匹配以及给出很有洞察力的数据驱动分析，来让招聘流程得以优化，进而提升工作效率，而这里面最为关键的环节便是智能成效高的简历匹配跟筛选。

我们怀着期望，期望那基于LLM的智能简历筛选系统，能够对以上痛点起到有效的缓解作用，并且实现以下这些核心能力：

02

[id_647104129]

【经典RAG方法的不足】

达成一个以 LLM 为根基的简历匹配系统，最为径直的想法便是借助 RAG（检索增强生成）的理念，凭借基于向量的语义检索去获取相匹配的简历，流程是这样的：

然而，就像多数经典RAG置于真实场景里的应用成效常常难以令人满意一般，此种简易方案于真实运用当中是远远欠缺的，呈现于：

即便相较于关键词匹配而言有着颇为显著的进步，然而从本质上来说依旧属于模糊匹配，举例来讲，像“3年Python经验”以及“5年Java经验”这两者可能存在着较高程度的语义相似性，不过其技能却并不相互匹配。 .

比如说，那种工作年限要大于等于3年的这类硬性规定，就不太适宜运用语义相似度去做筛选。同样的，薪资范围是15 - 25K以及期望是20K的这种匹配情况，也不适合借助向量来达成。

向量算法能够给出相似度分数，然而却没办法去解释缘何匹配，如此情形致使HR不能够很好地理解候选人的具体优势所在以及具体不足所在，这进而会使得HR对于AI结果的信任度有所降低。

鉴于简历格式以及内容存在着多样性，关键信息易于遭受“稀释”态势，致使匹配精准程度不足；像不太具重要意义的兴趣爱好，有可能对匹配结果产生影响 。

【升级的方案】

我们在简单的向量匹配方案上做升级，核心思想总结成三点：

核心匹配进程是个历经三阶段的挑选进程，会逐一渐渐缩减候选范畴，最终给出候选人，。

像上面展示的那样，从人力资源专员的自然语言需求出发，或者从给定的职位描述去开始，之后借助语言模型解析并且提取结构化信息，当然在这之前要先对候选简历做向量索引，。

这种呈现为漏斗形状的筛选流程，保障了效率与准确度的平衡，首先在第一阶段之时，会快速地进行粗筛操作，做到不使任何一份可能具有相关性的简历被遗漏，接着来到第二阶段，要保证关键要求能够得到充分满足，随后第三阶段，针对符合要求的人员进一步开展精细的打分以及排序工作。

【系统模块架构】

系统有着诸核心模块架构情形如下，靠左边之处存在着简历文档库以及对其展开的解析处理范畴，而右侧的状况呢，则是输入查询环节以及核心的筛选又或者输出流程：

主要包含以下模块：

03

关键实现要点

于这一范畴之内，我们会深度钻研该系统于达成进程里的若干关键技术要点，涵盖了：简历剖析、元数据抽取、向量索引构建、查询领会、匹配演算法还有结果产出等方面内容 。

【简历解析：从PDF到结构化内容】

挑战在于，简历常常是以Word或者PDF文档的形式来提供的，直接针对PDF展开分析是不太方便的。通常情况下，先是要将PDF转化为机器能够读取的文本格式，并且要尽可能地去保留简历的结构以及关键信息。

方案：运用成熟的文档解析器，借助多模态大模型，针对PDF展开解析，并输出呈现为Markdown格式的文本，诸如LlamaParse/RAGFlow等 。

......
## 教育背景
学历为本科，专业是计算机科学与技术，毕业院校是清华大学，时间跨度为2014年至2018年 。
## 工作经验
在XYZ科技，担任对Python有所涉及，并专注于后端领域的工程师一职，从2018年开始，一直持续到现在 。
  - 参与开发分布式后台系统，使用Django框架...

怎样凭借成熟的解析器以及多模态模型，把PDF乃至PPT解析成为Markdown，我们于之前的文章当中都有着详实的阐述，在这里不多做展开说明了。

【元数据生成：简历结构化信息提取】

把简历转变成Markdown仅是起始的第一步，我们另外还得从其中提炼出关键的结构化信息，从而方便后续的匹配以及过滤工作。比如说候选人姓名，联系方式，技能列表，工作年限，学历，期望薪资，工作地点等等 。

通常，我们能够去定义一个Metadata元数据模型，借此去统一表示这些字段，：

class Metadata(BaseModel):
名字，是，字符串类型，用于表示，一个人的，称呼。
邮箱，标识为，str形态 ，是 email # 句号。
Phone，这是一个用来表示电话的字符类型，它被定义为字符串（str） 。
技能：列表（字符串类型），# 核心技能的列表（数量最多为10个）。
领域：字符串类型，# 此意为所属的领域范围（像 IT、金融、销售等等之类），标点。
学历标注为：字符串类型，专门用于表示最高学历，其包含的可能类别为本科、硕士、博士以及专科 。
work_years：这是用以表示工作年限的，它属于整数类型，占据一定的数据空间，反映工作的时长计量采用的是整数形式，代表着工作经历的年数是以整数来体现的 。
薪资（被表述为“20 - 25K”这般形式），其数据类型为：字符串。
当前所在位置：列表类型，元素为字符串 ，# 现居地 。
自定义标签：列表[str 类型]，为个性采用不同标签，像属于技术专家范畴，具备沟通能力强性质来标定等意思（这儿就是在解释说明所谓个性标签的具体所指）。
    ....

借助具有直接结构化输出能力的LLM，编写一个Prompt供其根据解析后的简历Markdown填写上述Metadata模型以供利用信息从事提取行为： 这里最好是这样做的 。

......
对元数据进行处理时，需要等待，之后会由自我大型语言模型经过清晰确定有明确构建构架的预测行为来交付工作内容，确切地表现为这样一番操作流程 ，这番操作用其形式来呈现，即为 ，元。
        Metadata,
        prompt_template,
        text=text,
    )
    # 保存到缓存
保存元数据到缓存，文本，元数据， 把这一个里的文本数据，以及另一个里的元数据，进行保存到缓存的操作， 用文本，还有元数据，达成。

因要达到开销减少之效，你能够为该步骤做结果缓存，像是凭借简历文本内容去生成哈希值当作缓存键，从缓存中存入提取结果当作缓存值 。

需留意，所提取的成果时常得进行规范化。比如呀，要将多个技能名称进行同义词的归并，好比把“JavaScript”以及那个“JS”归为同一种技能；学历也要统一成标准的描述等之类的情况。一种办法是借助提示词来加以限定，就像针对学历；还有另一种办法呢，是让LLM去搜集而后予以保存，在后续进行筛选的时候再运用搜集的结果来做限定，比如针对技能。

【向量索引：用于语义检索】

先是完成原始简历文件的解析，接着提取出足够的结构化关键信息，之后便能够使用传统的RAG方法去创建向量索引。借助开发框架能够快速完成，举例来说是以LlamaIndex作为例子，这些步骤有先后，且是连贯的，以此为流程去操作。

 #针对解析的每个文档做处理
 for... 
    document = Document(
        text=full_text,
        #设置LLM提取的元数据 
        metadata={
请你提供完整的句子内容，以便我按照要求进行改写。仅“'skills':...”这样不完整的表述无法准确改写 。
您提供的内容似乎不完整，请补充完整句子以便我进行改写 。
        }
    )
记录文档的列表呀，把那个文件呢，添加进去放到已处理文档列表里呐。。
...  
          

print(" 创建新的向量索引...")
# 创建向量存储与索引 
储存上下文，经由从默认设置里取用向量储存就是此向量储存这一方式而形成，此向量储存指正在用于构建实例的那个向量储存 。
使用文档创建向量存储索引，索引被赋予一个标志，该标志就是index ，from代表从哪里来，documents表示文档 ，通过这种方式进行操作的有一个名为Vector。
        processed_documents, 
存储上下文等于存储上下文，这一情况是存在的，它就处于这样一种状态，即存储上下文与自身相等，是这样一种状况，没错，就是存储上下文等于存储上下文 。
)     
#检索器：用于语义检索   
retriever等于，自我索引经由，作为检索器之方式，相似度顶尖个数设定为相似度顶尖个数参数值 ，所得到的结果 。
...

在实际的应用情形当中，同样是需要对于索引的缓存机制予以考虑的，以此规避掉那些不必要性的重复嵌入情况产生。在索引得以完成之后，你便能够获取到检索器，而这之后也是将会被运用到语义检索方面的 。

【查询理解：从自然语言到过滤条件】

HR的筛选需求是那种并非结构化的自然语言，系统要把它转变为能够使用的结构化条件，这一步同样依靠LLM去达成查询意图解析。举例来说，对照输入查询“寻觅具有3至5年Python后端开发经验的工程师，对Django框架熟悉，具备分布式系统经验”，我们期盼提取出。

当下实现之时，可借助简历解析的时候所采用之相同 Metadata 模型，促使 LLM 开展结构化输出；其中部分信息，能够凭借简历解析之际获得到的列表予以限定，例如技能列表之类的 。

{
  "min_work_years": 3,
  "max_work_years": 5,
逗号隔开：“skills”，包含，“Python”，“Django”，“分布式系统”各项 。
  "domain": "信息技术"
  ......
}

【多阶段筛选：语义+硬性+评分】

阶段1：语义匹配初筛

基于向量检索来开展简历的语义初步筛选工作。能够直接运用HR所提出的查询问题或者JD文本，或者把经LLM进行解析之后的查询关键要点再次加以组织整合成一个查询向量，于向量数据库里检索出相似度是最高的若干简历。选取Top-K（就像50份这样）从而形成初步筛选的列表。

在此过程中可以设定一个相似度阈值，低于阈值的简历不予考虑。

这一步骤，主要是借助语义匹配的召回方式，来将范围予以扩大，进而保证潜在的合格者不会遭受遗漏标点符号。

阶段2：硬性条件筛选

要针对那些经过语义初步筛选的简历，运用硬性的规则进行过滤那般，可举例来说（依据自身的各种需求去设定）：

此一阶段当中，着重于精确匹配，那便是，只要是不符合硬条件的，不管语义关联到何种程度，一概予以一票否决，借此确保，能够进入到下一阶段的候选人，必定是符合基本要求的。

阶段3：多维度综合评分

最终剩余的、契合严格要求的候选人，我们得针对每一个人算出一个综合匹配的评分，去进行排序。在此所设计的综合评分机制是这样的：

其中关键信息的匹配考虑6个维度（权重见上图）：

处于实际应用期间，针对每个维度展开的考虑，均存在着细致入微的区别，此时你得精心去做算法的设计。就拿“薪资”这个维度来讲，HR与简历里针对它的描述，也许会涵盖极为众多的表达方式：像是月薪或者年薪，存在单位方面的差异（比如3万与20K），还有各式各样精确或者模糊的表述（像10K+、2万左右、1.5 - 2万、面议等等）；就算出现不匹配的状况，也需要考量差距的大小情况（差距较小意味着存在协商的可能性）等。在某些维度的匹配度实施计算之际，同样能够借助LLM再加上精心设计的few - shot提示词来予以完成。

针对每个维度的评分，能够被归一化于零至一百分的范围之内。而后，依据重要性进行加权，并将其总和计算得出一个总分。与此同时，能够引入一个初始语义相关性分当作参考参照。其中意味着，由于在规定程度上，向量相似度能够反映出简历与关键文档的整体契合水平，涵盖了一些无法实施结构化量化的隐性信息。最终的得分计算方式是这样的：

......
metadata_score = (
行业匹配所占比例为35%，其计算方式是用领域分数乘以0.35然后相加，。
技能得分乘以零点三五作进一步计算，此为技能匹配部分，占比百分之三十五 。
薪资得分乘以零点一零加上，薪资部分乘以百分之十被计算在内，在这里薪资匹配的占比确切来说是百分之十来求值。
学历匹配方面，教育分数乘以零点一然后加上，这里是百分之十 。
位置匹配部分，是取位置得分乘以零点零五再加上，位置匹配占比为百分之五 。
用于个性标签的，tags_score乘以0.05 的部分，占比为5% 。
    )
# 总匹配度 (语义20%, 元数据80%)
总的分数等于语义分数乘上零点二加上元数据分数乘上零点八 。 注意:原本句子不存在任何明显的冗余字，因此，在不增加字数的前提下，我们尽可能地通过词语替换和语序改变来让句子变得难读却又。
......

那当中的metadata_score呢，是那上面所说的6个维度评分经过加权之后所得到的分数，然而semantic_score呀，是向量语义相似度转化而成的分值哦（就好比乘以100从而得到百分制那样）。在这里呢，赋予结构化匹配80%的权重，赋予语义匹配20%的权重，主要是鉴于结构化信息会更加客观可靠，而语义匹配能够当作辅助参考 。

处于综合评分阶段的时候会有多个状况出现，其中有每位候选人所获得的总分，另外还涵盖着各维度的得分明细，而且还有简单说明，这些内容能够方便HR来理解分数背后所蕴含的含义。

【筛选结果输出】

在筛选以及评分结束之后，要把结果用友善、直观的形式呈现出来，以此方便HR能够快速进行浏览。当然，最为简单的方式是借助元数据将原始简历也就是(pdf文件)的内容直接展示出来，然而为了协助使用者快快知晓候选人的关键信息以及评估结果，设计出一种用于候选人的匹配卡片。此信息涵盖：

借助如此清晰明了、一眼就能看清的卡片式展示呈现方式，HR能够迅速知晓每一位候选人的优势与劣势所在，也就是哪些方面是完全契合要求的，哪些方面又是略微存在不足的。

04

测试与未来演进

我们在上面完成了一个初步设计之为属于基于LLM的简历筛选系统的，并且针对其中存在需要呈现的相关一系列关键要点做了极为详细的解释说明。最后，我们来查看一下关于这个Demo系统的测试所呈现出来的效果：

我们准备了几十份中文简历，交给系统使用，这些简历来自不同行业，有着不同格式与内容，同时，我们还演示筛选方式，有两种，一种是自然语言筛选，另一种是提供JD描述。

当进入系统之后，最先要做的是，完成简历解析这项工作，接着还要完成元数据提取这项工作，之后还要完成索引准备这项初始化工作，：

【自然语言筛选】

需寻找工程师，其要有在信息技术行业三年以上的经验，还要有丰富的商业智能以及云计算经验，学历得是硕士学历以上，年薪要求不超过五十万，工作地点为上海或者北京 。

系统解析与筛选过程如下：

此处在系统当中，会输出处于不同阶段的筛选结果，这对使用者而言，在不同层面有着助于其能够去调整筛选标准标点符号 。

最后筛选出的候选人：

系统会输出候选人，会按照匹配度从高到低进行输出，并且还会输出评估细节，会对结果提供详细的解释。

最后，系统会对候选人有一个综合评价与建议供HR参考：

经由这个案例能够察觉，系统充分地于多个简历里寻获到众多契合要求的人才，与此同时针对略带条件一致的情形（像候选人有所部分依据缺乏相符 ）亦能够甄别挑出来并恰宜地削减名次。这般智能挑选的办法，相较人类借助肉眼浏览，不但可以把效率增添很多倍，尚可越发具备合理性和遍及性。

【使用JD文件筛选】

运用JD文件做筛选，从本质上来说，跟自然语言没有太大的差异，仅仅是增添了对JD文件的解析以及关键信息的抽取，然后后续的评估方法和输出效果维持一致，这里就不再详细去展示了。

【未来演进方向】

通过上述方式，我们凭借AI技术搭建了一个以LLM作支撑的智能简历筛选匹配系统，执行了一些具针对性的设计举措，不过，此处仍留存较多需改进优化的空地领域 ：

然而，智能招聘所涉及的范围并非仅仅局限于此，往后，能够把它延伸发展成为涵盖招聘整个流程的AI智能体系统，让我们尽情设想一番：

随LLM等AI能力持续增强，未来人才招聘是人与AI协同过程，AI高效客观处理数据，HR专注人性化决策，二者相辅相成，实现更高效率、准确性与公平性。

私信“交流”，一起交流LLM应用