AWS CDK高阶构造库：快速构建生成式AI应用的基础设施
1. 项目概述：当CDK遇上生成式AI
如果你正在AWS上构建生成式AI应用，并且厌倦了在控制台里反复点击、手动配置各种服务，或者觉得用CloudFormation模板管理复杂的AI基础设施链路既繁琐又容易出错，那么 awslabs/generative-ai-cdk-constructs 这个项目，很可能就是你一直在寻找的“脚手架”。
简单来说，这是一个由AWS实验室（awslabs）官方维护的 AWS CDK（Cloud Development Kit）高阶构造（Construct）库 。它的核心使命，是将构建生成式AI应用时那些高频、通用但又颇为复杂的云端基础设施部署模式，封装成一个个开箱即用、可组合的CDK构造块。你可以把它想象成一个专为生成式AI场景设计的“乐高套装”，里面提供了预先组装好的“墙面”、“门窗”和“楼梯”，让你能专注于搭建“房子”的功能和设计，而不是从烧制每一块砖开始。
我在实际项目中引入它，最直接的感受是 开发效率的质变 。以往，要部署一个包含Amazon Bedrock模型调用、向量数据库（如Amazon OpenSearch）、API网关和Lambda函数的完整RAG（检索增强生成）应用，即使对资深AWS架构师来说，编写、测试和维护一套完整的IaC（基础设施即代码）也需要数天时间。而使用这个构造库，通过几十行类型安全的代码（支持TypeScript、Python等），就能在几分钟内拉起一套生产就绪的、符合最佳实践的基础设施骨架。它特别适合 全栈工程师、ML工程师以及希望快速原型验证或标准化AI应用部署的团队 ，将你从繁琐的云资源配置中解放出来，更聚焦于提示词工程、业务逻辑和用户体验。
2. 核心构造解析：你的生成式AI工具箱里有什么？
这个库不是一个单体工具，而是一个不断丰富的“工具箱”。理解每个“工具”（Construct）的用途和能力，是高效使用它的关键。下面我们来拆解几个最核心、最常用的构造。
2.1 BedrockKnowledgeBase ：一站式RAG核心引擎
这是库中的“明星”构造，它完整封装了基于Amazon Bedrock知识库的RAG解决方案。你不需要再手动串联S3、Bedrock Embedding模型、OpenSearch和Bedrock Knowledge Base API。
它的价值在于抽象和自动化 ：
- 数据源集成 ：只需指定一个S3桶路径，它能自动处理文档的上传、分块（Chunking）和元数据提取。支持多种格式（PDF, TXT, DOCX, PPTX等）。
- 向量化流水线 ：内部自动调用你指定的Bedrock嵌入模型（如
amazon.titan-embed-text-v1），将文本块转化为向量。 - 向量数据库部署 ：可以一键部署并配置一个托管的OpenSearch Serverless向量集合（Collection），或者连接到已有的向量数据库。它帮你处理好了所有网络、安全（加密、IAM角色）和索引配置。
- 知识库创建 ：自动创建Bedrock知识库资源，并将其与数据源、向量库绑定。
一个典型的使用场景 ：你有一个产品手册的PDF文件夹存放在S3。你想构建一个智能客服助手来回答产品相关问题。使用 BedrockKnowledgeBase ，你只需要在CDK代码中指定S3路径、选择嵌入模型和向量数据库类型，部署后，文档会自动被摄取、向量化并存入索引。之后，你的应用代码只需通过Bedrock Runtime API查询知识库，就能获得基于文档的精准答案。
2.2 ChatBot ：快速构建对话式Web接口
这个构造解决了一个前端展示的痛点。当你构建了一个强大的后端RAG或对话系统后，如何快速提供一个界面供内部测试或给用户演示？ ChatBot 构造可以快速部署一个完全无服务器的聊天机器人Web应用。
它基于以下AWS服务构建 ：
- 前端 ：静态React应用托管在Amazon S3，通过CloudFront分发。
- 后端API ：由Amazon API Gateway和AWS Lambda函数提供RESTful API。
- 对话管理 ：可选集成Amazon DynamoDB来持久化聊天会话历史。
- AI后端 ：可以灵活配置后端Lambda函数去调用任何AI服务，无论是Bedrock、SageMaker端点，还是你自己的模型。
实操心得 ：这个构造非常适合 概念验证（PoC）和内部工具 。它能让你在几个小时内就获得一个可交互的、界面美观的聊天应用。对于生产环境，你可能需要基于此定制UI和增强安全控制，但它提供了一个极佳的起点和架构参考。
2.3 LLMChain 与 PromptChain ：编排复杂AI工作流
生成式AI应用不仅仅是简单的问答。复杂的场景可能需要串联多个LLM调用、条件判断或外部API。 LLMChain 和 PromptChain 这类构造提供了轻量级的工作流编排能力。
LLMChain：允许你定义一系列步骤（Step），每个步骤可以是一个LLM调用、一个Lambda函数或一个条件判断。它类似于一个简化的状态机，专门为顺序或带分支的AI任务设计。PromptChain：更侧重于提示词（Prompt）的模板化和动态组装。你可以定义带有变量的提示词模板，并在运行时注入不同的上下文（如用户查询、检索到的文档片段）。
应用场景示例 ：一个内容审核系统。 LLMChain 可以编排这样的流程：1. 用第一个LLM判断用户输入的情感倾向；2. 如果为负面，则调用第二个LLM分析具体风险点；3. 根据风险等级，调用不同的处理Lambda函数（如通知人工、直接过滤）。所有这些逻辑都可以用声明式代码定义。
2.4 其他实用构造与模式
除了上述核心构造，库中还包含许多其他实用组件：
-
SageMakerEndpoint：简化将SageMaker上训练好的模型部署为端点的过程，并自动生成调用该端点的Lambda函数样板代码。 -
VectorIndex：一个更底层的向量数据库抽象，如果你需要更精细地控制OpenSearch Serverless集合的配置，可以使用它。 - 安全与监控 ：大多数构造默认集成了良好的安全实践，如加密、最小权限IAM角色。也方便与CloudWatch日志、指标集成，为后续监控打下基础。
注意 ：该库处于快速发展阶段（目前通常为开发者预览版）。这意味着新构造会不断加入，同时现有API也可能发生突破性变更。在生产中使用时，务必锁定特定的版本号，并在升级前仔细阅读变更日志。
3. 实战演练：从零部署一个企业知识库问答系统
理论说得再多，不如亲手搭一遍。让我们用一个完整的例子，展示如何用 generative-ai-cdk-constructs 在30分钟内搭建一个具备后台异步文档处理能力的企业知识库问答API。
3.1 环境准备与项目初始化
首先，确保你的本地环境已就绪：
- Node.js & AWS CDK ：安装Node.js（建议LTS版本）和AWS CDK CLI (
npm install -g aws-cdk)。 - AWS凭证 ：配置好AWS CLI，并拥有足够权限的IAM凭证（通常需要
AdministratorAccess或包含相关服务权限的策略）。 - Bootstrap ：在目标AWS区域（如
us-east-1）运行cdk bootstrap，为CDK部署准备环境。
接下来，创建一个新的CDK项目（这里以TypeScript为例）：
mkdir my-ai-knowledge-base && cd my-ai-knowledge-base
cdk init app --language typescript
安装所需的依赖库：
npm install @aws-cdk/aws-lambda-nodejs @aws-sdk/client-bedrock-agent @aws-sdk/client-s3
npm install @cdklabs/generative-ai-cdk-constructs
注意，构造库的包名是 @cdklabs/generative-ai-cdk-constructs ，这反映了它目前由CDK Labs（孵化器）维护的状态。
3.2 基础设施栈代码编写
打开 lib/my-ai-knowledge-base-stack.ts 文件，用以下代码替换原有内容。我们将构建一个包含知识库、处理Lambda和查询API的栈。
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as path from 'path';
// 导入生成式AI构造库
import { BedrockKnowledgeBase, OpenSearchVectorIndex } from '@cdklabs/generative-ai-cdk-constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
import * as iam from 'aws-cdk-lib/aws-iam';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
export class MyAiKnowledgeBaseStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// 1. 创建源文档存储桶
const sourceBucket = new s3.Bucket(this, 'SourceDocumentsBucket', {
removalPolicy: cdk.RemovalPolicy.DESTROY, // 演示用，自动删除
autoDeleteObjects: true,
encryption: s3.BucketEncryption.S3_MANAGED,
});
// 2. 创建向量索引（使用OpenSearch Serverless）
const vectorIndex = new OpenSearchVectorIndex(this, 'VectorIndex', {
vectorFieldName: 'embedding', // 向量字段名
vectorDimensions: 1536, // 对应Titan Embedding G1 - Text模型的维度
});
// 3. 创建Bedrock知识库（核心构造）
const knowledgeBase = new BedrockKnowledgeBase(this, 'EnterpriseKB', {
knowledgeBaseName: 'EnterpriseProductKB',
vectorIndex: vectorIndex, // 关联我们创建的向量索引
dataSource: {
bucket: sourceBucket,
// 可以指定前缀，例如 'documents/'
},
embeddingModel: 'amazon.titan-embed-text-v1', // 指定嵌入模型
chunkingStrategy: {
// 使用默认的分块策略，也可自定义
type: 'DEFAULT',
},
});
// 4. 创建查询API的后端Lambda函数
const queryHandler = new NodejsFunction(this, 'QueryHandler', {
runtime: lambda.Runtime.NODEJS_18_X,
entry: path.join(__dirname, '../lambda/query.ts'), // 处理函数路径
handler: 'handler',
environment: {
KNOWLEDGE_BASE_ID: knowledgeBase.knowledgeBaseId,
// 区域从Stack中获取
AWS_REGION: this.region,
},
timeout: cdk.Duration.seconds(30),
memorySize: 512,
});
// 5. 为Lambda函数授予调用Bedrock知识库的权限
queryHandler.addToRolePolicy(new iam.PolicyStatement({
actions: ['bedrock:Retrieve', 'bedrock:RetrieveAndGenerate'],
resources: [
`arn:aws:bedrock:${this.region}:${this.account}:knowledge-base/${knowledgeBase.knowledgeBaseId}`,
],
}));
// 6. 创建API Gateway
const api = new apigateway.RestApi(this, 'KnowledgeBaseApi', {
restApiName: 'Enterprise KB Service',
description: 'API for querying the enterprise knowledge base.',
defaultCorsPreflightOptions: {
allowOrigins: apigateway.Cors.ALL_ORIGINS, // 生产环境应限制来源
allowMethods: apigateway.Cors.ALL_METHODS,
},
});
const queryIntegration = new apigateway.LambdaIntegration(queryHandler);
api.root.addResource('query').addMethod('POST', queryIntegration);
// 7. 输出有用的信息到CloudFormation输出
new cdk.CfnOutput(this, 'SourceBucketName', {
value: sourceBucket.bucketName,
description: 'Name of the S3 bucket to upload documents',
});
new cdk.CfnOutput(this, 'ApiEndpointUrl', {
value: api.url + 'query',
description: 'Endpoint URL for querying the knowledge base',
});
new cdk.CfnOutput(this, 'KnowledgeBaseId', {
value: knowledgeBase.knowledgeBaseId,
description: 'ID of the created Bedrock Knowledge Base',
});
}
}
3.3 Lambda处理函数实现
在项目根目录创建 lambda 文件夹，并在其中创建 query.ts 文件：
import { BedrockAgentRuntimeClient, RetrieveAndGenerateCommand, RetrieveCommand } from '@aws-sdk/client-bedrock-agent-runtime';
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
const client = new BedrockAgentRuntimeClient({ region: process.env.AWS_REGION });
const KNOWLEDGE_BASE_ID = process.env.KNOWLEDGE_BASE_ID!;
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
console.log('Received event:', JSON.stringify(event, null, 2));
try {
const body = JSON.parse(event.body || '{}');
const { query, retrievalMode = 'RETRIEVE_AND_GENERATE' } = body;
if (!query) {
return {
statusCode: 400,
body: JSON.stringify({ error: 'Missing required field: query' }),
};
}
let response;
if (retrievalMode === 'RETRIEVE') {
// 仅检索相关文档片段
const retrieveCommand = new RetrieveCommand({
knowledgeBaseId: KNOWLEDGE_BASE_ID,
retrievalQuery: {
text: query,
},
retrievalConfiguration: {
vectorSearchConfiguration: {
numberOfResults: 5, // 返回最相关的5个片段
},
},
});
const retrieveResponse = await client.send(retrieveCommand);
response = {
retrievedResults: retrieveResponse.retrievalResults,
};
} else {
// 检索并生成答案（默认）
const ragCommand = new RetrieveAndGenerateCommand({
input: {
text: query,
},
retrieveAndGenerateConfiguration: {
type: 'KNOWLEDGE_BASE',
knowledgeBaseConfiguration: {
knowledgeBaseId: KNOWLEDGE_BASE_ID,
modelArn: 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0', // 指定用于生成的模型
},
},
});
const ragResponse = await client.send(ragCommand);
response = {
generatedAnswer: ragResponse.output?.text,
citations: ragResponse.citations,
};
}
return {
statusCode: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(response),
};
} catch (error) {
console.error('Error processing query:', error);
return {
statusCode: 500,
body: JSON.stringify({ error: 'Internal server error', details: (error as Error).message }),
};
}
};
3.4 部署与验证
-
合成与部署 ：
cdk synth cdk deploy首次部署可能需要10-15分钟，因为需要创建OpenSearch Serverless集合等资源。
-
上传文档 ：部署成功后，控制台会输出
SourceBucketName。将你的企业文档（如PDF、TXT）上传至该S3桶的根目录或指定前缀下。Bedrock知识库会自动开始同步和向量化处理。你可以在AWS控制台的Bedrock“知识库”页面查看同步状态。 -
测试API ：获取输出的
ApiEndpointUrl。使用curl或Postman发送POST请求：curl -X POST https://your-api-id.execute-api.region.amazonaws.com/prod/query \ -H "Content-Type: application/json" \ -d '{"query": "我司产品A的核心优势是什么？"}'你将收到一个由Claude模型生成的、基于你上传文档的答案。
这个实战案例的价值 ：我们用了不到100行的基础设施代码和50行的业务逻辑，就构建了一个具备企业级可扩展性、安全性和维护性的RAG后端系统。所有底层细节——向量数据库配置、网络隔离、IAM策略、数据同步流水线——都被构造库优雅地抽象了。
4. 深入原理：构造库如何封装最佳实践
使用这个库不仅仅是调用API，更是在采纳一套经过设计的AWS生成式AI最佳实践。理解其背后的设计哲学，能帮助你在更复杂的场景下灵活运用或进行定制。
4.1 安全性与权限的最小化原则
构造库在创建资源时，默认遵循AWS安全最佳实践。例如：
- 加密 ：创建的S3桶、OpenSearch集合默认启用加密（KMS或服务托管密钥）。
- 网络隔离 ：
OpenSearchVectorIndex默认部署在VPC内（如果使用Serverless VPC端点）或配置了安全的访问策略，避免公开暴露。 - 最小权限IAM ：为Lambda函数或知识库执行角色生成的IAM策略，通常只包含完成其任务所必需的最低权限。例如，查询Lambda只有
bedrock:RetrieveAndGenerate权限，而不是宽泛的bedrock:*。
实操心得 ：尽管默认设置已很安全，但在生产环境中仍需根据合规要求进行审查。例如，你可能需要改用自定义的KMS密钥来满足加密要求，或者调整VPC和子网配置以匹配公司的网络规划。构造库通常通过属性（props）暴露这些高级配置选项。
4.2 无服务器与弹性架构
库中绝大多数构造都基于无服务器服务（Lambda, API Gateway, S3, OpenSearch Serverless, Bedrock）。这带来了几个核心优势：
- 自动扩展 ：无需预置或管理服务器，流量高峰时自动扩容，空闲时成本降至零。
- 高可用性 ：这些服务本身跨多个可用区部署，提供了内置的高可用性。
- 按需付费 ：你只为实际使用的资源（如向量搜索的计算单元、Lambda执行时间、Bedrock模型调用）付费。
这种架构选择使得基于此库构建的应用天生具备处理不确定、爆发式AI工作负载的能力。
4.3 可观测性设计
好的基础设施必须可观测。构造库在创建资源时，通常会配置好基本的CloudWatch日志和指标。
- Lambda函数 ：自动启用日志，并配置合理的日志组和保留期。
- Bedrock知识库 ：同步作业的状态、成功/失败事件会发送到CloudWatch。
- OpenSearch ：Serverless集合提供搜索延迟、请求计数等指标。
给你的建议 ：在项目初期，就应考虑增强可观测性。你可以在CDK栈中额外添加：
- 自定义指标 ：在查询Lambda中，使用
putMetricData记录每次查询的响应时间、检索到的文档数量等业务指标。 - 结构化日志 ：以JSON格式输出日志，便于后续用CloudWatch Logs Insights进行分析，例如记录用户查询、生成的答案长度、模型使用情况等。
- 告警 ：基于错误率或延迟指标创建CloudWatch告警。
5. 进阶应用与定制化策略
当你熟悉了基础构造后，就可以开始探索更高级的用法，解决更复杂的业务场景。
5.1 混合检索策略的实现
单纯的向量相似性搜索（语义搜索）有时会遗漏关键词完全匹配的重要文档。一个健壮的RAG系统往往需要结合 向量搜索 和 关键词搜索 （如OpenSearch的lexical search）。
generative-ai-cdk-constructs 的 BedrockKnowledgeBase 目前主要对接向量搜索。但你可以通过“逃逸舱口”进行定制。
策略 ：不直接使用 BedrockKnowledgeBase 的数据源同步功能，而是：
- 使用
OpenSearchVectorIndex构造创建向量索引。 - 自己实现一个文档处理流水线（可以用AWS Step Functions或一个Lambda函数编排）：
- 从S3读取文档。
- 使用Amazon Textract或Lambda进行文本提取和分块。
- 同时，将文本块存入OpenSearch， 既存入向量字段（通过Bedrock Titan Embedding），也存入用于关键词搜索的文本字段 。
- 在OpenSearch中配置一个混合搜索（Hybrid Search）的索引映射和搜索查询。
- 在查询时，你的Lambda函数直接调用OpenSearch的搜索API（而非Bedrock Knowledge Base的Retrieve API），执行混合搜索，将结果作为上下文传递给Bedrock模型生成答案。
这种方式增加了复杂度，但给予了你最大的灵活性和对检索过程的控制力。
5.2 多模型路由与A/B测试
生产环境可能同时使用多个模型（如Claude-3 Haiku用于简单问答，Sonnet用于复杂分析，或不同供应商的模型）。你需要一个智能的路由层。
实现方案 ：
- 使用
LLMChain构造，在链中定义一个“路由”步骤。这个步骤可以是一个Lambda函数，其逻辑基于：- 查询复杂度分析 ：通过一个轻量级模型或规则（如查询长度、关键词）判断。
- 成本控制 ：优先使用低成本模型，仅在必要时路由到高能力模型。
- 负载均衡 ：在不同模型端点间轮询。
- 路由Lambda函数根据逻辑，将请求转发到不同的下游资源。这些资源可以是：
- 不同的Bedrock模型ID。
- 通过
SageMakerEndpoint构造部署的自有模型。 - 甚至是通过API Gateway集成的外部模型API。
- 为了进行A/B测试，你可以在路由逻辑中引入随机分流，并将每次请求的模型选择、输入输出记录到DynamoDB或S3，用于后续的效果分析和模型评估。
5.3 与现有CI/CD流水线集成
将基于此CDK构造库的项目纳入你现有的软件开发流程至关重要。
典型CI/CD流程（以GitHub Actions为例） ：
- 代码提交触发 ：推送代码到特性分支触发测试流水线。
- 安全与质量扫描 ：使用
cdk synth生成CloudFormation模板，并用cfn-nag等工具进行安全策略检查。同时运行单元测试（针对Lambda函数逻辑）。 - 部署到开发环境 ：通过
cdk deploy --require-approval never自动部署到开发AWS账户和环境。 - 集成测试 ：部署后，自动化脚本调用部署好的API进行冒烟测试，验证知识库同步和查询功能是否正常。
- 人工评审与生产部署 ：创建Pull Request，合并后触发生产流水线。生产部署前可设置手动批准关卡。生产部署使用明确的版本标签和回滚策略。
关键配置 ：在 cdk.json 中为不同环境（dev, staging, prod）配置不同的上下文变量，如知识库名称、实例类型、是否启用删除保护等。
{
"context": {
"environments": {
"dev": {
"knowledgeBaseName": "mykb-dev",
"removalPolicy": "destroy"
},
"prod": {
"knowledgeBaseName": "mykb-prod",
"removalPolicy": "retain"
}
}
}
}
6. 常见陷阱、问题排查与优化指南
即使有了强大的工具，在实际操作中依然会遇到各种问题。以下是我在多个项目中总结的常见“坑点”和解决方案。
6.1 部署与初始化问题
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
cdk deploy 失败，提示 OPEN_SEARCH_ACCESS_DENIED |
执行部署的IAM角色缺少操作OpenSearch Serverless的权限。 | 1. 检查部署角色的IAM策略，确保包含 aoss: 相关权限（如 CreateCollection , BulkGet ）。 2. 最简单的方式是临时为角色附加托管策略 AmazonOpenSearchServiceFullAccess （仅限开发），生产环境需细化权限。 |
知识库同步状态一直为 IN_PROGRESS 或失败 |
1. S3桶策略阻止Bedrock访问。 2. 文档格式不受支持或已损坏。 3. 向量索引未就绪。 |
1. 检查Bedrock知识库执行角色的S3读取权限，以及S3桶策略是否允许该角色访问。 2. 在Bedrock控制台查看同步作业的详细错误信息。 3. 确认OpenSearch Serverless集合状态为 ACTIVE 。 |
| Lambda函数超时 | 1. 文档分块过多或过大，处理耗时。 2. Bedrock模型响应慢。 3. 冷启动。 |
1. 增加Lambda超时时间（如至5分钟）和内存（如1024MB）。 2. 优化提示词，减少不必要的上下文。 3. 为Lambda配置预置并发以消除冷启动影响（会增加成本）。 |
6.2 运行时性能与成本优化
性能优化 ：
- 向量索引调优 ：对于
OpenSearchVectorIndex，关注vectorDimensions必须与所选嵌入模型严格匹配（如Titan Embed Text v1是1536）。错误维度会导致搜索失败或结果不准。 - 分块策略 ：默认分块策略可能不适合所有文档。对于技术文档或代码，可能需要更小的块大小和重叠。你可以通过
chunkingStrategy属性自定义maxTokens和overlapTokens。 - 检索优化 ：调整
numberOfResults（检索片段数量）和similaritySearchK参数。并非越多越好，过多的无关片段会干扰模型并增加延迟和成本。通常5-10个高质量片段足够。
成本控制 ：
- OpenSearch Serverless OCU ：这是主要的潜在成本项。监控OCU（OpenSearch Compute Units）使用情况。在开发环境，可以设置较低的容量下限；对于有明显波峰波谷的应用，可以考虑使用定时任务（如通过EventBridge触发Lambda）在非高峰时段自动缩放容量。
- Bedrock模型调用 ：区分
InvokeModel（按输入输出token计费）和InvokeModelWithResponseStream（流式，类似计费）。对于长文本生成，流式响应可以改善用户体验，但计费方式相同。选择性价比合适的模型，例如Haiku通常比Sonnet便宜一个数量级，且对许多任务足够胜任。 - Lambda与API Gateway ：这部分成本通常较低。确保Lambda函数逻辑高效，避免不必要的循环或外部调用。使用API Gateway缓存（如果查询可缓存）可以显著减少后端调用。
6.3 内容安全与合规性考量
生成式AI应用必须考虑内容安全。
- 输入输出过滤 ：在调用Bedrock模型前后，添加内容审查层。可以使用Bedrock内置的Guardrail功能（如果模型支持），或者在Lambda函数中集成一个轻量级的内容安全分类器。
- 数据隐私 ：确保上传到S3的源文档不包含敏感个人信息（PII）。可以考虑在文档处理流水线中增加一个使用Amazon Comprehend进行PII检测和脱敏的步骤。
- 审计与溯源 ：确保所有用户查询和AI生成的答案都连同时间戳、用户ID（如有）和使用的上下文来源（引用），被安全地日志记录到诸如Amazon CloudWatch Logs或S3中，并配置合适的保留策略，以满足合规审计要求。
一个重要的提醒 ： generative-ai-cdk-constructs 是一个加速开发的利器，但它不替代你对所构建系统架构和安全性的深入理解。它封装了“通用模式”，但你的“具体业务需求”和“合规边界”需要你自己来定义和实现。把它当作一个生产力强大的伙伴，而不是一个全自动的黑盒。
更多推荐
7
0- 0
已为社区贡献93条内容
所有评论(0)