LLMの普及で、ますます重要となるベクトルデータの活用　シチュエーション別「Pinecone」の3つのプラクティス

自己紹介とアジェンダ紹介

八百俊哉氏：では、最後の発表です。「Pineconeの重要性とプラクティス」というところでお話をしようと思います。よろしくお願いします。

まず自己紹介です。名前は、「やお」と読みます。八百俊哉です。大学で機械学習を専攻しており、画像処理や自然言語処理の概要はそこで学びました。

2020年に新卒で株式会社フィードフォースに入社して、入社時からデータサイエンティストとして、社内のデータ分析を中心に業務を担っています。

最近はデータ分析だけではなく、ChatGPTを使って新規事業をなにか作れないかと模索しています。休日はバレーボールをやっています。

本日のアジェンダです。1つ目が、LLMの急速な普及によって、ベクトルデータは非常に重要性が高まっていますよというお話と、通常のデータベースとベクトルデータベースの違いについてお話しします。

その後、先ほども少しお話がありましたが、「Pinecone」の基本機能と特徴を話して、最後は、プラクティスみたいなところで、indexをどういうふうに管理するのがいいのかというお話をしようかなと思っています。

LLMの急速な普及により、重要性を増すベクトルデータの活用

このあたりは、みなさんすでにご存じかと思いますが、さらっと見ていこうかなと思います。

近年、ベクトルデータの重要性が非常に高まっていると思っています。従来のデータ形式、（スライドに）「こんにちは」と書いていますが、こういうデータではなく、ベクトルデータをうまく活用することが非常に重要になってくる。

ベクトルデータは、普通のデータベースで扱うのではなく、ベクトルデータベースという特別なデータベースを使うことが非常に効果的になってきます。

LLMとベクトルデータベースはどういう関係性があるのか。1つ目、普通にChatGPTに聞くだけであれば、LLMの知識内で回答が返ってくるのですが、ベクトルデータベースを活用すると、「ReAct」みたいなかたちで、クエスチョン内容に近いデータを探索してきて、LLMの知識にない情報でも回答を作成できるという利点があります。

従来のデータベースとベクトルデータベースにおける“3つの違い”

ここから、従来のデータベースとベクトルデータベース、どのような違いがあるのかを、あらためてさらっとさらおうかなと思います。

3つですね。まず1つ目、データ構造が違います。2つ目、検索／クエリ処理みたいなところが違います。3つ目、スケーラビリティ。大きくこの3つの部分ですね。

1つ目からさらっていこうと思います。従来のデータベースは、テーブルとしてデータを格納するのですが、各テーブルは、行と列で構成されているかなと思います。一方で、ベクトルデータベースは、ベクトルとしてデータを格納する……まぁ、これは当たり前と言えば当たり前ですが、このように大きな違いがあります。

続きまして2個目ですね。これはかなり大きな違いかなと思います。従来のデータベースは、SQLを用いてデータを検索や更新を行いますが、完全に一致したデータしか取得できませんでした。

厳密に検索するというところですね。ベクトルデータベースは、類似度に基づいた検索をするので、「完全に一致していなくても、似たものを5つ取ってこいとか」、「似たものを10個取ってこい」みたいなことが可能です。

3つ目は、スケーラビリティです。従来のデータベースは、スケーラビリティの問題が発生しやすかった。ただ、ベクトルデータベースは、大規模なデータセットやリアルタイムなクエリにも対応可能という、この3つの大きな違いがあります。

それぞれをLLMと掛け合わせることでどういう効果があるのかというところで、1つ目、機械学習モデルや深層学習で生成されるベクトルデータの管理が非常に容易になるというところですね。これは、Embeddingの話と深く関わってくるところになっています。

2つ目、与えられたクエリベクトルに最も近いベクトルを効率的に検索できる。3つ目、スケーラビリティが普通にいいよねという話ですね。

「Pinecone」の優れた特性

ここからPineconeの話に入っていきます。Pineconeは、先ほども軽く紹介されていた方がいたと思いますが、ベクトルのデータベースのサービスになっています。

主な機能が3つありますが、これは、Pineconeのサイトからそのまま持ってきただけなので、割愛しようかなと思います。

Pineconeの概念を説明

Pineconeを使って、社内でいろいろちょっと試行錯誤してるのですが、ベクトルデータベースに最適なプラクティスはまだあまり確立されていないかなと思うので、ここから私が実際にやっていることをちょっと紹介しようと思います。

ちょっと文字が小さくてごめんなさい。後ろの方は見えないかもしれませんが、Pineconeの概念です。実際に、Pineconeにはどういう値が登場するのかを軽く図で押さえました。

まず、一番上にあるのがOrganizationですね。これは、組織。Indexという大きな固まりを束ねています。Organization単位で請求が発生するかたちになっています。

次に大きな固まりが、Indexですね。このIndexが、Vectorを束ねています。なので、複数のVectorがIndexの中に入っている状態ですね。

その中にあるVectorに含まれているのが、主に4つです。ほかにもいっぱいあるのですが、今回は4つだけご紹介します。

values。これには、ベクトルデータが入っています。idには、index内で固有の重複なしの値が入っています。namespacesは、グループですね。最後metadataです。この4つを今回紹介しようと思います。

ベクトルデータはそのままですね、文字列をEmbeddingしたベクトルが入っています。idもindex内で重複しなければ特に指定はないのですが、Fetchという関数を使うことによって、idをもとにVectorを取得することもできます。

namespacesは、Vectorの集合を作成したい時に使用します。下のほうに例で書いていますが、indexをqueryする時に、namespacesをsampleとすると、indexの中からnamespacesがsampleとなっているものの中から似ているものを3つ取ってくる、みたいなことができる感じです。

最後に、metadata。さまざまなフォーマットがサポートされているメタ情報で、フィルタリングする時に使用する値です。

フィードフォース社の活用事例

ここから、実際に社内でどういう活用をしているのかを紹介します。

valuesはそのままベクトルが入るのですが、idもなんでも適当に作成しています。ここの例でいうと、「Slack」から持ってきたEmbeddingデータであると、slackの後ろにチャンネル名をつけて、そのチャンネルの何個目のデータかをidにしています。これは自由に入れてもらって大丈夫かなと思います。

次に、namespacesには、どの文章からベクトルを作成したのかという値を入れています。（スライドを示して）ここではSlackからこのデータを作っているのでslackと入れていますね。

metadataの説明です。metadataもまず文書IDのところで、Slackのどのチャンネルから持ってきたデータか、実際のテキストを入れて、metadataの中にももう1つね、どの文章かみたいなデータも入れています。

シチュエーション別、3つのプラクティス

ここから、シチュエーション別のプラクティスとして、どういった時にどのデータが本当に必要なのかを考えながら、3つほど、例を紹介しようかなと思います。

1つのサービスから、条件分岐なしでベクトルを取得する場合ですね。これは、ほとんど工夫する必要はないかなと思います。metadataもnamespacesもなく、導入ができます。使用するものは、valuesとidですね。

ここからちょっとずつ条件分岐が発生してくるのですが、1つのサービスから1つの集合を指定してベクトルを取得する場合、右側の図でいうと、（スライドを示して）この1つの丸の部分ですね。条件が1つだけのところからベクトルを取得する場合は、namespacesを用意することによって対応できるようになっています。

集合を区別できるnamespacesをそれぞれのベクトルに用意することによって、queryの条件に合わせて取得する集合を変更できます。

最後です。1つの会社で、複数のSaaSを束ねているというシチュエーションがあると思います。例えば、サービスAからはこの情報とこの情報が欲しくてほかのサービスからはこの情報とこの情報が欲しいみたいな、複数の条件でベクトルを取得したい場合には、namespacesではなくmetadataを使う必要があります。

なぜかというと、namespacesは1つの条件しか指定できないからです。複数の条件を使ってベクトルを取得する時は、metadataを使う必要があります。

図で起こすと、こういうかたちですね。複数の条件の中からベクトルの集合を指定して、そこから類似している文章を取得しています。

こちらは、非常にさくっと作れるものではないというか、Indexを増やせば増やすほど料金がかかってくるので、サービスが今後どう拡張していくのかとか、「そのIndexってほかのサービスから参照しないんだっけ？」みたいなことを考えながら全体設計をする必要があります。たぶん、最初に紹介した1個目、2個目をやったことがある人じゃないと、設計は難しいんじゃないかなと思っています。

最後までご清聴いただきありがとうございました。現在進行形で、このあたりは抽象化が進んでいる部分なので、変化が激しくて、アップデートで明日はぜんぜん違うということもあると思いますが、現在の私がわかる範囲で情報をまとめてみました。

という感じで、最後までありがとうございました。

（会場拍手）