招聘匹配中的检索、规则与模型增强

招聘初筛需要回答三个问题：岗位要求什么，候选人的哪段经历支持这项要求，还有哪些信息需要追问。一个分数可以帮助浏览，但只有把分数连接到证据，结果才方便复核。

这个招聘助手把工作分成三层：本地岗位知识检索找到相关要求，规则引擎形成可解释的匹配结果，外部模型在显式启用时补充语言表达与语义审阅。核心评估可以在本机完成。

问题：技术名词出现了，是否就算满足要求

岗位描述会混合标准术语、缩写、别名和项目经验要求。只判断字符串是否出现，难以区分直接命中、别名和相关概念。候选人写过某个工具，也不等于已经证明能够独立完成相关工作。

因此，结果需要同时保留概念、匹配类型和来源。把“技能标签中出现 FastAPI”与“工作经历中描述了用 FastAPI 搭建服务”分别展示，比把它们压缩成一个肯定结论更有用。对没有找到直接证据的要求，界面应提示继续核实。

岗位数据保存在 SQLite 普通表中，知识按岗位画像、职责、预期产出和评价材料等内容分段。检索在 Python 中结合词面和概念别名打分，排序后返回 Top-K 片段。当前实现没有使用 SQLite FTS5，也没有引入向量索引。

评分引擎另外承担确定性的计算：按岗位族群选用权重模板，对技能、年限、学历和经历证据等维度评分，再结合硬性条件限制结果。直接、别名、相关和加分项有不同的匹配权重，结果携带匹配依据、缺失概念、风险提示和追问草稿。

检索负责找到相关材料，评分负责按规则计算，两者的输出再由界面解释给使用者。这样可以分别检查“材料是否相关”“规则是否合理”和“解释是否忠于证据”，避免把所有问题都归结为一个总分。

例如，站内的虚构案例包含 Python 和 FastAPI 的经历，同时缺少 FAISS 的直接证据。演示会列出已命中的内容，并将 FAISS 放进待核实项。这里的“缺少证据”是阅读结果，不等同于断定候选人没有这项能力。

检索增强生成（RAG）的核心思路，是把检索到的材料交给生成环节作为上下文。检索可以采用词面方法；是否使用向量数据库并不是判断它的唯一标准。

在这个项目中，更准确的产品描述是“可解释规则匹配与可选 LLM 增强”。岗位检索和本地评分有独立用途，规则结果并不依赖模型生成。模型增强负责摘要、推荐语、亮点和追问等表达，并可提出有界的语义修正。

基础规则分与模型修正后的结果需要区分。当前实现允许的修正范围是 ±5，且仍受硬性条件上限约束。前端也应分别呈现不同分数的含义，不能把综合匹配、推荐分或模型判断统称为准确率。

岗位知识规模较小时，概念词表和本地计算便于部署、复算和维护。使用者可以追问某条结果来自哪里，开发者也能定位到词表、证据或权重，而不必只修改提示词反复尝试。

这一选择有明确代价：词表没有收录的术语、隐含经验以及跨领域表达，可能无法得到充分匹配。词表需要持续维护，相关概念的权重也需要结合反馈检查。模型增强为语言理解和追问提供补充，但不应悄悄改变基础规则的含义。

外部模型默认关闭；启用后，发送前会对相关内容脱敏。网络或模型调用失败时保留规则结果，让主流程能够继续。“本地优先”描述的是默认处理路径，开启外部模型后仍存在外发数据路径。

当前没有经过人工标注的准确率验收，站内分数仅用于解释虚构案例。要判断实际效果，后续需要构建经授权、脱敏并人工复核的样本，分别检查概念命中、证据归属、遗漏信息和追问是否有帮助。

这个项目最重要的设计选择，是让每一条结论都能回到可以检查的材料：规则承担可复算的部分，模型补充解释，最终由招聘者核实证据并作出判断。