Marico's space

最近在给客户落地多知识库 RAG（检索增强生成）方案，可观测性这块一直是个老大难问题——日志打了一堆，查问题还是靠猜。最近看到 AWS 发布了一套参考架构，把可观测性直接当成基础设施来设计，不是事后打补丁。这套方案用单个 CloudFormation 模板链部署七层可观测性能力，专门针对多知识库代理检索场景。据我所知，这是 AWS 首个把代理推理、路由决策、引用追踪、持续评估都纳入基础设施版本的公开蓝图。

架构核心用的是 Amazon Bedrock 的托管知识库（Knowledge Base）和 AgentCore。代理在多个知识库之间路由，返回带引用的答案，每个决策点都通过结构化链路追踪暴露出来。按需评估和持续评估两种模式都会反馈到代理行为优化中。

七层可观测性

AWS 把可观测性拆成七个instrumentation点，对应代理执行的不同阶段：

1. 代理推理链路：捕获代理的内部决策树（查询哪个知识库、如何分解问题、何时停止）。
2. 知识库路由日志：记录代理选择了哪个知识库及原因，包含置信度分数。
3. 检索遥测：追踪块（chunk）选择、向量相似度分数、重排序决策。
4. 引用链追踪：将每个答案片段关联回跨多个知识库的源文档。
5. 按需评估：对每个查询运行质量检查（相关性、忠诚度、答案完整度）。
6. 持续评估：采样生产流量进行漂移检测和模型降级监控。
7. CloudFormation 部署状态：将可观测性栈本身作为版本化管理的基础设施。

每一层都向 CloudWatch Logs 输出结构化 JSON，通过链路 ID（trace ID）实现跨层关联。代理不只是记录错误，而是记录每个路由决策、每个候选检索结果、每条引用链接。

多知识库路由与引用链

当代理在单次查询中跨多个知识库路由时，引用追踪就变得不简单了。AWS 用两阶段方案解决这个问题：

第一阶段：路由决策
代理根据知识库元数据（领域、时效性、权威性）评估查询，选择一个或多个知识库。这个决策会连同置信度分数和推理文本一起记录日志。

第二阶段：引用组装
每个知识库返回带有源元数据的块。代理综合出答案并附加引用链：一个包含 (kb_id, document_id, chunk_id, confidence) 的元组列表。如果答案涉及三个知识库，引用链就有三条记录。

可观测性栈对两个阶段都做了暴露。你能看到代理为什么选 KB-A 而不选 KB-B，也能审计最终答案是否真的用了它引用的那些块。

CloudFormation 部署结构

整个栈通过单个 CloudFormation 模板配合嵌套栈来部署：

Resources: KnowledgeBaseStack: Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Sub 'https://s3.${AWS::Region}.amazonaws.com/cfn-templates/kb-stack.yaml' Parameters: VectorStoreType: OpenSearchServerless EmbeddingModel: amazon.titan-embed-text-v2:0 AgentStack: Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Sub 'https://s3.${AWS::Region}.amazonaws.com/cfn-templates/agent-stack.yaml' Parameters: KnowledgeBaseIds: !GetAtt KnowledgeBaseStack.Outputs.KBIds FoundationModel: anthropic.claude-3-sonnet-20240229-v1:0 ObservabilityStack: Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Sub 'https://s3.${AWS::Region}.amazonaws.com/cfn-templates/observability-stack.yaml' Parameters: AgentId: !GetAtt AgentStack.Outputs.AgentId EvaluationMode: continuous SamplingRate: 0.1

可观测性栈是独立参数化的。你可以在不动代理栈或知识库栈的情况下，切换按需评估和持续评估模式、调整采样率、配置告警阈值。

参数化的内容：

• 评估模式（按需、持续、两都）
• 持续评估的采样率
• CloudWatch 日志保留期
• 引用准确性和检索延迟的告警阈值

硬编码的内容：

• 七层可观测性（全部启用）
• 链路 ID 传播（始终启用）
• 引用链结构（固定 schema）

按需评估 vs 持续评估

AWS 提供了两种评估模式，反馈环路不同：

评估模式	触发时机	延迟影响	适用场景
按需	每个查询	+200-500ms	高风险查询、合规审计、调试
持续	异步采样	无（响应后执行）	漂移检测、模型降级、A/B 测试

按需评估同步执行。代理在返回答案前等待质量检查（相关性、忠诚度、完整度）完成。这会增加延迟，但保证每个响应都满足质量阈值。适合金融咨询、法律研究、医疗分诊等场景。

持续评估采样 10% 的生产流量，异步执行评估。结果汇入 CloudWatch 仪表板，如果质量指标下降则触发告警。这能在不阻塞用户请求的前提下捕捉模型漂移、知识库过时、提示词回归等问题。

两种模式使用相同的评估指标（RAGAS 框架：忠诚度、答案相关性、上下文精确度）。区别在于何时以及如何影响代理行为。

这套栈暴露的故障模式

单知识库 RAG 系统会隐藏的几种故障模式，在多知识库路由和完整可观测性下变得可见：

路由振荡
代理在两个知识库之间摇摆不定，相似查询却选择了不同知识库。引用链显示不一致的知识库选择。修复方法：调整知识库元数据或增加路由迟滞。

引用幻觉
代理引用了它实际并未检索到的块。引用链追踪能发现这个问题：被引用的 chunk_id 没有出现在检索遥测数据中。修复方法：增加检索的 top-k 值或调整重排序参数。

跨知识库一致性失败
代理从三个知识库检索，但综合出的答案自相矛盾。持续评估会标记出低忠诚度分数。修复方法：在代理提示词中增加一致性检查，或限制每次查询的知识库数量。

评估漂移
按需评估通过，但持续评估显示指标随时间下降。这说明评估标准与生产查询分布不匹配。修复方法：用生产样本重新训练评估模型。

CloudFormation 栈漂移
有人在控制台手动修改了可观测性参数。CloudFormation 漂移检测能发现，但需要决定：更新模板还是回滚变更。

状态管理与链路传播

代理在查询之间不维护持久状态。每次调用都是无状态的，这简化了可观测性但让多轮对话变得复杂。

链路 ID 在三个层级间传播：

1. API Gateway 在入口处生成 request-id。
2. AgentCore 将其包装成 trace-id，传递给所有知识库查询。
3. CloudWatch Logs 按 trace-id 索引，支持跨服务关联。

如果需要多轮状态（对话历史、用户偏好），必须在代理外部自己实现。AWS 建议用带 TTL 的 DynamoDB 处理临时状态，S3 存储长期对话日志。可观测性栈不追踪状态变更，只记录单个查询的链路。

安全边界

CloudFormation 模板强制执行最小权限 IAM 角色：

• 代理角色可以调用 Bedrock 模型和查询知识库，但不能修改知识库内容。
• 知识库角色可以读取 S3 和 OpenSearch，但不能写入。
• 可观测性角色可以写入 CloudWatch 和读取代理链路，但不能调用代理。

跨账户知识库访问需要显式信任策略。如果要让账户 A 中的代理查询账户 B 中的知识库，必须：

1. 授予代理角色对跨账户知识库 ARN 的 bedrock:Retrieve 权限。
2. 为知识库添加资源策略，允许该代理角色访问。
3. 更新可观测性栈，从两个账户收集链路。

模板默认不处理跨账户可观测性。需要自定义 CloudWatch 跨账户接收器。

技术结论

适合用这套方案的场景：

• 需要多知识库路由并附带完整引用追踪。
• 可观测性是合规要求，不是锦上添花。
• 需要可复现的基础设施来部署代理（不要 ClickOps）。
• 同时需要实时质量检查和长期漂移检测。

不适合的场景：

• 只有一个知识库，简单的 RAG 就够用。
• 无法接受按需评估带来的 200-500ms 延迟。
• 团队缺乏 CloudFormation 经验（嵌套栈模式有一定门槛）。
• 需要多轮对话状态（这套架构是无状态的）。

对于原型验证来说，七层可观测性确实是杀鸡用牛刀。但如果你的生产环境是多知识库检索，而且需要审计每一条引用、检测模型漂移，这是目前 AWS 首个把可观测性当作基础设施来设计的参考架构。