Events
Milvus実践：Troopの株主アクティビズムを支えるベクトルデータベース

ウェビナー

Milvus実践：Troopの株主アクティビズムを支えるベクトルデータベース

Zillizウェビナー - Zoom

Join the Webinar

セッションについて

株主アクティビズムとエンゲージメントに革命をもたらしている先駆的なテック企業、Troopとのコラボレーションによる限定ウェビナーにぜひご参加ください。TroopがMilvusを活用してSECデータベースを精査し、インテリジェントなレコメンデーションエンジンを構築し、さらには株式投票を自動化する方法を学びましょう。Milvusのベクトルデータベース技術が単なる追加機能ではなく、株主アクティビズムの民主化というTroopのミッションを拡大するための中核的なコンポーネントであることをご確認ください。

取り上げるトピック:

大企業における集団的な金融アクティビズムに向けて個人を力づける、市場のギャップに対するTroopのソリューションをご紹介します。
Milvusの堅牢なベクトルデータベース機能が、Troopの機械学習ツールに不可欠であり、効率的なSECデータベース分析とパーソナライズされた株主向けレコメンデーションを支えている仕組みを学びます。
あらゆるものをベクトル化し埋め込むというTroopのビジョンと、この野心的なロードマップにおいてMilvusが果たす極めて重要な役割を探ります。

View presentation slides

Transcript

本日のセッション「Vis in Action,the Vector Database Behind Truth Shareholder Activism」と、ゲストスピーカーのZen Yuiをご紹介できてうれしく思います。ええと、こちらがYui Yuiです。ここにいる皆さんに自己紹介していただいてもよろしいですか？もちろんです。こんにちは、そしてSteffi、お招きいただき本当にありがとうございます。私の名前はZen Yuiで、Troopの共同創業者兼CTOです。

ええと、簡単に言うと、私たちは株主アクティビズムと議決権行使助言の会社です。ええと、この分野でこれからお話しするさまざまなことを行うために、機械学習を活用しています。ええと、お招きいただき本当にありがとうございます。もちろんです。ええと、まず最初に、私たちは本当にChuについて知りたいと思っています。

ええと、Chuの概要と提供しているサービスについて簡単に説明していただけますか？はい、もちろんです。よろしければ、この件についてスライドを用意しているので、すぐに入っていけます。はい。いいですね。もちろんです。

では、ええと、皆さんご参加ありがとうございます。ええと、ここに来られてとてもうれしいです。ええと、Troopについてお話しする前に、Troopと私たちのエンジニアリングチームは、機械学習と生成AIにおける私たちの成功の多くを、この分野で、そしてこれらのツールを使ってハッキングしている他の方々の素晴らしい講演を聞くことに負っている、ということをお伝えしたいです。ですので、今日、私たちが構築したものや、私たちがいくつかの問題をどのように解決したかを聞く中で、ええと、皆さんがこの一部を自分の仕事に取り入れたり、取り組んでいる何かで行き詰まりを解消したりできるかもしれないことを願っています。ええと、またこの講演の最後に、私の連絡先情報を共有しますので、皆さんとつながって、株主アクティビズム、生成AI、あるいは皆さんが取り組んでいることについてお話しできれば大変うれしいです。

ええと、そして今日のこの講演は、構造化データパイプラインの一部として大規模言語モデルを使用すること、非構造化データから大規模にラベルを作成すること、そして会社のために機械学習の可能性の世界全体を切り開くことについてです。ええと、また、生成AIを使ってデータを圧縮し、下流でより小さなモデルを訓練できるようなものにすること、そして場合によっては従来の教師あり学習手法を重ねることについてもお話しします。そしてもちろん、これらすべてがどのように可能になっているのか、ええと、Visで埋め込みを大規模に保存することについてです。ええと、そして、ええと、それらをどのように行っているかに入る前に、私自身について簡単な背景をお話しします。ええと、Troopの前は、私はビッグデータのデータエンジニアで、ええと、バッチおよびストリーミングシステムのようなものに取り組んでいました。

ええと、私は約100テラバイト規模のデータコーパスを扱っていました。そして、ええと、私はビッグデータを2つの方法で定義しています。1つ目は、1台のマシンで扱えない、または簡単には扱えないものです。2つ目は、一般的に管理が不快になるほどのデータサイズであり、処理に計画上多くの時間がかかるものです。そして私は、最も価値のあるデータ問題はメモリに収まらないと感じています。

ええと、それにもかかわらず、RAGのようなものや、これらのインコンテキスト学習手法の多くを行うHello Worldの例の非常に多くは、ええと、Hello Worldの例が非常に1つの、例のないものであり、インメモリデータベースを使用する理由は理解しています。ですので今日は、ええと、これらの多くの手法をより大規模な分散データに適用すること、それをどのように行うのか、複数のマシン、複数台のマシンにまたがるデータセット、そして一度にすべて処理したくない量のデータに対して、Vissをどのように使えるのかについてお話ししたいと思います。それでは、ええと、Troopについて簡単にお話ししましょう。Troopは、ええと、一般の投資家が上場企業をガバナンスできるようにするテクノロジーを構築しています。ええと、その理由は、私たちは皆、これらの企業の株式を所有しているからです。

私たちは株主です。それらの株式には投票権が付いています。つまり、コーポレートガバナンスは私たち全員の共同責任であるということです。Robinhoodで株を買うときに、私たちの多くがあまり考えないことですが、それらの株式には議決権が伴い、これらの企業は私たちの生活に影響を与える重要な決定を下します。それらは私たちの都市の政策にさえ影響を与えます、ええと、などです。

それで、ええと、ご存じのように、troop、troopの起源はマトリックスの中のブリップにまでさかのぼります。これを覚えている人がいるかわかりませんが、ええと、約2年前、Redditorの集団がWallstreet Bettsというsubredditに集まり、GameStopという株をめぐって集団化しました。そして私たちはこの歴史的瞬間に非常に興奮していました。なぜならそれは、マルチプレイヤー・ファイナンスの最初の本当の例、つまりインターネット上のまったくの見知らぬ人たちが集まり、お金を使って一緒に問題を解決しようとすることを示していたからです。ええと、GameStop運動は市場における集団行動の最も成功した事例ではなかったかもしれませんが、広く分散したものとしては最初の非常に重要な事例でした。GameStop運動について多くの人が語らないのは、その6か月後に、その同じインターネット上の見知らぬ人たちのグループが、実際に年次株主総会で誰かをGameStopの取締役会議長に選出することに成功したということです。

そしてそれは驚くべきことです。その前例はあまりありません。ですから私たちは、ほぼ同じ時期に、ええと、Engine Number Oneという小さなアクティビスト・ヘッジファンドがExxonMobilという巨大な石油・ガス会社に、再生可能エネルギーの名のもとに3つの取締役会席を明け渡させたことを、とてもクールだと思いました。そしてそれは直感的にはわかりにくいかもしれませんが、彼らはしばらくの間、強力な財務的主張を実際に展開しました。米国が電気自動車へ移行している中で、石油・ガス会社は競争力を維持するための移行計画が必要であり、Exxonの同業他社には移行計画がある、というものです。

そしてExxonは、わかった、ええと、それはビジネス上理にかなっている、と言いました。そこで私たちtroopチームは、一歩引いて、うわ、これら2つはとてもクールだ、Mike、つまり、マルチプレイヤー・ファイナンスとアクティビズムは本当にクールだ、と言いました。非常に興味深く、ええと、効果的であるようにも見えます。では、インターネット上の見知らぬ人たちが集まり、彼らの証券口座をまとめ、実際にこれを継続的に行うのを助けるコミュニティを作ったらどうだろう？そしてそこからtroopが生まれました。今日まで早送りすると、私たちには、ええと、2つのプロダクトがあります。

右側のTroopですが、ええと、私たちは、私たちは最初、株主アクティビズムのコミュニティアプリでした。そしてそれはまさに私が説明してきたものです。コミュニティプラットフォームです。troop. comにアクセスするか、私たちのネイティブアプリをダウンロードして、あなたと同じ株を保有する他の大勢の見知らぬ人たちと出会い、新しいアクティビズムを立ち上げることができます。一緒にデューデリジェンスを行うことができ、十分な牽引力が得られれば、実際にtroop、ええと、私たちのリサーチおよび法務チームとつながり、それをすべてS E Cに提出して現実のものにする支援をします。このプロジェクトに取り組んで2年が経ち、私たちが気づいたことの一つは、ほとんどの人がバンドルされたパッシブ運用の金融商品を通じてかなりの富を投資しているということです。

ETFや、投資信託、あなたの退職口座を考えてみてください。そしてそれらは高い忠実度を持つべき関係です。私たちは資産運用会社と話すべきであり、それらの株式について議決権を行使すべきです。ええと、しかし実際には良いコミュニケーションの仕組みがありません。さらに、それらの資産運用会社は、私たちが何を重視しているのかを本当に知りません。ですから現在、彼らは社内で作成した一連の議決権行使指針に従って投票していますが、それは私たちが望むものを代表していないことが多いのです。

そこでtroopは、Gen AIと機械学習を使って、そのギャップを埋めることを目指しています。つまり、資産運用会社がスケールして、私たちが何を望んでいるのかを理解できるよう支援し、その結果として、私たちのすべてのパッシブ運用される資産を私たちの価値観に従って自動的に議決権行使できるようにすることです。そしてこの問題の規模を理解し、またおそらくなぜgen AIが適しているのかを理解するために。多くの人はこれを理解していませんが、上位10社の資産運用会社だけで37兆ドルを運用しています。それは何億人ものアメリカ人に広がっており、そうした人々はこれらの資産運用会社と一度も話すことがありません。そしてこれらの資産運用会社は、何億人ものアメリカ人に代わって、この37兆ドルについて、3000社をはるかに超える上場企業で議決権を行使しています。これらの企業はそれぞれ、少なくとも年に1回の株主総会を開催し、そこで投票が必要な多くの事柄について話し合います。重要な意思決定を行うのですが、これをうまく取りまとめる良い方法は実際にはありません。

非常に多くの情報があります。この分野でハッキングをしてきた方、gen AIツールを使っている方、あるいは最新の株式を追っている方の多くは、おそらく、人々が行っているいくつかのクールな取り組みに馴染みがあるでしょう。チャットボックスのチューニング、チャットボット、決算報告書との対話などです。ええと、Twitterで大きく話題になった有名なものがありました。誰かがチャットボットを作り、Teslaの決算報告書と対話して、主要なリスクや、会社がうまくいった点、改善できる点について質問するようなものでした。そこで私たちはその研究を基に、はるかに大きなスケールで発展させたいと考えました。つまり、インターフェースがチャットではなく、私たちがただ、あなたが何を重視しているのか、資産運用会社の取締役たちは何なのかを把握し、その2つを組み合わせることで、基本的に、あなたが重視する内容に基づいて、これらすべての会議において、これらすべての人々のために、大規模に自動的に投票できるようにする、ということです。そしてこれを実現するための、もちろん最もエレガントな解決策の1つが、AIにおける十分に訓練されたモデルです。要するに、世の中の多くの皆さんと同じように、私たちはRAGを使ってSEC提出書類を一括処理し、構造化された特徴量、要約、ラベルに変換しています。それらを下流で、投票、パーソナライゼーション、レコメンデーションエンジンなどを行うファインチューニング済みモデルや特定用途向けモデルに利用できるようにし、この問題を管理可能で、従来のデータサイエンスやデータエンジニアリングのツールで実際に扱える健全なものにしています。

ですから今日の話はまさに、皆さんがRAGに関する多くの講演を見ていることは承知していますが、その前段階についてです。テラバイト単位、さらにテラバイト単位の情報を実際にどう理解するのか。どう埋め込むのか。どう整理するのか。そして、RAGを大規模に成功させるために、どう準備するのか。ではまず、TroopsのソリューションのV1の、いわばささやかな起源について話しましょう。ええと、これは皆さんの多くにとって見覚えがあると思います。私たちがやっていたのは、本質的にはLang Chainを使うことでした。このツールの大ファンです。そして具体的には、Facebookチームから出てきたベクトルデータベースのFaceを使っていました。これは、ベクトル検索、特に検索に関する、かなりすごい研究を多数実装しています。たとえば、実際に全員との距離を取ることなく、10億のベクトルを検索するようなものです。

ですから、私たちはこれら両方のプロジェクトの大ファンです。ええと、私たちはそれらをつなぎ合わせ、事前構築済みの質問応答ソリューションを使って、PDF形式のSEC提出書類からの抽出を基本的に自動化しました。要するに、それは機能しました。非常に高速でした。少し手を加えることで、構造化データを取り出すことができました。

JSONや構造化データを取得することができました。それは機械可読です。しかし、私たちは主に2つの重要な問題に直面しました。1つは、一度に1つの提出書類しか扱えないという制約があったことです。Faceの仕組みとしては、情報をチャンク化し、埋め込みを作成し、このローカルのベクトルストアにロードする責任は自分たちにあります。

もちろん、そのマシンのメモリにどれだけ収まるかによって制限されます。そして2つ目に、Faceは埋め込みを作成し、それを後で使うために永続化することを可能にはしてくれますが、ベクトルデータベースを長期ストレージからロードしたりアンロードしたりする全体の処理は、自分たちで管理し、そのコードをすべて書く必要があります。そこで私たちは考えました。実際にこれを大規模に解決しているベンダーがどこかにあるはずだ、と。つまり、メモリ上にあるベクトルと、静止状態で保持しているより大きなベクトルコーパスを切り離しているようなものです。そこで私たちは、いくつかの具体的な基準を満たすソリューションを探すことになりました。1つ目は、多くのハイエンドで大容量のデータツールと同様に、コンピュートとストレージを分離するものを探していたということです。

私たちは、一度にクエリする必要がある量よりもはるかに大きなコーパスと、保存時のはるかに多くの埋め込みを持ちたいと考えていました。複数の企業や複数の提出書類を同時にクエリする場合でも、SEC の全履歴をメモリにロードしておく必要は決してありません。ですから、この2つの項目を分離するソリューションを探していました。2つ目に、ええと、作業をスケールアウトできる能力が欲しかったのです。皆さんの多くもこの問題に直面していると思いますが、従来のリレーショナルなシングルノードデータベースやドキュメントデータベースで作業していると、データ量がある時点、つまり転換点に達し、クエリの実行が本当に遅くなり始め、速くする唯一の方法がより大きなノードを購入することになる、ということがあります。そこで私たちは、ええと、ノードを追加するだけでコンピュート能力を2倍にできるような、実際にスケールアウト可能なソリューションを探していました。

そして、ええと、それが私たちが探していたパターンでした。そして3つ目に、私たちのアプリケーションは Kubernetes 上で動いており、Google Cloud を使っています。ええと、理想的には、これは私たちがセルフホストして自分たちの Kubernetes クラスター内で実行できるものであるべきでした。ご存じのとおり、troop、私たちのコミュニティアプリは、非常に昼間向けのアプリのようなものですよね？そして私たちには大量の潜在的なコンピュート能力があります。ですから、たとえば夜間や週末に多くのデータパイプラインを実行し、ええと、そうでなければ使われていないコンピュート能力を活用できるのは理にかなっています。

ですから私たちはそれをセルフホストしたかったのです。そしてもう1つは、ええと、ご存じのとおり、私の優先事項の1つは、大規模なデータセットをウェアハウジングし構築するときには、ストレージを自分たちで所有したいということです。ですから理想的には、私たちが所有するデータストアへまっすぐ導いてくれるものを探していました。理想的にはそれはバケットで安価なストレージであり、理想的にはオープンソースで一般的なファイル形式で書き込まれるものでした。そして、ええと、そこで Viss の登場です。そうです、Viss はコンピュートとストレージをエレガントに分離します。

ええと、私たちは実際に mini IO アダプターを通してバケットに直接書き込むことができ、それがとても気に入っています。ええと、中核において、Viss は分散システムです。ET c d 上で動作し、ノードを追加することができ、それらが通信して互いに作業を共有します。そして最後に、ええと、Viss を Kubernetes クラスターにインストールするのは非常に簡単でした。実際に helm chart も用意されています。

私たちは非常に素早く立ち上げることができ、ええと、いくつかの設定を行うことで本番稼働できました。そして、ええと、ご存じのとおり、私は Viss のようなソリューションを見つけられて嬉しく思いました。なぜなら、それは私が成熟したスケールした分散データベースだと考えるものに非常によく適合しているからです。では話を進めましょう。先ほど、私たちは保存時のデータが、ええと、実際に一度にクエリする必要がある量よりもはるかに多いと述べましたが、ではそれほど多くの情報を実際に取り込むとはどういうことなのかについて少し話しましょう。ええと、この場にデータエンジニアの方がいれば、これは皆さんの仕事によく似て見えるでしょうし、私はただ、ええと、皆さんが新しい種類のテキストから埋め込みへ、そして Vector ストアへというパラダイムを、この、ええと、分散データパラダイムに当てはめる手助けをしたいのです。ではどのように機能するのでしょうか？Lang Chain に詳しい方なら、おそらく2つの概念に馴染みがあるでしょう。

彼らはドキュメントストアとベクターデータベースを導入しており、多くの人がこれを1つのソリューションにまとめています。実際にテキストペイロードをベクトルと同じ場所に配置している人たちもいて、それは興味深いです。ええと、そしてこれらすべてを Postgres のようなソリューションにただ押し込んでいる人たちもいます。もちろん、それがあなたのコーパスで機能するなら、それはシンプルで素晴らしいことです。ただし、私たちのようにそれが機能しない場合は、ええと、本当にこれらのコンポーネントをそれぞれの部分に分割し、その仕事に最適なツールを使う必要があります。

それで、先ほど述べたように、私たちはテキストをチャンク化することにし、ええと、そのチャンク化されたテキストコーパスをバケットに書き込み、時間でパーティション分割しました。つまり、ええと、SEC提出書類の1つの詳細として、それらは毎日SECのデータベースとウェブサイトで公開されます。たとえば最新のTeslaの提出書類について、そのIDは何か、何日に提出されたのかといったことを見ることができます。そこで実際に、私たちは生のテキストチャンクを時間でパーティション分割しています。その後、それらを埋め込みモデルに送り、ベクトルを受け取り、mil vistas内に、これも時間でパーティション分割されたコレクションを作成しました。

そして私たちが行っているのは、実際に生のテキストチャンクの時間パーティションに一致するパーティションへ書き込むことです。vissに詳しい方ならご存じだと思いますが、vissのベクトルドキュメントに少しメタデータを書き込むだけで、ベクトルをクエリし、そのメタデータを取得し、モデルで使用するための対応する生テキストチャンクを見つけることができます。ええと、より一般的に言うと、私の意見では、vissを大規模に使う鍵は、つまりvissなら5分で立ち上げられますし、実際にパーティション分割も管理してくれます。しかし、本当に大規模でサイズのあるものを書こうとするなら、重要なのは、自分のパーティション方式が何であれ、それについて多くの時間をかけて考えることだと思います。それは時間かもしれませんし、customer id単位かもしれませんし、user id単位かもしれませんが、データがどのように増えていくのかを考えてください。そして、正しくパーティション分割できているかどうかの鍵は、特定のドキュメントのベクトルやテキストペイロードにランダムアクセスしたい場合、そのデータが書き込まれているパーティションを直接狙えるかどうかです。私たちの場合は、提出書類のデータが分かっているので、そのベクトルを探しに行くことができます。

ええと、mil vista'sでこれを何も設定しない場合、デフォルトのパーティション分割は一種のラウンドロビン方式で、作業を小さなチャンクにきれいに分割してくれます。ええと、これの唯一の欠点は、先ほど述べたように、大規模になると、おそらく探しているデータがあるパーティションだけを見つけることができないという点です。ここに、troopにおいてVUSsの上で、そしてこれを、ええと、もう少し高性能にするために私たちが書いたカスタムコードの上で、RAGがどのように機能するかを示す簡単な図があります。まずクエリから始めます。たとえば、今後の株主総会で、ええと、投票対象となる取締役会メンバーのリストを探しているとします。私たちはクエリを埋め込み、それを私たちが書いたカスタムvissサーバーに送信します。このサーバーはVissクライアントとvissサーバーの間に位置しています。

これが行うことは、基本的に、ディスクから読み取ってメモリに取り込もうとしているパーティションを追跡することです。そして、もし他の、ええと、Vissクライアントがしばらくそのパーティションを要求していなければ、最終的にそれをメモリから消します。ですので、皆さんの中で、会社の本番環境でvissを大規模に動かしている方がいれば、2つの異なるmilsクライアントが同じパーティションをメモリにロードし、ええと、それを使って作業しているという問題に直面したことがあるかもしれません。そのうち一方のクライアントが、もう一方がまだ作業している間にそれをメモリから消すと、競合のような状態に陥ることがあります。ええと、これらすべては、コレクション全体をメモリにロードするのを避けるためだということも付け加えておきます。それは、ええと、私たちの問題では実行する余裕がありません。

ええと、そこで私たちはこのカスタムvisサーバーを書きました。これは基本的に、メモリへのロードと、誰も使っていないときのパッシブエージェントを管理します。その後、従来のragと同じように、ええと、それらのベクトルからメタデータを取り出し、バケットから生テキストペイロードを取得し、それをコンテキストとしてL lmmに送信し、それから結果を取得します。ええと、このカスタムvissサーバーですが、Goで書かれており、実は今VISSプロジェクトにコントリビュートすることについて話し合っているものです。現時点では、かなりtroopのユースケースに合わせてカスタム調整されています。

しかし、もしそれについて聞くことに興味があるなら、通話の後で連絡してください。それがどのように機能するのか喜んで説明します。そして先ほど述べたように、私たちはこれを vissnext に社内でコントリビュートすることについて話しています。ですので前にも述べたように、ええと、troops の機械学習プログラムの重要な目標は、クリーンな情報と私たちの生データからなる合理的なデータレイクを作成することです。ご存じのように、これらの PDF は何百ページにも及ぶことがあり、中には、いわゆる、数百メガバイトの大きさになるものもあります。そしてここでの目標は、基本的に情報を要約し、はるかに小さく、予測可能で管理しやすいものに圧縮することです。特に、下流でのファインチューニングやカスタムトレーニング、小規模モデルでの利用に向けてです。

そのために、ええと、私たちが行う必要があることの一つは、本質的には大量の情報を受け取り、それをはるかに小さなペイロードに要約する要約プロンプトとパイプラインを作成することです。そして、もし皆さんの中でこの種のワークフローに取り組んでいる方がいれば、ええと、たとえば RAG アーキテクチャの上で、社内またはステークホルダーから共通の質問に直面したことがあるでしょう。その要約が正しいとどうやって分かるのか、というより大きなパターンとしてです。彼らが尋ねているのは、実行しているこのブラックボックス抽出の、ええと、有効性と正確性をどのように評価しているのか、ということです。ええと、私たちはこれを行うための少し興味深い方法を見つけたので共有したいと思います。そしてこれは、埋め込みの力を示す始まりのようなものであり、私たちが検索だけでなく、はるかに多くの用途に対して埋め込みをどのように考えているかを示すものだと思います。要約やデータ圧縮の、ええと、プロンプトの場合、できることの一つは、モデルの結果を取得することです。たとえば 20 ページのデータの段落要約かもしれません。その要約を埋め込み、要約プロンプトの 3 つのバリアントを実行して、それらすべてを埋め込み、そのうえで結果の平均埋め込みがソース資料の埋め込みに最も類似しているプロンプトまたはモデルを選ぶ、ということです。平易な英語で言えば、それは要約で語られているトピックや概念、エンティティが、ソース資料のものに最も近いということを意味します。

ある意味では、最小限の情報しか失っていないということです。ですから私たちは要約を圧縮アルゴリズムとして考えており、それを評価するには、トピック的に同じものを描写し、同じことについて話しているかを見るだけでよいはずです。大規模には、複数の要約モデルのバリアントを実行し、基本的に機械で比較し、埋め込みを使ってどれが最も効果的かを機械で評価できます。その後、実際にその結果の埋め込みを取得し、middle に書き戻します。これは、後ほど少し話す別のユースケースのためです。

同様に、ええと、きっと皆さんの多くがこれに直面していると思いますが、人間によるラベリングは高価です。ラベルの人間による評価は非常に高価です。ただ興味深いことの一つは、より広い生成 AI および ML コミュニティでは、G P T four はほとんどの一般的なユースケースに対してかなり正確だと見なされていることです。また最も遅いモデルでもあります。高価です。

では、より高価なモデル、G P T four のようなより高度なモデルを活用して、実際により安価なモデルを評価し、訓練するにはどうすればよいのでしょうか？それは troop と私たちのアーキテクチャ、私たちの働き方の中核のようなものです。そして皆さんの多くにとっても同じだと思います。同様に、データのサブセットに対して、ええと、高価な基盤モデルを使って要約、ラベル、カテゴリを生成し、それらの出力を埋め込み、そのうえで実際に結果を、はるかに安価なファインチューニング済みまたはカスタムトレーニング済みモデルの埋め込み出力と比較できます。そして最後に、ご存じのように、私のキャリアにおいてデータエンジニアであり、かつてデータアナリストでもあった者として、ええと、これはもう 10 年間、10 年間ホットなトピックであり続けています。埋め込みを使ってデータ民主化を導入すること、そして基本的にチーム全体にアクセスをどう与えるか、ということです。皆さんはこの情報の蓄積、この巨大なデータレイク、これらすべての埋め込み、これらすべての情報を構築しました。これらの結果もまた埋め込まれています。それにチームがアクセスできるようにするにはどうすればよいのでしょうか？ええと、私たちのトランザクションデータについては、ご存じのように、Google Analytics から入ってくるもの、私たちのアプリケーション指標、そのすべてが BigQuery の従来型データレイクに取り込まれ、Looker で公開されています。

しかし、テキストペイロードのような非構造化のものについては、ええと、基本的には、ある意味でチームに rag モデルへ直接アクセスできるようにする必要があります。そこで、内部データ探索のための Looker に加えて、ええと、troop はシンプルな streamlet アプリケーションも導入しました。そして、このアプリで私たちが行ったことは、それを VIS と私たちのdocument store に直接向けただけです。そうすることで、チームが thetext ペイロードに対してアドホッククエリを実行でき、実際に、つまり、ええと、embedding store から情報を取り出して独自のカスタム rag パイプラインを作り、ええと、現在の主要な foundation model の一つで独自のプロンプトを作成できるようになっています。ですので、ええと、つまり、この Streamlet アプリケーションは、VIS と data lake など他のすべてが立ち上がった後では、ええと、このアプリケーション全体を組み上げるのにおそらく午後いっぱい程度しかかかりませんでした。ええと、これをどのように行ったかについては、通話の後で皆さんと喜んでお話ししますが、ええと、皆さんのほとんどは、もし何らかの、つまり、フロントエンドチームがいれば、かなり素早くこれをハックして作れるのではないかと思います。実際、コードの大部分は、ええと、Streamlet をセットアップするには Python を知っているだけでよく、フロントエンドは無料で付いてきます。

ですので、ええと、これを行うことを強くお勧めしますし、これは vis を単なるデータパイプライン用のツールから、実際に社内チームに公開されるものへと変えたようなものです。そして最終的にはユーザー向けにもなるものだと思います。ただし、プロダクトの観点からは、まだ完全にはそこを固めきれていません。さて、それでは、ええと、Steph、troop について、そして私たちが novis をどのように使っているか、ええと、特に embeddings を使って私たちのテキストコーパスを基本的に圧縮し、理解し、機械レベルや検証済みラベルを作成し、ええと、下流のファインチューニングや、そして、ええと、機械学習プログラムのようなものを支えている方法について話す機会を招待してくれてありがとうございます。ですので Steph、そして視聴してくださった皆さん、ありがとうございます。

ありがとう Jen。プレゼンテーション、本当に感謝します。ええと、これから q and a に入ります。ええと、Zoom バーの下部に質問を貼り付ける感じでお気軽にどうぞ。ええと、質問が入ってくるかを見るために数分取りましょう。

わかりました。ええと、最初の質問です。ええと、米国における価値観の多様性を考えると、使用している embeddings や LMS のバイアスを心配していますか？質問は、多くの異なるタイプの人々がいることを考えると、LLMs や embeddings にバイアスがあることを心配しているか、ということです。ええと、これは実は私たちのチームがかなり頻繁に話し合っていることです。ええと、そして私たちがこのために投入している作業の多くは実際に、ええと、grounding のような手法を使うことや、ええと、先ほど述べたように、人間による検証を取り込むことです。そうすることで、実際に、ええと、特定の視点に答えられるように、ええと、これらのモデルをファインチューニングし、トレーニングできます。例として、このプロジェクトの初期に私たちが行ったことの一つは、私たちの、ええと、l m と embeddings エンジンが、実際に米国の政治的価値観のスペクトラム全体を表現できるようにすることでした。そして、ええと、私たちはそれぞれのペルソナにおける成功と精度を互いに独立したものとして考えています。

そのため、私たちはそれを優先しています。要するに、はい、私たちはそれを非常に重視しており、バイアスを心配しています。ええと、しかし、モデルをファインチューニングして、さまざまな価値観に対応して語れるようにすることができています。いいですね。ええと、他に質問があるか見てみます。ええと、chat Streamlet app のあなたのバージョンを公開したり、ユーザー向けにしたりすることはありますか？ええと、はい。

先ほど構築した streamli app について述べたように、ええと、多くのデータツールにとって chat はぎこちないインターフェースになり得ると思います。例えば、ユーザーの前に chat インターフェースを置いても、何を聞けばよいのかさえ分からないことがあります。ですので、ええと、私たちはまず社内ツールとして始めています。なぜなら、社内チームは非常に集中していて、何を聞くべきかを分かっているからです。troop の将来バージョンで、アセットマネージャーが顧客に関する情報を収集するための chat インターフェースがあることは 100% 想像できます。ええと、そしておそらく私たちのような一般投資家が、スケールした形でアセットマネージャーとやり取りするためのものにもなるかもしれません。

ええと、それは私たちが話していることで、もし一般の方々が私たちにstreamlet appを公開してほしいと思うなら、ええと、真剣に検討します。ええと、そして喜んでそうします。ええと、たとえば、今参加している方や、そうしたものを作ろうと考えている方がいるとしたら、何か共有したい具体的なコツはありますか？ええと、すみませんStephanie、もう一度言っていただけますか？ああ、ええと、実はここに別の質問が見えます。ええと、ドキュメント全体にわたる大量のデータやvectorstoresからのマッチングにはどのように対処していますか？トークンの制限はありましたか？Lancing、L l m、ええと、要約には限界があります。ええと、l l mではそうだとこの方は言っているのだと思います。

はい。ええと、Vincent、質問ありがとうございます。はい、まったくその通りです。ええと、それは難しい問題です。troopが構築したソリューションの方法は、hello worldの例からは少し外れているかもしれませんが、問題を複数のステップに分解することだと思います。

ではステップ1として、たとえば100ページのP D Fがあるとしますよね？そして、P D f内のどこか未知のページから抽出しようとしているものの種類が一般的には分かっているとします。解決策の一例は、実際にすべてのページを順番に見ていくことです、そうですよね？そして、そのページ内のトピックのミニ抽出を取り出します。つまり、これはmap produce問題のように考えることができます。各ページを取り、それをより小さな量のデータにマップする、あるいは各チャンクをより小さな量のデータにし、それに対して抽出を実行します。そして、その後、ええと、これを反復的に行い、はるかに小さな要約に絞り込むまで続けます。そして各ステップで重要なのは評価手法です。

つまり、どのように、ええと、要約の有効性を評価するのかということです。なぜならおっしゃる通り、Vincent、要約には限界があり難しいからです。ええと、Novusでembeddingsを使う本当にクールな方法の一つは、圧縮されたデータの結果を単に埋め込み、それをソース資料、つまりソース資料のembeddingsと比較することです。ですから、embeddingsが非常に似ていれば、ソース資料に含まれていた概念の大部分を抽出でおそらく捉えられているということになります。ええと、そして実際により大きなものを見ると、たとえばllama and indexがちょうどこれについて講演していましたが、ええと、モデルを評価するためにembeddingsを使うことは、ますます人気のある手法になっています。ええと、これがVinceの質問への答えになっていればと思います。

ええと、それでは、ええと、ここにある次の質問は、AIによるパーソナライゼーションが今後数年で金融や資産運用をどのように変えると思いますか？というものです。私は、私たちが金融と関わる全体のあり方がひっくり返ろうとしていると思います。ええと、それは非常に、消費者体験のような体験から来ていて、つまり、平均的な人は金融の世界で何が起きているのかをあまりよく知らず、特に私たちのビジネスでは、ええと、株主総会で何が起きているのかについてそうです。私たちが会う人の中で、投票資料を読んで、今後の株主総会で何が取り上げられるのかを理解している人はほとんどいません。ええと、ですから、何が起きているのかを把握し、あなたに代わって正しい選択をするのは、asset stewardship teamと呼ばれるチームに大きく依存していました。AIによって、パーソナライゼーションの機会は素晴らしいものになると思います。なぜなら、実際にあなたのお金を管理する人たちとその背後にいる投資家との間で、ある種の自動化された会話やデータ交換を大規模に行えるようになるからです。

そして、troopが注力しているガバナンスの世界だけでなく、より広い資産運用と金融の世界においても、私たちは、競争上の切り口、つまり自分たちを売り込む方法が「あなたのためのパーソナライゼーション」であるような製品を、これからもっと多く目にする世界に向かっていると思います。そして、そのすべてがAIによって可能になると思います。ビジョンを共有していただきありがとうございます。ええと、ここにさらに質問はありますか？ええと、確認します。ええと、もしこれ以上質問がなければ、このセッションを締めくくります。

Zen、本日はご参加いただき本当にありがとうございました。そして、このウェビナーに参加してくださった皆さんにも感謝します。Seff、お招きいただきありがとうございます。そして皆さん、ご参加ありがとうございます。ええと、私の連絡先情報は画面にありますので、ぜひご連絡ください、ええと、お話ししたい場合は。ありがとうございます。ありがとうございます。

今後も私たちとのウェビナーを楽しみにしています。ありがとうございます。さようなら。

Meet the Speaker

Join the session for live Q&A with the speaker

Zen Yui
Co-Founder & CTO, Troop
Zen is the co-founder and CTO of Troop, a corporate governance platform enabling everyday shareholders to collectively influence large corporations. Prior to Troop, Zen spent 9 years designing big data systems with Spark and Kafka for retail and healthcare industries. He holds a graduate CS degree specializing in cryptography and distributed systems from Cornell, and is passionate about data democracy and privacy.