CBRE与AWS利用亚马逊Bedrock进行结构化数据的自然语言查询

关键要点

CBRE与AWS合作，使用Amazon Bedrock开发了一个自定义的自然语言查询环境。该环境支持客户通过自然语言快速查询大量结构化数据，准确率超过95。系统集成了AWS Lambda、Amazon RDS及OpenSearch服务，简化了查询过程。

这篇文章介绍了CBRE与AWS的合作，如何利用亚马逊Bedrock开发一个自然语言查询NLQ环境，帮助客户通过自然语言查询结构化数据。

CBRE是全球最大的商业房地产服务和投资公司，业务遍布100多个国家，拥有13万名专业人士。CBRE正在利用人工智能AI的潜力，为其商业房地产生命周期各个环节创造价值，从投资决策到建筑管理。CBRE的数据环境包含来自300多个来源的390亿个数据点，并结合企业级技术，能够部署多种AI解决方案，提升个人生产力和大规模转型。虽然CBRE为客户提供了精心策划的高级仪表板，但他们希望为客户提供一种通过自然语言提示快速进行自定义数据查询的解决方案。

Amazon Bedrock 是一项完全托管的服务，为用户提供来自领先AI公司的高性能基础模型FMs，如AI21 Labs、Anthropic、Cohere、Meta、Stability AI和亚马逊，通过单一API提供广泛的功能，用于构建生成式AI应用程序，简化开发并保持隐私和安全性。通过Amazon Bedrock的全面能力，用户可以尝试多种基础模型，利用自己的数据进行私有化定制，使用微调和检索增强生成RAG等技术创建管理代理，从旅行预订、保险索赔处理到广告活动创建和库存管理，全程无需编写代码。由于Amazon Bedrock是无服务器的，因此用户无需管理基础设施，可以安全地将生成式AI能力集成到现有应用中。

在这篇文章中，我们描述CBRE如何与AWS原型团队合作，开发一个自定义的查询环境，允许用户使用自然语言查询提示，这一切都是基于Amazon Bedrock、AWS Lambda、Amazon关系数据库服务RDS和Amazon OpenSearch服务。AWS原型团队成功交付了一个可扩展的原型，高度准确率超过95地解决了CBRE的业务问题，并支持对类似NLQ的嵌入重用，以及与CBRE仪表板的集成API网关。

客户使用案例

目前，CBRE管理着一套标准化的高级客户仪表板和报告，这些仪表板由各种商业智能BI工具如Tableau和Microsoft Power BI和他们自有的用户界面提供支持，使CBRE客户能够查看关于CBRE管理的各种物业的核心指标和报告，包括入住率、租金、能源使用等。

公司的数据与分析团队定期收到客户关于特殊报告、指标或洞察的请求，这些请求需要自定义开发。CBRE希望能够让客户通过自然语言提示快速查询现有数据，且界面友好。通过Lambda函数管理提示，该系统利用OpenSearch服务和Anthropic Claude 2在Amazon Bedrock上查询客户数据库并生成适当的业务分析响应，其中包含平易近人的回答、推理过程和SQL代码。为此，开发了一个简单的用户界面，以简化复杂性，允许用户输入问题并直接获取结果，未来还可以将该解决方案应用到其他仪表板上。

主要使用案例和环境要求

生成式AI是分析和转化大量数据集为可用摘要和文本的强大工具。CBRE的主要需求包括： 使用自然语言查询以英语提交的一般问题作为主要输入 使用大语言模型LLM生成和运行商业仪表板的SQL查询的可扩展解决方案 提交至环境的查询需返回以下内容： 以简单英语呈现的结果 以简单英语的推理过程 生成的SQL代码 如果输入的NLQ与以前的查询相似，能够重用现有的表、列和SQL代码的嵌入 查询响应时间控制在3至5秒内 目标为90的“好”响应基于客户用户验收测试 为CBRE仪表板集成提供API管理层 用户验收测试UAT时的简单UI和前端

解决方案概述

CBRE与AWS原型团队构建了一个环境，允许用户通过自然语言英语向结构化数据表提交查询，基于Anthropic Claude 2在Amazon Bedrock上实现，支持最高10万个tokens的处理。使用Amazon Titan生成嵌入。通过LangChain实现了Anthropic Claude 2与CBRE样本数据库的连接框架。AWS原型团队开发了一个AWS云开发工具包AWS CDK栈，以遵循AWS最佳实践进行部署。

该环境经过多个开发冲刺逐步开发而成，CBRE在并行完成用户验收测试，以确认其性能符合预期。

下图展示了NLQ能力的核心架构。

NLQ的工作流程包括以下步骤：

一个Lambda函数将架构JSON和表元数据CSV写入S3桶。用户发送JSON事件格式的问题NLQ。包装函数在OpenSearch服务中搜索类似问题。如果找到，跳至步骤6；否则，继续步骤4。包装函数从S3桶读取表元数据。包装函数创建动态提示模板并使用Amazon Bedrock和LangChain获得相关的表。包装函数选择S3桶的架构JSON中仅相关的表架构。包装函数创建动态提示模板，并利用Anthropic Claude 2生成SQL查询。包装函数通过psycopg2执行SQL查询。包装函数创建动态提示模板以生成利用Anthropic Claude 2的英语答案。包装函数利用Anthropic Claude 2和OpenSearch服务执行以下操作：使用Amazon Titan生成嵌入。将问题和SQL查询以向量形式存储在OpenSearch服务索引中以便重用。包装函数整合输出并返回JSON结果。

Web UI与API管理层

AWS原型团队构建了一个Web界面及API管理层，以便在开发期间进行用户测试，并加速与CBRE现有BI能力的集成。下图展示了Web界面及API管理层的工作流程。

轻蜂加速器下载安卓版

工作流程包括以下步骤：

用户通过Web浏览器从其笔记本电脑访问Web门户。使用低延迟的Amazon CloudFront分发提供静态网站，由Amazon证书管理器ACM签发HTTPS证书进行保护。S3桶存储网站相关的HTML、CSS和JavaScript，以供渲染静态网站。 CloudFront分发配置为从此S3桶获取源，保持同步以为用户提供最新版本的网站。使用Amazon Cognito作为主要身份验证和授权提供者，利用其用户池允许用户登录、访问API网关、访问网站桶和响应桶。Amazon API Gateway端点和REST API级别受到Amazon Cognito的保护，仅允许经过身份验证的实体访问Lambda函数。一个带有业务逻辑的Lambda函数调用主Lambda函数。一个S3桶用来存储主Lambda函数生成的响应，前端定期查询以在Web应用上显示。建立一个VPC端点以隔离主Lambda函数。为Lambda和Amazon S3导入和配置VPC端点，以确保前端堆栈能够获得足够的访问权限以访问VPC内的资源。AWS身份与访问管理IAM实施必要的权限以确保前端应用。Amazon CloudWatch捕获跨各种资源尤其是Lambda和API网关的运行日志。

技术方案

Amazon Bedrock是一个完全托管的服务，通过API提供来自领先AI初创公司和亚马逊的基础模型，使您可以从多种模型中选择以找到最适合用例的模型。在Amazon Bedrock无服务器体验中，您可以快速入门，私有化定制基础模型，并使用AWS工具集成和部署，而无需管理任何基础设施。

选择Anthropic Claude 2作为解决方案的支持，作为一种通用的LLM，支持最高10万个token。LLM在自动生成代码方面表现出色。相关的元数据可以帮助指导模型的输出并定制SQL代码生成以针对特定用例。AWS提供像AWS Glue这样的工具，使用crawlers自动从数据源提取技术元数据。利用Amazon DataZone构建商业元数据。采取了一种轻量级的方法，以便快速建立所需的技术和业务目录，使用自定义脚本。元数据为模型生成与数据库架构和业务需求相符的特定SQL代码做了准备。

对于Anthropic Claude 2模型，根据NLQ生成SQL查询需要输入上下文文件： metacsv：这是一种人写的元数据，以CSV格式存储在S3桶中，其中包括架构中表的名称及其描述。将metacsv文件作为输入上下文发送给模型参见端到端解决方案架构图的步骤3和步骤4，以根据输入NLQ查找相关表。metacsv在S3中的位置如下：

    s3//ltdbSchemaGeneratorBucketgt/ltDBNamegt/table/metacsv

schemajson：此JSON架构由Lambda函数生成并存储在Amazon S3中。根据架构的步骤5和6，将相关表架构作为输入上下文发送给模型，以根据输入NLQ生成SQL查询。schemajson的S3位置如下：

s3//ltdbSchemaGeneratorBucketgt/ltDBNamegt/schema/schemajson

DB架构生成Lambda函数

此函数需要手动调用。以下可配置环境变量在部署这个Lambda函数时由AWS CDK管理：

dbSchemaGeneratorBucket 用于存储schemajson的S3桶secretManagerKey AWS Secrets Manager的数据库凭证密钥secretManagerRegion Secrets Manager密钥所在的AWS区域

在成功运行后，schemajson 会被写入S3桶。

Lambda包装函数

这是解决方案的核心组件，执行端到端解决方案架构中描述的步骤2至10。以下图展示了其代码结构和工作流程。

它运行以下脚本：

indexpy Lambda处理程序主程序，处理输入/输出并根据输入上下文中的键运行函数langchainbedrockpy 获取相关表，生成SQL查询，并利用Anthropic Claude 2将SQL转换为英语opensearchpy 在OpenSearch服务中检索类似的嵌入或生成新的嵌入sqlpy 使用pyscopg2和opensearchpy模块运行SQL查询boto3bedrockpy 亚马逊Bedrock的Boto3客户端utilspy 各种实用程序函数，包括OpenSearch服务客户端、Secrets Manager客户端和格式化最终输出响应

Lambda包装函数有两个层次的依赖：

LangChain层 包含LangChain、boto3和psycopg2的pip模块和依赖OpenSearch服务层 OpenSearch服务Python客户端的依赖

AWS CDK在包装函数部署期间管理以下可配置环境变量：

dbSchemaGeneratorBucket 用于存储schemajson的S3桶opensearchDomainEndpoint OpenSearch服务端点opensearchMasterUserSecretKey OpenSearch服务凭证的密钥名称secretManagerKey Amazon RDS凭证的密钥名称secretManagerRegion Secrets Manager密钥所在的区域

以下代码展示了输入事件的JSON格式：

json{ useVectorDB lt0或1gt inputqueries [ lt问题1gt lt问题2gt lt问题3gt ] S3OutBucket lt输出响应桶gt S3OutPrefix lt输出S3前缀gt}

它包含以下参数：

inputqueries是一个NLQ问题的列表，范围为1到X。如果有多个NLQ，它们会作为跟进问题添加到第一个NLQ。useVectorDB键定义是否使用OpenSearch服务作为向量数据库。如果是0，它将运行端到端工作流而不搜索OpenSearch服务中的类似嵌入。如果是1，则会搜索类似的嵌入。如果找到了类似的嵌入，它将直接运行SQL代码，否则将执行模型推理。默认情况下，将useVectorDB设置为1，因此该键是可选的。S3OutBucket和S3OutPrefix键是可选的。这些键表示JSON响应的S3输出位置，主要用于前端的异步模式。

以下代码展示了输出响应的JSON格式：

json[ { statusCode lt200或400gt Question lt输入NLQgt sqlcode lt亚马逊Bedrock生成的SQL查询gt SQLAnswer ltSQL响应gt EnglishAnswer lt英语答案gt }]

statusCode为200表示Lambda函数成功运行；statusCode为400则表示出错。

性能调优方案

性能调优是一个迭代过程，涉及多个层次。在此部分，我们讨论了该解决方案的性能调优方案。

RAG的输入上下文

LLMs主要在通用领域的语料库上进行训练，因此在领域特定的任务上效果较差。在这种情况下，当期望根据PostgreSQL DB架构生成SQL查询时，架构成为我们的输入上下文，供LLM生成上下文特定的SQL查询。在我们的解决方案中，有两个输入上下文文件对输出质量、性能和成本至关重要：

获取相关表：由于整个PostgreSQL数据库架构的上下文长度较长对于我们的演示数据库超过16000个tokens，因此必须仅选择相关表的架构，而不能使用整个数据库架构，这样可以减少模型的输入上下文长度，这不仅对生成内容的质量有影响，也影响性能和成本。根据NLQ选择合适的表是至关重要的一步，建议在metacsv中详细描述表的特征。数据库架构：schemajson由架构生成器Lambda函数生成，保存在Amazon S3中，并作为输入上下文传递。它包括列名、数据类型、不同值、关系等等。LLM生成的SQL查询的输出质量高度依赖于详细的模式。我们的演示中，每个表的架构的输入上下文长度在20004000个tokens之间。更详细的架构可能提供较好的结果，但也需要优化上下文长度以提高性能和降低成本。作为解决方案的一部分，我们已经对DB架构生成器Lambda函数进行了优化，以平衡详细架构与输入上下文长度。如果需要，您可以根据要生成的SQL查询的复杂性进一步优化函数，以包含更多细节例如，列元数据。

提示工程与指令调优

提示工程允许您设计LLM的输入以生成优化的输出。根据输入NLQ创建动态提示模板，采用LangChain请参见端到端解决方案架构中的步骤4、6和8。我们将输入的NLQ