※本記事は、AWS re:Invent 2024にて発表された「Structured analysis from unstructured data pipelines (AIM277)」の内容を基に作成されています。このプレゼンテーションは、AWSパートナーであるRedpanda社によってスポンサーされました。本記事では、プレゼンテーションの内容を要約し、技術的な詳細と実装手順を解説しております。

なお、本記事の内容は発表者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、AWS re:Inventのオリジナルの発表内容をご確認いただくことをお勧めいたします。

AWSイベントの詳細情報は https://go.aws/3kss9CP でご覧いただけます。また、より多くのAWSに関する動画コンテンツは http://bit.ly/2O3zS75 でご視聴いただけます。AWS re:Inventの詳細については https://go.aws/reinvent をご参照ください。

Amazon Web Services (AWS)は、オンラインおよび対面でのイベントを通じて、クラウドコンピューティングコミュニティをつなぎ、AWSの専門家との協働や学びの機会を提供しています。本記事で紹介された技術や実装方法については、各自の環境や要件に応じて適切にカスタマイズしていただくことをお勧めいたします。

1. イントロダクション

1.1. 発表者と背景紹介

私はDenis Coadyと申します。Redpandaに所属しており、私たちはKafkaと互換性のあるリアルタイムストリーミングプラットフォームを提供しています。本日は、非構造化データから構造化データを抽出し、分析に活用できるようにするAIパイプラインの構築について、わずか1日で実現可能なソリューションをご紹介します。

私の考えでは、AIが難しいと感じるのであれば、それは間違ったアプローチを取っている可能性が高いです。AIは私たちの業務を効率化し、より良い洞察を得るための強力なツールとなり得ます。今回は、いくつかの製品を組み合わせることで、非構造化データを構造化し、分析に活用可能な形に変換する方法をお示しします。この手法は、アイデアの検証からシステムの実装まで、1日という短期間で実現できる実用的なものです。

特に注目していただきたいのは、AIを効果的に活用することで、従来は膨大な時間と労力を要していた作業を、効率的に処理できるようになるという点です。今回のプレゼンテーションでは、実際の業務課題に対して、どのようにAIを活用して解決したのか、その具体的な実装方法と得られた知見をお伝えしていきます。これは単なる技術的なデモンストレーションではなく、実務で即座に活用できる実践的なアプローチです。

このプレゼンテーションを通じて、AIを活用したデータパイプラインの構築が、考えているほど複雑ではなく、適切なツールと方法論を用いることで、効率的に実現できることをお示ししていきます。

1.2. プロジェクトの動機：カスタマーインサイトの必要性

製品マネージャーとして、私の主要な課題の一つは、顧客のニーズをより深く理解することです。私たちの営業チームはChorus.AIを使用して、すべての顧客とのコミュニケーションを記録しています。これは非常に価値のある情報源となっています。

私自身、多くのミーティングに参加していますが、5,000時間に及ぶすべての会話に直接参加することは物理的に不可能です。しかし、これらの会話の中には、顧客が抱える本質的な問題や痛点が含まれています。特に、顧客と営業担当者が直接対話をする中で、より率直な意見や本音が語られることが多いのです。これらの会話から、製品の機能要望や使用事例、顧客が直面している課題について、貴重なインサイトを得ることができます。

私の目標は、これらの豊富な会話データから、製品開発に活かせる具体的なインサイトを抽出することです。顧客との対話には、製品の改善に直結する情報が豊富に含まれており、これらを効果的に分析し活用することで、より顧客ニーズに合致した製品開発が可能になると考えています。このような背景から、大量の会話データから有用な情報を効率的に抽出し、構造化するためのシステムの必要性を強く感じていました。

1.3. 直面した課題

このデータパイプラインを構築するにあたり、いくつかの重要な課題に直面しました。まず、データ量の規模が非常に大きいことが挙げられます。8,000件の会話データ、合計で5,000時間に及ぶ音声データを扱う必要がありました。この音声データは、圧縮した状態でも数百ギガバイトに達し、効率的な管理が困難な規模となりました。

また、会話の長さも大きな課題でした。LLMを活用する際には、モデルのコンテキストウィンドウのサイズに制限があるため、長時間の会話データを効果的に処理する方法を考える必要がありました。

最も重要な課題の一つは、データのプライバシー保護です。これらの会話データは、顧客が私たちに信頼して提供してくれた非常に機密性の高い情報です。そのため、すべての処理を自社のデータセンター内で完結させる必要があり、インターネット経由で外部にデータを送信することは避けなければなりませんでした。

これらの課題に対して、データを構造化することで、より効果的な分析が可能になると考えました。構造化されたデータは、データベースへの格納や検索が容易になり、さらにベクトル検索などの高度な分析手法も適用できるようになります。これにより、集約的な分析からより深いインサイトを得ることが可能になります。

これらの課題を解決するためには、適切なツールの選択と、効率的なパイプラインの設計が不可欠でした。特に、プライバシーとデータ量の課題に対しては、慎重な技術選定と実装方法の検討が必要でした。

2. 技術スタックと実装

2.1. 使用したツール

このプロジェクトでは、私たちは以下の技術スタックを採用しました。主要なコンポーネントとして、Redpanda Connect、Whisper、そしてAWS Bedrockを使用しています。

Redpanda Connectは、私たちのコネクタとETLパイプラインソフトウェアです。最も重要な特徴は、単一のバイナリと単一のYAMLファイルだけで完全なパイプラインを構築できる点です。特にプロトタイピングの段階では、この簡潔さが非常に有効でした。また、260以上のコネクタが利用可能で、私たちが必要とするほとんどすべての接続に対応できます。例えば、Chorus.AIのHTTP APIインターフェースへの接続も容易に実現できました。

音声文字起こしには、OpenAIのWhisperを選択しました。最も重要な選定理由は、セルフホスティングが可能だという点でした。大量のデータを処理する際、一般的な転写サービスを使用すると非常にコストが高くなってしまいます。プロトタイピング段階で数千ドルものコストがかかってしまうと、上司から承認を得るのが困難になります。そのため、セルフホスティングによって、コストを大幅に抑えることができるWhisperは最適な選択でした。

AWS Bedrockは、モデルの実験やプロトタイピングを容易にするツールとして採用しました。特に、異なるモデルを試したり、設定を調整したりする際の使いやすさが魅力でした。

これらのツールを組み合わせることで、データの取得から処理、分析までの一連のパイプラインを効率的に構築することができました。また、中間処理のデータはRedpandaに保存しています。これは、AIの処理が高コストであるため、データを一度だけ処理し、その結果を保持しておく必要があるためです。Kafkaでも同様のことは可能ですが、Redpandaの方がはるかに簡単に実装できます。特に8時間という限られた時間内でプロトタイプを作成する必要があった私たちのケースでは、この選択は非常に重要でした。

2.2. データパイプラインの構築

データパイプラインの全体像として、私はRedpanda Connectを使用してデータの取得から変換、AWS Bedrockとの連携、そして中間処理までを行いました。このソリューションでは、Redpanda Connectを使用してデータの取得と変換を行い、中間処理のデータをRedpandaに保存する構成を採用しています。

パイプラインの構築では、Redpanda Connectの大きな特徴であるYAMLベースの設定を活用しています。データ接続やAWS Bedrockとのやり取りなど、パイプライン全体をYAMLファイルで定義できます。これにより、インフラストラクチャをコードとして管理でき、非常に速いプロトタイピングが可能になります。実際、バイナリとYAMLファイルを用意するだけで、パイプラインを即座に稼働させることができました。

処理の手順としては、まずChorus.AIのHTTP APIインターフェースを通じて生のWAV音声ファイルデータを取得します。この際、APIコールのレート制限に注意を払う必要があります。AWS Bedrockにも同様のレート制限があるため、これらの制限を考慮しながらデータ処理を行います。

データの流れとしては、取得したデータをRedpandaに保存し、必要な変換や処理を行った後、次のステップに渡します。このように中間データを保存することで、AIによる高コストな処理を一度だけ行えばよくなり、効率的なパイプライン運用が可能になります。

このようなパイプラインの構築により、データの取得から処理、分析までの一連の流れを自動化し、効率的なインサイト抽出を実現しています。

2.3. 音声文字起こしの実装詳細

音声文字起こしの実装にあたって、私はWhisperを選択し、自己ホスティングで運用することにしました。実は、Whisperサーバー自体の実装もOpenAIに作成させました。私の考えでは、AIを使ってAIを作るのが効率的だからです。AIにコードを書かせることで、私自身がコーディングする必要がなくなりました。

実行環境としては、AWS g4dn.xlargeインスタンスを使用しました。これにより、全データの処理コストを78ドルに抑えることができました。これは、商用の文字起こしサービスを利用した場合の$7,200や$1,800と比較すると、大幅なコスト削減を実現できています。

ただし、このアプローチにも重要な注意点があります。データ処理に5日間かかり、時々処理を再開する必要がありました。そのため、少量のデータを扱う場合や本番環境での運用時には、このような自己ホスティング方式は推奨できません。代わりにサーバーレスオプションを選択すべきです。

データ処理において、私は可能な限りオープンな形式を使用することを心がけました。例えば、OpenAIのデフォルト出力は単なるテキストブロブですが、引数を追加することで異なる形式での出力が可能です。私はWebVTT形式を選択しました。この形式は字幕用のフォーマットで、パースが簡単で可読性も高く、デバッグ作業が容易になります。

このように、開発段階では低コストで実験できる方法を選択し、本番環境では運用の安定性を重視するアプローチを取ることで、効率的な開発とスケーラブルな運用の両立を図りました。

3. LLMを活用したデータ構造化

3.1. JSONフォーマット変換の手法

音声から文字に起こしたテキストデータを、データベースで利用可能な形式に変換する必要がありました。最新のLLMは、適切なプロンプトを与えることで、JSONフォーマットでの出力を非常に正確に生成できます。

私がこのコードを書いていないことは明らかです。なぜなら、タイプミスがなく、文法的にも完璧だからです。実際には、私はLLMに対して、望む出力フォーマットを指定し、入力がどのような形式で来るか、そして具体的なプロンプトの作成を依頼しました。これは私が呼んでいる「メタプロンプト」アプローチです。

データの構造化において私が重視したのは、後の分析で活用しやすい形式にすることです。テキストはまだテキストの状態であり、これをデータベースで使用可能な形式に変換する必要がありました。LLMに適切な指示を与えることで、このような構造化を効率的に行うことができます。

例えば、特定の機能リクエストや、顧客が抱える課題、あるいは製品の使用事例など、私たちが分析したい特定の要素を抽出し、それらをJSONフォーマットで構造化データとして出力するようにLLMを設定しました。これにより、後の分析段階で、ベクトル検索やその他の分析手法を容易に適用することが可能になりました。

このアプローチの特徴は、人間が手作業で行うよりも一貫性のある構造化が可能な点です。タイプミスや形式の揺れが少なく、常に一定の品質でデータを構造化できます。これは、大規模なデータセットを扱う際に特に重要な利点となります。

3.2. プロンプトエンジニアリング手法

プロンプトエンジニアリングにおいて、私は「メタプロンプト」というアプローチを採用しました。これは、LLMに対して「これが望む出力フォーマットで、入力はこのような形式で来る。良いプロンプトを書いてください」と依頼する方法です。このメタプロンプトの活用は、多くの人がまだ試していない効果的な手法です。

LLMを扱う際の重要な考え方として、私はLLMをジュニア社員のように扱うことを推奨しています。彼らは何をすべきか完全には理解していないため、多くのサポートと手本が必要です。ここで重要になってくるのが、「One-shot」「Two-shot」「Few-shot」エンコーディングです。これは単に、LLMに与える事前の例示の数を指しています。

具体的には、「これが望む出力の形式で、このような内容を期待している。新しいデータが来たら、このパターンに従って処理してください」という形で例を示します。このアプローチは非常に効果的で、まるでジュニア社員を訓練するかのように、LLMに期待する出力のパターンを学習させることができます。

プロンプトの設計において、私はコーディングを一切行っていません。その代わりに、AIにAIを作らせるというアプローチを取りました。例えば、プロンプトの生成自体もLLMに任せることで、より効率的かつ正確な結果を得ることができました。LLMに具体的な例を示し、期待する出力形式を明確に伝えることで、一貫性のある高品質な結果を得ることができます。

このプロンプトエンジニアリング手法は、テンプレート化が可能で、様々な職種や目的に合わせて再利用できます。私はプロダクトマネージャーの視点でプロンプトを設計しましたが、同じアプローチを使って、営業、マーケティング、エンジニアリングなど、異なる役割に応じたプロンプトを作成することができます。ポイントは、目的を明確にし、適切な例示を提供することで、LLMが期待通りの出力を生成できるよう導くことです。

3.3. 異なる役割に応じたデータ活用方法

私は製品マネージャーとして、自分の視点からのインサイト抽出に焦点を当てていましたが、このアプローチは他の部門にも同様に適用できます。それぞれの役割に応じて、異なる洞察を得ることが可能です。

製品マネージャーとしての私の場合、製品のセキュリティに関する具体的な機能要望や、顧客が直面している課題について、より深い理解を得ることができました。私は主にAIと製品セキュリティを担当しているため、これらの分野に関連するインサイトを抽出することに注力しました。正直に言うと、これは私自身の業務をより効率的にするためでもあります。上司には内緒ですが。

セールス部門では、特定の属性を持つ取引に関する分析が可能です。営業担当者は、顧客との会話から特定のパターンや傾向を見出すことができ、これを今後の営業活動に活用できます。

マーケティング部門は、顧客との会話全体を通じて見られるトレンドやパターンを分析することができます。何が顧客にとって重要なのか、どのような点に注目しているのかを把握することで、より効果的なマーケティング戦略を立てることができます。

エンジニアリング部門にとっては、顧客が実際に製品をどのように使用しているのか、どのような機能が活用されているのか、そして顧客が製品を使って何を実現しようとしているのかを理解する機会となります。

この手法の素晴らしい点は、同じテンプレートを使用しながら、各部門の目的に合わせてカスタマイズできることです。それぞれの部門が関心を持つ特定の洞察を抽出し、Gen AIを活用して業務をより効率的にすることができます。結局のところ、AIが仕事を楽にしてくれないのであれば、それは正しい使い方をしていない証拠なのです。

4. AWS Bedrockの実践的知見

4.1. 実装上の注意点

AWS Bedrockを使用する際に、私は実装上のいくつかの重要な注意点に直面しました。これらの点は、ドキュメントを読むだけでは必ずしも明確ではなく、実際の実装を通じて学んだものです。

まず、使用したいモデルが選択したリージョンで利用可能かどうかを確認することが重要です。すべてのリージョンで全てのモデルが利用できるわけではありません。これは一見当たり前のように思えますが、エラーメッセージが必ずしも明確ではないため、問題の特定に時間がかかる可能性があります。Webページやドキュメントには各リージョンでの利用可能なモデルが記載されていますが、実装時にこの点を見落としがちです。

次に、コンテキストサイズの制限に関する課題があります。どのLLMも大きなコンテキストサイズでは良好なパフォーマンスを発揮できません。コンテキストサイズが小さいほど、より良い結果が得られます。私の場合、長い会話トランスクリプトから特定のインサイトを抽出する必要があったため、「痛点」「機能リクエスト」「具体的なインサイト」といった特定の情報に焦点を当てるようにプロンプトを設計しました。128Kや100万トークンのコンテキストウィンドウを持つモデルでも、パフォーマンスと記憶力は急速に低下するため、できるだけ短く具体的な入力に絞ることが重要です。

最後に、レート制限への対応は特に注意が必要です。AWSはこの制限を非常に真剣に扱っています。ドキュメントやコードを見ただけでは、この制限の重要性に気付きにくいかもしれません。「これは速いし、好きなだけクエリを送れる。従量課金なのだから、AWSはもっと多くの収益を得られるはずだ」と考えがちです。しかし、実際にはコードが突然429レート制限エラーで失敗し始め、最終的にはAWSからの警告メールを受け取ることになります。私の経験から、一度に1つのコールを行い、並行処理は避けることをお勧めします。処理は十分に高速なので、並行処理は必要ありません。

4.2. Bedrock Studioの活用

AWS Bedrock Studioは、プログラムによる実装の前にプロンプトやモデルの検証を行うための素晴らしいツールです。私は、このツールがOpenAIやChatGPTのインターフェースと同様の機能を提供しながら、カスタムモデルや実際の実装で使用する設定でテストができる点を高く評価しています。

プロンプトのテストと会話形式での検証は、Bedrock Studioの重要な機能の一つです。プログラムで実装する場合、プロンプトの検証や調整が少し煩雑になる可能性がありますが、Bedrock Studioを使用することで、実際の設定やコンフィグレーションを使用しながら、プロンプトの動作を簡単に確認することができます。

私のアプローチとしては、まずBedrock Studioでプロンプトのチューニングと設定の調整を行い、期待通りの動作を確認してから、コードへの実装を行うようにしています。これにより、プロンプトの設計や調整にかかる時間を大幅に削減することができます。

また、モデルの設定とチューニングも、Bedrock Studioを使用することで効率的に行うことができます。実装前の検証プロセスとして、異なるモデルや設定を試すことができ、最適な組み合わせを見つけることができます。これは、実際のコードを書く前に、アプローチの有効性を確認する上で非常に重要です。このような事前検証により、実装段階でのトラブルを最小限に抑えることができます。

5. 分析と実用化

5.1. RAGパイプラインの構築

データを処理し、構造化されたJSONを得た後、私は従来のRAG（Retrieval-Augmented Generation）プロセスを活用することにしました。Amazonはこのプロセスを非常に簡単に実装できるようにしてくれています。実際、私はRAGパイプラインの構築に5分しかかかりませんでした。

具体的な実装手順は非常にシンプルです。まず、構造化されたJSONオブジェクトをS3バケットにアップロードします。次に、Bedrock Studioで、このS3バケットを指すようにKnowledge Baseを設定します。これだけで、RAGパイプラインの構築は完了です。

このアプローチの素晴らしい点は、5,000時間分の音声データに対して質問ができる独自のRAGパイプラインが、わずか数分で構築できることです。このように、AWSは複雑な機能を非常に使いやすい形で提供しており、私たちはこれを活用することで、短時間で効果的なソリューションを構築することができました。

このシンプルさと迅速な実装可能性は、特にプロトタイピング段階において非常に重要です。私たちの場合、8時間という限られた時間内でアイデアを検証する必要があったため、この効率的な実装方法は非常に有用でした。

5.2. 質問応答システムの実装

Knowledge Baseを設定した後、私は独自のRAGパイプラインとUIを持つシステムを構築し、5,000時間分の音声データに対して質問できるようになりました。このシステムを使用することで、様々な観点からデータを分析することが可能になりました。

例えば、私の主な関心事である製品セキュリティに関して、「製品セキュリティに関して顧客が要求している具体的な機能は何か」といった質問をすることができます。システムは集計された情報を提供し、さらに重要な点として、その情報をどこから得たのかという引用情報も提供します。この引用機能は、情報の信頼性を確保し、ハルシネーション（AIによる誤った情報の生成）を防ぐ上で非常に重要です。

システムの特徴的な点として、定性的な回答だけでなく、定量的な回答も生成できることが挙げられます。これは私にとって予想外の発見でした。また、このシステムの利点として、普段は直接聞きづらい質問や、知っているべきだと感じて躊躇してしまうような質問も、気兼ねなく行えることが挙げられます。AIは（少なくとも現時点では）判断を下すことはないので、プライベートかつ自信を持って質問することができます。

このように構築したシステムは、APIとして共有することも可能です。これにより、私のチームの他のメンバーも、彼らが担当する製品領域について同様の分析を行うことができます。これは、チーム全体でのインサイト抽出を可能にする強力なツールとなっています。

5.3. コスト分析

このような分析システムを構築した場合、コストは非常に管理しやすいレベルに収まっています。一度RAGの段階まで到達すると、大規模なモデルを使用しても、クエリあたり数セントという非常に手頃なコストで運用することができます。

コストをさらに最適化したい場合は、モデルのチューニングを行うことで、より低コストでの運用も可能です。しかし、私の経験では、現在のクエリあたり数セントというコストは、得られる価値に比べると十分に合理的な水準だと考えています。

特に重要な点として、このシステムはAPIとして共有可能であり、チーム全体で活用できる形にすることができます。つまり、一度構築したシステムを他のプロダクトマネージャーや他のチームメンバーも利用できるため、コストパフォーマンスは更に向上します。他のチームメンバーも、それぞれが関心を持つ領域について同様の質問を投げかけ、インサイトを得ることができます。

スケーリング時のコストについては、処理の大部分が一度きりの変換作業であり、その後のクエリは効率的に処理できる設計となっています。これにより、システムの規模が拡大しても、コストが予期せず増大するリスクを抑えることができています。

6. 教訓と発見事項

6.1. AIシステム構築の原則

このプロジェクトを通じて、私は重要なAIシステム構築の原則をいくつか学びました。最も重要な原則は、AIをジュニア社員として扱うというアプローチです。AIは、新入社員と同様に、非常に強力なタスクを実行できる能力を持っていますが、明確な指示が必要です。上司として、AIに対して具体的な指示を与え、その作業を監督する必要があります。このように適切な指示と監督があれば、AIは素晴らしい成果を上げることができます。

次に重要なのは、90%の精度で十分だという考え方です。AIに100%の完璧さを求めるのは現実的ではありません。それは人間でも同じことです。AIは時々間違いを犯しますが、それは許容できることです。私たちの目標は完璧を目指すことではなく、人間と同程度の精度を達成することです。AIの役割は私たちを支援することであり、その観点から見れば90%の精度は十分に価値があります。

AIに対する明確な指示の重要性も強調しておきたいと思います。AIは、新入社員と同様に、何をすべきか完全には理解していない状態です。そのため、多くのサポートと明確な例示が必要です。期待する出力のパターンを具体的に示し、どのような結果を求めているのかを明確に伝えることが重要です。

結果の検証プロセスも不可欠です。ハルシネーション（AIによる誤った情報の生成）は完全にゼロにはなりません。常にある程度のあいまいさが存在します。そのため、新入社員の仕事を確認するように、AIの出力も監督し、結果が適切であることを確認する必要があります。特に、モデルがどのように決定を下したのかを説明できない場合、それは大きな問題となる可能性があります。上司から「どのようにしてその結論に至ったのか？」と聞かれた時に、「分かりません」という答えは通常受け入れられないのと同様です。

6.2. 実装における重要ポイント

プロジェクト全体を通じて、私は重要な実装のポイントをいくつか見出しました。まず、プライバシー保護に関してです。私たちが扱うデータは、顧客が信頼して提供してくれた非常に機密性の高い情報です。そのため、すべての処理をデータセンター内で完結させることは絶対的な要件でした。この要件を満たすことで、官僚的な手続きやアクセス権限の問題を回避し、かつ安全なシステムを構築することができました。

コスト管理に関しては、常に実用的なアプローチを心がけました。プロジェクトを安価に保ち、安全に保ち、そしてシンプルに保つことで、多くの官僚的な手続きや許可の問題を回避することができました。例えば、Whisperの自己ホスティングを選択したことで、プロトタイピング段階での大幅なコスト削減を実現できました。

データの系統と説明可能性の確保も非常に重要です。企業がより多くのAIモデルを導入するにつれて、「この結果はどのように導き出されたのか？」「この決定はどのように下されたのか？」という質問が増えてきます。モデルがどのように決定を下したのか説明できない場合、それは大きな問題となります。上司に「わかりません」と答えることは通常許されないのと同様です。

最後に、ジェネレーティブAIへの取り組みに遅すぎることはありません。多くの人々はジェネレーティブAIをどのように始めるべきか模索しており、投資家からAI企業になれと言われて苦心している人もいます。しかし、私の経験から言えることは、早く始めて、素早く失敗し、そして前進することが重要だということです。このプロジェクトでも、8時間という短時間でプロトタイプを作成し、アイデアを検証することができました。80ドル程度のコストで、アイデアを試すことができたのです。

つまり、コストを抑え、データのプライバシーを確保し、説明可能性を担保しながら、失敗を恐れずに試行錯誤を重ねることが、AIプロジェクトの成功には不可欠だと言えます。