使用亚马逊云构建企业智能知识问答助手第一篇 之 架构演进

背景

企业智能知识问答助手或称 Chatbot，是许多企业常用的内部应用程序，用于提供客户服务、人力资源服务，业务流程自动化等。早期 Chatbot 普遍缺乏人工智能，仅能按预定义的对话流程进行交互，这大大增加了内容维护人员的工作量，也难以灵活应对客户的问题。自然语言处理技术的进步显著提升了 Chatbot 理解语义的能力，减少了人工定义对话流程的需求，提高了回答的灵活性。近年来，大语言模型（LLM）的出现极大增强了 Chatbot 的能力，无论是回复生成的便捷性还是对话自然度都得到显著改善。LLM 支持的 Chatbot 可以进行开放域的对话，并生成更加类人的回复，满足更复杂，更个性化的用户需求。总体而言，人工智能尤其是 LLM 的应用使 Chatbot 服务更加智能化，为企业内部应用带来更高的效率和价值。Chatbot 与企业内部数据，LLM 带来的自然语言理解和生成技术的深度结合，会优化企业内部服务和支持，实现更高水平的自动化。

没有大规模预训练的大语言模型 Chatbot 通常有以下弱点：

• 通常需要大量手工工作来整理问题和答案的 QA 库以进行精确匹配，其可以接入的知识来源也受限。
• 此类 Chatbot 没有语义理解和上下文感知能力，需要用户输入完整且精确的问题以被正确理解，
• 其回答也往往是预设的，因此难以对不精确的问题做出符合语境的回答。

相比之下，集成了 LLM 的 Chatbot 可以进行更好的语义解析和上下文推理，无需依赖精确的规则匹配，能够生成更加人类化、适合语境的回复。

本文将通过一个在亚马逊云上构建企业智能知识问答助手的真实客户案例，来介绍它的技术架构是如何随着需求的变化和自然语言处理技术的进步而逐步演进的。本篇也是一个系列博客的开始，后续还将继续为您介绍诸如如何针对 Knowledge Base 类型文章提高问答准确率，如何针对长文档问答的需求提高准确率，以及源数据的权限管理和数据同步等内容。

需求演化

企业智能知识问答助手，从传统 100% 匹配开始，演化到基于 Bert 模型的更符合自然语言的问法的相似度匹配，再到基于 LLM 进行更灵活的问答的体验。随着技术的发展，LLM 能力的加强和对 LLM 的控制能力加强，Chatbot 的需求也从解放提供问答的人工，到解放数据整理人工。其提供的应用技术体验也从按照设定的路线触发到相似度匹配，从按照设定的答案回答到更加人性化的回答。在 Chatbot 的发展历程中主要分为三个阶段：

• 第一阶段：基于关键词匹配的 Chatbot
• 第二阶段：基于 Bert 语义理解的 FAQ Chatbot
• 第三阶段：基于 LLM 的企业知识大脑

第一阶段，基于关键词匹配的 Chatbot

这种 Chatbot 往往需要以下几类数据：

• 触发词：用于定义何时当前内容会被展示出来。
• 答案：问题被触发之后的答案展示。
• 问题细化引导：当需要进一步询问客户，进行问题细化的时候，需要对问题进行进一步细分。如：计算服务，具体请选择 EC2/ Lambda/ Fargate 等，需要细化问题，提供不同答案。

这种模式有两个弊端：

• 需要数据提供方提供大量且准确的数据，并且将其很好的组织起来，用来做隔离，做梳理，这带来了很大的数据准备的人工的工作量。
• 其触发模式也比较固定，在大多数的场景下，不能直接抛出对应的答案，需要再进行多次选择方能拿到最终的答案。

第二阶段：基于 Bert 语义理解的 FAQ Chatbot

这种 Chatbot 相比第一阶段有诸多优势：

• 利用了 NLP 模型进行了相似语义匹配，使得匹配的行为更加灵活。 该模式可以直接根据问题进行语义相似度匹配，所以不用进行多次点击从而得到最终答案。
• 对数据的准备要求也更为轻量化，不需要再进行数据的整体触发逻辑分析，只需要单纯进行 QA 的问题准备即可，触发的控制和准备完全交给模型进行控制。

这种 Chatbot 模式中的架构图如下：

本阶段主要由三部分组成：

• Teams APP 集成与服务端：
  • 与 Teams 集成：当前项目选择 Teams 作为前端提问的流量入口，所以需要在 Teams 集成 Chatbot 客户端。为了优化在 Teams 平台上的开发工作流程，我们选择采用 Bot Service 框架进行 Bot 构建。该框架提供了一套完整的解决方案，包括 Bot 注册和管理模块、用户会话和个人对话管理模块、消息收发控制模块，以及前端 UI 组件渲染和事件处理模块。 通过利用 Bot Service 框架，我们可以轻松地构建符合 Teams 规范的 Bot 应用程序，并与 Teams 平台进行无缝集成。框架的模块化设计使得我们能够专注于业务逻辑的实现，而将底层的技术细节封装在框架内部，大大提高了开发效率。 此外，Bot Service 框架还提供了丰富的扩展性，允许我们根据具体需求定制和扩展框架的功能，以满足特定的业务场景。总的来说，使用 Bot Service 框架进行 Teams Bot 开发是一种高效、灵活的方式，可以帮助我们快速构建出高质量的企业级应用程序。
  • 服务端： EKS 集群。负责接收来自前端的用户请求，并通过负载均衡策略将请求转发至后端的 EKS 集群中的实例。集群中主要包括：和 Teams 实现频道对接 ，进行消息状态同步，消息传递等，用户历史对接，用户对话追踪功能实现，用 bot framework SDK 进行更丰富的对话管理功能，在组织内部进行 bot 发布和管理等。EKS 集群中的应用程序组件主要包括：1）Microsoft Teams 通道集成模块，实现与 Teams 平台的双向通信，包括接收和发送消息、同步消息状态等功能。 2）用户历史记录持久化模块，负责存储和检索用户与 Bot 的对话历史记录。 3）对话管理引擎，基于 Bot Framework SDK，提供对话上下文跟踪、自然语言理解、对话流程控制等高级功能。 4）Bot 发布和生命周期管理模块，允许在企业内部发布、更新和维护 Bot 应用程序。
• FAQ 数据的存储与搜索
  • 向量化数据存储。向量化数据存储模块旨在提供对向量数据类型及其相关元数据的持久化存储和高效检索能力。在本系统中，我们选择采用 Amazon OpenSearch Service 作为向量数据库的底层存储和检索引擎。Amazon OpenSearch 是亚马逊云端的托管型服务，基于开源的 ElasticSearch 分布式搜索和分析引擎构建。它支持向量相似度查询等高级数据处理功能。借助 Amazon OpenSearch 的强大能力，我们的向量化数据存储模块能够高效地存储和管理大规模的向量嵌入数据（Vector Embeddings），将向量数据与结构化元数据相关联，并提供基于向量相似度的语义检索功能。 确保了系统能够适应未来数据量和查询复杂度的持续增长，同时最大限度地利用了云端的弹性资源管理优势，为构建智能化的向量搜索和推理应用奠定了坚实的基础。FAQ 知识库数据通过 OmniML 平台的数据接入模块上传至 Amazon DynamoDB 数据库进行临时存储。随后，OmniML 平台的数据处理管线将对上传的数据执行提取、转换和加载（ETL）操作，并通过预定义的数据更新流程将处理后的 FAQ 数据持久化写入 Amazon OpenSearch 集群中。
  • 基于Amazon SageMaker 搭建的 Embedding 模型。基于 Amazon SageMaker 搭建的 Embedding 模型提供了将自然语言转化为向量的能力。基于 Amazon SageMaker 搭建的模型可以对外以 API 的形式提供接口，便于上下游应用程序及服务进行调用。我们基于 Amazon SageMaker 机器学习平台训练了自然语言模型，该模型能够将自然语言文本映射到对应的向量表示。 该 embedding 模型经过在 Amazon SageMaker 平台上的训练和优化，可以更为准确地将任意长度的文本序列转化为固定维度的向量，这是实现语义相似度计算、语义搜索等智能应用的基础。 我们将训练好的嵌入模型部署在 Amazon SageMaker 的托管实时推理环境中，并通过 Amazon API Gateway 为其构建了 RESTful API 端点，使其可以对外以服务的形式被上下游应用程序和服务调用。通过这种无服务器架构，我们实现了嵌入模型的弹性伸缩和高可用，同时降低了基础设施的运维成本。上游应用可以通过简单的 HTTP 请求向嵌入模型 API 发送原始文本，并接收对应的向量表示，而无需关注底层机器学习模型的具体实现细节。这种解耦设计大大简化了应用程序与机器学习模型的集成复杂度，提高了开发效率。本项目中，该模型会被数据更新 pipeline 所调用，实现 Amazon OpenSearch Service 数据库中的数据更新。
  • OmniML 平台。ChatBot 的运维过程包含以下几个关键环节：1. 数据运维：涉及各个业务部门对于知识库 FAQ 数据的持续维护和更新,确保知识内容的准确性、完整性和时效性。2. 数据同步：实现从前端可视化 FAQ 编辑界面到向量数据库的无缝数据同步，保证知识库的高效更新。这通常涉及数据处理流水线、ETL pipeline 等。3. 系统监控：包括但不限于 ChatBot 响应准确率监控、系统健康状态监控、日志收集和分析等,以确保系统的稳定高效运行。4. 应用发布与测试：新版本 ChatBot 应用的内测、发布上线等，保证产品的不断迭代优化。OmniML 是一个由亚马逊云科技专业服务团队开发的构建在多个亚马逊云服务之上的平台软件，也经由这个项目最终打包成了一个标准的可对接多种企业内部聊天工具的机器学习服务平台，OmniML 提供了一站式的 AI 运维解决方案，其中的可视化界面、工作流编排、监控预警等组件可以极大简化 ChatBot 的运维流程，提高运维效率，降低运维成本。

• BI Dashboard

• • 为了在系统上线后持续监控和优化用户体验，我们在基于 Teams 的前端界面中集成了用户反馈收集机制。 具体而言，我们开发了正赞和倒赞两种用户交互逻辑，允许用户针对特定的聊天内容或系统响应进行实时的正向反馈。这些用户反馈将通过自定义的 Bot Framework 活动被捕获和上报，并最终持久化存储到我们的用户反馈数据存储中。 通过分析和挖掘这些结构化的用户反馈数据，我们能够洞察用户在实际使用场景中的感受和体验，从而持续优化对话模型、改善自然语言理解能力、完善知识库内容等，不断提升系统的可用性和智能水平。

在前端 Teams 客户端中，用户点击”正赞”或”倒赞”按钮后，将触发一个 HTTP 请求被发送到我们的 Amazon EKS 集群。集群中的应用程序负责将该用户反馈事件持久化存储到 Amazon DynamoDB 数据库的用户反馈表中。

为了对存储在 Amazon DynamoDB 中的用户反馈数据进行分析和可视化，我们使用 Amazon Athena 对 DynamoDB 表执行 SQL 查询。Athena 是一种交互式查询服务，能够直接从数据源（如 DynamoDB）中提取数据。查询的结果集将被用作 Amazon QuickSight 的数据源，在 Amazon QuickSight 的仪表板中以可视化的形式呈现，提供用户反馈分析的洞见。 该架构充分利用了亚马逊云科技云原生服务的功能，实现了从用户交互到数据分析的端到端流程。前端 Teams 应用与后端 EKS 集群、DynamoDB 和 Athena 等云服务的无缝集成，确保了用户反馈数据的高效采集，可靠存储和灵活分析，为我们的产品优化和决策提供了数据驱动的支持。同时，该设计具有很强的伸缩性和可维护性，能够适应日益增长的用户量和数据量。

第三阶段：基于 LLM 的企业知识大脑

基于大型语言模型（LLM）构建的企业级知识大脑系统。相比于传统的基于规则或机器学习的自然语言处理（NLP）方法，LLM 赋予了 Chatbot 卓越的自然语言理解、生成和推理能力，显著增强了其处理复杂查询、领域外问题和长文本的性能，从而极大拓展了企业内部 Chatbot 的应用场景。 该知识大脑系统采用了检索增强生成（Retrieval-Augmented Generation，RAG）的架构理念，并遵循下一代智能搜索和知识库解决方案的最佳实践指南，将第二阶段基于 BERT 语义理解模型的 FAQ Chatbot 系统的核心功能模块（如数据存储、管理、查询和模型托管等）融合其中。 在知识源方面，由于 LLM 擅长处理长格式文本，我们将企业内部广泛使用的 Confluence 文档协作平台和 SharePoint 文档管理系统等作为重要数据源纳入，使知识大脑能够直接检索和利用这些标准化的企业知识资产。 通过对 LLM 的引入，结合 RAG 架构和现有组件的集成，我们的企业知识大脑系统实现了语义理解、知识检索和自然语言生成的有机结合，为企业用户提供了一站式的智能知识服务，提升了工作效率和决策质量。

本阶段的架构主要由六个主要部分组成，除了和第二阶段相同的 Teams APP 集成与服务端，FAQ 数据的存储与搜索，BI Dashboard 三个部分，额外增加了 Confluence 数据搜索接入，多路召回和重排，基于 Amazon SageMaker 搭建的大语言模型进行内容生成 三个部分。同时功能上新增了多语言集成功能，能够根据语种进行召回过滤和针对该语种的回复。

Confluence 数据注入部分：通过 Amazon CloudWatch 定时触发 Lambda 将 Confluence space 中的相关页面元数据和页面内容信息读取到 Amazon DynamoDB 中，再经过 pipeline 同步到 Amazon OpenSearch 数据库中。数据召回部分：包含根据向量相似度的相似语义召回和基于关键词的 BM 2.5 召回，再经过重排得到最后的排序结果。LLM 生成部分：根据召回结果，根据语言选择合适的 PE 再经由大模型生成相关答案。

• • 多路召回和重排

多路找回新增加了基于 Amazon OpenSearch BM2.5 的关键词召回结果，以适应关键词更为重要的问题场景。在某些特定的搜索场景下，单一的检索策略可能无法完全满足用户的需求。以地名作为搜索关键词的情况为例，基于 BM25 算法的关键词匹配搜索往往比纯粹依赖于语义匹配的结果更加精准。 为了适应多样化的搜索需求并提供更加精准的匹配结果，我们引入了多路召回的策略。具体来说，系统会同时执行 BM25 算法的关键词匹配检索和基于语义的 embedding 的基于向量的余弦距离搜索方式相似度检索，分别得到两个不同的初始结果集。随后，通过特定的重排序机制，对这两个结果集进行融合，生成综合的最终排序结果，从而更好地匹配用户的查询意图。该策略的优势在于，它结合了多种检索模型的长处，有效克服了单一模型的局限性，提高了搜索质量的平稳性和鲁棒性。同时，通过可配置的重排序规则，能够灵活适配不同的搜索场景，进一步提升了整体的检索效果。在基于第二阶段的 embedding 模型基础之上新增的召回结果的 Rerank 模型，更好地对召回回来的内容进行清洗和管控，避免不相关的语句进入召回结果，减少 LLM 的 output 有相关噪音的幻视结论的可能。Rerank 模型可以将多路召回的结果进行最终的融合，给出自己的相关性建议。

• • Confluence 数据的搜索接入

为了更好的管理需要纳入知识库回答范围的新的文章，我们利用企业内部常用的文章知识管理平台进行内容的对接。相比单纯的文章上传解析，对接专业的文档知识库能更好地用 API 的形式读取相关内容和文章元数据，并且专业文档库通常自带权限管理系统，我们可以利用文档库自身的权限管理系统进行权限控制的对接，使得 LLM 输出的内容符合本身平台对用户的内容限制标准。本项目中采用，Confluence 自带的 API 可以便于内容的读取和文章元数据的读取，Confluence 自带的文章权限编辑管理功能可以便于系统对接，用户可以直接在 Confluence 上进行用户和空间权限的设置，并且 Chatbot 应用程序可以利用 API 进行相关内容的读取，对大模型的内容输出相关内容和权限的控制。

• • • 基于 Confluence 的内容同步对接机制

基于亚马逊云科技云原生服务，我们构建了一个自动化的知识库内容同步系统，实现 Confluence 知识库与 OpenSearch 搜索引擎之间的同步更新。 该系统的核心流程如下：1. CloudWatch 事件驱动：基于 Amazon CloudWatch Events 的时间调度功能，定期触发一个 Amazon Lambda 函数执行。 2. Confluence 内容差异判断：Lambda 函数通过调用 Confluence API，获取知识库内容的元数据变更信息，识别出本次同步周期内有更新的文章列表。 3. 数据处理流水线：对有更新的文章，启动 Data update Pipeline 执行数据更新流程，从 Confluence 提取原始内容，进行必要的数据清洗和格式转换，最终将处理后的文章内容更新到 OpenSearch 集群中。 4. 搜索引擎刷新：随着 OpenSearch 集群中的数据实时更新，新的知识库内容将自动纳入后续的搜索服务范畴。

• • • 和 FAQ 数据源的逻辑集成

为了更好地和第二阶段进行集成补充，新增和 FAQ 数据源的集成逻辑部分。阶段三是对阶段二的能力补充，所以其需要和基于 FAQ 的回答有逻辑集成需要。对于不同业务场景和不同 BU 来说，对于一些严肃的场景，其对回答的质量和精确度要求较高，对回答的话术和回答规范都有一定要求，这种情况下应首先进行 FAQ 匹配，在 FAQ 里确切没有相关答案的时候才走到 LLM 回答的路线上，保证精确回答的概率。基于这样的使用场景，我们设计了回答思路，根据不同的问题其对于 FAQ 和文章内容的匹配程度进行分别回答，FAQ 存储对回答内容和精确度都有要求的问题答案，进行优先匹配，匹配不成则进入 LLM 的匹配逻辑中。在 LLM 的答案生成中，为了尽可能地满足答案生成准确度的要求和标准，我们也对 LLM 的生成过程进行了优化，具体优化流程请参考这个系列中的第二篇文章《使用亚马逊云构建企业智能知识问答助手第二篇 之 提升问答准确率的优化实践》。

• • 基于 Amazon SageMaker 托管的大语言模型进行内容生成

基于 Amazon SageMaker 搭建的大语言模型在企业内部云环境进行私有化部署。将 LLM 的能力集成在企业内部环境中，便于企业应用程序安全可靠调用。本项目中，该模型使用 Lambda + API Gateway 进行封装，API 的形式提供对外能力暴露。

• • 多语言的集成

在一些企业场景下，需要根据不同国家地区的内容进行分割，以便更好的匹配符合当地政策和当地公司的信息。在这种需求场景下，我们设计了根据语言类型进行内容分割的机制。在提问的时候首先检测用户的提问语言品种，在相同语言的语种下进行相似度搜索进行召回。在本项目中我们选择 lingua-language-detector 进行语言语种的检测，在 FAQ 编辑和数据同步时，和 Confluence 的数据同步 pipeline 中也引入该库进行语言语种的检测，便于在召回时进行筛选。检测语言语种有多种不同的方法，LLM 或者字符判断方法都是可选择的种类，但是在实际应用中，考虑到精确度和延迟要求，我们选择了库的形式进行语言的检测，可以最大化精确度和最小化加入此环节带来的延迟影响。

第三阶段是基于第二阶段进行的 LLM 能力的加持，在逻辑结合上需结合 FAQ 直接回答答案的场景，并且满足答案和召回对语言的过滤要求，和 LLM 基于知识库回答答案的灵活性需求，因此需要在不同的召回结果上，满足精确度、语言，速度的要求。因此设计了以下业务流程图：

第一，优先匹配满足 FAQ 中固有经过审核的答案的搜索需求。

第二，通过召回过滤满足语言一致性的需求。

第三，对接 LLM 通过召回和语言检测，生成对应语言的答案。

总结

通过对 Chatbot 产品的持续优化和迭代，我们清晰地看到了先进技术在企业应用中的巨大价值体现。人工智能技术的应用显著降低了人力成本，减轻了员工的基础数据维护工作量。与此同时，基于大型语言模型的自然语言生成能力也极大提升了 Chatbot 响应的灵活性和多样性，使其能够满足更加多元化的用户查询场景。 我们的 Chatbot 系统采用了传统的自然语言处理（NLP）模型与大型语言模型的有机融合架构。传统 NLP 模型（如 BERT）为语义理解提供了强大的能力，而 LLM 则赋予了系统生成高质量自然语言响应的能力。两者的结合充分发挥了各自的优势，实现了高精度的查询理解与高质量的响应生成，全面提升了用户体验。 该架构的灵活性还体现在知识源的扩展性上。我们不仅整合了传统的知识库数据，还将企业内部的文档协作平台（如 Confluence）和文档管理系统（如 SharePoint）作为重要的知识源纳入，使 Chatbot 能够基于上下文语义从海量非结构化数据中检索相关知识碎片，并生成连贯、信息丰富的自然语言响应。 总的来说，人工智能技术在我们的 Chatbot 产品中的创新应用，实现了智能化与智能化的有机融合，为企业用户带来了显著的工作效率提升和价值创造，也为企业级人工智能系统的落地应用提供了一个成功范例。该系列 blog 后续还将继续为您介绍诸如如何针对 Knowledge Base 类型文章提高问答准确率，如何针对长文档问答的需求提高准确率，以及源数据的权限管理和数据同步等内容。

本篇作者