「Q4 Inc.が、Q&Aチャットボットの構築において、数値と構造化データセットの課題に対処するために、Amazon Bedrock、RAG、およびSQLDatabaseChainを使用した方法」

「Q4 Inc.のQ&Aチャットボットの構築における課題解決方法：Amazon Bedrock、RAG、およびSQLDatabaseChainの活用」

この記事はQ4 Inc.のStanislav Yeshchenkoと共同執筆されました。

企業は、Q&Aチャットボットを構築するための主要なアプローチとして、Retrieval Augmented Generation (RAG)に取り組んでいます。我々は、入手可能なデータセットの性質から生じる新たな課題が続々と現れていることを目の当たりにしています。これらのデータセットは、数値データとテキストデータの組み合わせであり、時には構造化されたデータ、非構造化されたデータ、または半構造化されたデータです。

Q4 Inc.は、AWS上で構築されたAIのユースケースの1つにおいて、これらの課題のいくつかに対処する必要がありました。この記事では、Q4が実装したQ&Aボットのユースケース、数値と構造化されたデータセットがもたらす課題、およびSQLを使用することが有効な解決策であるとQ4が結論づけた方法について説明します。最後に、Q4チームがAmazon BedrockとSQLDatabaseChainを使用して、SQL生成を伴うRAGベースのソリューションを実装した方法について詳しく見ていきます。

ユースケースの概要

Q4 Inc.は、トロントを拠点とし、ニューヨークとロンドンにオフィスを構える、発行者、投資家、売り手が効率的に接続、コミュニケーション、関与するためのリーディングな資本市場アクセスプラットフォームです。Q4プラットフォームは、IRウェブサイトの製品、バーチャルイベントソリューション、エンゲージメント分析、投資家関係の顧客管理（CRM）、株主および市場分析、監視、ESGツールを通じて、資本市場全体での相互作用を促進します。

現在の社会の速いペースとデータ駆動の金融環境では、投資家関係担当役員（IRO）は、企業と株主、アナリスト、投資家の間のコミュニケーションを促進する重要な役割を果たしています。IROは、日々の業務の一環として、CRM、所有権記録、株式市場データなどのさまざまなデータセットを分析します。これらのデータの集約は、財務報告書の作成、投資家関係の目標の設定、既存および潜在的な投資家とのコミュニケーションの管理に使用されます。

需要の増加に応えるために、Q4は効率的で動的なデータの取得を実現するチャットボットQ&Aツールを作成することを目指しました。このツールは、IROが必要な情報に直感的かつ分かりやすい形式でアクセスするための方法を提供することが目標です。

最終的な目標は、パブリックで利用可能なデータと独自の顧客固有のQ4データをシームレスに統合し、最高レベルのセキュリティとデータプライバシーを維持することです。性能に関しては、エンドユーザーに対するポジティブな体験を確保するために、クエリの応答時間を秒単位で維持することが目標でした。

金融市場は規制がある業界であり、リスクが高いです。不正確または古い情報を提供することは、投資家や株主の信頼に悪影響を与えるだけでなく、データプライバシーのリスクも引き起こす可能性があります。業界と要件を理解しているQ4は、市場に導入される前に、データプライバシーと応答精度を評価する上での指針と位置づけています。

PoC（概念実証）のため、Q4は金融所有権データセットを使用することにしました。このデータセットは、所有資産の数量を表す時系列データポイント、投資機関、個人、公開企業間の取引履歴、およびその他の要素で構成されています。

Q4は、我々が議論してきたすべての機能要件と非機能要件を満たすことができることを確認するため、プロジェクトが商業的に実現可能なままである必要がありました。それはアプローチ、アーキテクチャ、技術選択、ソリューション固有の要素の決定の過程を通じて尊重されました。

実験と課題

人間の言語の質問を理解し、正確な回答を生成するために、大規模な言語モデル（LLM）を使用する必要があることは、最初から明らかでした。

以下は、チームによって行われた実験、特定された課題、および得られた教訓のいくつかです：

  • 事前トレーニング – Q4は、独自のデータセットを使用してLLMを事前トレーニングする際に生じる複雑さと課題を理解しました。これは、データの前処理、トレーニング、評価など、非自明なステップが多く、リソースを必要とするアプローチであることがすぐに明らかになりました。そのため、費用対効果が悪くなる可能性があります。時系列データセットの性質を考慮すると、Q4は新しいデータが入ってくるたびに連続的な事前トレーニングを継続的に実施する必要があると認識しました。これには、データサイエンス、機械学習、ドメイン知識に精通した専門のクロスディシプリナリーチームが必要でした。
  • 微調整 – 事前トレーニングされた基礎モデル（FM）の微調整には、いくつかのラベル付きの例を使用しました。このアプローチは最初の成功を示しましたが、多くの場合、モデルの虚構幻想が課題となりました。モデルは微妙な文脈的な手がかりを理解するのに苦労し、正しい結果を返すことができませんでした。
  • セマンティックサーチを伴うRAG – SQL生成に移る前の最後のステップとして、従来のセマンティックサーチを伴うRAGを利用しました。チームは、検索とセマンティックサーチ、埋め込みを使用して文脈を抽出する実験を行いました。埋め込みの実験では、データセットは埋め込みに変換され、ベクトルデータベースに格納され、その後、質問の埋め込みと一致するデータを抽出するために使用されました。3つの実験のいずれかで抽出された文脈は、元のプロンプトを補完するための入力としてLLMに使用されました。このアプローチは、テキストベースのコンテンツにはうまく機能しましたが、データが自然言語で単語、文、段落から成る場合に適しています。Q4のデータセットは主に数字、金融取引、株価、日付などから成る金融データであり、3つのケースともサブオプティマルな結果となりました。数値から生成された埋め込みは類似性順位付けに苦労し、多くの場合、正しくない情報を取得する結果となりました。

Q4の結論：SQLの生成が前進の道である

従来のRAGメソドロジーを使用する際に直面する課題を考慮し、チームはSQLの生成を検討し始めました。アイデアは、ユーザーの質問を自然言語でLLMに提示し、最初にSQL文を生成することです。生成されたクエリはデータベースに対して実行され、関連するコンテキストを取得します。最後に、コンテキストは要約ステップの入力プロンプトを補完するために使用されます。

Q4の仮説は、検索ステップにおいて、特に数値データセットに対してより高い再現率を得るために、ユーザーの質問からまずSQLを生成することが必要であるということでした。これにより、正確さが向上するだけでなく、特定の質問に対してビジネスドメイン内のコンテキストを維持することも期待されていました。クエリ生成と正確なSQLの生成のために、Q4はLLMをデータセット構造に完全にコンテキストを認識させる必要がありました。これは、プロンプトにデータベーススキーマ、いくつかのサンプルデータ行、理解しにくいフィールドのための人間が読みやすいフィールドの説明を含める必要がありました。

初期のテストに基づくと、この方法は素晴らしい結果を示しました。必要な情報を備えたLLMは正しいSQLを生成し、その後データベースに対して実行して正しいコンテキストを取得しました。このアイデアを実験した結果、Q4はSQLの生成が自身の特定のデータセットのコンテキスト抽出の課題に対処する進むべき道であると判断しました。

まずは、全体的な解決策のアプローチについて説明し、そのコンポーネントを分解し、最後に組み合わせてみましょう。

解決策の概要

LLMは、数十億のパラメータを持つ大規模なモデルであり、さまざまなソースから非常に大量のデータを使って事前にトレーニングされています。トレーニングデータセットの幅広さから、LLMはさまざまなドメインにおける一般的な知識を持つことが期待されています。LLMはまた、モデルごとに異なる推論能力で知られています。この一般的な振る舞いは、追加のドメイン固有の事前トレーニングデータを使用して基本モデルをさらに最適化したり、ラベル付きデータを使用して微調整することで、特定のドメインや業界に最適化することができます。適切なコンテキスト、メタデータ、および指示が与えられれば、適切なドメイン固有のコンテキストにアクセスできる汎用LLMは、良質なSQLを生成することができます。

Q4のユースケースでは、まず顧客の質問をSQLに翻訳します。これを行うために、ユーザーの質問、データベーススキーマ、いくつかのサンプルのデータベース行、そして詳細な指示をLLMに対してプロンプトとして結合します。SQLを得た後、必要に応じて検証ステップを実行することができます。SQLの品質に満足した場合、クエリをデータベースに対して実行し、次のステップに必要な関連するコンテキストを取得します。関連するコンテキストを取得したら、元の質問、取得したコンテキスト、そして一連の指示をLLMに送信して最終的な要約された応答を生成します。最後のステップの目標は、LLMに結果を要約させ、文脈に即した正確な回答を提供し、それをユーザーに渡すことです。

プロセスの各段階で使用するLLMの選択は、正確さ、コスト、パフォーマンスに大きな影響を与えます。同じユースケース内でLLMを切り替える柔軟性を提供するプラットフォームやテクノロジーを選択することは、出力の品質、レイテンシ、コストを最適化する上で有益です。LLMの選択については、この記事の後半で詳しく説明します。

解決策の構築ブロック

アプローチを高レベルで説明したので、詳細に立ち入って解決策の構築ブロックについて見ていきましょう。

Amazon Bedrock

Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazonを含む主要な企業からの高性能なFMの選択肢を提供するフルマネージドサービスです。Amazon Bedrockは、生成型AIアプリケーションを構築するために必要なさまざまなツールを提供し、開発プロセスを簡素化し、プライバシーとセキュリティを保護します。さらに、Amazon Bedrockでは、さまざまなFMオプションから選択でき、モデルの応答をユースケースの要件に合わせて調整するために独自のデータを使用してモデルをさらに微調整することができます。Amazon Bedrockは完全なサーバーレスであり、利用可能なモデルへのアクセスを単一のAPIを介して拡張します。最後に、Amazon BedrockはHIPAAの適格性やGDPRのコンプライアンスなど、さまざまなセキュリティおよびプライバシー要件をサポートしています。

Q4の解決策では、Amazon BedrockをサーバーレスでAPIベースのマルチファウンデーションモデルの構築ブロックとして使用しています。タスクのタイプに応じて、同じユースケース内でLLMへの複数回のトリップを行い、SQL生成、検証、要約のいずれかに最適なモデルを選択することができます。

LangChain

LangChainはオープンソースの統合およびオーケストレーションフレームワークであり、事前に構築されたモジュール（I/O、リトリーバル、チェーン、およびエージェント）を備えており、FM、データソース、ツール間のタスクを統合し、オーケストレーションするために使用できます。このフレームワークは、ゼロからコードを書かずに、複数のステップを組み合わせて必要な出力を生成する生成型AIアプリケーションの構築を容易にします。LangChainはAmazon BedrockをマルチファウンデーションモデルAPIとしてサポートしています。

Q4のユースケースに特化して、LangChainをワークフローでのタスクの調整やオーケストレーション、データソースやLLMsへの接続などに使用しています。このアプローチにより、既存のLangChainモジュールを使用できるため、コードが簡素化されています。

SQLDatabaseChain

SQLDatabaseChainは、langchain_experimentalからインポートできるLangChainのチェーンです。SQLDatabaseChainを使用することで、効果的なテキストからSQLへの変換や実装を活用して、SQLクエリの作成、実装、実行を簡単に行うことができます。

私たちのユースケースでは、SQLDatabaseChainを使用してSQL生成を行い、データベースとLLMの間の相互作用を簡素化し、オーケストレーションしています。

データセット

私たちの構造化データセットは、SQLデータベース、データレイク、またはデータウェアハウスに存在するものであれば、SQLをサポートしている限り利用できます。私たちのソリューションでは、SQLサポートのあるどのデータセット型でも使用することができ、このことはソリューションを抽象化し、ソリューションを何ら変更させないべきです。

実装の詳細

ソリューションのアプローチ、ソリューションのコンポーネント、技術の選択、およびツールを探究したので、これらの要素を組み合わせることができます。以下の図は、エンドツーエンドのソリューションを示しています。

エンドツーエンドソリューションアーキテクチャ

実装の詳細とプロセスフローについて説明しましょう。

SQLクエリの生成

コーディングを簡素化するために、既存のフレームワークを使用します。オーケストレーションフレームワークとしてLangChainを使用します。まず、入力ステージから始めます。ここではユーザーの質問を自然言語で受け取ります。

この最初のステージでは、この入力を受け取り、データベースとのコンテキスト抽出のために実行できる同等のSQLを生成します。SQLの生成には、SQLDatabaseChainを使用します。SQLDatabaseChainは、Amazon Bedrockを介して所望のLLMにアクセスするために依存しています。Amazon Bedrockを使用することで、単一のAPIを介して複数の下位LLMにアクセスし、LLMトリップごとに適切なLLMを選ぶことができます。まず、データベースへの接続を確立し、使用するテーブルから必要なスキーマといくつかのサンプル行を取得します。

私たちのテストでは、2-5行のテーブルデータが十分な情報を与え、余分なオーバーヘッドを追加せずにモデルに適切なコンテキストを提供することがわかりました。3行は、過剰な入力を避けつつ、コンテキストを提供するのに十分でした。私たちのユースケースでは、AnthropicのClaude V2から始めました。このモデルは、適切なコンテキストと指示が与えられた場合に高度な推論と明確な文脈に基づく応答が得られることで知られています。指示の一部として、Comp_NAME列が会社名を表すことを説明することができます。これで、ユーザーの質問自体、データベースのスキーマ、使用するテーブルの3つのサンプル行、および必要なSQLをプレーンなSQL形式でコメントや追加なしで生成するための一連の指示を組み合わせて、プロンプトを構築することができます。

すべての入力要素は、モデルの入力プロンプトと見なされます。モデルが好む構文に合わせて調整された上手に設計された入力プロンプトは、出力の品質と性能の両方に大きな影響を与えます。特定のタスクに使用するモデルの選択は重要ですが、その理由は出力の品質だけでなく、コストとパフォーマンスの影響もあるからです。

この記事では、モデルの選択とプロンプトのエンジニアリングと最適化について後で詳しく説明しますが、クエリ生成の段階では、特にユーザーの質問が適切に表現されており、複雑で間接的な入力ではない場合、クロードインスタントが同等の結果を生成できることに気付きました。しかし、より複雑で間接的なユーザーの入力でも、クロードV2はより良い結果を生成しました。私たちは、いくつかのケースではクロードインスタントがより良い精度を提供し、レイテンシと価格の観点で優れていることが分かりましたが、クエリ生成の場合はクロードV2が適しているとわかりました。

SQLクエリの確認

次のステップは、LLMが正しいクエリ構文を生成し、データベーススキーマと提供された例行との文脈を考慮してクエリが意味を持つかを確認することです。この検証ステップでは、SQLDatabaseChain内のネイティブクエリの検証を使うか、検証命令とともに生成されたクエリをLLMに二度目のトリップで実行することができます。

検証ステップでは、LLMを使用している場合、前と同じLLM（クロードV2）またはより簡単なタスクに適したよりパフォーマンスの高いLLM（クロードインスタントなど）を使用することができます。Amazon Bedrockを使用しているため、これは非常に簡単な調整です。同じAPIを使用して、APIコールでモデル名を変更することで対応できます。ただし、精度が要求されている限り、一般的にはより小さなLLMの方がコストとレイテンシの両方でより効率的な結果を提供できるため、考慮する必要があります。私たちの場合、テストによって生成されたクエリが一貫して正確で正しい構文であることがわかったため、この検証ステップをスキップしてレイテンシとコストを節約することができました。

SQLクエリの実行

確認済みのSQLクエリを使って、データベースに対してSQLクエリを実行し、関連するコンテキストを取得することができます。これは簡単なステップです。

生成されたコンテキストを、初期のユーザーの質問といくつかの指示と共に選んだLLMに提供し、モデルにコンテキストのある要約を生成させます。その後、生成された要約をユーザーに初期の質問の回答として提示し、データセットから抽出されたコンテキストと調和させます。

要約ステップで使用するLLMには、Titan Text ExpressもしくはClaude Instantのいずれかを使用することができます。どちらも要約タスクに適した良い選択肢となります。

アプリケーション統合

Q4のAIサービスの1つであるQ&Aチャットボットの機能は、モジュール性と拡張性を確保するために、APIを介してQ4アプリケーションからアクセス可能なマイクロサービスとして構築されています。このAPIベースのアプローチにより、Q4プラットフォームエコシステムとのシームレスな統合が可能になり、AIサービスの機能をプラットフォームの全てのアプリケーションスイートに公開することが容易になります。

AIサービスの主な目的は、自然言語を入力として使用して、任意の公開データまたはプロプライエタリデータソースからデータを取得するための簡単な機能を提供することです。さらに、AIサービスはデータプライバシーやセキュリティなどの機能的および非機能的要件を満たすために、追加の抽象化レイヤを提供します。次の図は、統合コンセプトを示しています。

Application Integration Image

実装上の課題

前述の構造化された数値データセットの性質によって提示される課題に加えて、Q4は取り組む必要のある他の実装上の課題に直面しました。

LLMの選択とパフォーマンス

タスクに適した正しいLLMの選択は重要です。なぜなら、それが出力品質やパフォーマンス（ラウンドトリップのレイテンシ）に直接影響するからです。以下にLLMの選択プロセスに関わるいくつかの要素を挙げます:

  • LLMのタイプ – FMのアーキテクチャと初期データによって、LLMが得意とするタスクの種類とその実行能力が決まります。例えば、テキストLLMはテキストの生成や要約に優れている一方、テキストから画像への変換や画像からテキストへの変換モデルは、画像解析や生成タスクに向いています。
  • LLMのサイズ – FMのサイズは、特定のモデルが持つモデルパラメータの数で測られます。現代のLLMでは、通常数十億です。一般的には、モデルが大きければ大きいほど、初期トレーニングまたは後続のファインチューニング時のコストも高くなります。一方、同じモデルアーキテクチャの場合、モデルが大きいほど、それに適したタスクの実行能力が高まると一般的に考えられています。
  • LLMのパフォーマンス – 通常、モデルが大きいほど、出力の生成にかかる時間が長くなります。ただし、同じモデルサイズでも、パフォーマンスはプロンプトの最適化やI/Oトークンのサイズ、プロンプトの明瞭さや構文などに大きく影響を受けます。適切に設計されたプロンプトと最適化されたI/Oトークンサイズは、モデルの応答時間を改善することができます。

したがって、タスクを最適化する際には、以下のベストプラクティスを考慮してください：

  • そのタスクに適したモデルを選択する
  • 求めている精度を生成できる最小のモデルサイズを選択する
  • モデルが理解しやすいように、プロンプトの構造を最適化し、指示をできるだけ具体的にする
  • 要求された精度レベルを生成するのに十分な指示と文脈を提供できる最小の入力プロンプトを使用する
  • 出力サイズを必要な意味を持つ最小サイズに制限し、出力要件を満たす

モデルの選択とパフォーマンスの最適化要素を考慮した上で、SQL生成のユースケースの最適化に取り組みました。テストの結果から、適切な文脈と指示が提供されている場合、クロード・インスタントは同じプロンプトデータで、クロードV2と比較してより優れたパフォーマンスと価格で同等のSQL品質を生成することがわかりました。ユーザーの入力がより直接的でシンプルな場合、要求された精度を生成するにはクロードV2が必要でした。

要約タスクにおいても同様の論理を適用すると、クロード・インスタントまたはタイタン・テキスト・エクスプレスを使用すると、クロードV2のような大きなモデルと比較して、求められる精度をより優れたパフォーマンスポイントで生成することができます。先に述べたように、タイタン・テキスト・エクスプレスは価格とパフォーマンスの面で優れたオプションです。

オーケストレーションの課題

ユーザーの質問に対して意味のある出力応答を得るためには、多くの作業が必要であるとわかりました。ソリューション概要に示されているように、このプロセスには複数のデータベーストリップとLLMトリップが絡み合っています。ゼロから作り上げるとなると、基本的なコードを作るために多額の投資が必要になります。私たちはすぐに、オーケストレーションフレームワークとしてLangChainを利用し、オープンソースコミュニティのパワーを活用し、既存のモジュールを再利用することに切り替えました。

SQLの課題

SQL生成は、セマンティック検索や埋め込みのような文脈の抽出メカニズムと比べて単純ではありません。まずデータベースのスキーマといくつかのサンプル行を取得して、LLMへのプロンプトに含める必要があります。また、SQLの検証段階では、データベースとLLMの両方と対話する必要があります。そのため、SQLDatabaseChainが適切なツールの選択でした。LangChainの一部であるため、適応は容易であり、SQLの生成と検証をチェーンで補助することができました。

パフォーマンスの課題

クロードV2を使用し、適切なプロンプト工学（次のセクションで詳しく説明します）を行った結果、高品質なSQLを生成することができました。生成されるSQLの品質を考慮すると、検証段階が実際に付加価値をもたらしているかどうかを見てみることにしました。さらなる分析の結果、生成されるSQLの品質は一貫して正確であり、SQLの検証段階のコストと効益が不利な状況であることが明らかになりました。したがって、私たちはSQLの検証段階を削除し、出力品質に悪影響を与えることなくSQLの検証のラウンドトリップ時間を削減しました。

要約ステップでより費用効果の高いパフォーマンスを最適化するだけでなく、Titan Text Expressを使用することができました。

さらなるパフォーマンスの最適化には、効率的なプロンプトエンジニアリングの技法を使用してクエリ生成プロセスを微調整することが含まれます。余分なトークンを提供するのではなく、モデルが理解できる正しい構文と最小限かつ最適な指示が提供されることに重点を置きました。次のセクションで詳しく説明しますが、それはここだけでなく、他のユースケースにも適用できる重要なトピックです。

プロンプトエンジニアリングと最適化

適切なプロンプトエンジニアリングの技法を用いれば、Amazon Bedrockのクロードを様々なビジネスユースケースに調整することができます。クロードは、会話型アシスタントとして主に機能し、人間/アシスタント形式を活用しています。クロードはアシスタントの役割に向けたテキストの補完を埋めるように訓練されています。求める指示とプロンプトの補完に基づいて、クロードのプロンプトを最適化することができます。

まず、有効な補完を与える適切にフォーマットされたプロンプトテンプレートから始め、実世界のデータを代表するさまざまな入力でプロンプトを実験し、さらなる最適化を行うことができます。プロンプトテンプレートを開発する際には、多くの入力を取得することが推奨されます。また、別々のプロンプト開発データとテストデータを使用することもできます。

クロードの応答を最適化する別の方法は、ルールや指示、有用な最適化を追加しながら、実験や反復を行うことです。これらの最適化によって、幻想を防ぐために「わからない」とクロードに伝えたり、ステップごとに考えること、プロンプトチェインを使用すること、応答を生成する際に「考える」余地を残すこと、理解と正確性をチェックすることなど、さまざまなタイプの補完を表示することができます。

クエリ生成タスクを使用して、プロンプトの最適化に使用したいくつかの技術について説明しましょう。クエリ生成の取り組みにはいくつかの核心的な要素がありました：

  • 適切な人間/アシスタントの構文の使用
  • XMLタグの活用（クロードはXMLタグを尊重し理解します）
  • 幻覚を防ぐための明確なモデルへの指示の追加

以下の一般的な例では、人間/アシスタントの構文、XMLタグの適用、指示の追加を使用して、出力をSQLに制限し、関連するSQLを生成できない場合は「申し訳ありません、お手伝いできません」とモデルに伝えるためにどのように使用したかを示しています。 XMLタグは、指示、追加のヒント、データベースのスキーマ、追加のテーブル説明、およびサンプル行を囲むために使用されました。

"""Human: SQLエキスパートです。指示に基づいてSQLステートメントを生成するように指示されています。<instructions>入力の質問を理解し、データベースのスキーマを参照し、サンプルの行を確認して、質問を表すSQLステートメントを生成してください。</instructions><database_schema>ここにテーブルスキーマを含めることができます</database_schema><table_description>"Comp-Nam"は企業名を表します。"Own-Hist"は所有履歴を表します。</table_description><example_rows>ここに2〜5つのサンプルデータベースの行を挿入できます</example_rows><question>{input}</question><additional_hints>応答では追加のコメントを含まず、SQLのみを提供してください。SQLは適切なデータベーススキーマに従う必要があります。データベースと関係のない質問の場合や、関連するSQLを生成できない場合は「申し訳ありません、お手伝いできません」と言ってください。答えをでっち上げないでください。SQL以外の何ものでも回答しないでください</additional_hints>Assistant: """

最終的な動作するソリューション

概念実証の過程で特定したすべての課題に対処した後、ソリューションの要件をすべて満たしました。SQL生成モデルによって生成されたSQLの品質に対して、Q4は満足しています。データをフィルタリングするためにWHERE句のみを必要とする単純なタスクから、GROUP BYや数学関数を伴うコンテキストベースの集計が必要な複雑なタスクまで、すべての場合において満足です。エンドツーエンドのレイテンシは、ユースケースで定義された受け入れ可能な範囲内に入りました。これは、各段階で最適なSQL生成モデルの選択、適切なプロンプトエンジニアリング、SQLの検証ステップの削除、および要約ステップ（Titan Text ExpressまたはClaude Instant）に効率的なLLMの使用によるものです。

Amazon Bedrockを完全マネージドサービスとして使用し、同じAPIを介して複数のLLMにアクセスできる機能を持つことは、実験とLLM間のシームレスな切り替えを可能にしました。この柔軟性を利用することで、Q4はタスクの性質に基づいて最もパフォーマンスの高いLLMを選択することができました。クエリ生成、検証、要約のいずれかのLLMコールにおいて。

結論

すべての使用ケースに適合する1つのソリューションはありません。RAGアプローチでは、出力の品質は正しいコンテキストを提供することに大きく依存します。正しいコンテキストを抽出することが重要であり、それぞれのデータセットは独自の特性を持っています。

この記事では、数値と構造化データセットの場合、コンテキストを抽出するためにSQLを使用することがより好ましい結果につながることを示しました。また、LangChainのようなフレームワークがコーディングの努力を最小限に抑えることも示しました。さらに、同じユースケース内でLLMを切り替えることができる必要性についても議論しました。最適な精度、パフォーマンス、コストを実現するために。最後に、Amazon Bedrockがサーバーレスであり、複数のLLMを内包していることによって、セキュリティ、パフォーマンス、コストの最適化に必要な柔軟性を提供していることを強調しました。

ビジネスに価値のあるユースケースを特定することにより、生成型AIを活用したアプリケーションの構築への取り組みを始めましょう。Q4チームが学んだように、SQL生成は、データストアと統合されたスマートアプリケーションを構築する際のゲームチェンジャーになる可能性があります。収益の可能性を開放します。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Related articles

Discover more

Want to read more? Go here