AI時代のベクターデータベース、リレーショナルデータベース、サーバーレス技術丨TiDBハッカソン2023 雑考

TiDB ハッカソン 2023 が終了したばかりですが、すべてのプロジェクトを注意深くレビューしました。プロジェクトが人工知能 (AI) 関連テクノロジーを使用する必要があることを強調するわけではありませんが、目を引くプロジェクトはほぼ一様に AI を使用してアプリケーションを構築しています。大規模言語モデル (LLM) の出現により、個々の開発者がわずか 5 分でプログラムに推論機能を追加できるようになりました。これは、これまでは非常に大規模なチームでしか実現できませんでした。アプリケーション開発者の視点から見ると、AI時代も到来しています。

これらの AI アプリケーションでは、ベクトル データベースが遍在しています。これらのプロジェクトのほとんどは依然としてリレーショナル データベースを使用していますが、もはや明らかな役割を果たしていないように見えます。リレーショナル データベースは依然としてアプリケーション開発者の注目に値するのでしょうか?

この質問に明確に答えるには、ベクトル データベースが従来のリレーショナル データベースとどのように異なるかを理解する必要があります。

ベクトルデータベースとは何ですか?

これを理解するために、私はベクトル データベースの研究に時間を費やしました。次に、ベクトルデータベースとは何かを最も簡単な言語で説明します。

この世界のほとんどのものには複数の特徴があり、たとえば、身長、体重、性格、性別、服装、趣味など、さまざまな種類の要素を使用して人を説明できます。通常、その気になれば、この次元や特徴を無限に拡張してオブジェクトを記述することができます。次元や特徴が増えるほど、オブジェクトやイベントの記述がより正確になります。

ここで、絵文字表現を 1 つの次元で表現すると、0 は幸福を表し、1 は悲しみを表します。以下の X 軸に示すように、0 から 1 までの数値サイズは、対応する式の悲しみと喜びを表現できます。

しかし、感情的な絵文字を説明する要素が 1 つしかない場合、それは一般的で不正確であることがわかります。たとえば、幸せを表現できる絵文字にはさまざまな種類があります。したがって、現時点では通常、それをより適切に説明するために新しい次元を追加します。たとえば、ここでは Y 軸を追加します。0 は黄色を表し、1 は白を表します。加算後、座標軸上の各式を表す点は(x, y)の組になります。

賢明な方であれば、Y 軸の新しい説明次元を追加したとしても、依然として区別できない絵文字があることに気づいたはずです。例えば

じゃあ何をすればいいの?解決策はまだ単純で、別の次元を追加するだけです。座標系には z 軸が追加されます。新しい次元を帽子をかぶっているかどうかに設定するだけです (ここでの各次元の値は説明のためにできるだけ単純なものであり、現実世界もそれほど単純であるという意味ではないことに注意してください)。着用していないことを表すには 0、着用していることを表すには 1 を使用します。これで、絵文字を記述するための (x, y, z) の 3 次元座標点が得られました。

もちろん、現実の世界では、物はそれほど少ないプロパティを持っているわけではないので、それを記述するために多くの次元を追加する必要があるため、高次元配列 (0.123、0.295、0.358、0.222...) のような記述が表示されます。この時点では、ベクトル データベースの「ベクトル」に非常に近づいていますが、実際、ベクトル データベースには、画像、ビデオ、テキストなどのさまざまなデータを表す配列が格納されています。これらは上記の変換方法により高次元配列に変換されて保存されます。

おそらくこの時点では、ベクトル データベースの役割をまだ理解していません。なぜこの形式に変更するのでしょうか?

簡単に言うと、これをベクトルに変換すると、世界の任意の 2 つのものの間の相関関係と類似性を定量化する方法が得られるからです。先ほどのデモンストレーションを通して、物体が各次元に近づくほど、宇宙でもより近くなります。2 点間の距離を計算することで、それらの点間の類似性を判断できます。

したがって、これまでに出現したことのない絵文字がある場合は、上記の方法を使用して、この絵文字をベクトル (0.01、1、0) に変換できます。

ライブラリにすでに保存されているベクトルを計算することで、最も近い絵文字を見つけることができます。

次に近いのは、

証拠として、PineCone クエリ データ ( https://docs.pinecone.io/docs/query-data#sending-a-query  ) でデータを取得する例を確認できます (スコアは単純に類似度と考えることができます)。

index.query(
  vector=[0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3],
  top_k=3,
  include_values=True
)
​
# Returns:
# {'matches': [{'id': 'C',
#               'score': -1.76717265e-07,
#               'values': [0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3]},
#                   {'id': 'B',
#                    'score': 0.080000028,
#                    'values': [0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2]},
#                   {'id': 'D',
#                    'score': 0.0800001323,
#                    'values': [0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4]}],
#               'namespace': ''}

Values は取得されたベクトル (この例では対応する絵文字と考えることができます) です。これは、すべてのクエリ基準をベクトル化して、必要なものに最も近いものを見つけることができることを意味します。絵文字をテキストに置き換えると、「セマンティック」検索を実装できます。絵文字を写真またはビデオに置き換えると、写真またはビデオの類似性の推奨を実装できます。

AI アプリケーションがベクトル データベースに依存することが多いのはなぜですか?

一言で説明すると、「大きなモデル」は限られたことしか覚えられません。

これは私たちの脳と非常によく似ています。コミュニケーションの過程において、私たちは会話の中で自分の知識をすべて相手に伝えることは不可能であり、限られた文脈からしか特定の「推論」をすることしかできません。したがって、現在の AI アプリケーションでは、LLM によって推論機能が提供され、表現する必要がある最も関連性の高いコンテキストが脳から見つけられます。したがって、類推すると、ベクトル データベースは LLM のメモリまたは知識ベースに似ています。したがって、ベクトル データベースの助けを借りずに AI 関連の機能を完成させるには、通常、大規模な AI モデルが完成できる機能と精度は非常に限られています。

この考え方に沿って見ると、実際には、精度の低いファジー マッチングに加えて、非常に正確で決定的な検索/インデックス作成を必要とする検索/インデックスが数多く存在します。これは、私たちが通常、重要な情報をノートに記録し、必要に応じてインデックスから正確に取得する方法と似ています。

したがって、ベクトル データベースとリレーショナル データベースの最大の違いは、データの保存方法とインデックスのクエリ方法です。リレーショナル データベースには正確なインデックスが存在するため、ミリ秒レベルで対応する情報を取得できます。アカウント、商品、注文情報など高速アクセスが必要な業務システムへの対応は、やはりそれだけで完結する必要があります。

ハッカソン賞を受賞したアプリケーション Heuristic AI (  https://devpost.com/software/cx-8lh7ps  ) を例として、これら 2 種類のデータベースを実際のプロジェクトで使用する方法を説明します。

私たちの日常生活では、使用している電子製品が故障した場合、通常、関連する解決策を得るために複雑なユーザーマニュアルを読む必要があり、習得するのに多くの時間がかかります。このプロジェクトでは次のことが達成されました。

  1. すべての製品マニュアルを Vector データベースにインポートします
  2. 自然言語を使用して遭遇した問題を説明し、セマンティック検索を通じてベクトル データベース内で最も関連性の高いコンテキストを見つけます。
  3. コンテキストを Prompt にパックし、OpenAI に送信して、対応するソリューションを生成します。

大まかな技術的な実装は次のとおりです。

このソフトがここで終わってしまったら、基本的にはおもちゃになってしまいます。通常、システムにユーザー認証や管理システムを追加する必要があり、さらに、オンライン ユーザーの数や製品の使用頻度などのビジネス データをバックグラウンドで分析するシステムも追加する必要があります。が使用され、その他の次元が使用されます。これらの機能は、従来のデータベースを使用して実装する必要があります。

もちろん、ハッカソンのプロジェクトとしては、このソフトウェアは実際には比較的完成度が高いです。ただし、さらに商業化する場合は、次の点を考慮する必要があります。

○ユーザーデータ量が飛躍的に増加し、システムの拡張性と安定性が向上

○ 複数のデータセンターや災害時におけるデータのバックアップとリカバリ

これらはどれもクールではなく、苦痛ですらありますが、それでも慎重かつ真剣に取り組む必要がある分野です。幸いなことに、このハッカソンでは、もう 1 つのトレンドを肉眼で観察できます。それは、開発者がアプリケーションの製品化における技術的な困難を軽減し続けるのに役立つサーバーレスです。

サーバーレス基本ソフトによる効率化

観察できること: 独立した開発者がプロ​​ジェクト開発においてますます重要な役割を果たしています。独立系開発者は、プロジェクト開発においてますます重要な役割を果たしています。昔に比べて、3 ~ 4 人の大規模なチームで協力する必要はなくなり、今日の優れたプロジェクトは 1 ~ 2 人の開発者、場合によっては個人だけで完成することが多くなっています。

この傾向の背後には、サーバーレスの波が重要な原動力となっています。サーバーレスを使用すると、開発者は基盤となるインフラストラクチャの詳細を気にすることなく、ビジネス ロジックに集中できます。今回は、ローカル デプロイメントを使用して独自のアプリケーションを実装している開発者は見当たりません。Vercel はフロントエンドとビジネス コードのデプロイメントに使用され、Qrdrant ( https://qdrant.tech/ ) または Pinecone () はバックエンドに使用されます。 Vectorデータベースなどのコンポーネント  (  https://www.pinecone.io/  )、リレーショナル データベースは TiDB Cloud Serverless (  https://bit.ly/3PsYJle  ) を使用します。このセットを使用すると、基本的にエンジニアはデモを完了できます。 -レベルのアプリケーション。

この時代、AI 分野だけが優れているわけではなく、他の伝統的なテクノロジーも実際に開発者にますます便利な体験を提供しており、常に時代の波に乗って繰り返されています。

開発者自身に焦点が戻る限り、誰もが明るい未来を得ることができます。

おすすめ

転載: blog.csdn.net/TiDB_PingCAP/article/details/132739523