Salesforce Einstein Copilot：企业生成式人工智能的最佳案例

Salesforce 公司我就不多做介绍了，最早的以及最成功的 SaaS 公司，CRM 产品的领导者，低代码平台的领导者， 以及随着这些年的并购，比如 Mulesoft、Tableau、Slack，已经成为软件行业中当之无愧的巨头了。

Salesforce Einstein Copilot

今年上半年，Salesforce 公司的 CRM 的对话式 AI 助手 Einstein Copilot 已经全面上市。

在生成式人工智能 (GenAI) 的支持下，Einstein Copilot 是集成到每个 Salesforce 应用程序中的对话助手。

特点

Einstein Copilot 提供值得信赖的响应， 因为它以公司独特的数据和元数据为基础，使其能够深入了解您的业务和客户关系。

Einstein Copilot 原生嵌入 Salesforce 应用程序中，提供一致的用户体验， 可以：

• • 回答问题、

• • 生成内容、

• • 并动态地自动执行任何操作，

从而提高工作效率、建立更深层次的客户关系并提高利润。

上面有两个关键点，一个是元数据，一个是原生，这是我为什么经常说虽然 AI 一直在蓬勃发展， 但是 企业应用中的 AI 应用一直没什么出彩的地方，这两个月参加 AWS、阿里云等一些公司的开门或闭门会议， 都有大量篇幅在 AI 上，但是实际的应用中亮点几乎没有，很多还在讨论 Text2SQL 上面。

Text2SQL 的伪命题

去年我就说 Text2SQL 是个伪命题，拿来玩可以，但是在企业中面向普通用户的使用场景，有很多先天的不足。

第一个问题就是不可控，不准确性、复杂场景更加不可控，当然经过微调和训练把这方面的能力近乎无上限的提升。

第二个问题就是权限和业务逻辑。去年和阿里云一个 Text 2 SQL 的团队聊的时候，他们想推广到企业去使用， 但是数据权限这个问题并没有考虑过，当然也没有计划和方案。只是想着一些自然语言提问、结果和报表生成这些很酷的事儿。

当人第二问题也能解决，直接而生硬的方法就是 SQL 的执行层加上权限一层，执行前动态的修改 SQL 来进行赋权， 很多企业的权限引擎也是这样实现的。

既然上面我提到的两个问题，都有解决方案能解决，那为啥我还说他是一个伪命题？

因为很别扭，Text 2 SQL 的功能不适合面向应用的最终用户，更适合面向产品和技术人员。从产品和技术的双重架构上来看，这个方案不合理，所以做这个功能本身就得不偿失，

那么在数据层面，GenAI 没有用了么？当然不是，上面提到的「元数据」就是答案，面向元数据的解决方案才是正儿八经的方案。当然 Salesforce 的应用不至于数据处理，基于其庞大的应用平台能力，他可以让其AI原生化，这是一般没有平台的软件很难做到的。

元数据怎么用在 数据层面解决 Text 2 SQL 这类问题呢，其实很简单，把 Text 2 SQL 替换成如下：

• • Text 2 MetaData

• • Text 2 API

• • Text 2 DSL

• • Text 2 Metrics

• • Text 2 ...

只要不是面向底层 SQL，你的方案大概率是可以的，而且是通用的，跨数据库的。

SQL生成新思路：函数 RAG 和智能工具扩展)

Einstein Copilot 功能

跑题跑回来，我们继续聊 Einstein Copilot，看看他提供了哪些能力，先不谈概念型的东西，看看他具体「原生」 了哪些操作。

• • 通过名称识别数据记录。比如「显示联系人张三。」

• • 通过名称识别对象。比如「列出账户李四的所有销售机会。」

• • 查询记录。比如「按创建日期排序，查找本季度结束的所有开放机会。」

• • 使用聚合查询记录。比如「过去 5 天内创建了多少个机会？」

• • 总结记录。比如「为xxx交易创建摘要」

• • 起草或修改电子邮件。比如「帮我写一封介绍电子邮件给 Acme 的史蒂夫。」

• • 使用知识回答问题。比如「30 天以上的退货政策是什么？」

除了这些最基本的，爱因斯坦 Copilot 还支持创建自定义操作（调用服务类、启动流程等）。

自定义操作就能让AI 有更多的行为，释放更强大的能力，比如如下操作：

• • 获取订单详情。

• • 发起订单退货。

• • 提出产品推荐。

• • 检查库存水平。

• • 创建和修改发票。

• • 图书销售会议。

• • 衡量顾客情绪。

• • 创建营销材料。

• • 记录内部 IT 票证。

Einstein Copilot 是当前企业应用中比较比较「原生」的两个 Copilot 之一，另一个是微软 Azure 云的助手。

Prompt Builder

给大家看一下 Prompt Builder，这个和其他的 Prompt Builder 类似，不过和应用平台融合在一起添加业务基本模型的支持。

Salesforce 提供了很方便的模板能力，你可以自己里面快速插入字段。这样在 Prompt 的执行过程里面，就可以使用真实的业务数据和 LLM 进行交互。

Prompt 编辑框里面可以看到已经有四个替换好的字段了（彩色粗体），不同的颜色表示不同的对象来源。

我们可以在上方选择资源类型（当前对象、当前用户、流 等），然后选择具体的字段即可插入到提示语编辑框里面：

在下方的关联记录里面搜索记录，选定一条然后点击「预览」，可以看到当前提示语的效果（输入和输出）：

配置这部分就没什么特别的，选择「标准模型」或者「自定义模型」，以及具体的模型型号（比如 OpenAI GPT 4）：

Prompt 的使用

写好的提示语，其中一个应用场景就是赋值给字段，我们暂且称之为 GenAI 的字段，配置好之后，你打开对应表单的时候就能看到字段旁边有一个「魔法棒」 图标：

点击图标，系统直接执行 提示语，生成结果输出。

点击使用按钮，可以迅速看到字段复制结果。

Action 的使用

上文提到，Einstein Copilot 还支持自定义操作，我们简单看一下大致过程（使用官方提供的教程）。

SalesForce 提供了自己特色的 Copilot Builder，可以开发调试 Copilot：

给 Copilot 添加自定义操作的时候，你可以在 Apex、Flow、和 提示词模板三个选项里面选择一个，

并选择一个具体的指令（这里用系统创建好的「退货流程」）：

编写对应的指令、输入、输出以及必要的选项就可以了。

好不客气的说，Einstein Copilot 的交互和功能就是大多企业应用使用 AI 的标准方式（当然，对于时候我们不需要那么强大的后台配置能力）。

在应用里面我们就可以打开助手，查找订单、查看订单详情：

点击对应的单号打开订单，然后直接发起退货流程。

安全和可信

Salesforce 说「信任」是他们 GenAI 的基础，所以在应用中做了很多东西来保证数据安全， 比如「用完就忘」等等。

不过对于小企业的话看看就好，大家可能没有能力构建完善的安全层。

不同场景和角色

最后提一下，Salesforce 对于不同的应用、场景、用户都做了人工智能的支持。

比如有 销售的AI、客户服务的AI、市场人员的AI、电商的AI，都是在上面我们讲的 Einstein Copilot 框架里面对具体业务的应用。

最后

Salesforce 2023 年的时候我关注到更多的是他们关于编码的模型等基础 GenAI 能力，一年不见没想到，他们已经在应用端把 AI 的能力真正发挥了出来。

当然，Salesforce 的成功不是偶然，很大程度上依赖了处于领先地位的 CRM 产品，以及其 aPaaS 平台。我之前也说，企业应用 AI 没有好的土壤，很大原因就是产品本身就不够好，很难想象一块发育不良的果树上能硕果累累， 应外就是平台能力的确实，不少企业应用本身还是停留在应用和产品上，这个对于 C 端的产品没问题，但是对 B 端产品来说就不够看了，灵活性和扩展性不足。