硅基生物的培养皿 http://blog.steaky.me/ 发现一点有趣的东西吧 Sun, 09 Aug 2026 11:07:41 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, steaky <![CDATA[[灵光一闪]拒绝未经认证的道德CA签发证书]]> http://blog.steaky.me/article/3ad3279e-3172-8042-bfa7-fa5a780bc9d5 http://blog.steaky.me/article/3ad3279e-3172-8042-bfa7-fa5a780bc9d5 Thu, 30 Jul 2026 00:00:00 GMT
最近有AI大厂买大量珍稀书籍扫描，做法是直接切掉书脊，等于获得了数字版本，却毁灭了原本，有讨论问这样训练AI你支持吗？我更关心的是，有些人认为“这不应该，这不道德”等等，这背后的判断逻辑机制、价值认同锚点，是被谁、如何灌输进去的？
举个例子，只要资本告诉你【尊重知识版权是应该的】，集体被灌输了所谓正义信念后，就被做局割韭菜了，慢慢的你付出了沉没成本，就会替镰刀喊话，还自以为正义。可见社会道德系统是后天建构的，信念是可以被操纵的。那么我们真正应该做的不是陪着人争论观点对错，而是研究如何讲故事割韭菜，不是吗？“版权正义”不是自然律，而是某套制度为了特定社会目标建立出来的规范；它后来又被道德化，使人忘记它原本只是制度选择。
人类的道德分为三个层次
  • 第一层是耶利米书31:33说的，神要把他的教导（תּוֹרָתִי）写在人的心板上，而不是希腊哲学意义上的普遍伦理，到了罗马书2:15，说的是律法的功用（ἔργον）写在人的心里，而不是律法本身（ὁ νόμος），这意味着人内部存在一种结构能够回应神的秩序，这是最里面的一层。
  • 然后是第二层，借着这第一层的秩序，产生了各种礼仪、司法、财产、婚姻等基本社会制度，在这一层上，神在出埃及记和利未记里亲自定义了一些条条框框。
  • 在第三层才是什么衣服正经、什么职业高尚、该不该买正版之类的东西。
可见神写进去的道德是十分薄的一层底层代码，比如不可谋杀（לֹא תִּרְצָח），但是从第二层建构开始，人过多的参与与推演就进入法利赛人式的堕落了，人对创造秩序和启示规范的二次扩展，开始把推导物等同于神命令。第二和第三层东西本身没有共通性，每个人甚至每个文化的处理方式都是不一样的，所以它的治理边界可以无限扩张，随着这种建构的扩张，遵守边界的人开始认为自己比别人义，人的传统开始冒充神的命令，并审判别人。这系列动作也就是马可福音7:8（离弃神的命令，拘守人的传统）乃至整本圣经都在批判的东西。
所以我不希望过多地参与这种根基都站立不住的讨论，非要讨论的话，我希望在创造秩序（神是怎么定义道德的）和道德建构（人是怎么控制道德的）的这一层讨论，一旦陷入具体的是非分辨，我们就沦为别人棋盘上的棋子而不自知了。
我自己做很多常人看来无法接受的事情，都没有任何心理负担，也不吃“别人都如何如何”的那一套，除非给我解释清楚道德的来源和合法性，让这套系统在我这里有一个合适的层级权限才可以进入我的道德评审模块，否则那些东西没有良心定罪权。
8月9日更新，更强化了我前面的观点：
今天看到以色列官员发了一篇推文，被X平台标记为“违规但显示”，地址：https://x.com/itamarbengvir/status/2067865510281170957
AI翻译为：
我多次批判过人的某些道德建构纯粹是政治正确，X平台把这贴文标记成违反规则，是毫无旧约圣经常识的，原贴中的母亲哭泣对应耶利米书31:15，人的血不能白流对应申命记32:43，要付出超额报应对应诗篇79:10-12，黎巴嫩应该燃烧甚至原封不动对应撒迦利亚书11:1，所以从圣经的伦理语言体系来看，这段话本身并不因为包含复仇、集体审判、超额报应、敌国燃烧等概念就自动构成道德违规。
X的问题在于它不是一个中性的东西，而是预先规定了一套关于公共语言的伦理边界，如果站在希伯来圣经自己的文本世界里，这种伦理确实完全不是默认前提，那么为什么X采用的现代政治伦理可以直接取得裁判者地位呢，然后把另一套更古老的战争审判伦理标记成不允许说的话？这和封杀川普没有任何区别。
一个自称多元包容的西方社会还是有一套构建出来的伦理基础公约数，我拆的就是这个，如果换一套伦理体系（旧约：复仇有正义性），就不包容了，那它的包容就是假的，不是“元包容”，这种谎言一戳就破。就像现代基督教一股脑说要爱仇敌一样，为什么如果我对着女牧师说圣经禁止女牧师，她怎么就不爱我了呢？
任何一个构建出来的“包容”体系背后都有一个“范围/价值锚”，真正的问题是，为什么这套包容体系的作者有定义权和审判权呢？造物主真的给这个作者如此高的权柄了么？所以说人的道德这东西，凡超出神所启示或创造秩序的那部分人造道德规范，本质上都是具有目标函数的社会建构，不是自然律，不应该构成理性判断依据，如果构成依据，则一定带有目的性功利性。
]]> <![CDATA[AWS AIP题库倒排索引式教材]]> http://blog.steaky.me/article/3803279e-3172-8046-a8e3-fd1503f9622d http://blog.steaky.me/article/3803279e-3172-8046-a8e3-fd1503f9622d Mon, 15 Jun 2026 00:00:00 GMT

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

资料来源：用户提供的 AIP 题库（淘宝买的ExamTopics119题版） 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
]]> <![CDATA[AWS AIP题库补漏教材]]> http://blog.steaky.me/article/3a23279e-3172-8009-a096-e3d182a1ce8f http://blog.steaky.me/article/3a23279e-3172-8009-a096-e3d182a1ce8f Sun, 19 Jul 2026 00:00:00 GMT
用途：作为既有“倒排索引笔记”的附录，只补充尚未形成系统选择规则的考纲内容。
范围：包括完全缺失的内容，以及只在题目解析边角出现、但原笔记没有独立整理的弱覆盖内容。
不重复：RAG、Knowledge Bases、分块、元数据过滤、重排序、向量库基础选型、Guardrails、CRI、Provisioned Throughput、CountTokens、Bedrock Flows、Prompt Management、Converse API、Model Evaluation、MCP、多代理分工、流式响应、金丝雀发布、提示评估质量门槛等既有内容。

Domain 1：基础模型集成、数据管理和合规性

1. FM Customization Lifecycle（基础模型定制生命周期）【弱覆盖补充】

题库已经出现 SageMaker Pipelines（SageMaker 流水线）、模型重新训练、自动部署和回滚，但下面几个考纲概念没有形成完整索引。
概念
是什么
什么时候用
多种选择时怎么选
Full Fine-tuning（全量微调）
更新模型大量或全部权重，使模型行为适应特定任务
数据量充足、任务稳定、需要较深程度改变模型行为
效果上限较高，但训练成本、存储成本和维护成本最高
LoRA（低秩适配）
只训练少量低秩参数，不大规模修改原模型权重
希望以较低成本完成领域或任务适配
资源有限、需要多个轻量模型变体时，优先于全量微调
Adapter（适配器）
在原模型旁增加少量可训练模块
同一个基础模型需要服务多个不同任务或领域
希望保留共享基础模型，并按场景加载不同适配模块时使用
SageMaker Model Registry（SageMaker 模型注册表）
保存模型版本、模型工件、指标和审批状态
自定义模型需要版本管理、审批、部署和审计
不能只把模型文件放在 S3；需要生产级模型治理时使用
Model Approval Status（模型审批状态）
标记模型是否可以进入生产环境
部署前必须经过人工或自动质量检查
指标未达标保持待审批或拒绝；通过质量门槛后才批准
Model Retirement（模型退役）
停止旧模型的新流量，解除依赖并清理资源
模型被替换、供应商弃用、成本过高或存在风险
先迁移流量和验证替代模型，再删除旧资源；不要直接停机

选择规则

  • 需要改变知识且知识经常变化：使用 RAG（检索增强生成），不是微调。
  • 需要稳定改变模型行为、语气或任务执行方式：考虑 Fine-tuning（微调）。
  • 希望降低定制训练成本：优先 LoRA（低秩适配）或 Adapter（适配器）。
  • 自定义模型进入生产：使用 Model Registry（模型注册表）管理版本、指标、审批和替换。
  • 题目只要求自动重新训练和重新部署：SageMaker Pipelines（SageMaker 流水线）是执行主线；Model Registry（模型注册表）负责模型版本治理，两者不是替代关系。

2. Inference Parameters（推理参数）【弱覆盖补充】

参数
是什么
什么时候调
选择规则
Temperature（温度参数）
控制采样随机性
在稳定性和创造性之间调整
抽取、分类、SQL、结构化输出用低值；创意写作用较高值
Top-k（最高概率候选数）
只允许从概率最高的 K 个 Token（令牌）中采样
需要限制候选范围
K 越小越保守；K 越大候选越丰富
Top-p（累计概率阈值）
从累计概率达到 p 的最小候选集合中采样
需要动态控制候选范围
p 越低越保守；p 越高越多样
Max Tokens（最大输出令牌数）
限制模型最多生成多少 Token（令牌）
控制成本、延迟和输出长度
太小会截断；太大可能增加成本和响应时间
Stop Sequence（停止序列）
模型生成指定字符串后停止
输出有明确终止符或分隔符
适合固定格式、分段输出和避免模型继续发挥

选择规则

  • 要求相同输入尽量稳定：降低 Temperature（温度参数），并固定模型、提示和其他参数版本。
  • 要求创造性：适度提高 Temperature（温度参数）或放宽 Top-p（累计概率阈值）。
  • 排查效果时不要同时大幅修改 Temperature、Top-k、Top-p，否则无法判断变化来源。
  • 参数名称、支持范围和默认值可能因模型不同而不同，应按具体 FM（基础模型）的接口能力配置。

3. Structured Output Validation（结构化输出校验）【弱覆盖补充】

题库已经出现“让模型输出 JSON”，但提示模型输出 JSON 不等于系统能可靠接收结构化数据。
概念
是什么
什么时候用
多种选择时怎么选
JSON Schema（JSON 模式）
定义字段名称、数据类型、必填字段、枚举值和嵌套结构
模型输出要交给程序、工作流或工具继续处理
比仅在提示中写“请输出 JSON”更严格
Schema Validation（模式校验）
在模型输出后验证是否符合 JSON Schema
下游不能接受缺字段、错类型或非法枚举
所有机器消费的关键输出都应校验
Parameter Validation（参数校验）
检查 Agent（代理）工具调用参数是否完整、合法和在允许范围内
Agent 调用 Lambda、API、数据库或有副作用的工具
结构正确仍不代表业务合法，还要检查范围、权限和状态
Output Repair（输出修复）
在格式不合法时重新生成或修复结构
低风险格式错误且允许重试
只能修格式，不能证明内容事实正确
Deterministic Post-processing（确定性后处理）
用普通代码追加固定字段、模板内容或强制格式
某段内容必须 100% 出现
确定性要求交给代码，不要依赖模型“尽量遵守”

选择规则

  • 只供人阅读：提示约束通常可以接受。
  • 供程序解析：JSON Schema（JSON 模式）＋ Schema Validation（模式校验）。
  • Agent 调用真实工具：再加 Parameter Validation（参数校验）、IAM 最小权限和幂等控制。
  • 固定免责声明、促销语或监管文本必须出现：使用 Deterministic Post-processing（确定性后处理），不要靠 Prompt（提示词）生成。

Domain 2：实施与集成

4. Safeguarded Agent Workflows（受保护的代理工作流）【真正缺口】

Agent（代理）不能只会调用工具，还必须能够被限制、终止和降级。
控制
是什么
什么时候用
选择规则
Stopping Condition（停止条件）
达到完成、失败或风险状态后终止工作流
任务有明确完成标准
比让模型自行判断“是否结束”更可靠
Maximum Iterations（最大迭代次数）
限制代理最多推理或调用工具多少轮
防止循环推理和重复工具调用
所有生产代理都应设置合理上限
Timeout（超时）
限制单次工具调用或整个任务的运行时间
外部 API、Lambda 或模型可能卡住
Lambda 控制单步骤超时；Step Functions 控制整体流程
Circuit Breaker（熔断器）
下游连续失败后暂时停止继续调用
下游服务故障、超时或限流持续发生
防止故障放大、成本失控和大量无意义重试
IAM Resource Boundary（IAM 资源边界）
限定代理可访问的服务、资源和操作
代理能够执行真实业务动作
即使模型判断错误，也不能越权操作
Tool-call Budget（工具调用预算）
限制单个任务允许调用工具的次数或成本
工具昂贵、耗时或有副作用
超预算后停止、降级或转人工
Idempotency（幂等性）
相同请求重复执行不会产生重复副作用
发送消息、创建订单、写数据库、付款等操作
代理重试有副作用的工具时必须使用幂等键
Human Approval（人工审批）
高风险动作执行前暂停并等待人工确认
删除、付款、发布、权限变更
风险由业务后果决定，不应只看模型置信度

选型关系

  • Step Functions（步骤函数）：负责停止条件、整体超时、分支、重试、补偿和人工审批。
  • Lambda（函数计算）：负责单个工具的参数校验、执行超时和错误转换。
  • IAM（身份与访问管理）：负责代理即使判断错误也无法越权。
  • Circuit Breaker（熔断器）：负责下游持续故障时停止继续放大问题。
  • Idempotency（幂等性）：负责重试不会重复产生业务结果。

高频陷阱

  • 指数退避只能缓解暂时错误，不能代替 Maximum Iterations（最大迭代次数）和 Circuit Breaker（熔断器）。
  • Guardrails（安全防护）控制内容安全，不负责阻止代理无限调用工具。
  • Timeout（超时）只能终止执行，不会自动撤销已经完成的外部副作用。

5. GenAI Gateway Architecture（生成式 AI 网关架构）【真正缺口】

GenAI Gateway（生成式 AI 网关）不是特指一个独立 AWS 服务，而是企业统一管理模型调用的集中入口架构。
能力
是什么
什么时候需要
选择规则
Provider Abstraction（模型提供商抽象）
客户端只调用统一接口，不直接绑定具体模型
多模型共存或未来可能更换模型
减少应用与模型 ID、供应商 API 的耦合
Model Routing（模型路由）
根据任务、成本、延迟、地区和风险选择模型
不同请求需要不同能力和价格
简单任务路由小模型；复杂任务路由高能力模型
Centralized Guardrails（集中式安全防护）
所有应用通过统一入口执行安全策略
多团队必须遵守同一治理要求
避免每个应用自己实现一套过滤逻辑
Quota Enforcement（配额执行）
按用户、租户、部门限制请求数、Token 或预算
多部门共享模型能力
与 CountTokens（令牌计数）和用量指标结合
Data Residency Routing（数据驻留路由）
根据数据所属地区限制可调用 Region（区域）
跨国业务和监管场景
合规优先于跨区域容灾和最低延迟
Fallback Routing（后备路由）
主模型不可用时切换备用模型或降级方案
有可用性要求
备用模型必须验证能力、格式和安全策略是否兼容
Central Observability（集中可观测性）
统一记录模型、提示、版本、延迟、Token 和错误
需要审计、成本归属和故障分析
日志中注意 PII（个人身份信息）脱敏和保留策略

与常见组件的区别

组件
主要职责
Amazon API Gateway（API 网关）
对外暴露 API、认证、限流、请求验证；它可以是 GenAI Gateway 的入口组件
AWS AppConfig（AWS 应用配置）
动态保存和发布路由规则、模型参数、功能开关
AWS Step Functions（AWS 步骤函数）
执行复杂、确定性、可审计的动态路由和降级流程
Amazon Bedrock Intelligent Prompt Routing（Bedrock 智能提示路由）
在受支持模型范围内按提示复杂度进行托管式模型路由
GenAI Gateway（生成式 AI 网关）
把认证、路由、配额、Guardrails、日志、成本和数据驻留统一成企业模型入口

选择规则

  • 只需要暴露一个 HTTP API：Amazon API Gateway。
  • 路由规则要无代码更新：AWS AppConfig。
  • 路由步骤复杂且需要完整执行历史：AWS Step Functions。
  • 多应用、多模型、统一治理：GenAI Gateway Architecture（生成式 AI 网关架构）。
  • 不要把“使用 API Gateway”自动等同于“已经完成生成式 AI 网关治理”。

6. Cross-environment Integration（跨环境集成）【小型补漏】

题库已经覆盖混合部署和边缘部署，但官方考纲还点名了以下两个服务。
概念
是什么
什么时候用
不要混淆
AWS Outposts（AWS 本地扩展基础设施）
把 AWS 管理的基础设施部署到客户本地数据中心
本地数据集成、低延迟、本地监管要求
不代表所有 AWS 云服务都能直接运行在 Outposts
AWS Wavelength（AWS 电信网络边缘计算）
把计算能力放到电信运营商 5G 网络边缘
移动网络、5G、极低网络延迟
不是普通企业本地数据中心方案
Secure Cloud-to-On-premises Routing（云到本地安全路由）
通过专线、VPN 和私网路由连接云与本地系统
原系统留在本地，但需要调用云上 FM
网络私有不等于数据自动合规，仍需检查数据驻留和脱敏

一行选择

  • 企业本地数据中心：AWS Outposts 或安全混合网络。
  • 电信 5G 边缘：AWS Wavelength。
  • 只是模型需要在设备侧运行：考虑边缘模型部署，不要看到“边缘”就选 Wavelength。

Domain 3：AI 安全、保障与治理

本领域无新增大章节

既有倒排索引笔记和错题集已经覆盖：
  • Guardrails（安全防护）功能矩阵
  • Prompt Injection / Jailbreak（提示注入／越狱）
  • PII（个人身份信息）检测与脱敏
  • SCP（服务控制策略）、IAM、VPC Endpoint（VPC 端点）
  • 数据驻留、审计、数据血缘、模型卡
  • Fairness Evaluation（公平性评估）、Bias Drift（偏差漂移）
  • Citation（来源引用）、Evidence Presentation（证据展示）、Agent Trace（代理跟踪）
只补充一个判断：
Confidence Score（置信度分数）不能直接等同于“可以自动执行”。是否转人工还要结合 Business Risk（业务风险）、规则校验结果、检索依据和历史准确率。高风险动作即使置信度高，也可能仍需人工审批。

Domain 4：生成式 AI 应用运营效率与优化

7. Intelligent Caching（智能缓存）【真正缺口】

缓存类型
是什么
什么时候用
多种选择时怎么选
Exact Cache（精确缓存）
完全相同的规范化请求直接复用旧结果
请求重复度高、输出稳定
最简单、误命中风险最低
Deterministic Request Hashing（确定性请求哈希）
把规范化请求和关键版本信息计算成缓存键
需要精确判断两个调用是否等价
缓存键必须包含模型、提示、参数和权限上下文
Result Fingerprinting（结果指纹）
为输入、配置和输出建立可追踪的唯一标识
需要防止旧版本结果被错误复用
用于审计、去重和缓存版本管理
Semantic Cache（语义缓存）
通过 Embedding（嵌入）判断新问题是否与旧问题语义相近
FAQ、客服、重复意图较多
命中率高于精确缓存，但必须设置相似度阈值和安全边界
Prompt Caching（提示缓存）
复用长系统提示、固定上下文或重复前缀的处理结果
多次请求共享大量相同上下文
重点降低重复输入 Token 成本和首响应延迟
Edge Cache（边缘缓存）
在靠近用户的位置缓存公共响应
公共、非个性化、高重复内容
不适合敏感数据、强实时数据和按权限变化的内容
Tool-result Cache（工具结果缓存）
缓存外部 API、检索或计算结果
工具调用昂贵且数据短期稳定
使用 TTL（生存时间）并按数据新鲜度失效

缓存键至少考虑

  • Tenant / User（租户／用户）
  • Authorization Scope（授权范围）
  • Model ID / Version（模型 ID／版本）
  • Prompt Version（提示版本）
  • Inference Parameters（推理参数）
  • Guardrail Version（安全防护版本）
  • Knowledge Base / Data Version（知识库／数据版本）
  • Request Content（请求内容）

选择规则

  • 完全相同且确定性强：Exact Cache（精确缓存）。
  • 文本不同但意图高度重复：Semantic Cache（语义缓存）。
  • 大量共享长系统提示：Prompt Caching（提示缓存）。
  • 公共静态内容：Edge Cache（边缘缓存）。
  • 实时价格、库存、权限敏感结果：不缓存或设置短 TTL，并严格隔离。
  • 大多数请求都是独一无二：缓存收益低，应优先优化检索、模型和调用路径。

高频陷阱

  • 只把用户问题作为缓存键，会造成跨租户泄漏、版本污染和旧知识返回。
  • 缓存降低模型调用次数，但不会自动保证答案仍然新鲜。
  • Semantic Cache（语义缓存）的相似不代表业务等价；付款、医疗、法律等高风险请求不应仅凭语义相似复用结果。

8. Vector Store Operations（向量存储运维）【弱覆盖补充】

原笔记已覆盖向量库与索引的基础选型，此处只补“上线后怎么维护”。
症状或任务
应关注什么
处理方向
Vector Query Latency（向量查询延迟）持续升高
索引大小、分片热点、内存、并发和查询参数
扩容、重新分片、索引优化或减少候选集合
Recall（召回率）下降
Embedding（嵌入）质量、数据分布变化、分块和查询预处理
重新评估 Embedding、分块、混合搜索和重排序
Stale Results（陈旧结果）
数据源已更新但向量索引未同步
检查增量同步、变更事件、失败重试和版本时间戳
Vectorization Failure（向量化失败）
文档格式、输入长度、模型版本和批处理失败
隔离失败对象，记录原因，重试或重新预处理
Automated Index Optimization（自动索引优化）
按性能指标调整索引或触发重建
适合大规模、持续变化的向量库
Data Quality Validation（数据质量校验）
空内容、重复文档、错误元数据、无效向量
在摄取和同步阶段拦截，而不是等查询失败后处理

排障切分

  • 检索不到：先看摄取、同步、向量化和权限。
  • 检索结果不相关：看 Embedding、分块、搜索方式和重排序。
  • 检索正确但回答错误：问题在生成 Prompt、上下文使用或模型，不要继续只调向量库。
  • 延迟问题：看索引、分片、候选量和并发；不要第一反应更换生成模型。

Domain 5：测试、验证与故障排除

9. Agent Evaluation（代理评估）【真正缺口】

Model Evaluation（模型评估）关注“回答质量”；RAG Evaluation（RAG 评估）关注“检索和依据”；Agent Evaluation（代理评估）关注“任务是否真正完成”。
指标
是什么
什么时候用
判断重点
Task Completion Rate（任务完成率）
有多少任务最终达到业务目标
所有任务型代理
最核心指标；回答流畅不等于任务完成
Tool Selection Accuracy（工具选择准确率）
代理是否选择了正确工具
一个代理可调用多个工具
选错工具可能造成错误、延迟和安全风险
Tool-call Success Rate（工具调用成功率）
工具调用是否成功返回预期结果
API、Lambda、数据库和外部系统
区分参数错误、权限错误和下游故障
Parameter Accuracy（参数准确率）
工具参数是否正确、完整且符合业务约束
结构化工具调用
JSON 合法仍可能传错账户、日期或金额
Unnecessary Tool-call Rate（无效工具调用率）
代理调用了多少不必要的工具
成本和延迟优化
过高说明任务分解或工具描述有问题
Repeated Tool-call Rate（重复工具调用率）
是否循环调用相同工具
检测代理失控
与最大迭代次数、熔断和幂等一起看
Multi-step Reasoning Quality（多步骤推理质量）
每个中间步骤是否合理并支持最终结果
复杂、多阶段任务
不只检查最终答案，还要检查中间状态和工具结果
Cost per Completed Task（每个完成任务的成本）
完成一个成功任务的全部模型和工具成本
比较不同代理架构
比 Cost per Request（单请求成本）更有业务意义
Time per Completed Task（每个完成任务的耗时）
从用户发起到任务真正完成的时间
有 SLA 的代理系统
不能只看单次模型延迟

与其他评估的选择

要评估什么
优先指标
模型写得好不好
相关性、事实准确性、一致性、流畅性
RAG 找得对不对
检索相关性、上下文匹配、召回率、检索延迟
回答是否依据来源
Groundedness / Faithfulness（有据性／忠实度）
代理有没有办成事情
Task Completion Rate（任务完成率）
代理工具用得好不好
Tool Selection Accuracy、Tool-call Success Rate
代理是否划算
Cost per Completed Task（每个完成任务的成本）

10. User-centered and Business Evaluation（用户中心与业务结果评估）【小型补漏】

题库已覆盖自动评估、自定义测试集、人工反馈和部署质量门槛；此处只补官方考纲要求的“用户与业务结果”视角。
指标或机制
是什么
什么时候用
注意点
Feedback Interface（反馈界面）
用户对回答点赞、评分或标记问题
持续收集真实使用反馈
用户满意不等于事实正确，要与质量指标结合
Annotation Workflow（标注工作流）
人工对输出进行分类、评分和纠错
自动指标难以覆盖主观质量时
高成本，适合抽样和高风险场景
Reformulation Rate（问题改写率）
用户需要重新表达多少次才能得到可用结果
判断系统是否理解用户意图
高改写率可能来自检索差、提示差或模型能力不足
Abandonment Rate（放弃率）
用户在任务完成前离开
评估延迟和体验
需要结合会话阶段定位问题
Escalation Rate（转人工率）
有多少任务需要人工接管
客服和自动化代理
高风险任务主动转人工不一定是坏事
Business Outcome（业务结果）
转化率、处理时间、成功任务数、节省成本等
判断 GenAI 是否产生实际价值
不要只用 Token 和延迟代替业务价值
Stakeholder Reporting（利益相关方报告）
自动汇总质量、成本、风险和业务指标
管理、审计和模型比较
报告应区分模型、提示、版本、语言、地区和用户切片

一行规则

技术指标回答“系统运行得怎样”，用户指标回答“用户是否能用”，业务指标回答“这套系统是否值得继续运行”。

临考最终压缩

  1. 模型定制：改知识用 RAG；改行为用 Fine-tuning（微调）；低成本适配用 LoRA（低秩适配）／Adapter（适配器）；生产版本治理用 Model Registry（模型注册表）。
  1. 结构化输出：让模型“输出 JSON”不够；机器消费必须加 JSON Schema（JSON 模式）和 Schema Validation（模式校验）。
  1. 代理控制：Stopping Condition（停止条件）＋ Timeout（超时）＋ Circuit Breaker（熔断器）＋ IAM Resource Boundary（IAM 资源边界）＋ Idempotency（幂等性）。
  1. 企业入口：API Gateway 是 API 组件；GenAI Gateway（生成式 AI 网关）是统一模型路由、配额、安全、日志、成本和数据驻留的架构。
  1. 缓存：完全相同用 Exact Cache（精确缓存）；语义重复用 Semantic Cache（语义缓存）；长固定上下文用 Prompt Caching（提示缓存）；缓存键必须包含租户、权限和所有版本。
  1. 向量运维：检索不到看摄取与同步；检索不准看 Embedding、分块和排序；检索正确但回答错，看生成阶段。
  1. 代理评估：不要只评回答质量；核心是 Task Completion Rate（任务完成率）和 Tool-use Quality（工具使用质量）。
  1. 业务评估：技术指标、用户指标和业务结果必须分开看。
]]> <![CDATA[微服务架构设计模式整理——上篇（概念篇）]]> http://blog.steaky.me/article/2793279e-3172-808a-9047-f1806b19692c http://blog.steaky.me/article/2793279e-3172-808a-9047-f1806b19692c Tue, 14 Oct 2025 00:00:00 GMT
⚠️
本文是Manning的《微服务架构设计模式》一书的整理笔记，并加入了一些自己的想法，给尚未读过这本书的人探探路。这本书的代码部分是基于Java编写的，我个人希望脱离Java体系的捆绑，所以文中不会照搬书中的Java内容，只整理架构性、思路性的东西。
本文是笔记的第一部分，描述微服务的整体概念，主要讨论传统单体模式服务的缺陷，应该如何按照业务领域拆分服务，服务之间的通信方式等问题。

第1章：逃离单体地狱

单体地狱指的是大泥球模式，比如部署在Tomcat上的巨大WAR包，里面承载了累计多年的极端复杂的业务逻辑和应用架构，虽然这种模式在开发早期有方便快捷的优点，但时间长了，过度的业务复杂性会吓退开发者，复杂的应用架构也难以理解，由于牵一发动全身，开发速度缓慢，架构紧身衣导致难以扩展，致使开发周期变长，屎上雕花，也会导致CICD变慢、难以测试，系统交付变慢，且长期依赖单一的过时技术栈比如很老版本的Spring难以升级。
微服务架构是把应用程序功能性分解为一组服务的架构风格，服务作为模块化的单元，服务的API为它构建了边界，让每个服务可以单独水平扩展，并且每个服务具有自己的数据库（不是指机器），这实现了低耦合。微服务架构和SOA的区别是，一不使用事件总线而是REST或gRPC通信，二服务之间数据库独立，三每个服务体量更小。
微服务架构的好处是每个服务可以独立扩展、团队自治，CICD快，容易采纳新技术，容易测试、容错型高；问题在于如何拆分服务（可能涉及DDD），如何处理分布式系统复杂性，如何跨部门协作，什么时候转向微服务架构。

第2章：服务的拆分策略

传统三层架构的弊端可以用六边形架构解决，它给程序设置了多个出入站适配器，可能是REST接口，可能是DAO类，虽然将业务逻辑和外部世界解耦了，但它可能还是一个大而全的东西。而微服务架构则是从服务视角，基于业务能力或DDD的方式把服务切分成了很多松耦合的可能是六边形的模块，模块之间通过适配器通信。微服务架构的建立是一个逐渐演化的过程：
第一步要将需求识别为系统操作。在这一步中，抽象的需求将被转化为领域模型，产生词汇表，并描述每个系统操作的行为，套用DDD的思路，行为有命令型和查询型两种。
第二步要确定如何分解服务。可以采用业务架构学派的方式根据业务能力拆分服务，产物大概是数据驱动的，但是这可能被数据库反向捆绑服务拆分，更推荐采用领域驱动设计的方式明确界限上下文、实体、聚合等，让设计由行为驱动。不论如何划分，都要注意模块的单一职责原则和CCP（共同闭包）原则。
第三步要确定每个服务的API。在这一步要把系统操作分配给具体的服务，确定服务间协作需要的API，但是在这个过程中要考虑进程间通信和分布式一致性等复杂问题。

第3章：微服务架构中的进程间通信

本章分为三部分，分别介绍了通信概述、同步通信、异步通信三个话题。

通信概述

首先是服务之间的交互方式，分为同步和异步交互，同步交互只有一对一的请求响应模式，这会导致线程阻塞和进程间耦合，而异步模式在子线程或消息队列中进行，不会阻塞整个进程，又分为一对一和一对多两种情况，一对一的情况下，有异步请求响应模式和单向通知模式，一对多的情况下，有发布订阅模式（比如在AWS里通过SNS+多个SQS调用多个Lambda函数）和发布异步响应（事件驱动）模式。
进程间的通信依赖于API，类比编程语言中的接口，它屏蔽了底层实现细节。在单体服务中，两个服务之间的接口定义和调用不匹配会导致编译失败，但在微服务中无法精确控制调用端的更新，且API会演化，这就需要使用版本号加旧版本适配器（如果更细了大版本，表示版本不兼容）控制API的行为，并且要把版本号暴露在URL或MIME类型中。
消息的格式分为文本和二进制两种，文本格式指XML或JSON，它们有很好的可读性，但通信开销大，二进制格式有Protocol Buffer和Avro，它们通信开销小但不可读。二者都定义了消息格式，前者可以增加消息格式约束，后者通过IDL（接口描述文件）来确定消息的内部格式。

同步通信

一个服务对另一个服务的远程过程调用（RPC）通过适配器（代理）实现，适配器中封装了底层通信协议细节，通信协议又分为REST（基于 HTTP+JSON）和gRPC（基于HTTP/2+Protobuf）两种。
首先是REST，最流行的RESTful接口规范是OpenAPI规范，它以资源（比如订单）为中心，通过GET、POST、PUT等操作谓词定义对资源的操作，并且可以对GET的结果做CDN缓存。但缺点在于，首先它是个类似于数据库高范式的紧身衣，难以遵守，最终沦为传统RPC风格，其次它不太擅长处理跨多资源的处理，容易让URL的设计长得十分难看偏离REST风格。（个人认为让RESTful彻底成功的点在领域建模，但是几乎没有团队能掌握DDD设计纯血模型）
然后是gRPC，它有RPC风格API简单容易设计契约清晰的优势，且性能快，但是要考虑老防火墙能不能放行HTTP2的问题。（书中说gRPC是REST的替代，我个人认为不能把系统设计风格和技术选型混为一谈）
断路器模式——当一个服务调用另一个服务时，被调用方可能会因为负载过高迟迟不响应，或者进程挂掉了，这会拖垮调用方（比如连接池），如果调用方一直重试，甚至拖垮API Gateway导致雪崩（云服务有保护设置，但自己部署就有问题）。处理方式是实现一个API Gateway级别的断路器。粗略来说，可以通过监控记录请求失败次数或超时情况，把失败的请求用一个预设好的失败来响应，而不是不给响应，之后再安排其他逻辑试探服务是否恢复了，让API Gateway继续指向被调用方。
服务发现——由于在云上服务可能会被部署到随机IP地址且随时改变，所以让调用者动态获取被调用者的位置成为了一种刚需，这就需要一个服务名称和地址的映射表，这个应该和表服务可以做再应用层，也可以做在infra层，它需要提供的服务有让服务自注册的API，让服务查询其他服务进行客户端发现的API，负责心跳监控和服务注销的机制，和一个数据映射表。在应用层有Spring Cloud/etcd等可以实现，但是这会带来技术栈的捆绑，做心跳检查也会带来服务间耦合，通常建议做在infra层，比如使用AWS Cloud Map，或者依赖负载均衡器，或者用k8s。

异步通信

在这种模式下服务之间通过消息通信，彼此约定好消息头和消息体的结构，服务之间的通信通常通过中间件比如SQS解耦，服务1把消息发给SQS1，服务2订阅SQS1处理消息，然后把响应消息发给SQS2，服务1订阅SQS2处理响应，两个消息之间共享相同的ID来标记业务上的关联性。中间件队列服务的选择则要考虑队列容量、消息顺序、消息分片、重复发送、失败重试、死信队列、消息延迟、可持久性、运维成本等多方面的权衡，避免让中间件本身成为瓶颈，还要考虑保持应用逻辑能够冪等地处理消息。
一个难点是会因为外部状态改变的事务性消息，比如写数据库后要给原始服务通过SQS返回消息，但是这两件事没法放在一个分布式事务里，此时如果想避免出现部分失败，则需要使用事务性发件箱模式（Transactional Outbox Pattern），思路是执行数据库操作时，在同一个事务里更新一个OUTBOX表存储消息（需要定期清理这张表），然后通过数据库本身的机制对外发消息，比如通过RDS CDC或DynamoDB Streams等数据库内建机制捕捉OUTBOX表的更新，驱动Lambda函数通知SQS将消息传递给下游服务，这样即便Lambda函数执行失败了，也能实现后续处理的可重放，且没有丢失数据。这个模式的代价是多了一张表，增加了DB压力，还要保障后续处理的幂等性。
异步通信带来的好处还有提高了程序整体的可用性，因为在由多个服务组成的系统中，整体的可用性取决于可用性最差的部分，如果希望最大化系统的可用性，就需要最大程度消除服务之间的同步性。
 
]]> <![CDATA[微服务架构设计模式整理——中篇（基盘篇）]]> http://blog.steaky.me/article/28e3279e-3172-80c4-b5e2-e42a2d846d1f http://blog.steaky.me/article/28e3279e-3172-80c4-b5e2-e42a2d846d1f Tue, 21 Oct 2025 00:00:00 GMT
⚠️
本文是Manning的《微服务架构设计模式》一书的整理笔记，并加入了一些自己的想法，给尚未读过这本书的人探探路。这本书的代码部分是基于Java编写的，我个人希望脱离Java体系的捆绑，所以文中不会照搬书中的Java内容，只整理架构性、思路性的东西。
本文是笔记的第二部分，描述承载微服务架构所需要的Infra，具体涉及到API Gateway、服务的可配置性、可观测性以及容器化/Serverless部署等，与AWS DVA考试内容有很大的重叠。

第8章：外部API模式

每个微服务都有无数自己的API，而每种客户端（比如Web、移动端、其他应用）一面需要调用多个API满足需求，一面可能要求API为客户端做某些定制化，这就会陷入很多问题，比如，请求数量多性能差用户体验不佳、缺乏封装导致的客户端和微服务在业务逻辑上紧耦合、防火墙内外进程间通信不支持某些协议等种种制约等，此外客户端和服务器的任何一方发生变化或升级都会导致另一边跟着动，管理困难。
为此引入API Gateway模式，它相当于做一个单独的服务，来充当所有微服务的Facade层，除了网页静态资源请求外，其他的API请求都走这个层，这个曾负责把请求转发给后端每个微服务。在这一层里，做的事情是把外部来的一个请求拆分成对多个微服务的多个同步或异步请求，并且可以把HTTP低速通信为内网的gRPC高速通信。
使用API Gateway需要解决的问题是弄清楚谁来负责这样一个巨大的耦合点，在权衡如何划分指责和服务部署流程后，根据对灵活性的取舍，可以让所有微服务的开发团队共同管理，也可以让Web、移动端、其他应用等各个端都维护自己独立的API Gateway。
API Gateway可以解决很多边缘性问题，比如身份验证、访问授权、限流、缓存、指标收集、日志收集等，在AWS中提供了API Gateway的服务，可以通过配置解决上述边缘问题。笔者补充，虽说ALB也能当弱化版API Gateway用，但不推荐反过来把API Gateway当ALB用，因为流量分发不是API Gateway的职责范围，推荐让API Gateway的后面接一个ALB。另外，书中提到AWS的API Gateway不支持组合API是个弊端，我反而认为组合API是个不好的实践，业务逻辑面条代码应该推到后续的Lambda函数或者后端程序里，而不是让API Gateway抗业务逻辑。
API Gateway面对的一个典型场景就是不同客户端会对多个微服务发起数据库查询然后组合它们的结果，这会导致查询层代码极不灵活需要随需求不断扩展方法，一个解决途径是使用GraphQL模式（在AWS中的服务是AppSync），它相当于用一种DSL包装了查询，通过URL参数传递给API Gateway，再由解析逻辑映射为对不同微服务的API调用。笔者补充：这东西相当于对工具产生了强依赖，GraphQL的引入一旦深入体系，迁出成本会显著上升。

第11章：开发面向生产环境的微服务应用

这一章提到了几个边缘性问题话题，首先是服务的安全性，也就是给服务添加认证，整体来讲有两种策略，第一种是给每个API都赋予一个鉴权逻辑，可以通过编程切面实现，但是这让鉴权逻辑混入了业务代码中，更推荐的方式是把这件事做在API Gateway上以摆脱鉴权和业务逻辑的耦合，当然需要付出的代价就是要运维这个Infra。书中详细阐述了如何使用Java实现，但是个人作为一个AWS用户更倾向于使用AWS原生的工具，让请求的第一次去找一个/token的路由，可以在这个路由的背后通过OAuth2或者Lambda等方法返回一个token，以后针对所有API的Header里都带着这个token即可，AWS的API Gateway提供了一套特定的写法来支持HTTP和REST API不同格式如何获取token，并且在其内部实现了会话缓存，不需要重新造轮子。
第二个话题是服务的可配置性，主要提到了一些外部服务比如数据库的连接字符串等位置信息应该如何管理，一种方案是写到程序的运行时里，比如走环境变量，但一旦位置发生了修改就不得不导致服务的重启，另一种方式是从配置中心比如AWS的Parameter Store拉取，这样虽然多了一个infra，但是当配置变更时提供了更大的灵活性，前提是你要为infra付费。
第三个话题提及了微服务的可观测性，即如何在系统复杂度提高后仍能监控其运行状态、性能与故障。这些手段共同形成从可用性 → 可追踪性 → 可诊断性的闭环，使团队能在出现异常时快速定位问题。结合AWS和一些SaaS服务来讲有以下几条
  • 暴露一个/health接口返回200检测服务是否健康(可以让CloudWatch Synthetics Canary主动探测)
  • 把所有服务的日志发送到统一日志流水线，比如CloudWatch Logs
  • 追踪分布式服务之间的延迟，比如使用X-Ray
  • 使用统一服务收集硬件以及业务层面的指标，比如使用CloudWatch
  • 统一管理每个服务的异常信息，比如使用Sentry.io

第12章：部署微服务应用

本章讨论的部署方式不仅适用于微服务，也概括了现代应用在不同封装层次下的典型部署模型，总共提及了四种服务的部署方式。
第一种是直接部署在物理机上，比如部署Java Web程序，就需要在物理机上安装JDK、安装Tomcat，然后通过流水线部署程序，这种方式部署速度快，能让服务吃足了资源，但是对技术栈的封装差，难以约束服务对资源的消耗，同时同一台机器上的服务缺乏隔离，需要手动维护管理每个服务的位置。
第二种方式是部署到虚拟机上，也就是通过EC2+ASG的方式，虚拟机封装了技术栈也隔离了服务实例，但缺陷是机器开得过大可能造成资源浪费，维护云平台还有额外的开销。
第三种方式是打包进Docker容器，它做到了很好的隔离性和对资源的控制，但容器镜像的管理工作是大头，且需要学习成熟的托管解决方案和治理平台，比如ECS和K8S。最后书中给出了用K8S部署一个Java服务的例子，这里不赘述。
第四种方法是Serverless部署加API Gateway访问，也就是Lambda函数，它不需要运维硬件，但限制颇多，需要对Lambda工具本身足够熟悉，且难以支持长连接。书中给出了让Lambda函数适配Spring Boot的例子，个人压根不推荐把Java用作Lambda函数的开发语言。最后书中推荐了Serverless Framework，但我觉得该方案在职责划分上较为模糊，不利于长期治理，推荐Terrafrom管理Lambda函数和API Gateway基础设施，Github Action管理代码和部署。
四种部署方式逐步体现了“封装性增强、资源利用率下降、运维责任转移”的演进规律。
 
]]> <![CDATA[微服务架构设计模式整理——下篇（业务逻辑篇）]]> http://blog.steaky.me/article/2933279e-3172-803b-afe0-d34f1b9115fe http://blog.steaky.me/article/2933279e-3172-803b-afe0-d34f1b9115fe Wed, 22 Oct 2025 00:00:00 GMT
⚠️
本文是Manning的《微服务架构设计模式》一书的整理笔记，并加入了一些自己的想法，给尚未读过这本书的人探探路。这本书的代码部分是基于Java编写的，我个人希望脱离Java体系的捆绑，所以文中不会照搬书中的Java内容，只整理架构性、思路性的东西。
本文是笔记的第三部分，描述如何开发业务逻辑，具体涉及到Saga分布式事务管理、领域驱动设计、事件溯源以及CQRS等话题，这些都是十分重量级的设计方案，本文更倾向于分析使用它们的代价权衡，而不是抄书描绘实现细节。

第4章：使用Saga管理事务

由于服务被分散到多个进程中，而每个进程各自拥有自己的可能是异构的数据库，还使用中间件通信，这导致无法执行传统开发中数据库的分布式事务，在这种情况下需要使用一种叫Saga的模式模拟分布式事务，Saga的一个挑战在于牺牲了ACID（原子性、一致性、隔离性、持久性）中的I（隔离性），只要保证最终一致性，那么就需要使用额外的手段尽量提高隔离性。Saga 实质上从强隔离走向语义隔离，它依赖业务语义（状态机、幂等、版本控制）来‘补偿’数据库的隔离缺口。
Saga的思路是，把一个事务中的一连串调用分成两类，一类是可补偿性事务，比如创建订单后，后续服务如果失败，则执行一个补偿事务对订单创建执行反向操作，另一类是关键性事务，这种事务通常被放在最后，一定成功，必须幂等，不会回滚。
Saga存在两种协调模式，一种是协作式Saga，请求由一个Server发出，并且通过事件在不同Server之间传递，这种方式简单，但难以理解，可能导致服务调用时的循环依赖，并且导致了两个服务要同时修改代码的紧耦合，另一种是编排式Saga，由一个中央类（或者AWS StepFunctions这类中间件）维护一个状态机，状态机启动服务，之后和每个服务通信，这种做法不会引入循环依赖（因为都依赖状态机），每个服务都不需要知道其他Saga参与方服务，改善了关注点隔离，但一个弊端在于把事务的业务逻辑都推进了状态机里，需要防止这里的架构腐化。通常境况下，推荐使用编排式Saga。
Saga模式缺乏对事务隔离性的支持，每个Saga事务做的更新都能被其他Saga看到，这可能会在并发情况下导致数据库异常，比如更新被其他事务覆盖，或者脏读等。有几个对策可以在编码层面缓解隔离性缺失的问题。比如采用语义锁，举例来说，在Saga事务开始时改变Order.state为Pendding，这样其他事务看到这个标记后就可以返回失败或者暂时阻塞；比如在更新之前重新读取数据验证一致性；比如添加版本号；比如把更新操作设计得可以交换顺序；比如通过调整调用时序减缓脏读等。

第5章：微服务架构中的业务逻辑设计

在这一章中讨论了DDD的设计方式如何运用到微服务当中。业务逻辑的组织方式有两种——事务脚本和领域驱动设计(DDD)。
事务脚本就是典型的贫血模型，举个例子来讲，订单类Order里只定义字段，也就是数据结构，不承载方法，方法都由OrderService和OrderDAO承载，这是一种以数据结构和数据流程驱动的设计方法，使用这种模式的后果就是在服务层会形成很长的面条代码，事实上大多数商业代码也都是用这种方式构架的，不能彻底否认它的价值。
但是对于以业务流程驱动设计，并且让数据库严格拆分的微服务架构，使用领域驱动设计则更为合适，因为它是纯粹面向对象的，所以容易测试和使用各种设计模式扩展。关于领域驱动设计是一个很大的话题，在这里只稍微提及一下战术层次的几个要素，在DDD中，有实体、值对象、工厂、存储库、服务、聚合、领域事件等概念，具体如何拆分服务，请参考DDD相关的书籍。
DDD模型承载在微服务六边形架构的内层，而外层则是各种入口和出口适配器，例如，入口有REST API，有来自其他服务领域事件队列的消费器，有针对本服务的CQRS命令接收通道，出口有出栈命令适配器，有存储库适配器，有领域事件发布适配器等。这种设计让领域层保持纯净，可测试，只与抽象接口而非基础设施交互，把与基础设施交互的逻辑都放在外层。
在使用DDD设计微服务时有几个原则要掌握好，第一是外部API调用以及CQRS的C只引用聚合根，第二是聚合之间的引用一定使用主键，第三是在一个事务中只能创建或更新一个聚合，且如果聚合涉及多种实体，则需要使用Saga，这些原则保证了一个微服务的独立性，即服务内部的ACID特性，也保证了服务之间的ACD特性。
领域事件则是当一个聚合发生某种变化时对外发出的通知，本质就是个发布订阅模式的异步调用，它用一套编程语法对外部消息队列发送特定格式的消息，由关注这个事件的下游订阅。以AWS举个例子，可以是当S3上上传一个对象时，通过S3 Event发出领域事件，由Lambda函数订阅进行下游处理。
但是我认为，熟练运用DDD恰恰是推行微服务架构最大的阻碍，因为掌握的人很少难以招聘，且运用DDD还要求这人是个懂infra和运维的全栈，一旦DDD使用不当，带来的从业务层到infra层的级联修改成本极高。

第6章：使用事件溯源开发业务逻辑

事件溯源是一种数据持久化技术，在谈论它之前，先举一个传统数据持久化的例子，比如有订单表Order和订单项目表OrderLineItem，通常会使用ORM映射直接存储结果值，但是这种做法存在几个问题，第一是老生常谈的ORM阻抗失调，第二是这两个表作为一个整体聚合，它们的历史无法追溯，第三是如果想追溯历史实现审计需要付出额外的努力，第四是持久化的同时如果想发送领域事件，则必须手动实现这些逻辑，事件发布凌驾于业务之上。
而事件溯源是以另一种思路存储数据，通过记录行为而不是数据来避免这些问题。它不直接让DB存储聚合的信息，而是强制命令操作发送领域事件，每个事件代表一次状态改变，将事件本身写入DB，在读取DB时，DB会将跟某个ID相关的事件全都读取到进程中进行折叠或者叫reduce，形成最新状态的实体。这个模式下有一些技巧，第一可以使用版本号和乐观锁保证事件写入的原子性，第二可以通过加入事件ID或时间戳等版本号要素应对并发情况下先来的后处理问题，第三可以折叠某个时间点之前大量的记录来节约存储空间。
事件溯源的好处在于，由于强制发布并持久化了领域事件，这很有利于审计和溯源，它完全保留了聚合的历史演进，给开发者提供了时光机，也最大程度地避免了阻抗失调。但是它的坏处也十分明显，首先有学习曲线，然后必须保证消息的传递一定成功，增加了架构复杂性，第三是随着业务演化，事件的数据结构的向后兼容性是个难题，第四是删除数据和查询数据都有一定难度。
书籍的后几节提供了一个Java框架来实现这一套模式，但是我想从架构角度补充一些这个架构的其他特点。首先存储事件而不是实体会导致DB压力和存储空间激增，也会导致Java进程聚合数据时的CPU和内存压力激增，归根结底，溯源的需求偏向OLAP范畴，但是事件溯源架构模糊了OLTP和OLAP两种需求的边界，既要有要，那就让数据库设计要在两边不断权衡撕扯，放在AWS上，如果想减轻数据库的压力，就要做冷热分离，事件存储走Kafka、快照进RDS、长期分析走Redshift Spectrum，这其中还要涉及到一系列数据流水线和ETL逻辑，技术成本一下就上去了。
ps.这和IoT领域的InfluxDB还不一样，虽然看上去有点像，但这个DB强调实时数据获取，接口偏向聚合，不是拿来溯源用的。
事件溯源我认为只适合金融等特定领域，保留历史快照是刚需的项目、只适合需求相对稳定、愿意大力投入技术的成熟团队。

第7章：在微服务中实现查询

微服务一旦割裂了数据库，就必须为读的复杂性支付代价。这一章要解决的问题是，多个微服务把DB隔开了，现在要跨DB查询，如何实现？
第一种模式是使用API组合，也就是对每个微服务都调用一个查询API，把他们的结果在程序里做组合。那么在哪里做调用和组合呢？有三个地方，第一是客户端，第二是API Gateway的实现里，第三个是开发专门的用来查询的微服务，但不论如何，依赖多个服务查询不但会降低系统的可用性，且难保证数据一致性，增加网络开销和多个DB的负载，通过编程手动组装多个服务返回的数据结构也是个苦差事。
而且这种模式，很难解决查询多个历史订单、分页排序等复杂问题，且随着查询需求的扩展，查询逻辑也要不断扩展，使代码很难维护。
这一章提倡的模式叫CQRS（命令查询责任分离），简言之，让对领域模型做增删改的操作走API服务，压一个“写库“，写库把数据变化实时同步到一个读库里，读库里有查询需求所需的视图，让读请求通过另外的API压这个”读库“，甚至可以专门开发用于查询的读取用微服务。至于数据的同步，可以物理传递，也可以通过领域事件触发一个对读库视图更改的API。
这个模式的好处在于，在微服务架构中能高效地实现各种复杂的查询，甚至可以选用不同的数据库承载写入和读取的任务，且对事件溯源模式支持友好，彻底实现了读写分离。但坏处在于，技术架构非常复杂，且数据复制有延迟，可能面临无法在写入后立即读取到最新数据的问题，并且，视图需要不断地更改维护。
接下来是我对这个模式的个人理解，读写分离是好的，但CQRS用在微服务里，纯粹是因为微服务强制拆分了DB，这种洁癖式强迫症带来了一系列的紧身衣，理念反噬了工程，在高昂的工程代价的背后（写库，发事件，同步，甚至ELT），要面临的还是数据同步和一致性的问题，是微服务的弊端，导致它不得不CQRS。我并不是说CQRS的想法不好，甚至在某些场景下是必须的，即OLDP和OLAP既要又要的时候，比如IoT设备要把数据写入InfluxDB，但是冷数据要丢该S3或者其他存储工具保存，在数据工程里，CQRS是数据分层的必然结果，源自需求驱动的架构演化，而在微服务语境里，则是自我设限的苦果。

写在最后

这本书还有两章谈如何做测试和重构，我想已经没有读下去的必要了，因为实现一个真正的微服务架构对公司和团队要求极高，不但全员要用DDD建模和开发，还要学习上面提到的这些紧身衣，还要懂各种Infra的使用，以及需要成熟的DevOps文化，关键的是，需要一群全才在一起工作，这十分不现实。并且在整个微服务的理念里，我看到它带来的技术架构弊端甚至大于了服务拆分带来的好处，为了拆服务带来巨大的技术维护成本究竟值得吗？试问什么样的系统一定非要走微服务的路线不可呢？
书中提出的每个技术模式在某些场景下都是合适的可用的，但是硬要拼凑在一起就太折磨人了，我认为一个比较理性的策略，是在K8S上稳定低跑单体应用，即便到了不得不拆服务的地步，也是拆成两三个大单体，而不是真的微服务，这样既能享受平台的红利，又不必付出过高的技术成本，做恰当的架构设计，不应该被理想主义所吞噬。
]]>