Amazon Bedrock を用いた Deltek 社の政府調達文書の質疑応答システム

この記事は、Deltek の Kevin Plexico と Shakun Vohra が共同で執筆した How Deltek uses Amazon Bedrock for question and answering on government solicitation documents を翻訳したものです。翻訳は Solutions Architect の宮口直樹が担当しました。

文書を使用した質疑応答 (Q&A) は、カスタマーサポートチャット、法律調査アシスタント、ヘルスケアアドバイザーなど、さまざまなユースケースで一般的に使用されるアプリケーションです。Retrieval Augmented Generation (RAG) は、大規模言語モデル（LLM）の力を活用して自然言語で文書とやり取りするための主要な方法として登場しました。

このブログ記事では、AWS Generative AI Innovation Center (GenAIIC) が Deltek 向けに開発したカスタムソリューションの概要を紹介します。Deltek は政府契約およびプロフェッショナルサービスの両分野におけるプロジェクトベースのビジネスで世界的な標準として認められた企業です。Deltek は 30,000 を超えるクライアントに業界特化型のソフトウェアと情報ソリューションを提供しています。

この共同プロジェクトでは、AWS GenAIIC チームは Deltek 向けに、単一および複数の政府調達文書に対する Q&A を可能にする RAG ベースのソリューション作成しました。このソリューションでは、Amazon Textract、Amazon OpenSearch Service、Amazon Bedrock などの AWS サービスを利用しています。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要な AI 企業から、高性能な基盤モデル (FM) と LLM を単一の API で選択して利用できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための機能を提供します。

Deltek は、PDF 以外のファイル形式のサポートやデータ取り込みパイプラインのよりコスト効率の高いアプローチの実装など、特定の要件により適合させるために、このソリューションの強化に継続的に取り組んでいます。

RAG とは何か？

RAG は、LLM が応答を生成する前に、学習データソース以外の信頼できる知識ベースを参照できるようにすることで、LLM の出力を最適化するプロセスです。このアプローチは、誤った情報、古い情報、一般的すぎる情報を提示したり、用語の混同により不正確な応答を生成したりするなど、LLM に関連する課題を対処します。RAG により、LLM は組織内部のナレッジや特定の分野を参照することで、モデルを再学習する必要なく、より関連性が高く、正確で、コンテキストに即した応答を生成できます。これによって組織は生成されるテキスト出力をより制御できるようになり、ユーザーは LLM がどのように応答を生成したかについての洞察を得ることができます。RAG はさまざまな状況で LLM の性能を改善するための費用対効果の高いアプローチとなります。

主な課題

単一の文書に対して Q&A で RAG を適用するのは簡単ですが、複数の関連文書に同じことを適用するには、いくつかの特殊な課題が生じます。例えば、時間の経過とともに変化する文書に対して Q&A を行う場合、質問が時間とともに変化する概念に関するものであれば、文書の時系列順序を考慮することが必要です。順序を考慮しないと、過去のある時点では正確だったが、時系列に沿って整理された文書群の中のより最新の情報に基づくと、現在では古くなっている回答を提供してしまう可能性があります。時間的側面を適切に扱うことは、単一の文書から、時間の経過とともに変化する相互にリンクした文書群への質問応答を拡張する際の重要な課題です。

ソリューションの概要

ユースケースの例として、時系列の関係にある 2 つの文書に対する Q&A について説明します。1 つは長い提案依頼書（RFP）の草案文書、もう 1 つは関連する後続の情報提供依頼書（RFI）への政府の回答で、追加および改訂された情報が提供されています。

このソリューションは、2 つのステップで RAG アプローチを展開しています。

最初のステップはデータ取り込みで、以下の図に示す通りです。これには、PDF 文書の一回限りの処理が含まれます。ここでのアプリケーションコンポーネントは、テキストの分割やバックグラウンドでのサービス呼び出しなどの簡単な処理を行うユーザーインターフェイスです。手順は以下の通りです。

1. ユーザーが文書をアプリケーションにアップロードします。
2. アプリケーションは Amazon Textract を使用して、入力文書からテキストと表を取得します。
3. テキスト埋め込みモデルがテキストチャンクを処理し、各テキストチャンクの埋め込みベクトルを生成します。
4. テキストチャンクの埋め込み表現と関連するメタデータが OpenSearch Service にインデックス化されます。

2 番目のステップは以下の図に示す通り Q&A です。このステップでは、ユーザーが取り込まれた文書に関する質問をし、自然言語での回答を期待します。ここでのアプリケーションコンポーネントは、バックグラウンドで別のサービスを呼び出すなどの簡単な処理を行うユーザーインターフェースです。手順は以下の通りです。

1. ユーザーが文書に関する質問をします。
2. アプリケーションは、入力された質問の埋め込みベクトルを取得します。
3. アプリケーションは、OpenSearch Service から取得したデータと質問を Amazon Bedrock に渡して、回答を生成します。モデルはセマンティック検索を実行し、文書から関連するテキストチャンク（コンテキスト）を見つけ出します。埋め込みベクトルは、質問をテキストから数値表現の空間にマッピングします。
4. 質問とコンテキストが組み合わされ、LLM へのプロンプトとして入力されます。言語モデルは、ユーザーの質問に対する自然言語の回答を生成します。

我々のソリューションでは、PDF、PNG、JPEG、TIFF をテキストデータに変換できる Amazon Textract を使用しました。また、表などの複雑なレイアウトも分析しやすい形式に整形します。次のセクションでは、Amazon Textract の機能を示す例を紹介します。

OpenSearch は、Elasticsearch から派生したオープンソースの分散検索および分析スイートです。大量のデータを効率的に保存し、クエリを実行するためにベクトルデータベース構造を使用しています。OpenSearch Service には現在、数万のアクティブユーザーがいて、数十万のクラスターを管理し、月間数百兆のリクエストを処理しています。私たちは OpenSearch Service とその基盤となるベクトルデータベースを使用して、以下のことを行いました。

• 文書をベクトル空間にインデックス化し、関連項目を近接して配置することで関連性を向上させる
• Q&A のステップで、ベクトル間の近似最近傍探索を使用して、関連する文書チャンクを迅速に取得する

OpenSearch Service 内のベクトルデータベースにより、関連データチャンクを効率的に保存し、迅速に取得することができ、これが質問応答システムの基盤となりました。文書をベクトルとしてモデル化することで、明示的なキーワード一致がなくても関連する段落を見つけられるようになりました。

テキスト埋め込みモデルは、テキストからの単語やフレーズを密なベクトル表現にマッピングする機械学習 (ML) モデルです。テキスト埋め込みは、RAG のような情報検索システムで以下の目的でよく使用されます。

• ドキュメント埋め込み – 埋め込みモデルを使用して、文書の内容をエンコードし、埋め込み空間にマッピングします。通常、文書を段落、セクション、または固定サイズのチャンクなどの小さな単位に分割することが一般的です。
• クエリ埋め込み – ユーザーのクエリをベクトルに埋め込みし、セマンティック検索を実行して文書チャンクと照合できるようにします。

この記事では、最大 8,000 トークンを受け取り、1,536 次元の数値ベクトルを出力するモデルである Amazon Titan Embeddings G1 – Text v1.2 を使用しました。このモデルは Amazon Bedrock 経由で利用可能なモデルです。

Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの有力な AI 企業から、すぐに使用できる基盤モデルを提供しています。プライバシーとセキュリティを維持しながら、これらのモデルにアクセスし、生成AIアプリケーションを構築するための単一のインターフェースを提供します。我々は、Amazon Bedrock の Anthropic Claude v2 を使用して、質問とコンテキストに基づいた自然言語の回答を生成しました。

以下のセクションでは、このソリューションの 2 つのステップをより詳しく見ていきます。

データ取り込み

まず、RFP および RFI の回答文書の下書きが、Q&A の時に使用できるように処理されます。データ取り込みには、以下のステップが含まれます。

1. 文書は Amazon Textract に渡され、テキストに変換されます。
2. 言語モデルが表に関する質問に適切に答えられるようにするため、Amazon Textract の出力から表を CSV 形式に変換するパーサーを作成しました。表を CSV に変換することで、モデルの理解力が向上します。たとえば、以下の図は PDF 形式の RFI 回答書の一部と、対応する抽出されたテキストを示しています。抽出されたテキストでは、表が CSV 形式に変換され、他のテキストの中に配置されています。
   
3. 長い文書の場合、抽出されたテキストが LLM の入力サイズ制限を超える可能性があります。そのような場合、テキストを小さなオーバーラップ部分を含む複数のチャンクに分割できます。チャンクのサイズとオーバーラップの割合は、ユースケースによって異なる場合があります。セクション単位のチャンク分割（各文書セクションごとに独立してチャンク分割を行う）を適用しており、後述のユースケースにて説明します。
4. 一部の文書クラスは、標準的なレイアウトや形式に従っている場合があります。例えば、RFP には、定義されたセクションを含む特定のレイアウトがあることが多いです。このレイアウトを使用すれば、各文書セクションを独立して処理できます。また、目次が存在しても関連性がない場合は、削除される可能性があります。このブログ記事の後半で、文書構造の検出と利用のデモンストレーションを行います。
5. 各テキストチャンクの埋め込みベクトルは、埋め込みモデルから取得されます。
6. 最後のステップで、埋め込みベクトルが OpenSearch Service データベースにインデックス化されます。埋め込みベクトルに加えて、文書名、文書セクション名、公開日などのメタデータも、テキストフィールドとしてインデックスに追加されます。文書が時系列的に関連している場合、公開日は有用なメタデータで、LLM が最新の情報を特定できるようになります。次のコードスニペットは、インデックスの中身を示しています。

index_body = {
    "embedding_vector": <embedding vector of a text chunk>,
    "text_chunk": <text chunk>,
    "document_name": <name>,
    "section_name": <section name>,
    "release_date": <release date>,
    # 更なるメタデータを追加できます
}

Q&A

Q&A フェーズでは、ユーザーは前のステップで取り込まれた RFP および RFI について自然言語で質問ができます。まず、セマンティック検索を実行し、ユーザーの質問に関連するテキストチャンクを取得します。次に、取得したコンテキストを使って質問を拡張してプロンプトを作成します。最後に、プロンプトを Amazon Bedrock に送信し、LLM が自然言語の回答を生成します。詳細な手順は以下の通りです。

1. 入力された質問の埋め込みベクトルが、Amazon Bedrock の Amazon Titan 埋め込みモデルから取得されます。
2. 質問の埋め込みベクトルを使用して、OpenSearch Service でセマンティック検索を実行し、関連性の高い上位 K 個のテキストチャンクを見つけます。以下は、OpenSearch Service に渡される検索クエリ本文の例です。検索クエリの構造化の詳細については、OpenSearch のドキュメントを参照してください。

search_body = {
    "size": top_K,
    "query": {
        "script_score": {
            "query": {
                "match_all": {}, # skip full text search
            },
            "script": {
                "lang": "knn",
                "source": "knn_score",
                "params": {
                    "field": "embedding-vector",
                    "query_value": question_embedding,
                    "space_type": "cosinesimil"
                }
            }
        }
    }
}

3. 取得したメタデータ (セクション名や文書のリリース日付など) は、テキストのコンテキストを補強し、以下のように大規模な言語モデル (LLM) にさらに情報を提供するために使用されます。

   def opensearch_result_to_context(os_res: dict) -> str:
       """
       Convert OpenSearch result to context
       Args:
       os_res (dict): Amazon OpenSearch results
       Returns:
       context (str): Context to be included in LLM's prompt
       """
       data = os_res["hits"]["hits"] 
       context = [] 
       for item in data:
           text = item["_source"]["text_chunk"] 
           doc_name = item["_source"]["document_name"] 
           section_name = item["_source"]["section_name"] 
           release_date = item["_source"]["release_date"] 
           context.append(
               f"<<Context>>: [Document name: {doc_name}, Section name: {section_name}, Release date: {release_date}] {text}"
           )
       context = "\n \n ------ \n \n".join(context)
       return context

4. 入力された質問は取得したコンテキストと組み合わされてプロンプトが作成されます。質問の複雑さや特殊性によっては、大規模な言語モデル (LLM) にさらなる説明とガイダンスを提供するために、初期プロンプトに追加で Chain-of-Thought (CoT) プロンプトを追加する必要があるかもしれません。CoT プロンプトは、質問を適切に理解し、回答を作成するために必要な論理的な推論と思考のプロセスを LLM に示すように設計されています。これは、LLM が質問に含まれる重要な情報を理解し、どのような回答が必要かを判断し、適切かつ正確な回答を構築するために従うべき一種の内部モノローグまたは認知的経路を示しています。本ユースケースでは、以下の CoT プロンプトを使用しています。

"""
Context below includes a few paragraphs from draft RFP and RFI response documents:

Context: {context}

Question: {question}

Think step by step:

1- Find all the paragraphs in the context that are relevant to the question.
2- Sort the paragraphs by release date.
3- Use the paragraphs to answer the question.

Note: Pay attention to the updated information based on the release dates.
"""

5. プロンプトは、Amazon Bedrock の LLM に渡され、自然言語で回答が生成されます。Amazon Bedrock の Anthropic Claude V2 モデルでは、以下のような推論パラメータを使用しています。再現性を確保し、LLM のハルシネーションを防ぐために、Temperature パラメータは通常 0 に設定されます。一般的な RAG アプリケーションでは、top_k と top_p はそれぞれ 250 と 1 に設定されます。max_tokens_to_sample は、生成が期待される最大トークン数に設定します（英語の場合、1 トークンは約 3/4 語に相当します）。詳細については、推論パラメータを参照してください。

{
    "temperature": 0,
    "top_k": 250,
    "top_p": 1,
    "max_tokens_to_sample": 300,
    "stop_sequences": ["\n\nHuman:\n\n"]
}

使用例

デモとして、関連する 2 つの文書に対する Q&A の例を説明します。1 つは 167 ページの PDF 形式の RFP 草案、もう 1 つは後に公開された 6 ページの PDF 形式の RFI 回答書で、RFP 案に対する追加情報と更新内容が含まれています。

以下は RFP 草案と RFI 回答書に基づいて、プロジェクトの規模要件が変更されたかどうかを尋ねる質問例です。

“Have the original scoring evaluations changed? if yes, what are the new project sizes?”

次の図は、回答が含まれている RFP 草案の関連セクションを示しています。

以下の図は、回答が含まれている RFI 回答書の関連セクションを示しています。

LLM が正しい応答を生成するためには、OpenSearch Service から取得したコンテキストに、前の図に示した表が含まれている必要があります。また、LLM は公開日などのメタデータからコンテンツの順序を整理し、自然言語で読みやすい回答を生成できる必要があります。

データ取り込みのステップは以下の通りです。

1. RFP 草案および RFI 回答書は、Amazon Textract にアップロードされ、テキストと表がコンテンツとして抽出されます。さらに、正規表現を使用して文書のセクションと目次を特定しました (それぞれ以下の図を参照)。このユースケースでは、目次に関連する情報がないため、削除できます。
   
   
2. 各文書のセクションを独立して、オーバーラップを含む小さなチャンクに分割しました。本ユースケースでは、チャンクサイズを 500 トークン、オーバーラップを 100 トークンとしました（英語の場合、1 トークンは約 3/4 語に相当します）。BPE トークナイザを使用しており、各トークンは約 4 バイトに相当します。
3. Amazon Bedrock の Amazon Titan Embeddings G1 – Text v1.2 モデルを使用して、各テキストチャンクの埋め込みベクトルを取得します。
4. 各テキストチャンクは、セクション名や文書公開日などのメタデータとともに、OpenSearch Service インデックスに格納します。

Q&A の手順は以下の通りです。

1. 入力された質問は、まず埋め込みモデルを使って数値ベクトルに変換されます。このベクトル表現は、次のステップでのセマンティック検索と関連コンテキストの取得に使用されます。
2. 上位 K 件の関連テキストチャンクとメタデータが OpenSearch Service から取得されます。
3. opensearch_result_to_context 関数と事前定義されたプロンプトテンプレートを使用して、入力の質問と取得したコンテキストに基づいてプロンプトが作成されます。
4. プロンプトは Amazon Bedrock 上の LLM に送信され、自然言語での回答が生成されます。以下は、Anthropic Claude v2 によって生成された応答で、 RFP 草案および RFI 回答書に示された情報と一致しています。質問は “Have the original scoring evaluations changed? If yes, what are the new project sizes?” でした。CoT プロンプトを使用することで、モデルは質問に正確に答えることができます。

主な機能

このソリューションは主に以下の機能を持ちます。

• セクション単位のチャンク分割 – 文書のセクションを識別し、各セクションを独立して小さなチャンクに分割し、一部オーバーラップさせることでデータ取り込みを最適化します。
• 表から CSV への変換 – Amazon Textract で抽出された表を CSV 形式に変換し、言語モデルが表を理解し質問に答える能力を向上させます。
• インデックスへのメタデータ追加 – セクション名や文書の公開日などのメタデータをテキストチャンクと共に OpenSearch Service インデックスに格納します。これにより、言語モデルが最新または関連性の高い情報を特定できるようになります。
• CoT プロンプト – chain-of-thought プロンプトを設計し、質問を適切に理解し正確な回答を作成するために必要な論理的ステップについて、言語モデルにさらなる明確化とガイダンスを提供します。

これらの機能により、文書に関する質問への回答におけるソリューションの精度と能力が向上しました。実際、Deltek の専門家による LLM 生成レスポンスの評価では、このソリューションは全体で 96% の精度を達成しました。

結論

このブログ記事では、複数の政府調達文書に対する質問回答のための生成 AI アプリケーションについて概説しました。この記事で触れたソリューションは、AWS GenAIIC チームが Deltek と協力して開発したパイプラインを簡略化したものであり、時系列で個別に公開される長大な文書に対する Q&A を可能にするアプローチを説明しました。Amazon Bedrock と OpenSearch Service を使用することで、この RAG アーキテクチャはエンタープライズレベルの文書量に対応できます。さらに、CoT ロジックを使用してプロンプトテンプレートを紹介し、LLM がユーザーの質問に対して正確な応答を生成するのを支援しました。このブログ記事では、複雑な提案文書とその改訂版のレビューを合理化するための実世界の生成 AIソリューションの概要を提供することを目的としました。

Deltek はこのソリューションを固有のニーズに合わせて積極的に改良し最適化しています。この改良には、PDF 以外のファイル形式のサポート拡大や、データ取り込みパイプラインのためのコスト効率が良い手法の採用が含まれます。

プロンプトエンジニアリングと生成 AI を活用した Q&Aの詳細は、Amazon Bedrock ハンズオンをご覧ください。技術サポートまたは AWS 生成 AI 専門家に連絡するには、GenAIIC ウェブページをご覧ください。

リソース

Amazon Bedrock の詳細は、以下のリソースを参照してください。

• Amazon Bedrock ワークショップ
• Amazon Bedrock ユーザーガイド

OpenSearch Service の詳細は、以下のリソースを参照してください。

• Amazon OpenSearch Service ドキュメント
• Amazon OpenSearch ワークショップ

AWS の RAG リソースについては、以下のリンクを参照してください。

• RAG (検索拡張生成)
• Amazon Bedrock のナレッジベース

著者について

Kevin Plexico は、Deltek の情報ソリューション部の Senior Vice President で、政府請負業者および AEC 業界の顧客に対する調査、分析、仕様書作成を監督しています。
彼は 5,000 を超える顧客に不可欠な政府市場の情報を提供する GovWin IQ の提供を主導し、業界最大の規模の分析チームを管理しています。
Kevin はまた、Deltek の Specification Solutions 製品を統括しており、MasterSpec ®、SpecText などの建設仕様書コンテンツを作成しています。

Shakun Vohra は、20 年以上のソフトウェアエンジニアリング、AI/ML、ビジネスプロセスの改革、データ活用の専門知識を持つ傑出した技術リーダーです。
Deltek では、複数の大陸にまたがる多様な高パフォーマンスチームを率いて大きな成長を遂げました。
Shakun は、技術戦略と企業の目標を合わせ、経営陣と協力して組織の方向性を形作ることに長けています。
戦略的なビジョンとメンターシップで知られ、次世代のリーダーと変革的な技術ソリューションの育成に一貫して尽力してきました。

Amin Tajgardoon は、AWS Generative AI Innovation Center の Applied Scientist です。
コンピューターサイエンスと機械学習に関する幅広い経験を持っています。
特に Amin 氏は、ディープラーニングと予測、予測の説明手法、モデルドリフト検出、確率的生成モデル、そして医療分野における AI の応用に注力してきました。

Anila Joshi は、10 年以上にわたり AI ソリューションの構築に携わってきました。
AWS Generative AI Innovation Center の Applied Science Manager として、可能性の限界を押し広げる AI の革新的な応用を先導し、顧客が安全なジェネレーティブ AI ソリューションを構想、特定、実装するのを支援することで、顧客による AWS サービスの採用を加速させています。

Yash Shah と彼の率いるサイエンティスト、専門家、エンジニアのチームは、AWS Generative AI Innovation Center で、AWS の主要顧客と協力し、Generative AI の可能性を最大限に引き出し、ビジネス価値を生み出すことに取り組んでいます。
Yash は 7 年半以上 Amazon に在籍し、複数の地理的地域にわたり、ヘルスケア、スポーツ、製造業、ソフトウェア業界の顧客と協働してきました。

Jordan Cook は、AWS 分野で 20 年近くの実績を持つ Sr. Account Manager で、セールスとデータセンター戦略を専門としています。Jordan は、Amazon Web Services に関する広範な知識と、クラウドコンピューティングに対する深い理解を活かし、企業がクラウドインフラストラクチャを最適化し、運用効率を高め、イノベーションを促進できるよう、カスタマイズされたソリューションを提供しています。