基于Amazon Bedrock构建企业级AI对话平台：架构、部署与实战-编程实验室

1. 项目概述：一个基于Amazon Bedrock的企业级AI对话平台

如果你正在寻找一个能快速部署、功能全面且完全运行在AWS云上的企业级AI对话应用，那么AWS官方开源的Bedrock Chat（BrChat）项目绝对值得你花时间深入研究。我最近花了大量时间部署和测试了这个平台，它本质上是一个基于Amazon Bedrock大模型服务的“开箱即用”的聊天机器人解决方案，但它的能力远不止简单的对话。你可以把它理解为一个私有化的、功能增强版的ChatGPT企业部署方案，它集成了知识库检索增强生成（RAG）、自定义智能体（Agent）、应用内Bot商店以及API发布等高级功能，所有这一切都通过AWS CDK（Cloud Development Kit）实现了一键式基础设施即代码部署。

简单来说，Bedrock Chat帮你解决了从零开始搭建一个生产级AI应用时最头疼的那些问题：用户认证与管理、对话历史存储、文件上传与向量化、多模型支持、前端界面、安全防护以及可扩展的架构。你不再需要自己拼接Lambda、API Gateway、DynamoDB和前端框架，这个项目已经为你设计好了一个经过实战检验的完整架构。它支持包括Claude 3.5/3.7 Sonnet、Amazon Nova、Llama 3、Mistral等在内的主流模型，并且通过Bedrock Knowledge Bases服务，可以轻松地将你的内部文档（PDF、Word、Excel、TXT、HTML、Markdown等）转化为机器人的“长期记忆”，实现基于企业知识的精准问答。

我之所以对这个项目印象深刻，是因为它将生成式AI的复杂能力进行了高度的产品化封装。开发者或企业IT团队可以通过几条命令，在35分钟左右就获得一个功能完备、界面专业的AI应用，并且能根据自身需求进行深度定制，比如限制访问IP、关闭自助注册、绑定自定义域名等。接下来，我将从架构设计、核心功能、部署实操以及我踩过的一些坑这几个方面，为你详细拆解这个项目。

2. 核心架构设计与技术栈解析

Bedrock Chat的架构充分体现了现代云原生应用的最佳实践：全托管、无服务器、事件驱动和高可用。整个系统没有一台需要你维护的EC2服务器，所有组件都采用了AWS的托管服务，这让运维复杂度降到了最低。下面这张架构图清晰地展示了各个组件如何协同工作：

2.1 前端展示层：React + CloudFront + S3

用户接触到的Web界面是一个基于React构建的单页应用（SPA），使用了Tailwind CSS进行样式开发。前端代码在构建后，会被上传到Amazon S3存储桶中，并通过Amazon CloudFront全球加速分发。CloudFront在这里扮演了两个关键角色：一是作为CDN加速全球访问，二是作为安全网关，集成了AWS WAF（Web应用防火墙）来执行IP白名单等访问控制策略。这种组合确保了前端应用的高性能、高可用性和安全性。前端通过WebSocket和REST API与后端通信，实现了聊天的流式响应，用户体验非常流畅。

2.2 后端API层：FastAPI + Lambda + API Gateway

后端是整个应用的大脑，采用Python的FastAPI框架编写。FastAPI以其高性能和自动生成API文档的特性而闻名，非常适合构建此类API服务。为了让无服务器函数也能运行像FastAPI这样的Web框架，项目使用了AWS Lambda Web Adapter。这是一个巧妙的设计：它将Lambda的请求/响应格式转换成标准的HTTP格式，使得FastAPI应用可以几乎不做修改就直接在Lambda中运行。

API Gateway作为统一的API入口，负责路由请求、限流、授权（与Cognito集成）和监控。所有业务逻辑，包括处理聊天消息、管理知识库文件、操作Bot商店等，都被封装在多个Lambda函数中。这种设计使得后端服务具备了无服务器的所有优点：按需付费、自动扩缩容、无需管理服务器。

2.3 数据与智能层：Bedrock + DynamoDB + OpenSearch

这是整个应用最核心的部分：

Amazon Bedrock：提供大模型推理能力。应用通过Bedrock的API调用各种基础模型，模型本身由AWS完全托管，你无需关心底层基础设施。
Amazon DynamoDB：一个全托管的NoSQL数据库，用于存储所有结构化数据，包括用户信息、对话历史、Bot的元数据、知识库配置等。DynamoDB的高性能和按请求付费模式非常适合此类应用。
Amazon Bedrock Knowledge Bases：这是实现RAG（检索增强生成）的关键服务。它本身是一个托管服务，集成了文档解析、文本分块、向量嵌入（Embedding）和向量存储。Bedrock Chat将用户上传的文件（如产品手册、公司制度）发送到Knowledge Bases，后者会自动处理并存储到其底层的向量数据库中（默认是Amazon OpenSearch Serverless）。
Amazon OpenSearch Serverless：作为Knowledge Bases的向量存储后端，提供高效的向量相似性搜索能力。当用户提问时，系统会先从这里的知识库中检索出最相关的文档片段，再连同问题和指令一起发送给大模型，从而生成基于知识的准确回答。

2.4 业务流程与集成层：Step Functions + EventBridge Pipes

为了协调复杂的异步任务，项目使用了AWS Step Functions工作流。例如，当用户为一个Bot创建或更新知识库时，会触发一个Step Functions工作流，它负责调用Bedrock Knowledge Bases的API进行文档的嵌入处理，并更新处理状态。这种将复杂流程可视化和状态化的方式，比在Lambda函数中写一堆回调逻辑要清晰和可靠得多。

另一个精妙的设计是使用Amazon EventBridge Pipes来监听DynamoDB流。当用户在应用中删除一个Bot时，DynamoDB会生成一个删除事件。EventBridge Pipes捕获到这个事件后，会自动触发一个Lambda函数，该函数会去清理这个Bot所关联的CloudFormation堆栈（每个自定义Bot的知识库资源实际上是由一个独立的、动态创建的CloudFormation堆栈管理的）。这实现了资源的生命周期自动化管理，避免了资源泄漏。

2.5 安全与身份层：Cognito + WAF

Amazon Cognito：提供完整的用户身份认证、注册、登录和权限管理。支持邮箱密码注册、第三方OIDC提供商（如Google）登录。用户和组（Group）信息都存储在Cognito中，应用通过组来管理权限（例如，只有CreatingBotAllowed组的用户才能创建自定义Bot）。
AWS WAF：绑定在CloudFront上，可以在网络层实施精细化的访问控制，例如只允许公司办公网的IP段访问，这是将内部应用暴露在互联网上时必不可少的安全措施。

这个架构的优雅之处在于，它几乎用到了AWS无服务器和AI服务的“全家桶”，并且将它们以最佳实践的方式组合在一起。对于想要学习如何构建生产级云原生AI应用的开发者来说，这个项目本身就是一个极佳的学习范本。

3. 核心功能深度体验与实操要点

部署好Bedrock Chat之后，我花了几天时间深度体验了它的各项功能。它不仅仅是一个聊天窗口，更是一个小型的AI应用平台。下面我结合实操截图，带你看看它的核心功能点以及使用时需要注意的细节。

3.1 基础聊天与多模型切换

登录后的主界面是一个简洁的聊天窗口。你可以直接开始与AI对话，感受不同模型的风格。界面右上角有一个模型选择下拉框，里面列出了你在AWS Bedrock控制台中已启用访问的所有模型。这是我非常喜欢的一个设计：它实现了模型的统一管理和按需切换。你不需要为每个模型单独开发界面，用户可以在对话中随时切换不同的模型进行尝试。

实操心得：在部署前，务必先去AWS控制台的Bedrock服务下的“模型访问”页面，勾选你计划使用的模型并保存。否则，前端下拉框里会是空的，或者调用会失败。建议至少开启Claude 3.5 Sonnet（平衡性能与成本）和Claude 3 Haiku（用于快速、低成本的任务如生成对话标题）。

3.2 自定义Bot与知识库（RAG）

这是Bedrock Chat的杀手级功能。点击左侧导航栏的“Bots”，你可以创建属于自己的AI助手。

创建Bot时，你需要填写：

名称和描述：让其他用户能理解这个Bot的用途。
系统指令：这是引导AI行为的“宪法”。你可以在这里详细定义Bot的角色、回答风格、禁忌等。比如：“你是一个专业的IT技术支持助手，用中文回答，语气友好且专业，对于不确定的问题要说明‘我不确定’，不要编造信息。”
知识库：你可以选择“创建新知识库”并上传文件（支持多种格式），或者“导入现有Bedrock知识库”。上传文件后，后台的Step Functions工作流会自动触发，将文件切片、向量化并存入OpenSearch。

这里有一个至关重要的权限控制点：默认情况下，普通用户无法创建Bot。只有属于CreatingBotAllowed用户组的成员才有此权限。这个组需要在Amazon Cognito用户池中手动创建并将用户加入。这个设计非常企业级，避免了内部系统的滥用。

多租户知识库模式：这是一个为了解决Bedrock Knowledge Bases数量限制（默认一个账户最多100个）而设计的巧妙方案。在V3版本中，新Bot默认启用“多租户模式”。这意味着多个Bot可以共享一个底层的Knowledge Base基础设施，它们上传的文件通过附加Bot ID作为元数据来进行逻辑隔离。这大大提升了资源利用率和可扩展性。如果你有旧的V2版本Bot，需要按照迁移指南手动将其迁移到共享模式。

3.3 Bot商店与协作分享

创建好的Bot可以发布到内置的Bot商店中，供其他应用用户发现和使用。

这构建了一个内部AI助手生态。比如，市场部可以创建一个“市场文案助手”，研发部可以创建一个“代码审查助手”，然后分享到商店。其他同事可以直接使用这些专业助手，无需重复创建。商店界面支持搜索和分类，方便用户查找。这极大地促进了AI能力在企业内部的复用和传播。

3.4 将Bot发布为独立API

这是另一个令人惊艳的功能。你可以将自己创建的Bot（特别是那些结合了特定知识库的Bot）发布为一个独立的、对外的HTTP API。

系统会为这个API单独部署一套包含API Gateway、Lambda和WAF的资源栈（通过另一个动态CloudFormation堆栈）。你会获得一个唯一的API端点（Endpoint）和API密钥。这意味着你可以将这个专用AI能力集成到自己的其他业务系统、移动应用或者提供给第三方合作伙伴使用，实现了AI能力的服务化输出。权限同样由PublishAllowed用户组控制。

3.5 智能体（Agent）功能

Agent功能让Bot的能力从“问答”升级到了“执行”。通过预定义的工具（目前支持调用Lambda函数），Bot可以代表用户去执行一些操作。

例如，你可以创建一个“天气查询Agent”，为其配置一个能调用第三方天气API的Lambda函数作为工具。当用户问“北京明天天气如何？”时，Bot（Agent）会自主规划：我需要调用“天气查询工具”，参数是“北京”和“明天”。然后它去调用对应的Lambda函数，获取结果后再组织语言回复给用户。这为构建自动化工作流打开了大门，比如自动生成报告、查询数据库、发送通知等。

3.6 管理功能

对于系统管理员，Bedrock Chat提供了专门的管理界面。

在这里，管理员可以：

API管理：查看所有已发布的API，管理其生命周期。
标记核心Bot：将一些重要的Bot标记为“Essential”，可能在界面展示上给予优先位置。
使用情况分析：查看各个Bot的被调用次数、Token消耗等粗略指标，用于成本分析和优化。
用户与权限管理：虽然深度管理仍需回到Cognito控制台，但这里提供了基础视图。

4. 详细部署指南与避坑实录

官方提供了“超级简单部署”和CDK直接部署两种方式。我两种都尝试过，下面分享最稳妥的步骤和我遇到的实际问题。

4.1 前置条件与准备工作

在开始部署前，请确保完成以下三件事，这能避免80%的部署失败：

AWS账户与权限：使用一个具有足够权限的IAM用户或角色进行操作。需要包含创建IAM角色、Lambda、API Gateway、CloudFront、Bedrock等服务的权限。建议直接使用管理员权限进行首次部署测试。
启用Bedrock模型访问：这是最容易忽略的一步！登录AWS控制台，进入你计划部署的区域（例如us-east-1）的Bedrock服务页面。在左侧导航栏找到“模型访问”，点击“管理模型访问”。在列表中找到你想要的模型（例如Claude 3.5 Sonnet、Claude 3 Haiku、Llama 3 70B等），勾选它们，然后点击“保存更改”。这个过程可能需要几分钟生效。
选择正确的区域：Bedrock Chat的前端和主要资源可以部署在多个区域，但其依赖的某些服务有区域限制。最关键的两点是：
- OpenSearch Serverless：你的部署区域必须支持OpenSearch Serverless和Ingestion APIs。截至2025年8月，支持的区域包括：us-east-1,us-east-2,us-west-1,us-west-2,ap-south-1,ap-northeast-1,ap-northeast-2,ap-southeast-1,ap-southeast-2,ca-central-1,eu-central-1,eu-west-1,eu-west-2,eu-south-2,eu-north-1,sa-east-1。
- Bedrock区域：通过--bedrock-region参数指定Bedrock服务所在的区域。这个区域必须支持Bedrock服务，可能与应用部署区域不同，但通常设为同一个区域最方便。

4.2 方案一：使用CloudShell进行“超级简单部署”（推荐新手）

这是最快上手的方式，适合在AWS控制台内操作。

打开CloudShell：登录AWS控制台，在顶部搜索栏输入“CloudShell”并进入。确保右上角显示的区域是你计划部署应用的区域（例如us-east-1）。

克隆并运行部署脚本：在CloudShell中依次执行以下命令：

git clone https://github.com/aws-samples/bedrock-chat.git cd bedrock-chat chmod +x bin.sh ./bin.sh

回答交互问题：脚本会询问你是否是新用户。除非你是从V2版本升级，否则都输入y。
等待部署完成：接下来就是自动化的部署过程，大约需要35-40分钟。脚本会在后台使用AWS CodeBuild来执行CDK部署。期间请保持CloudShell标签页不要关闭。
获取访问地址：部署成功后，命令行会输出Frontend URL: https://xxxxxxxxx.cloudfront.net。复制这个URL在浏览器中打开即可。

重要安全配置（生产环境必做）：默认部署是“门户大开”的，任何人拿到URL都能注册。这对于生产环境是极不安全的。务必使用可选参数来加固：

./bin.sh --disable-self-register --ipv4-ranges "你的公司公网IP段/24" --allowed-signup-email-domains "你的公司域名.com"

--disable-self-register：关闭自助注册，用户只能由管理员在Cognito中创建。
--ipv4-ranges：限制只有指定IP段可以访问前端。
--allowed-signup-email-domains：即使开启自助注册，也只允许特定邮箱域名注册。

踩坑记录一：部署失败与版本回退我第一次部署时，脚本运行到最后报错了，没有输出Frontend URL。查看CodeBuild日志发现是某个Lambda函数构建问题。这是因为我部署时使用的是代码库的main分支，可能包含了不稳定的最新代码。解决方案是使用一个稳定的发布版本。我重新执行了以下命令，部署成功：
./bin.sh --version "v3.0.0"
建议新手在部署时显式指定一个已知稳定的版本号，如v3.0.0，而不是依赖默认的latest。

4.3 方案二：使用CDK在本地环境部署（推荐高级用户/定制化）

如果你需要深度定制，或者希望在本地开发调试，可以使用CDK直接部署。

环境准备：确保本地有Node.js（建议18+）、Docker和Git。Docker是CDK构建Lambda函数层所必需的。

克隆代码与安装依赖：

git clone https://github.com/aws-samples/bedrock-chat cd bedrock-chat/cdk npm ci # 使用ci命令确保依赖版本锁定

配置参数：这是定制化的核心。你有两种方式配置：

传统方式（cdk.json）：直接修改cdk/cdk.json文件中的context字段。
推荐方式（parameter.ts）：修改cdk/parameter.ts文件，这是类型安全的方式，尤其适合管理多环境（开发、测试、生产）。

以下是一个parameter.ts的配置示例，设置了生产环境的安全策略：

import { BedrockChatParams } from '../lib/parameter'; export const bedrockChatParams = new BedrockChatParams(); bedrockChatParams.set('prod', { bedrockRegion: 'us-east-1', selfSignUpEnabled: false, // 关闭自助注册 allowedIpV4AddressRanges: ['203.0.113.0/24'], // 公司IP段 allowedSignUpEmailDomains: ['mycompany.com'], enableLambdaSnapStart: true, // 启用SnapStart减少冷启动 enableRagReplicas: true, // 生产环境开启RAG副本提高可用性 globalAvailableModels: [ // 只允许使用这些模型，控制成本 'claude-v3.5-sonnet', 'claude-v3-haiku', 'amazon-nova-lite' ], defaultModel: 'claude-v3.5-sonnet', // 默认聊天模型 titleModel: 'claude-v3-haiku', // 用更便宜的模型生成标题 });

Bootstrap与部署：

# 首次在该区域部署CDK应用需要bootstrap npx cdk bootstrap aws://你的账户ID/你的区域 # 部署生产环境堆栈 npx cdk deploy --all -c envName=prod --require-approval never

部署成功后，在输出信息中找到FrontendURL即可访问。

踩坑记录二：本地磁盘空间不足CDK在构建过程中会拉取Docker镜像并在本地生成大量资产，如果磁盘空间不足（尤其是默认只有8GB的Cloud9或小容量EC2），会导致部署失败。错误信息可能比较隐晦，如“Error: ENOENT: no such file or directory”。解决方案：确保部署环境有至少20GB的可用磁盘空间。如果使用EC2，可以扩展根卷大小；如果在本地，请清理磁盘。

踩坑记录三：WAF部署区域限制CloudFront的WAF必须部署在us-east-1区域。如果你的组织策略禁止在非主区域创建资源，部署会失败。此时，你可以在配置中禁用前端WAF：在parameter.ts中设置enableFrontendWaf: false。但请注意，这将失去IP限制能力，你需要通过其他方式（如Cognito域名限制、API Gateway策略）来保证安全。

4.4 用户与权限管理

部署完成后，你需要管理用户。

如果开启了自助注册：用户可以通过前端注册页面自行注册。
如果关闭了自助注册：你需要登录AWS控制台，进入Amazon Cognito服务，找到对应的用户池（用户池ID在CloudFormation输出的AuthUserPoolIdxxxx中），手动创建用户。
分配权限组：要让用户能创建Bot，必须将其加入CreatingBotAllowed组。在Cognito用户池的“组”页面创建该组，然后将用户添加到组中。你还可以配置autoJoinUserGroups参数，让新注册用户自动加入特定组。

5. 高级配置与成本优化实战

将Bedrock Chat投入实际使用，特别是团队共用时，成本是需要仔细考虑的问题。下面分享一些关键的配置项和优化经验。

5.1 模型选择与成本控制

Bedrock按Token消耗和模型类型收费。不同模型价格差异巨大（例如Claude 3 Opus比Haiku贵一个数量级）。通过以下配置精细控制模型使用：

globalAvailableModels：在cdk.json或parameter.ts中配置这个列表，可以限制在整个应用中只出现哪些模型。避免团队成员无意中使用昂贵模型。
defaultModel和titleModel：分别设置默认聊天模型和生成对话标题的模型。将titleModel设置为claude-v3-haiku或amazon-nova-lite这类廉价模型，可以显著节省成本，因为每次对话都会自动调用一次标题生成。

5.2 RAG副本与OpenSearch成本

enableRagReplicas和enableBotStoreReplicas这两个参数直接影响OpenSearch Serverless的成本。

开发/测试环境：设置为false。OpenSearch Serverless会以最低配置（0.5 OCU）运行，成本极低。
生产环境：设置为true。这会启用备用副本，提高可用性，但成本会翻倍（至少1 OCU以上）。你需要根据对可用性的要求来决定。

重要提示：OpenSearch Serverless集合在创建后无法修改副本配置。如果你一开始为测试环境设置了enableRagReplicas: false，后来想转到生产，不能直接改参数更新堆栈。你需要先销毁旧的Bot（及其底层的CloudFormation堆栈），然后修改主堆栈配置并重新部署，最后创建新的Bot。或者，你可以考虑为生产环境部署一个全新的、独立的Bedrock Chat实例。

5.3 Lambda SnapStart的取舍

enableLambdaSnapStart: true可以大幅减少Python Lambda函数的冷启动时间，提升用户体验。但是，请注意：

额外费用：Lambda SnapStart会根据缓存的内存大小收取费用。
区域限制：并非所有区域都支持Python的SnapStart。部署前请查阅AWS官方文档确认。
初始化代码影响：如果你的Lambda初始化代码（如加载大型模型）非常耗时，SnapStart的收益会非常明显。但对于Bedrock Chat这种主要调用外部API（Bedrock）的应用，冷启动延迟的主要部分可能在网络连接而非运行时初始化。你可以通过对比测试来决定是否开启。

5.4 知识库文件处理的最佳实践

当通过Bot上传文件构建知识库时，后台处理流程是：上传到S3 -> 触发Bedrock Knowledge Bases -> 解析、分块、向量化 -> 存入OpenSearch。这个过程是异步的，可能需要几分钟，取决于文件大小和数量。

文件格式与大小：支持常见格式，但复杂的PDF（特别是扫描版）或内含大量图片的文档，解析效果可能不佳。建议上传前尽量使用文本清晰、结构简单的文档。
测试方法：上传文件后，不要立即提问。可以到AWS控制台的Bedrock服务下的“知识库”页面，找到对应的知识库，查看“同步状态”是否为“已完成”。也可以在应用内Bot的“知识库”标签页查看状态。
元数据筛选：在多租户模式下，所有Bot的文件都存储在同一个物理知识库中。检索时，系统会自动附加bot_id作为过滤条件，确保每个Bot只能访问自己的文件。这是通过Bedrock Knowledge Bases的元数据过滤功能实现的，你无需担心数据混淆。

6. 常见问题排查与运维技巧

在实际使用和运维过程中，我遇到了一些典型问题，以下是排查思路和解决方法。

6.1 前端能打开，但登录/注册后白屏或报错

可能原因1：Cognito配置问题。

排查：打开浏览器开发者工具（F12），查看网络（Network）选项卡。尝试登录时，看是否有对cognito-idp.[region].amazonaws.com的请求返回4xx错误（如400 Invalid Parameter）。
解决：检查CloudFormation输出中的AuthUserPoolClientId和AuthUserPoolId是否正确配置到了前端。通常部署脚本会自动完成，但如果手动修改了Cognito配置（如添加了自定义域名），可能需要更新前端配置并重新构建部署。

可能原因2：API Gateway或Lambda故障。

排查：查看网络请求中，对自家API Gateway域名（如xxxx.execute-api.[region].amazonaws.com）的调用是否失败。
解决：进入AWS控制台的API Gateway服务，检查对应的API（名称可能包含BedrockChatApi）是否有部署阶段（Stage）。检查CloudWatch Logs中相关Lambda函数的日志，看是否有运行时错误（如权限不足、Bedrock模型未启用）。

6.2 聊天无响应，或提示“模型调用失败”

可能原因1：Bedrock模型未在部署区域启用。

解决：这是最常见的原因。请务必按照“前置条件”部分所述，在正确的区域（由bedrock-region参数指定）的Bedrock控制台启用所需模型。

可能原因2：IAM角色权限不足。

排查：查看调用Bedrock的Lambda函数（名称可能包含MessageApi或BotApi）的CloudWatch日志。如果出现AccessDeniedException或UnauthorizedOperation错误，说明其执行角色缺少Bedrock的调用权限。
解决：Bedrock Chat的CDK代码应该已经为Lambda角色附加了必要的Bedrock策略（bedrock:InvokeModel）。检查CloudFormation堆栈的“资源”页，找到该Lambda函数，查看其IAM角色，确认是否有正确的策略。

可能原因3：区域不匹配。

排查：确认前端调用Bedrock时传递的区域参数，是否与模型实际启用的区域一致。检查bedrock-region参数的配置。
解决：确保bedrock-region参数设置正确，并且该区域已在Bedrock中启用模型。

6.3 知识库文件上传后，Bot回答仍不准确

可能原因1：文件处理未完成或失败。

排查：在AWS Bedrock控制台的“知识库”页面，找到该Bot对应的知识库，查看“同步状态”和“最近同步”信息。如果有错误，会显示失败原因。
解决：常见失败原因包括文件格式不支持、文件过大、或S3权限问题。根据错误信息调整文件或检查S3存储桶策略。

可能原因2：检索参数或指令设置不当。

排查：Bedrock Knowledge Bases在检索时，可以配置返回的相似片段数量（Top K）和相关性阈值。默认设置可能不适合你的文档类型。
解决：目前Bedrock Chat的UI可能未暴露这些高级参数。如果需要调整，可能需要修改后端Lambda代码中调用retrieveAndGenerateAPI时的参数。

可能原因3：文档质量或分块问题。

解决：RAG的效果严重依赖原始文档质量和分块策略。对于结构复杂的文档（如手册、法律条文），可能需要预处理：将其转换为纯文本、添加清晰的章节标题、删除无关内容。Bedrock Knowledge Bases使用默认的分块和嵌入模型，对于特定领域文档，效果可能不是最优。如果对效果要求极高，可以考虑使用自定义的数据处理流水线，再将处理好的向量导入Knowledge Bases。

6.4 如何监控应用运行状态与成本？

CloudWatch Dashboard：建议创建一个CloudWatch仪表板，监控以下关键指标：

Lambda：Invocations（调用次数）,Errors,Duration（持续时间）,Throttles（限制次数）。
API Gateway：Count（请求数）,4XXError,5XXError,Latency（延迟）。
Bedrock：在Bedrock控制台的“使用情况”页面查看各模型的Token消耗。
DynamoDB：ConsumedReadCapacityUnits,ConsumedWriteCapacityUnits。

成本分摊：由于所有资源都在一个AWS账户下，要区分不同团队或项目的成本比较困难。可以考虑的方案：

为不同团队部署独立的Bedrock Chat实例（使用不同的CDK环境参数），实现资源隔离和成本分离。
通过为不同Bot使用的Lambda函数添加特定标签，然后利用AWS Cost Explorer的标签分账功能进行粗略的成本分摊。

6.5 如何升级到新版本？

Bedrock Chat项目仍在活跃开发中。升级需要谨慎：

备份数据：重要的数据主要是DynamoDB中的对话历史和Bot配置。可以考虑启用DynamoDB的按需备份或使用导出到S3的功能。
查看迁移指南：非常重要！例如从V2升级到V3，有重大的架构变更（如多租户知识库），不按指南操作会导致旧的Bot不可用。务必阅读项目根目录或docs/migration/下的迁移指南。
测试环境先行：如果可能，先在一个独立的测试环境（通过-c envName=test部署）进行升级测试。
执行升级：对于“超级简单部署”，可以再次运行./bin.sh并指定新版本号。对于CDK部署，拉取最新代码，合并可能的配置文件变更（如cdk.json或parameter.ts），然后运行cdk deploy --all。系统会提示你检查安全变更，确认后执行更新。

经过一段时间的深度使用，我认为Bedrock Chat是AWS在生成式AI应用落地方面给出的一个非常出色的“参考答案”。它平衡了开箱即用的便利性和企业级的可扩展性、安全性。对于想要快速在内部搭建一个安全、可控、功能丰富的AI对话平台的企业或团队来说，这个项目能节省数月甚至更长的开发时间。当然，它也不是银弹，其复杂度和对AWS服务的深度绑定意味着你的团队需要具备一定的AWS运维能力。但无论如何，将其作为一个起点或学习案例，价值都是巨大的。

基于Amazon Bedrock构建企业级AI对话平台：架构、部署与实战