フォーム読み込み中
2023年12月19日掲載
12月9日に、Insight Technology様主催による db tech showcase2023 が開催されました。まずはご参加・ご視聴頂いた皆さま、および登壇者や関係者、運営に携わっていただいた皆さま、そして今回のお誘いを頂きましたAlibaba Cloud Japan様、ありがとうございました。そしてイベントレポートというか今回のプレゼン内容を振り返って、テックブログにて残す形で情報発信します。
ソフトバンクといえば通信会社というイメージが多いかもしれませんが、ソフトバンクは様々なIT領域に範囲を広げております。その一環として、パブリッククラウドの取り組みがございます。ソフトバンクは、クラウドサービスの開発・販売、ソリューションの開発・販売、クラウドマネージドサービス、クラウドデリバリーサービス、クラウドテクニカルサポートサービスの5本を軸としながらクラウドサービス事業をしています。
私はクラウドサービスおよびソリューションの開発・販売、テクニカルサポートを担当しており、その中で生成AI、LLMなどに触れる中で認識した課題および解決策を本日のテーマとしてお話させていただきます。
現在、私はパブリッククラウドのテクニカルサポートチームとして、お客様の技術的な問い合わせを100%解決させています。
その過程で、生成AIが登場するより前にパブリッククラウドの情報検索サービスを立ち上げていますが、情報は武器だということを常に実感します。パブリッククラウドの情報量を数値化で示せば、例えば1つのパブリッククラウドの収録語数は約16,850,000、 広辞苑に近い情報量があります。この情報量からテクニカルサポート業務として目的の情報を的確かつ効率よく素早くキャッチアップするのはとても大変なことです。
こういった経験則に基づいた話として、生成AIを用いた独自サービスは、情報を「武器」として活用する新しい手法です。辞書並みの大量のデータから目的の情報を文章として効率よく得るためには、LLMによる独自サービスが必須です。
では、LLMによる独自サービスはどう構築したらよいでしょうか?その礎となるのが、RAGアーキテクチャ、取得拡張生成となりますので、これについてお話しします。このRAGアーキテクチャは、データソースから最適な情報を抽出し、それをもとに機械学習モデルが新たなテキストを創出するプロセスです。初めに、複数のフォーマットのデータソースからテキスト情報を集め、このテキスト情報を高次元のベクトル空間に埋め込みます。次に、埋め込まれたデータからVector Queryを通じて、必要な情報を効率的に検索します。この検索により、関連性の高いテキスト情報を特定し、それらを利用して、LLM が最終的な回答文章を生成します。現在のLLMによるサービス構成は、主にRAGアプローチを中心とする構成となっています。
また、db tech showcaseでお話ししなかったのですが、全文検索とベクトル検索の組み合わせによるRe-rankingアプローチ、質問文を先にLLMが仮の答案を出力してから、全文検索とベクトル検索の組み合わせで回答を出力するHyDE(Hypothetical Document Embeddings)アプローチもあります。先述のパブリッククラウドの情報検索サービスは精度に特化およびURLを含めた質問文から調査をすることが多いため、HyDE(Hypothetical Document Embeddings)アプローチとなります。
LLMによる独自サービスの全体的な流れは先述通りとなりますが、LLMによる独自サービスを開発するにあたり、いくつか課題があります。
一つ目は、LLMサービス開発工数と学習コスト&運用コスト問題
二つ目は、精度向上のためにベクトル検索だけでなく、全文検索をしたい
三つ目は、検索結果が本当に求めていることとは異なる回答を出してしまう。これは、テキスト内の単語の重要度を数値化しながら、意味あるデータへ変換する必要があります。
著者はそれを解決するために様々なベクトル型データベースを確認しました。その結果、辿り着いたのが、Alibaba Cloud の AnalyticDB for PostgreSQLです。
Alibaba CloudのAnalyticDB for PostgreSQLは、Greenplum DatabaseをAlibabaによって最適化した高性能の分析データベースサービスです。PostgreSQLと完全に互換性があり、列指向+行指向+ベクトルデータベースで分析やトランザクション処理を行うことができます。これはテキストや画像データを組み合わせたマルチモーダル検索として活躍することもできます。AnalyticDB for PostgreSQL はフルマネージドサービスでありながら、elastic版とサーバレス版があり、サーバレス版は使った分だけ課金をする仕組みがあり、コストに優しいです。更に、AnalyticDB は名前からしてその通りにSQLクエリだけでデータ前処理やTF-IDFによる検索、SQLだけで機械学習機能を提供しています。
先ほどのLLMによる独自サービス開発で共通する課題を説明しました。LLMによる独自サービス開発は、ビジネス現場で必要だった情報を継続的 に得るまで、Try & Errorを繰り返しながら分析・実装が必要と認識しており、この目線でいくつか課題に対する解決策として、なぜ他のベクトルデータベースでなくAnalyticDBなのか?これについて1つ1つずつ説明します。
まずはLLMによる独自サービスの迅速な開発と、意図しない検索結果の課題があると思います。
この課題に対し、AnalyticDBであれば、Object StorageからのELTを通じて迅速なデータロード、SQLを用いたTF-IDFによるキーワード検索を提供します。LangChainやApache MADlibなどの拡張機能を活用し、テーブルら構造化データとベクトルら非構造化データを組み合わせることで、精度の高いハイブリッド検索を実現します。
Object Storage Serviceからの ELT による迅速なデータロードについて説明します。下記の資料は、往来のETLアプローチと、ELTアプローチを比較しています。往来は「Extract (抽出)」「Transform (変換)」「Load (書き出し)」、データを変換しながらデータベースにデータを格納しますが、「Transform (変換)」を後回しにしたELTではデータを先に格納し、後でデータベース内でSQLクエリを使って変換します。AnalyticDBはELT「Extract (抽出)」「Load (書き出し)」「Transform (変換)」をサポートしているので、継続かつ効率的なデータ処理ができます。
ではどうやって、OSS(Object Storage Service)にファイルが置かれたら、AnalyticDBへ反映するのでしょうか?方法は色々ありますが、今回はFunctionComputeを使います。AnalyticDBは、FunctionComputeを使いObjectStorageからAnalyticDBへ直接データをインポートできます。ユーザーがファイルをアップロードすると、自動的にAnalyticDBへ格納されます。FunctionComputeを通じてデータの前処理やベクトル化データの格納も可能です。
LangChainは生成AIサービス構築のためのOSSで、AnalyticDBに対応しています。
LangChainを使わない場合としても、OpenAIのCookbookにある手順で、AnalyticDBとOpenAI APIキーを設定することで、LLMを使用した独自サービスがすぐ始められます。
ここでは紹介していない他のLLMによる生成AIサービス構築のためのOSS、SDK、拡張機能があっても、AnalyticDB for PostgreSQLは PostgreSQLと100%互換性を持つため、PostgreSQL対応のOSS、SDK、拡張機能で柔軟に対応することもできます。
AnalyticDBはSQLを使用してベクトル検索やキーワード検索、機械学習を行うことができるデータベースです。加えて、データをDBから一切外に出さずに、SQLクエリだけでTF-IDFによる全文検索、k-meansによるクラスタリングが可能で、In-Database Analyticsアプローチによりデータベース内で目的の処理が完結します。これにより、AnalyticDBからデータ前処理や分析、加工処理のためにデータを他へ移動する必要はなくなるので、その分サードパーティのコストや移動・処理時間を節約できます。
先ほどの説明をまとめたデモ動画をご閲覧ください。
二つめ、ITリテラシーが低いユーザーでも、サービス運用における学習・利用コストを抑制したい。これはお客さまでもよくある質問です。この課題に対し、AnalyticDBは初期費用なしで始められるサーバレスかつフルマネージドサービスで、料金はデータの保存と実行クエリに基づき、低コストで済みます。更に、LLMと併用することで、非エンジニアでもLLMに質問文を入れるだけで、プロンプトtoSQLによるアプローチが実現しやすいです。ちなみに著者はApache MADlibによるSQLで機械学習アプローチにあまり詳しくないので、ChatGPTなどと相談しながら1つ1つずつ攻略していました。なので、LLMの力を借りたら、機械学習やSQLの知識がゼロでも、誰でもすんなりSQLや機械学習による分析ができるというのは非常に大きいと思います。
AnalyticDBにはElasticモードとサーバレスモードの2つの運用モードがあります。
大量のSQLクエリが必要なシステムではElasticモードが適していますが、スモールスタートおよび小規模としてサーバレスモードを低コストで試すことができます。
サーバレスモードでは、AnalyticDBを気軽に試して、必要なければいつでも使用を停止できます。
プロンプト to SQLによる分析アプローチについて説明します。AnalyticDBはPostgreSQLと完全互換であり、ユーザーの質問文からLLMがSQLクエリを自動生成し実行します。クエリが成功すれば結果が表示され、失敗すればLLMが再度クエリを生成します。このアプローチにより、非エンジニアも簡単にデータ分析ができます。
これは元々、オープンソースの textSQL のアイデアを参考にしています。
百聞は一見に如かず、Demoをご閲覧ください。
これはソフトバンクのAzure OpenAI スターターパッケージ のインターフェースに加え、オープンソースの textSQL のアイデアを参考にしながら、AnalyticDB for PostgreSQL用に改修したものです。ユーザーは事前にファイルをObject Storage Serviceへアップロードするだけで、非エンジニアでも様々な分析、可視化ができます
LLM + AnalyticDB for PostgreSQLの組み合わせとして、ここまでの話をまとめます。
LangChainのサポートとOpenAI Cookbookのサンプルコードにより、誰でも簡単に利用開始できます。TF-IDF、ベクトル検索、ハイブリッド検索をサポートしており、精度の向上が簡単です。スモールスタートが可能で初期コストゼロ、そしてPostgreSQLと完全互換性があるため、非エンジニアでもLLMを使用して多彩なSQL分析が行えます。
イメージしてみてください。SQLやコード開発が苦手でも、指示するだけでデータ分析や可視化をはじめ、DXやビジネスに力を与えるアプローチは素晴らしいと思いませんか。
ソフトバンクはAlibaba Cloudの素晴らしさを享受しながら、こういったサービスやソリューションを開発、展開していますので、興味がある方は是非ソフトバンクまで。
これで、AnalyticDB for PostgreSQLの紹介についてのプレゼンは以上となります。ご清聴ありがとうございました。
これはプレゼンの時間などの都合でカットしていますが、せっかくなので未発表情報も載せます。実はAnalyticDB for PostgreSQLはマルチモーダル検索・分析が出来ます。そのため、画像・動画(厳密には画像を約1フレームごとに識別)の媒体を識別しながら分析することもできます。先述通り、AnalyticDB for PostgreSQLは ベクトルデータを保持しながら、大規模なベクトル検索を柔軟に構築することができるので、テキストだけでなく画像(動画)もベクトル化することで、テキスト to 画像(動画)変換のためのモデルを使えば、ベクトルデータを使った様々な検索が行えます。そのモデルはOpenAI による「CLIP」モデル、もしくはOpenAIの「CLIP」モデルのオープンソース版モデル ViT-L/14 、を使用します。画像データをResnet50やViTなどのTransformerで変換し、テキストデータをGPT-3のようなTransformerで変換し、それぞれのベクトルが比較可能になれば、画像とテキストのベクトルが近似しているかどうかで関連性を抽出するというアプローチです。このアプローチであれば、AnalyticDB上で テキスト to 画像(動画)、画像(動画)to テキスト、画像(動画)to 画像(動画) といった様々な検索が実現できます。
こちらも都合で没となっていますが、デモ動画をご閲覧ください。
このアプローチは SuperDuperDB や EvaDB、Google Cloud の Gemini に似ていますが、AnalyticDB for PostgreSQLはLLMが登場するよりずっと前から、全文検索・ベクトル検索に加え、マルチモーダル検索が出来ることや、SQLだけでTF-IDF全文検索に機械学習、加えてスモールスタートしやすい課金の仕組みなので、ML/AI系データベースとしても非常に強いデータベースだと実感しました。コスパも良いし、自由度が高いので、気になる方は試してみるといいと思います。
AWS
Google Cloud
Azure
Alibaba Cloud
条件に該当するページがございません