ToB企服应用市场:ToB评测及商务社交产业平台

标题: GenAI 客户支持 - 第 2 部分：构建知识库 [打印本页]

---

作者: 守听    时间: 2024-9-13 20:26
标题: GenAI 客户支持 - 第 2 部分：构建知识库
作者：来自 Elastic Cory Mangini

本系列博文揭示了我们的现场工程团队怎样使用 Elastic Stack 和生成式 AI 开发出一款可爱又高效的客户支持谈天机器人。如果你错过了本系列的第一篇博文，可以在此处找到。

检索增强生成 (RAG) 优于精细调整模子

作为工程团队，我们知道 Elastic 客户需要信任基于 AI 的生成式支持助手来提供准确且相关的答案。我们最初的概念验证表明，大型语言模子 (LLM) 基础训练不敷以满足 Elastic 如许技术深度和广泛的技术需求。我们探索了为支持助手微调我们自己的模子，但出于多种原因，我们最终采用了基于 RAG 的方法。

• 处理非结构化数据更轻易：微调需要问答配对，这与我们的数据集不匹配，而且在我们的数据规模下很难做到。
  
• 实时更新：通过访问最新文档立刻整合新信息，确保相应最新且相关。
  
• 基于脚色的访问控制：跨脚色的单一用户体验根据允许的访问级别限定特定文档或泉源。
  
• 维护更少：支持中心和支持助手上的搜索共享许多相同的底层基础架构。我们通过相同的工作努力改进了搜索结果和谈天机器人。
  

将支持助手理解为一个搜索标题

然后我们形成了一个假设，推动了支持助手的技术开发和测试。
   提供更简洁、更相关的搜索结果作为 LLM 的配景，将最大限度地减少模子使用不相关信息回答用户标题标机会，从而产生更强烈的积极用户情绪。
  

为了查验我们团队的假设，我们必须在搜索的配景下重新构建我们对谈天机器人的理解。将支持谈天机器人视为图书管理员。图书管理员可以访问大量册本（通过搜索），并且天生就了解（LLM）广泛的主题。当被问到标题时，图书管理员大概可以大概根据自己的知识回答，但大概需要找到得当的册本来解决有关深层范畴知识的标题。
搜索扩展了 “图书管理员” 以亘古未有的方式查找书中段落的能力。杜威十进制分类法（Dewey Decimal Classification）实现了可搜索的册本索引。个人电脑发展成为具有有限文本搜索的更好目次。通过 Elasticsearch + Lucene 的 RAG 不但可以在整个图书馆的册本中找到关键段落，还可以为用户综合答案，通常只需不到一分钟。该体系具有无限的可扩展性，因为通过向图书馆添加更多册本，拥有回答给定标题所需知识的机会更大。
用户输入的语言、提示和温度等设置（随机度）仍然很重要，但我们发现我们可以使用搜索作为一种理解用户意图的方式，并更好地增强传递给大型语言模子的上下文，以提高用户满足度。

Elastic Support 的知识库

我们为搜索和 Elastic Support Assistant 提取的知识体系取决于三个关键活动：我们的支持工程师撰写的技术支持文章、我们收罗的产品文档和博客，以及丰富服务，这增长了我们混合搜索方法中每个文档的搜索相关性。
还需要注意的是，用户标题标答案通常来自多个文档中的特定段落。这是我们选择提供支持助手的重要原因。用户在多个文档中的特定段落中找到答案需要付出巨大的努力。通过提取这些信息并将其发送到大型语言模子，我们既节流了用户的时间，又以易于理解的自然语言返回答案。

技术支持文章

Elastic Support 遵循以知识为中心的服务方法，支持工程师记录他们对案例的解决方案和见解，以便我们的知识库（内部和外部）每天都在增长。这完全在后端的 Elasticsearch 和前端的 EUI Markdown 编辑器控件上运行，是 Elastic Support Assistant 的关键信息泉源之一。
我们为 Support Assistant 所做的大部分工作是启用语义搜索，以便我们可以使用 ELSER。我们之前的架构有两种单独的知识文章存储方法。一种是用于面向客户的文章的 Swiftype 实例，另一种是通过 Elastic Appsearch 存储内部支持团队文章。这是我们工程团队的技术债务，因为 Elasticsearch 已经为我们需要的几个功能带来了划一结果。
我们的新架构使用文档级安全性来从单个索引源启用基于脚色的访问。根据 Elastic Support Assistant 用户的不同，我们可以检索适合他们使用的文档，作为发送给 OpenAI 的上下文的一部分。这可以根据需要在未来扩展到新脚色。
偶然，我们还需要为支持团队解释外部文章的信息。为了满足这一需求，我们开发了一个名为 private context 的 EUI 插件。它会在文章中查找以文本块开头的多行 private context 标签，使用正则表达式解析它们以查找 private context 块，然后将它们处理为称为 AST 节点（范例为 privateContext）的特殊事物。

1. {private-context}
2. Notes written here only appear to the Support team.
3. This might also include internal Links (e.g. GitHub or Case number)
4. {private-context}

复制代码

这些变化的结果产生了一个索引，我们可以使用该索引与 ELSER 一起进行语义搜索，并根据用户的脚色对信息进行过细的访问。

我们实行了多次索引迁移，从而为两种用例生成了单个文档结构。每个文档包罗四大类字段。通过将元数据和文章内容存储在同一个 JSON 文档中，我们可以根据需要高效地使用不同的字段。
对于支持助手中的混合搜索方法，我们使用 title 和 summary 字段进行语义搜索，并在更大的 content 字段上使用 BM25。这使支持助手既能快速搜索，又能与我们将作为上下文传递给 OpenAI GPT 的文本高度相关。

提取产品文档、博客和搜索实验室内容

尽管我们的技术支持知识库有超过 2,800 篇文章，但我们知道有些标题这些文章无法解答 Elastic 支持助手的用户标题。例如：What new features would be available if I upgraded from Elastic Cloud 8.11 to 8.14? 不会出如今技术支持文章中，因为这不是一个故障修复标题，也不会出如今 OpenAI 模子中，因为 8.14 已经过了模子训练日期截止日期。
我们选择通过包罗更多官方 Elastic 泉源（例如所有版本的产品文档、Elastic 博客、搜索/安全/可观察性实验室和 Elastic 入门指南）作为语义搜索实现的泉源（类似于此示例）来解决这个标题。通过使用语义搜索在相关时检索这些文档，我们使支持助手可以大概回答更广泛的标题。
提取过程包括数十万份文档，并处理跨 Elastic 属性的复杂站点舆图。我们选择使用名为 Crawlee 的抓取和自动化库来处理保持知识库最新所需的规模和频率。
四个爬虫作业中的每一个都在 Google Cloud Run 上实行。我们之以是选择如许做，是因为作业的超时时间为 24 小时，并且可以在不使用 Cloud Tasks 或 PubSub 的环境下安排它们。我们的需求导致统共有四个作业并行运行，每个作业都有一个可以捕获特定种别文档的基本 URL。在抓取网站时，我们建议从没有重叠内容的基本 URL 开始，以制止提取重复项。这必须与在过高的级别抓取和提取对你的知识存储无用的文档保持平衡。例如，我们抓取 https://elastic.com/blog 和 https://www.elastic.co/search-labs/blog 而不是 elastic.co/，因为我们的目标是技术文档。

即使有了准确的基本 URL，我们也需要考虑 Elastic 产品文档的不同版本（我们的知识库中有 114 个重要/次要版本）。首先，我们为产品页面构建了目次，以便加载和缓存产品的不同版本。我们的技术堆栈是 Typescript 与 Node.js 以及 Elastic 的 EUI 的组合，用于前端组件。

1. export const fetchTableOfContents = async (currentUrl: string) => {
2.   const tocUrl = currentUrl.replace(/\/current\/.*$/, '/current/toc.html');
4.   const response = await fetch(tocUrl, {
5.     headers: { Authorization: ELASTIC_CO_AUTH_HEADER },
6.   });
8.   if (!response.ok) {
9.     throw new Error(
10.       `Failed to fetch [${tocUrl}] with status [${response.status}]`
11.     );
12.   }
14.   const dom = new JSDOM(await response.text());
16.   return dom.window.document;
17. };

复制代码

然后，我们加载产品页面的目次并缓存产品的版本。如果产品版本已缓存，则该函数将不实行任何操作。如果产品版本未缓存，则该函数还会将产品页面的所有版本参加队列，以便它可以抓取产品文档的所有版本。

哀求处理程序

由于我们抓取的文档结构大概千差万别，我们为每种文档范例创建了一个哀求处理程序。哀求处理程序告诉抓取工具将哪个 CSS 解析为文档主体。这为我们存储在 Elasticsearch 中的文档创建了划一性，并捕获了相关的文本。这对于我们的 RAG 方法尤其重要，因为任何填充文本也是可搜索的，并且大概会因我们发送给 LLM 的上下文而错误地返回。
此策略的一个风险是，如果维护网络空间的团队对 css 选择器进行了未经关照的更改，则抓取工具将返回内容的 null 结果。因此，提取是我们使用支持助手的可观察性策略监控的一个范畴。本系列反面的第 5 篇博客将先容这一点。

博客哀求处理程序

此示例是我们最直接的哀求处理程序。我们指定爬虫程序应查找与提供的参数匹配的 div 元素。该 div 内的任何文本都将被提取为生成的 Elasticsearch 文档的内容。

1. const body =
3. document.querySelector('div.title-text-one-column.container')
5. ?.textContent ?? '';

复制代码

产品文档哀求处理程序

在此产品文档示例中，多个 css 选择器包罗我们想要提取的文本，为每个选择器提供了一个大概性列表。这些匹配参数中的一个或多个中的文本将包罗在生成的文档中。

1. const body =
3.      // the ',' is an "OR" condition for different variations of the selector
6.      document.querySelector(
9.        '#preamble div.sectionbody, #content div.part, #content div.section, #content div.chapter'
12.      )?.textContent ?? '';

复制代码

爬虫还允许我们配置和发送授权标头（header），以防止它被拒绝访问所有 Elastic 产品文档版本的页面。由于我们需要预测支持助手的用户大概会扣问任何版本的 Elastic，因此捕获充足的文档以表明每个版本中的细微差异至关重要。产品文档确实有一些重复的内容，因为给定的页面大概不会在多个产品版本中更改。我们通过微调搜索查询来处理这个标题，除非用户尚有指定，否则默以为最新的产品文档。第四篇博客将详细先容这一点。

丰富文档泉源

Elastic 的整个知识库包罗超过 300,000 份文档。这些文档的元数据范例千差万别，乃至根本没有。这就需要我们丰富这些文档，以便搜索可以大概容纳针对这些文档的更大范围的用户标题。在这种规模下，团队需要使丰富文档的过程自动化、简单化，并且可以大概填充现有文档并在创建新文档时按需运行。我们选择使用 Elastic 作为向量数据库，并启用 ELSER 来支持我们的语义搜索，并使用生成式人工智能来填补元数据空白。

ELSER

Elastic ELSER（Elastic Learned Sparse Embedding Retrieval）通过将 Elastic 文档转换为增强搜索相关性和准确性的丰富嵌入来丰富 Elastic 文档。这种先进的嵌入机制使用机器学习来理解数据中的上下文关系，超越了传统的基于关键字的搜索方法。这种转换允许更快地检索相关信息，即使是从像我们如许的大型复杂数据会集检索。
ELSER 之以是成为我们团队的明确选择，是因为它易于设置。我们下载并部署了模子，创建了摄取管道并重新索引了我们的数据。结果是丰富的文档。
怎样安装和运行支持诊断故障清除实用程序是一篇流行的技术支持文章。ELSER 计算了 title 和 summary 的向量数据库嵌入，因为我们将它们与语义搜索一起使用作为混合搜索方法的一部分。结果存储在 Elastic 文档中作为 ml 字段。

怎样安装和运行的向量嵌入...

ml 字段中的嵌入存储为关键字和向量对。发出搜索查询时，它也会转换为嵌入。嵌入接近查询嵌入的文档被视为相关文档，并会进行检索和排名。以下示例是 title 字段 “How to install and run the support diagnostics troubleshooting utility” 的 ELSER 嵌入的样子 。虽然下面只显示了 title，但该字段还将包罗 summary 的所有向量嵌入。

1. "content_title_expanded": {
2.       "predicted_value": {
3.         "software": 0.61586595,
4.         "run": 0.9742636,
5.         "microsoft": 0.3588995,
6.         "utilities": 0.12577513,
7.         "quest": 0.3432038,
8.         "required": 0.092967816,
9.         "patch": 0.027755933,
10.         "download": 0.17489636,
11.         "problem": 0.18334787,
12.         "tab": 0.23204291,
13.         "should": 0.16826244,
14.         "connection": 0.022697305,
15.         "diagnostic": 1.9365064,
16.         "issue": 0.5547295,
17.         "test": 0.29294458,
18.         "diagnosis": 0.5534036,
19.         "check": 0.5284877,
20.         "version": 0.30520722,
21.         "tool": 1.0934049,
22.         "script": 0.1992606,
23.         "driver": 0.38722745,
24.         "install": 1.1497828,
25.         "phone": 0.04624318,
26.         "reset": 0.005169715,
27.         "support": 2.2761922,
28.         "repair": 0.010929011,
29.         "utility": 1.5231297,
30.         "update": 0.54428,
31.         "troubles": 0.71636456,
32.         "manual": 0.5289214,
33.         "virus": 0.33769864,
34.         "tools": 0.32632887,
35.         "network": 0.44589242,
36.         "button": 0.57999945,
37.         "administrator": 0.49048838,
38.         "patient": 0.09216453,
39.         "installation": 0.43931308,
40.         "##hoot": 1.3843145,
41.         "supporting": 0.06898438,
42.         "deployment": 0.17549558,
43.         "detection": 0.0026870596,
44.         "manager": 0.1197038,
45.         "probe": 0.19564733,
46.         "suite": 0.31462,
47.         "service": 0.47528896,
48.         "report": 0.12370042,
49.         "setup": 0.91139555,
50.         "assist": 0.008046827,
51.         "step": 1.1416973,
52.         "window": 0.17856373,
53.         "outlook": 0.03414659,
54.         "supported": 0.45036858,
55.         "customer": 0.2380667
56.       }
57.     }

复制代码

摘要和标题

语义搜索的有效性取决于文档摘要的质量。我们的技术支持文章有由支持工程师编写的摘要，但我们提取的其他文档没有。考虑到我们提取的知识规模，我们需要一个自动化流程来生成这些摘要。最简单的方法是提取每个文档的前 280 个字符并将其用作摘要。我们对此进行了测试，发现这会导致搜索相关性较差。
我们团队的一位工程师想出了一个主意，改用人工智能来做这件事。我们创建了一项新服务，使用 OpenAI GPT3.5 Turbo 来增补我们所有在提取时缺少摘要的文档。将来，我们打算测试其他模子的输出，以找出我们大概在最终摘要中看到的改进。由于我们有一个 GPT3.5 Turbo 的私有实例，我们选择使用它来在所需的规模下保持低本钱。
服务自己很简单，是找到并微调有效提示（prompt）的结果。提示为大型语言模子提供了一组总体方向，然后为每个任务提供了一组特定的方向子集。虽然更复杂，但这使我们可以大概创建一个 Cloud Run 作业，该作业循环遍历我们知识库中的每个文档。循环在转到下一个文档之前实行以下任务。

• 使用提示和文档 content 字段中的文本向 LLM 发送 API 调用。
  
• 等待完成的相应（或妥善处理任何错误）。
  
• 更新文档中的 summary 和 questions 字段。
  
• 运行下一个文档。
  

Cloud Run 允许我们控制并发工作者的数量，如许我们就不会使用分配给我们的 LLM 实例的所有线程。如许做会导致支持助手的任何用户超时，因此我们选择在几周内增补现有的知识库 —— 从最新的产品文档开始。

创建总体摘要

提示的这一部分输出尽大概简洁的摘要，同时仍保持准确性。我们通过要求 LLM 多次检查其生成的文本并根据源文档检查其准确性来实现这一点。指示了特定的指导方针，以便每个文档的输出都划一。用一篇文章亲身实验这个提示，看看它可以生成什么样的结果。然后更改一个或多个指导方针并在新的谈天中运行提示，以观察输出的差异。

1. const promptsByGenerationStrategy = {
3. [GenerationStrategy.AbstractiveSummarizer]: `
5. For \`generate[ì]\`, you will generate increasingly concise, entity-dense summaries of \`data\`, considering content fields only,respecting the instructions in \`generate[i].prompt\` definition and the meaning of target \`generate[i].name\` field.
7. Repeat the following 2 steps 3 times.
8. Step 1. Identify 1-3 informative entities (";" delimited) from the article which are missing from the previously generated summary.
9. Step 2. Write a new, denser summary of identical length which covers every entity and detail from the previous summary plus the missing entities.
11. A missing entity is:
12. - relevant to the main story,
13. - specific yet concise (5 words or fewer),
14. - novel (not in the previous summary),
15. - faithful (present in the article),
16. - anywhere (can be located anywhere in the article).
18. Guidelines:
19. - The first summary should be long yet highly non-specific, containing little information beyond the entities marked as missing. Use overly verbose language and fillers (e.g., "this article discusses") to reach ~80 words.
20. - Make every word count: rewrite the previous summary to improve flow and make space for additional entities.
21. - Make space with fusion, compression, and removal of uninformative phrases like "the article discusses".
22. - The summaries should become highly dense and concise yet self-contained, i.e., easily understood without the article.
23. - Missing entities can appear anywhere in the new summary.
24. - Never drop entities from the previous summary. If space cannot be made, add fewer new entities.
27. Output: \`generatedField[i]\` with the resulting string.
28. `,

复制代码

创建第二个摘要范例

我们创建第二个摘要，使我们可以大概搜索代表文章的整个文本的特定段落。在此用例中，我们实验保持更接近文档中已有的关键句子的输出。

1. [GenerationStrategy.ExtractiveSummarizer]: `
4.    For \`generate[ì]\`, you will generate a summary with key sentences from the article that cover the main topics.
7. `,

复制代码

创建一组相关标题

除了摘要之外，我们还要求 GPT 生成一组与文档相关的标题。这将以多种方式使用，包括为用户提供基于语义搜索的建议。我们还在测试将标题集纳入 Elastic Support Assistant 的混合搜索方法的相关性，以便我们搜索标题、摘要、正文内容和标题集。

1. [GenerationStrategy.QuestionSummarizer]: `
3. For \`generate[ì]\`, you will generate a key-term dense list of questions covering most subjects that \`data\` can answer with confidence.
4. - Each individual question must be complete and specific, always containing the related subjects.
5. - Don't explicit the existence of \`data\` in any way within the question (e.g. "Does the document provide...", "Does the article have...").
6. - Cover different levels of abstraction/specificity.
7. - Make versions explcit whenever suitable.
8. - Consider content fields only.
9. - Format: \`\${Q1}? \${Q2}?...? \${QN}?\`.
10. - Respect the instructions in \`generate[i].prompt\` definition and the meaning of target \`generate[i].name\` field.
12. Output: \`generatedField[i]\` with the resulting string.
13. `,

复制代码

支持助理演示

尽管后端运行了大量任务和查询，但我们仍选择保持谈天界面自己的简单易用。乐成的支持助理将顺畅地工作并提供用户可以信任的专业知识。我们的 alpha 版本如下所示。

重要学习要点

构建我们当前知识库的过程并非一帆风顺。作为一个团队，我们每天都会测试新的假设，并观察我们的支持助理用户的行为以了解他们的需求。我们经常将代码推送到生产环境并权衡其影响，以便我们可以大概制止出现小故障，而不是功能和项目级别的故障。​​
   更小、更准确的上下文使 LLM 相应更具确定性。
  我们最初将较大的文本段落作为用户标题标上下文。这低落了结果的准确性，因为大型语言模子通常会忽略关键句子而选择那些没有回答标题标句子。这使得搜索变成了一个标题，既要找到准确的文档，又要找到这些文档怎样与用户标题相匹配。
   RBAC 策略对于管理特定脚色可以访问的数据至关重要。文档级安全性减少了我们的基础办法重复，低落了部署本钱并简化了我们需要运行的查询。
  作为一个团队，我们很早就意识到我们的技术债务会拦阻我们为支持助手提供令人喜好的体验。我们与产品工程师密切互助，并订定了使用最新 Elastic 功能的蓝图。我们将撰写一篇关于从 Swiftype 和 Appsearch 过渡的深入博客，以详细说明这一经验。敬请等待！
   一个搜索查询无法涵盖用户标题标埋伏范围。有关此内容的更多信息，请参阅第 4 部分（RAG 谈天机器人的搜索和相关性调整）。
  我们测量了用户对回复的情绪，并学会了更有效地解读用户意图。实际上，用户标题背后的搜索标题是什么？
   了解用户搜索的内容对于我们丰富数据起着关键作用。
  即使文档规模达到数十万份，我们仍然会发现记录知识中存在差距。通过分析用户趋势，我们可以确定何时添加新范例的泉源，并更好地丰富现有数据，以便我们将来自多个泉源的上下文打包在一起，以供 LLM 进一步阐述。

下一步是什么？

在撰写本文时，我们已经为索引中的 300,000 多个文档和超过 128,000 个人工智能生成的摘要建立了向量嵌入，平均每个文档有 8 个标题。考虑到我们只有约 8,000 篇带有人工撰写摘要的技术支持文章，这对我们的语义搜索结果来说是 10 倍的改进。
Field Engineering 有一个门路图，其中列出了扩展我们的知识库的新方法，并扩展了我们的显式搜索界面和 Elastic Support Assistant 在技术上的大概性。例如，我们计划为技术图表创建收罗和搜索策略，并为 Elastic 员工收罗 Github 标题。
创建知识源只是我们与 Elastic Support Assistant 互助的第一步。请在此处的第一篇博客中阅读有关我们最初的 GenAI 实验的信息。在第三篇博客中，我们深入探究了用户体验的设计和实施。随后，我们的第四篇博客将揭示我们调整搜索相关性的策略，以便为 LLM 提供最佳配景。请继承关注，获取更多关于你自己的生成式 AI 项目标见解和灵感！
准备好自己实验了吗？开始免费试用。
想要获得 Elastic 认证？了解下一期 Elasticsearch 工程师培训何时开始！

原文：GenAI for Customer Support with Elastic ELSER — Search Labs

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4