Momentoブログ

Blog Articles

vector index ってなんだろう？

vector indexは、ベクトルと呼ばれる多次元データを保存・管理するために設計された特殊なタイプのインデックスです。「embedding models」と呼ばれるAIモデルからベクトルを生成することができます。embedding modelsは、オブジェクト（記事、画像、動画）をベクトルとして要約します。この数値表現は、元のオブジェクトの意味するものを保持します。ベクトルに含まれるそれぞれの数値は、vector embeddingと呼ばれます。 vector indexは、超効率的なAI対応システムを管理する鍵です。vector embeddingと呼ばれる、アイテムの本質を数学的に捉えたベクトルデータを格納します。vector indexの中にあるとき、これらのvector embeddingは、SF映画で見るような3Dホログラフィックな「星図」のように見えます。embeddingが近ければ近いほど、その点は大きく明るくなります。それを1000次元で想像してみましょう。専門用語で言えば、related vector embeddingsは、データ内の関係を明らかにします。これにより、vector indexは、プレーンテキスト検索の単純なマッチングを超え、AIが強化したセマンティック検索の領域へとアプリを移行させることができるのです。なぜセマンティック検索が重要なのか？例を見てみましょう。これはカサブランカで撮影されたファッション写真と、カサブランカのバザールにいる女性の写真です。通常、これらの写真にはあまり関連性がありません。それぞれ服装も、照明も、人物も、カラー写真とセピア調の白黒写真も、建物の中の写真と路上の写真も、まったく違います。しかし、両者を結びつけるものは、どちらも写真であり、どちらも人間の画像であり、どちらも服を着ていて、どちらもモロッコのカサブランカという街で撮影されたということです。vector indexに格納されたベクトルではどう見えるのでしょうか？ Photo1 = [ 234.53, 45.31, 23.45, …]Photo2 = [ 45.32, 98.6, 23.45, …] これはどういうことかというと、vector indexにこれらのベクトルを書き込むことで、類似するvector embeddingは、vector indexの多次元空間において、他のベクトルの近く、隣、または同じになります。それらは自動的に関連しているのです。従って、セマンティック検索で、23.45近辺のvector embeddingを持つベクトル、45.31近辺のvector embeddingを持つベクトルなど、すべてのベクトルを見つけることができます。45.31付近のXYZを検索します。私たちが扱っているのは数値の配列であり、かさばるデータではないので、このような検索を満たすことは、他のインデックスタイプよりも劇的に効率的であり、パフォーマンスも高いのです。 vector indexを何に使うのか？ vector embeddingでvector indexが何をするのかがわかったところで、vector indexを使って何ができるのか、いくつかの例について説明しましょう。 AI チャットボット例えば、ある製品のドキュメントサイトなど、特定のデータセットをAIに学習させることを考えてみましょう。それを、様々な言語でアプリケーションを書くための他のトレーニングデータと組み合わせれば、ドキュメントのセットに対して質問をし、AIにユーザーのためにコードを書かせることができます。もうドキュメントを検索する必要はなく、AIに普通に質問するだけで、トピックに沿った、あるいは質問した内容に似た回答を生成してくれるのです。このユースケースは、私がナレッジbotと呼びたいものです。検索このアプローチは、推薦エンジン、画像認識、自然言語処理(NLP)など、様々なアプリケーションにおいて基本となっています。膨大なデータセットから関連する項目を効率的に見つける能力により、類似検索は現代のデータ分析や機械学習における強力なツールとなっているのです。これは、商品カタログ、動画/音楽ストリーミングサイト、電子商取引サイトなどで利用できます。推薦エンジンこれは”検索”でも触れたが、単独な機能としても十分に一般的です。例えば、あなたがテーブルを購入するためにオンラインで調べているとしましょう。あなたの過去の購入履歴や、他の人が検索したもの、クリックしたもの、高評価を得たものを知ることで、AIを活用したレコメンデーションは、単純な検索よりもあなたのリサーチに適したサイトや画像、動画を提供することができるのです。異常検知異常検知は、データ分析において重要なプロセスであり、予期された動作に適合しない異常なパターンを特定します。これらの異常値や異常現象は、不正行為、ネットワーク侵入、システム障害などの問題を示す可能性があります。リアルタイムで異常を検出できるため、即座に対応でき、潜在的なリスクを軽減し、システム全体の整合性と信頼性を高めることができます。感情分析言葉をvector indexの多次元空間にマッピングすることで、ポジティブ、ネガティブ、またはニュートラルな感情に相関するパターンを見分けることができます。これにより、大規模なデータセット間で効率的な比較が可能になり、製品やトレンドなどに対する意見を測定するのに役立ちます。リアルタイム処理と適応性により、vector indexは、様々なプラットフォームにおけるユーザーの感情を理解し、それに対応するために価値あるものとなります。この記事は Kirk Kirkconnell によって書かれたWhat is a vector index?の日本語訳です。翻訳は、Momento Community Advocateの小板橋由誉が担当しました。

カーク・カークコネル

著者

データベース

View ブログ: サーバーレスWebSocketサービス「Momento Topics」を構築するまで

サーバーレスWebSocketサービス「Momento Topics」を構築するまで

数ヶ月前、Momentoはフルマネージド・サーバーレスWebSocketサービス「Topics」をリリースしたました。このサービスは、あらゆるものを接続することを目的としています。バックエンド・サービスとバックエンド・サービス、バックエンド・サービスとユーザー・インターフェース、さらにはユーザー・インターフェースとユーザー・インターフェースを、文字通り2回のAPIコールで接続することができます👇。そしてメッセージを受け取ること：リソース管理もコンフィギュレーションもなく、ただコードを書いて実行するだけです！ Amazon SQS、SNS、Kinesisのようなサービスもサーバーレス・イベント・メッセージング・サービスだが、バックエンド・コンポーネント間でイベントを送受信することに重点を置いています。反面、Pusher、Amazon AppSync、AWS IoT Coreのようなサービスは、WebSocketのようにバックエンド・サービスとユーザー・インターフェイスを接続して使用することを意図しています。これらはWebSocketの複雑さの多くを抽象化した素晴らしいサービスですが、私たちMomentoは、リアルタイム通信を構築するための開発者体験を改善し続けることができると考えました。 ‍ そこで私たちは、あらゆるものがあらゆるものと通信できるようにする、極めてシンプルなサービス、Topicsを構築しました。この高度にスケーラブルなサービスは、毎秒数百万トランザクション（TPS）という驚異的な低レイテンシーを誇り、プライムタイムの準備が整っています。信じられないですか？このサービスがどのように構築され、何がこのサービスを輝かせているのかを見てみましょう。イベントとサブスクリプションまず、トピックを介してMomento Topicsに情報を公開したり購読したりするときに何が起こっているのかについて説明しましょう。トピックとは、パブリッシャーと購読者間の集中的なコミュニケーション形態であり、専用のチャットルームのようなものだと考えてください。ユーザーインターフェイスやバックエンドサービスがトピックを購読するとき、Momento に何かが起こったときに通知するように指示します。具体的には、誰かがトピックにイベントをパブリッシュ (送信) したときに通知されます。サブスクライブのユースケースとしては、チームメイトがサインオンしたときや、インスタントメッセージを受け取ったときにエンドユーザーに通知することが考えられます。 Momento Topicsでは、サブスクリプションは、サブスクライバとMomentoサーバ間の長期間のgRPC接続です。これは電話を設定するようなものです。あなたのユーザーインターフェイスは、Topics サービスを呼び出し、そのサービスとのオープンな接続を持つようになり、両者間で即座に直接データを転送できるようになります。 SNSはアクティブな接続を維持しないので、これはAmazon SNSなどとは異なります。その代わりに、SNSの購読者は電話帳に追加され、イベントが発生したときに誰が呼び出されるべきかをサービスが知ることになります。その結果、レイテンシーは高くなるが、ステートレス通信が可能になります。ステートレス通信は、電子メールを送信したり、キューに何かを追加したりする必要があるときなど、リアルタイム性が要求されないときには非常に有効です。このような状況では、ワークフローの非同期性によりレイテンシーが高くなることは全く問題ありあせん。 Topicsが他のWebSocketサービスと異なるのは、転送プロトコルです。標準的なWebSocket接続は、wsまたはwssでデータを転送します。IoT デバイスは通常、MQTT 経由でデータを転送します。しかし、Momento TopicsはgRPCを使用しているため、データはHTTPで転送されることになります。これらのプロトコルの主な違いを見てみましょう： WSS Pros：全二重（同時双方向）通信を提供。リクエストにヘッダーやメタデータを必要としないため、帯域幅のオーバーヘッドが少ない。ブラウザやサーバー環境で広くサポートされています。Cons：接続の設定と管理が複雑な場合があります。接続管理のためにサーバーリソースを大量に消費します。 MQTT Pros：低帯域幅、高遅延、または信頼性の低いネットワークに最適化されています。様々なレベルのメッセージ配信保証を提供。遺言（LWT）を提供します。Cons：ウェブブラウザではネイティブにサポートされていません。オーバーヘッド（キープアライブメカニズム）が追加されるため、wssに比べてレイテンシーが高くなります。 HTTP (gRPC) Pros：HTTP/2を使用し、より高速なパフォーマンスを実現するための多重化とヘッダー圧縮をもたらします。双方向ストリーミングが可能です。Cons：JSONやXMLの代わりにプロトコル・バッファを使ってシリアライズする。インテグレーターにとっては、RESTほどなじみがないかもしれない。一方、イベントはほとんど説明の必要がありませｎ。イベント・ドリブン・アーキテクチャーについて私が聞いた中で最も良い説明は、Momentoのカンファレンス「MoCon」でエリック・ジョンソンが語ったものです。彼はこう言った。そして我々は反応する。イベントとはその “何か “のことなのです。イベントは何でも表現できます。ブール値でも、エンティティ識別子でも、JSONオブジェクト全体でも、さらには写真でもかまいません。Momento Topicsでは、イベントのペイロードとしてバイト配列を提供します。すべての購読者は、あなたが提供する同じペイロードを受け取るので、イベントに適切に反応することができます。さて、サブスクリプションとは何か、何を受け取るのかを理解したところで、アーキテクチャについて話しましょう。サービス・アーキテクチャ私にとってサーバーレスWebSocketを使う最大の理由は、ベンダーが提供するインフラ管理です。私はシステム管理者ではなく、アプリビルダーです。接続の負荷分散や自動スケーリング・グループの設定、利用率の計算や急増するワークロードの管理方法などは知りません（知りたくもありません）。私が知っているのは、アプリケーションにビジネス価値を提供する方法です。私が時間とエネルギーを費やしたいのはそのことであって、インフラの心配をすることではありません。幸運なことに、Momentoのエンジニアたちはインフラについて熟知しており、深く気にかけています。ここでは、オンデマンド・スケーリング、使用した分だけの支払い、スケジュールされたダウンタイムなし、リソースのプロビジョニングなしといったサーバーレス機能を提供するために、彼らがどのようにTopicsを構築したかを覗いてみましょう。 Topicsは2層のアーキテクチャで構築されており、自分で接続を管理するよりも1000倍速く、優れたファンアウトを可能にします。2つの層とは、ルーティング層とストレージ層です。ルーティング層ティア1はルーティング・レイヤーです。このレイヤーは、メモリ内にMomentoエコシステムの完全な地形図を持っています。SDKからのリクエストに対応し、サブスクライバーへの接続を管理し、どのティア2ノードがトピックメッセージを保持しているかを計算します（詳細は後述します）。このレイヤーは、高スループットのEC2インスタンスの自動スケールフリートです。Topicsサービスは、ラウンドロビンのロードバランシングパターンを使用して、受信サブスクリプションを管理します。キャパシティが特定の閾値に近づくと、Control Plane（Momentoの頭脳）が別のインスタンスをウォームアップし、エコシステムのトポグラフィを渡し、それをミックスに追加します。ストレージ層第2階層はストレージ層です。イベントがトピックにパブリッシュされると、ここに着地し、接続されたルーティングレイヤーのノードに配信されます。このレイヤーには、アーキテクチャーの優れた部分があります。ストレージノードはルーティングレイヤーノードとだけ通信し、ルーティングレイヤーノードはサブスクライバーと通信します。新しいサブスクリプションが追加されると、指定されたルーティングノードはどのストレージノードがそのトピックを所有しているかを計算し、そのストレージノードとの長期間のgRPC接続を確立します。これは、ルーターがエンドユーザーのサブスクリプションで行っているのとまったく同じパターンです。つまり、Momentoサーバーは他のMomentoサーバーとサブスクライブし、可能な限り接続を再利用しているのです。例を見てみましょう。上記の例では、3つのルーティング・ノードと2つのストレージ・ノードがある。5人のエンドユーザーが「weather-alerts」キャッシュの「Dallas – TX – Hail storm」トピックを購読しています。決定論的ハッシュによって、トピックメッセージはストレージAに存在します。接続が来ると、リクエストはルータ-A、ルータ-B、ルータ-Cに均等に分散されます。4番目のサブスクライバで、Router-AはStorage-Aに接続する必要があると判断するが、Storage-Aとの接続がすでに開かれていることを知っているので、接続は再利用されます！同じことがサブスクライバ#5にも起こります。サブスクライバ#5はストレージノードとの既存のコネクションを再利用します。メッセージがトピックにパブリッシュされると、ストレージノードはそれをオープンなコネクションにブロードキャストし、次にルーティングノードも同様に、サブスクライバーへのオープンなコネクションにブロードキャストします。これにより、少ない接続数と拡張性の高いファンアウトパターンが可能になり、その結果、非常に高速なメッセージ配信と、開発者にとって弾力的に拡張可能なエクスペリエンスがもたらされます。トピックの位置の決定 Topicsサービスを構築する前の最初の会話では、開発者がトピックリソースを使用する前に作成する必要はないということで合意していました。チームは、それが開発者のエクスペリエンスを奪い、イベントメッセージングに不必要な部分だと感じていました。このサービスのゴールは、アプリケーション開発者がビジネス上の問題を解決するという1つの焦点に集中できるように、未分化の重労働をできる限り引き受けることでした。そこでチームは、トピックリソースを作成してサーバー上のストレージロケーションを割り当てる代わりに、サブスクライバーのアカウントID、キャッシュ名、トピック名を使用してランデブーハッシュを使用し、ストレージノードを動的かつ明確に指すことを選択しました。つまり、ルーティングノードがロードバランサーの内外にシャッフルされるとき、どのトピックがどこに存在するかという状態を維持する必要がありません。‍ 結論 Topicsは、当社のキャッシュ・サービスと同じハードウェア上で動作します。意図的に低遅延、高スケーラブル、瞬時に準備できるように設計されています。 2層アーキテクチャを使用することで、サブスクリプションをファンアウトし、サブスクライバーの数に関係なく、低遅延のメッセージ配信を提供することができます。このようなアーキテクチャは、Momento Topicsが他のイベントメッセージングサービスと異なる点です。他の多くのサービスは、このような方法で実行する機能を持っていますが、そのほとんどは、あなたのためにそれを管理できません。 Momentoはできます。つまり、夜中の3時にメッセージが届いていないという電話がかかってくることはないので、安心して眠れるのです。それは私たちの責任です。サブスクリプションはgRPC接続であり、電話のようなものであることを覚えておいてください。電話はステートフルであり、あなたと通話相手の両方が通話中でなければ機能しません。つまり、LambdaやCloudflareワーカーのようなサーバーレス関数でサブスクライブしようとしてもうまくいかないのです。関数の実行が終わると、コードは一時停止されます。これは、電話が保留になり、最終的に切断されることを意味します。ブラウザ、コンテナ、サーバーのようなステートフルな環境で使ってください。とはいえ、どこからでもパブリッシュできます。データを公開しても接続は設定されないので、すべての機能で自由に使用できます。私たちは、あなたがトピックスで成功することを望んでいます。ご質問、ご意見、ご不明な点がありましたら、お知らせください。私たちはオープン・アーキテクチャを信条としています！どのように機能するかを喜んで共有させていただきます。チームへのご連絡は、ウェブサイトから直接お願いします。あなたからのご連絡と、あなたが作るものを見るのを楽しみにしています！ Happy coding!