Amazon Finance が AWS の生成 AI を活用し規制対応を効率化
Amazon の財務技術チームは、AWS Bedrock を活用した生成 AI アプリケーションにより、複雑化する規制対応問い合わせの処理を効率化し、知識ベースの構築とコンテキスト管理を実現している。
キーポイント
規制対応の課題と背景
多様な形式や要件を持つ規制当局からの問い合わせが増加する中、従来の手作業プロセスではスケーラビリティと正確性の維持が困難になっていた。
AWS Bedrock を活用した解決策
各チームが独自のドキュメントを登録できる知識ベース(Knowledge Base)を構築し、Amazon Bedrock などの AWS サービスを用いて回答生成の自動化を実現した。
コンテキスト管理と継続的改善
多段階の対話における文脈維持や、モデルのハルシネーション(事実誤認)、精度の低下を検知するための観測性(Observability)機能を重視している。
影響分析・編集コメントを表示
影響分析
この事例は、生成 AI が単なる業務効率化ツールを超え、厳格なコンプライアンス要件下で意思決定を支援する重要なインフラとして機能しうることを示しています。特に、AI の判断根拠を追跡可能にする「観測性」の重要性を強調しており、金融や法務分野での AI 実装におけるベストプラクティスを提供するものです。
編集コメント
規制対応という極めてシビアな領域において、生成 AI の「ハルシネーション」リスクをどう管理し、かつ「観測性」を確保するかという実務的な課題解決策が示されており、業界全体にとって非常に参考になるケーススタディです。
Amazon の財務技術(FinTech)チームは、異なる管轄区域の規制に準拠して Amazon チームが規制関連の問い合わせを管理するためのシステムを構築・運用しています。これらのチームは、当局からの規制関連問い合わせを処理しており、それぞれが異なる要件、ドキュメント形式、複雑さを有しています。
これらの規制関連問い合わせの処理には、ドキュメントのレビュー、関連情報の抽出、Amazon のインフラストラクチャ内の複数のシステムから支援データを取得し、規制で定められた時間枠内に対応をまとめることが含まれます。問い合わせの頻度とビジネスの複雑さが増大するにつれ、Amazon はよりスケーラブルなアプローチが必要となりました。
本稿では、Amazon FinTech チームが Amazon Bedrock およびその他の AWS サービスを活用して、規制関連問い合わせの処理方法を変革するスケーラブルな AI アプリケーションを構築する方法を実証します。このソリューションを利用する各チームは、自チーム固有のドキュメントや参照資料で構成された独自のナレッジベースを作成・維持しています。
課題
規制関連問い合わせの管理における規模と複雑さは、いくつかの相互に関連した課題をもたらしました:
知識の断片化と検索の複雑さ
規制当局からの照会には、数千の歴史的ドキュメントから情報を統合する必要があります。これらのドキュメントは PDF、PPT、Word、CSV など様々な形式で存在し、分野固有の専門用語を含んでいます。チームは、膨大な文書群の中で関連する先例や裏付けとなる情報を迅速に見つけ出す方法が必要でしたが、同時に正確性と規制遵守を維持する必要がありました。
対話コンテキストと状態管理
規制当局からの照会には、複数回のやり取りを含む対話が求められ、過去のやり取りからの文脈が正確な回答を生成するために不可欠です。セッション間を通じて対話の状態を維持し、チームメンバーが反復的なやり取りを通じて回答を洗練させる過程で回答の進化を追跡することは、大きな複雑さを伴います。
観測可能性と継続的改善
生成 AI システムにおいては、特定の回答がなぜ生成されたかを理解することが、その回答自体と同様に重要です。チームは、改善点を特定し、責任ある AI の原則への準拠を維持するために、検索プロセス、モデルの判断、ユーザーとのやり取りについて包括的な可視性を必要としました。例えば、モデルがソースドキュメントに含まれていない情報を捏造(hallucinate)したときや、規制違反につながる可能性のある古いコンプライアンスガイドラインをシステムが取得した場合を検出する必要があります。モデル、プロンプト、およびドキュメントコーパスの変化に伴い、AI システムの精度は時間とともに低下する傾向があるため、継続的な監視が必要です。
ソリューションの概要
これらの課題に対処するため、Amazon FinTech チームは Amazon Bedrock、AWS Lambda、および関連する AWS サービスを活用したインテリジェントな規制対応自動化システムを構築しました。本ソリューションでは、Retrieval Augmented Generation(RAG:検索拡張生成)を実装し、Amazon Bedrock Knowledge Bases とベクトル保存用の Amazon OpenSearch Serverless を組み合わせることで、数千件の歴史的ドキュメントからの情報検索を可能にしています。Claude Sonnet 4.5 を Converse Stream API を通じて活用したリアルタイムのチャット対話と、会話履歴管理のための Amazon DynamoDB を組み合わせることで、文脈を考慮した多段階の対話を実現しています。OpenTelemetry とセルフホスト型の Langfuse による包括的な観測機能により、AI システムのパフォーマンスに対する継続的な監視と改善が保証されています。規制に関する問い合わせは非常に文脈依存性が高く、キャッシュヒット率が低くなる傾向があるため、本システムでは大規模言語モデル(LLM)の応答や中間結果をキャッシュしません。
以下の図は、Amazon Bedrock Knowledge Bases を Converse API やその他のツールとともにワークフローで使用し、規制関連の問い合わせに必要な情報を提供する方法を示しています。
ナレッジベース取り込みフロー
ナレッジベース取り込みフローは、ユーザーがドキュメントをアップロードした後に開始される自動化されたドキュメント処理パイプラインを提供します。その役割は、ドキュメントのデータを Amazon Bedrock Knowledge Base に埋め込むことです。以下にそのフローを示します。
ナレッジベース取り込みワークフローを使用すると、ドキュメントを一括アップロードし、自動化されたパイプラインを通じて検索可能なベクトル埋め込みに変換することができます。以下の詳細なフローは、前述の図で示されています。
- ユーザーによるドキュメントアップロード:ユーザーはクライアントアプリケーションを通じてドキュメントをアップロードします。
- プレサイン URL 生成:クライアントアプリケーションは、Amazon API Gateway にリクエストを送信し、これにより知識ベースの取り込み用 AWS Lambda 関数が呼び出され、プレサイン S3 URL が生成されます。
- ドキュメントアップロード:クライアントアプリケーションは、生成されたプレサイン URL を使用してドキュメントをアップロードします。
- 取り込みトリガーとデータ処理:ドキュメントが Amazon Simple Storage Service (Amazon S3) に正常にアップロードされると、クライアントアプリケーションは Amazon API Gateway をトリガーしてドキュメント処理用 AWS Lambda を起動し、フォーマット変換の処理や複数のドキュメントの並列取り込みを管理します。これらのドキュメントに含まれる画像、チャート、表については事前処理を行う必要はありません。Amazon Bedrock Knowledge Base は、Amazon Bedrock Data Automation (BDA) で構成されており、これにより多様なモダリティを持つコンテンツを効果的に抽出できるためです。その後、AWS Lambda 関数は Amazon Bedrock Knowledge Bases を呼び出します。
- ベクトルストレージ:Amazon Bedrock Knowledge Base は、階層型チャンキング戦略を用いてドキュメント内容をチャンク化し、Amazon Titan Text Embeddings を使用して埋め込みベクトルを生成し、結果として得られるベクトルを OpenSearch Serverless に保存します。階層型チャンキングは、金融文書のセクション構造を反映したネストされた親子関係を作成します。この戦略は構造化され複雑なドキュメントに対して効果的であり、正確な検索のために小さなチャンクをインデックス化しつつ、一貫性のある回答を提供するために十分なコンテキストを含む大きな親チャンクを返すことができます。
自動化された取り込みパイプラインを構築することで、知識の断片化という核心的な課題に対処し、複数のフォーマットにわたる数千件の歴史的ドキュメントを効率的に処理しながら、関連する AI 回答のためのコンテンツインデックス最適化を実現します。この並列化アプローチにより、システムは効果的にスケーリング可能となり、年々の規制関連問い合わせの増加に対応しつつ、大規模なドキュメント量全体で一貫した処理パフォーマンスを維持できます。
チャットアプリケーション
チャットアプリケーションは、AWS サーバーレスアーキテクチャを基盤としたリアルタイム会話インターフェースを提供し、システムとの自然言語での対話を可能にします。顧客が AI の応答をより早く読み始められるよう、応答ストリーミングを採用しており、この機能は WebSocket 接続を通じて実装されています。これらの WebSocket 接続と Claude Sonnet 4.5 モデルを活用することで、文脈に応じた関連性の高い応答を提供しつつ、DynamoDB 上で会話の状態を維持します。ワークフローは以下の通りです:
- チャット会話の開始:ユーザーはクライアントアプリケーションを通じて、新しいチャットセッションを開始するか、既存のセッションを開きます。
- WebSocket 接続:アプリケーションは WebSockets を使用して、Amazon API Gateway と永続的な双方向接続を確立します。
- メッセージ送信:アプリケーションは、WebSocket 接続を介してユーザーの質問を投稿し、これを Chat サービスの AWS Lambda 関数に伝播させます。
- クエリ拡張:Chat Service の AWS Lambda 関数は、Claude 3.5 Haiku モデルとクエリ拡張戦略を使用して、ユーザーの質問の複数のバリエーションを生成します。
- 知識検索:Chat Service Lambda は、拡張された各クエリに対して Amazon Bedrock Knowledge Bases の Retrieve API を呼び出します。この API は、基盤となる OpenSearch Serverless インデックスに対してベクトル類似性検索を実行し、最も関連性の高いドキュメントチャンクと、そのソースメタデータおよび関連度スコアを返します。
- コンテキストの組み立て:Chat Service の AWS Lambda 関数は、Amazon DynamoDB から会話履歴(既存の会話については、特定の会話 ID に基づいて)を取得し、取得したナレッジベースの結果とユーザーの質問を組み合わせてコンテキストを作成します。
- レスポンス生成:Chat Service の AWS Lambda 関数は、Claude Sonnet 4.5 とレスポンスジェネレータープロンプトを使用して、Converse Stream API を通じて、組み立てられたコンテキストに基づいて文脈に即した回答を生成します。
- ユーザーエンゲージメント:Chat Service の AWS Lambda 関数は、生成されたレスポンスを Markdown 形式で WebSocket 接続を介してクライアントアプリケーションへストリーミングし、すべての会話を Amazon DynamoDb の会話履歴テーブルに保存します。
- 観測可能性:プロセス全体を通じて、Chat サービスは OpenTelemetry (OTEL) SDK を使用して、エンドツーエンドのトレースをセルフホスト型の Langfuse インスタンスに公開します。これにより、レイテンシ指標、トークン使用量、プロンプトテンプレート、モデルレスポンスなどの詳細なテレメトリデータが収集されます。
マルチターン会話型体験
規制に関する問い合わせの議論は、チームが回答を洗練させ追加データソースを参照する過程で、複数のやり取りを通じて進行することがよくあります。この反復プロセスをサポートするため、Amazon FinTech チームは、低遅延かつ文脈を意識した対話を可能にする Amazon Bedrock ConverseStream API と統合し、Amazon API Gateway (WebSocket APIs)、AWS Lambda、および Amazon DynamoDB を用いたマルチターン会話型ワークフローを実装しました。各チャットセッションは Amazon Cognito によって安全に認証され、一意の会話 ID が割り当てられます。DynamoDB はメッセージを時系列順に保存してセッション間での文脈を維持するため、ユーザーは以前の議論をシームレスに再開し、継続性を保つことができます。
ユーザーが問い合わせを送信すると、システムは入力値をサニタイズしてプロンプトインジェクション攻撃を防ぎます。サニタイズ後、システムは意図を分類し、Amazon Bedrock Knowledge Base からの検索が必要かどうかを判断します。この判断は、LLM を呼び出してユーザーの問い合わせが会話型か知識集約型かを分類することによって行われます。複雑で知識集約的な質問に対しては、ユーザーによる略語や省略された質問の一般的な使用に対応するクエリ拡張戦略が採用されます。この層では Claude 3.5 Haiku を用いて最大 5 つのクエリバリエーションを生成し、Knowledge Base に対して並列で Retrieve API を呼び出して、OpenSearch ベクトル類似度検索を用いて関連結果を取得します。スケールにおけるパフォーマンスを維持するため、このワークフローではマルチスレッディングを使用してこれらの取得呼び出しに並列処理を実装しています。この最適化により、取得レイテンシは 10 秒(逐次処理)から 2 秒未満に短縮され、応答性の高い対話が可能になりました。
取得された情報と直近の会話履歴は、Amazon Bedrock Guardrails を付加した ConverseStream API を介して Claude Sonnet 4.5 に渡されます。この Guardrails は sensitive information filters を実装しており、入力と出力の両方から PII(個人識別情報)や金融データを自動的に検出・除去します。これは規制文書を守る上で極めて重要です。プロンプトインジェクションの試行が検出された場合、システムは「申し訳ありませんが、その質問には回答できません」と応答し、対話の流暢さを維持しながら安全でコンプライアンスに準拠したやり取りを保ちます。
このアーキテクチャは、継続性、透明性、スケーラビリティを実現します。ユーザーは検索および生成フェーズを通じてステータス更新を伴うリアルタイムのストリーミング応答を受け取り、エンゲージメントが向上し、レイテンシが削減されます。DynamoDB における永続的なログは、コンプライアンスレビューのための不変の監査証跡を提供し、サーバーレスかつイベント駆動型の設計は自動的にスケーリングして同時セッションをサポートします。これらの機能により、Amazon FinTech チームは、Amazon Bedrock によって支えられた、文脈に即した、安全で規制遵守の応答を生成する複雑で反復的な対話を行うことが可能になります。
観測可能性 (Observability)
観測可能性は、AI ドライブ型のワークフローを理解し改善する上で重要な役割を果たします。規制問い合わせ応答システムへの完全な可視性を達成するため、Chat Service AWS Lambda は OpenTelemetry (OTEL) を統合し、自己ホスト型の Langfuse インスタンスを構成して、各インタラクションの詳細なエンドツーエンドのトレースをキャプチャしています。この設定により、エンジニアや応用科学者は、プロンプトがどのように処理され、知識がどのように取得され、応答がどのように生成されるかという微細なテレメトリ情報を入手できます。これにより、システムの性能と精度のほぼ継続的な改善が可能になります。ネイティブの Langfuse SDK ではなく OTEL を使用するという決定は、ベンダーに依存しない柔軟性を提供し、テレメトリデータを複数の観測可能性バックエンドへルーティングしたり、進化する監視要件に適応させたりすることを可能にします。
ランタイム時、Chat Service の各 AWS Lambda ステージは手動で OTEL Java SDK を用いてインストゥルメント化され、OTEL Generative AI セマンティック標準 に従ってレイテンシ、トークン使用量、モデルの判断、プロンプトメタデータが記録されます。スパン はほぼリアルタイムで Langfuse へ公開され、チームは Amazon Bedrock ConverseStream API、ナレッジベース検索、Claude Sonnet 4.5 が単一のリクエスト内でどのように相互作用するかを透明性を持って把握できます。詳細なテレメトリデータにより、チームはパフォーマンスのボトルネックを特定し、プロンプト戦略を最適化し、リトリバル精度を向上させる一方で、責任ある AI プラクティスを維持することが可能になります。
この観測可能性フレームワークは、システムの挙動に対する信頼と説明責任を維持します。エンジニアはユーザーのアクションとモデルの結果を相関付け、複数サービスにわたるデータ系譜を追跡し、運用を中断することなく設定を微調整できます。OpenTelemetry の相互運用性と Langfuse の可視化・分析機能を組み合わせることで、Amazon FinTech チームは大規模な生成 AI システムの評価に向けたスケーラブルで拡張性の高い基盤を獲得し、あらゆるインタラクションを継続的な改善のための実行可能なインサイトへと変換します。
以下のスクリーンショットは、Langfuse でキャプチャされたエンドツーエンドのトレースを示しており、観測性ソリューションがクエリ拡張や知識検索からモデルのプロンプト、応答、レイテンシ指標に至るまでの完全なワークフローをどのように捉えているかを解説しています。また、ソースドキュメントの引用も強調されており、応答生成中にコンテキスト情報がシステム内でどのように流れるかという透明性の高い視点を提供します。
参照:Langfuse に投稿されたエンドツーエンドのトレース
結論
本記事では、Amazon FinTech チームが Amazon Bedrock を活用してスケーラブルな AI ソリューションを構築し、知識検索の自動化、会話ワークフロー、応答生成を通じて規制関連の問い合わせに対応する方法をご覧いただきました。ドキュメント取り込みパイプライン、多段階の状態保持型会話、OpenTelemetry と Langfuse による詳細な観測性を組み合わせることで、このアーキテクチャはチームが統制され、追跡可能でコンプライアンスに準拠した方法で規制関連の問い合わせに対応することを可能にします。
スタック全体が AWS のサーバーレスサービス上で構築されているため、エンタープライズグレードのデプロイに必要な運用上のスケーラビリティ、セキュリティ、弾力性を提供します。法的コンプライアンス、規制関連の問い合わせ、あるいは高ボリュームの内部知識ワークフローに取り組む場合でも、このパターンはビジネスドメインに合わせて調整・拡張できる実用的な基盤となります。
生成 AI を活用して知識集約型プロセスの近代化を検討されている場合は、Amazon Bedrock のドキュメントをご参照ください。ここでは、安全でガバナンスが効き、スケーラブルな AI 駆動ワークフローをどのように構築し始めるかについてご紹介します。
著者紹介
<img loading="lazy" class="size-full wp-image-129979 alignleft" src=
原文を表示
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.
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.
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.
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.
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 Serverlessfor 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.
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:
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:
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.
- Document Upload by User: Users upload documents through the client application.
- 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.
- Document Upload: The client application uses the generated pre-signed URL to upload the document.
- 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.
- 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.
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.
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:
- Initiate Chat Conversation: Users initiate or open an existing chat session through the client application.
- WebSocket Connection: The application uses WebSockets to establish a persistent, bi-directional connection with Amazon API Gateway.
- Message Submission: The application posts the user questions through the WebSocket connection which is propagated to the Chat service AWS Lambda function.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
At runtime, each stage of the Chat Service AWS Lambda is manually instrumented using the OTEL Java SDKto 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.
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.
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
Reference: End-to-End Trace Posted in 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.
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.
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.
About the authors
<img loading="lazy" class="size-full wp-image-129979 alignleft" src=
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み