type
Post
status
Published
date
Jun 15, 2026
slug
summary
tags
category
数据工程与机器学习
icon
password

AWS Certified AI Professional 题库倒排索引式教材

资料来源：用户提供的 AIP 题库 DOCX 与 AWS 官方技术文档。本文不是按题号复述，而是把 100+ 场景压缩成“需求条件 → 正确服务/功能 → 选择理由”的考试条件反射。

0. 总体判题框架

这套题的核心不是“会不会训练模型”，而是：能不能在 AWS 上把 Generative AI application（生成式 AI 应用）做成企业级系统。题目反复考五件事：
  1. RAG 与数据层：Knowledge Bases、vector store、chunking、metadata filtering、reranking、citation、data catalog、data residency。
  1. 集成与编排：Converse API、InvokeModelWithResponseStream、Bedrock Flows、Agents、AgentCore、Step Functions、Lambda、API Gateway、EventBridge。
  1. 安全与治理：Bedrock Guardrails、IAM/SCP、PrivateLink、CloudTrail、model invocation logging、PII filtering、Macie、Comprehend、Lake Formation。
  1. 性能与成本：Provisioned Throughput、inference profiles / cross-Region inference、token metrics、CountTokens、streaming、prompt caching、retry with jitter、X-Ray。
  1. 评估与排障：Bedrock model evaluation、LLM-as-a-judge、RAG evaluation、CI/CD gate、prompt regression、human review、CloudWatch/X-Ray tracing。

题库勘误与警戒点

  1. 文件名写 119 题，但可解析正文中实际题号有缺号，主题也有重复，例如科学论文 hierarchical chunking 场景出现了两次。备考时不要迷信题号。
  1. 有些解析文字中“选项 B 正确”但描述的实际是 A 的方案，这种属于题库整理错误。考试时按需求和服务边界判断，不按解析标签死背。
  1. “CRI”在题库里被误译成“容器运行时接口”，正确是 Cross-Region Inference（跨区域推理）。
  1. Token 管理题中“自己写 tokenizer”是旧式答案；现在官方有 CountTokens API，但仍需要在应用/Lambda/API 层主动调用并发布指标。
  1. CloudTrail 只记录 API 活动，不记录完整 prompt-response 内容；完整模型交互审计要用 model invocation logging。
  1. Macie 是 S3 静态数据发现/分类，不是实时对话过滤；实时 PII 用 Guardrails / Comprehend。
  1. API Gateway usage plan 按 request 限流，不懂 token，不适合 token quota 治理。
  1. Kendra、Neptune、SageMaker 自托管模型在题库中经常是“能做但不是最低运维”的干扰项。
  1. SQS 是异步缓冲工具，遇到 <500ms / <1s 的实时交互题通常是错误方向。
  1. 题目说“最低操作开销”时，优先 Bedrock 原生能力，而不是 Lambda/SageMaker/OpenSearch 自己拼一套。

高频英文术语校正

题库中文有不少机翻词，考试和官方文档里要按英文识别：
题库中文/奇怪译法
正确英文
记忆说明
通用人工智能
Generative AI / GenAI（生成式 AI）
不是 AGI。
基础模型 / 功能模型 / 财务经理 FM
Foundation Model / FM（基础模型）
“财务经理”是机翻事故。
安全防护措施 / 守护栏
Amazon Bedrock Guardrails（Bedrock 护栏）
负责输入/输出安全策略。
基石评估任务
Amazon Bedrock model evaluation job（模型评估任务）
可做 LLM-as-a-judge。
容器运行时接口 CRI
Cross-Region Inference / CRI（跨区域推理）
不是 Kubernetes CRI。
红/黄/绿 RAG
Retrieval-Augmented Generation / RAG（检索增强生成）
不是 red/amber/green。
代币
Token（标记）
成本、配额、上下文窗口都按 token。
调用日志 / 交付日志
Model invocation logging（模型调用日志）
可投递到 CloudWatch Logs / S3。
资料来源引文
Citations / source attribution（引用/来源归属）
RAG 合规题高频。
接地检查
Contextual grounding check（上下文接地检查）
检测回答是否基于 reference source。
拒绝主题
Denied topics（拒绝主题）
Guardrails 中禁止某类话题。
词过滤器
Word filters（词过滤器）
禁竞争对手名、敏感词。
敏感信息策略
Sensitive information filters（敏感信息过滤）
PII 检测、遮蔽、阻止。
分层分块
Hierarchical chunking（分层分块）
父块保上下文，子块保精确召回。
语义分块
Semantic chunking（语义分块）
按语义边界切文档。
重排序
Reranking（重排序）
初检索后用 reranker 提高真正相关性。

第一章：Foundation Model Integration, Data Management, and Compliance（基础模型集成、数据管理和合规性）

1.1 需求场景 → 正解条件反射

在“需要基于企业私有资料回答，并要求来源可追溯”的场景下，使用 Amazon Bedrock Knowledge Bases（Bedrock 知识库）+ RetrieveAndGenerate / RetrieveAndGenerateStream 是正解

因为 Bedrock Knowledge Bases 托管了 RAG 的主要链路：data source ingestion（数据源摄取）、chunking（分块）、embedding（嵌入）、vector store 写入、retrieval（检索）、context assembly（上下文组装）和 citations（引用）。题库中医疗建议、金融报表、产品目录、法律研究、酒店 PMS、资助申请、临床决策等场景，只要出现：
  • “只能基于批准文档回答”
  • “必须引用具体来源”
  • “不得推荐不存在的产品”
  • “必须可追溯到源文档”
  • “要降低幻觉”
  • “要尽量低运维”
优先反射到 Amazon Bedrock Knowledge Bases（Bedrock 知识库）。
若题目强调“直接检索并生成回答”，选 RetrieveAndGenerate API（检索并生成 API）。若题目强调“流式用户体验”，选 RetrieveAndGenerateStream API（流式检索并生成 API）。

在“产品目录/政策库/医学文件/财务报告中不能凭空编造”的场景下，RAG 优先于 prompt engineering（提示工程）和 fine-tuning（微调）

提示工程能约束语气和格式，但不能保证模型只推荐目录中存在的商品。微调会把成本、周期、隐私和验证复杂度拉高，也不适合 3 周 PoC。题库的条件反射是：
  • 有权威数据源 → RAG。
  • 要低运维 → Bedrock Knowledge Bases。
  • 要证明回答来自哪里 → citations / source attribution。
  • 要临床/金融事实一致性 → RetrieveAndGenerate + Guardrails contextual grounding。

在“检索结果语义相似但上下文不相关”的场景下，优先使用 reranking（重排序）

Vector similarity（向量相似）不等于真正 relevant（相关）。监管合规、法律案例、医学文献题里，经常出现“初始检索返回语义相似但上下文不相关，导致幻觉”。正解是：
  • 如果已经使用 Bedrock Knowledge Bases，优先启用 reranking configuration（重排序配置），使用托管 reranking model。
  • 如果题目明确要求自定义管线，才考虑 Retrieve API → Bedrock Rerank API → InvokeModelWithResponseStream。
  • 自己部署 SageMaker reranker 不是最低运维。
考试判断句：粗召回用 embedding，精排用 reranker。

在“检索范围太大，跨内容类型/时间跨度导致慢且不准”的场景下，优先使用 metadata filtering（元数据过滤）

当题目说底层 embedding model 已经很好，但检索慢、不相关，且向量搜索评估了太多文档，正确方向不是换模型，而是缩小候选集：
  • 在 S3 文档旁边提供 metadata sidecar file（元数据边车文件），例如 document.pdf.metadata.json。
  • 或使用 S3 object metadata / object tags。
  • 在 Knowledge Bases 中启用 metadata-aware filtering（元数据感知过滤）。
  • 查询时按 content_type、publish_date、source、jurisdiction、department、hotel_id 等过滤。
考试判断句：先过滤，后向量搜索；先减少噪音，再追求模型能力。

在“法律、医疗、法规、缩写、引用、专有术语必须精确匹配”的场景下，使用 hybrid search（混合搜索）

纯向量搜索容易漏掉 exact term（精确术语）、acronym（缩写）、citation（引文编号）。题库中法律研究助手、医疗术语搜索都考这一点。正解是：
  • Amazon OpenSearch Service / OpenSearch Serverless 支持 vector search + keyword search 的 hybrid search。
  • BM25 / keyword search 保证术语、引文、缩写匹配。
  • Vector search 保证语义关系。
  • Reranking 再提升最终相关性。
考试判断句：术语、法规、案例号、药名、缩写出现时，hybrid search > pure vector search。

在“小数据集、索引少、要求高准确和低延迟”的向量搜索场景下，MemoryDB + HNSW 常是题库正解

题库里有一个小型专有金融数据集的向量搜索题，正解选择 Amazon MemoryDB（Redis 兼容内存数据库）+ HNSW index（分层可导航小世界索引）+ vertical scaling（纵向扩展）。这里的考试逻辑是：
  • MemoryDB 是内存数据库，适合低延迟检索。
  • HNSW 适合高召回、高性能的近似最近邻搜索。
  • 小型数据集不需要分布式分片和复杂水平扩展。
但要注意现实细节：Flat search 理论最准确，但成本和扩展性差；题库中选项 A 错在配了 horizontal scaling（水平扩展）这类不合题意的扩展方式。

在“向量规模很大、文档千万级、实时低延迟、元数据过滤强”的场景下，OpenSearch Serverless / OpenSearch Service 是主力

当题目出现：
  • 1000 万文档嵌入
  • 2000 万餐厅 + 2 亿评论
  • 多语言语义搜索
  • 实时客户交互
  • 复杂 metadata filters
  • 低运维/自动扩展
优先选择：
  • Amazon OpenSearch Serverless（OpenSearch 无服务器）：低运维、大规模向量搜索、元数据过滤。
  • Amazon OpenSearch Service（托管集群）：需要更强搜索控制、hybrid search、自定义索引/分析器时。
考试判断句：百万以内可考虑 Aurora pgvector；千万级/复杂搜索/低延迟更像 OpenSearch。

在“文件少于百万、大学档案/摘要搜索、低运维、语义相似”的场景下，Aurora PostgreSQL Serverless + pgvector 是正解

题库中大学数字化档案、少于 100 万文件、元数据无关键词、要求语义匹配，正解是：
  • Amazon Titan Embeddings（Titan 嵌入模型） 生成向量。
  • Amazon Aurora PostgreSQL Serverless with pgvector（Aurora PostgreSQL 无服务器 + pgvector） 存储和查询。
原因：规模没大到必须 OpenSearch；Aurora Serverless 运维更轻，能同时存 metadata 和 vector。

在“需要 Knowledge Bases 低成本向量存储，但 metadata filtering 需求不复杂”的场景下，可考虑 Amazon S3 Vectors（S3 向量）

官方文档中 Bedrock Knowledge Bases 已支持 Amazon S3 Vectors（S3 向量） 作为 vector store。它适合低成本、低运维的向量存储，但题库中凡是强调“高级元数据过滤/复杂过滤”时，不选 S3 Vectors，因为它有 filterable metadata 数量和大小限制。
考试判断句：S3 Vectors 省钱省运维；复杂 metadata filtering 还是 OpenSearch / Aurora。

在“图关系、实体关系、知识图谱推理”的场景下，才考虑 Neptune Analytics（Neptune 分析）

题库里 Neptune 多作为干扰项。除非题目明确强调 graph-based retrieval（基于图的检索）、entity relationship（实体关系）、多跳关系推理，否则不要因为“关系复杂”就选 Neptune。大多数文档 RAG 检索题仍是 OpenSearch / Knowledge Bases。

在“客户必须拥有并控制自己的数据，供应商只安全读取已索引内容”的场景下，Amazon Q Business 是强候选

题库第一题的逻辑是：客户企业拥有内部数据，不需要实时访问，要求数据治理、所有权、可撤销访问和低运维。正解是：
  • 每个客户维护自己的 Amazon Q Business index（Q Business 索引）。
  • 客户把服务商配置为受控数据访问者。
  • 服务商通过安全 API 查询已索引内容，不把原始数据搬出来。
不要反射到每个客户部署 MCP server，也不要让供应商跨账户直接管理客户 Bedrock Knowledge Base，除非题目明确要求这样。

在“Amazon Q Business 从 S3 数据源按 IAM Identity Center 组做访问控制”的场景下，使用集中 acl.json

如果 S3 中每个部门是一个 prefix，每个用户属于一个 IAM Identity Center group，题库正解是：
  • 在 S3 bucket 顶层创建单个 acl.json（访问控制列表文件）。
  • 将 S3 prefix 映射到 IAM Identity Center groups。
  • 在 Amazon Q Business S3 data source 的 access control 配置中引用此 ACL 文件。
不要用 IAM permission set 试图控制 Q Business 检索结果；Q Business 的文档访问控制要走它自己的 data source ACL / identity mapping 机制。

在“非结构化数据预处理、质量校验、元数据审计、文本分块”的场景下，AWS Glue 是正解

题库中金融公司预处理客户通话记录、财务报告和文档，要求 data quality、metadata、monitoring、custom chunking，正解是：
  • AWS Glue Crawler（Glue 爬虫） 自动发现和编目。
  • AWS Glue Data Catalog（Glue 数据目录） 存元数据。
  • AWS Glue ETL job（Glue ETL 作业） 做文本清洗、转换、分块。
  • AWS Glue Data Quality（Glue 数据质量） 验证质量、输出指标。
考试判断句：数据准备 + 元数据 + 数据质量 = Glue 组合拳。

在“跨账户/列级访问/敏感数据湖治理”的场景下，Lake Formation LF-tags 是正解

如果题目要求：
  • 数据湖跨账户访问
  • 列级权限
  • 敏感客户记录/PII 列不能暴露
  • 按业务部门、区域、表、列授权
优先选择：
  • AWS Lake Formation tag-based access control / LF-TBAC（基于 LF 标签的访问控制）。
  • Column-level permissions（列级权限）。
  • Cross-account grants（跨账户授权）。
不要用 S3 bucket policy、ACL、IAM path policy 替代列级数据治理。

在“数据源集中注册、元数据标记、生成内容可追溯”的场景下，Glue Data Catalog + CloudTrail 是正解

当题目说 GenAI 输出必须“完全可追溯”，支持 data source registration（数据源注册）、metadata tagging（元数据标记）、audit logs（审计日志）：
  • AWS Glue Data Catalog 注册数据源与元数据。
  • 对数据源、表、列、文档对象应用 metadata tags。
  • AWS CloudTrail 记录跨服务访问与活动。
  • 生成结果可用 S3 object tags 或元数据记录 source ID / citation ID。
Lake Formation 是访问控制加强版；如果题目只问可追溯和注册，不一定需要 Lake Formation。

在“数据分类/敏感数据发现”的场景下，Amazon Macie 是正解

题库里 Macie 的“分类效果”就是：对 S3 中敏感数据做 automated sensitive data discovery / classification（自动敏感数据发现/分类），识别 PII、财务信息等，并产生 findings（发现）和分类结果。它不是实时聊天过滤器，也不是模型输出过滤器。
考试判断句：
  • S3 静态数据分类 → Amazon Macie。
  • 实时输入/输出 PII 过滤 → Bedrock Guardrails sensitive information filters 或 Amazon Comprehend PII。

在“多大陆数据驻留，处理和存储必须在同一大陆”的场景下，使用区域内 S3 + 区域内预处理 + CloudTrail + Macie，避免跨大陆 CRI

如果题目要求欧洲、北美、亚洲分别处理本地数据，不能跨大陆：
  • 每个地理区域使用本地 Amazon S3 bucket（S3 存储桶）。
  • 在同一区域/同一地理边界内做 preprocessing（预处理）和 Bedrock 调用。
  • 使用 Macie 做数据分类。
  • 使用 CloudTrail 和 S3 Object Lock 做不可变审计。
如果题目要求“数据驻留和处理必须在同一大陆”，跨大陆 inference profile 是错的。若是“EU 内跨区域”才可用 geographic cross-Region inference。

在“文档 50–200 页，超出上下文窗口导致截断”的场景下，RAG + semantic chunking 是正解

不要把大文档硬塞进上下文窗口。正确思路是：
  • Semantic chunking（语义分块） 按意义切分。
  • 使用 sentence buffer / breakpoint percentile threshold 保持语义连续性。
  • 用 RetrieveAndGenerate API 动态选择最相关 chunk。
固定大小切块容易破坏语义；顺序链接 chunk 到最大上下文窗口会引入噪声并触发截断。

在“科学论文方法/结果/讨论跨段落，需要保持更大上下文”的场景下，hierarchical chunking 是正解

题库中 2500 万科学论文、查询涉及 methods/results/discussion，正确是：
  • Hierarchical chunking（分层分块）。
  • Parent chunks（父块）例如 1000 tokens，保存章节/段落级上下文。
  • Child chunks（子块）例如 200 tokens，支持高精度检索。
  • Overlap（重叠）减少边界割裂。
考试判断句：
  • 超长技术文档、问答只需相关片段 → semantic chunking。
  • 科学论文/章节结构/跨段落语义连贯 → hierarchical chunking。
  • 财务报告表格+解释文本 → layout-aware / structure-aware chunking。

在“财务报告表格和解释文本必须保持关系”的场景下，layout-aware / structure-aware chunking 是正解

财报常见 5–100 页，表格和解释文本交错。正确方案：
  • 使用 Bedrock Knowledge Bases 建 RAG。
  • 按 document layout（文档布局）、section（章节）、table（表格）、footnote（脚注）做上下文分块。
  • 保留指标与解释段落之间的关系。
  • 输出 citations。
固定大小分块、查询时才切分、拆成结构化/非结构化两个应用，都是复杂或破坏上下文。

1.2 工具倒排索引：数据与 RAG 工具

Amazon Bedrock Knowledge Bases（Bedrock 知识库）

功能
对应场景
考试反射
Managed RAG（托管 RAG）
私有知识问答、产品推荐、医疗/金融/法律文档
低运维首选。
RetrieveAndGenerate API
检索并生成，要求来源引用
比自己编排 Retrieve + InvokeModel 更低运维。
RetrieveAndGenerateStream API
RAG + 流式响应
复杂问题/用户体验/前端逐步显示。
Retrieve API
只要检索结果，后续自定义生成/重排
手动 RAG 管线时用。
Citations / source attribution
监管、审计、金融/医疗透明性
“引用来源”必选。
Metadata filtering
内容类型、时间、来源、部门、区域过滤
检索范围过大时优先。
Reranking configuration
初始检索相似但不相关
降幻觉、提高真正相关性。
Semantic chunking
大文档、上下文窗口、截断
按意义切。
Hierarchical chunking
科学论文/章节/跨段落连贯
父块保上下文，子块保精度。
Fixed-size chunking
简单文本、无结构要求
题库里常是干扰项。
Vector stores
OpenSearch Serverless/Service、Aurora、S3 Vectors、Neptune 等
根据规模、过滤、成本选。

Amazon OpenSearch Service / OpenSearch Serverless（OpenSearch 搜索服务/无服务器）

功能
对应场景
选择理由
Vector search / k-NN
千万级向量、低延迟语义搜索
分布式搜索能力强。
Hybrid search
法律、医疗、法规、缩写、精确术语
关键词 + 向量。
Metadata filtering
多语言监管文档、文档类型、日期、监管机构
复杂过滤强。
Serverless capacity
低运维、自动扩展
不想管节点/分片。
Data access policies in OpenSearch Serverless
Bedrock Knowledge Base 访问 403
需要给 Bedrock service role / Lambda role 配 AOSS 数据平面权限。

Amazon Aurora PostgreSQL with pgvector（Aurora PostgreSQL + pgvector）

场景
正解理由
少于百万文档、大学档案、摘要语义搜索
比 OpenSearch 运维更轻，能同时存 metadata 和 vectors。
已有 PostgreSQL，规模中小，SQL 查询和向量检索结合
可用 pgvector。
大规模高 QPS、复杂搜索、千万级向量
不优先，容易变成调优/扩展题。

Amazon MemoryDB（MemoryDB 内存数据库）

场景
正解理由
小型专有向量数据集、低延迟、高准确
内存级延迟，HNSW 高召回。
大规模水平扩展向量搜索
题库不倾向，OpenSearch 更常见。

Amazon S3 metadata / object tags / sidecar metadata JSON（S3 元数据、对象标签、元数据边车文件）

功能
对应场景
System metadata（系统元数据）
时间戳、对象创建/修改属性。
User-defined metadata（用户自定义元数据）
作者、source ID、业务上下文。
Object tags（对象标签）
领域分类、合规标签、审计标签。
.metadata.json sidecar
Knowledge Bases metadata filtering 最常用模式。
Lifecycle rules（生命周期规则）
只保留 3 年文档、日志保留。
Object Lock（对象锁）
不可变审计、合规保留。

第二章：Implementation and Integration（实施与集成）

2.1 需求场景 → 正解条件反射

在“模型调用跨 Python Lambda 和 JavaScript EKS，需要一致多轮对话接口”的场景下，Converse API 是正解

Amazon Bedrock Converse API（Converse 对话 API） 是 Bedrock 的统一聊天协议层。它把不同模型厂商的 messages、roles、system prompt、tool use、streaming 统一起来。题库中的判断是：
  • 多环境：Lambda Python + EKS JavaScript。
  • 跨 SDK 一致。
  • 多轮上下文。
  • 相同 FM。
  • IAM role 认证一致。
正解：
  • 使用 Converse API / ConverseStream API。
  • 在 request messages array 中传入 previous conversation messages。
  • 使用 IAM roles。
不要自己为不同语言写输入/输出 adapter，也不要把会话状态放进进程内存。

在“实时语音助手/座席辅助/端到端小于 500ms 或 1s”的场景下，必须全链路 streaming

只要题目说实时通话、客户讲话中给建议、低于 500ms/1s，正确链路通常是：
  • Amazon Transcribe Streaming API（Transcribe 流式转录 API），小音频块或 partial results。
  • Amazon Bedrock InvokeModelWithResponseStream（流式模型调用） 或 ConverseStream。
  • API Gateway WebSocket API（WebSocket API） 做双向实时推送。
  • 主管评分/实时状态存 DynamoDB。
  • 审计内容存 S3。
Batch Transcribe、SQS 排队、Bedrock batch inference、异步 SageMaker 都不满足实时。

在“S3 新对象触发，转录录音，生成结构化摘要/情感分析”的场景下，S3 EventBridge + Step Functions + Transcribe + Bedrock 是正解

当录音 MP3 上传到 S3 后立即处理：
  • S3 object-created event → Amazon EventBridge。
  • EventBridge 触发 AWS Step Functions。
  • Step Functions 调用 Amazon Transcribe。
  • 然后调用 Amazon Bedrock，提示模型输出 JSON。
  • 结构化输出存回 S3 / DynamoDB。
考试逻辑：事件驱动解耦，Step Functions 编排托管服务，少写 glue code。

在“简单 GenAI 工作流：S3 取内容 → 表达式解析 → 模型审查 → S3 存结果”的场景下，Bedrock Flows 是正解

Amazon Bedrock Flows（Bedrock 流程） 用于可视化编排 GenAI 工作流。题库中客户通信审查题，正解是：
  • S3 retrieval node（S3 检索节点）读取模板内容。
  • Expression（表达式）提取模板中特定部分。
  • Prompt / Agent node（提示/代理节点）调用模型审查。
  • S3 storage node（S3 存储节点）写回结果。
如果只是 GenAI 原生流程，Bedrock Flows 比 Step Functions 更贴题。Step Functions 能做，但不是最低 GenAI 运维。

在“工作流中间输出超过 Step Functions 256 KB”的场景下，S3 外部化大对象，只传 URI

Step Functions state payload 有 256 KB 限制。多代理 ReAct 工作流的中间推理轨迹很容易超过。正解：
  • 大型中间输出存 Amazon S3。
  • 状态之间只传 s3Uri、object key、trace ID、metadata。
  • 用 ResultPath / ResultSelector 控制 Step Functions 状态数据。
不要压缩塞进 state，不要拆多个状态机，不要额外引 DynamoDB 除非题目要求低延迟键值状态。

在“多个独立分析任务要从 45 秒降到 10 秒”的场景下，用 Step Functions Parallel state 并行调用 Bedrock

如果每批 5 份报告，每份报告要做财务分析、情绪分析、合规验证，且任务独立：
  • 使用 AWS Step Functions Parallel state（并行状态）。
  • 每类分析一个 Lambda / Bedrock 调用。
  • 配置 Bedrock client timeout。
  • 用 CloudWatch 监控 execution time 和 inference latency。
不要顺序处理，不要用 SQS 增加排队延迟。

在“长期澄清工作流/等待用户补充/保留对话状态”的场景下，Step Functions Standard + callback + DynamoDB 是正解

对于多轮澄清、用户请求含糊、需要暂停等待输入：
  • Step Functions Standard Workflow（标准工作流） 支持长期状态保存。
  • 使用 callback pattern / waitForTaskToken（回调等待模式）。
  • 会话历史存在 DynamoDB，按 user/session key 查询。
  • DynamoDB on-demand + server-side encryption 支持高并发和加密。
不要用 Express Workflow 做长期等待；不要用 ElastiCache 存合规审计历史；不要把状态放进 Lambda/ECS 进程内存。

在“强制人工审核 AI 建议”的场景下，Step Functions waitForTaskToken + DynamoDB 审计是正解

监管要求所有 AI 推荐必须由人工技术人员审核：
  • Step Functions 生成 task token 并暂停。
  • 人工审核系统提交批准/拒绝。
  • Lambda 调用 SendTaskSuccess / SendTaskFailure。
  • 审核结果写入 DynamoDB / S3 作为审计记录。
这比自定义轮询或缓存方案更确定、更可审计。

在“多部门专业回答，需要多代理架构”的场景下，supervisor agent + collaborator agents 是正解

医疗临床、保险核验、预约、理赔这类多领域助手：
  • 一个 supervisor agent（主管代理） 做 intent classification / routing。
  • 多个 collaborator agents（协作代理） 各自处理部门任务。
  • 每个 collaborator agent 使用自己的 department-specific Knowledge Base。
  • IAM 控制知识库访问。
不要让一个通用代理写一堆规则，也不要多个主管并行抢答后合并。

在“代理需要调用外部 API、Lambda、REST API、事件驱动工具”的场景下，Agents action groups / AgentCore Gateway 是正解

  • Amazon Bedrock Agents action groups（代理操作组）：让代理调用 Lambda 或 API schema 定义的动作。
  • Amazon Bedrock AgentCore Gateway（AgentCore 网关）：把 API、Lambda、现有服务转换成 MCP-compatible tools（MCP 兼容工具），让代理安全发现和调用。
  • 同步工具调用用 API Gateway；事件驱动调用用 EventBridge。
题库中的 AgentCore 题强调 memory、session-aware reasoning、access control、event-driven + synchronous invocation，正解组合是：
  • AgentCore Runtime / Memory / Identity / Observability 管代理状态、会话、权限和可观测。
  • API Gateway + EventBridge 注册工具 支持同步/异步调用。

在“远程 MCP server 访问用户信息，需要授权”的场景下，Lambda + API Gateway + Cognito OAuth 是正解

Model Context Protocol / MCP（模型上下文协议）服务器如果是远程服务，不用 STDIO。本题正确形态：
  • MCP server 运行在 AWS Lambda。
  • 前面放 Amazon API Gateway HTTP endpoint。
  • 用 Amazon Cognito 实施 OAuth 2.1 / 用户授权。
  • 代理通过 HTTP transport 调用 MCP server。
STDIO transport 更适合本地进程，不适合远程受管服务。

在“不改代码即可动态切换模型/成本阈值/区域合规规则/A-B 测试”的场景下，AWS AppConfig 是正解

如果题目出现：
  • dynamic cost thresholds（动态成本阈值）
  • Region-specific compliance rules（区域合规规则）
  • real-time A/B testing（实时 A/B 测试）
  • no code deployment（不部署代码）
  • thousands of concurrent requests（数千并发即时传播）
正解：
  • AWS AppConfig（应用配置） 存 feature flags / dynamic configuration。
  • Lambda 使用 AWS AppConfig Agent / Lambda extension 获取缓存配置。
  • 业务逻辑在 Lambda 内根据 user tier、transaction amount、region、cost metric 选择 FM。
不要用 Lambda environment variables；改环境变量不是安全动态配置治理。

2.2 工具倒排索引：集成工具

Amazon Bedrock Flows（Bedrock 流程）

节点/功能
对应场景
S3 retrieval node
从 S3 读取输入内容。
S3 storage node
将模型输出或中间结果写回 S3。
Expression
从整体输入中提取模板片段、字段。
Prompt node
调用托管提示/模型。
Agent node
调用 Bedrock Agent。
Condition node
分支逻辑。
Lambda node
必须写业务逻辑时调用 Lambda。
Flow version / immutable deployment
从测试到生产的流程治理。

Amazon Bedrock Agents / AgentCore（Bedrock 代理 / AgentCore）

功能
对应场景
Action groups
调用 Lambda/API 工具。
Knowledge base attachment
代理基于专属知识库回答。
Multi-agent collaboration
supervisor + collaborators 多领域分工。
Agent trace
跟踪代理 step-by-step orchestration，用于审计/排障。
AgentCore Memory
代理跨交互记忆和会话上下文。
AgentCore Runtime
安全、可扩展运行代理。
AgentCore Identity
集成企业 IdP，用户/代理权限控制。
AgentCore Gateway
将 API/Lambda/服务变为 MCP-compatible tools。
AgentCore Observability
追踪代理执行路径、性能瓶颈、中间输出。

AWS Step Functions（步骤函数）

模式
对应场景
Standard Workflow
长时间、可靠、有状态、人工介入。
Express Workflow
高吞吐短流程，不适合长等待。
Parallel state
独立分析任务并行化，降低总延迟。
Map state
批量对象并行处理、文件并行处理。
waitForTaskToken
人工审批、等待外部回调。
Service integrations
直接编排 Transcribe、Bedrock、S3 等。
ResultPath / ResultSelector
控制状态输入输出，传 S3 引用避免 256 KB 限制。

Amazon API Gateway（API 网关）

功能
对应场景
REST API / HTTP API
暴露推理服务或 webhook。
WebSocket API
实时双向座席辅助。
Lambda authorizer
多 webhook 身份验证方法统一处理。
Cognito authorizer
用户级认证授权。
Request transformation
简单转换可用，但复杂模型路由不优先。

第三章：AI Security, Safety, and Governance（AI 安全、保障与治理）

3.1 需求场景 → 正解条件反射

在“输入/输出安全策略、禁止话题、PII、毒性、竞争对手名、提示注入”的场景下，Amazon Bedrock Guardrails 是主正解

Amazon Bedrock Guardrails（Bedrock 护栏） 是题库安全治理的核心。出现以下需求就优先反射 Guardrails：
  • 不得提供投资建议、保证收益、股票推荐。
  • 不得输出竞争对手内容。
  • 不得泄露 PII。
  • 不得输出危险建议、不安全温度、不道德/有害/操纵性请求。
  • 检测 prompt injection / prompt attacks（提示注入/攻击）。
  • 检测 hallucination（幻觉）或不基于上下文的输出。
  • 需要生产前 mask，生产时 block。
Guardrails 的考试用法：
Guardrails 功能
英文
对应场景
内容过滤器
Content filters
Hate、Insults、Sexual、Violence、Misconduct、Prompt Attack 等分类。
拒绝主题
Denied topics
禁止投资建议、保证收益、特定高风险对话类别。
词过滤器
Word filters
禁竞争对手名称、特定品牌/敏感词。
敏感信息过滤
Sensitive information filters
PII 检测、mask / block。
上下文接地检查
Contextual grounding check
摘要、问答、RAG 中检测回答是否偏离 source。
自动推理检查
Automated reasoning checks
用规则/逻辑约束验证输出，题库中常作为治理增强项。
Detection vs Block
检测 vs 阻止
只想通知不阻断时用 detect；强监管生产用 block。
考试判断句：能用 Guardrails 托管策略解决，就不要自己写 regex / Lambda 后处理。

在“PII 不得发送给模型”的场景下，推理前过滤必须发生在模型调用前

如果要求“prompt 中不得包含任何 PII”，正确方案必须在模型调用前做 PII 处理：
  • Bedrock Guardrails sensitive information filters 可在输入和输出阶段处理。
  • Amazon Comprehend PII detection（Comprehend PII 检测） 可作为预处理层。
  • Amazon Macie 不是实时聊天过滤器，它是 S3 静态数据发现。
题库中银行 AI 助手正解是：Guardrails sensitive information policy + topic policy + Converse API logging + S3 delivery/image logging。

在“同一文档不同角色看到不同 PII”的场景下，推理时动态选择 Guardrails，而不是复制知识库

医疗设备公司题：外科医生可以看到 PII，工程师要遮蔽 PII。正解：
  • Cognito 用户组识别角色。
  • 运行时根据用户组选择不同 Guardrails configuration。
  • S3 Lifecycle 删除超过 3 年报告。
  • 定期同步 Knowledge Base。
不要在摄取时永久删除 PII；那会破坏外科医生需求。也不要维护两套知识库，容易漂移。

在“组织级集中限制员工只能用批准模型和批准 Guardrail”的场景下，SCP + Guardrail 部署 是正解

多账户组织中员工都有 Bedrock 权限，但公司要统一管控：
  • 使用 AWS Organizations Service Control Policy / SCP（服务控制策略） 限制可调用模型。
  • SCP 要求调用模型时必须指定中央批准的 GuardrailIdentifier。
  • 使用 CloudFormation StackSets 把自定义 Bedrock Guardrails 部署到组织各账户/区域。
  • 对专有信息/禁题用 block filtering policy。
IAM permission boundary 可以补充角色内最大权限，但组织级最大权限边界是 SCP。

在“部门只能访问特定模型系列”的场景下，IAM 条件键限制 ModelId / GuardrailIdentifier

企业身份联邦场景中，常见组合：
  • Microsoft Entra ID → IAM SAML federation。
  • 每个部门映射到特定 IAM role。
  • IAM policy 用 bedrock:ModelId 或资源/条件限制可调用模型。
  • 对 Guardrails 使用 GuardrailIdentifier 强制批准护栏。
  • Bedrock runtime 使用 AWS PrivateLink interface VPC endpoint（接口型 VPC 端点）。
  • CloudTrail + model invocation logging 做审计。

在“Bedrock 所有 API 调用必须走私有网络路径”的场景下，PrivateLink interface VPC endpoint 是正解

正确表达：
  • AWS PrivateLink / interface VPC endpoint for Amazon Bedrock runtime（Bedrock runtime 接口 VPC 端点）。
  • Lambda/ECS/EKS 放在 private subnets。
  • IAM condition 限制 aws:SourceVpce。
NAT Gateway 访问公共 Bedrock endpoint 不满足“专用网络路径”。

在“谁在何时访问什么、模型交互审计、提示响应内容保留”的场景下，CloudTrail + model invocation logging 分工明确

需求
正解
谁调用了哪个 API，何时调用，配置怎么改
AWS CloudTrail（云审计）。
实际 prompt / response / metadata / image / document 日志
Amazon Bedrock model invocation logging（模型调用日志）。
长期保留、合规存储
S3 + lifecycle / Object Lock。
近实时分析
CloudWatch Logs / CloudWatch Metrics。
日志不可变性
S3 Object Lock compliance mode + CloudTrail log file integrity validation。
CloudTrail 不是 prompt-response 日志。题库中凡是“保留所有提示-响应对”，都不能只选 CloudTrail。

在“区域数据驻留 + CRI 报 SCP deny”的场景下，要允许地理推理配置文件，而不是给管理员权限

如果公司只允许 eu-central-1，但使用 Amazon Nova Pro 时 Bedrock CRI 实际路由到 eu-west-3，SCP 会 deny。正确处理：
  • 使用 geographic cross-Region inference profile（地理跨区域推理配置文件），例如 EU 范围。
  • SCP 明确允许 eu.* 或特定 eu.amazon.nova-pro-v1:0 inference profile 所需资源。
  • IAM role 也要允许通过该 inference profile 调用相关 EU 区域中的模型。
不要直接开放 eu-west-3 公共访问，不要管理员权限，因为 SCP 仍会覆盖 IAM。

在“跨地区高可用但数据不得出地理边界”的场景下，geographic cross-Region inference 是正解

  • In-Region inference（区域内推理）：最严格，所有处理留在单一区域。
  • Geographic cross-Region inference（地理跨区域推理）：EU/US/APAC/Japan 等边界内路由，提高吞吐和可用性，同时满足地理数据驻留。
  • Global cross-Region inference（全球跨区域推理）：最大吞吐/成本优势，但不适合数据驻留约束。
考试判断句：有 data residency → Geo CRI；无 residency 且要最大吞吐 → Global CRI。

在“扫描财务文件、提取结构化数据、低置信度人工审核、区域内审核”的场景下，Textract + A2I + 区域 IAM/S3 是正解

贷款申请题正确组合：
  • Amazon Textract（文本提取） 从扫描件提取结构化数据和置信度。
  • Amazon Augmented AI / A2I（增强型人工智能人工审核） 低置信度转人工。
  • Textract 与 A2I 部署在申请人同一区域。
  • 推理前用 Lambda / Comprehend / Guardrails 去 PII。
  • S3 区域内存储原文档，metadata/tags 审计。
Kendra/OpenSearch 不是扫描件字段提取工具。

在“必须人工审核关键高风险交互，但不能全量人工审核”的场景下，Bedrock evaluation / Guardrails + A2I 是正解

金融建议、医疗临床等高风险领域：
  • 自动化大规模评估用 Amazon Bedrock evaluation。
  • 策略执行用 Bedrock Guardrails。
  • 只把 flagged / low confidence / edge cases 送 Amazon A2I。
考试判断句：自动筛大多数，人审少数高风险。

在“企业级模板、提示、治理、审批、审计”的场景下，Prompt Management + IAM + CloudTrail 是正解

多团队多区域管理数百个 prompt templates：
  • Amazon Bedrock Prompt Management（提示管理）：versioning（版本控制）、prompt variables（参数化变量）、prompt variants（变体）。
  • IAM 控制谁能编辑/批准/发布。
  • CloudTrail 审计创建、修改、批准、使用。
  • 与 Flows 集成实现主应用一致使用。
不要用 S3 标签自造版本控制，也不要用 DynamoDB+Lambda 自造审批，除非题目明确要求自定义。

3.2 工具倒排索引：安全治理工具

Amazon Bedrock Guardrails（Bedrock 护栏）

功能
正确场景
易错点
Content filters
毒性、侮辱、暴力、性内容、misconduct、prompt attack
不是精确屏蔽竞争对手名。
Denied topics
投资建议、保证收益、股票推荐、不允许业务主题
比提示词约束更强。
Word filters
竞争对手名、品牌名、敏感词
输入和输出都可 block。
Sensitive information filters
PII 输入/输出检测、mask/block
实时对话选它，不选 Macie。
Contextual grounding check
摘要、RAG QA、事实基于 source
阈值越高越严格。
Detect action
只监控/通知，不阻断
题目说“不想屏蔽全部标记响应”。
Block action
强监管、不能泄露
生产防护常选。
Guardrail metrics
Intervention / blocked / detected 指标
CloudWatch 告警。

AWS CloudTrail（云审计）

场景
作用
API 活动审计
谁调用、何时调用、从哪里调用。
多区域 trail
组织级日志汇总到 S3。
Data events
S3 object-level 操作审计。
Log file integrity validation
日志完整性校验。
CloudTrail Lake
可查询长期审计。

Amazon Bedrock model invocation logging（模型调用日志）

场景
作用
监管保留 prompt-response
记录模型输入、输出、metadata。
图像/文档交互审计
Converse API 文档/图像日志可投递到 S3。
成本/业务归因
配合 per-request metadata tagging。
合规长期存储
S3 + Object Lock / lifecycle。

Amazon Macie / Amazon Comprehend / Amazon Comprehend Medical

服务
正确场景
非正确场景
Amazon Macie
S3 静态数据敏感信息发现/分类
实时聊天过滤。
Amazon Comprehend PII
文本输入预处理、PII 检测/遮蔽
复杂图像/扫描件字段提取。
Comprehend toxicity / prompt safety
FM 前分层内容过滤
替代 Guardrails 全部治理。
Amazon Comprehend Medical
医疗实体抽取辅助
不等于幻觉检测或完整临床正确性评估。

第四章：Operational Efficiency and Optimization（运营效率与优化）

4.1 需求场景 → 正解条件反射

在“稳定高吞吐、按小时 10000 请求、已购买 Provisioned Throughput 但没生效”的场景下，必须用 provisioned model ARN 调用

Bedrock Provisioned Throughput（预配置吞吐量） 不是买了就自动接管 base model ID。应用必须在 modelId 中传入 CreateProvisionedModelThroughput 返回的 provisioned model ARN（预置模型 ARN）。
错误代码形态：
正确方向：把 modelId 替换成 provisioned model ARN。
考试判断句：Provisioned capacity unused + on-demand throttled → modelId 没用 provisioned ARN。

在“高峰限流、时区流量波峰、低流量不能有固定小时成本”的场景下，cross-Region inference profiles 是正解

如果题目要求：
  • 全球用户，不同时区晚上高峰。
  • 高峰期 throttling。
  • 低流量时不能付固定 hourly cost。
  • 要保持质量与性能。
正解：
  • 使用 inference profiles / cross-Region inference（推理配置文件/跨区域推理）。
  • 监控 invocation count、InputTokenCount、OutputTokenCount、InvocationThrottles。
不要买 Provisioned Throughput，因为它 billing continues until deleted，会产生固定成本。

在“严格低延迟 + 巨量并发 + 预算可控”的场景下，低延迟模型 + Provisioned Throughput + autoscaling 是正解

实时客户服务建议、50 万并发、200ms 这类题库虽然现实中夸张，但考试逻辑是：
  • 选择 low-latency / real-time optimized model（低延迟实时模型）。
  • 购买 Provisioned Throughput 保证容量。
  • 配合 autoscaling / capacity planning。
不要选大型复杂推理模型、批处理优化端点、SageMaker 自托管 GPU，除非题目明确要求自托管。

在“SageMaker 实时 LLM 聊天 p95 延迟、用户等首 token 超过 2 秒就放弃”的场景下，预热 + 预加载 + streaming + dynamic batching

题库中 SageMaker 容器化 LLM 低延迟题正解两项：
  • Model preloading（模型预加载）：容器启动时加载权重，避免首次请求延迟。
  • Dynamic batching（动态批处理）：小窗口批处理提高 GPU 利用率。
  • Minimum instance count > 0（最小实例数大于 0）：消灭冷启动。
  • Response streaming（响应流）：降低 time to first token / TTFT。
错误方向：min instances = 0、lazy loading、多模型端点懒加载、异步推理。

在“用户等待完整答案太慢/复杂问题超时”的场景下，streaming 是最小架构改动

无论是 API Gateway、AppSync、Amplify 前端、座席辅助还是 RAG：只要用户感觉慢、复杂问题容易超时，优先考虑：
  • InvokeModelWithResponseStream。
  • ConverseStream。
  • RetrieveAndGenerateStream。
  • 前端逐 token / chunk 展示。
流式响应改善 perceived latency（感知延迟），也能降低同步请求超时感。

在“token 限制、成本分摊、业务部门计费、接近模型 token limit 前预警”的场景下，CountTokens + CloudWatch + DynamoDB 是正解补全

题库旧答案是 Lambda 中实现模型专用 tokenizer。按现在官方能力，应补全为：
  • 在 Lambda/API 层调用 CountTokens API（标记计数 API），因为 tokenization 是 model-specific。
  • 发送请求前估算 token usage。
  • 将 InputTokenCount、OutputTokenCount、estimated tokens、team、app、business unit 写入 CloudWatch metrics 和 DynamoDB。
  • 用 CloudWatch alarms / anomaly detection 预警。
API Gateway usage plan 只能限 request，不懂 token。

在“每月成本超预期、token 消耗异常、近实时预警”的场景下，CloudWatch token metrics + anomaly detection 是正解

Bedrock runtime 会发布 CloudWatch 指标，例如：
  • InputTokenCount
  • OutputTokenCount
  • InvocationLatency
  • client/server errors
  • throttles / invocation counts
题库中成本异常题的正确组合：
  • Bedrock model invocation logging 到 S3。
  • Guardrails contextual grounding check 检测幻觉。
  • CloudWatch anomaly detection 对 token metrics 做异常检测。
Glue + Athena 是离线批分析，不是近实时。

在“多个模型/业务部门 token 使用可视化和自定义仪表板”的场景下，CloudWatch + Managed Grafana 是正解

  • CloudWatch 原生收集 Bedrock metrics。
  • CloudWatch dashboards 适合统一技术指标和基本告警。
  • Amazon Managed Grafana 适合多团队、多 stakeholder、自定义视图。
  • CloudWatch alarms 对 token 消耗、延迟、错误率报警。
如果还要把技术指标和业务指标关联，优先把业务指标导入 CloudWatch，并用 composite alarms（复合警报）+ SNS 通知。

在“高峰瞬时错误、要防止重试风暴”的场景下，exponential backoff with jitter + circuit breaker 是正解

Bedrock 高峰超时/节流时，简单固定延迟重试会放大流量。正确模式：
  • Exponential backoff with jitter（带抖动的指数退避）。
  • Circuit breaker pattern（断路器模式）：错误率超阈值时暂停/减少重试。
  • 对 streaming response，监控 chunk delivery timeout，并缓存已收到 chunks。
  • 请求前做 token-aware truncation / summarization。
考试判断句：固定 1 秒重试 = 重试风暴风险。

在“跨服务定位延迟来源、关联模型参数”的场景下，AWS X-Ray + annotations 是正解

需要跨 API Gateway / Lambda / Bedrock / KB 找 latency source：
  • AWS X-Ray（分布式追踪）。
  • 对 trace 添加 annotations：modelId、inference profile、Region、temperature、maxTokens、prompt version。
  • CloudWatch 看指标，X-Ray 找链路。

在“重复输入要求输出 99.5% 一致”的场景下，Prompt Management + 固定参数 + 低温度 + 缓存/预置吞吐量

题库咖啡烘焙题正解选 Bedrock 原生组合：
  • Provisioned Throughput 稳定容量和延迟。
  • Guardrails 阻止不安全建议。
  • Prompt Management 通过版本和审批减少 prompt drift。
补充考试知识：如题目进一步强调一致性，可降低 temperature、topP，使用固定 prompt version、固定 retrieval context，必要时做 semantic cache / response cache。

在“多数请求都是独一无二”的场景下，response cache 不是主正解

如果题目明确说“大多数交互是 unique”，DynamoDB / ElastiCache 响应缓存命中率低，不是根本方案。应优化：
  • RAG grounding。
  • latency-optimized inference。
  • metadata filtering / reranking。
  • streaming。

在“Prompt caching 可降低延迟和输入 token 成本”的场景下，适合长而重复的系统上下文/知识前缀

官方 Bedrock 支持 Prompt caching（提示缓存）。适合：
  • 大段 system prompt / policy context 重复。
  • 多轮对话中前缀上下文稳定。
  • 降低 input token cost 和 latency。
不适合每次完全不同、上下文变化很大的请求。

4.2 工具倒排索引：运营优化工具

Amazon Bedrock inference options（Bedrock 推理方式）

方式
正确场景
易错点
On-demand inference
流量不稳定、避免固定成本
高峰可能 throttling。
Provisioned Throughput
稳定高吞吐、低延迟、容量保证
必须用 provisioned model ARN；有固定成本。
Inference profiles
跨区域吞吐、成本/性能、CRI
有数据驻留时选 geographic。
Global CRI
无数据驻留，最大吞吐/成本优化
敏感数据驻留题勿选。
Geographic CRI
EU/US/APAC/Japan 边界内
需要 SCP/IAM 允许 profile。
Batch inference
离线批处理
实时/低延迟题勿选。

Amazon CloudWatch（云监控）

指标/功能
对应场景
InputTokenCount / OutputTokenCount
token 成本、配额、异常。
InvocationLatency
推理延迟。
InvocationClientErrors / ServerErrors
客户端/服务端错误。
InvocationThrottles
限流诊断。
Anomaly Detection
成本/用量异常。
Composite alarms
技术指标 + 业务指标联动报警。
Custom metrics
幻觉率、公平性指标、业务转化率。
SNS notifications
告警通知利益相关者。

AWS X-Ray（分布式追踪）

功能
对应场景
Trace segments
找 API/Lambda/Bedrock 哪一段慢。
Annotations
关联 modelId、prompt version、region、inference profile。
Service map
可视化跨服务调用。

第五章：Testing, Validation, and Troubleshooting（测试、验证与故障排除）

5.1 需求场景 → 正解条件反射

在“比较多个基础模型质量和安全性”的场景下，Amazon Bedrock model evaluation job 是正解

题库里多次出现：给定 sample prompts，要比较多个 FMs 的 quality / safety。正解：
  • 把 prompt dataset 存为 JSONL。
  • 上传到 Amazon S3。
  • 创建 Amazon Bedrock model evaluation job（模型评估任务）。
  • 候选模型作为 generator（生成器）。
  • 使用 judge model / evaluator model（评判模型）评分。
  • 输出结果到 S3。
不要用 Knowledge Base 生成报告；Knowledge Base 是 RAG，不是模型评估框架。

在“LLM-as-a-judge 大规模自动评分”的场景下，Bedrock evaluation + evaluator model 是正解

LLM-as-a-judge（以大语言模型作为评判者） 适合：
  • 准确性、相关性、完整性、语义一致性。
  • 多语言一致性。
  • 金融/医疗建议 appropriateness。
  • 幻觉检测。
  • 质量阈值 gate。
可使用 Claude Sonnet / Nova 等受支持 evaluator model。要注意 generator model 和 evaluator model 在可用区域、权限上满足 Bedrock 要求。

在“RAG 系统需要同时比较分块策略和两个 FMs”的场景下，retrieval-and-generation evaluation 是正解

只评 retrieval 不够，因为最终质量取决于检索 + 生成。正确配置：
  • Retrieval and generation evaluation（检索与生成评估）。
  • 将每种 chunking strategy 纳入评估数据集。
  • 对 retrieval 用 precision@k、context relevance、context coverage。
  • 对 generation 用 LLM judge 评分，比如 correctness、faithfulness、completeness。
  • 用统一 evaluator model 评估两个 FMs，保证可比性。

在“模型升级后多语言回答不一致，45 分钟内并行评估 15000 对话，CI/CD 阻断部署”的场景下，标准化多语言测试集 + Bedrock evaluation + pipeline gate

正确结构：
  • 为每种语言准备语义等价的 standardized multilingual conversations（标准化多语言对话）。
  • 并行运行 Bedrock model evaluation job。
  • 评估 semantic similarity（语义相似）、hallucination、policy compliance。
  • CI/CD pipeline 根据质量阈值阻断发布。
性能压测、Route 53/Global Accelerator、上线后每周审计都不能阻止质量退化进入生产。

在“提示版本导致复杂文档摘要不一致”的场景下，prompt regression test 要进 Git/CI

题库中有一题不是 Bedrock Prompt Management，而是更工程化：
  • 在 code repository 中版本控制 prompts。
  • 准备复杂临床文档测试集。
  • 定义可量化指标：factual accuracy、completeness、consistency、ROUGE/BERTScore 等。
  • 自动比较 prompt versions。
  • 记录文档类型与性能模式。
这是因为题目强调“诊断复杂文档不一致、比较既定指标、保存历史记录”，不是单纯发布提示模板。

在“客户服务应用要自动比较多个 prompt templates、模型配置、允许人工反馈、低质量不部署”的场景下，Bedrock evaluation + CodePipeline gate 是正解

  • 使用自定义 prompt dataset。
  • Bedrock evaluation job 自动评分。
  • 人工审核员查看结果并反馈。
  • CodePipeline / CI/CD gate 阈值不达标则 fail deployment。
CloudWatch 运营指标不能替代响应质量评估。

在“3 周医疗文档摘要 PoC，要评估准确性和处理时间，保护隐私”的场景下，匿名数据集 + RAG + judge model 比微调更合适

正确方向：
  • 50–100 份 anonymized patient records（匿名患者记录）。
  • 安全 Knowledge Base / RAG。
  • 比较多个 FMs。
  • LLM judge 评价 accuracy / completeness / processing time。
微调 3 周内风险高、隐私重、验证难。

在“临床 RAG 要高准确、识别幻觉、降低人工审核成本”的场景下，自动 LLM judge + targeted human review 是正解

  • Bedrock evaluations 跟踪 retrieval precision、faithfulness、hallucination rate。
  • 自动化筛选大部分输出。
  • 只把边缘/低分/高风险输出送人工审核。
实体识别置信度不是幻觉率；CloudWatch Synthetics 只能做固定回归，不能覆盖开放式临床问题。

在“React + Amplify + AppSync GraphQL + Lambda resolver + Knowledge Base 超时”的场景下，streaming 改善体验

如果复杂问题慢、同步 resolver 等最终结果导致超时：
  • 用 AWS Amplify AI Kit / streaming response。
  • 或改用流式 API 返回 partial output。
  • 避免简单增加超时和重试，因为会增加负载、成本和重复请求。

在“OpenSearch Serverless + Bedrock KB 同步成功但测试 400/403 授权错误”的场景下，检查 BedrockAgentRuntime 和 AOSS 数据访问策略

题库中此类故障的核心：
  • Lambda execution role 需要调用代理/知识库运行时权限，如 bedrock:InvokeAgent 或相关 runtime 权限。
  • OpenSearch Serverless 不只靠 IAM，还要配置 data access policy（数据访问策略）。
  • 给 Bedrock service role 和应用 Lambda role 授权 aoss:APIAccessAll 以及 collection/index pattern 访问。
  • 若要求大规模自动分配权限，使用基于 pattern 的 collection/index resource rules。

在“模型调用失败、流式响应断裂、输入截断”的场景下，排障顺序

  1. Token budget：CountTokens / max_tokens / context window / chunk size。
  1. Retrieval scope：metadata filtering / reranking / topK。
  1. Runtime metrics：InvocationLatency、ClientErrors、ServerErrors、Throttles。
  1. Retry policy：exponential backoff with jitter，避免重试风暴。
  1. Streaming handler：chunk timeout、partial response buffering。
  1. Trace：X-Ray annotations 按 modelId、prompt version、region 查。
  1. Logs：model invocation logging / CloudWatch Logs / CloudTrail。

5.2 工具倒排索引：评估与排障工具

Amazon Bedrock model evaluation（Bedrock 模型评估）

功能
对应场景
Automatic model evaluation
标准指标评估模型质量。
LLM-as-a-judge
语义质量、安全、相关性、完整性评分。
Custom prompt dataset
S3 中 JSONL，标准化输入。
Custom metrics
业务特定评分维度。
Model comparison
多个 FMs 选择。
RAG evaluation
retrieval / generation 端到端评估。
Output to S3
评估报告、JSONL 结果保存。
CI/CD gate
阈值不达标阻断部署。

Human review（人工审核）

工具
正确场景
Amazon A2I
低置信度 Textract、关键金融/医疗交互。
Step Functions waitForTaskToken
强制人工批准后继续流程。
DynamoDB / S3 audit store
保存审核决定和时间戳。

全局服务倒排索引

Amazon Bedrock

功能
条件反射
InvokeModel
简单同步调用。
InvokeModelWithResponseStream
实时/座席/聊天/长回答降低 TTFT。
Converse API
多轮对话、跨模型统一 message interface。
ConverseStream
多轮对话 + streaming。
CountTokens
请求前 token 估算、成本/配额控制。
PerformanceConfigLatency=optimized
要低延迟，题目明确提到参数。
Provisioned Throughput
稳定吞吐、容量保证、固定成本。
Inference profiles
跨区域吞吐和成本/性能优化。
Geographic CRI
数据驻留在地理边界内。
Model invocation logging
记录 prompt/response/metadata 到 S3/CloudWatch。
Per-request metadata tagging
成本归因、业务部门分摊。
Prompt caching
重复长上下文降延迟/输入 token 成本。

Amazon Bedrock Knowledge Bases

功能
条件反射
RAG
权威资料 grounding。
Citations
可追溯、医疗/金融/法律审计。
Metadata filtering
候选集太脏、时间/类型/来源过滤。
Reranking
语义相似但不真正相关。
Semantic chunking
超长文档避免截断。
Hierarchical chunking
科学论文、章节上下文。
OpenSearch Serverless
大规模、低运维、复杂过滤。
Aurora pgvector
中小规模、SQL + vector、低运维。
S3 Vectors
低成本、简单 metadata。
Neptune Analytics
图关系 RAG。

Amazon Bedrock Guardrails

功能
条件反射
Denied topics
禁投资建议/保证收益/高风险主题。
Word filters
禁竞争对手名/专有词。
Sensitive information filters
PII mask/block。
Contextual grounding
摘要/RAG 幻觉检测。
Content filters
毒性、暴力、侮辱、prompt attack。
Detect action
要通知但不阻断。
Block action
强合规阻止。
Guardrail metrics
CloudWatch 干预告警。

Amazon Bedrock Prompt Management

功能
条件反射
Prompt versioning
提示历史、回滚。
Prompt variants
A/B 测试。
Prompt variables
结构化必填输入、模板复用。
Approval workflow
临床/金融/媒体内容审批。
Prompt governance
多团队多区域统一提示标准。
Integration with Flows
主应用以托管提示运行。

Amazon Q Business / Q Developer

服务
条件反射
Amazon Q Business index
企业内部资料安全问答，客户保留数据控制权。
Q Business S3 ACL file
S3 prefix + IAM Identity Center group 文档访问控制。
User Store / identity mapping
查询时按用户/组过滤文档。
Amazon Q Developer customization
让代码建议遵守内部库、算法、代码风格，不改项目目录。
Q Developer admin dashboard
公司级采用率、活跃/低利用用户、接受代码行数。

AWS Glue / Lake Formation / Macie

服务
条件反射
Glue Crawler
自动发现数据源。
Glue Data Catalog
数据源注册、元数据、血缘基础。
Glue Data Quality
数据质量验证和指标。
Glue ETL
非结构化数据预处理、分块。
Lake Formation LF-tags
跨账户、列级、属性化数据湖权限。
Amazon Macie
S3 静态敏感数据发现/分类。

Step Functions / Lambda / API Gateway / EventBridge

服务
条件反射
Step Functions Standard
长流程、人工审批、可靠状态。
Step Functions Parallel/Map
并行批处理。
waitForTaskToken
人工介入。
Lambda
轻量业务逻辑、token 预算、API glue。
API Gateway WebSocket
实时双向推送。
Lambda authorizer
多 webhook 身份认证。
EventBridge
S3 上传、新模型发布、状态变化触发。
SQS
异步缓冲；实时低延迟题慎选。

Observability（可观测性）

工具
条件反射
CloudWatch Metrics
token、延迟、错误、throttle。
CloudWatch Logs
模型/知识库/应用日志。
CloudWatch Anomaly Detection
token/cost 异常。
CloudWatch Composite Alarm
技术指标 + 业务指标。
AWS X-Ray
分布式延迟来源追踪。
Amazon Managed Grafana
多 stakeholder 自定义可视化。
QuickSight
报表/BI，实时运维告警不是首选。
CloudTrail
API 审计，不是 prompt-response 内容日志。

考试条件反射速查表

需求关键词
选型反射
“批准文档”“引用来源”“不得幻觉”
Bedrock Knowledge Bases + RetrieveAndGenerate + citations + Guardrails contextual grounding。
“语义相似但不相关”
Reranking。
“检索范围太大/时间跨度太长”
Metadata filtering。
“法律引文/医疗缩写/精确术语”
Hybrid search。
“千万级向量/低延迟/复杂过滤”
OpenSearch Serverless / Service。
“少于百万/低运维/vector + metadata”
Aurora PostgreSQL Serverless + pgvector。
“客户拥有数据，供应商安全访问企业索引”
Amazon Q Business。
“Q Business S3 按部门权限”
bucket 顶层 acl.json + IAM Identity Center group。
“非结构化数据质量/元数据/分块”
Glue Crawler + Data Catalog + Glue ETL + Glue Data Quality。
“列级跨账户数据湖权限”
Lake Formation LF-tags。
“静态 S3 敏感数据分类”
Amazon Macie。
“实时 PII 输入输出过滤”
Bedrock Guardrails sensitive information filters / Comprehend PII。
“禁止投资建议/保证收益”
Guardrails denied topics。
“禁竞争对手名”
Guardrails word filters。
“只检测不阻断”
Guardrails detect action。
“生产强合规”
Guardrails block action。
“私有 Bedrock 调用路径”
PrivateLink interface VPC endpoint for Bedrock runtime。
“提示版本/审批/参数化”
Bedrock Prompt Management。
“GenAI 可视化工作流”
Bedrock Flows。
“长期澄清/人工审批”
Step Functions Standard + waitForTaskToken。
“并行模型分析”
Step Functions Parallel。
“Step Functions 超 256KB”
S3 存大对象，状态传 URI。
“实时语音/座席辅助”
Transcribe Streaming + InvokeModelWithResponseStream + WebSocket。
“多轮对话统一 API”
Converse API。
“模型工具调用”
Bedrock Agents action groups / AgentCore Gateway。
“多代理分部门”
Supervisor agent + collaborator agents + 专属 KB。
“远程 MCP server 授权”
Lambda + API Gateway + Cognito OAuth。
“不部署代码动态模型路由”
AWS AppConfig + Lambda extension。
“Provisioned Throughput 未使用”
modelId 要填 provisioned model ARN。
“高峰限流但不要固定成本”
Cross-Region inference profiles。
“数据驻留 + 跨区域吞吐”
Geographic CRI。
“稳定高吞吐低延迟”
Provisioned Throughput。
“请求前 token 预算”
CountTokens API。
“token 异常/成本预警”
CloudWatch token metrics + anomaly detection。
“跨服务找延迟来源”
X-Ray + annotations。
“模型比较/质量安全报告”
Bedrock model evaluation job。
“多语言升级回归”
标准化多语言数据集 + Bedrock evaluation + CI/CD gate。
“RAG 分块策略比较”
Retrieval-and-generation evaluation。
“低置信度扫描件人工审核”
Textract + A2I。
“强制人工批准 AI 建议”
Step Functions waitForTaskToken + DynamoDB 审计。

官方文档参考入口

以下是写作时用于校正服务英文名和功能边界的 AWS 官方文档入口：
  • Amazon Bedrock Knowledge Bases: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
  • Knowledge Bases chunking: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking.html
  • Bedrock Guardrails: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
  • Contextual grounding check: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html
  • Bedrock Flows: https://docs.aws.amazon.com/bedrock/latest/userguide/flows.html
  • Bedrock Flow node types and expressions: https://docs.aws.amazon.com/bedrock/latest/userguide/flows-nodes.html
  • Bedrock model evaluation: https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html
  • LLM-as-a-judge evaluation: https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-judge.html
  • Prompt datasets for evaluation: https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation-prompt-datasets.html
  • Converse API: https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html
  • CountTokens API: https://docs.aws.amazon.com/bedrock/latest/userguide/count-tokens.html
  • Provisioned Throughput: https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html
  • Cross-Region inference: https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html
  • Geographic cross-Region inference: https://docs.aws.amazon.com/bedrock/latest/userguide/geographic-cross-region-inference.html
  • Bedrock monitoring and runtime metrics: https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html
  • Model invocation logging: https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
  • Bedrock Agent multi-agent collaboration: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html
  • Bedrock Agent action groups: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-create.html
  • Bedrock AgentCore overview: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html
  • AgentCore Memory: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html
  • AgentCore Gateway: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
  • AgentCore Observability: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html
  • AWS AppConfig: https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html
  • AWS AppConfig Agent Lambda extension: https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html
  • Amazon Q Business S3 ACLs: https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/s3-user-management.html
  • Amazon Q Business user store: https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/principal-store-hiw.html