GraphGists

能力管理：过滤和推荐引擎的问题。

puzzle

简介

此 GraphGist 模拟了一个**内部工作推荐引擎**，换句话说，就是一个能力管理系统。当组织需要在现有人员中快速找到合适的员工来完成一项任务或职位时，可以实施此系统，而该任务或职位突然空缺。这项任务可能很棘手，找到最适合该角色的员工可能很困难，尤其是在大型组织中[1]。为了克服这些问题，组织将寻求以下策略

  • 找到“理想员工”的任务分配给一个人。但是，空缺职位可能涉及一些技术技能，这个人无法单独评估。此外，无论谁进行选择，都不认识所有人，因此他的选择很可能存在偏差，因为一个人无法快速探索整个员工网络。

  • 为了克服偏差，一群人负责做出选择。但是，谁来选择选择者以及他们如何做到这一点？他们的决策过程可能（太）缓慢，并且必须在协商结束时提供一种方法来处理不同人员之间不一致的判断。

如果**组织持续跟踪其人员的活动、角色和绩效的相关记录**，则可以克服这些问题。但是，将信息保存在存储库中是不够的：与往常一样，必须组织信息并使其易于访问，才能使其具有意义。

此 GraphGist 演示了将**上述存储库存储在 Neo4j 图数据库中并在 Cypher 语言中查询它**是多么有用和简单。此外，还特别努力**建议定制此原型**。整个讨论演示了如何使用图数据库来解决此问题，从而优化了灵活性，以便不同的组织可以通过删除某些组件和改进其他组件来构建在相同的基本查询结构之上，并使此原型适应其需求。

讨论的结构在以下 TOC 中进行了总结。

目录

初始数据模型

此 GraphGist 示例在构建时考虑了某些功能，使其能够复制和改进大型组织现有能力管理工具的功能[2]。但是，保留了一些通用功能和模式，使此示例也能够用于表示在线通用推荐系统。在此模型中，原型足够灵活，可以集成来自组织内部存储库以及从在线社交网络收集的外部信息。

Figure 1
图 1. 初始数据模型

参见 Alistair Jones 的 arrow 工具。

从关注每个Employee在图 1中的单个“自我网络”[3]开始，此网络可视化显示了几个有趣的数据关系。关于公司内部数据，请注意

  • WORKS_AS 指向Employee的当前Role。此关系有两个属性：duration（Employee在该角色中花费的年数）和location（员工的工作地点）。第一个属性可用于推断员工在特定领域获得的专业知识水平，而第二个属性可用于了解是否应重新分配资源，以便在新的Role中工作。Role节点本身链接到一组Activity节点，并表示组织内部的特定职位。

  • WORKED_AS 与前一个关系非常相似，唯一的区别在于它还说明了Employee之前的[4]角色。

  • CAN_PERFORM 是关于Employee能力的几乎二元陈述：如果员工已成功执行过特定活动，则链接属性为bin_threshold=1；如果假设Employee能够执行该活动但从未尝试过，则在图中将其设置为bin_threshold=-1；最后，如果已知Employee无法执行相关活动，则属性bin_threshold=0。

  • IN_TEAM 指示员工是否属于或曾经属于某个团队，其中员工参与的当前状态嵌入在链接属性current中（如果员工不再是团队的活跃成员，则为 0）

员工的个人信息可以来自专业社交网络中的Employee个人资料、基于组织内部用户画像活动的相关数据，或整合这两个数据源

  • HAS_DEGREE 突出显示员工的Degree（以授予学位的机构、学习科目/领域和最终成绩为特征）。这种关联可能非常重要，尤其对于知识型员工或新手而言。

  • HAS_SKILL 表示Employee 拥有特定的技能。现在，此技能的掌握程度未嵌入链接中（这可能暗示对技能的自我评估），而是可以从其他同事的认可中推导出。

  • ENDORSES 表示员工可以为同事评分的可能性。这些分数（1<level<4）不是通用的——它们指的是特定的Personal Skill，因为同事可能自信地评估一项特定技能，但另一项则不然。

Figure 2
图 2. 组织图中活动和角色的网络

上图展示了组织图中活动和角色的网络。每个Role节点都具有几个属性

  • dept 指示该角色属于哪个部门

  • hierarchy 是员工和经理角色之间的基本区分——在需要时，可以分配更复杂的结构

  • open_status 是一个二进制值，用于标记：“1”表示职位空缺，“0”表示职位已满）。

Activity 节点被分配了一个complexity（其中 1<`complexity`<5），该索引衡量特定Activity 的难度，同时考虑了所需的专业技术以及与其他同事、顾问、客户等的社交互动水平。

Role 节点可以通过RELATED_ACTIVITY 链接链接到一个或多个Activity 节点。此连接通过属性 level_weight（也处于离散尺度 1→4）进行丰富，表明Role 需要一定程度的对应RELATED_ACTIVITY 掌握，以便员工以令人满意的方式执行。经理Role 也可能通过SUPERVISES_ACTIVITY 链接连接：在这种情况下，可能会期望员工能够很好地指导活动，但不一定需要直接执行活动。

最后，每个Activity 可以通过IN_AREA 链接连接到唯一的Competence Area 节点（即，在此模型中，不允许不同能力领域之间重叠，但此假设显然可以放宽）。Competency Areas 应理解为组织执行的不同Activitie 的高级分类。

设置图 TOC

以下是使用 Cypher 生成模型的命令集。

整个图看起来像

MATCH (n) RETURN n

筛选不合格的候选人 TOC

从搜索中排除一些员工是需要完成的首要任务。此要求可能源于常识性推理、内部规章制度或人力资源部门提出的请求。此外，它将最大程度地减少后续查询中需要遍历的节点和链接的数量，从而提高性能。

频繁更换职位或晋升最近入职的员工通常不是期望的结果。因此，第一个查询将搜索刚刚加入组织或最近开始新职位的员工，并将这些候选人从潜在候选人池中过滤掉。为了跟踪不合格的候选人，在图中这些员工节点中设置了一个额外的属性exclude。这里，属性是二进制的：“exclude=1”表示该人已被淘汰，至少目前是这样。添加exclude 属性的 Cypher 查询将是

MATCH (n:Employee)
SET n.exclude=1
WITH n AS person
MATCH (person)-[r:WORKS_AS]-()
WHERE r.duration>1
SET person.exclude=0
RETURN person.name AS `Matching Candidate`

结果表仅填充满足在组织工作一年以上的初步条件的候选人。

推荐求职候选人的另一个筛选条件是需要一定的学位。这对于公开招聘广告非常常见，但对于内部晋升也可能是一项基本要求。因此，要排除那些没有持有此类学位的候选人，查询

MATCH (n:Employee {exclude:0})
WHERE NOT (n)-[:HAS_DEGREE]-(:Degree {area:"area 1"})
SET n.exclude=1

这些筛选条件可以使用其他数据库管理系统轻松实现。例如，可以在 SQL 中使用WHERE 查询，将degree 和duration 属性都设置为员工最后担任职位的列值。简单的电子表格能够执行这些操作。

但是，至关重要的是，仅选择那些拥有特定能力领域内活动所需技能的候选人。因此，**不要通过节点属性进行筛选，而是通过它们的链接或数据关系进行筛选**。此外，还必须将搜索扩展到技能、活动和领域之间 3 度（甚至更远）的连接。换句话说，我们正在寻找潜在候选人如何与能力领域相关联，深度为 3。SQL 数据库将需要执行更多JOIN 操作才能提供答案——这是一个难以编码且创建耗时查询的任务。随着查询连接深度的扩展，这种搜索对于 RDBMS 来说将变得越来越困难，并导致性能极差。

为了更量化，假设组织具有以下属性

  • 10,000 名当前员工

  • 每个员工平均拥有 1 个学位和 13 种不同的个人技能

  • 每个团队由 5 人组成，平均活跃 1 年

  • 活动是分配给团队的单一任务 [[5]]，每天分配 1 个。

经过 1 年的运营，这些参数将导致大约 100 万个节点的图。对于这种规模的图，遍历深度为 3 的路径的查询需要 RDBMS 执行 30 多秒，但使用 Neo4j 仅需不到 0.2 秒[6]。当查询数据库是在线工具的一部分时，这种差异可能至关重要。例如，钻取过程的最佳内部使用应避免过滤掉太多候选人（以便组织中没有人匹配所需的特征）。如果对预筛选网络查询与能力区域相关的候选人（深度为 3），则筛选将返回零个匹配迄今为止所有要求的候选人

MATCH (n:Employee {exclude:0})
WHERE (n)-[:HAS_SKILL]-(:Personal_Skill)<-[:REQUIRES]-(:Activity)-[:IN_AREA]->(:Competence_area {name:'Competence Area 2'})
SET n.exclude=1
RETURN DISTINCT count(n) AS Candidates

组织（尤其是他们的 HR 部门）将需要能够与同事共享其候选人画像。这需要通过在线工具处理钻取，以便可以实时更新和评估对画像的任何修改，以应对可用人员的情况。有了这个特定目标，我们可以简化查询为

MATCH (n:Employee)-[:HAS_DEGREE]-(:Degree {area:"area 1"})
WHERE (n)-[:HAS_SKILL]-(:Personal_Skill)<-[:REQUIRES]-(:Activity)-[:IN_AREA]->(:Competence_area {name:'Competence Area 2'})
WITH n AS person
MATCH (person)-[r:WORKS_AS]-()
WHERE r.duration>1
RETURN person.name AS `Matching Candidate`

此查询导致空表，这立即突出了排除一些模式匹配要求的必要性。作为 Cypher 查询编写，这可能看起来微不足道：拥有很少编码知识的人员可以轻松地接受培训来更新此类查询，以便尝试不同的要求组合。相反，由于查询时间过长，**不建议将完全相同的查询实现为 RDBMS 支持的在线系统**。

候选人排名：一种“社交”方法 TOC

在上一段中，有一系列查询可以轻松排除候选人，并且已经证明了一些请求的组合可能过于严格。再次考虑我们的示例，现在有趣的是查看一些根据不同方法对可用候选人进行排名的选项。现在需要对可用候选人进行排名，为此，有必要放宽关于个人技能的最终条件[7]。实现此目的的两种选择是协作排名和基于内容的过滤。

能力管理的协作排名

为了对最佳候选人进行排名，第一种方法是组建一个招聘委员会，其中包括可能在团队中与候选人一起工作或将与候选人一起工作的员工。为了证明协作排名的优势，假设提供空缺职位的团队（团队 3）目前仅由一名员工组成。

MATCH (n:Employee)-[:IN_TEAM]-(m:Team {name:'Team 3'})
RETURN n.name AS `Team Member`

这说明了引言中概述的偏差问题 ^(go to)^：在选择理想候选人时，我们必须整合团队中已经工作的员工（员工 5）的知识，以及空缺职位。在这种情况下，一种直观有效的解决方案是依赖于诸如以下的数据关系

(Employee A)-[:Endorses {level:x}]-(Personal_Skill a)-[:HAS]-(Employee B)

其中属性 level x 是员工 A 对员工 B 评估的Personal Skill 的评分。这种 Cypher 查询提供了对同事眼中候选人技能的理解。

为了使此分析量化，将引入一个员工之间差异或相似性的指标，以了解哪些员工对同事有相似的看法。使用此指标，可以查询特定群体中谁最适合空缺职位的排名，即使该群体中的人员不直接认识候选人。然后，该方法与**基于用户的推荐系统**非常相似，这是一种基本的协作过滤技术。为了关联量化距离指标，一个简单的解决方案是应用余弦相似度（此方法在尼科尔·怀特撰写的GraphGist 中有详细解释）。基本概念是，特定团队成员的同事，如果以类似的方式评估了其他员工，则很可能成为加入招聘委员会的合适人选。因此，委员会扩展到不是团队成员但仍然适合团队招聘委员会的员工。

余弦相似度排名也可以作为推荐分析的基础。但是，重要的是要记住，在我们的数据模型中，员工认可的是个人技能，而不是其他员工。因此，必须包含员工 A 和 B 之间的附加定向关系（[:RATES {rating: …​}]），其中

\( rating_{ A \to B }= \frac{ \sum_{ i=1 }^{ N } \textrm{ level }(\textrm{ Personal Skill }(i))} {N} \)

其中 \(N:= \textrm{# endorsed Personal_Skills of B, by A }\)，属性rating 是 A 对 B 的单个个人技能进行的认可级别的平均值。

MATCH (u1:Employee)-[x:ENDORSES]->(:Personal_Skill)<-[:HAS_SKILL]-(u2:Employee)
WITH  AVG(x.level) AS rating_score,
      u1, u2
CREATE UNIQUE (u1)-[:RATES {rating:rating_score}]->(u2)

这些初步计算提供了计算员工 5 的余弦相似度的能力。但是，添加一个额外的步骤可能有助于表达更通用的查询。查询还应该能够处理团队 3 由不止一名成员组成的案例。在这种情况下，所需的方法是计算一个平均组评分向量，用于每个不在组中但至少被一个组成员评估过的员工。此平均分数标记为team_rating，并设置为从团队到被评估的Employee 的数据关系上的属性。

MATCH (u1:Employee)-[x:RATES]->(u2:Employee)
WHERE (u1)-[:IN_TEAM]-(:Team {name:'Team 3'}) AND NOT (u2)-[:IN_TEAM]-(:Team {name:'Team 3'})
WITH  AVG(x.rating) AS team_score,
      u2
MATCH (t:Team {name:'Team 3'})
CREATE UNIQUE (t)-[:RATES {team_rating:team_score}]->(u2)

包含[:ENDORSES] 和[:RATES] 数据关系的图的一部分可以使用以下方法可视化

MATCH (t:Team)--(u:Employee)
OPTIONAL MATCH (u)-[:ENDORSES]-(p:Personal_Skill)
RETURN t,u,p

计算出组评分后，现在可以引入团队 3 与其他不是团队 3 成员的员工的整体相似性。相似性的工作方式与针对单个员工计算时相同。请注意，为了检索共同评分，至关重要的是要根据数据关系的类型对 2 阶连接执行 MATCH 子句并进行显式筛选。使用图数据库，这很简单，因为数据关系本身就是对象。

MATCH (t:Team {name:'Team 3'})-[x:RATES]->(:Employee)<-[y:RATES]-(u2:Employee)
WHERE not (u2)-[:IN_TEAM]-(t)
WITH  SUM(x.team_rating * y.rating) AS xyDotProduct,
      SQRT(REDUCE(xDot = 0.0, a IN COLLECT(x.team_rating) | xDot + a^2)) AS xLength,
      SQRT(REDUCE(yDot = 0.0, b IN COLLECT(y.rating) | yDot + b^2)) AS yLength,
      t, u2
MERGE (t)<-[s:SIMILARITY]-(u2)
SET   s.similarity = xyDotProduct / (xLength * yLength)

为了也考虑团队成员的直接推荐，将s.similarity=2 设置为团队 3 成员与团队本身的相似性。对于图中的所有其他员工，similarity<1，因此优先考虑团队成员的评估而不是其他评估很简单。

MATCH (t:Team {name:'Team 3'})-[x:IN_TEAM]-(u1:Employee)
MERGE (t)<-[s:SIMILARITY]-(u1)
SET   s.similarity = 2.0

一旦了解了团队 3 与所有其他员工之间的相似性[8]，就可以对哪些员工可能是空缺职位的理想人选做出初步推荐。

对于此初始分数的计算，假设团队 3 之外的所有同事在评估其他同事的技能方面能力相同。从算法上讲，这意味着那些直接被员工 5 评估过的人不会获得额外的权重或分数。为了限制要考虑的评分数量，可以根据提供这些评分的员工的相似性来限制评分。采用k最近邻[9](k-NN)算法将允许查询仅选择k个最相似同事的评估。如何选择k？一个简单的选择是将一个小型团队视为在其评估下一个成员方面胜任，至少与组织中的平均团队一样胜任。如果团队规模超过平均水平，则可以选择团队成员所做的所有评估。在本例[10]中，k=5，**包括**员工 5，假设他至少评估了一些候选人。

一旦选择了k的值，下一步就是查询图模型以获取k-NN员工，然后将他们的评估平均作为特定员工在有空缺职位的团队中可能表现如何的可能估计。如前所述，将首先考虑团队内部员工的评估。

MATCH (b:Employee)-[r:RATES]->(m:Employee), (b)-[s:SIMILARITY]-(t:Team {name:'Team 3'})
WITH     m, s.similarity AS similarity, r.rating AS rating
ORDER BY m.name, similarity DESC
WITH     m.name AS candidate, COLLECT(rating)[0..5] AS ratings
WITH     candidate, REDUCE(s = 0, i IN ratings | s + i)*1.0 / LENGTH(ratings) AS reco
ORDER BY reco DESC
RETURN   candidate AS Candidate, toFloat(reco) AS Recommendation

此查询会产生将空缺职位分配给现有员工的第一个建议。请注意，即使团队 3 中没有人直接认识员工 1，员工 1 获得的推荐甚至高于员工 3 获得的推荐。团队 3 唯一直接认识的人是员工 3，如果没有推荐系统，这将是唯一可能的选择。使用图模型，现在组织可以探索其整个员工网络中的候选人，并消除源于招聘委员会规模较小的偏差。

在本节中，最重要的是数据模型本身所组成网络和数据关系，而不是单个成员的属性和特征。此方法（目前）不考虑空缺职位所在的胜任能力领域。使用图数据模型的优势在于，即使在几乎不了解单个员工的活动和专业领域的情况下，该方法也能够根据相互评分连接进行排名。

改进排名：基于路径的加权 TOC

但是，本例中的图数据模型可以提供更多见解。可以使用其他标准来改进候选人排名。最直观的做法是根据员工图的社交数据关系，为建议引入**基于内容的**加权。事实上，开始时纯粹是“社交”协同过滤，其中没有考虑评估员工的专业知识。当没有关于空缺职位所需或期望的技能和经验的信息时，这种方法是可以的。但是，现在可以使用表征理想候选人和有空缺职位的团队的其他特征，通过各种方法进一步改进排名。

强调胜任能力领域节点而不是员工节点的作用，例如，可以根据特定员工在组织图中与空缺职位相关的胜任能力领域的距离来对候选人的推荐分数进行加权。权重将基于路径（员工）--(胜任能力领域)的长度。考虑到职位 6 的空缺职位，我们知道：(职位 6)-[:RELATED_ACTIVITY]-(活动 6)-[:IN_AREA]-(胜任能力领域 2)，改进后的推荐查询如下所示

MATCH (b:Employee)-[r:RATES]->(m:Employee), (b)-[s:SIMILARITY]-(t:Team {name:'Team 3'}), p=shortestPath ( (n1:Competence_area {name:"Competence Area 2"})-[*..5]-(b) )
WITH m.name AS candidate, s.similarity AS similarity, r.rating AS rating, p
ORDER BY candidate, similarity DESC
WITH candidate, COLLECT(rating*1.0/(length(p)-1))[0..5] AS ratings
WITH candidate, REDUCE(s = 0.0, i IN ratings | s + i)*1.0 / LENGTH(ratings) AS reco
ORDER BY reco DESC
RETURN candidate AS Candidate, toFloat(reco) AS Recommendation

受shortestPath约束，可以

  • 将评分限制为仅那些距离胜任能力节点不超过 5 跳的员工（在shortestPath MATCH子句中指定[*..5]长度，不满足此要求的员工将从进一步评估中移除）

  • 对于所有满足条件的人，查询会将其评分加权为与其距离（表示为最短可用路径[11]））从感兴趣的胜任能力领域成反比。

在计算候选人评分的权重时，减去1，因为在本GraphGist中，无论哪个员工到胜任能力领域的可能的最短路径长度恰好为2：((员工)-[:CAN_PERFORM]-(活动)-[:IN_AREA]-(胜任能力领域))。来自最大程度缩短此主题距离的员工的评分不受影响。在本例中，上述纯粹的协作排名得到了进一步确认，甚至优先考虑了更熟悉空缺职位所涉及的胜任能力领域的员工所做的评估。员工 1 仍然被计算为最佳选择，即使他现在相对于其他同事的优势较小。

改进排名：Jaccard相似度 TOC

另一种可能的改进策略依赖于所谓的“Jaccard相似系数”。第一段中使用的余弦相似度确实源自该指数，该指数广泛用于社会和经济科学中以评估两个样本的多样性或相似性。在这里，可以使用最简单的情况：事实上，我们可以将与所需特征的匹配的存在/不存在视为二进制值，说明特征是否属于样本。另一种改进策略将使用Jaccard相似系数。在本GraphGist中前面使用的余弦相似度源自该指数，该指数广泛用于学术界评估两个样本的多样性或相似性。在这里，它用于最简单的情况：主题特征用于构建样本，二进制值说明特征是否属于样本。这构建了两种集合

  • T（对于团队 3）

  • Ei（每个第 i 个员工的评估将被使用）

T中包含所有候选人评估所需标准，例如特定胜任能力领域中拥有的个人技能、与其自身角色相关的或执行的活动、感兴趣的胜任能力领域的学位。这些累积地表征了团队 3 中已有的所有员工集合。T中包含的标准将与第i个员工拥有的标准进行匹配，并且仅当某个路径将标准与该员工连接时，才会在集合Ei中进行过滤。

检索到这两个集合后，可以使用Jaccard公式计算系数J，如下所示

\( J = \frac{|T \; \cap \; E_i |}{|T|} \)

（请记住，根据定义，\(T \cup E_i = T\)[12]。

现在，已经介绍了此改进查询的所有元素。首先为所有值得包含在候选人评估中的节点设置二进制属性pool。为了改进结果，采用与上述相同的标准进行此初步选择：最多5个最近邻员工，即在评估其他同事方面与团队 3 余弦相似度最高的员工。

MATCH (b)-[s:SIMILARITY]-(t:Team {name:'Team 3'})
WITH DISTINCT b, s.similarity AS similarity
ORDER BY similarity DESC LIMIT 5
SET b.pool=1

接下来设置属性t_feature以标记代表所选团队特征的节点。例如，可以包含通过个人技能和活动与团队中的员工关联的胜任能力领域、特定领域（或领域）的学位以及执行特定活动的的能力。

MATCH (u1)-[:IN_TEAM]-(:Team {name:'Team 3'})
WITH u1
OPTIONAL MATCH (u1)-[:HAS_SKILL]-(:Personal_Skill)-[:REQUIRES]-(:Activity)-[:IN_AREA]-(c1:Competence_area)
OPTIONAL MATCH (u1)-[:CAN_PERFORM]-(:Activity)-[:IN_AREA]-(c2:Competence_area)
OPTIONAL MATCH (u1)-[:HAS_DEGREE]->(d:Degree)
   WHERE d.area="area 1" OR d.area="area 2"
OPTIONAL MATCH (u1)-[:CAN_PERFORM]-(a1:Activity)
OPTIONAL MATCH (u1)--(:Role)--(a2:Activity)
SET c1.t_feature=1, c2.t_feature=1, d.t_feature=1, a1.t_feature=1, a2.t_feature=1;

现在，要计算Jaccard系数，请评估每个参与评估的员工拥有多少团队特征。这可以通过查询集合T中的节点来完成

MATCH (feats {t_feature:1})
WITH count(distinct feats) AS T_size
MATCH (u2 {pool:1})
WITH u2, T_size
OPTIONAL MATCH (u2)-[:HAS_SKILL]-(:Personal_Skill)-[:REQUIRES]-(:Activity)-[:IN_AREA]-(c3:Competence_area {t_feature:1})
OPTIONAL MATCH (u2)-[:CAN_PERFORM]-(:Activity)-[:IN_AREA]-(c4:Competence_area {t_feature:1})
OPTIONAL MATCH (u2)-[:HAS_DEGREE]->(d2:Degree)
   WHERE d2.area="area 1" OR d2.area="area 2"
OPTIONAL MATCH (u2)-[:CAN_PERFORM]-(a3:Activity {t_feature:1})
OPTIONAL MATCH (u2)--(:Role)--(a4:Activity {t_feature:1})
WITH u2, count(distinct d2) AS counter, [a3,a4] AS activity, [c3,c4] AS competence, T_size
UNWIND activity AS activities
UNWIND competence AS competences
WITH u2, (counter+count(distinct activities)+count(distinct competences))*1.0/T_size AS jaccard
SET u2.jaccard=toFloat(jaccard)

最后一步是使用Jaccard系数作为权重：这可以通过与基于路径的改进非常相似的查询来完成。在这里，额外的WHERE子句过滤了无法提供Jaccard系数的员工的评估。

MATCH (b:Employee)-[r:RATES]->(m:Employee), (b)-[s:SIMILARITY]-(t:Team {name:'Team 3'})
WHERE b.jaccard>0
WITH m.name AS candidate, s.similarity AS similarity, b.jaccard AS jaccard, r.rating AS rating
ORDER BY candidate, similarity DESC
WITH candidate, COLLECT(rating*jaccard*1.0)[0..5] AS ratings
WITH candidate, REDUCE(s = 0.0, i IN ratings | s + i)*1.0 / LENGTH(ratings) AS reco
ORDER BY reco DESC
RETURN candidate AS Candidate, toFloat(reco) AS Recommendation

查看结果，员工 3 的排名现在略有提高，考虑了与同一胜任能力领域相关的学位或个人技能等标准。请注意，这挑战了员工 1 作为最佳选择的先前排名。

在本例中，最短路径和Jaccard距离仅作为改进k-NN和余弦相似度建议的指标。但是，当处理冷启动问题时，这些基于既定标准的指标也可以替代基于协同过滤的建议。当组织或评估组成立时间过短，无法提供足够数量的其他同事的不同活动的评估时，就会发生这种情况。这可能会阻止成功采用上述相似性。但是，如果组织持续更新并详细记录其员工的资料，则可以将基于特征的相似性用于（少量）评估的排名，并帮助解决问题。

超越工作推荐：胜任力管理工具 TOC

在本GraphgGist中，主要目标是处理内部招聘的情况，通过根据当前员工与新职位和相关团队的兼容性对他们进行排名。但是，组织可能还需要执行其他与胜任力管理相关的任务。这在以下活动中可能很有用：评估员工在职位中的绩效、评估团队是否具备所有可用胜任力、改进培训课程的组织。通过了解前面介绍的胜任力管理代数模型的细节，可以发现图数据模型的其他优势。

原始图数据模型非常适合之前的任务，但在关注胜任力管理时，有必要引入通用技能节点，这些节点以前作为个人技能节点上的属性嵌入。个人技能由单个员工拥有，但需要根据特定的技能组合导航和遍历图，而无需处理重复项（组织中可能有几个员工拥有相同的技能组合）。在RDBMS中，此简单修改将很麻烦，因为需要查询整个数据库以检索个人技能节点的数据关系，然后将其中一些连接重新分配到新添加的技能节点。在图数据模型中，此更新可以使用很少几行Cypher表示并快速执行

MATCH (a:Activity)-[rel:REQUIRES]-(ps:Personal_Skill)
MERGE (s:Skill {name:ps.set})
MERGE (a)-[:REQUIRES]->(s)<-[:IN_SKILLSET]-(ps)
DELETE rel
REMOVE ps.set;

在新模型中，活动可能[:REQUIRES]通用技能，并且员工的各种个人技能可能或可能不[:IN_SKILLSET]。请注意，此查询很容易将属性更新为个人技能的链接分类。如何计算员工执行特定活动的胜任力？首先，针对活动所需的技能查询图。然后，对于每项技能，评估员工是否拥有相应的技能集中存在的个人技能——如果没有，则分配空分数。如果此个人技能也得到了其他同事的认可，则其级别的平均值将是员工胜任力级别的分数。否则，此分数将为空。以员工 1 和活动 1 为例，此Cypher查询如下所示

MATCH (a:Activity {name:"Activity 1"})-[:REQUIRES]->(s:Skill)
WITH a, count(s) AS skill_req
MATCH (a)-[:REQUIRES]-(r:Skill)-[:IN_SKILLSET]-(p:Personal_Skill)-[:HAS_SKILL]-(u:Employee {name:"Employee 1"})
OPTIONAL MATCH (:Employee)-[x:ENDORSES]->(p)<-[:HAS_SKILL]-(u)
WITH a, u, p.name AS personal_skill, toFloat(AVG(x.level)*1.0) AS rating, skill_req
WITH a, u, REDUCE(a=0.0, b IN COLLECT(rating)|a+b)*1.0/skill_req AS comp_level
MERGE (u)-[r:CAN_PERFORM]-(a)
  ON CREATE SET
    r.comp_level=comp_level,
    r.bin_threshold=(-1)
  ON MATCH SET r.comp_level=comp_level

请注意，员工(k)关于某个活动(i)的能力等级计算如何更新了图中的[:CAN_PERFORM]链接。这种基于技能的评估代表了员工[13]执行特定活动的能力以及胜任程度。为了评估员工在某个角色\(R_j\)（涉及活动集\(A(R_j)\)）方面的胜任能力，可以使用三个参数：新计算的能力等级（\(l_{ik}\)）、每个活动的复杂度（\(K_i\)）以及主管作为参考的因素[14]。此模型中嵌入了对活动集\(A(R_j)\)中每个活动(i)所需最大能力等级的评估，方法是通过[:RELATED_ACTIVITY]数据关系的属性level_weight（\(v_{ij}\)）。可以假设由条件hierarchy:"manager"标识的主管角色与每个所需活动的level_weight匹配。因此，主管角色索引为

\( SupR_j = \sum_{ i \in A(R_j)} K_i v_{ ij}\)

等效地，员工(k)`在员工级角色(j)的角色索引将为

\( R_k = \sum_{i \in A(R_j)} K_i \tilde{l}_{ik}\)

其中\(\tilde{l}_{ik}=min(l_{ik},v_{ij})\)。最后，可以将员工(k)对角色(j)的态度衡量为比率

\( LR_{kj} = \frac{R_k}{SupR_j} \)

现在，使用Neo4j图中的Cypher查询重现这些计算

MATCH(r:Role {name:"Role 1"})-[l:RELATED_ACTIVITY]->(a:Activity)
WITH a, l.level_weight AS v_param, toFloat(l.level_weight*a.complexity*1.0) AS sup_param
MATCH (u:Employee {name:"Employee 1"})-[x:CAN_PERFORM]->(a)
WITH u.name AS Employee, a, sup_param,
  CASE
    WHEN toFloat(x.comp_level)>toFloat(v_param) THEN v_param*a.complexity*1.0
    ELSE x.comp_level*a.complexity*1.0
  END AS role_param
WITH Employee, REDUCE(a=0.0, b IN COLLECT(role_param)|a+b)*1.0 AS role_index, reduce(a=0.0, b IN COLLECT(sup_param)|a+b)*1.0 AS sup_index
RETURN Employee, toFloat(role_index/sup_index) AS `Competency Ratio`

鉴于能力比率受主管角色专业知识阈值的约束，其范围在[0,1]之间。接近0的值表示不应考虑该员工担任该角色，而接近1的值则表明该员工有可能被提升为主管角色以执行这些活动。通过删除上述查询第3行中对单个员工的指定，可以使用相同的查询直接搜索[15]具有特定角色最佳能力的员工。

最后，可以编写一个非常简单的查询，该查询还突出显示与他们监督的活动预期专业知识水平相比，评分不足的主管

MATCH (u:Employee)-[:WORKS_AS]->(:Role)-[s:SUPERVISES_ACTIVITY]-(a)
OPTIONAL MATCH (u)-[t:CAN_PERFORM]-(a)
WHERE toFloat(t.comp_level)<s.level_weight
RETURN u.name AS `Flagged Manager`

根据我们的图数据模型，查询突出显示的主管可能需要进一步培训，或让同事认可他们的能力[16]。

结论

此GraphGist的范围是通过示例解决并解释以下几点

  1. 员工、他们的活动和能力的网络可以轻松地以图数据库的形式建模，从而使跨网络编写查询变得简单直观；

  2. 与查询RDBMS相比，可以通过图数据库更快、更有效地提取一些信息；

  3. 图数据库查询可能会提高对选择模型公式中隐藏问题的认识。数据库或查询可以实时更正，而其他数据库可能是单一的，并且在执行修改和更新时会带来严重的性能问题。

首先，演示了图数据模型如何完美地适合表示组织的内部结构。节点可以分配给员工、角色、活动和能力领域。数据关系及其属性可用于指示某个职位已担任多长时间、员工已执行哪些活动以及同事或主管如何评估员工。在从该图开始对工作推荐系统进行建模时，还包括了制造公司能力管理代数模型中的元素。

根据空缺职位的要求筛选和排名候选人是极大地受益于复杂遍历查询的任务。这些查询搜索的深度可以远远超出图中节点的最近邻居。在此GraphGist中，遍历查询用于

  • 筛选一些员工

  • 计算评估其他同事的员工（或团队和员工之间）的相似性

  • 推断员工与某个能力领域的“接近程度”，因此推断他与之相关的自身能力

  • 推断员工之间的基于特征的相似性（或将单个员工与整个团队进行比较）

所有这些查询对于成功构建能够根据员工能力分配或重新分配内部人力资源的内部工作推荐系统至关重要。此GraphGist的意图并非提供所有可能在该系统中发挥作用的推荐机制[17]）的全面回顾，而是概述一些可用于提供必要推荐的方法的实现。在我们的示例中，员工“1”和“3”的排名不同，这基于不同标准的优先级以及使用的特定推荐方法。

将组织网络表示为图数据模型使根据每个内部工作搜索的特定需求更容易、更快地探索和导航。查询图数据库——将空缺职位与拥有正确能力的员工进行匹配或提供更好的团队集成——通常需要高度复杂的遍历查询。在关系数据库解决方案中实现此推荐工具将需要大量额外的编码，查询性能较慢，并且更新数据模型的难度增加。使用Neo4j，内部推荐工具提供了更快的查询响应，并具有适应数据模型实时更改的灵活性。

1。如果组织发展到几乎任何人都无法亲自认识其他所有人的程度，我们就可以将其视为“大型”组织。这种情况使内部搜索更接近于从外部社交网络招聘员工，这种情况已在其他GraphGist中处理过。
2。在此GraphGist中，我们主要指的是“优化能力管理系统：代数方法”中概述的代数方法，Fortunato 等人，在国际协作企业研讨会：CENT 2011上发表。这种方法以及可以根据其假设构建的图被航空制造公司Alenia Aermacchi spa采用
3。意指包含该节点的所有且仅包含一级连接的网络。
4。图数据库提供了一种非常直观且易于查询的方式来搜索员工的整个职业生涯路径，使每个职位都指向之前的职位。在这里，为了使我们的模型易于理解，我们没有充分利用此功能。感兴趣的读者可以参考“图数据库”，O’Reilly，2013，第 71 页及以下
5。实际上，任务更容易跟踪，因为这可以通过收集日志文件和团队成员以及主管的即时审查来实现自动化。
6。“图数据库”的估计，O’Reilly，2013
7。例如，每当新角色中的员工可能逐渐从其他同事那里学习新技能，或者某些其他的人际素质可能发挥更重要的作用等时，这都是合理的。
8。仅与那些至少曾经共同评价过某个员工的同事计算相似性，也就是说，他们都共同认可了他的某些技能
9。电影推荐GraphGist中也详细解释了此算法
10。5 人的平均小组规模是此 GraphGist 中对组织做出的假设之一。但是，这也可以从图数据库中轻松计算出来。
11。这种方法类似于距离加权范围，该范围已广泛应用于关于协作网络的研究中，例如参见 Shilling & Phelp，2007
12。有人可能会反对从整个组中收集特征并将它们与单个员工进行比较可能会导致系数低估的问题。但是，再次注意，系数将用于对应用程序进行排名，而不是作为其自身的度量：因此，重新缩放或其他规范化程序当然是可以的，但它们不会改变我们的结论，因此在此处跳过
13。事实上，我们设置了bin_threshold=-1以指示这不是基于实际观察的评估，而是根据其能力及其与相应活动的匹配程度进行的评估
14。再次参考该模型，将能力等级表示为与组织监督活动所需的等级相比的比率非常有用：声明员工在执行活动方面的能力优于组织对该活动所需的最大能力是无用且误导性的信息
15。迄今为止概述的代数能力模型的完整正式实现需要旨在正确进行数据分析的工具。实际上，感兴趣的读者可能希望探索RNeo4j插件。然而，Cypher查询已经可以处理从组织数据库中提取有用信息的最重要功能。
16。实际上，查询将返回既没有与相应活动的:CAN_PERFORM链接的员工，也没有迄今为止对其个人技能进行:ENDORSES的员工
17。确实存在一个完全独立的推荐方法库，该库建立在Neo4j之上：Reco4j，更多信息链接::https://neo4j.ac.cn/news/using-neo4j-and-reco4j-for-graph-based-recommendations/[此处