不要把 RAG 当成 Copilot：从知识问答到 Role Workflow

很多企业 AI 项目的第一步，都是做一个 RAG demo。

把企业文档导入知识库，用户提问，系统检索相关内容，再交给 LLM 生成回答。这个路径非常自然，也很容易展示效果：以前查文档要翻半天，现在一句话就能问出来。

但也正因为它太自然，很多人会把 RAG 和 Copilot 混在一起。

好像只要 RAG 做好了，企业 Copilot 就差不多完成了。

我现在越来越觉得，这是一个很重要的误区。

RAG 是企业 AI 的知识底座，但它不是完整的 Copilot。真正能进入企业工作的 Copilot，不只是回答问题，而是要进入某个岗位、某个场景、某条业务流程，并且能基于证据做判断、生成报告、暴露不确定性、记录 trace、进入人工复核。

换句话说：

RAG 不是企业 Copilot 的终点，而是 Role Copilot Workflow 中的知识能力节点。

这篇文章想用 HR Copilot 的简历筛选场景，说明 RAG 应该放在 workflow 的什么位置，以及为什么“知识问答”距离“企业级 Copilot”还差一整条流程链路。

RAG 问答和 Role Copilot 不是一回事

一个典型 RAG 问答链路大概是这样：

它解决的是：用户问了一个问题，系统从知识库里找相关材料，然后生成一个答案。

这当然有价值。

但企业里的很多 AI 任务，输入并不是一个简单问题，而是一个业务任务。

比如 HR 场景里，用户真正想要的不是：

候选人 A 有没有 Kubernetes 经验？

而是：

帮我判断候选人 A 是否适合高级 Java 后端岗位，并生成一份可复核的候选人分析报告。

这里面至少包含：

• JD 要求
• 用人部门偏好
• 简历材料
• 多格式文档解析
• 候选人能力维度
• 评分规则
• 证据引用
• 证据不足时的追问建议
• 候选人报告
• trace 记录
• 人工复核

这已经不是“问答”了，而是一条 Role Copilot Workflow。

可以粗略对比一下：

维度	RAG 问答	Role Copilot Workflow
输入	用户问题	业务任务
核心能力	检索与回答	编排、判断、报告、复核
输出	答案	结构化报告、建议、追问点、trace
风险控制	主要依赖 prompt	evidence gate、human review、audit
复用方式	知识库能力复用	多岗位 workflow 复用

RAG 解决“材料里有什么”。

Role Copilot 解决“在这个岗位任务中，基于这些材料应该如何判断和行动”。

这是两件相关但不同的事。

一个通用的 Role Copilot Workflow

我现在更倾向于把企业 Copilot 抽象成这样一条 workflow：

每个节点的职责不一样。

Task Intake 接收的是业务任务，不只是自然语言问题。

Role Context Resolver 负责理解当前角色、场景、目标和约束。HR Copilot 关心 JD、候选人、用人偏好；DevOps Copilot 关心项目、构建、发布、故障；Project Copilot 关心需求、代码、测试和评审。

Document Parser / Tool Node 负责处理 PDF、Word、Markdown、日志、表格等材料。企业场景里，材料经常不是干净文本。

Query Builder 把业务判断目标转成检索问题。

Retrieval Node 从知识库或材料集中召回相关内容。

Evidence Extractor 从召回内容中抽取能支撑判断的具体事实。

Citation Builder 把每条事实绑定到来源。

Evidence Gate 判断证据是否足以支持结论。

Judgment / Insufficient Evidence 决定是做业务判断，还是明确声明证据不足。

Report Generator 生成业务可用的输出。

Trace Recorder 记录这次判断是如何形成的。

Human Review 让人类进入复核、追问、审批或纠正。

这条 workflow 的关键不在于节点名字是否固定，而在于它表达了一个架构事实：

企业 Copilot 不是一个“更强的问答框”，而是一条围绕角色任务组织起来的判断流程。

RAG 在 Workflow 中的位置

在这条 workflow 里，RAG 处于什么位置？

我会这样定义：

RAG 是 Knowledge Capability Node，Role Copilot 是 Role Workflow。

RAG 主要覆盖这些部分：

它负责把业务问题转成知识检索，召回相关材料，抽取证据，并生成引用。

但 RAG 不负责完整的岗位任务。

它通常不直接负责：

• 角色上下文解析
• 多工具编排
• 业务评分规则
• 证据门控
• insufficient evidence 判断
• 报告结构
• trace schema
• 人工复核流程
• 后续状态追踪

所以更准确的表达是：

RAG 提供证据原料，Role Copilot 负责把证据放进岗位任务、判断规则和业务流程里。

如果只做 RAG，系统像一个知识问答助手。

如果做 Role Copilot Workflow，系统才开始像一个可追踪、可复核、可治理的岗位助手。

用 HR Copilot 跑一遍

来看一个 HR 简历筛选场景。

用户任务是：

判断候选人 A 是否适合高级 Java 后端岗位。

如果只是 RAG 问答，系统可能会回答：

候选人 A 有 Java 和 Spring Cloud 经验，简历中未提到 Kubernetes。

但一个 HR Copilot 不应该停在这里。

它应该走一条完整 workflow。

Task Intake

接收任务：判断候选人 A 是否适合高级 Java 后端岗位。

Role Context Resolver

读取岗位上下文：高级 Java 后端、JD 要求、用人部门偏好、候选人评分 rubric。

Document Parser / Tool Node

解析候选人 PDF 简历、Word 版 JD、Markdown 格式的面试标准。这里已经涉及 tools，而不是纯 RAG。

Query Builder

构造检索问题：

• 候选人是否满足 Java 5 年以上？
• 是否有微服务经验？
• 是否有云原生或 Kubernetes 经验？
• 是否有团队协作或项目主导经验？

Retrieval Node

召回：

• 候选人简历项目经历
• JD 要求
• 用人部门补充说明
• 候选人评分 rubric

Evidence Extractor

抽取事实：

• 候选人有 6 年 Java 经验
• 有 Spring Cloud 项目经历
• 简历中未明确出现 Kubernetes 生产经验
• JD 要求具备云原生落地经验

Citation Builder

绑定引用：

• resume.pdf p2 项目经历
• jd.md 第 3 条
• hiring-note.md 第 1 条

Evidence Gate

判断证据是否足够：

• Java 年限：证据充分
• 微服务经验：证据较充分
• Kubernetes 生产经验：证据不足

Judgment / Insufficient Evidence

形成有限判断：

候选人 A 可以进入一面，但不能直接判定完全匹配。Java 和微服务经验证据充分；Kubernetes 生产经验缺少明确证据，需要在面试中重点追问。

Report Generator

生成候选人分析报告，包括优势、风险、证据、追问点。

Trace Recorder

记录这次判断背后的 query、retrieval、evidence、citation、judgment、trace_id。

Human Review

HR 或面试官复核报告，决定是否进入下一轮。

你会发现，RAG 在这里很重要，但它只是其中一段。真正的 Copilot 能力来自整条 workflow 的编排。

这个 HR Copilot workflow 也可以进一步落到 Agent Skills 的形态里。比如我在 role-copilot-skills 里整理了一个 HR Agent Copilot 的 skills 目录，用来承载简历筛选、候选人详情报告、面试问题生成等可复用能力：

hr-agent-copilot

Citation 不等于结论可信

在企业 AI 里，一个常见问题是：只要回答里带了引用，大家就容易觉得它可信。

但 citation 只能证明“这句话来自哪里”，不能自动证明“这个结论是对的”。

比如简历里写：

参与云原生平台建设。

系统给出 citation：

resume.pdf p2 项目经历

这条 citation 可以支持：

候选人参与过某种云原生相关工作。

但它不能直接支持：

候选人具备 Kubernetes 生产故障排查经验。

因为中间缺了具体证据。

云原生平台建设可能包括很多工作：业务服务开发、CI/CD 接入、容器镜像配置、Kubernetes 部署、监控告警、故障处理。没有更具体的 evidence，就不能把宽泛经历推断成具体能力。

所以应该区分三层：

• citation: 这句话来自哪里
• evidence: 原文中可支持判断的具体事实
• judgment: 基于证据能得出的结论

如果 evidence 不足，系统就应该进入 insufficient_evidence。

Insufficient Evidence 不是失败，而是质量控制

很多人希望 AI 永远给出确定答案。

但在企业场景里，不确定不是问题；问题是把不确定伪装成确定。

如果材料只写：

候选人参与云原生平台建设。

合格回答应该是：

当前材料中未找到候选人具备 Kubernetes 生产故障排查经验的明确证据。已有证据显示候选人参与过云原生平台建设，但材料未说明其是否负责 Kubernetes 部署、容器编排、生产故障处理。建议在面试中追问 Kubernetes 相关经验。

不合格回答是：

候选人具备 Kubernetes 经验。

另一个不合格回答是：

候选人没有 Kubernetes 经验。

前者是过度推断。

后者是把“未找到证据”当成“事实不存在”。

这里有一个很重要的规则：

evidence_absent != fact_false

也就是：

证据缺失，不等于事实为假。

因此，一个成熟的 Role Copilot 应该能结构化表达证据不足：

• 已检索材料是什么
• 已有证据是什么
• 证据缺口是什么
• 当前能得出什么有限判断
• 当前不能得出什么结论
• 下一步应该如何验证

这不是保守，而是企业系统必须具备的判断边界。

RAG 层可以复用，Role Workflow 必须重做

这套抽象不只适用于 HR。

同一个 Knowledge Runtime 可以服务多个 Role Copilot：

• HR Copilot 检索简历、JD、面试记录、评分 rubric。
• DevOps Copilot 检索构建日志、发布文档、故障手册、变更记录。
• Project Copilot 检索需求文档、代码、测试结果、评审意见。

但是，每个 Role 的 workflow 不一样。

HR Copilot 的 workflow 围绕候选人筛选、评分、报告和面试追问。

DevOps Copilot 的 workflow 可能围绕构建诊断、发布风险、命令预览和审批。

Project Copilot 的 workflow 可能围绕需求理解、代码变更、测试影响和评审建议。

因此：

Knowledge Runtime 可以复用，但 Role Workflow 必须按岗位任务重新设计。

这也是为什么我不太愿意把企业 AI 简化成“做一个 RAG 系统”。

真正的问题不是“能不能查到文档”，而是：

• 查到的材料如何变成 evidence？
• evidence 如何绑定 citation？
• citation 是否足以支持 judgment？
• 证据不足时如何回答？
• 判断过程如何 trace？
• 最终结果如何进入 human review？
• 这条 workflow 如何在不同 Role 中复用和扩展？

这些才是企业 Copilot 的关键问题。

从知识问答到可治理判断链路

如果只看 demo，RAG 很容易显得像企业 AI 的主体。

但如果看真实业务流程，RAG 更像地基和管道。它提供上下文、证据和引用，但不会自动变成一个完整的岗位 Copilot。

企业 Copilot 的关键，不是让模型更会回答问题，而是让每一次回答和判断都能：

• 被证据支持
• 被 citation 指向来源
• 被 evidence gate 约束
• 在证据不足时拒绝越界
• 被 trace 回放
• 被人类复核
• 被业务流程接住

所以我更愿意把路线表达为：

从 RAG 问答，走向 Role Copilot Workflow。

RAG 是必要的，但不是终点。

真正让 AI 进入企业工作的，是围绕具体岗位任务设计出来的 workflow：它知道该查什么、如何取证、如何判断、什么时候不能判断、如何输出报告、如何留下 trace、如何交给人复核。

这才是从“知识库问答”走向“企业级 Copilot”的关键一步。