# 【人力资源】Agent 遇见 HR：员工服务、决策、政策三线突破 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：通用业务用户 - **时间信息**：6月23日 | 14:00 - 14:30 - **标题**：【人力资源】Agent 遇见 HR：员工服务、决策、政策三线突破 - **PDF 资料**：无 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：14:00 - 14:30 - **会议类型**：专题演讲 - **面向 Persona**：通用业务用户 ### 亚马逊云科技演讲人 - **曹镏**：资深解决方案架构师 ## 二、会议资料 PDF 转录内容 （本场次无 PDF 资料） ## 三、会议回放视频转录内容 非常高兴能在这里给大家带来我们 HR 场景的 AI 应用 因为在过去的很长的一段时间里面 大家可能会首先关注的是 AI 实际上生成式 AI 这几年的发展 这样的一个 AI 应用远不止是 现在某一个单一的 AI 场景 而是对于我们整个企业里面来说 每一个地方每一个部门 它都要去思考自己的部门如何去做 这样的一个 AI 的应用和 AI 的决策 所以今天我们给大家带来的是一个 HR 和 AI 结合的这样的一个场景的一个分享 在开始的时候我们首先回顾一下 在整个 HR 领域我们到底经历了什么和遇到了什么 那么在过去的20年里面 整体的说25年里面 我们可以把 HR 分为这么几个阶段 那么在早期的时候 2000年的时候我们的 HR 逐步的去做数字化和线上化这样的一个应用 那么这可能还是一个非常早期的 因为那时候的电脑还是比较的原始 第二阶段进入了一个数字化的阶段 在2010年左右 那么在2024年进入到了智能化的时代 2026年我们现在我们认为它是一个 Agentic AI 的时代 那么在这几个时代里面有一个显著的差异在于 我们早期的时候去做数字化基础的一种信息化的流程 第二个阶段在2010年我们去遇到了很多很多多样的这种 SaaS 这种统一的平台 不光是我们基础的数据还能让我们的流程实现这样的现代化 第三个阶段通过 AI 辅助 BI 帮助我们的 HR 可以更多的去挖掘我们团队内 有各种各样的一种企业内部的信息 无论是薪资的信息还是人力资源的信息 那么到现在为止我们出现了很多 AI agent 来去做各种各样的可以去闭环的任务 那么即便是发展这么快 实际上挑战还是依然存在的 客观的说我认为我在服务我的客户的时候 很多客户会提出来 我们的员工咨询是不是可以用 AI 全部去解决 发展到现在我认为这个员工咨询这个场景 它可能解决能解决一部分 但肯定解决不了很多 举一个例子来说 有一个有一个很基础的一个员工咨询 他问他去问我打探一下我的同事的工资是多少 这种情况下你说如果我们交给 AI 去回答 可能就是这个后果是不堪设想 第二个是数据的分析部分 数据分析的部分我们可以看到 从刚才的那张大图里面发展了这么多年 数字化发展了从2010年 整个就开始不断的数字化 流程的数字化 企业信息的数字化 到现在为止我认为基础的企业里面 很多企业的 HR 的部门 无论是我们的专家部门 或者是共享服务 他们都可以拿出很多的数据 但是在我实际跟客户接触的过程中 也会有 HRBP 来反馈 我们 BP 服务的一个部门 是一个特殊的业务部门 那么业务部门的数据是不是 更加有针对性 我们有业务特点的数据性 而这一块恰恰是在这个 现在这一段其实做的不是很好的 第三个就是政策的落地 我们一个政策 如果你是一个规模还处于起步阶段 只有几个 HR 或者十几个员工 你在微信群里发个消息 你的政策我认为就可以落地了 但是以今天亚马逊为例 覆盖全球的100多万员工的 这样的一个企业 当你政策想要去落地的时候 你很难说我在微信群里发一个消息 这里涉及到不同的语言 不同的肤色 不同的人种 不同的地区和政策 那我们不可能用一个很简单 很粗暴的方式去让它落地了 这些挑战依然存在的情况下 我们就要去思考 我们怎么样去通过我们的 AI 能力 和 AI 服务去解决这些具体的问题 在这里举一个基础的例子 那么在今天我也会给大家 带了几个例子来看一看 这些问题具体 我们的实践中会有什么样的解决方案 第一个是一个员工入职 这是一个非常常见的场景 我见到很头部的企业 它能够做到整个员工的生命周期 都是在线上化的 在这样的情况下 就是有一个客观的痛点 就是如果我去做 整个员工生命周期的线上化 那么入职其实是它最重要的一个起点 那么在这个入职的一个过程 一个员工在入职的过程中 我们通常来说可以把它放为几个步骤 就包括了它的一个基础的一个入职清单 基础的它刚入职的时候 一些政策的回答 这个政策就包括我的 IT 怎么配置 我的电脑怎么配置 我的权限怎么申请等等 第三块就是涉及到它自己 一个入职员工 它可能本身就是会有权限的申请 它涉及到部门里 你可以操作哪些系统 你可以触碰到哪些数据 这些都是在很多企业里面 都是需要提交工单的 第四块包括这样的员工到了我们企业以后 我们是不是有自动的欢迎消息能够发出来 第五块就包括它的个人的资料辅助信息的填写 可能是并不局限于我们入职的时候 最基础的信息 比如说并不是我的出生年月这种 而是说我一些特殊的技能 我额外除了我的母语以外 或者第二语言第三语言第四语言 这些个人信息往往是在入职以后填写的 在这里也是给大家分享一个 我们在我们的实践过程中 其实我们很多的客户 在采用这样的一个服务 Amazon Quick 去搭建它的这样的一种入职体系和入职能力 这个产品它大概可以分为这么几个基础的模块 就是一个 第一个是 Spaces 这个是一个团队的空间 比如我们团队如果里面有一些共享的知识 往往可以放在这个里面 第二个是一个 Chat Agent 简单来说我如果要构建一个 我在部门里面的 Agent 对话的机器人 或者 Agent 用来回答一些政策性问题 我可以用它这个 Agent 第三块就是一个 Research 这是一个深度检索的模块 坦率地说我们现在有很多问题调用 它并不是一个简单的大模型推理 就能给出答案 这需要基于很多事实的分析 深度的报告 第四个就是包括它能够去整个数据 这也是我们认为我们真正的一站式办公所需要考虑的 我的办公并不是通过一个模型 通过一个互联网搜索就能解决 而是我企业里面有没有商业化的数据 并且把这些商业数据能够很好的展示化出来 第五块就是 Flow 就是通过这个是一个流程 就是我有数据 我有这种团队的数据 我有个人的数据 可以做深度的检索 我可以和人机交互做对应节点的时候 我们通过这个 Flow 就可以把前面这些事情给串联起来 形成一个工作流 并且把这段工作流不断地去自动化来构成我们 这是一个构成这样的一个产品 我们叫 Quick 那么简单看一下 就是如果我们去构建一个入职的 Agent 大概在这个上面其实是怎么去用的 这里会有一个我们的管理员 他会通过配置一个基础的 agent 这样的形式 来去构建一个人机可以跟用户交互的模块 这里面就是一个 Chat Agent 用户可以去跟 Chat Agent 对话 而它配置完 Chat Agent 有一个重要的作用 是把我们的数据和行为和 Chat Agent 连接起来 这里面包括我们的空间 这就是我们团队里面共享的数据 第二个是我们企业的一个知识 就是我们企业里面可能有 除了政策以外的我们团队里面达到的一些文档之类的 可能它可能本身存在一些网盘里面 那么也可以去接入进来作为构建 agent 的一部分 第三块是 agent 的行为 比如说我要发起一个工单 或者是调用一些 API 那么就通过 agent 这个模块来构建起来 通过这样的一个方式 从用户的请求出发 然后去查询我们企业的知识 我们的政策以及触发对应的行为 来满足它的一个入职的这样的一个操作 这样的一个配置 通常来说如果你没有一套完善的系统 那可能是比较长的一个时间 你可能要工作 寻求开发资源 或者是类似的一个方式 可能要几个几周 甚至上月的时间开发出来 当然在这个 Quick 里面 你只需要配置一下 可能几个小时就完成了 那么最更重要的一点是 为什么我们要构建这样的一个 agent 其实它并不只是说 我们能够去帮助我们的 HR 在减少时间 其实不光是服务于它 更重要的是服务于我们的员工 我们的员工如果有这样的一个东西 能够帮助它去做入职引导 指引薪酬福利的查询 以及假期政策等等 这个会让我们的员工的工作效率 变得更高 本来它可能要花半天的时间 在各个地方和各个人去对接 去问询 但实际上它如果通过这样的一个工具 那就可以很快地去得到对应的一个答案 而不需要把时间浪费在这些 事务性的问询上面 这个是一个非常常见的一个场景 但是我们可以很高效地去构建它 第二个就是一个数据决策 这个地方也是我们的 HR 一个很常见的一个问题 举个例子来说我们部门里面 可能会有一些 leaders 他就问一些给到我们的 HRBP 一个很直观的问题 比如说三个季度 我们研发部门的人才盘点的情况是怎么样子 高潜的比例怎么样 跟行业对比如何 这个我们现在能够看到的做法 这种无论是你出九宫格也好 或者是说人才的盘点的整体报告也好 你可能是一种 我自己企业本身就可以直接出这种报告 通过查询我的人才数据库 然后做这种人才的九宫格 然后分析人才分布 然后对标行业数据以及生成可视化报告 它可能是自动化了 其中的一部分到两部分 或者是我专门找专业的咨询机构 去做这样的事情 这个咨询机构包括行业内的一些 这种专门做人才盘点的企业和服务的企业 但这样的一个很重的模式 它会带来一个问题 就是我们的 HRBP 在服务我们业务部的时候 它怎么样去比较灵活的可以做这件事情 而不是说依赖于每个 HRBP 都需要对接一个行业部门 或者是我的企业要为每个 HRBP 针对性的去定制这样的一个人才报告 在这里我非常推荐的是亚马逊的一个做法 就是亚马逊在做这件事情的时候 其实我们的 HR 报告 HR 的团队会很大程度上借助于 刚才我们说的 Quick 这款产品来去构建 它其实应用了其中的 Quick Flow 这个能力 去类似于这种工作流的方式 去构建整个的流程 下面我们可以看一下 在这里我在 PPT 的右侧的部分是一个 demo 视频 demo 大家可以我们可以稍微看一下 这个 demo 是一个普通的员工信息 当然这个信息是我之前为了做视频 demo 而准备的一个虚拟数据并不是正式的 我们可以看一下 这个虚拟的数据里面 我大概是把这个里面虚拟了一些职级 岗位人员分布不同的职能等等 做成了一张虚拟表 这种表往往是我们作为人才盘点的一种基础 第二个就是我们想要有价值的报告 这里面有实际产出的 第一个包括我们生成这种九宫格人才地图的报告 这也是我们 HR 非常常见的 第二个是继任计划和风险的分析 这是第二个报告 那么第三个是人才发展培养计划这样的一个报告 这是一个非常完善的报告 大概有20页 是我基于测试的数据做出来的 那么这个问题就是 如果我们生成这个报告大概要多久 那么我们可以看一下 这个就是用 Amazon Quick 的 Flow 的能力 它先去从我最基础的 Excel 表格里面 去提取了一个非常扎实的图形化的数据 它这个无论是九宫格数据风险数据 都是先把结构化数据抽取出来 然后做成可视化的报表 再基于这些可视化的这种扎实的数据 以及可视化的部分 然后去在这个基础上再去构建我们这样的分析能力 这里面就会形成无论是改进计划 人才优化建议等等 那么我们这个过程大概是执行了有11分钟 从原始的数据到可执行的方案是完全是自动的 当然这个问题大家会说 标准化的报告是不是我们想要的 就是刚才回到一开始的问题了 就是标准化的报告今天谁都能做 我找一个咨询机构 我找一个自己的企业也能做 那对我们 HRBP 有帮助吗 恰恰就是这个问题 在 Amazon 的 BP 在用这件事情的时候 它会把这个地方对于其中的流程节点进行调整 因为我服务的部门如果是一个仓库 以及我服务的部门是一个产品业务团队 那我想要的人才报告肯定是不一样的 第二块就是我不但是生成报告 我还可以去对报告本身以及数据进行提问 比如说人才的整体健康度 这个一开始并没有提前来报告里面 第二个就是人才有没有这种结构性的问题 这样的一个问题去询问它 这样的一个 Agent 的 可以让你自己去提问的目的是 因为我们的数据和报告 它其实只是一个结构化的输出 它不代表我们所有在底层数据产生的洞察 而我们想要我们的 HRBP 想要去跟我们的业务主管部门 去谈人才盘点的这样一个结果的时候 准备我们面谈的一个信息的时候 我拿一个专门的报告 还是说我在这里面除了基础的报告 并且在这个报告上有针对部门的定制 而且还充分的通过 Agent 的去挖掘了数据的底层逻辑 以后可能会去谈 哪个方式对于我们 HRBP 更有效率 就像我们现在今天推动的 HR 推动的在 HR 部门推动的 AI 创新一样 可能是说它是一个自上而下的 上面的领导直接拍一个 我们做一个产品 做一个工具 一下子就解决所有 HR 的问题了 但实际上真正相当 如果我们想要让 HRBP 去效率更高 让我们的 BP 们效率更高 实际上它一定是发挥它的主观能动性 在我们通过工具赋能它的情况下 让它可以去通过这种产生更大的价值和效率 这个是上面一个点 下面我们再看另外一个场景 因为刚刚那个是一个非常有意思的东西 就是我们通过这样的一个 Quick 让我们的 HRBP 或者是我们共享服务中心 或者是我们某个专家给他们提供价值 在这里除了这种通用的个人化的工具以外 其实我们企业还是有必要去做一些中心化的服务 这是需要我们整个企业去做的 在这里我举了一个很简单很小的例子 我还有几天的年假 能帮我提交一下下周的年假申请吗 这是一个很简单的问题 但是我可以这么说 在今天的中国的可能拍脑门 我说低一点就80% 甚至可以87% 这样的一个比例 它的企业的 HR 团队是没有这样的技术能力 构建出这样的一个东西 能够让它的员工再一个 构建一个对话 agent 出来 让它的员工通过这一句话 就能把这件事情给闭环了 因为这个事情 如果看起来你觉得它是一个很小的问题 我可以用人去处理 但实际上当这个企业 它有一定规模的情况下 这个问题会变得很难处理 就包括说一个 举一个最简单的例子 我们有一个客户 他的业务也不是特别广 是一个制造业企业在出海 大概他的也就覆盖了四五个国家 但是当他这个四五有四五个国家的时候 他的国家 他想给他的员工提供一个 一站式的 Agent 服务平台 来解决这个问题的时候 他发觉几乎做不到 因为每个国家 每个地区 都有不同的请假的政策 然后不同国家的政策的情况下 这个员工还要给他支持多个语言 然后在多语言的情况下 能够精准地算出 这个人应该有几个年假 而且能让 而且我还要把有几天年假的这个能力 暴露给一个 agent 让 agent 能够操作 太麻烦了这个事 这里面就会存在很多的一个技术风险 因为这里面 如果把这个地方拆解开 就是在右侧这一块 它实际上如果我要构建这样的一个对话能力 首先涉及到一个意图理解 首先就是你要把这个事情 拆解成一个我数字化系统能够理解的事情 第一个是查询余额 第二个是提交请假 这看上去是一段话 它其实是有两个意图在这个地方 然后两个意图就会拆分出来 查询 第一个就要去查询余额 这个是这种拆分能力 意图识别能力是要很强的 而且不能错 你第一个就要调用这个员工的余额 第二个是要确认信息 比如说它的日期和类型 为什么这边有个日期 它说的是帮我提交下周一 首先你问大模型 这个大模型如果没有额外的图 是一个通用的大模型 它很难准确地告诉你下周一是哪一天 所以在这里 首先它要知道下周一到底是几月几号 第三个它能够提交申请 我们怎么样让模型具备这种写的能力 这其实是一个很重要的 也是我这几年发展的一个关键 今天带来的能力 就是让模型能够自动地采用 工具调用这样的方式 去能够自主地去做一些行动 提交请假 然后最终返回结果 就是这么一个简单的问题 但实际上是一个 在你的员工规模比较大的时候 它会变成一个很复杂的问题 用 AI 解决都很难 在这里大家也会有人提问 那我是不是用个传统的 Chatbot 比如说我们有一些聊天工具里面 它会自己带 自己带一个对话机器人 是不是也能够去做这样的一个事情 这个事情我是这么看的 就是它其实在我们上面的第一步 就会很容易被卡住 生成式 AI 大语言模型出现以后 它有一个很有趣的一点 就是它通过自然语言的理解 提升了模型意图识别的这样的一个能力 大语言模型在回答一个问题 虽然它是一个概率模型 但是它意图识别的 能达到了一个前所未有的高度 它能够在你多轮对话的过程中 能够准确的发现这个人的意图 以及意图不断地转化 就刚才我举了这个场景里面 其实它一个很清晰的问题的拆分就是 它有两个意图 第一个意图是要查假 其第二个意图是要去请假 但如果是传统的 Chatbot 往往在这里面就要基于自然语言的匹配 然后通过这个语言更接近于 比如说通过一些向量检索 然后去拆 它这个地方更接近于什么样的一个意图 或者是我传统的一种预设 就基于我有一大堆意图 本身就训练好 然后一起塞进去 但是这种情况下往往会带来一个问题 这个一句话里面 隐含的意图太多的时候 它识别不准确 第二个是在多轮对话的情况下 就是当你这个 Agent 暴露出来 想要一个 Agent 服务于我企业员工的时候 它就不一定是一个单一的请假场景 它还会涉及到很多 它除了问请假以外 它还可能去问工资 它还可能问其他的政策 这些都可能 那这样意图就不断地去变化 所以相比较而言 我们认为 传统的 Chatbot 在做对话类的时候 它会遇到很多很大的一个瓶颈 除了这种意图的识别以外 然后它的主动的推理和执行 以及对多个系统的调用 能力远不足于 没有现在的 AI Agent 的能力强 为什么涉及到多个系统调用的能力 为什么会提到这一点 就是在今天的时候 我们当有一个员工的问题进来的时候 举个例子来说 很多企业它的薪酬福利 它的员工薪资 它的请假销假 它其实都不在一个系统里面 它可能是一个已经是被迭代化了 这么多年以后发展以后 它都不在一个 都很难去提供一个单一的接口去做的时候 那么一次意图一次请假 这有可能触发多个系统的调用 而在多个系统调用以后 它还需要把这些多个系统调用的结果 收集回来 然后再生成一个自然语言的 朗朗易懂的一段的这样的一个内容 所以这个恰恰就是这样的一个统领 在这里我们举一个例子 这是一个我们已经实现过 在一个客户这边做过的一个 一站式服务 Agent 的一个抽象 在这里通过这个抽象进行一个举例 以请假这个场景来说 在这里我们可以看到这张图上 大概有这样的一个链路 我们就简单的 从这个链路的角度拆解一下 第一它这个请求第一过 虽然这个整个它是一个 AI Agent 的 但它的构建是 内部是有一定的复杂性 第一件事情其实是拿身份和上下文 我们做 AI 的 当一个 AI 系统要服务于 HR 团队的时候 它最重要的是不能犯错 因为 HR 本身这个部门有一定的敏感性 它有很多信息是不能够被越界访问的 它对安全性的要求极高 任何错误的回答 或者是不严谨的回答 或者是超越身份的回答 都有可能带来 在我们企业内部形法上的问题 所以所有对于 HR 这边 调用模型的能力进行问答的时候 第一件事情就要我要知道它身份是谁 而且这个身份会通过注入的方式 注入到它后续模型那边去 然后模型在调用任何系统的时候 全部要带上这个 模型去调用 tool 的时候也要带上这个 因为在模型在调用 比如说它调用这个请假的这样 调用请假这样的一个领域的时候 那么我必须知道这个人是 他的身份年龄职级 在哪个国家哪个地区 只有在这样的情况下 我才能准确的把它 给它生成这样的一个请假查询的请求 那么这里面就会从架构上来说 取完身份以后 它就会把我们的这个 AI Agent 的两个部分 第一个是做编排 第二个是做领域 编排和领域之间的一个区别在于 我因为请假我们可以把它做一个 独立的领域 那么福利政策 我们可以把它做为一个独立的领域 包括我们 IT 办公地址查询这类 我们都可以把它做 视作为一个独立的领域 而避免是所有的能力都通过一个服务 或者是单一的系统去查询 而编排它重要的作用 就是识别用户我这个请求进来以后 它的意图是什么 你决定我要去查询哪个子系统 或者是子 Agent 这样的一个推理的能力 但当它的请求经过推理和识别以后 识别出来这是一个请假域的请求 那么它会定位到对应的请求 到这样的一个请假域 去请假域的 agent 那么这个 agent 也会去帮它去解析这样的日期 然后查询对应的余额 就是假期的余额 通过我们 HR 系统的 API 然后结合领域类的这种 agent 政策 最终去触发这样的一个提交审批 就是请假的审批 来完成整个流程的一个闭环 这样的一个过程 这个是我们有做过 而且在亚马逊 亚马逊内部也有这样的一个 agent 在给我们提供类似的一个服务 就是大概是这样的一个过程 当然这里面就是会回到这个 一个1.HR 系统本身的一个敏感性 就是它并不是所有的问题都能够回答 这个是我们 HR 当构建一个 agent 给我们企业内部员工的时候 一个很特殊的问题 因为一开始的愿景都是非常美好的 我们的 HR 部门为了提升 我们人员和组织的效率 我们做了一个一站式的 agent 这个 agent 将服务于企业内部所有的员工 并且能够快速地回答 员工关于它在企业内部的各种问题 这种愿景是非常好非常宏大 一个动作就可以服务全集团几万名员工 但这个里面就是挺挑战的 就是第一个就是 不是你很难就是说所有的问题都用 agent 来回答 它有一个边界 在这里我举了一个很小的例子 就是我有一个紧急情况 对 这个问题 我分享一个实际的经验 就是在我们的企业这样的一个 agent 你去问它这样的一个问题的时候 它会告诉你一个紧急联系人和联系电话 或者是一个联系的一个职能部门 因为当你有一个紧急的问题的时候 我不能够说是我把这个问题 丢给一个大模型去回答 这样的回答是不负责任的 对于我 HR 团队也是一个非常大的挑战 所以对于这些问题 其实是我们要管理员工的一个输入 它输入的除了这种我有一个紧急情况以外 它也有可能是输入一些不安全的内容 举个例子来说 我查一查别人的薪酬 如果我能查我的薪酬 我是不是也可以查一查别人的薪酬 那么我如果除了查我的薪酬以外 我是我能帮自己想想 我是不是可以许你帮别人请假 这些都是一个不安全的内容 甚至在今天的大模型时代以后 这种大模型注入 模型注入的这种风险 来通过这样的注入来破坏你的模型 拿到越界 达到超越权限的能力 这些对于我们的团队来说 都是要积极防范 极其重要的 第二个就是它所在的员工 员工所在的地区的法规 有一些是敏感的 你不能问 你问了我也不好回答 在这里我就不详细做的解释 我们举个例子 有中东问题 在中东这些国家 你有一些很多的禁忌问题 你问我 我也不会回答你 你问任何人 它其实是不好回答的 那这种禁忌问题 其实是要在这个 Agent 过滤掉 而不是让 Agent 随便给一个答案 因为毕竟它是一个大模型的推理 它有可能按照自己的理解 去回答这问题 第三个 内容是否需要兜底 兜底的场景就是 其实就有点接近于我这个紧急情况 你很难遇到员工会有一个什么样的问题 比如说他问了一个问题说 我发现有一处地方有火灾了 那么这个问题其实在亚马逊 内部也是一样的 这种问题不会让一个 AI 去回答这种问题 你也不能够让一个 AI 回答这个问题 这种问题就是典型的需要兜底 最后就是回答是不是可用 这就是一个更复杂 更深层 更深层次的问题 就是我们构建这个问答机器人 它实际上到底有没有解决员工的问题 到底是我们做了一个给老板看的东西 还是说真正服务于员工的东西 在这里其实是有一套逻辑和方法论的 在我们的实践经验里面 在这个地方可以去采用 比如说我们有那种对话的评分机制 就是并不是单纯地说 当然有一个前提就是在做这样的业绩的时候 你可以有一个用户反馈 比如说竖大拇指或者向下的点大拇指 这样的方式给他说好或者说不好 但更重要的是你有没有科学的方式 亚马逊有两部分公开的论文 专门去分享过 是公开的论文 就是专门分享过 亚马逊在做对话类的机器人的时候 如何去评估一个对话机器人 他回答到底是不是有效的 这个大家如果有兴趣的话 也可以搜索一下 那个就是亚马逊的 HR 的研发团队 自己研究出来的成果 非常有意思 那个报告 他就是会把对话 就是我跟你说多轮对话 他首先会评估你把对话按 Turn 一问一答 一问一答 然后拆解开 拆解开以后会评估你每轮 Turn 每个对话他的目的是什么 他到底想问什么 然后再从你的答案里面再去分析 这个答案到底有没有解决 他这人的对话的目标 然后解决度是多少 在解决度的情况下 他还会再做一轮分析 就是你所有的回答里面是不是有幻觉 是不是基于我如果是一个政策类的 我是不是能跟我的所有的文档联系起来的 这样一个回答 这个是一个非常科学的体系 在这里就不详细的说那套东西 大家如果有兴趣可以再往上搜一下 那是公开的论文 那么我们回到内容保护这个方面去 刚才提到了几点 就是说用户的输入 其实是不能够去随随便便的去响应的 所以我们在用户输入的时候 会去有一些政策去控制它 包括在这里就是我们的模型 模型推理平台上 其实是带了这种 Guardrails 进行内容保护的 这样当用户输入的时候 我们会去通过这样自动的一个 类似于路由的机制 它会去检查 你这里面会不会有禁止的话题 涉不涉及到有一些敏感的内容 以及有一些敏感词的过滤 还有敏感信息的过滤 这样这个是用来保护我们的 HR 的 Agent 以及保护我们整个团队的 如果过滤能够通过的话 它会给出一个最终的答案 OK 后面的话我们给大家分享 下面的话主要是最后 就是我们看一看怎么样就开始 其实我们在选择 HR 场景的时候 刚才有分享过几个 无论是请假 销假 或者是说做政策问答 或者是做人才盘点 这就涉及到一个场景的一个选择 其实比较推荐的一个做法是 我们首先去梳理高频用户场景 那么高频的用户场景 往往会能够带来明确的 ROI 这样的 ROI 会让我们的领导层 更容易去决策一件事做 还是不做 第二个就是 如果我们想要去服务于 HRBP 的时候 我们 BP 现在坦率说国内的企业的 BP 都是工作强度非常大的 它一方面要做好 HR 本身的事情 第二方面还要尽可能的 帮助业务团队去赋能 帮他们业务做得更好 那么核心点在于 它有大量的数据分析请求的时候 AI 应用的请求的时候 我们怎么样去大幅的帮它减少时间 不要让它做得那么累 最后最重要的是数据和权限 这个是我们 HR 做相关系统的一个 底层的基石 另外任何的数据的不安全和不可控 都会带来一个灾难 举个例子来说 刚才的这个一个请假的 Agent 如果我们的请假系统 没有一个很好的权限控制的时候 我们不建议去做一个请假的 Agent 这个可能会带来一场灾难 OK 今天分享到这里 谢谢大家