Amazon 内部金融团队的 RAG 实战：用 Bedrock 把监管审查从人工翻文件变成 AI 对话

前言

最近看到 Amazon 自己的 FinTech 团队分享了他们怎么用亚马逊云科技的服务搭建了一套监管审查自动化系统。作为一个天天跟 RAG 打交道的人，这个架构让我眼前一亮——不是那种 demo 级别的东西，是真正在生产环境跑的。

问题：金融监管审查为什么难

金融行业的监管审查有几个典型挑战：

• 文档量大：上千份历史文件，PDF、PPT、Word、CSV 混在一起
• 术语专业：各业务线有自己的行话和缩写
• 频率递增：审查要求年年涨，人力跟不上
• 合规严格：回复必须准确，不能瞎编

说白了就是知识碎片化 + 检索复杂度高 + 不容出错。

架构全貌

整套方案基于 Amazon Bedrock 和配套服务，分三层：

1. 文档摄入层

文档上传后走自动化流水线：

• S3 Pre-signed URL 上传
• Lambda 做格式转换和并发管理
• Bedrock Knowledge Bases + Bedrock Data Automation (BDA) 提取多模态内容
• Amazon Titan Text Embeddings 生成向量
• OpenSearch Serverless 存储

分块策略选的是层级分块（Hierarchical Chunking）。这个选择很有讲究：金融文档通常章节层次分明，层级分块能创建父子嵌套关系，小块精准匹配，父块保留上下文。

2. 对话层

这是系统的核心，处理流程：

用户提问 → 输入净化（防注入）
    → 意图分类（对话型 or 知识密集型）
    → 查询扩展（Claude 3.5 Haiku 生成多变体）
    → 并行检索（多线程调 Knowledge Bases Retrieve API）
    → 上下文组装（DynamoDB 对话历史 + 检索结果）
    → 流式生成（Claude Sonnet 4.5 + Converse Stream API）
    → 输出过滤（Bedrock Guardrails 删除 PII）
    → WebSocket 流式返回

几个技术亮点：

• 查询扩展把检索延迟从 10 秒压到 2 秒以内
• 不做 LLM 缓存——监管审查太个性化，缓存命中率低
• WebSocket 支持流式返回，用户体验好

3. 可观测层

OpenTelemetry + 自托管 Langfuse：

• 每个 span 记录延迟、token 用量、prompt 元数据
• 选 OTEL 而非 Langfuse SDK 是为了厂商中立性
• 能追溯从查询扩展到最终生成的完整链路

安全设计

两道防线值得注意：

1. 输入端：检测 prompt injection，触发后返回固定回复
2. 输出端：Bedrock Guardrails 的敏感信息过滤器自动识别和删除 PII、财务数据

这在金融场景下是硬性要求，不是可选项。

关键设计决策

决策	理由
层级分块	匹配金融文档的章节结构
查询扩展	金融缩写多，单条查询命中率低
不缓存 LLM 响应	高个性化场景缓存命中率极低
Serverless 架构	审查频率有波动，按量付费更合理
OTEL 可观测	厂商中立，方便迁移

动手参考

核心服务清单：

• Amazon Bedrock Knowledge Bases — 知识库管理和 RAG
• Claude Sonnet 4.5 — 主推理模型
• Claude 3.5 Haiku — 查询扩展
• Amazon OpenSearch Serverless — 向量存储
• Amazon DynamoDB — 对话历史
• Amazon API Gateway — WebSocket API
• AWS Lambda — 业务逻辑
• Amazon Bedrock Guardrails — PII 过滤

总结

这不是一个 demo，是 Amazon 自己内部团队在生产环境跑的系统。几个核心思路——层级分块、查询扩展并行检索、OTEL 可观测、不盲目缓存——对任何做金融或法规类 RAG 的团队都有参考价值。

参考资料：

• 原文链接
• Amazon Bedrock Knowledge Bases