How Amazon Finance streamlines regulatory inquiries by using generative AI on AWS亚马逊金融如何利用AWS上的生成式AI简化监管问询处理

Amazon’s Finance Technology (FinTech) teams build and operate systems for Amazon teams to manage regulatory inquiries in compliance with different jurisdictions. These teams process regulatory inquiries from authorities, each presenting different requirements, document formats, and complexity levels.亚马逊的金融技术（FinTech）团队为亚马逊各团队构建并运营系统，以管理不同司法管辖区的合规监管问询。这些团队处理来自监管机构的问询，每个问询都有不同的要求、文档格式和复杂程度。

Processing these regulatory inquiries involves reviewing documentation, extracting relevant information, retrieving supporting data from multiple systems within Amazon’s infrastructure, and compiling responses within regulatory timeframes. As inquiry frequency and business complexity grew, Amazon needed a more scalable approach.处理这些监管问询涉及审阅文档、提取相关信息、从亚马逊基础设施内的多个系统中检索支持数据，并在监管时限内编制回复。随着问询频率和业务复杂性的增长，亚马逊需要一种更具可扩展性的方法。

In this post, we demonstrate how Amazon FinTech teams are using Amazon Bedrock and other AWS services to build a scalable AI application to transform how regulatory inquiries are handled. Each team using this solution creates and maintains its own dedicated knowledge base, populated with that team’s specific documents and reference materials.在这篇文章中，我们将展示亚马逊FinTech团队如何使用Amazon Bedrock和其他AWS服务构建可扩展的AI应用，以转变监管问询的处理方式。使用此解决方案的每个团队都创建并维护自己的专用知识库，其中填充该团队特定的文档和参考资料。

Challenges挑战

The scale and complexity of managing regulatory inquiries presented several interconnected challenges:管理监管问询的规模和复杂性带来了若干相互关联的挑战：

Knowledge fragmentation and retrieval complexity知识碎片化和检索复杂性

Regulatory inquiries require synthesizing information from thousands of historical documents. These documents exist in various formats (PDF, PPT, Word, CSV) and contain domain-specific terminology. Teams needed a way to quickly locate relevant precedents and supporting information across this vast corpus while maintaining accuracy and regulatory compliance.监管问询需要从数千份历史文档中综合信息。这些文档存在各种格式（PDF、PPT、Word、CSV）中，包含特定领域的术语。团队需要一种方法，能够快速定位相关先例和支持信息，同时保持准确性和监管合规性。

Conversational context and state management对话上下文和状态管理

Regulatory inquiries require multi-turn conversations where context from earlier interactions is essential for generating accurate responses. Maintaining conversational state across sessions and tracking response evolution as team members refine answers through iterative interactions presents significant complexity.监管问询需要多轮对话，其中早期交互的上下文对于生成准确回复至关重要。跨会话维护对话状态，并跟踪团队成员通过迭代交互完善回复时的回复演变，带来了显著的复杂性。

Observability and continuous improvement可观测性和持续改进

With generative AI systems, understanding why a particular response was generated is as important as the response itself. Teams required comprehensive visibility into the retrieval process, model decisions, and user interactions to identify areas for improvement and maintain compliance with responsible AI principles. For example, teams must detect when the model hallucinates information that isn’t present in source documents, or catch when the system retrieves outdated compliance guidelines that could lead to regulatory violations. AI systems experience accuracy drift over time as models, prompts, and the document corpus change, requiring continuous monitoring.对于生成式AI系统而言，理解为何生成特定回复与回复本身同样重要。团队需要全面掌握检索过程、模型决策和用户交互的可视性，以识别改进领域并遵守负责任的AI原则。例如，团队必须检测模型何时产生源文档中不存在的信息幻觉，或发现系统检索到可能导致监管违规的过时合规指南。随着模型、提示和文档语料库的变化，AI系统会随时间经历准确性漂移，需要持续监控。

Solution overview 解决方案概述

To address these challenges, Amazon FinTech team built an intelligent regulatory response automation system using Amazon Bedrock, AWS Lambda, and supporting AWS services. The solution implements Retrieval Augmented Generation (RAG) with Amazon Bedrock Knowledge Bases and Amazon OpenSearch Serverless for vector storage, enabling information retrieval from thousands of historical documents. Real-time chat interactions powered by Claude Sonnet 4.5 through the Converse Stream API, combined with Amazon DynamoDB for conversation history management, provide contextually-aware multi-turn conversations. Comprehensive observability through OpenTelemetry and self-hosted Langfuse ensures continuous monitoring and improvement of the AI system’s performance. The system doesn’t cache large language model (LLM) responses or intermediate results because regulatory inquiries are highly contextual and are prone to a low cache hit rate.为应对这些挑战，亚马逊FinTech团队使用Amazon Bedrock、AWS Lambda和支持性AWS服务构建了智能监管回复自动化系统。该解决方案采用检索增强生成（RAG），结合Amazon Bedrock知识库和Amazon OpenSearch Serverless进行向量存储，实现从数千份历史文档中检索信息。通过Converse Stream API驱动的Claude Sonnet 4.5实时聊天交互，结合Amazon DynamoDB进行对话历史管理，提供具备上下文感知的多轮对话。通过OpenTelemetry和自托管Langfuse实现全面可观测性，确保AI系统性能的持续监控和改进。该系统不缓存大语言模型（LLM）回复或中间结果，因为监管问询高度依赖上下文，缓存命中率低。

The following diagram shows how you can use Amazon Bedrock Knowledge Bases in a workflow, alongside Converse API and other tools, to provide necessary information for regulatory inquiries:下图展示了如何在工作流中使用Amazon Bedrock知识库，结合Converse API和其他工具，为监管问询提供必要信息：

Knowledge base ingestion flow知识库摄入流程

The knowledge base ingestion flow provides an automated document processing pipeline that initiates after the user uploads a document. Its job is to embed the document’s data into an Amazon Bedrock Knowledge Base. Here is the flow:知识库摄入流程提供在用户上传文档后启动的自动化文档处理管道。其任务是将文档数据嵌入Amazon Bedrock知识库。流程如下：

You can use the knowledge base ingestion workflow to upload documents in bulk and transform them into searchable vector embeddings through an automated pipeline. The following detailed flow is illustrated in the previous figure.您可以使用知识库摄入工作流批量上传文档，并通过自动化管道将其转换为可搜索的向量嵌入。以下详细流程如上图所示。

1. Document Upload by User: Users upload documents through the client application.用户上传文档：用户通过客户端应用上传文档。
2. Pre-Signed URL Generation: The client application sends a request to Amazon API Gateway, which invokes the knowledge base ingestion AWS Lambda function to generate a pre-signed S3 URL.预签名URL生成：客户端应用向Amazon API Gateway发送请求，后者调用知识库摄入AWS Lambda函数以生成预签名S3 URL。
3. Document Upload: The client application uses the generated pre-signed URL to upload the document.文档上传：客户端应用使用生成的预签名URL上传文档。
4. Ingestion Trigger and Data Processing: After the document is successfully uploaded to Amazon Simple Storage Service (Amazon S3), the client application triggers the Amazon API Gateway to initiate the document processing AWS Lambda, which handles format conversion and manages the concurrent ingestion of documents. We don’t need to pre-process the images, charts, and tables in these documents because the Amazon Bedrock Knowledge Base is configured with Amazon Bedrock Data Automation (BDA) to effectively extract this multimodal content. The AWS Lambda function then calls the Amazon Bedrock Knowledge Bases.摄入触发和数据处理：文档成功上传到Amazon Simple Storage Service（Amazon S3）后，客户端应用触发Amazon API Gateway启动文档处理AWS Lambda，该函数处理格式转换并管理文档的并发摄入。我们不需要预处理这些文档中的图像、图表和表格，因为Amazon Bedrock知识库配置了Amazon Bedrock Data Automation（BDA）来有效提取这种多模态内容。然后，AWS Lambda函数调用Amazon Bedrock知识库。
5. Vector Storage: The Amazon Bedrock Knowledge Base chunks the document content using a hierarchical chunking strategy, generates embeddings using Amazon Titan Text Embeddings, and stores the resulting vectors in OpenSearch Serverless. Hierarchical chunking creates nested parent-child relationships that mirror the sectioned structure of financial documents. This strategy works well for structured and complex documents because it indexes small chunks for precise retrieval while returning larger parent chunks to provide sufficient context for coherent responses.向量存储：Amazon Bedrock知识库使用分层分块策略对文档内容进行分块，使用Amazon Titan Text Embeddings生成嵌入，并将生成的向量存储在OpenSearch Serverless中。分层分块创建嵌套的父子关系，反映财务文档的分节结构。这种策略适用于结构化和复杂文档，因为它索引小块以实现精确检索，同时返回较大的父块以提供足够的上下文来生成连贯的回复。

Building an automated ingestion pipeline addresses the core challenge of knowledge fragmentation by efficiently processing thousands of historical documents across multiple formats while optimizing content indexing for relevant AI responses. This parallelized approach enables the system to scale effectively, accommodating the growing year-over-year regulatory inquiry activity while maintaining consistent processing performance across large document volumes.构建自动化摄入管道通过高效处理数千份跨多种格式的历史文档，同时优化内容索引以生成相关的AI回复，解决了知识碎片化的核心挑战。这种并行化方法使系统能够有效扩展，适应逐年增长的监管问询活动，同时在大文档量下保持稳定的处理性能。

Chat Application 聊天应用

The Chat Application provides a real-time conversation interface powered by AWS serverless architecture, enabling natural language interactions with the system. We chose to stream responses to customers so they can begin reading the AI response sooner in real-time, implementing this capability through WebSocket connections. Through these WebSocket connections and the Claude Sonnet 4.5 model, it delivers contextually relevant responses while maintaining conversation state in DynamoDB. The workflow operates as follows:聊天应用提供由AWS无服务器架构驱动的实时对话界面，实现与系统的自然语言交互。我们选择向客户流式传输回复，以便他们更早地实时阅读AI回复，通过WebSocket连接实现这一功能。通过这些WebSocket连接和Claude Sonnet 4.5模型，它在DynamoDB中维护对话状态的同时提供上下文相关的回复。工作流如下：

1. Initiate Chat Conversation: Users initiate or open an existing chat session through the client application.发起聊天对话：用户通过客户端应用发起或打开现有聊天会话。
2. WebSocket Connection: The application uses WebSockets to establish a persistent, bi-directional connection with Amazon API Gateway.WebSocket连接：应用使用WebSocket与Amazon API Gateway建立持久的双向连接。
3. Message Submission: The application posts the user questions through the WebSocket connection which is propagated to the Chat service AWS Lambda function.消息提交：应用通过WebSocket连接发布用户问题，该连接被传播到聊天服务AWS Lambda函数。
4. Query Enhancement: The Chat Service AWS Lambda function uses the Claude 3.5 Haiku model with a query expansion strategy to generate multiple variations of the user’s question.查询增强：聊天服务AWS Lambda函数使用Claude 3.5 Haiku模型和查询扩展策略生成用户问题的多个变体。
5. Knowledge Retrieval: The Chat Service Lambda invokes the Amazon Bedrock Knowledge Bases Retrieve API for each expanded query. The API performs vector similarity searches against the underlying OpenSearch Serverless index and returns the most relevant document chunks along with their source metadata and relevance scores.知识检索：聊天服务Lambda对每个扩展查询调用Amazon Bedrock知识库Retrieve API。该API对底层OpenSearch Serverless索引执行向量相似性搜索，并返回最相关的文档块及其源元数据和相关性分数。
6. Context Assembly: The Chat Service AWS Lambda function retrieves conversation history from Amazon DynamoDB (for existing conversations, based on that specific conversation ID) and combines it with the retrieved knowledge base results and the user’s question.上下文组装：聊天服务AWS Lambda函数从Amazon DynamoDB检索对话历史（针对现有对话，基于特定对话ID），并将其与检索到的知识库结果和用户问题结合。
7. Response Generation: The Chat Service AWS Lambda function uses the Converse Stream API with Claude Sonnet 4.5 and a response generator prompt to produce a contextually relevant answer based on the assembled context.回复生成：聊天服务AWS Lambda函数使用Converse Stream API与Claude Sonnet 4.5以及回复生成提示，基于组装的上下文生成上下文相关的答案。
8. User Engagement: The Chat Service AWS Lambda function streams the generated response back to the client application in Markdown format through the WebSocket connection and stores all the conversation in the Conversational History Table by Amazon DynamoDb.用户参与：聊天服务AWS Lambda函数通过WebSocket连接以Markdown格式将生成的回复流式传输回客户端应用，并将所有对话存储在Amazon DynamoDB的对话历史表中。
9. Observability: Throughout the process, the Chat Service publishes end-to-end traces to a self-hosted Langfuse instance using the OpenTelemetry (OTEL) SDK. This captures detailed telemetry data including latency metrics, token usage, prompt templates, and model responses.可观测性：在整个过程中，聊天服务使用OpenTelemetry（OTEL）SDK向自托管Langfuse实例发布端到端追踪。这捕获详细的遥测数据，包括延迟指标、令牌使用量、提示模板和模型回复。

Multi-turn conversational experience多轮对话体验

Regulatory inquiry discussions often progress through multiple exchanges as teams refine responses and reference additional data sources. To support this iterative process, the Amazon FinTech team implemented a multi-turn conversational workflow using Amazon API Gateway (WebSocket APIs), AWS Lambda, and Amazon DynamoDB, integrated with the Amazon Bedrock ConverseStream API for low-latency, context-aware dialogue. Each chat session is securely authenticated through Amazon Cognito and assigned a unique conversation ID. DynamoDB stores messages in chronological order to preserve context across sessions, so users can resume prior discussions seamlessly and maintain continuity.监管问询讨论通常通过多次交流逐步推进，因为团队完善回复并引用额外的数据源。为支持这一迭代过程，亚马逊FinTech团队使用Amazon API Gateway（WebSocket API）、AWS Lambda和Amazon DynamoDB实现了多轮对话工作流，并与Amazon Bedrock ConverseStream API集成以实现低延迟、上下文感知的对话。每个聊天会话通过Amazon Cognito进行安全认证，并分配唯一的对话ID。DynamoDB按时间顺序存储消息以跨会话保留上下文，因此用户可以无缝恢复先前的讨论并保持连续性。

When a user submits a query, the system sanitizes inputs to prevent prompt injection attacks. After sanitization, the system classifies intent and determines whether retrieval from the Amazon Bedrock Knowledge Base is required. This determination is made through an LLM call that classifies the user query as either conversational or knowledge intensive. For complex, knowledge-intensive questions, the workflow employs a query expansion strategy that addresses the prevalent use of acronyms and abbreviated questions by users. This layer generates up to five query variations using Claude 3.5 Haiku, then makes parallel Retrieve API calls to the Knowledge Base, retrieving relevant results using OpenSearch vector similarity search. To maintain performance at scale, the workflow implements parallel processing for these retrieval calls using multi-threading. This optimization reduced retrieval latency from 10 seconds (sequential processing) to under 2 seconds, enabling responsive conversations. The retrieved information—combined with recent conversation history—is passed to Claude Sonnet 4.5 through the ConverseStream API augmented with Amazon Bedrock Guardrails, that implement sensitive information filters to automatically detect and remove PII and financial data from both inputs and outputs. This is critical for protecting regulatory documentation. When prompt injection attempts are detected, the system responds with “Sorry, the model cannot answer that question,” maintaning secure and compliant interactions while maintaining conversational fluency.当用户提交查询时，系统对输入进行消毒以防止提示注入攻击。消毒后，系统对意图进行分类，并确定是否需要从Amazon Bedrock知识库检索。这一判断通过LLM调用完成，将用户查询分类为对话型或知识密集型。对于复杂的知识密集型问题，工作流采用查询扩展策略，解决用户普遍使用缩写和简略提问的问题。该层使用Claude 3.5 Haiku生成多达五个查询变体，然后向知识库发起并行Retrieve API调用，使用OpenSearch向量相似性搜索检索相关结果。为在规模上保持性能，工作流使用多线程对这些检索调用实现并行处理。这一优化将检索延迟从10秒（顺序处理）降低到2秒以下，实现响应式对话。检索到的信息——结合近期对话历史——通过Amazon Bedrock Guardrails增强的ConverseStream API传递给Claude Sonnet 4.5，后者实施敏感信息过滤器，自动检测并从输入和输出中移除PII和财务数据。这对于保护监管文档至关重要。当检测到提示注入尝试时，系统回复"抱歉，模型无法回答该问题"，在保持对话流畅性的同时维护安全合规的交互。

This architecture delivers continuity, transparency, and scalability. Users receive real-time, streaming responses with status updates throughout the retrieval and generation phases, improving engagement and reducing latency. Persistent logs in DynamoDB provide an immutable audit trail for compliance review, while the serverless and event-driven design scales automatically to support concurrent sessions. Together, these capabilities enable Amazon FinTech team to conduct complex, iterative conversations—producing contextually relevant, secure, and regulatory-compliant responses powered by Amazon Bedrock.该架构提供连续性、透明度和可扩展性。用户在整个检索和生成阶段接收实时流式回复和状态更新，提高参与度并降低延迟。DynamoDB中的持久日志为合规审查提供不可变的审计追踪，而无服务器和事件驱动设计自动扩展以支持并发会话。这些能力共同使亚马逊FinTech团队能够进行复杂的迭代对话——生成由Amazon Bedrock驱动的上下文相关、安全且符合监管的回复。

Observability可观测性

Observability plays a critical role in understanding and improving AI-driven workflows. To achieve complete visibility into the regulatory inquiry response system, the Chat Service AWS Lambda integrated OpenTelemetry (OTEL) with a self-hosted Langfuse instance to capture detailed, end-to-end traces of each interaction. This setup provides engineers and applied scientists with fine-grained telemetry on how prompts are processed, knowledge is retrieved, and responses are generated. This enables nearly continuous refinement of the system’s performance and accuracy. The decision to use OTEL over the native Langfuse SDK provides vendor-neutral flexibility, allowing telemetry data to be routed to multiple observability backends and adapted to evolving monitoring requirements.可观测性在理解和改进AI驱动的工作流中发挥着关键作用。为全面了解监管问询回复系统，聊天服务AWS Lambda将OpenTelemetry（OTEL）与自托管Langfuse实例集成，以捕获每次交互的详细端到端追踪。此设置为工程师和应用科学家提供关于提示如何处理、知识如何检索以及回复如何生成的细粒度遥测数据。这使得系统性能和准确性的近乎持续的改进成为可能。选择OTEL而非原生Langfuse SDK提供了供应商中立的灵活性，允许遥测数据路由到多个可观测性后端，并适应不断变化的监控需求。

At runtime, each stage of the Chat Service AWS Lambda is manually instrumented using the OTEL Java SDK to record latency, token usage, model decisions, and prompt metadata in OTEL Generative AI semantic standard. Spans are published to Langfuse in near real time, giving the team a transparent view of how the Amazon Bedrock ConverseStream API, Knowledge Base retrieval, and Claude Sonnet 4.5 interact within a single request. The detailed telemetry allows the team to identify performance bottlenecks, optimize prompt strategies, and enhance retrieval precision while maintaining responsible AI practices.在运行时，聊天服务AWS Lambda的每个阶段都使用OTEL Java SDK手动插桩，以OTEL生成式AI语义标准记录延迟、令牌使用量、模型决策和提示元数据。跨度以近实时方式发布到Langfuse，使团队能够透明地查看Amazon Bedrock ConverseStream API、知识库检索和Claude Sonnet 4.5如何在单个请求中交互。详细的遥测数据使团队能够识别性能瓶颈、优化提示策略并提高检索精度，同时保持负责任的AI实践。

This observability framework maintains trust and accountability in the system’s behavior. Engineers can correlate user actions with model outcomes, trace data lineage across multiple services, and fine-tune configurations without disrupting operations. By combining OpenTelemetry’s interoperability with Langfuse’s visualization and analytics, Amazon FinTech team gains a scalable, extensible foundation for evaluating generative AI systems at scale—turning every interaction into actionable insight for continuous improvement.此可观测性框架维护系统行为的信任和问责。工程师可以将用户操作与模型结果关联，跨多个服务追踪数据血缘，并在不中断运营的情况下微调配置。通过将OpenTelemetry的互操作性与Langfuse的可视化和分析相结合，亚马逊FinTech团队获得了可扩展、可扩展的基础，用于大规模评估生成式AI系统——将每次交互转化为持续改进的可操作洞察。

The following screenshot illustrates an end-to-end trace captured in Langfuse, showcasing how the observability solution captures the complete workflow—from query expansion and knowledge retrieval to model prompts, responses, and latency metrics. It also highlights source document citations, offering a transparent view of how contextual information flows through the system during response generation以下截图展示了在Langfuse中捕获的端到端追踪，展示了可观测性解决方案如何捕获完整工作流——从查询扩展和知识检索到模型提示、回复和延迟指标。它还突出显示了源文档引用，提供了上下文信息在回复生成期间如何流经系统的透明视图

Reference: End-to-End Trace Posted in Langfuse参考：发布在Langfuse中的端到端追踪

Conclusion结论

In this post, you saw how Amazon FinTech team built a scalable AI solution using Amazon Bedrock, designed to support regulatory inquiries by automating knowledge retrieval, conversational workflows, and response generation. By combining a document ingestion pipeline, multi-turn stateful conversations, and detailed observability via OpenTelemetry and Langfuse, the architecture empowers teams to handle regulatory inquiries in governed, traceable and compliant manner.在这篇文章中，您了解了亚马逊FinTech团队如何使用Amazon Bedrock构建可扩展的AI解决方案，旨在通过自动化知识检索、对话工作流和回复生成来支持监管问询。通过结合文档摄入管道、多轮有状态对话以及通过OpenTelemetry和Langfuse实现的详细可观测性，该架构使团队能够以受治理、可追踪且合规的方式处理监管问询。

Because the entire stack is built on AWS serverless services, it offers the operational scalability, security, and elasticity required for enterprise-grade deployment. Whether you’re dealing with legal compliance, regulatory inquiries, or high-volume internal knowledge workflows, this pattern offers a practical foundation that you can tailor and extend to your business domain.由于整个堆栈构建在AWS无服务器服务之上，它提供了企业级部署所需的操作可扩展性、安全性和弹性。无论您处理的是法律合规、监管问询还是高容量内部知识工作流，此模式都提供了实用的基础，您可以根据业务领域进行定制和扩展。

If you’re ready to modernize your knowledge-intensive processes with generative AI, explore the Amazon Bedrock documentation to discover how you can begin building your own secure, governed, and scalable AI-powered workflows.如果您准备使用生成式AI现代化知识密集型流程，请探索Amazon Bedrock文档，了解如何开始构建您自己的安全、受治理且可扩展的AI驱动工作流。

About the authors关于作者