招聘匹配中的检索很容易给人一种“看起来对了”的感觉：查询技能 FastAPI，结果段落里也出现 FastAPI。但这个命中究竟来自候选人的技能标签、项目经历，还是一段否定描述？它是否足以支撑某个岗位要求？仅看检索分数很难回答。

这篇文章把评估重点放在一条更窄、也更能复核的问题上：检索是否找到了能够支持或反驳某个岗位要求的证据。项目当前使用 SQLite 普通表和概念别名，在 Python 中进行词面与概念打分并返回 Top-K 片段；这里没有使用 FTS5 或向量索引。下文的评估集是建议的验证方法，不代表已经完成的准确率测试。

先定义“有用”，再看排名

检索评估前，需要先确定使用者要做什么。若目标是快速找到包含术语的文本，词面召回可能够用；若目标是核实候选人是否提供了岗位要求的证据，就还要检查证据类型、来源和语气。

我会把一个查询的相关性拆成几个标签，而不是只给文本一个总分：

  • 直接证据：候选人描述了完成相关任务的经历。
  • 术语或别名命中：文本提到目标技能或同义表达，但没有交代实际使用方式。
  • 相关背景：内容与要求相邻，可能帮助理解，但不足以确认能力。
  • 反向或否定信息：文本明确说明没有经验、没有使用，或只计划学习。
  • 没有支持材料：当前资料中找不到能够作出判断的片段。

这些标签不是候选人的能力等级。它们描述的是“当前资料对这个要求提供了什么证据”，避免把没有检索到误写为没有能力。

构造小而有区分度的样例

可以从虚构简历和虚构岗位构造一组小型样例。每个样例只改变一个关键因素，方便归因：

  1. 精确术语：要求 FastAPI，经历直接写出用 FastAPI 构建服务。
  2. 别名表达：要求 PostgreSQL，经历写 Postgres。
  3. 词面命中但证据薄弱：技能列表含 Kubernetes，没有项目细节。
  4. 否定表达：经历写“没有在生产环境使用 Redis”。
  5. 相关但不等价：要求向量检索，经历只描述关键词检索。
  6. 多段证据：技能标签和项目经历分别提到同一概念。
  7. 缺少证据：资料完全没有出现要求涉及的能力。

标注时记录要求、候选文本、预期证据标签、来源位置，以及是否应该追问。标注说明要在运行检索前写好，避免看到结果后再改答案。

用分层指标定位问题

样例集足够小，可以先人工逐条检查。对每个查询记录 Top-K 中是否出现了应有证据、证据排在第几位、是否把否定内容当成正向命中，以及解释是否保留原文来源。之后再汇总：

  • 召回：应当找到的支持或反向证据有没有出现在 Top-K。
  • 排序：直接证据是否排在弱相关片段之前。
  • 误命中：仅因技能词出现，就被解释成有相关工作经验的比例。
  • 来源保真：界面展示的证据能否回到原始经历或标签。
  • 缺口表达：无证据时是否明确显示“资料未提及”，而不是推断能力缺失。

如果数据量只有十几条，不适合宣称统计意义上的准确率。此时逐条错误分析比百分比更有解释力。每次改进后固定相同样例，比较新增别名减少了哪些漏召回、又带来了哪些误命中。

词面、概念与向量方法应按错误类型比较

词面匹配容易理解和复算，但对缩写、别名和表达变化敏感。概念词表可以覆盖常见别名，同时引入维护成本：一个别名可能并不适用于所有上下文。向量检索可能找到词面不同但语义相近的片段，也会把主题相近、证据不足的内容召回。

所以评估不应只比较一个总体分数，而应在同一组固定样例上分别观察：哪些问题是漏召回，哪些是错误排序，哪些是语气或来源解释错误。向量相似度不能代替证据判定，模型生成的解释也不能代替原文核对。

从评估结果回到产品边界

检索层负责提出候选片段，规则层负责应用明确的匹配条件，展示层负责说明证据来源和信息缺口。三者职责分开，才能定位错误。举例来说，正确片段没有进入 Top-K 是召回问题；片段进入了但规则给错权重，是评分问题；分数正确但界面写成能力结论，则是表达与产品边界问题。

当前项目没有经授权、脱敏并人工复核的真实简历评估集，也没有可以据此报告的实测指标。下一步若要评估真实效果，需要明确数据授权、去标识化、标注一致性和样本覆盖范围。小型虚构样例能帮助检查逻辑，却不能证明系统适用于真实招聘决策。

这套方法的价值不是给匹配系统贴上“准确”的标签，而是让每种错误都能被看见、分类和复查。只要结果仍然回到原文证据，使用者就能知道系统找到什么、没找到什么，以及哪些结论还需要人工核实。

参考

相关项目查看AI 招聘助手的实现与交互