基于过滤的Top-k档案匹配

Top‐k匹配查询用于知识库中的基于过滤的档案匹配

Alejandra Lorena Paoletti(B)，Jorge Martinez‐Gil 和 Klaus‐Dieter Schewe
哈根贝格软件能力中心，哈根贝格，奥地利 {Lorena.Paoletti,Jorge.Martinez‐Gil,kd.schewe}@scch.at

摘要

为候选人配置文件找到最匹配的工作机会，或为特定工作提供找到最佳候选人配置文件，分别是人力资源（HR）领域中最常见且最重要的查询类型。这在技术上需要在知识库和关系数据库上研究 top‐k 查询。本文提出了一种能够在关系数据库上执行 top‐k 查询的算法，能够产生有效且高效的查询结果。该方法结合了工作与候选人配置文件之间匹配关系的偏序结构，并对相关数据进行了高效的设计。特别是，聚焦于单一关系——匹配关系，对于实现预期目标至关重要。

1 引言

配置文件描述了一组技能，这些技能要么是个人简历（CV）中详述的个人能力，要么是职位公告通过工作描述列出的要求。在此基础上，档案匹配旨在衡量一个给定的配置文件与一个请求的配置文件之间的匹配程度。尽管档案匹配不仅涉及人力资源领域，还广泛应用于其他众多领域：房地产领域、将系统配置与需求规格进行匹配、图像相似性等。

在HR领域查询知识库方面，通常研究的方法是为给定的配置文件（无论是简历还是工作机会）寻找最佳 k（具有 k ≥ 1）匹配[1]。这构成了通常所说的top‐k查询。Top‐k查询在数据库领域已被深入研究，通常是在关系数据模型的背景下进行的[2,7]。在知识库背景下对这类查询的研究也已开展[6]。

在关系数据库中，Top‐k查询通常通过关联权重或聚合来处理，这些权重或聚合用作对与用户相关的数据部分进行排序需求、相关关系的潜在连接，以及构成预期结果集的元组的排序（或排序）。在查询中计算所有这些步骤是一个高度资源消耗的过程，具体取决于数据的设计和性质。本文的贡献在于利用支持包含层次结构的数据结构，即来自网络数据库并已在面向对象数据库中回顾的环与蜘蛛结构。我们利用这些已知在支持利用层次化数据结构的查询方面表现出色的结构，通过在知识库概念的偏序上进行预加权以及通过匹配度量对元组进行预排序，从而最小化元组的选择和关系的连接，并消除查询中的加权和排序操作。

本文的研究与之前的工作[3]一致，我们在其中探讨了改进档案匹配的技术以及在人力资源领域知识库（KB）中提出膨胀算子的新思路。本研究的起点基于[4]波波夫和耶贝列安通过在知识库中定义基于过滤器的非对称匹配度量来表示分类法的工作。该研究在[5]中进一步扩展，通过加权有向边形式的交叉关系来扩展本体层次结构。

本文组织如下：在第2节中，我们介绍了在[3]中提出的关于档案匹配理论的若干方面，这些内容与本工作相关。我们在第3节介绍在top‐k查询方面的数据组织贡献。在第3.1节中，我们引入一种关系数据库模式以实现top‐k查询，而在第3.2节中，我们展示了一种实现top‐k查询方法的算法。

2 预备知识

本节介绍了[3]中的基本概念，这些概念对于HR领域中档案匹配的表示至关重要。

知识库的TBox中的概念 Ci定义了一个格(L,≤)，我们用 L中的概念Ci来表示给定知识库中的概念 Ci。因此，从现在起，术语TBox和格将作为同义词使用。格 (L,≤) 中的过滤器是非空子集 F ⊆ L，使得对于所有C, C′，当 C ≤ C′成立且 C ∈F成立时， C′ ∈F也成立。

如果 P ⊆I是一个配置文件，则 P以一种自然的方式定义了概念格 L的一个过滤器 F。因此，在确定匹配关系时，我们可以专注于格中的过滤器 F。

如果(L,≤)是一个格，且 F ⊆ P(L)表示该格中的过滤器集合。则一个匹配度量是一个函数 μ: F × F →[0, 1]，使得 μ(F1,F2) =m(F1 ∩F2)/m(F2)，其中 F1,F2 ∈ F。如果 w是与每个概念C ∈ L相关联的权重，那么匹配度量 μ由权重 w(C) = m({C}) ∈[0, 1]定义，使得

$$
μ(F1,F2)= \sum_{C ∈F1 ∩F2} w(C)·\left(\sum_{C ∈F2} w(C)\right)^{-1}
$$

图1. 一个格、其过滤器及匹配度量

示例1。 一个包含四个元素的格： L={C1, C2, C3, C4}最多可定义五个过滤器 F={F1,F2,F3,F4,F5}，如图1（a）和（b）所示。

如果我们给 L 的元素赋予一些权重，例如 w(C1)= 1/2, w(C2)= 2/5, w(C3)= 3/10, w(C4)= 1/2，然后使用公式(1) 计算匹配度量 μ(Fi,Fj) 以及 μ(Fj,Fi)（对于 1 ≤ i, j ≤ 5)，可得到图1(c) 所示的结果。

请注意，通常情况下，匹配度量并不对称。如果 μ(Fg,Fr) 表示给定过滤器 Fg 与必需过滤器 Fr 的匹配程度，那么 μ(Fr,Fg) 则度量了在给定过滤器 Fg 中存在但非必需过滤器 Fr 所要求的技能过剩情况。显然，当 i= j 对于 1 ≤ i, j ≤ 5 时， μ(Fi,Fj) 与 = μ(Fj,Fi) 不相等。

示例2。 以Fr= F3作为所需配置文件，以及两个给定过滤器Fg1= F3和 Fg2= F4为例。根据它们的匹配度量： μ(Fg1,Fr) = μ(Fg2,Fr) = 1，两者都同样且高度符合 Fr中的要求。然而，如果考虑度量 μ(Fr,Fg1) = 1和μ(Fr,Fg2) = 1/2，则 F3比 F4更匹配，因为 C2不属于所需技能集。

3 配置文件匹配的内部结构

在一个建模的选拔过程中，存在一组由格 L中的过滤器定义的配置文件 P，即职位和申请人配置文件，我们用 ϕ表示配置文件为被选中所需满足的条件，那么 Pϕ表示在 P中满足 ϕ的配置文件集合，而 Pr ∈ P是一个必需的配置文件，通过持有条件 ϕ来驱动该选拔过程。

请注意，当提及匹配度量时，我们指的是包含格 L元素权重的公式（1），如示例 1所示。

定义1。 对于所有P ∈ P ϕ和 P′ ∈(P−P ϕ)，从配置文件集合 P ϕ中选择 λ个配置文件，其中 λ ≥ k被选中而 P′未被选中，如果μ(P, Pr) > μ(P ′, Pr)，并且 P ϕ的任何子集都不满足此性质。

为了获得最佳的‐k匹配配置文件（无论是工作还是申请人配置文件），我们首先需要查询表示这些配置文件的过滤器。

考虑 Fr是一个表示所需配置文件 Pr的过滤器，例如一个请求的工作配置文件。然后，考虑 l是 F中的若干过滤器(Fg1,…,Fgl)，这些过滤器代表与 Pr在某种程度上匹配的候选配置文件，满足 ϕ，即它们的匹配度量高于阈值ti ∈[0, 1] ，也就是说，μ(Fgx,Fr) ≥ ti对于 x= 1,…, l成立。

然后，每个 Fgx 表示有限数量的配置文件 j（Pg1,…, Pgj），即与 Pr 匹配的候选配置文件，其中 μ（Pgy, Pr） ≥ ti 对于 y= 1,…, j 和 j ≤ k。

L中的过滤器与由过滤器表示的配置文件数量之间的关系由函数 ν定义：N → N ，其中 ν(x) = j且 ∑ₗₓ₌₁ ν(x) = λ。然后任何 Fgl+1 is not selected不被选为匹配值μ(Fgl+1,Fr) < ti。

至于定义的第二部分，每个过滤器 F ∈ F均由其极小元素唯一确定，因此我们可以写作 F={C1,… Cr}。于是，由过滤器表示的每个配置文件也由 F 中的元素唯一确定。因此，对于 Pϕ子集中的任意配置文件 P′′ ，若匹配值为 μ(P′′, P)< ti，则 P′′不满足该性质。

请注意，我们在函数 ν(x)中使用了 λ而不是 k，因为我们认为 Pϕ中的配置文件λ− k也需要被考虑，因为它们满足 μ(Fgx,Fr) ≥ ti。换句话说，我们选择选取匹配度量恰好高于阈值的所有配置文件，而不是恰好在 k处截断。

示例3。 假设有 A一份工作和四位候选人的配置文件{B, C, D, E}满足 A中的要求，其中五个配置文件由示例1中的过滤器表示，即：

表示配置文件的过滤器	匹配度量
F4 表示 {A, B}	μ(B, A) = 1
F2 表示 {C}	μ(C, A) = 0.63
F3 表示 {D, E}	μ(D, A) = μ(E, A) = 0.5

如果我们选择 k= 3并使用 ti= 0.5，最终输出为{B, C, D, E}并包含 λ= 4，提供由 F3表示的所有配置文件。

为了获得满足 ϕ的最佳 l过滤器，我们首先需要知道表示 l过滤器的最小匹配值。因此，我们首先选择任意ti。如果找到的解少于 l个，则降低 ti（ti−1）；如果找到的解多于 l个，则增加 ti（ti+1）。当找到满足μ（Fgx ,Fr）的 l过滤器且对应 x= 1,…, l时，搜索停止。

在给定最优 t i 的情况下，我们查询相关的 k配置文件，其中 μ(Pg , P r) ≥ t i 。这假设已知 L 中所有过滤器之间的匹配度量，以及最终由过滤器表示的所有配置文件之间的匹配度量。

如示例1所示，过滤器之间的匹配度量定义了一个如图1(c)所示的矩阵。理论上，配置文件之间的匹配度量也应如此。然而，我们专注于过滤器，以实现更快且更高效的Top‐k匹配查询用于基于过滤器的配置文件匹配

由于假设过滤器的数量小于配置文件的数量（l ≤ k），因此可以高效搜索配置文件。

定义2. 矩阵 M 是 F 中过滤器之间匹配度量 μφ 的结构，其中列代表必需过滤器Fr，行代表给定过滤器 Fg。

获取 k中的解决方案涉及参考某一列或某一行。该过程类似，但视角不同。从列中读取度量提供所谓的适应度在配置文件之间 μ（Pg， Pr），而从行中读取的度量则是倒置的度量μ（Pr， Pg），称为过度合格。这一点应在示例2中加以强调，其中需求可能根据倒置度量进行第二次排序。

如果我们将重点放在列上，在查询特定的 Fr时，会存在Fgx(x= 1,…, l)，其中 μ(Fgx,Fr) ≥ ti。我们假设所有元素都根据 μ(Fgx,Fr)的 ≤关系按全序排列。其优势在于，当搜索任意给定的 l和 ti时，我们只需指向列中正确的元素，并在 μ的降序中搜索接下来连续的 l − 1个元素。若在行上进行搜索，则过程类似。

接下来，我们将解释如何组织配置文件。我们首先假设一个身份标签 ρi， 表示 M中的行数 i，以及 σi，表示 M中的列数 i，其中 i> 0。

定义3。 给定一个必需过滤器 Fr，对于 M 中表示 μ(Fgx,Fr) 的 σi 列中的每个元素 μi，都存在一条配置文件记录

(μi, n > i, n=i, n<i, next, prev,p)

描述匹配配置文件Pg，其中： n>i表示满足 μ(Pg, Pr)> μi的配置文件数量，n=i表示满足 μ(Pg, Pr)= μi的配置文件数量，n<i表示满足 μ(Pg, Pr)< μi的配置文件数量，next 是指向满足 μ(Fg(x+1) ,Fr) ≥ μi的下一个匹配值的引用，prev 是指向满足 μ(Fg(x− 1) ,Fr) ≤ μi的前一个匹配值的引用，p 是指向匹配 Fr的过滤器链表的引用。

当确定由过滤器表示的配置文件数量时，无需实际查询这些配置文件，数字n > i , n= i , n < i 具有重要意义，即对于给定的 μi，如果(n > i + n = i) ≥ k，我们就能获得所有所需的配置文件。

参考下一个 和前一个 使得通过跟踪这些参考来追踪下一个更大或更小的匹配值成为可能。每个配置文件记录还在一个列中额外包含一个指向相关配置文件的引用 p，这些配置文件按 μ的元素顺序组织在传递闭包结构中 σi，并按 ≤排序。

示例4。 图2展示了与F4（表示配置文件的过滤器 A）在示例3中的配置文件记录的表示。请注意，为了简化图形，此处仅显示了与 μ= 0.5的过滤器和配置文件的关系。

3.1 Top‐K配置文件匹配的实现

我们在第3节中描述的top‐k查询的实现方法基于一个关系数据库模式，用于存储与维护 L实例中的过滤器、配置文件和匹配度量。该关系模式由9个关系组成，但我们仅展示其中两个关系：ProfileRecords 和 MatchingProfiles，它们分别描述了如定义3中的配置文件记录以及匹配配置文件的链表。图3展示了表示示例3中涉及元素的关系示例。对于ProfileRecords中的每个RequiredFilter，都有一定数量的匹配度量，表示 M中每列 σi的元素数量。ProfileRecords中的属性NextID是指向该关系中另一元组（ID）的引用，用于定义适应度元素的 ≤关系。属性GreaterFitness、EqualFitness和LesserFitness分别表示来自配置文件记录的元素 n>i、 n=i、 n<i，如定义3所述。

(a) 关系 ProfileRecords

身份	必需过滤器	适应度	更大适应度	相等适应度	较小适应度	Next ID
1	F4	1	0	1	3	2
2	F4	0.63	1	1	2	3
3	F4	0.50	2	2	0	4
4	F4	0.13	4	0	0	null

(b) 关系 MatchingProfiles

身份	必需过滤器	必需配置文件	给定过滤器	给定配置文件	健身下一站 ID
1	F4	A	F4	B	1
2	F4	A	F2	C	0.63
3	F4	A	F3	D	0.5
4	F4	A	F3	E	0.5

相应地，对于 RequiredFilter(Fr) 在 ProfileRecords 中的每一个，都存在一定数量的 GivenFilters 在 MatchingProfiles 中满足 Fr 中的要求。该属性NextID 是对关系中定义 Fitness 元素 ≤ 关系的另一个元组（ID）的引用。请注意，null 值表示 GivenFilter 列表的结束。

3.2 查询前K个候选配置文件

格 L中的过滤器通过 L中概念的层次依赖来表示配置文件的属性。因此，对于 P中的每个必需配置文件 Pr ，都有一个必需过滤器 Fr ∈ L来表示该配置文件。然后，从我们的关系模式中检索所需过滤器的前‐k个候选配置文件，主要通过对关系ProfileRecords和MatchingProfiles进行查询来实现。

算法。Top‐k
输入：必需过滤器: Fr, 匹配配置文件数量: k, 匹配阈值: μ
输出：匹配配置文件: Pg1, …, Pgk, 度量: μ1, …, μk

开始
1 创建关系 Results=(给定配置文件, 适应度, NextID)
2 (适应度, 计数, NextID) := π(3,5,7)(σ (2=Fr,(ProfileRecords) )max(Fitness))
3 当 (计数 < k) 或 (适应度 ≥ μ) 时执行
4 Results ← π(5,6,7)(σ(6=fitness,(MatchingProfiles))2=Fr)
5 next := Results.NextID
6 当 (next 不为空) 时执行
7  Results ← π(5,6,7)(σ(2=Fr)(MatchingProfiles) ⨝ (1=3 Results))
8 结束循环
9 (适应度, 总数, NextID) := π(3,5,7)(σ(1=nextid)(4 Results ← π(5,6,7)(σ(6=fitness,)))
10 计数 := 计数+总数
11 结束循环
12 返回 (π1,2(Results))
结束

算法 Top‐k 返回一个有序列表，其中包含与给定过滤器匹配的 top‐k 个配置文件。我们使用关系代数符号，因此 σ、 π 和 ⨝ 分别是选择、投影 和 自然连接 操作符。数字下标用于表示关系属性。例如， π1(MatchingProfiles) 是关系 MatchingProfiles 的属性 ID 的投影。

该算法的输入包括：必需的过滤器 Fr、匹配配置文件的数量 k以及用于搜索的最小匹配值 μ。输出为： k个匹配配置文件 Pg1,…, Pgk 及其对应的匹配度量 μ1,…, μk。

通过 Fr，该算法获取Fitness值最大的元组，从ProfileRecords中（第2行），并沿NextID的引用继续访问（第9行），直到达到k个元组或满足 μ(Fg ,Fr) < ti（第3行）。然后，对于MatchingProfiles中的每个 Fg ，算法在配置文件的链表上进行查询（第6– 8行），并将结果追加到临时关系Results中（第7行）。注意，通过使用“适应度 ≥ μ”在第3行中，我们包含了 λ − k元素，如定义1所示。该算法通过返回 给定配置文件 和 适应度 在 结果的元组上的值来结束。

在 Fitness(ProfileRecords和MatchingProfiles) 元素上实现 B树索引以访问已排序的元素，以及在 RequiredFilter(ProfileRecords 和 MatchingProfiles) 上建立用于随机访问的索引，有望提升性能。通过计算 (n>i+ n=i) 来对给定所需配置文件记录的情况下并行处理匹配配置文件的搜索，是另一个改进方向。

请注意，第3.1节和3.2节未考虑过度资格问题。尽管如此，它已被视为与 Fitness所示类似的流程。此外，还考虑了几个简单的算法，用于更新配置文件变更，从而更新匹配值、配置文件链表，特别是配置文件记录中的元素 n>i, n=i, n<i。

4 结论

本文提出了一种算法来处理 top‐k 查询，其中我们在关系数据库之上使用传递闭包结构进行实现。识别配置文件中的缺失需求对于选择最佳候选人至关重要，但仍需进一步考虑。这意味着需要基于匹配度量对差距查询进行研究，这也是我们未来研究的重点。