如今，亚马逊财务运营部门的应付账款 (AP) 和应收账款 (AR) 分析师通过电子邮件、案例、内部工具或电话接收客户的查询。当出现查询时，分析师必须与主题专家 (SME) 联系，并仔细阅读包含与查询相关的标准操作程序 (SOP) 的多个政策文件，这一过程非常耗时。这种来回的沟通过程通常需要几个小时到几天的时间，主要是因为分析师，尤其是新员工，无法立即获得必要的信息。他们花费大量时间咨询中小企业并审查大量政策文件。
为了应对这一挑战，亚马逊财务自动化开发了大语言模型基于法学硕士（LLM）的问答聊天助手亚马逊基岩。该解决方案使分析师能够快速检索客户查询的答案，并在同一通信线程中生成及时响应。因此，它大大减少了解决客户查询所需的时间。
在这篇文章中，我们分享了亚马逊财务自动化如何构建这个生成式人工智能使用 Amazon Bedrock 的问答聊天助手。
解决方案概述
该解决方案基于检索增强生成(RAG) 管道在 Amazon Bedrock 上运行，如下图所示。当用户提交查询时，RAG 首先从知识库中检索相关文档，然后根据检索到的文档生成 LLM 响应。
该解决方案由以下关键组件组成：
- 知识库– 我们使用了亚马逊开放搜索服务作为嵌入文档的向量存储。为了进行绩效评估，我们处理了多个亚马逊财务政策文档并将其索引到知识库中。或者，亚马逊基岩知识库为端到端 RAG 工作流程提供完全托管的支持。我们计划迁移到 Amazon Bedrock 知识库，以消除集群管理并为我们的管道添加可扩展性。
- 嵌入模型– 在撰写本文时，我们正在使用Amazon Titan 多模式嵌入 G1亚马逊基岩上的模型。该模型是在来自亚马逊的大型且独特的数据集和语料库上进行预训练的，根据我们的比较分析，其准确性高于或相当于市场上其他嵌入模型。
- 发电机型号– 我们使用了基础模型(FM) 由 Amazon Bedrock 提供，具有快速提供高度准确答案的平衡能力。
- 多样性排名– 它负责重新排列从向量索引获得的结果，以避免对任何特定文档或部分的偏斜或偏见。
- 迷失在中游– 它负责将最相关的结果有效地分发到提示的顶部和底部，从而最大限度地提高提示内容的影响力。
- 护栏– 我们使用了亚马逊基岩护栏检测个人身份信息 (PII) 并防范即时注入攻击。
- 验证引擎– 从响应中删除 PII 并检查生成的答案是否与检索到的上下文一致。如果没有，它会返回一个硬编码的“我不知道”响应以防止出现幻觉。
- 聊天助手界面– 我们使用以下方式开发了 UI流线型，一个开源 Python 库，用于基于 Web 的应用程序开发机器学习(ML) 用例。
评估 RAG 性能
聊天助手的准确性是亚马逊财务运营最关键的性能指标。在我们构建了聊天助手的第一个版本后，我们通过向聊天助手提交问题来测量机器人响应的准确性。中小企业对 RAG 的回答一一进行人工评估，发现只有 49% 的回答是正确的。这远远低于预期，解决方案需要改进。
然而，手动评估 RAG 是不可持续的，它需要财务运营和工程团队花费数小时的努力。因此，我们采用了以下自动化绩效评估方法：
- 准备测试数据 – 我们构建了一个包含三个数据字段的测试数据集：
问题– 这由来自政策文件的 100 个问题组成，答案来自各种来源，例如政策文件和工程 SOP，涵盖复杂的文本格式，例如嵌入的表格和图像。预期答案– 这些是 Amazon Finance Operations SME 手动标记的答案。生成的答案– 这是机器人生成的答案。
- 自然语言处理分数– 我们使用测试数据集来计算胭脂分数和流星分数。由于这些分数仅使用单词匹配算法而忽略文本的语义，因此它们与 SME 分数不一致。根据我们的分析，与人类评估相比，差异约为 30%。
- 基于LLM的分数– 我们使用 Amazon Bedrock 提供的 FM 来对 RAG 性能进行评分。我们设计了专门的 LLM 提示，通过将生成的答案与预期答案进行比较来评估 RAG 性能。我们生成了一组基于法学硕士的指标，包括准确性、可接受性和事实性，以及代表评估推理的引文。与人工分析相比，这种方法的方差约为 5%，因此我们决定坚持这种评估方法。如果您的 RAG 系统是基于 Amazon Bedrock 知识库构建的，您可以使用新的Amazon Bedrock 知识库的 RAG 评估以法学硕士作为评委来评估检索或检索和生成功能的工具。它提供检索评估指标，例如上下文相关性和上下文覆盖率。它还提供检索和生成评估指标，例如正确性、完整性和有用性，以及负责任的人工智能指标，例如有害性和拒绝回答。
提高RAG管道的准确性
基于上述评估技术，我们重点关注 RAG 流程中的以下几个方面，以提高整体准确性。
添加文档语义分块，将准确性从 49% 提高到 64%
在诊断 RAG 管道中的错误响应后，我们发现 14% 的不准确是由于发送给 LLM 的上下文不完整造成的。这些不完整的上下文最初是由基于固定块大小（例如 512 个标记或 384 个单词）的分段算法生成的，该算法不考虑文档边界，例如章节和段落。
为了解决这个问题，我们使用 QUILL Editor、Amazon Titan Text Embeddings 和 OpenSearch Service 设计了一种新的文档分段方法，具体步骤如下：
- 使用 QUILL 编辑器将非结构化文本转换为结构化 HTML 文档。通过这种方式，HTML 文档保留了将内容划分为逻辑块的文档格式。
- 识别HTML文档的逻辑结构，并根据HTML标签插入分隔符字符串以进行文档分段。
- 使用嵌入模型生成文档块的语义向量表示。
- 根据部分中的重要关键字分配标签，以识别部分之间的逻辑边界。
- 将分段文档的嵌入向量插入 OpenSearch 服务向量存储中。
下图说明了文档检索器拆分工作流程。
在处理文档时，我们遵循特定规则：
- 精确提取文档某个部分的开头和结尾
- 提取章节标题并将其与章节内容准确配对
- 根据各部分中的重要关键字分配标签
- 索引时保留策略中的降价信息
- 在初始版本中从处理中排除图像和表格
通过这种方法，我们可以将 RAG 精度从 49% 提高到 64%。
使用即时工程将准确度从 64% 提高到 76%
快速工程是提高法学硕士成绩的关键技术。我们从项目中了解到，不存在一刀切的快速工程方法；设计特定于任务的提示是最佳实践。我们采用以下方法来增强 Prompt-to-RAG 生成器的有效性：
- 在大约 14% 的案例中，我们发现即使没有从 RAG 检索到相关上下文，法学硕士也会产生反应，从而导致幻觉。在这种情况下，我们设计了提示，并要求法学硕士在没有提供相关上下文的情况下不要生成任何响应。
- 在大约 13% 的案例中，我们收到了用户反馈，称法学硕士的回复过于简短，缺乏完整的背景信息。我们设计了提示，鼓励法学硕士更加全面。
- 我们设计了提示，以便能够为用户生成简洁而详细的答案。
- 我们使用 LLM 提示生成引文，以正确归因用于生成答案的来源。在 UI 中，引文会在 LLM 响应后面列出超链接，用户可以使用这些引文来验证 LLM 表现。
- 我们改进了提示，引入更好的思维链 (CoT) 推理：
- 法学硕士使用内部生成推理的独特特征有助于提高绩效并使响应与人类的连贯性保持一致。由于提示质量、推理请求和模型固有功能之间的相互作用，我们可以优化性能。
- 鼓励 CoT 推理会促使法学硕士考虑对话的背景，从而不易产生幻觉。
- 通过建立在既定上下文的基础上，该模型更有可能生成逻辑上遵循对话叙述的响应，从而减少提供不准确或幻觉答案的机会。
- 我们添加了之前回答过的问题的示例，以建立法学硕士的模式，鼓励 CoT。
然后，我们使用 Amazon Bedrock 提供的 FM 元提示来制作满足上述要求的提示。
以下示例是生成快速摘要和详细答案的提示：
您是一名人工智能助手，可以根据提供的文本上下文帮助回答问题。我会给你一些文档中的段落，然后提出一个问题。您的任务是仅使用给定上下文中的信息为问题提供最佳答案。这是上下文：<上下文>{}</上下文>这是问题：<问题>{}</问题>仔细思考如何利用上下文来回答问题。<思考过程>- 仔细阅读所提供的上下文并分析其中包含的信息- 识别上下文中与回答问题相关的关键信息- 确定上下文是否提供了足够的信息来令人满意地回答问题- 如果没有，只需说明“我不知道，我没有回答这个问题所需的完整背景”问题”- 如果是，请将相关信息综合成简洁的摘要答案- 使用 Markdown 格式将摘要扩展为更详细的答案，使其清晰明了可读的</思考过程>如果您没有足够的上下文来回答问题，请在下面提供您的回答格式：我不知道，我没有回答这个问题所需的完整背景。如果您确实有足够的上下文来回答问题，请按以下格式提供您的回答：#### 快速总结：此处为您的 1-2 句话简明摘要。####详细解答：您的扩展答案位于此处，使用 **粗体**、*斜体* 和项目符号等 Markdown 格式来提高可读性。请记住，最终目标是为问题提供内容丰富、清晰易读的答案仅使用所提供的上下文。让我们开始吧！以下示例是根据生成的答案和检索到的上下文生成引文的提示：
您是一名人工智能助理，专门负责将生成的答案归因于所提供文档中的特定部分。您的任务是确定给定文档中的哪些部分最有可能用于生成所提供的答案。如果您找不到完全匹配的内容，请建议与答案内容密切相关的部分。这是生成的要分析的答案：<生成的答案>{}</生成的答案>以下是各种文档中需要考虑的部分：<部分>{}</节>请仔细阅读生成的答案和提供的部分。在下面的便笺本空间中，集思广益并推理哪些部分与答案最相关：<便笺本></暂存器>确定相关部分后，按以下格式提供输出：**文档名称：** <文档名称> \n**文档链接：** <文档链接> \n**相关部分：** \n- <部分名称 1>- <部分名称 2>- <部分名称 3>不要在最终输出中包含任何额外的解释或推理。只需按照上面指定的格式列出文档名称、链接和相关部分名称即可。助手：通过实施及时的工程方法，我们将 RAG 精度从 64% 提高到 76%。
使用 Amazon Titan 文本嵌入模型将准确性从 76% 提高到 86%
实施文档分割方法后，我们仍然发现检索到的上下文的相关性得分较低（55% - 65%），并且在超过 50% 的情况下，不正确的上下文排在前列。这表明仍有改进的空间。
我们尝试了多种嵌入模型，包括第一方和第三方模型。例如，与 all-mpnet-base-v2 等其他顶级嵌入模型相比，bge-base-en-v1.5 等上下文嵌入模型在上下文检索方面表现更好。我们发现，使用 Amazon Titan Embeddings G1 模型将检索到的上下文的可能性从大约 55-65% 增加到 75-80%，并且 80% 的检索到的上下文具有比以前更高的排名。
最后，通过采用Amazon Titan 文本嵌入 G1模型中，我们将整体准确率从 76% 提高到 86%。
结论
通过使用 RAG 管道和 Amazon Bedrock 上的法学硕士，我们在为 Amazon Finance Automation 开发生成式 AI 问答聊天助手方面取得了显着进展。通过持续评估和迭代改进，我们解决了幻觉、文档摄取问题和上下文检索不准确等挑战。我们的结果显示 RAG 准确度从 49% 显着提高到 86%。
您可以跟随我们的旅程并采用类似的解决方案来解决 RAG 应用程序中的挑战并提高整体性能。
关于作者
索赫布·莫因是亚马逊的软件开发工程师，领导了生成式人工智能聊天机器人的开发。他专门利用生成式人工智能和大数据分析来设计、开发和实施安全、可扩展、创新的解决方案，使财务运营能够提高生产力和自动化。工作之余，索赫布喜欢旅行、打羽毛球和参加国际象棋比赛。
尼廷·阿罗拉是亚马逊财务自动化高级软件开发经理。他在构建关键业务、可扩展、高性能软件方面拥有超过 19 年的经验。Nitin 负责领导财务领域的数据服务、通信、工作管理和多项生成式人工智能计划。在业余时间，他喜欢听音乐和阅读。
白云飞是 AWS 的首席解决方案架构师。云飞拥有 AI/ML、数据科学和分析方面的背景，帮助客户采用 AWS 服务来交付业务成果。他设计的人工智能/机器学习和数据分析解决方案能够克服复杂的技术挑战并推动战略目标。云飞拥有电子电气工程博士学位。工作之余，云飞喜欢读书和音乐。
库马尔·萨廷·高拉夫是 Amazon 经验丰富的软件开发经理，在大数据分析和软件开发方面拥有超过 16 年的专业知识。他带领工程师团队使用 AWS 大数据技术构建产品和服务，为跨不同业务垂直领域的 Amazon Finance Operations 提供关键业务见解。除了工作之外，他还从阅读、旅行和学习国际象棋的策略挑战中找到乐趣。
莫哈克楚格是 Amazon 的软件开发工程师，在利用 AWS 上的生成式 AI 和大数据开发产品方面拥有超过 3 年的经验。他的工作涵盖一系列领域，包括基于 RAG 的 GenAI 聊天机器人和高性能数据协调。除了工作之外，他还从弹钢琴和与乐队一起表演中找到乐趣。
帕斯·巴维什是亚马逊的高级产品经理，在构建有影响力的产品方面拥有 10 多年的经验。他目前领导亚马逊财务自动化的生成式人工智能功能的开发，推动组织内部的创新和效率。作为一名敬业的导师，帕斯喜欢分享他的产品管理知识，并在排球和阅读等活动中找到满足感。