招聘场景中的大模型很容易给出一个听起来专业的回答：某位候选人适合数据平台岗位，因为他有数据仓库、云计算和团队管理经验。真正困难的是追问三次：这些判断分别来自简历哪一段？岗位对这些能力的要求来自哪个版本？系统没有看到的内容，有没有被当成事实补出来？
RAG（Retrieval-Augmented Generation，检索增强生成）被广泛采用，正是因为它把模型的“表达能力”与外部知识的“事实来源”分开。但招聘 RAG 不是在向量数据库里找几段文字再塞进提示词。它还要处理实体关系、时效、权限、个人信息和证据引用。
一个能演示的 RAG 很容易，一个能解释、能更新、不会越权的招聘 RAG 是另一回事。
RAG 解决的不是“模型不聪明”，而是知识不可控
RAG 原始论文 将参数化语言模型与可检索的外部非参数记忆结合。这样做有两个关键价值：知识可以在不重新训练模型的情况下更新，回答也有机会关联到检索证据。
对招聘系统来说，最需要外部化的知识包括：
- 企业岗位序列、职级与招聘流程；
- 岗位、技能、证书、专业和行业之间的关系；
- 当前生效的 JD、面试标准与用人规则；
- 经授权访问的候选人简历与招聘记录；
- ATS、解析接口和产品操作文档。
这些知识的更新周期完全不同。岗位制度可能按季度调整，候选人状态可能几分钟变化一次，技能图谱则持续演进。把它们全寄希望于模型参数，本身就是错误的数据架构。
招聘知识为什么不能只做向量检索
向量检索擅长找到语义相近的文本，但招聘问题往往同时包含精确约束和关系推理。
例如“找在广州、有三年以上跨境电商推荐经验、最近两年仍使用 Python 的候选人”，其中地点、年限和时间范围是结构化过滤，推荐系统与跨境电商是语义概念，Python 还要关联到具体经历。单一向量相似度很难同时保证这些条件。
更合理的召回通常是三路并行：
- 结构化过滤保证地区、时间、权限和必需条件；
- 关键词检索保留产品名、证书、缩写等精确命中；
- 向量与图谱检索发现同义表达、相邻技能和实体关系。
候选结果再经过重排模型，结合当前问题判断真正相关的证据。图结构的作用并不是让架构看起来更复杂，而是显式保存“岗位需要技能”“技能属于领域”“经历证明技能”等可遍历关系。2024 年的 GraphRAG 相关研究也在处理普通 RAG 对网络化知识和全局关系利用不足的问题。
权限必须发生在检索之前
招聘知识库与普通产品 FAQ 最大的不同，是其中包含个人信息和组织敏感信息。一个常见但危险的实现是：先从全量向量库召回，再在提示词里告诉模型“不要泄露无权访问的数据”。
这时越权数据已经进入模型上下文。即使最终页面没有显示，日志、缓存、追踪系统或提示注入仍可能造成泄露。
权限应进入检索条件本身：用户是谁、属于哪个组织、可以访问哪些岗位和人才池、当前用途是什么。原始数据删除或权限变化后，向量、关键词索引、图谱边和缓存都要同步失效。向量数据库不是原业务系统权限模型的替代品。
从“检索一次”升级为证据控制
RAG 的下一阶段研究也说明，仅仅检索并不能自动保证事实性。Self-RAG 让模型学习何时检索，并对生成内容与证据支持程度进行反思；研究在开放问答、事实核验和长文本生成上观察到事实性与引用准确性的改善。
工程上不必原样复现论文模型，但可以吸收三个思想：
- 不是所有问题都需要检索，先判断意图与知识范围；
- 检索结果不是天然正确，需要重排、去重和时效检查；
- 每一个关键结论都应检查是否被证据支持。
招聘回答还应把信息来源分级：简历明确写出、企业知识库明确规定、标准化映射得到、模型推断。模型推断不能在界面上伪装成候选人事实。
引用设计决定系统是否真的可核验
“根据候选人简历”不是有效引用。可核验引用至少要包含文档、版本、页码或原文片段。制度类知识还要显示生效时间；候选人数据要显示访问范围，避免通过引用泄露原本不可见的信息。
建议输出结构不是一段纯文本，而是：
claim：模型给出的结论；evidence_ids：支持该结论的证据；source_type：简历、JD、制度或知识图谱；confidence：证据充分程度；unsupported：无法得到证据支持的内容。
前端再根据结构渲染摘要与引用。这样可以自动检测“有结论无证据”，也便于模型升级后的回归测试。
RAG 不能只评最终答案
如果答案错了，可能是正确文档没有被召回、重排把它放得太后、模型忽略了证据，或业务知识本身已经过期。只让人工打一个“答案好不好”无法定位问题。
检索层可以测 Recall@k、MRR、权限过滤正确率和过期文档命中率。生成层可以测结论支持率、引用正确率、冲突处理和无答案拒答率。业务层则观察招聘人员核对时间、有效搜索迭代次数和错误处置成本。
测试集一定要包含反例：知识库没有答案、两个制度版本冲突、用户无权访问目标人才、问题中包含错误前提，以及简历里出现诱导模型执行指令的文本。
一个适合从零开始的落地顺序
第一阶段不要直接连接全量候选人库，可以从岗位制度或产品文档问答开始，建立文档版本、引用和无答案机制。第二阶段加入岗位与技能图谱，验证混合检索和关系解释。第三阶段再连接候选人数据，并把原系统权限带入每一次检索。最后才考虑让 RAG 进入搜索、匹配和工作流操作。
每扩大一步，都先回答四个问题：知识由谁维护？权限在哪里执行？错误如何被发现？数据删除如何传导？
RAG 的价值不是让大模型“知道更多”，而是让系统对自己依据的知识负责任。对招聘这种高敏感、高时效场景，证据链、权限和评估比模型生成得多自然更重要。