Join the Webinar
Loading...
何を学べますか？
LLMを利用していて、データのプライバシーとセキュリティを重視していますか？その場合、検索拡張生成アプリケーションをオンプレミスでデプロイするか、データプレーンとコントロールプレーンを分離するものを使用する必要があります。
このウェビナーでは、両方のソリューションを紹介し、LLMWareやMilvusなどのオープンソースツールを使用して、RAGアプリケーションをオンプレミスでデプロイする方法を詳しく解説します。
取り上げるトピック:
- クラウド上でのデプロイとオンプレミスでのデプロイにおけるさまざまな懸念点を理解する
- ローカルの埋め込みモデルと生成モデルを使用する方法を学ぶ
- LLMWareがMilvusを使って独自のフレームワーク上でRAGアプリケーションを作成するのにどのように役立つかを見る
本日は、オンプレミスRAGデプロイメントにおけるデータ整合性の保護という本日のセッションと、ゲストスピーカーのDarren Oberstをご紹介できることをうれしく思います。彼はAI blocksのCEOであり、金融サービスおよび法務業界における生成AI向けのLLMベースのアプリケーション開発の状況を革新する、革新的なAIプラットフォームです。AI blocks以前、DarrenはExelのCEOを務め、HCL softwareを立ち上げ、5年間で売上10億以上に成長させました。Darrenは現在、検索、拡張生成、オープンソース、LLMミドルウェア、えー、LL mwareとも呼ばれるもの、そしてオープンソース向けの特殊なエンタープライズLLMモデルのファインチューニングを含む、エンタープライズLLMベースのアプリケーション構築に注力しています。Darrenは、物理学と哲学の学位を取得したUC Berkeleyの卒業生であり、Harvard Law Schoolを優等で卒業しています。
ようこそDarren Oberst。素晴らしいですね、Eugene。どうもありがとうございます。そして本日ご参加いただいた皆さん、ありがとうございます。えー、これから見ていくスライドがいくつかあります。それから、えー、できればセッションの少なくとも半分は、えー、ライブデモに使う予定です。えー、Eugeneがおっしゃったように、えー、本当にインタラクティブにしたいと思っていますので、質問があれば投稿してください。えー、必ず途中で止めて、通話に参加している皆さんにとって関心のある領域について、より多くの時間をかけるようにします。
えー、これには本当にワクワクしています。えー、私たちは、えー、visと、えー、実際のテクノロジーと、えー、過去18か月間取り組んできました。これについては本当に素晴らしい経験をしており、プライベートクラウドRAGシステムという観点で、私たちが組み立てているテックスタックの中心的な存在です。ですので、これを説明しようと思います。えー、全体的な機能のいくつかを具体的に示すとともに、特に皆さんに強調したいのは、そのアーキテクチャの一部としてBUが果たす中心的な役割です。それでは、えー、さっそく始めましょう。
えー、ですので本日の本当の目標はデモに到達することです。えー、このものを見ていきます。えー、ライブで動作しているプライベートクラウドのエンドツーエンドのRAGシステムです。えー、それを本当に動機づけるために、えー、いくつかのスライドを、えー、用意しています。えー、AI blocksについて簡単な紹介をします。宣伝は最小限に抑えますが、えー、文脈や、私たちが何者なのか、いくつかの機能についての動機づけを設定する助けにはしたいと思います。えー、これらはすべて、つまり、オープンソースの中にあるものなので、えー、皆さん自身で見に行って確認できるものばかりです。
プライベートクラウドRAGについて、いくつか動機づけを設定したいと思います。つまり、これは何を意味するのでしょうか？なぜ誰かが、えー、それをしたいと思うのでしょうか？なぜこれは、えー、興味深い方向性なのでしょうか？えー、そして、これらすべてのピースをどのようにまとめるのか、そしてそれを実際に、えー、単一のプライベートクラウド、えー、インスタンスでどのように実現できるのか、その概念的なアーキテクチャを説明するために、えー、数分使いたいと思います。えー、それから見ていくデモシナリオですが、えー、4つの異なる、えー、デモシナリオまで進めようと思います。えー、まず2つのスクリプトを実行します。これらは本当に、えー、ドキュメント解析、テキスト、チャンク化、埋め込み、そして基本的なセマンティッククエリの、えー、簡単なハローワールドタイプの例をお見せするためのものです。えー、すべて、つまり、visを使っています。そして、えー、LLM whereライブラリの中にラップされています。
ですので、その例が2つあります。えー、それらは実際に、えー、私たちのLL mware GitHub、えー、リポジトリで例として利用できます。ですので、ご自身で見に行って、実行してみることができます。ただ、ここではその2つの例をやや素早く進めます。えー、それから3つ目の例に入ります。えー、これは実際には最初の2つのシナリオを土台にしたRAGシナリオで、この場合、RAG向けにトレーニングしファインチューニングした、えー、10億パラメータの、えー、LLMを持ち込みます。
そして最後に、もし時間があれば、実際に、ええと、ある種のポップアップWebアプリを開こうと思います。ええと、それは私たちが運用してきたマルチテナントの、ええと、ご存じの、マルチスレッドの、ええと、SaaSサイトから派生したものです。ええと、そのサイトでは、ええと、実際にvisを使っていて、ええと、Kubernetesクラスター上で大規模に並列化しています。そして繰り返しになりますが、スケーラビリティの面で非常に素晴らしい結果が得られています。ですので、検索機能の一部を説明する助けとして、ええと、コンソール画面を見るより少し分かりやすい場合もあるので、皆さんに見ていただけるよう簡単なUIをお見せしたいと思いました。ですので、取り上げることはたくさん、ええ、あります。
では、ええと、まず少しだけ動機づけから始めましょう。ええと、なぜプライベートクラウドでragなのか？ええと、実際、多くの意味で、これは今日の生成AIで耳にするマーケティングや注目の多く、つまりほとんどすべてが、ええと、パブリッククラウドAPIサービスであるという状況に真っ向から反しているように思えるでしょう。では、なぜ誰かが、ええと、プライベートクラウドでこれを行うことについて話すのでしょうか？さて、一番の理由は、ええと、機密性の高いビジネス文書のデータプライバシーです。そして、ご存じのように、ある種の、あの、あの、あの、何か、あの、私たちがほとんど毎日、常に交わしている対話があり、皆さんの多くも、ええ、そうだと思います。人々はパイロット、概念実証、検証、ええ、これで上司を感心させよう、というところから始めます。
典型的にはOpenAIから始め、Pineconeから始め、ええと、ご存じのように、パブリッククラウドのデプロイから始めます。なぜなら、それは開始するための非常に速い方法だからです。しかし多くの業界や多くの企業では、それが本格的になって、私たちは実際にどのようにして、LLMを私たちのプライベートな、ご存じの、ナレッジベースに接続するシステムを構築し始めるのか、という段階になると、データプライバシー、データガバナンス、企業のセキュリティゾーンの外にそれらの文書を移動することの機密性に関する問題が最重要になります。ですので、ひとつお話しすると、これは私たち皆がたくさん持っているような話だと思いますが、ええ、私たちは実際、ええと、数週間前にパネルに参加していました。ええと、ある非常に上級の、ええ、銀行の幹部が、ご存じのように、chat GPTに何ができるか、GPTが主導しているその革命について、その利点を本当に熱心に称賛していました。そこで私たちは、そのセッションの後に、この幹部を捕まえて、こう言いました。ご存じですか？感触を教えてください、つまり、あなたの組織の内部では何が起きているのですか？つまり、皆さんはこうしたものを一部展開しているのですか？すると返ってきた答えは、まあ、私たちの金融機関の内部では、何も私たちのセキュリティ領域から出ることはありません、以上です、というものでした。ですから、LLMベースの技術を実際に展開する場合には、何らかの形のプライベートクラウドでなければなりません。そして繰り返しになりますが、その方法はいろいろあります、いわば猫の皮を剥ぐ方法はいろいろあるということですが、しかしそれは安全なものでなければならないのです。
この金融機関が、ご存じのように、重要なビジネス文書、契約書、規制情報、研修資料、HR情報、顧客関連情報、PII関連データを送信することはあり得ません。それがパブリッククラウド上に出ていくことは絶対にありません。私たちが耳にする2つ目の主な理由、ええと、そしてこれは、ええと、本当に2023年の素晴らしいストーリーのひとつだったと思いますが、オープンソースのイノベーション曲線がまったく驚異的だったということです。ええと、それは私の人生で思い出せる中でも最も革命的な出来事のひとつです。ご存じのように、ソフトウェア業界で働いてきて、ええと、1年前のオープンソースがどこにあったかと今日を見比べると、実に信じられないほどの曲線です。ほぼ月単位でオープンソースとして展開され、デプロイされている技術の種類、基盤モデルの種類という点で。
ええと、改善に改善を重ね続けるテクノロジーがあります。そして、ますます多くのお客様から聞こえてくるのは、そのイノベーションの曲線を土台にして構築できるようになりたい、ということだと思います。彼らはプロプライエタリなテクノロジーに縛られたくありません。ええと、そしてオープンソースには、それをカスタマイズでき、自分たちのものにできる可能性があるとも見ています。そして、誰もが、LLMが何を意味するのか、生成AIが何を意味するのかを理解し始めるにつれて、私たちはますます多くの企業が、これを完全に外部委託したくはない、と言うのを目にしています。
実際、私たちはこれを、自分たちの未来に不可欠なもの、自分たちの差別化の一部、お客様や従業員に提供したい能力の一部になるものとして見ています。私たちはそれを自分たちのDNAの一部にしたいのであり、オープンソースモデルが私たちに可能にしてくれるのは、それをカスタマイズし始めることです。そうするとAIは、他の誰かのAIではなく、本当に私たちのビジネスに固有で、プロプライエタリなAIになります。ええと、3つ目の大きな理由は、ええと、コストです。さて、企業におけるLLMや生成AIには素晴らしいユースケースがたくさんありますが、このAPIを呼び出すたびに支払いが必要だと考えると、意味をなさないものがあります。
また、1,000億を超えるパラメータを持つモデルについて考え始めた場合にも、意味をなしません。今日お見せするモデルのコストは、つまり、推論ベースで10億から70億の範囲にあるものですが、おそらく100倍安いです。実際、実際にデプロイするには数百倍安いかもしれません。そうすると、プライベートクラウドにデプロイできるより小さなモデルについて考え始めると、今日実際に実現可能な一連のユースケース全体が実用的になり始めます。ええと、ちょっと、ここで少し止めたいです。
これについて、皆さんが行った、あるいは見た研究のリンクはありますか？というのも、それは実際とてもすごいことで、コストがそれほど大幅に低いということなので。ええと、それを共有できるようにしたいです。もちろんです。ええと、それについては、数枚後のスライドで触れます。実際にご案内します。つまり、あなたは、ちょうど完璧に話を振ってくれました。
実際に、私たちのGitHubリポジトリをお見せします。Hugging Face上のランディングページもお見せします。そこはまさに、モデルや、モデルに関するいくつかのベンチマーク、そしてこれらのトピックについて投稿してきた一連の記事や動画がある場所です。完璧です。わかりました。ええと、次に、今日デモを見る中で、私が本当に強調したいテーマの1つになると思います。
RAG、検索拡張生成です。検索があり、生成があります。そして、RAGシステムを構築することについて本当に考えるとき、私たちは生成側にあまりにも多くの焦点が当たり、検索側には十分に焦点が当たっていないと考えています。もし検索を正しく行い、インデックス化やテキストのチャンク化の方法、適切なタイプの埋め込みモデルの適用、それをベクトルデータベースに入れるという点で優れた検索戦略を持っていれば、適切な検索メカニズムが多くの重みを担うことができます。逆に、適切な検索がなければ、世界中のあらゆる生成AIがあっても、必ずしも優れた事実ベースのRAGシステムを提供してくれるわけではありません。
ですから、またそうした話として、人々が、まあ、GPT-3.5ではRAGには十分ではないかもしれない、と言っているのを聞きます。ドキュメントに質問しようとするとき、GPT-4やGPT、つまり4.5、あるいは将来登場する何かが必要なのかもしれない、と。私たちの経験では、ほとんどの場合、それは生成AIの問題ではないと思います。
それが問題です。それは、ええと、検索戦略の両方を正しく整えること、つまりそのコンテキスト情報のパッケージングにあります。その部分を正しくできれば、多くの場合、はるかに、はるかに小さいモデルでも同じ結果、あるいはほとんど同じくらい良い結果を得ることができます。ただし繰り返しになりますが、今日の例でそのいくつかをお見せする予定です。ええと、そして最後に、ええと、私たちは、rag をエンタープライズに持ち込むことは、エンタープライズを ai の側に持ち出すことではないと本当に考えています。
本当にその逆である必要があります。AI がエンタープライズのプロセス、エンタープライズのワークフロー、そしてエンタープライズの知識に組み込まれる必要があります。プライベートクラウドでそれを行うことを考え始めると、この全体像によって、企業が日々実際に運営される方法に AI を統合し始めることがずっと容易になります。さて、Dragon とは何でしょうか？ええと、Dragon については、たくさんの画像などが入ったかなり良い動画がいくつか公開されていますので、ぜひ見てみることをお勧めします。ええと、では Dragon とは何でしょうか？ええと、dragon は、私たちが展開した一連のモデルです。
ええと、私たちはそれらをローンチしたばかりで、たしか今から約3週間前です。ええと、これらはすべて、hugging face 上の私たちのリポジトリに公開されているモデルです。ええと、dragon は実は、かっこいい名前であることに加えて、Rag を提供するという意味でもあり、ええと、私たちがローンチしたモデルシリーズで、7つのモデルを構築しました。ええと、その7つのモデルは rag ファインチューニングであり、それが何を意味するかはすぐに説明しますが、主要な6および7 billion parameter foundation models の7つです。さて、私たちが実際に行ってきたことは、過去数年の間に、ええと、契約書、規制文書、複雑な金融、ええと、ニュースや情報に関する、事実ベースの質問応答を備えた、かなり大規模な、ええと、独自の自己キュレーション・自己開発の、いわば bespoke dataset と、非常に具体的なタスクとスキルのセットを構築してきたことです。
そして私たちはこのデータセットを構築し、その後、ええと、これらすべてのモデルをファインチューニングしました。そして私たちが提供しているものは、ええと、私たちのリポジトリ内の一式です。そして繰り返しになりますが、先ほど出た質問に関連して、たぶんその画面に切り替えましょう。モデルがどこにあるかをお見せできます。私たちは、非常に始めやすい、ええと、生成スクリプトを提供しています。
私たちは、つまり、LL Mware がこれらに本当に第一級の、ええと、サポートを提供するという点で、かなりユニークなことを行ってきました。私たちが、多くの open source models で見てきたことの一つは、問題がモデルそのものではない場合があるということです。問題は、その周辺の、いわばラッパーコード、Lang Chain や LAMA index、あるいは使用しようとしている LL Mware コードに、そのモデルを本当に輝かせるための組み込みの機能や細かな仕組みが十分に備わっていないことです。ええと、そのため、モデルをワークフローに完全に統合するために必要な作業量が、open AI や anthropic の場合に比べて、はるかに多くなってしまうことがあります。ええと、そして最後に、私たちはこれらすべてをベンチマークしました、ええと、ただし MLU ml、MMLU、a RC、heli swag のようなものではベンチマークしていません。
繰り返しになりますが、もし、もし、もしご存じであれば、Hugging Faceの、ええと、LMMリーダーシップボードには、世の中に非常に多くの科学的指標があります。しかし、私たちが常に尋ねられる重要な質問は、まあ、これは機能するのか、ええと、自分が持っている特定のワークフローに対して信頼できるレベルの精度を提供してくれるのか、ということです。ええと、完璧である必要はありません。100%である必要もありませんが、それが90%正確なのか、98%正確なのかについて、何らかのベースライン評価が必要なのです。そして、どのような状況で成功する可能性が高いのか？どの領域ではそうではないのか？そこで私たちは、いわゆる常識的な、ええと、RAGと構造化ベンチマークを構築し、これらのモデルのひとつひとつに対してこれらのテストを実行し、その結果をすべて公開しました。ですから、モデルの1つを選べば、どのようなユースケースで、どの程度の精度が得られそうかについて、かなりよく把握できます。しかし最も重要なのは、もし、もし本当に本番グレードのシステムを構築することを考えているなら、つまり、RAG a Llamaの観点で本当に意味のあることをしようとしているなら、ということです。
いや、それがあなたの望むものなのかは分かりません、赤いパジャマ。私はそれが何なのかさえ分かりません。Falconはちょっとかっこいいですが、最終的に必要なのはドラゴンです。ドラゴンは炎であり、ドラゴンは究極のチートコードです。Game of Thronesを見たことがある人なら誰でも、あのドラゴンたちは最終的に、まあ、そこにいる最強の存在だと分かるでしょう。
ええと、だから私たちは、それは、ある種、クールなブランディング方法だと思いました。私たちの本当の志は何かというと、最高のプライベートクラウドを構築したいということです。つまり、70億以下のパラメータモデルを、すべてオープンソースで公開し、人々が本当に高品質で最先端のRAGシステムを、ええと、より低コストで、すべてオープンソースで、すべてプライベートクラウド上で構築できるようにしたいのです。ええと、わかりました。これは、尋ねられた質問の1つに入る良い流れですね。ええと、プライベートクラウドとパブリッククラウドについて話すとき、その違いが何なのか明確にしてもらえますか？もし誰かが自分のプライベートクラウドでNovusを使っていて、LLMとしてOpenAIを使っている場合、そのAPIリクエストはパブリッククラウドを使用していると見なされますか？ええと、そして、ええと、どのようにそうなのですか？つまり、どの時点であれ、情報が企業のセキュリティゾーンの外に出ている場合、少なくともこの会話の文脈では、それを引用符付きで、パブリッククラウドのユースケースと見なしています。
ええと、そして繰り返しますが、想像してみてください、例えば、そして、これから見ていく例の1つですが、ええと、いくつかの契約書を取り、それらの契約書を解析し、テキストチャンク化し、埋め込みし、重要な契約条項をコンテキストにパッケージ化して、それをOpenAIに送信するとします。実際には、ほとんどのユースケースでは比較的安全でしょう。うんうん。しかし、それはパブリッククラウドのユースケースです。ですから、私たちが話そうとしている状況は、LLMモデルを含め、すべてがプライベートクラウドの文脈で実行されるということです。
ですから、デモに進んだときに実際にお見せするのは、文字通り、LLMモデル、埋め込みモデル、ええと、Visまで、すべてが1台のサーバー上で実行され、そのサーバー上のワークフローが、ええと、プライベートクラウドの、ええと、インスタンス上で実行されているというものです。いいですね。わかりました。とてもいいですね。ありがとうございます。
他に質問はありますか？その時点で触れておくとよいと感じたのはそれだけでした。では、ええと、続けていただきましょう。いいですね。いいですね。ええと、Dragonについては触れましたが、ええと、Dragonは、私たちが本番グレードのモデルだと信じているもののシリーズです。
ええと、それらは単一のGPUインスタンス上で動作します。ええと、そして繰り返しになりますが、Q&Aや議論の過程で、そのことについてもう少し話します。しかし、私たちが構築したものでもう一つ、非常に大きなギャップがあると分かったのは、ええと、CPU向けの、ええと、推論モデルです。ええと、非常によくあるシナリオとして、先ほどの質問に戻ると、そのアプリケーションを本番環境に実際に展開する準備ができたとき、データの機密性によっては、パブリッククラウドモデルを実際に呼び出す形で問題ない場合もあります。そして、その本番アプリケーションが展開される前に行われる可能性のある、さまざまなレビューについて考えることになります。しかし、テストや迅速なプロトタイピングでは、ええと、きっと皆さんの多くは、クライアントと仕事をしていたり、コンサルティングのような役割に就いていたりすると、ええと、クライアントは非常に突飛でクレイジーなアイデアをたくさん持っているものです。
ねえ、これは動くの？ねえ、このタイプのシナリオで、このタイプのドキュメントの場合、結果を得られるの？これは私のプロセスを自動化できるの？これは良いユースケースなの？そこで私たちがblingモデルで作りたかったのは、これは最高の小型の、ええと、GPU不要のinstructモデルで、実際にはinstruct学習済み、ragでファインチューニングされた質問応答モデルであり、ラップトップ上で推論を実行できます。そしてデモでは実際にそのうちの1つをお見せしますが、パラメータ数は10億から30億です。ええと、そして繰り返しになりますが、それらはすべてベンチマークされ、スコアリングされています。そして私たちが考えていることの一つは、blingモデルでいくつかの簡単なテストや迅速なプロトタイピングを実行できるということです。そして本番環境に移行するとき、必ずしもそのOpenAIモデルに行く必要はありません。
同じワークフローで、プライベートクラウドの、たとえばdragonモデルに行くことができます。やることは単にモデル名を変更するだけです。そして最後に、私たちが展開した最後の、ええと、モデルファミリーは、デモで見ることになりますが、ええと、industry Burtです。そして、これらは私たちがファインチューニングした、ええと、sentence transformerモデルです。実際に見ていく例は、契約向けのindustry burtです。
そして私たちはまさにそれを行いました。ええと、私たちは、何千もの契約書で、ええと、モデルをファインチューニングしました。ですから、契約に関するいくつかの用語や言語に対して、少しより細かくチューニングされています。繰り返しになりますが、それを少し具体的に理解していただくために、例をお見せします。つまり、これらがモデルファミリーのようなものです。
それらはすべて、ええと、hugging faceで利用できます。ええと、これをどこで入手できるかという質問についてですが、私は、私はここで少し立ち止まって、可能であれば私たちの、ええと、リポジトリをお見せしようと思います。おっと、すみません。はい。これはモデルの一例です。
皆さん、hugging faceが見えているといいのですが。ええと、hugging faceの、ええと、LL Mwareリポジトリを見に行きたい場合は、そこにあります。ええと、hugging face上で、これはモデルカードの一つです。これは実際に私たちがロードしたモデルの一つです。ええと、Dessiは私たちのパートナーの一つです。
私たちは別のウェビナーを行いました。ですから、私たちは常に、ええと、パートナーを宣伝するのが好きです。ええと、これは私たちがragでファインチューニングした、60億パラメータのモデルです。モデルカードで見えるのはすべての情報であり、ベンチマークテスト、精度、ええと、そしてリポジトリに含めているものとしては、テスト結果、つまりこれらの回答シートと、サンプルスクリプトの両方があります。ですから、モデルを使い始めるためのhello worldを行う素晴らしい方法として、ええと、これらの生成スクリプトを実行できます。そうするとテストが実行されます。
ええと、ですので、質問がある方や興味のある方には、ここにさらに多くの情報があります。ただ、今お話ししたすべてのことは、私たちのLL Mware組織ページで見つけることができます。これらは、こうした小規模モデルのいくつかの利点や、さまざまな検討事項、トレードオフについて述べている私たちのブログの一部です。そして、私が言及した、ええと、3つのモデルファミリーに関するコレクションも見ることができます。では、ええと、ここでプレゼンテーションに戻りますが、ええと、LL Mwareとは何でしょうか？ええと、繰り返しますが、これについて大きな宣伝をしたいわけではありません。ええと、これは私たちが公開したライブラリです。
ええと、繰り返しますが、GitHubではLL Mwareとして見つけられます。ええと、これは何かというと、簡単に言えば、lang chainやLAMA indexのようなツールキットで、ええと、完全にオープンソースですが、今まさに話してきたようなものを中心にインデックス化されています。ええと、これは本当に、企業向けワークフロー、ええと、大規模にスケールするドキュメント取り込みのために設計されています。そして繰り返しますが、それはアーキテクチャの中で強調します。ですので私たちは独自の、ええと、Cベースの、ええと、ドキュメントパーサーをゼロから構築しました。ええと、PDF Word文書、PowerPoint、Excelの仕様を完全に実装しています。
そして考え方としては、もし本当にこれを企業で展開したいなら、数千、数万、数十万のドキュメントという問題に向き合うことになります。それを並列化し、複数のワーカーに分散できる必要があります。ですので、私たちが本当に最初に注力してきたのは、ご存じの通り、大規模にスケールする、ええと、ドキュメント取り込みです。ええと、私たちは永続的なデータストアを備えたエンドツーエンドのデータモデルに注力しています。ええと、つまりvissはLL Mwareに関するあらゆるユースケースで登場します。また、私たちのパーサーにはMongoDBも統合して使用しています。ええと、s aex、chunker、そしてテキストコレクションインデックスです。
そして私たちの本当の優先事項は、ええと、オープンソースモデルを使ったLLMベースのアプリケーションを構築するためのフレームワークを作り上げることです。これは後付けではなく、本当に基盤としてのものです。ですので私たちは、幅広いオープンソースおよびhugging faceモデルをサポートするために、新しい機能や能力を継続的に構築しています。そして本当に、ええと、先ほど議論したモデルを先頭に据えています。始めるのは非常に簡単です。そして繰り返しますが、今日の議論の中で、ええと、そのいくつかを取り上げる予定の例がたくさんあります。
さて、これでさまざまな要素を一通り設定したので、それをすべてまとめたいと思います。つまり、プライベートクラウド、エンドツーエンドの真のプライベートクラウドがどのような概念アーキテクチャになるかを示したいと思います。すべてが箱の中にある、ええと、そのアーキテクチャがどのようなものになるかです。そしてその後、切り替えて、実際にその中でいくつかのデモを実行し始めます。よろしいですか？概念的にどこから始まるかというと、ええと、取り込みです。
ええと、先ほど言ったように、LL Mwareの一部として、ええと、私たちは独自の、ええと、パーサーをパッケージ化しています。ええと、それらは本当に高速で、その例を、ええと、ご覧いただきます。また、そのドキュメントから収集するメタデータの豊富さと、そのメタデータの一貫性という点でも非常に高品質です。そのメタデータを、検索、つまりretrie retrievalの観点でデータパイプラインを下っていく際に、かなり広範囲に利用できます。そして最終的には、何らかのLLM呼び出しを行った後に、そのメタデータを引き戻して、どこがソースだったのか、そのソースに関する具体的な情報は何だったのかを特定できます。ええと、先ほど述べたように、パーサーは、ええと、MongoDBのテキストコレクションと完全に統合されています。私たちはテキストのチャンクを抽出し、最終的にそのデータベースに格納します。
そして繰り返しますが、それは例の中でご覧いただきます。ええと、VUSベクトルおよびデータベースは、このデモシナリオで使用する、ええと、この概念アーキテクチャの中核になります。ええと、小規模で特化した、オープンソースモデル、ええと、この目的のために私たちがファインチューニングしたindustry Bertモデルです。そしてLLMには、blingモデルも使用しているDragonシリーズを使います。ですので、embeddingsを実行する際のこの流れとして、すべての情報はテキストチャンク化されます。
これは業界向けのbird埋め込みモデルを通過し、その後それらすべてのベクトルが、ええと、VUSsの、あー、データベースに保存されます。そして概念的な観点から見ると、ええと、最終的にはすべてがクエリまたはプロンプトのいずれかに行き着きます。これらがあなたがやり取りする主要な2つのクラスです。ええと、LL Mware内では、この作成されたナレッジインフラストラクチャをクエリするか、または何らかのタイプのプロンプト呼び出しを実行し、ええと、LLMを呼び出すことになります。そして通常はその2つの間で何らかの相互作用が発生します。そして最後に、このデモで私たちが行うことは、ええと、少しユニークなのですが、ええと、実際にこの全体の、あー、インフラストラクチャを、ええと、ご覧の通りすべてオープンソースのツール群ですが、それをNvidiaの、あー、A10、あー、チップ上に配置しました。これはGPU RAMの、24ギガバイトのRAMを備えています。
そしてこれは実際には、あー、このケースでは、AWSの、ええと、AMIを使用します。これはEC2インスタンスで、G5 4X largeです。ええと、標準のLinux上で実行されます。標準で、ええと、Nvidiaの、ええと、A10チップが搭載された状態で提供され、そこに私たちがロードしたものがあります。それから私たちが行った唯一のことは、ええと、LL Mwareライブラリを取り込み、それからいくつかの、ええと、サンプルコードを取り込んだことです。これが、あー、セットアップです。
ここで少しだけ止めて、デモに移って見始める前に、アーキテクチャについて何か質問があるか確認します。はい。ええと、質問があります。LL Mwareにはどの埋め込みモデルが使われていますか、またデータ取り込みのベンチマークはありますか？速度についてです。ではそれをご覧いただきます。
ええと、私たちは2つの、ええと、埋め込みモデルを使います。ええと、1つは、1つは、ええと、標準の、ええと、sentence transformerです。それをご覧いただきます。つまり、性能はかなり速いと思います。そしてもう1つは、ええと、industry Bertモデルを使います。これは、あー、基本的には標準的なBertで、110百万の、ええと、パラメータを持ち、私たちが契約書でファインチューニングしたものです。そして繰り返しますが、実際にリアルタイムでいくつかの埋め込みを実行するのをご覧いただきます。ええと、私たちは埋め込みに関する性能ベンチマークは行っていません。
その多くは基盤となるハードウェア、ええと、インフラストラクチャに依存します。ですので十分なハードウェアを投入し、埋め込みジョブを並列化できれば、ええと、驚くほど高速に実行できます。ええと、ここで見るのは単一サーバー上で実行されているものだけで、時間も表示されますので、そして、どのくらい速いかをざっくり見積もることができます。ええと、でもそうですね、実際にご覧いただけます。いいですね。
私も質問があります。ええと、なぜ2つの埋め込みモデルを使うのですか？それはここで行います。ええと、本当に単なる説明のためで、ええと、そして、これはおそらくデモを少し設定することになります。ええと、私たちは2種類の、ええと、ドキュメント、ソースドキュメントを見ていきます。ええと、1つは国連決議、United Nationsの決議のセットです。
それは約2年分のそれらの決議です。各決議はたぶん3、4ページから15または20ページ程度で、あー、その週にどれだけ議論する必要があったかによるのだと思います。そしてさまざまな事柄があります。それはUnited Nationsが、ええと、まあ、決議した内容です。ええと、たとえば、戦争と平和の問題についてかもしれません。
環境や社会正義に関する問題かもしれません。ええと、United Nationsが関与する任意の数の事柄であり得ます。それらは500のPDFドキュメントです。ええと、かなり汎用的な、ええと、範囲です。ですので、私たちは汎用的で小型かつ高速な埋め込みモデルを使います。なぜならそれで良い結果が得られるからです。
ああ、では次に使う2つ目は、ええと、契約書です。そして、約80件の、ええ、契約書をダウンロードします。それについては、契約書や法律文書向けにファインチューニングしたモデルを使います。ええと、その業界ドメインに対してファインチューニングを行うと、その業界ドメインに独自の、ええ、側面がある場合、全体として、検索の精度と品質の面でメリットが得られることがわかっています。そしてまた、実際にそれを強調してみたいと思います、つまり、例の1つで。
では、なぜ異なる埋め込みモデルを使うのでしょうか？それは、実質的に異なるドメインのライブラリやコレクションを見ることになるからです。そのため、そのドメイン向けに埋め込みモデルのファインチューニングを始められる場合、通常はより良い結果を得ることができます。はい。とてもいいですね。ありがとうございます。
では、皆さん準備はいいですか？準備できています。では、デモに切り替えましょう。ええと、言っておくと、これは2台、同一構成の2台のマシンにセットアップしてあります。ですので、最初の1台で何か問題が起きた場合に備えて、ええ、確認できる、ええ、ええ、ええ、フォールバックがあります。これがそのマシンです。
ええと、これは先ほどお話しした、ただのEC2インスタンスです。これは、ええ、AWS上の、ええ、Linuxサーバーです。起動時間や、ええ、EBSが、いわゆる、ウォームアップされるところや、その他もろもろは省略しました。ええと、ただ、やりたかったのは、ええ、この3つの、ええ、Pythonファイルを順に見ていくことで、ええ、少なくとも1つはすぐに開いて、皆さんにコードの、いわばレシピに慣れてもらおうと思います。そして最初に見る例は、このUN決議のものです。
そして繰り返しになりますが、ええ、これからお見せする内容について、皆さんにはっきりさせておくと、これはすべて、その概念アーキテクチャをこの単一の、ええ、AWSインスタンス上にロードしたものです。visがあり、Mongoがあり、すべての埋め込みモデルがあり、すべてのLLMモデルがあります。これから行うのは、1回限りの取り込みです。つまり、ここに取り込まれるものはいくつかありますが、情報が取り込まれた後は、実際には何も外に出ません。ですので、裏側でAPIコールは発生していません。
皆さんが見るものはすべて、実際に、ええ、このマシン上で実行されています。ええ、2つ目に言っておきたかったのは、この例は、ええ、私たちのGitHubページの、ええ、リポジトリに掲載されています。ええ、Eugeneが言及したように、私たちは、ええ、visと一緒に、オープンソースコミュニティを促進する、いわゆる25日間の、ええ、ハッカソンのようなものに参加しています。これらは、数分で始められて、ええ、L Mwareやvisを使ってかなりクールなことができるサンプルスクリプトのいくつかです。ですので、皆さんが少しでも、少なくともコードのロジックに慣れられるように、ええ、これを手短に見ていきますが、うまくいけば、少なくとも皆さんが、ええ、まず私たちが何をしているのかを理解する助けになると思います。
ええと、申し上げたように、この場合、使用する埋め込みモデルは、標準的な既製のオープンソースのsentence transformerモデルです。これはmini Burtです。ええ、時々、もっと大きく、もっと大きく、もっと大きいものが必要だと考える人がいます。実際には、このmini lmm expertは、私たちにとって多くのユースケースで頼りになるモデルだとわかっています。小さく、速く、そしてかなり優秀だからです。ですので、一般的な概念実証としては、実際のところ、悪い出発点ではないと考えています。
また考えてみると、ええ、繰り返しますが、VUSがこの分野の専門家ですが、非常に大規模な埋め込みセットを持つ、本当に、本当に大きなコレクションを構築するのであれば、少し小さめのモデルで、少し小さめの次元数を持つものには、ええ、そのシステム全体の長期的な運用管理という点で、実際に非常に実用的な利点がたくさんあります。とにかく、ここではmini、ええ、LM expertを使います。ええ、milsは当然、私たちのデータベースになります。ええ、出発点としては、新しいライブラリを作成するだけです。これにより、ええ、L mware内に構造がセットアップされます。それから、公開バケットに置いてあるこれらのサンプルファイルをダウンロードします。
ですから、これを実行すると、ええと、これを、つまり、pip install L mware を実行して、このセットアップを実行すると、実際には、えー、これらすべてのサンプルファイルをローカルのフォルダ構造に取り込んでくれます。さて、このステップは解析のステップです。これらのファイルをすべてローカルにダウンロードしたら、パーサーは実際には非常にシンプルなインターフェースで動作します。ライブラリにファイルを追加するだけです。その1行が実際に何をしているかというと、えー、個々のドキュメントをファイル拡張子に基づいて基盤となるパーサーにルーティングしています。
それはテキストチャンクとして解析し、すべてのメタデータ、テーブル、画像を抽出し、それをテキストコレクションに入れます。ですから、このステップが、えー、これら500件のドキュメント全体にわたって展開されていくのが見えるはずです。それから、新しい埋め込みをインストールするための、えー、非常にシンプルな、えー、インターフェースもあります。これを、そのモデルに適用します。えー、それを、えー、vus に入れます。
Status Manager は非常に大規模なアプリケーションでとても便利です。大規模な、えー、埋め込みや解析ジョブの進捗をリアルタイムで把握するためにポーリングできます。そしてそれが終わったら、ここでシンプルなテストクエリを実行します。えー、もちろん、このすべての本当の面白さは、セマンティック検索を行って、あらゆるものを抽出し、本当にクールな検索を行うことにあります。ここでは、それを説明するために、えー、シンプルな例を1つだけやります。それは、女性に影響を与えるサステナビリティ課題に関するサンプルクエリです。これもまた、適切な概念型のクエリだと考えています。多くの場合、完全一致検索では失敗したり、適切な結果が得られなかったりするところだからです。サステナビリティ課題のようなものには、えー、多くの概念が関わっているからです。
そしてそれを画面に出力します。それだけです。では、先に進んで、えー、実行してみます。取り上げたい例が3つあります。なので、うまくいけば、うまくいけばサーバーがスリープ状態になっていたりしないといいのですが。よし、始めましょう。
えー、解析中です。えー、解析ステータスマネージャーが、10ドキュメントごとに、えー、この更新を出力しています。えー、これは単に、コンソールに送っているだけでなく、えー、データベースにも送っています。ですから、えー、これら500件のPDFドキュメントが見えます。繰り返しになりますが、平均で数ページ、長さはおそらく最大で15ページか20ページです。これらのドキュメントのうち200件を解析しました。えー、すべてリアルタイムでです。そのすべての情報がローカルで、えー、この、えー、サーバー上で動いています。
ですので、これらを、えー、どんどん処理し続けます。すべての解析が終わったら、次に、えー、埋め込みを開始します。解析で起きていることは、500件すべてのドキュメントが解析されているということです。それらは小さなテキストチャンクとしてもパッケージ化されています。そのテキストチャンク、個々の各テキストチャンクが最終的に、えー、埋め込まれることになります。
完了しました、えー、50秒、1秒あたり約10ドキュメントです。そして今、埋め込みを実行していて、埋め込みを500テキストチャンクずつ渡しています。合計で約12,000、えー、チャンクあるのが見えますが、非常に速く進んでいます。さて、12,000というのはまだかなり小さなライブラリですが、これによって、単一の、えー、マシン上で、えー、これらすべてがローカルに動いている感覚をつかんでもらえるといいと思います。500件のドキュメントをどれだけ速く解析したか見てください。それを埋め込み、最初のクエリを実行したところです。
すごい。このサンプルコードとこのサンプルスクリプトは、私たちのリポジトリにあります。ダウンロードして、手順に従えば、数分でかなり興味深い、えー、つまり、埋め込み作業を始められます。えー、聴衆から質問があります。PDFファイルはS3から取得しているのですか？はい、そうです。
PDFファイルは、えー、実際には私たちが提供しているものです。これは単なる、サンプルドキュメントをすべて置いてある公開S3バケットです。えー、もちろん、えー、どんなカスタムユースケースでも、それらはプライベートS3バケットにあってもよく、つまり、企業がそこから取得するような形でも構いません。えー、しかしこの場合は、私たちが利用可能にしている、えー、公開サンプルファイルから取得しているだけです。それがダウンロードされたものです。とてもクールです。
さて、では、ええと、単なる検索のサンプルです。もう一度、さらにいくつか見ていきます。ええと、主な焦点はおそらく少し、ええ、技術寄りのものになります。つまり、私たちがテキストのチャンク化や埋め込みのために、こんなに高速に解析していることがどれほどすごいか、ということです。ただ、少なくともその結果のいくつかはお見せしたいと思いました。ええと、これもまた、ある種の素敵な概念的クエリです。
そして、たった1行で取得したものですが、ええと、ライブラリに対してセマンティッククエリを実行すると、ドキュメントがあり、ページ番号があり、そして距離があります。ええと、私たちが非常に興味深いと感じていることの1つは、埋め込み空間の幾何学です。そして、これらの距離のいくつかを使って、本当に興味深いことをし始めることができます。たとえば、トピック分類を定義し始めることができます。どのような種類の情報を、どれだけ見るかを、埋め込み距離のしきい値に基づいて定義し始めることができます。ええと。そして、ご覧いただけるように、私たちはテキストをほんの短い文字数で切っています。皆さんがすばやく読めるようにするためです。
しかし、かなりうまくできていることがわかります。ええと、たとえば、持続可能性に関する問題を抱える女性、つまりグローバリゼーションと自立および相互依存、気候変動といったものです。開発における女性、脆弱な国々、経済資源の分配におけるより大きなジェンダー平等など、ええと、多くのトピックが見て取れます。私たちが与えたクエリに関連する興味深い文脈を前面に引き出すために、セマンティックな意味の一部をうまく捉えていると言えます。
さて、ええと、もう1つ例をお見せします。これはかなり似たものになります。かなり似たタイプのレシピになりますが、ドメインが異なります。ですのでコードはお見せしませんが、もちろん、もしどなたかが望まれるなら、少し戻って確認することもできます。これはかなり似たことを行いますが、今回は国連決議を見る代わりに、まったく同じフローを行い、ええと、80件の契約書を取得します。そしてこの例では、ええと、こちらもご覧のとおり、80件の契約を非常に高速に解析します。
ただし今回は、ここでのあのミニの、ええ、Bertモデルではなく、その契約向けにファインチューニングされた埋め込みモデルを使います。というのも、やはり私たちが見つけたのは、契約に関する主要な概念や用語のニュアンスが少しでもあるだけで、実際により良い検索結果が得られるということです。ですので、私たちはそれら80文書を解析してテキストチャンク化し、23秒で処理しました。それは7,643個のテキストチャンクに分解されました。そして今、それらの埋め込みを、ええと、どんどん処理しています。ええ、画面が見えているとよいのですが。
はい。ええ、聴衆からもう1つ質問があります。ええと、コード内でモデルをどのようにアンサンブルするか、簡単に説明していただけますか？次の例でそれをお見せします。なので、よろしければそこで、完璧に、強調して説明します。完璧です。
完璧です。ええと、この例は、繰り返しになりますが、UN決議の例とほぼまったく同じです。ええと、ただ、非常によく似たレシピを示しています。これは、うまくいけば、これが再現可能なパターンであることを示す助けになります。いくつかのドキュメントを取り込み、それらが解析され、埋め込みモデルを選択し、埋め込みを作成し、そしていくつかの検索を実行し始めることができます。
さて、ここでは、やはり、おそらくある種の軽量なHello World的な例ですが、私たちはたとえば、ええと、インセンティブ報酬のようなものを選びました。ご覧のとおり、報酬という単語自体はここには反映されていなかったにもかかわらず、それに非常に関連する単語を拾うという点でかなりうまくできています。しかし、インセンティブおよびインセンティブボーナスに関する、ええと、こうした重要なテキストチャンクをすべて拾い上げています。さて、これをお見せしたかった理由の1つは、まさに先ほどの質問につながっているからです。つまり、私がお見せしたい3つ目の例です。そして3つ目の例は、ええと、これらのモデルを、ええ、RAGシナリオの中で、ある種チェーン化したり、組み合わせたりし始めるものです。
そしてこれは、この契約書の例をある種発展させたものです。ですのでこの例では、これからやることは、ええと、契約書を使います。つまり契約書用の埋め込みモデルを使います。同じ、ええと、レシピの定型コードです。ライブラリを作成します。これらのドキュメントをダウンロードします。すでにダウンロードされているので、再度ダウンロードされることはありません。
ええと、これらのドキュメントを解析し、埋め込みをインストールして、それから今度はもっと面白いことをします。つまり、埋め込み空間を作成したら、次に10億パラメータのblingモデルをロードします。先ほど業界向けのBertをロードしましたが、それは埋め込みモデルです。つまりベクトルを生成するもので、そこにテキストを入力すると、ベクトル出力が返ってきます。そのベクトル出力は、実質的に、そのテキストのチャンクをベクトル空間内で識別するために使われます。
それを、ええと、Novusに入れているわけです。それがすべての検索に役立ちます。さて、次のステップでは別の種類のモデルをロードします。LLM、生成モデルで、テキストを受け取り、コンテキストの文章と質問を受け取って、その文章に基づいて質問に答えます。テキストを出力します。
もし想像できるなら、GPTのようなミニ、ミニ、ミニ、ミニ版です。そして完全にローカルで実行されます。ええと、すでにhugging faceからダウンロードしてあります。なのでこのマシン上で実行されています。メモリとGPUにロードするのに、おそらく10秒か15秒かかるでしょう。
このモデルを使います。そして私たちが使うインターフェース、LL mware内の概念、抽象化は、プロンプトを作成するというものです。なぜならプロンプトとは最終的に、そのモデルが何であれ、モデルで何をしたいかだからです。ではここでモデルをロードします。ええと、このblingモデルをロードして、非常にシンプルなクエリを用意しています。
繰り返しますが、世界で最も面白いクエリというわけではありません。ただ、「役員の基本年俸はいくらですか？」と尋ねます。これらはそれぞれ雇用契約書です。10ページか15ページあります。これを実際のプロジェクトとしてイメージできます。誰かがやって来て、「全従業員に提示した内容の一覧を取得して確認できますか？比較可能ですか？違いはありますか？外れ値はありますか？」と言うようなものです。通常これは一種の手作業になります。特にそれが10件の契約書ではなく、100件、あるいは1000件の場合です。ここでは、先ほど作成した埋め込み空間を使って、その作業すべてをLLMに依頼します。
そのモデルをロードし、セマンティッククエリを実行します。これは戻って、ええと、ベクトル空間にクエリをかけます。そして契約書ごとに、契約書ごとに、契約書ごとにループします。そして各契約書について何をするかというと、基本的には、その契約書に対する上位の、ええと、セマンティック検索結果を取得します。それをソースとしてプロンプトにパッケージします。
ソースを追加するこの1行が行うのは、これらすべてのクエリ結果をプロンプトにパッケージ化して集約することです。そしてプロンプトを呼び出します。モデルをロードし、そのコンテキストをロードしました。そして実際にモデルにプロンプトを送るときに行うことは、質問を投げかけて、その結果を出力するだけです。いいですか？そして繰り返しますが、これらすべて、これらのモデルのオーケストレーション、埋め込み空間は、すべてローカルで実行されています。データは、この処理が実行されているサーバーから決して外に出ません。
では、今からこの例を実行しましょう。ここには契約書が10件しかありません。見てわかるように、非常に速く処理が進みました。埋め込みを非常に、非常に高速に作成しています。ええと、これは10個のドキュメントだけのシンプルな例です。
そして今ここが重要なステップです。今、LLMモデル、10億パラメータの小さな、小さいけれど強力な、ええと、blingモデルを取り込んでいます。それを、ええと、メモリに取り込んでいるだけで、その後、推論を本当に、本当に速く処理していきます。それから、それから、ええと、1秒か2秒かけて、実際にそこから得られた結果を見てみます。ええと、これが実行されている間に、聴衆からの別の質問を紹介します。
ええと、それが議論されているかどうかはわかりませんが、ウォークスルーの最後に、GBT four パイナップル絵文字を使ってゼロから独自のデータセットを構築する方法について、もっと学びたいです。はい、いいですね、いいですね。さて、これが実行されたので、すべての推論が実行され、ええと、すべてのクエリが実行され、ええと、それは、ええと、すべての契約を反復処理しました。では、実際に何をしたのかを見せましょう。いいですか？ もう一度言うと、私たちは10件の契約を取り、それらを解析し、埋め込みました。基本的な質問でセマンティック検索を実行しました。つまり、役員の給与はいくらか、というものです。そして各契約について行ったことは、各契約をループし、見つけた上位の検索結果を取り、基本的には、Rhea executive employment contractで見つかった最良の情報は何かを探しに行きました。そしてそれがこの4つのパッセージでした。
これは、ええと、0. 62 離れていたことがわかります。これは 0. 6、4. 8、1.
84。プロンプトのその1行がソースをパッケージ化し、ええと、最終的にどのソースがどの情報を提供したかを識別するすべてのメタデータ付きで、このすべてのテキストをパッケージ化しました。これがLLM、つまり、その、小さいけれど強力なblingモデルに渡されました。そしてここにモデルの回答がありました。つまりモデルはこのパッセージを読み、この場合、その検索結果のちょうど真ん中あたりにあった答えを見つけ、それから、ええと、正しい答えを返してくれました。つまり、私たちがここに座っているほんの数秒の間に、これらすべての契約についてこれを実行してくれたのです。
さて、私は特に10億パラメータのモデルを強調したいと思いました。10億パラメータのモデルが、皆さんご存じのようにGPT-4ができることを何でもできる、と勧めるためではありません。もちろんできません。もちろんできませんし、ミスもしますし、間違うこともあります。それらの種類のモデルの代替として意図されたものではありません。
しかしこれが示しているのは、優れた検索戦略があれば、小さなモデルでさえ意味のある作業をしてくれるということです。今回の場合、小さなモデルはGPU上で動いているので、ものすごく、ものすごく高速ですが、この小さなモデルは、あなたのMacラップトップ上でもそのまま動かせます。量子化も不要で、特別な処理も不要です。ええと、ただ動きますし、妥当な速度で推論を実行します。そして比較的シンプルな抽出型のキー・バリュータスクにおいて、かなり良い品質を返してくれます。
しかも正しい答えを得ています。ですので、これは本当に良い例だと思うので、皆さんにお見せしたかったのです。これは単純なragのユースケースにすぎませんが、これは皆さんが再現し、スケールさせて、さらに多くの複雑なことを行えるレシピだと私たちは考えています。あなたの埋め込み空間です。ここまで3つの例を見てきましたが、そこでは、どのように解析するか、その埋め込み空間をどのように作るか、それに対してクエリをどう実行するかが見えたと思います。
そして今、そのプロンプトとLLMモデルを統合しました。ですので、エンドツーエンドのragを始められます。ええと、YouTubeには他にもいくつか動画があります。ぜひチェックしていただきたいのですが、そこではこれをより詳しくウォークスルーし、いくつかのファクトチェック機能を説明し、この出力のすべてが自動的にJSON Lファイルとして生成される方法のいくつかを説明しています。上流のシステムにプッシュすることもできますし、人に見せたい場合にはCSVファイルとしてプッシュして、「ねえ、これが私の得た出力です。
これは、つまり、正確に見えますか？」と言うこともできます。そして人がすばやくレビューして、最終確認を行うことができます。では、ええと、3つの例を見てきました。それらはすべて、この醜い、醜いコマンドライン上のものでした。ええと、そこで、もう少し視覚的なものを実際に見たい方のために、ええと、実はWebアプリも動かしています。すみません、ええと、すみません、今そちらに切り替えます。
このWebアプリは、そのインフラストラクチャの上で動いているシンプルなWebアプリです。そしてどうか、ええと、UIに何か問題があっても。あらかじめお詫びします。ええと、実はこのデモのためだけに、その一部を準備しました。コンソール上ではない形で、ええと、今行ったことをただ生き生きと見せられるものを提供したかったのです。
ええと、それから、これを機会として使って、あの、ええと、ちょっと強調したかったのですが、クールなライブラリやコンソール、実験やその他すべてに加えて、私たちは実際にこれとまったく同じインフラストラクチャを使ってきました。つまり、vis を使って、非常にスケーラブルな、ええと、アプリケーションにおいて、すべての要素を組み合わせ始められるものです。つまり、この高性能な検索を、ええと、ローカルのプライベートクラウド、LLM とともに行い、そのすべてを、ええと、プライベートクラウドの文脈で実行するわけです。では、これから入っていく内容ですが、時間が少し足りないのは分かっていますし、データセットに関するあの質問にも戻りたいと思っています。なので、私がちょっと面白いと思ったものを1つだけお見せしたいと思います。これは非常にシンプルな小さな検索、ええと、画面で、ええと、私たちがモックアップしたものです。
そして、あのシンプルな質問に戻ります。雇用契約で最も単純なこと、最も基本的なことといえば、たとえば、給与の金額はいくらだったのか、ですよね？そしてまず、これをテキストインデックスに対してだけ実行してみます、いいですか？これはセマンティック検索ではありません。これは単に、給与と金額という、かなり基本的な単語に見えるものに対する純粋なテキストインデックスです。そして、これが何を取得し、何を優先したのかを見てほしいのです。まあ、これは完全に理にかなっています。salary という単語があり、amount という単語があります。
これ以上どう良くできるでしょうか？でも、給与額を探しているとき、何を探しているのでしょうか？数字を探しています。実際の金額を探しているのです。つまり、テキストインデックスが行ったのは、単語に基づいてインデックス化し、salary amount を提示したということです。でも今お見せしたいのは、そして繰り返しになりますが、なぜ、つまり、ファインチューニングされた埋め込みモデルを使うのか、なぜ異なる埋め込みモデルを使うのか、あるいはなぜテキスト検索ではなくセマンティック検索を使うのか、という質問です。さて、これはまた、非常に、非常にシンプルな小さな例です。今、同じクエリ salary amount を使いましたが、今回は実際にそれを私たちのセマンティックインデックスに対して実行しました。見てください、何をしたか。
異なる結果セットを優先しました。そして、ここで興味深いのは、それが amount という単語を言及していない、言及していないのに、そうしているように見えることです。なぜなら、それは埋め込み空間を通されていて、そこでは大量の契約書を、いわば処理してきたため、amount というものが実際には、多くの場合、より重要なのは実際の金額そのものを取得することだと理解しているからです。したがって、それが優先した、つまりそのクエリに対して埋め込みの幾何、ええと、ジオメトリ上でより近かったのは、実際に金額を含んでいる節であり、amount という単語を含んでいる節ではありませんでした。非常にシンプルな小さな例ですが、これを使って、セマンティック検索の力、そして特定のドメインにファインチューニングされた埋め込みモデルを持つことの力を強調したかったのです。最後に、時間が厳しいのは分かっているので、おそらくこれにふさわしい扱いはできないと思います。
ええと、ただ、Dragon モデルを見る機会もまだ本当に得られていません。繰り返しになりますが、これについては私たちが用意している動画などがたくさんありますが、1つだけ残しておきます。そして、もしかするとこれはフォローアップセッションで取り上げられることかもしれませんが、実際にできることは、そしてこれは私たちが取り込んだモデルで、私たちの Dragon DESI モデルの1つでした。この UI のために、これを行う方法を2つ用意しました。直接質問できるテキストパッセージ、またはこれらの契約書の1つから直接何かを取り出す方法です。そして私は vacation だけを使います。
ええと、そして、ええと、休暇日は何日ですか？そして今これは、その雇用契約書のドキュメントに対して、LLM ベースのクエリ、rag シナリオを実行しています。そしてこれが返ってきたものです。AI モデルが返答し、ローカルの GPU 上でローカルモデルとして実行しているサブ秒の応答時間が見て取れます。契約書全体を読み取り、埋め込み空間から該当するものを呼び出し、適用される条項を、情報がどこにあるのかのソースと確認とともに提示しました。ここで一旦止めます。繰り返しになりますが、ここにはもっと多くのものがあります。
私たちはまだ表面をなぞっているだけだと思います。でも願わくば、これで Melva と LL Mware によって動作するエンドツーエンドのプライベートクラウド rag システムの、いくつかの異なるユースケースをお見せできたのではないかと思います。ここでプレゼンテーションを一旦止めます。これ以上、ええと、デモは扱いません。ええと、でも少しだけ息を整えて、独自のデータセットをどう構築するかという質問にはまた戻ります。
ええと、でも、でも Eugene、他に私が答えるべき質問があるかどうか確認するために、いったん止めてもいいかもしれません。ええと、その前に、ええと、これはもっと早く答えられるかもしれません。ええと、ええ、ある方が質問しました。推論に別の10億パラメータモデルを利用している理由が聞き取れませんでした。私たちの Dssi モデルがより小さなモデルを教えるのでしょうか、それともここでは別の概念が起きているのでしょうか？ とても良い質問で、答えは実はとてもシンプルです。ええと、私はいくつか違うものを見せたかっただけです。
ええと、10億パラメータモデルは、例えばそのスクリプトを自分のノートPCで実行している場合には本当に便利です。つまり、このセッションが終わって、少しわくわくして、「お、これはちょっと面白いぞ。見に行ってみよう。LL Mware に行って、リポジトリを落としてくるか、PIP install してみよう」と思うわけです。おそらくノートPCで実行することになるでしょう。
10億パラメータモデルは、hello world として始めるには素晴らしい方法です。「なるほど、うん、なんとなく分かった。これがどう動くのか理解できた」と言えるようになりますし、ほとんどのユースケースで、優れてはいるけれども最高ではない精度を出してくれます。そして、例えばもっとプロフェッショナルな環境があるとします。GPU サーバー上でこれを実行しているかもしれませんし、あるいは、6億または70億パラメータモデルを、ええと、迅速に、自分専用の推論サーバーとして立ち上げる方法についての別の動画で紹介しているような、ポップアップの GPU サーバーをセットアップするかもしれません。それが使えるなら、これ以上のものはありません。私なら常に、GPU 上で6億または70億パラメータモデルを使います。なぜなら、間違いなくより良い結果が得られるからです。
ですから、私たちが示したかったことの一部は、手元のノートPCで10億パラメータモデルからおよそ30億パラメータモデルまでを使ってローカルにテストするのは素晴らしい、ということです。そして、より本番環境に近いところへ移行する準備ができたとき、あるいは GPU に載せる準備ができたときには、その bling モデルの名前を dragon モデルに差し替えるだけで、より高性能な結果が得られる、これ以上のものはありません。いいですね。とてもいいです。残り時間があと数分しかないので、ええと、ええ、データセットの件に少し触れてから締めくくるのが良いと思います。
データセットは素晴らしい質問です。ええと、データセットは、このすべての鍵です。ですから、ええと、私たちが最初にこれを始めたとき、利用可能な多くの公開データセットを見ました。ええと、それらはチャットに非常に寄っていて、非常にたくさんのものがあります。会話の流暢さのようなもの、つまり、あの、安全性や有用性といった種類の指標を向上させたいのであれば、
そこには素晴らしいものがたくさんあります。でも私たちのユースケースは本当に違っていました。ええと、私たちは実際には、ある種の真面目で無駄のない、つまり、これらの密度の高い契約書や規制情報、決議、コンプライアンス、金融ニュースなどを読んで、そこから非常に技術的な種類のものを抽出できる LLM が欲しかったのです。そこにあるデータセットはそれほど多くありませんでした。ですから、そのデータセットを準備するには、おそらく、そうですね、3つの重要な次元があると言えるでしょう。
1つ目は、生のソース資料をいくつか集めることで、それ自体が仕事です。2つ目は、モデルに学習させたい主要なタスクや指示、スキルのカテゴリを本当に定義することでした。ええと、そして、その中には、例えば value type のようなものがあるかもしれません。モデルが who に関する特定の種類の質問をされたときには常に一貫して回答し、人物を特定できるようにしたいのです。一方で、会社の住所について尋ねている場合には、その種類の value type に一貫して応答できるようにしたい、ということです。あるいは question type かもしれません。ですので、私たちは Boolean questions に多くの時間を費やしました。
はい、いや、モデルは実際かなりうまく機能します。もしそれにイエス・ノーの質問をしたら、これは起こりましたか？ここにある小さなテキストを見て終了できますか？便宜上、契約を終了できますか？つまり、イエス・ノーの質問はスキルですよね？まず、ソース素材を集めます。次に、その一連の指示を特定します。そして第三に、本当に難しい部分ですが、適切な種類の鋭い質問をしていることを確認するために、細部に多くの時間を費やします。十分な一貫性と多様性の両方を構築し、さらにそれらのコンテキストから導き出されるべき、適切な事実ベースの種類の回答を提供していることを確認します。
つまり、設計においてかなりの注意を払った、ボトムアップの取り組みだったと言えるでしょう。そして、どのように設計するかについて、あらゆる細部に注意を払いました。さて、あなたの質問は、GPT-4を足がかりにできるか、ええと、GPT-4をもとにブートストラップできるか、ということだったと思います。答えはもちろんです。ええと、実際、LL Mwareでは非常に優れたツールをいくつか提供しており、先ほど私たちが実行したこの種の推論はすべて、実際にはプロンプト状態に取り込まれます。それらは個別のJ-S-O-N-Lファイルとして保存され、その後統合され、箱から出してすぐにモデル対応のLLMファインチューニングデータセットとしてパッケージ化できます。ええと、私が最も注意すべきだと思うのは、そのデータセットを収集する機械的な側面というよりも、最初のいくつかの点について、つまり、どのようなトレーニング目標を持っているのか、適切なソース素材は何か、そしてモデルにトレーニングさせたい主要なスキルやタスクは何かについて、十分に考えることです。
いいですね。ええと、皆さんお越しいただきありがとうございます。Darrenさん、この素晴らしいプレゼンテーションをありがとうございました。皆さんが取り組んでいることを見られて、本当に素晴らしかったと思います。また、ライブデモや、それらがどれほど高速かを見られたのも本当に素晴らしかったです。
ええと、皆さんが今後何をされるのか、もっと見るのを楽しみにしています。そして皆さん、改めてありがとうございます。ええと、これは近日中に録画形式で利用可能になりますので、また次回皆さんにお会いしましょう。素晴らしいです。皆さん、本当にありがとうございました。ご質問があればいつでもご連絡ください。
Meet the Speaker
Join the session for live Q&A with the speaker
Darren Oberst
CEO of Ai Bloks
Darren Oberst is the CEO of AI Bloks, an innovative AI platform revolutionizing the landscape of LLM-based application development for Generative AI in financial services and legal industries. Prior to AI Bloks, Darren served as the CEO of Exadel, and launched and grew HCL Software to over $1B revenue in 5 years. Darren is currently focused on building enterprise LLM-based applications, which includes retrieval augmented generation, open source LLM middleware (LLMWare), and fine-tuning specialized enterprise LLM models for open source. Darren is a graduate of UC Berkeley with degrees in Physics and Philosophy and Harvard Law School with Honors.