如何 Deltek 利用 Amazon Bedrock 在政府招标文件中进行问答 机器学习博客

Deltek如何利用Amazon Bedrock在政府招标文件上的问答

关键要点

本篇文章将讨论Deltek如何通过Amazon Bedrock构建问答系统，以处理政府招标文件。文章中将介绍此解决方案的背景、主要挑战和解决方案的细节，包括数据摄取和问答的过程。此外，我们还将提供相关资源和建议信息，以帮助读者更深入了解这一前沿技术。

问答QampA是一种用于客户支持聊天机器人、法律研究助理和医疗顾问等多种场景的常见应用。近年来，检索增强生成RAG法作为一种主流方法，利用大型语言模型LLMs的强大功能与文档进行自然语言交互。

本文将概述AWS生成AI创新中心GenAIIC为Deltek全球公认的项目型企业标准开发的定制解决方案。Deltek为超过30000个客户提供行业特定的软件和信息解决方案，专注于政府合同和专业服务领域。

在本次合作中，AWS GenAIIC团队为Deltek创建了一种基于RAG的解决方案，使其能够进行针对单个或多个政府招标文件的问答。该解决方案使用了包括Amazon Textract、Amazon OpenSearch Service和Amazon Bedrock等AWS服务。Amazon Bedrock是一项完全托管的服务，提供来自亚马逊及其他顶尖人工智能公司如AI21 Labs、Anthropic、Cohere、Meta和Stability AI的一系列高性能基础模型FMs和LLMs，用户可以通过单一API访问，构建具有安全性、隐私性和负责任AI的生成AI应用。

Deltek正在不断改进此解决方案，以更好地满足其特定需求，例如支持除PDF以外的文件格式，并实施更具成本效益的数据摄取管道。

什么是RAG？

RAG是一个优化LLMs输出的过程，允许它们在生成响应之前参考外部的权威知识库。此方法解决了与LLMs相关的某些挑战，例如呈现错误、过时或一般性的信息，或由于术语混淆而导致的产生不准确响应的问题。RAG通过交叉参考组织的内部知识库或特定领域，使LLMs能够生成更相关、准确和上下文相关的响应，而无需重新训练模型。这为组织提供了对生成文本输出更大的控制，同时使用户能够了解LLM如何生成响应，从而提升了LLMs在多种情境下的能力，并且是一种成本效益高的方案。

主要挑战

对单个文档应用RAG进行问答相对直观，但在多个相关文档之间应用同样的办法则面临独特的挑战。例如，当使用问答在随着时间推移而演变的文档上时，如果问题涉及到随着时间变化的发展概念，考虑文档的时间顺序至关重要。不考虑这个顺序可能会导致提供一个在过去某个时间点是准确的答案，但基于最新信息而言，现在已经过时。妥善处理时间相关的方面是在将问答从单个文档扩展到多个相互关联的文档集合时面临的关键挑战。

解决方案概述

本文将以两个时间相关的文档为示例，描述问答的过程：一个长的草案请求提案RFP文档，以及一个相关的后续政府回应RFI响应，提供了额外和修订的信息。

解决方案的RAG方法分为两个步骤。

第一步是数据摄取，如下图所示。这包括对PDF文档的单次处理。该应用程序组件是一个用户界面，带有一些小的处理功能，例如分割文本和在后台调用服务。具体步骤如下：

用户将文档上传至应用程序。应用程序使用Amazon Textract从输入文档中提取文本和表格。文本嵌入模型处理文本块并为每个文本块生成嵌入向量。这些文本块的嵌入表示以及相关元数据被索引到OpenSearch Service。

第二步是问答，如下图所示。在此步骤中，用户对已摄取的文档提出一个问题，并期望得到自然语言的响应。应用程序组件同样是一个用户界面，具有一些小的处理功能，例如在后台调用不同的服务。具体步骤如下：

用户提出一个关于文档的问题。应用程序从文本中检索输入问题的嵌入表示。应用程序将从OpenSearch Service检索到的数据和查询传递给Amazon Bedrock以生成响应。模型执行语义搜索以找到文档中的相关文本块也称为上下文。嵌入向量将问题从文本映射到数值表示的空间。问题和上下文结合在一起，然后作为提示输入LLM。语言模型生成用户问题的自然语言响应。

我们在解决方案中使用了Amazon Textract，这可以将PDF、PNG、JPEG和TIFF转换为机器可读文本。它还有效地格式化复杂结构，例如表格，以便于分析。在后续部分中，我们将提供一个示例，以展示Amazon Textract的能力。

OpenSearch是一个开源的分布式搜索和分析套件，来源于Elasticsearch。它使用向量数据库结构来有效存储和查询大量数据。OpenSearch Service目前拥有数万活跃客户，超过数十万的集群在管理中，每月处理数百兆请求。我们使用OpenSearch Service及其底层向量数据库做以下操作：

梯子加速将文档索引到向量空间，使相关项能更紧密地靠近，从而提高相关性。在问答步骤中，通过近似最近邻搜索快速检索相关的文档块。

OpenSearch Service中的向量数据库使得相关数据块的高效存储和快速检索成为可能，以支持我们的问答系统。通过将文档建模为向量，我们能够找到相关段落，即使没有明确的关键词匹配。

文本嵌入模型是将文本中的单词或短语映射到密集向量表示的机器学习ML模型。文本嵌入通常用于信息检索系统，例如RAG，以下是几种用途：

文档嵌入 嵌入模型用于编码文档内容并将其映射到嵌入空间。通常，首先将文档拆分为较小的块，例如段落、章节或固定大小的块。查询嵌入 用户查询被嵌入为向量，以便通过进行语义搜索与文档块进行匹配。

在此篇文章中，我们使用了Amazon Titan模型，该模型的Amazon Titan Embeddings G1 Text v12能够处理高达8000个tokens，并输出一个1536维的数值向量。该模型通过Amazon Bedrock提供。

Amazon Bedrock提供来自顶尖AI公司的现成FMs，诸如AI21 Labs、Anthropic、Cohere、Meta、Stability AI和Amazon。它提供了统一接口来访问这些模型并构建生成AI应用，同时保持隐私和安全。我们使用了Anthropic Claude v2在Amazon Bedrock上生成自然语言回答，针对问题和上下文。

在后面的章节中，我们将更详细地探讨解决方案的两个阶段。

数据摄取

首先，草案RFP和RFI响应文件被处理，以备在问答时使用。数据摄取包括以下步骤：

文档传递至Amazon Textract进行文本转换。

为了更好地让我们的语言模型回答有关表格的问题，我们创建了一个解析器，将Amazon Textract输出的表格转换为CSV格式。将表格转化为CSV提高了模型的理解能力。例如，以下图形展示了一个RFI响应文档部分的PDF格式，然后是对应提取出的文本。在提取的文本中，表格已经转换为CSV格式，置于文本的其余部分之间。

对于长文档，提取的文本可能超过LLM的输入大小限制。在这样的情况下，我们可以将文本划分为较小的、重叠的块。块的大小和重叠比例可能会根据使用案例有所不同。我们应用了基于部分的切块在每个文档部分独立执行切块，之后在本文的示例用例中将对此进行探讨。

有些文档可能遵循标准布局或格式。可以利用这种结构优化数据摄取。例如，RFP文档往往有一定的布局，有已定义的部分。利用布局，可以独立处理每份文档的各个部分。如果存在，但不相关的目录，也可以考虑删除。在本文后面，我们将提供关于检测和利用文档结构的示范。从嵌入模型中检索每个文本块的嵌入向量。最后一步是将嵌入向量索引到OpenSearch Service数据库中。除了嵌入向量外，文本块和文档元数据如文档、文档章节名称或文档发布日期也将作为文本字段添加到索引中。文档发布日期是与时间相关的元数据，对于关联的文档非常有用，以便LLM识别出最更新的信息。以下代码片段展示了索引体：

pythonindexbody = { embeddingvector lt文本块的嵌入向量gt textchunk lt文本块gt documentname lt文档名gt sectionname lt文档章节名称gt releasedate lt文档发布日期gt # 可以添加更多元数据}

问答

在问答阶段，用户可以提交一个关于前面步骤中摄取的草案RFP和RFI响应文档的自然语言问题。首先，使用语义搜索来检索与用户问题相关的文本块。然后，将问题与检索的上下文结合，创建提示。最后，将提示发送至Amazon Bedrock，由LLM生成自然语言响应。具体步骤如下：

从Amazon Bedrock的Amazon Titan嵌入模型中提取输入问题的嵌入表示。使用问题的嵌入向量在OpenSearch Service上进行语义搜索，找到前K个相关文本块。以下是一个传递给OpenSearch Service的搜索体示例。有关更多详细信息，请参见OpenSearch文档中关于结构化搜索查询的内容。

pythonsearchbody = { size topK query { scriptscore { query { matchall {} # 跳过全文搜索 } script { lang knn source knnscore params { field embeddingvector queryvalue questionembedding spacetype cosinesimil } } } }}

任何检索到的元数据，诸如章节名称或文档发布日期，均被用来丰富文本块，并为LLM提供更多的信息，例如：

pythondef opensearchresulttocontext(osres dict) gt str 将OpenSearch结果转换为上下文 Args osres (dict) Amazon OpenSearch结果 返回 context (str) 包含在LLM提示中的上下文 data = osres[hits][hits] context = [] for item in data text = item[source][textchunk] docname = item[source][documentname] sectionname = item[source][sectionname] releasedate = item[source][releasedate] contextappend( fltltContextgtgt [文档名称 {docname} 章节名称 {sectionname} 发布日期 {releasedate}] {text} ) context = n n n njoin(context) return context

输入问题与检索的上下文结合，生成提示。在某些情况下，根据问题的复杂性或特定性，可能需要在初始提示中添加额外的思维链CoT提示，以提供更多的澄清和指导。CoT提示的目的是引导LLM理解问题并构建响应所需的逻辑步骤，帮助其理清关键信息，确定需要什么样的回应，并以合适准确的方式构建该回应。我们为该用例使用以下CoT提示：

python上下文以下包含来自草案RFP和RFI响应文档的几段：

上下文 {context}

问题 {question}

请逐步思考：

1 找到上下文中与问题相关的所有段落。2 按发布日期对段落进行排序。3 使用这些段落回答问题。

注意：注意基于发布日期的更新信息。

将提示传递到Amazon Bedrock的LLM，以生成自然语言的响应。我们使用了以下推理配置，适用于Amazon Bedrock上的Anthropic Claude V2模型。温度参数通常设置为零，以确保可重复性并防止模型虚构。对于常规的RAG应用，topk和topp通常分别设置为250和1。将maxtokenstosample设置为预计生成的最大token数量1个token大约等于3/4个单词。有关更多详细信息，请参见推理参数。

python{ temperature 0 topk 250 topp 1 maxtokenstosample 300 stopsequences [nnHumannn]}

示例用例

作为演示，我们描述一个QampA的示例，其中涉及两个相关文档：一个长达167页的草案RFP文档和一个后续发布的6页RF响应文档，该响应文档包含对草案RFP的额外信息和更新。

以下是一个示例问题，询问项目规模的要求是否发生了变化，考虑到草案RFP和RFI响应文档的内容：

“原始评分评估是否发生了变化？如果有，新的项目规模是什么？”

下图显示了草案RFP文档中的相关部分，其中包含答案。

以下图显示了RFI响应文档中的相关部分，其中也包含答案。

为了使LLM生成正确的响应，来自OpenSearch Service的检索上下文必须包含前文提到的表格，并且LLM应能够通过元数据如发布日期推断检索内容的顺序，从而生成可读的自然语言响应。

以下是数据摄取步骤：

草案RFP和RFI响应文档上传到Amazon Textract，以提取文本和表格作为内容。此外，我们使用正则表达式来识别文档章节和目录见下图。由于该用例中的目录没有相关信息，因此可以去除。

我们独立地将每个文档