HR 招聘机器人：纯 LLM 还是 RAG + LLM？我们用 3 万条话术测出真相

引言

招聘场景的 HR 机器人，到底该用纯 LLM 直接生成话术，还是先检索再生成？这个问题在团队内部吵了很久。有人说纯 LLM 响应快、链路短，有人说 RAG 能保证话术贴合公司真实岗位和候选人背景。

与其继续争论，不如直接测。我们把过去一年沉淀的 3 万条真实外联话术（覆盖技术岗、职能岗、销售岗）导入系统，做了三组对照实验：纯 LLM、纯 RAG、RAG + LLM 兜底。结果有些反直觉。

纯 LLM：快，但"编"得让人心慌

纯 LLM 的方案最简单：把候选人简历、岗位 JD、公司介绍一股脑塞进 prompt，让模型直接生成第一句外联话术。链路短，不需要向量库，部署成本几乎为零。

我们用某主流大模型跑了 5000 条测试样本，平均首字响应时间 1.5 秒，确实快。但问题出在"稳定性"上。

最典型的翻车场景是：当候选人简历里出现模型训练数据里少见的冷门技术栈（比如某个细分工业协议、某个小众数据库），模型会"脑补"出似是而非的话术——把候选人没做过的事说成"您在 XX 领域深耕多年"，一旦被候选人识破，回复率直接归零，甚至引发投诉。

纯 LLM 的本质是"闭卷考试"：模型靠训练时记住的知识硬答，遇到知识库之外的岗位细节，只能靠猜。这在招聘这种"说错一句就丢信任"的场景里，风险太高。

纯 RAG：准，但"死"得没有灵魂

第二个方案是纯 RAG。我们把 3 万条话术切成 chunk，做向量化存入向量库，检索时按相似度召回 top-k，再拼一个固定模板输出。

这个方案的问题恰恰相反——太"死"了。RAG 只能从已有话术里"抄"，没法针对候选人的具体背景做个性化改写。比如库里存的是"您在 Java 后端有丰富经验"，遇到一个做 Go 的候选人，检索结果还是硬套 Java 的模板，话术生硬、缺乏针对性。

更麻烦的是，纯 RAG 的命中率严重依赖向量库的质量。我们实测发现，当候选人背景和库内话术的语义距离较远时，top-k 召回的往往是不相关的内容，拼出来的话术驴唇不对马嘴。

RAG + LLM 兜底：命中率 95% 的折中解

最终我们落地的方案是"RAG 优先 + LLM 兜底"的双层架构，这也是 ClawBrain HR Agent 的核心思路。

第一层，先用向量检索从 3 万条话术库里召回语义最接近的 top-5 话术作为"参考素材"。如果相似度超过阈值（我们设的是 0.85），直接基于检索结果做轻量改写输出，响应时间可以压到 100ms 以内。

第二层，当检索相似度低于阈值（说明库里没有足够匹配的话术），才触发 LLM 兜底——把召回的话术作为 few-shot 示例，结合候选人简历和岗位 JD 重新生成。这样既保证了命中场景的快速稳定，又保留了冷门场景的灵活性。

下面是一段简化的核心逻辑示意：

def generate_outreach(candidate, top_k=5, threshold=0.85):
    # 第一层：向量检索召回参考话术
    hits = vector_search(candidate.embedding, top_k=top_k)
    best_hit = hits[0]

    # 命中：相似度够高，直接轻量改写
    if best_hit.score >= threshold:
        return rewrite(best_hit.text, candidate.name)

    # 未命中：LLM 兜底，用召回结果做 few-shot
    examples = [h.text for h in hits]
    return llm_generate(candidate, examples)

实测数据说明了一切。

总结

纯 LLM 和纯 RAG 是两个极端：一个快但会"编"，一个准但会"抄"。招聘外联这种"既要准、又要像人话"的场景，单靠任何一方都不够。

真正能落地的，是把两者组合起来的分层架构——高频命中走检索快路径，低频冷门走 LLM 兜底慢路径。这套思路不只在招聘场景成立，在任何"知识库 + 个性化生成"的业务里都适用。

而这正是 ClawBrain 在做的事。它是专为龙虾（OpenClaw）打造的智能决策引擎，具备任务闭环、自主规划、错误自愈能力。在 HR 招聘机器人这个场景里，ClawBrain 的价值不只是"选对模型"，而是让整个检索、改写、兜底、反馈的流程自动闭环——话术命中率下降时自动触发知识库更新，生成结果被候选人拒绝时自动标记并优化 prompt，让龙虾真正能独立把招聘外联这件事跑起来，而不是每次都要人来盯着改。