作者：来自 Elastic Chris Blaisure

欢迎来到 Inside Elastic 博客系列，我们将展示 Elastic 的内部运营如何解决实际业务挑战。本系列将揭示我们将生成式 AI（gererative AI - GenAI）集成到客户成功和支持运营中的历程，让你了解我们流程的幕后情况。我们在构建此功能的同时，也在博客中介绍它，我们很高兴你能加入我们的行列！

生成式人工智能：下一个前沿

OpenAI 的生成式人工智能工具于 2022 年底推出，为人工智能生成内容开辟了无限可能。企业领导者迅速寻求利用这项技术应对其独特挑战的方法。在听到 Elastic 领导者提出以下问题后，我们的客户成功和支持团队的运营尤其如此：

• 生成式人工智能如何提高客户支持效率和效力？
• 生成式人工智能如何增强客户体验和满意度？
• 生成式人工智能如何与现有的客户支持系统和流程集成？
• 生成式人工智能如何帮助自动执行重复性任务并腾出支持代理的时间进行更复杂和战略性的活动？

负责定制内部工具的现场工程团队开始研究生成式人工智能，并在场外开会集思广益，探讨潜在的应用。鉴于我们是 Elastic，我们了解我们产品的搜索功能以及我们如何集成到更大的人工智能技术堆栈中。然而，仅靠技术并不能回答上述任何问题。

在讨论生成式 AI 的可能性时，我们确定了两种支持工作流程，我们认为这两种工作流程可以使我们的内部团队受益，从而让我们的客户受益：

• 自动案例摘要：我们的支持工程师花费大量时间提供案例摘要，以便升级或将案例从一位工程师转移到另一位工程师。我们的假设是，我们可以使用生成式 AI 来自动化此过程，并提高我们支持团队的效率和效力，改善问题解决率，并提高整体客户满意度。
• 起草初步答复：服务水平协议是我们支持服务的主要优势，确保及时响应至关重要。我们不确定大型语言模型 (LLM) 是否足够智能，可以提供准确、相关的响应，但我们确信，从此过程中获得的经验对于决定下一个用例至关重要。

有了这一决定，我们决定构建一个可扩展的概念验证，使我们能够为部分用户实施这些工作流程，同时包括用于评估和改进质量的反馈机制。

构建反馈概念验证

就背景而言，我们的现场工程团队已在 Google Cloud Platform 之上构建了我们系统的基础设施，并使用 Salesforce Service Cloud 为我们的案例管理提供支持。这种现有设置使我们可以直接将初始概念验证与 Vertex AI 集成，Vertex AI 已在内部启用并符合我们的安全和隐私政策。

当然，我们知道 Elastic 将在我们的设计中发挥作用（后续博客将谈到这一点），但在这个初始阶段，我们专注于 LLM 本身并将生成文本应用于概述的工作流程。第一个架构如下所示：

创建案例摘要

从总体上讲，我们希望保持自动化的简单性。我们要求 CRM 团队在所有案例上添加一个自定义按钮，该按钮将调用外部端点。该外部端点是一个 Google Cloud Function，它执行以下操作：

1. 该函数接受 Salesforce 唯一案例 ID 作为输入，并以文本形式检索案例详细信息。

2. 然后，检索到的文本将与以下工程提示一起自动发送到 Vertex AI：

Write the summary of the following customer agent conversation in a paragraph? \Considering the conversation below, what are the pending actions by the Agent? Keep the response short.\Use only the information from the conversation below:"""${text}"""Provide the answers in the dictionary format : {Summary:[], Pending Actions:[]}`;

3. AI 生成的回复通过 Salesforce Chatter Post 发布到案件中。

基本上就是这样！唯一的例外是长期案件，我们必须将文本分解为摘要的摘要。一旦我们确定了设计，我们就会在一个星期内完成并运行。

自动生成草稿初始回复

虽然比案例摘要稍微复杂一些，但自动生成回复以供我们的支持工程师审查相对简单。我们利用现有的自动化功能处理所有新创建的案例，并调用新的 Google Pub/Sub 队列来分别处理所有传入请求。Pub/Sub 执行以下任务：

1. 它将案例 ID 存储在队列中，以便在资源可用时使用。

2. 在执行时，它将案例 ID 传递给另一个 Google Cloud Function，该函数将仅提取客户的初始请求作为文本。

3. 然后，检索到的文本将与以下工程提示一起自动发送到 Vertex AI：

You are an expert Elastic Support Engineer, using only Elastic products, provide a \response with resolution to this email by a customer:"""${text}"""`;

4. AI 生成的回复通过 Salesforce Chatter Post 发布到案例中。

同样，这是一种简单的方法来获取初始草稿回复，该回复可扩展到我们正在查看的案例子集。 这花了我们几天时间来修改现有代码和附加的 Pub/Sub 功能，大约花了两周时间完成。

使用 Vertex AI 作为我们这个概念验证的 LLM 是一个轻松的决定。 我们知道我们有很多与 LLM 准确性相关的事情需要考虑（见下文），但将其与我们现有的基础设施连接起来的便利性使这个过程更快。 与搜索非常相似，AI 生成的回复的相关性是一个更深入的对话，我们知道我们接下来会解决这个问题。

获取用户反馈

前面提到的 Salesforce Chatter 帖子的示例：

在草稿回复和案例摘要这两个用例中，决定使用 Salesforce Chatter 来提供 AI 生成的文本是基于这样的想法：我们可以使用标准的 Chatter 功能来 “点赞” 以识别积极情绪，并使用线程响应来获取主观反馈。这是流程中的关键步骤，减少了反馈循环中的摩擦，因为用户可以在同一个操作系统中处理案例并提供反馈。

有更复杂的技术可用于评估 LLM 准确性，尤其是当 Elasticsearch 提供上下文时。尽管如此，我们还是故意避免进行概念验证，因为我们的数据量是可管理的，而且我们希望审查每一条评论。

客观评估结果并做出决策

Days Open	44
Generated Content	940
Feedback	217
Positive Sentiment	15.67%

最初的用户反馈产生了约 16% 的积极回应率，低于预期。查看主观反馈后发现，LLM 缺乏对我们产品的深入了解，这阻碍了其解决技术支持查询的能力。该模型在通用摘要和不需要特定产品知识的响应方面表现更好。这凸显了内容方面的差距，因为 LLM 是在公共数据上进行训练的，缺乏对关键数据源（如我们的产品文档和内部知识库文章）的访问权限。

根据这些数据，我们决定添加两个新的设计原则：

• 优化输入数据：我们认识到需要更明确的输入体验，以便向 LLM 提供更清晰、更直接的问题，从而提高响应质量。这相当于数据工程中的 “垃圾进，垃圾出”说法。
• 设置更高的准确度/情绪阈值：技术支持需要高精度，因此我们的目标是 >80% 的基准，并开发了系统来衡量和提高各个阶段的准确性。

在这些原则的指导下，我们决定最佳体验是将这些和所有其他潜在功能整合到统一的聊天界面中。这应该有助于以一致的方式管理输入，以实现更好的工作流程和响应。此外，我们知道下一次演进需要包括 Elasticsearch，以通过检索增强生成架构提高响应准确性。这应该使我们能够大规模评估准确性并显著提高我们响应的准确性。

解决业务问题

基于这种数据支持的理解，我们了解大型语言模型如何响应我们的特定工作流程，并决定将解决方案集成到聊天机器人中，我们重新审视了业务领导提出的问题：

• 生成式人工智能如何提高客户支持的效率和效果？
  • 我们相信我们可以构建一个自助式聊天机器人体验，以回答与支持相关的产品问题。支持代理使用聊天机器人将加快他们的分析和调查速度，从而减少平均解决问题的时间。此外，新加入者可以从聊天机器人而不是团队的其他成员那里学习。这可以减少入职时间，并为目前正在回答这些问题的现有团队成员创造能力。
• 生成式人工智能如何增强客户体验和满意度？
  • 与数千家支持组织合作的技术服务行业协会 (TSIA) 经过多年的研究，证实客户更喜欢自助服务而不是辅助支持。展示类似的自助聊天机器人可以提高用户体验和客户满意度，因为实时、相关的响应可以将客户响应时间缩短至几毫秒，并且不需要阅读大量文档。
• 如何将生成式人工智能与现有的客户支持系统和流程集成？
  • 我们才华横溢的开发人员团队可以在客户提出这些问题时轻松将聊天体验集成到我们的自定义支持门户中，并利用 Elasticsearch 进行知识内容搜索。
• 生成式人工智能如何帮助自动执行重复性任务并释放支持代理（support agent）的时间以进行更复杂和更具战略性的活动？
  • 支持代理不断搜索产品文档、内部支持内容和知识文章以寻找答案。自然语言聊天是这些搜索活动的演变，它提供上下文相关的响应，而不是推荐要阅读的信息。仅在搜索时间上获得的效率就将释放支持代理的时间以进行其他增值战略活动。

经过几个月的数据收集，我们向利益相关者展示了基于聊天的支持 AI 助理的发现、设计和计划，根据上述结果进行了调整，并从概念验证转向了已获批准的项目。

我们的客户和社区是我们所做的一切的核心。在构建任何内部或外部体验时，我们始终将客户放在第一位。投资于这一过程使我们能够制定明智的计划并加以执行，始终将客户放在首位。

下一步是什么？

我们的现场工程团队现在专注于开发可扩展、安全且准确的支持 AI 聊天助手。本博客系列将继续定期更新，每期都会重点介绍我们构建过程的不同方面。请继续关注更多见解和灵感，以用于你自己的生成 AI 项目。

先睹为快我们当前的架构：

接下来阅读：生产中的 RAG：使你的生成式 AI 项目投入运营。

本文中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。

在这篇博文中，我们可能使用或提及了第三方生成式 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制第三方工具，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害承担任何责任。在使用 AI 工具处理个人、敏感或机密信息时，请谨慎行事。你提交的任何数据都可能用于 AI 培训或其他目的。我们无法保证你提供的信息将得到安全或保密。在使用任何生成式 AI 工具之前，你应该熟悉其隐私惯例和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文：GenAI for customer support — Part 1: Building our proof of concept | Elastic Blog