You’re in!
ウェビナー
Floomを使ってアプリにマルチモーダルAIを統合する
本日は、ええ、セッション「FloomでアプリにマルチモデルAIを統合する」をご紹介できて嬉しく思います。そしてゲストスピーカーのmark、ええ、max、ええ、maxは、コーディングとハッキングにおける20年以上の経験をキャリアにもたらし、ソフトウェアセキュリティとアーキテクチャにおける豊富な専門知識によって特徴づけられています。彼は著名な患者、著者であり、テック業界全体で重要な役割を担ってきました。たとえば、ええ、docs InnovationのCTO、Cyber Arcのリード、そしてcarsのCEOなどです。これらの役割は、彼の知識の深さとテクノロジーイノベーションにおけるリーダーシップを物語っています。ようこそ、Max。
ええ、今日は、今日は企業としてのあなた方、ええ、bloomについてお話ししたいと思います。ええ、Bloomについて、そしてそのビジネスが何をしているのか少し教えてください、ええ、またその間に、画面共有を停止します。あなたがドクター共有を持っていると聞いたので。はい。まず最初に、お招きいただきありがとうございます。ええ、そして参加してくださった皆さん、ありがとうございます。
そして、ええ、これをセットアップしてくれてありがとう、Steffy。では、今私の画面を共有しています。見えているといいのですが。はい。そうですね。基本的に、fluは開発者がアプリにマルチモーダルAI機能を統合するのを支援することがすべてです。
これがFluの目的です。これはオープンソースソリューションです。つまり、ええ、Flumeのチームとコミュニティ、ええ、そしてAIや開発、アーキテクチャなどのさまざまな専門家によって構築されています。ええ、そしてかなり新しいプロジェクトで、立ち上げたのは、ええ、3か月前です。ええ、しかし私たちは、これを約7〜8か月間構築してきました。
ええ、そして、ええ、それが基本的にfluです。では、ええ、ご紹介いただいたように、これが私です。ええ、私はソフトウェア開発とアーキテクチャに関して、ええ、経験があります。ええ、ええ、それをもう20年以上やっています。ええ、また、ええ、いくつかの企業でチーフアーキテクトを務め、2つの、ええ、異なるスタートアップを立ち上げました。ええ、その両方が買収され、cards were、Zepo Appsに買収されました。ええ、そして私が、ええ、直近で担っていた役割は、cyberforのCTOで、ええ、Amdocsの、かなり大きな、ええ、多国籍企業で、従業員は30,000人です。
ええ、それが基本的に私についてです。さてfluについてですが。ええ、私たちは、現在最大級の、ええ、問題の一つを解決しようとしていると言えます。ご存じのように、1年以上前に、ええ、OpenAIが、ええ、chat、GPTをリリースしたとき、ええ、誰もが彼らのAPIを、ええ、待ち望んでいました、ええ、なぜなら人々は理解していたからです。つまり、それには巨大な可能性があると。テキスト生成やコード生成などの、いわゆる単純な例だけでなく、テキストや動画、画像、ええ、音、つまり音声、オーディオなどの中からパターンを特定することにおいてもです。ええ、そしてまた、さまざまな詳細を抽出したり、当然生成したり、そして、そしてそれ以外にも非常に多くのことがあります。ですから私たちはAIを基本的に、非常にスケーラブルで、非常に、非常に安価な一種の人間として見ています。ええ、APIで呼び出すことができるものです。
これが私たちのAIに対する考え方です。そして実際に起こったことは、つまり、多くの異なる、ええ、アプローチが、ええ、AIを統合しようとする開発者たちによって出てきたことです。そのほとんどはコードライブラリに非常に重点を置いています。ええ、たとえばLang chain、LA index kernelなどです。ええ、しかし私たちはある意味すぐに、そこには大きな、大きなギャップ、大きな問題、あるいは大きな問題群があると感じました。ええ、そして、そして、私たちは、そのアプローチ、ええ、エンタープライズにより適したアプローチには、アプリケーションと機能と、ホストされている場所にかかわらず非常に異なる複数のAIモデルとの間のすべてのやり取りを管理するのを助ける、何らかの中央集権的なコンポーネントが必要だと考えています。
だからこそ私たちは、ええ、考えていたのです。つまり、ええ、巨大なギャップがあると。一方にはAIの可能性があり、AIを統合したい多くの人々がいます。しかし残念ながら、そのほとんどは本番レベルの方法でそれを実現することが本当にできていません。ええ、特にエンタープライズグレードではそうです。ですから、これが私たちが解決しようとしていることです。私たちは大きな問題があると感じ、そして私たちは、私たちは何週間も腰を据えて、これらの問題に対するさまざまな解決策について考えようとしました。そしてこれが基本的にflu、ええ、が発明された経緯です。
つまり、基本的にこのギャップの根本的な原因、あるいは実際のギャップは、私たちが、スタートアップからエンタープライズまでの企業の従業員100人以上にインタビューした結果、基本的に4つの大きな課題を特定した、ということだと考えています。1つ目は、エンタープライズグレードの堅牢な開発またはデプロイメントインフラが実際には存在しないということです。つまり、さまざまなコードライブラリはありますが、ロギング、キャッシュ、監査、モニタリング、プライバシー、セキュリティ、安全性などを備えた中央集権的な管理が欠けています。そして、これを完全に機能させ、完全に本番環境レベルのパイプラインにするためには、GitHubで買い回りをするようにして、さまざまなライブラリをダウンロードする必要があります。そしてこれは、エンタープライズの視点では非常に不安定な体験を生み出します。
私たちのプロダクトはエンタープライズ開発に非常に重点を置いており、これこそが基本的に私たちが解決しようとしていることです。2つ目の問題は、さらに大きなものだと言えると思いますが、技術的な障壁です。現在、平均的なエンタープライズと話すと、gen AIプロジェクトは主にデータサイエンスチームやイノベーションチームに集中している一方で、AI開発の事前知識がまったくない開発者という、労働力の大多数が置き去りにされていると聞きます。そしてこれは、私たちが変えようとしていることでもあります。私たちはAIをもっとアクセスしやすいものにしたいのです。
つまり、これはAIに投資している専門企業内の非常に専門的で非常に高価なグループから、機能統合を担う大多数、つまり開発者へと移行させるということです。3つ目の問題は、現在、中央集権的な管理が存在しないことです。先ほど述べたように、キャッシュ、フェイルセーフ機構など、プライバシーやセキュリティのために中央集権的な管理を通過するすべてのスループットに加えて、現在の既存技術にAIを統合する際には、私たちは多くの異なる、大量のコードを書きます。そしてこれは本当にあっという間に非常に大きなコードベースになります。
それは基本的に2つの異なるものに基づいて構築されています。1つ目はAIロジックそのものです。link chainで構築されているか、あるいは何であれです。2つ目は、開発者が非常に大規模なB2CやB2Bのプロダクトに統合しようとしたときに、突然自分たちに欠けていることに気づく周辺インフラのすべてです。そのようなプロダクトには非常に専門的な本番環境のニーズがあります。そして、これは1つの統合だけの場合ですから、本当にあっという間に頭痛の種になります。ですから、もし多くの異なるAI統合があったらと想像してみてください。私たちはそれが間違いなく未来だと考えています。
将来的には、人々は間違いなくより多くのAI機能を統合するようになるでしょう。そうなると、本当にあっという間に管理不能な問題になります。そして最後の問題は、インスピレーションの不足だと考えています。現在、平均的なプロダクトマネージャーと話すと、私たちが聞くのは、彼らが主にコード生成やテキスト生成に注力しているということです。しかし、gen AIが提供できる他の何百もの可能性は置き去りにされています。そして、それが基本的に私たちが問題だと考えていることです。ですから、現在の既存のAI統合フロー、いわば平均的なフローは、平均的なエンタープライズではアプリであり、通常はPythonでなければなりません。なぜなら、データサイエンスはPythonを使うのが好きだからです。
ただし、ほとんどの本番環境のアップグレードシステムは、さまざまな理由からPythonベースではありません。そこで、コードライブラリと連携するために構築する必要がある、ある種の接続性プロキシのようなものが必要になります。そして、Lang ChainやLAMA Indexなど、さまざまなコードライブラリがあり、その中にすべてのロジックを構築します。そして、すべてのロジックコーティングがあります。つまり、通常はデータ取り込みやrugメカニズム、埋め込みなどです。
つまり、それは明らかにvisによって、ええ、そしてキャッシュメカニズムについてはRedisによって、グラフソリューションについてはNEO four Jによって、などによって処理されています。そして、それから私たちにはAIゲートウェイと呼んでいるかなり新しい概念があり、この接続性を取り巻く、ええ、インフラを提供しています。通常はロギング、キャッシュ、ルーティング、セキュリティなどです。つまり、1つのAPIがあり、使用しているAPIスキーマやSDKを変更することなく、さまざまなAIモデルに接続できるようになります。基本的に、それが現在の私たちの物事の見方であり、ええ、平均的なAI統合が今どのように見えるかについての考え方です。
そして、ええ、私たちはこれについて本当に、本当に深く考え、ええ、これにたどり着きました。つまり、ええ、これはまったく新しいカテゴリーで、ええ、an flumeと呼ばれ、AIオーケストレーターです。オーケストレーターは基本的に2つの異なる部分で構成されています。内部にはAIゲートウェイがあり、これはportkeyなど、現在私たちが持っているさまざまなソリューションに非常によく似ています。ええ、そして一方で、AIパイプライン内の実際のロジック構築を支援する実際のオーケストレーターがあります。
私たちはこれら2つ、ええ、AIオーケストレーターとAIゲートウェイを1つのソリューションに統合しました。ちなみにこれはオープンソースです。ええ、そして基本的には、この背後にあるすべての、ええ、すべてのAIロジックを舞台裏でDockerコンテナ内で処理するロジックであり、どこにでも配置できます。なぜなら、ご存じのとおりDockerなので、プライベートクラウド、パブリッククラウド、開発者のPCに配置できます。これは、ええ、ある意味で、ええ、開発者のidに非常に近いものです。ええ、そしてそれをアプリケーションとAIモデルの間に配置します。どのAIモデルにも完全に依存しません。完全にマルチモデルです。
ええ、そして私たちはこれをクラウドサービスとしても提供しており、つまり基本的にはsusソリューションとしてです。したがって、2つの異なる選択肢があります。もしあなたが企業で、ええ、あるいは、または、さまざまな規制下にあり、すべてを社内で使いたいのであれば、素晴らしいです。私たちのDockerコンテナを使えます。ええ、または、あなたがスタートアップであったり、何もインストールせずにfluを試したいだけであれば、flu cloudを使えます。ええ、では、それは何をオーケストレーションするのでしょうか？基本的には、私たちがAI functionsと呼んでいるものをオーケストレーションします。
そしてAI functionsとは基本的に、ええ、私たちは、現在知られているgen AIの2つの異なるメカニズムに目を向けました。そして直接推論があり、これはシンプルなものです。非常にシンプルなAPIがあり、それからagentsがあります。これは、ええ、LLMの内部でこの、ええ、思考コンセプトをトリガーするようなものです。私たちが見たのは、人々は圧倒的多数のケースで、両方を非常にシンプルなIO function、つまり入力、出力、さまざまな機能として使用しているということでした。そこで私たちは、その両方を1つの、ええ、ええ、名前または1つのオブジェクトに抽出することにし、それをAI functionと呼んでいます。これは開発者に響きます。なぜなら、それはシンプルなfunctionですが、今ではその中にAIが入っているからです。
そしてこれらは、私たちが現在構築している非常に、ええ、大規模なデータセットのごくシンプルな例の一部にすぎず、そこには何百もの異なるAI functionsがあり、ええ、あなたのコード内で数秒以内に今すぐ呼び出せるものです。ええ、例えば、テキストから物理住所を抽出し、整形されたjsonを返すことができ、それはあなたのコード内で実際にアクセスできるオブジェクトに変換されます。ちなみに、どんなフレームワークを使っていてもよく、Pythonである必要はありません。そして、テキストから音声を生成する、またはその逆もあります。数秒でAIモデルを切り替えることができます。さまざまなモデル、さまざまな設定を試し、キャッシュ、スマートキャッシュをオンにし、ええ、プライバシーやセキュリティのメカニズムを使う、などができます。
ええと、別の例としては、動画のPGレーティングを分類したり、画像内のオブジェクトを検出したり、テキスト内の感情を検出したり、データについて質問したり、などがあります。ですので私たちは、ある意味、ええと、プロダクトマネージャーの視点で考えようとしています。なぜプロダクトマネージャーが、ええと、あるいは彼らが自分たちのプロダクトでgen AIからどのような恩恵を受けるのか、ええと、単純なテキストやコード生成以外で、ということです。これが、基本的にfluでAI functionを定義する方法です。ですので、コードライブラリのことや学習曲線のことは忘れてください。これは非常にシンプルで読みやすいYAML形式のファイルで、AIに関する事前知識がまったくない開発者でも、数分で記入できます。
ええと、ではこのYAMLファイルを見ていきます。ここで見えるものは、ちなみにKubernetesに非常によく似ています。あー、ええと、ここで見えるのは、定義しているオブジェクトのkindを指定しているということで、それはAI pipelineです。ええと、その後にnameを指定し、次にmodelを指定します。複数のモデルを指定することもできます。1つのモデルが機能せず、別のものにフォールバックしたい場合は、新しいmodelと新しいrulesのセットを簡単に指定できます。そして、使用したい最初の、またはデフォルトのmodelの、あー、状態に関係なく、AI featureが確実に動作するようにできます。
そして、ええと、ここで見えるように、完全に非依存でもあります。ええと、これはURIで、このURIはpackage、あー、または最近私たちが呼んでいるpluginを指しています。そして基本的に、ええと、fluの中に注入できるlogic、またはcode logicです。自分で構築することもできますし、私たちが本当にもうすぐローンチするmarketplaceからダウンロードすることもできます。ええと、そして内部やその他すべてを簡単にデバッグできます。
ですので、たとえ私たちがデフォルトでサポートしていなくても、ええと、数分以内に任意のAI modelと簡単に接続できるようになります。つまり、これはこのAI pipelineをパッケージ化するという考え方のようなもので、ええと、多くの異なる内部packageによって、この手順をAからZまで完全にカスタマイズできるようにします。ええと、使いたいlogicが何であってもです。ですので、ある意味ではCICDやKubernetesに似ています。ええと、CICDに似ているのは、自分のpluginを注入できる非常に明確なflowだからです。ええと、そしてKubernetesに似ているのは、今やある意味リモートで、ええと、assetsを管理しているからです。そしてこの場合、そのassetはAI pipelineです。これがprompt templateの見た目です。見た目としては、ええ、さまざまな、あー、prompt templateと本当に非常によく似ています。
基本的にはsystem promptとuser promptをコンパイルします。他の人が私たちのmarketplaceにアップロードしたexamplesを使うこともできますし、必要であれば自分で書くこともできます。ええと、そしてこれは非常に重要な部分です。これは私たちがcontextと呼んでいるものです。Contextは実際には、他の人たちがrugと呼んでいるものです。
ええと、ですが私たちはrugは、ひどい名前だと思っています。なので、これが私たちがcontextを使う理由です。そしてcontextでは基本的に、AI featureに取り込みたいdataを実際に指定します。そして、あー、基本的にはAI modelに転送したいdata、knowledgeです。つまり基本的にはrugです。ここでは非常にシンプルでわかりやすいrugを示す、非常に単純化した方法から始めます。
ここではPDFファイルを扱うpluginを使用していて、1つのPDFファイルを使用していることがわかります。次のスライドで、もう少し、ええと、あー、ええと、複雑な例をお見せします。しかし今は、あー、次の部分に進みましょう。そしてここでは、responseをどのように指定または設定するかを示しています。ですので私たちは開発者として、AI expertsとしてではなく、この場合はそう言うべきだと思いますが、responseがformatterと呼ぶpluginによってformattedされることを確認したいのです。
そして、このプラグインによって、開発者は期待している正確なレスポンスを事前に設定できます。ご存じのとおり、AIにおける最大の問題の一つは変動性です。多くの人がこれを本番環境に実際にデプロイすることを恐れています。なぜなら、AIからどのような回答が返ってくるのか分からないからです。ええ、そしてこれは当然、私たちのプラットフォームを使用しているエンドユーザーに影響します。そこでfluでは、このリスクを可能な限り最小化しようとしました。このフォーマット済みのフォーマッターを有効にすることで、AIから返ってくる回答が、まさにあなたが求めているものと一致していることを確認できるようにしたのです。
ここではテキストを指定し、言語を指定し、最大文数を指定します。ええ、そしてここで使用できる変数は他にも本当にたくさんあります。ええ、またこれはマルチモデルでもあり、さまざまなシナリオに対応するために独自のプラグインを書くこともできます。そしてこれは、flumeに携わる多くの人々から要望された機能で、いわば、一番要望の多かった機能は基本的にバリデーションだと言えます。つまり、平均的なエンタープライズがあるとして、最大の懸念の一つは、人々や消費者がAIを使ってPIIの持ち出しを行うことです。PIIとは個人を特定できる情報の持ち出しをAI経由で行うこと、あるいは何らかの形でプロンプトインジェクションを使ってAIをだまし、クレジットカード情報などを返させること、あるいは単に、私たちのブランドがさらされたくない悪い言葉をフィルタリングすることです。
そのため、ここにあるフィルターもプラグインになっており、誰でも独自のプラグインを書くことができます。実際、私たちはすでにflu向けに独自のプラグインを書いている2社の異なるLLMセキュリティ企業と協力しています。したがって、開発者としては、使用したい任意のプラグイン、バリデーションプラグインを簡単に設定し、それらが期待している任意の変数、任意の引数を設定できます。そして、このバリデーションプラグインが動作するようになります。そして、これもまた非常に、ある種人気のある機能です。
ええ、ここにglobalがあります。globalは基本的に、AIパイプライン全体に適用されるパッケージやロジックを意味します。レスポンスやプロンプトだけでなく、基本的にすべてに対してです。そしてここで見ているのは、コスト管理プラグインを使用しているところです。このコスト管理プラグインは、先ほど言ったように、fluを試している人々の間で非常に人気があるもので、ユーザーが1日に使用できる最大トークン数、またはパイプラインが1日や1か月などに使用できる最大トークン数を設定できます。つまり、現在人々が自分たちで解決しようとしている非常に大きな問題を、本当にかなり楽にしてくれます。彼らは独自のAIゲートウェイを書こうとし、自前のコスト管理メカニズムなどを構築して自分たちのコストを管理しようとしています。そして最後はキャッシュです。
つまり、独自のキャッシュメカニズムを書く代わりに、ファイルに2行のコードを書くだけです。ええ、そうすれば、さまざまな引数を持つ完全に動作するキャッシュメカニズムが手に入ります。自分のものを使うことも、Marketplaceからダウンロードすることもできます。次に必要なことは、このyamoファイルの編集を終えたら、実際にそれをデプロイすることです。つまり、ある意味ではGitHubやKubernetesにかなり似ています。yamoファイルの設定を行い、それをfluインスタンスにデプロイするからです。
これを行う方法は本当に、本当に簡単です。私たちのCLIをインストールし、それからflume, deployと書いて、エンドポイントを指定するだけです。それはflum Cloudでも、自分のfluインスタンスでも、何でも構いません。そして、先ほど編集したyamlを指定するだけです。基本的にはそれだけです。
ええと、複数送信して、複数の yaml を、ええと、1つのバッチでデプロイできます。そして、そしてそれが基本的に AI functions をデプロイする方法です。では、私たちが今そう呼んでいる rugor context を少し掘り下げると、私たちは rug します。ええと、私たちはさまざまなユースケースがたくさんあることをよく認識しています、ええと、そしてご存じのとおり、それは高度にカスタマイズ可能であるべきで、これこそまさに私たちが今日取り組んでいることです。ええと、私たちは非常にカスタマイズ可能でありながら、メンテナンスが容易でデバッグ可能な体験を、AI の事前知識がまったくない開発者に提供しようとしています。
ええと、そしてこれが基本的に私たちが考え出したものです。そしてここで見えているのは、ええと、この特定のケースでは context の最後のセクションが、実際にすべてのファイル、ええと、この特定のパスにあるすべての PDF ファイルを取り込んでおり、検索パターンのさまざまな設定を使用しているということです。この特定のケースでは、Mel で非常に人気のある L2 を使用しています。ええと、そして、そしてここでは top results も指定しています。ええと、別の例として、今回は AWS S3 用の別の productplugin を使用しています。自分の認証情報を編集して、パスを設定するだけです。
そして、ええと、この特定の例では、co-sign similarity を使用し、top K を指定しています。これは私たちが top results と呼んでいるものです。ええと、そしてこれが基本的に RUG の見た目です。ええと、flu では、私たちはそれをさらにカスタマイズ可能にするために本当に懸命に取り組んでおり、RUG 関連または embeddings 関連のすべて、ええと、これは現在 flu で完全にマルチモーダルです。ええと、ええと、video の部分を除いて、これは、ええと、約2〜3週間ですぐにリリースする予定です。ええと、それは Melva db に基づいています。
つまり、それが、ええと、ええと、私たちが flume 内部で作業する方法のようなものです。ちなみに flume cloud でも、また flume docker でも、私たちは、ええと、Docker composed file の中で VU db を一緒に提供するような形です。さて、開発者が最後にやる必要があることとして、私たちは AML file から始めて、それをデプロイしました。今ではそれは完全に管理され、オーケストレーションされています。開発者が最後にやる必要があることは、ただ私たちの SDK を使うことです。さて、前に Python と言ったのを覚えていると思いますが、必ずしも全員が Python で作業しているわけではありません。
実際、本番レベルのプロダクトの大多数、つまり高スケールで高性能なものは、Python ベースではありません。ええと、そして私たちは、人々が自分たちの、ええと、Python コードやサービスと通信するのを助けるこれらのプロキシを構築するだけに費やす、この時間を省きたいと考えました。だからこそ、私たちは7つの異なる、最も人気のある言語向けに SDK をリリースしました。ですので、おそらくあなたの、ええと、言語や proor framework も見つかるでしょう、ええと、その中に私たちの SDK があるはずです。そして、あなたがやる必要がある唯一のことは、ただ5行のコードを書き、ええと、先ほど flu にアップロードまたはデプロイした AI、ええと、function を指定し、それから prompt を指定するだけです。
さて、先ほど言ったように、それは完全にマルチ their models です。複数の prompts、images、ええと、レイによって、AI model に送信したいものは何でも、ええと、送信できます。これはデモで、実際には flu のものです。録画されたデモです。ですので、ええと、実行しますが、実行する前に、ええと、ここで何が見えているのかを、ええと、説明しようと思います。
右側では、ええと、flu の内部を見ることができます。つまり、verbal mode をオンにした状態で実際に見ることができ、基本的に舞台裏で起こっていることを何でも見ることができます。ええと、これは AI の経験がある人にはある程度なじみのあるものです。ええと、それは embeddings を行い、それらを Melb にロードします。それから、ええと、runs、ええと、cosign similarity を実行します、この特定のケースではそうだと思います。ええと、そしてすべてのデータを LLM に戻します。
そして左側に見えているのは、ここではコード部分です。つまり、ここにはさまざまな AI、ええと、functions があります。3つの異なる例があります。1つ目は Ducks example です。とても単純なものです。
特定のドキュメント、PDF ファイルを埋め込むだけです。それはたまたまイタリアの、ええと、銀行のものです。私たちはその、ええと、ウェブサイトをスクレイピングして、ええと、embedding に通し、ええと、それからそれにいくつか質問をします。そして次に2つ目の、ええと、YAML file があり、これは別の AI function を表していて、実際に images を作成します。ええと、そして3つ目、3つ目は text to speech です。
つまり、3つの異なるパイプラインがあります。そしてここ、ええ、画面の下部に、私たちのCLIが動作している様子が表示されます。では、デモを実行してみます。はい、ここにあるのはシンプルで、ええと、かなりわかりやすい例です。ええと、そしてこちらが、私たちの埋め込みフレームワークを通して実行するPDFファイルです。
fluの中では、これは単に、ええと、ヨーロッパのウェブサイトから直接取得した公開情報です。そしてこちらには、このAI関数がfluでどのように見えるかを表す実際のYamalファイルがあります。ご覧のとおり、非常にシンプルで、とても読みやすいです。モデルを指定し、プロンプトを指定し、レスポンスを指定するだけで、それで終わりです。そして、必要であればキャッシュやセキュリティプラグインなども併用して、完全に動作するAIパイプラインまたはAI関数を持つことができます。
そして右側では、実際に裏側で何が起きているかを見ることができます。ええと、実際にはPDFファイルを保存し、それを解析し、データを抽出しています。ええと、その後、ええと、いくつかのパイプラインモデルコネクタを使って埋め込みを取得します。この具体的なケースではopen aiを使用しています。ええと、そして次のステップで、ええと、埋め込みを、ええと、こちらのMELVA DBにプッシュしています。これはすでにmelva dbにプッシュされています。
つまり、インデックスを作成し、コレクションを作成し、ええと、メモリにロードし、この特定のPDFに関連するすべてのベクトルを挿入しました。そして、先ほど言ったように、これはCICDに非常によく似ています。ある種のイベントワークフロー、ええと、あるいはメッセージングシステムとさえ言えるでしょう。ええと、なぜなら、私たちは、ほとんどの場合、少なくとも、ええと、私たちの、ええと、経験が教えてくれるところでは、AI接続性またはAI統合はほぼ常に、ええと、非常に、ええと、ええと、特定のフロー、ええと、データ取り込み、その後のプロンプト構築、レスポンス構築、ええと、さまざまなプラグイン上での動作などと、非常によく整合していると確信しているからです。ええと、ここでは、flu内部のイベントの例として、pipeline committee上で確認できます。
ええと、これはすべて、ここでflu deployを見た後に行われています。そして今、Pythonで具体的にこの特定のプロンプトを実行する、非常にシンプルなテストコードがあります。Neva, SGRのチームメンバーと役割は誰か、これはイタリアの非常に大きな銀行です。ええと、そしてその後、ここにこのヘルパーツールがあります。ええと、選択肢を入力しています。最初のもの、つまりRug Pipeline関連の処理は、flumeの裏側で行われます。
ええと、そしてこれです。実際に、AIから要求した完全なレスポンスが数秒以内に返ってきています。私たちはAIについて、ええと、埋め込みやrugなどについて何も知る必要がありませんでした。しかし、この具体的なケースでは、gene AIの能力を表す、完全に動作する結果が得られています。そして今度は画像パイプライン、あるいは現在では実際にはパイプラインではなく関数と呼んでいるものに進みます。ええと、ただしこの場合、さらにシンプルなyamalファイルであることがわかります。
ですので、ええと、このonealファイルを編集し、これをあなたのflumeインスタンスにデプロイすることを想像してみてください。それだけです。あなたのプロダクトに完全に動作するAI機能が備わります。ええと、では今それをデプロイしました。そして、そして、ええと、fluが、ええと、このAI関数を取り込み、今それをテストしています。つまり、実際にこれを再びPythonから実行しようとしています。ええと、これがfluを実行するときに知っておく必要のある唯一のコードです。
実際にはFlume clientを使用し、エンドポイントと、APIキーを指定します。これは、これがあなたのFlum cloudである場合のflumeです。そうでなければ、APIキーさえ持つ必要はありません。関数IDと実際のプロンプトを指定します。ここでのプロンプトは、AIインフラへの投資を検討している投資家のグループです。では今、ええと、たぶん、はい、open AIとDollyで動作すると思います。ということで、lumを通じて実行されます。そしてすぐに答えが表示されます。
つまり、deli が生成した画像はかなりひどいものですが、機能はしています。ですから、実際には AI モデルの品質に大きく依存します。ただ flu の面白いところは、DLLquality が気に入らなければ、実際の製品アプリケーションコードを一行も変更せずに、数秒で他の任意の AI モデルに切り替えられることです。そしてこれは、別の例で、ええと、テキスト読み上げ AI 関数で、実際に実行できます。私たちはそれをデプロイしました。
さて、これはこの、ええと、プロンプトに送信しているテキストです。そして、ええと、すぐに実際の、ええと、MP3 ファイル、この場合はたぶん、または wave ファイルが得られ、それが、ええと、AI モデルからのテキストを実際に再生します。つまり、ここでの基本的なアイデアは、開発者にとっての AI アクセシビリティを簡素化し、ええと、ある程度一般化しようとしているということです。そしてご覧のとおり、AI 関数を表す、非常によく似た見た目の YAML ファイルが 3 つあります。それらは一方では非常に、ええと、似ていますが、他方では AI に関する事前知識がなくても、まったく異なることを行います。
ですので、ええと、これが基本的に、ええと、現在 flum が、ええと、できることです。ええと、私たちが melva DB を選んだ理由は、私たちが、ええと、さまざまなベクターデータベースを試し、ベンチマークしたからですが、ええと、ドキュメントと、得られたレイテンシのおかげで、私たちは VIS にすぐに惚れ込みました。それは他のものよりはるかに優れていました。ええと、そしてそれは、見た目もプロフェッショナルで、プロフェッショナルに感じられ、プロフェッショナルに動作しました。だからこそ私たちは、ええと、Novus がベクターデータベースにおける、ええと、第一候補になるとすぐにわかったのです。Novas DB の最大の、ええと、メリットだと思うのは、特にエンタープライズのケースでは、エンタープライズにおいて予測可能であることです。
ソフトウェアを構築しているとき、規模に関係なく、ええと、求めるのは予測可能性です。そのソフトウェアには、ええと、レイテンシや速度の面だけでなく、品質の面でも非常に良い結果があり、ええと、クラッシュや例外やエラーなどがないことを望みます。ええと、そしてこれが bu で見つけたものです。私たちは、BU や、ええと、他のすべてのデータデータベースで多くの異なるベンチマークをテストし、そして、ご存じのとおり、BU が正しい選択だとすぐに感じました。ええと、しかし VUS は舞台裏で正確にどのように flu を可能にしているのでしょうか？まず第一に、私たちは RUG と一般的な埋め込み検索について、完全に VUS に依存しています。つまり cosign similarity であれ、L2、ええと、IP であれ何であれ、どんな種類の検索でも常に Mel に依存しており、私たちはそれを使っています。ええと、ビデオを除くマルチモデルで、ビデオについては現在統合中、ええと、または実験中ですが、それは flu docker のデフォルトの、ええと、ベクターデータベースです。
ですから、私たちの Docker composed file で flu をインストールすると、すぐに vu も、ええと、インストールされます。そして、ええと、それは、クラウド向けのデフォルトのベクターデータベースです。ですから私たちは舞台裏で Zillow cloud を使用しています。ええと、それはスケーリング、高スループット、そして優れたパフォーマンスを提供するからであり、これこそが私たちが求めているもので、特に予測可能性と信頼性です。ええと、それで、先ほど言ったように、私たちは現在、ええと、マルチモーダルビデオの、ええと、埋め込み、ええと、cosign similarity 検索などを実験しています。ですから、重要な学びとして私が言えるのは、ええと、多くのさまざまな、ええと、100 人以上とも言える人々と協力し、Gene AI を統合しようとしている、または gene AI 統合について考えている、あるいはすでに何らかの意味で gene AI を統合している人々と関わる中で学んだことは、ほとんどの企業が現在 Gene AI を POC として維持しているということです。ええと、それが、先ほど述べたように、この大きなギャップを生み出しており、そのギャップを flu で解決しようとしているのです。ええと、さまざまな理由からです。
しかし、私が前に挙げた理由のリストは、少なくともこの特定のテーマについて私たちが感じていることだと言えます。ええと、そしてもう一つ大きなことは、私がプロダクトマネージャーと話すとき、さまざまな企業の平均的なプロダクトマネージャーに、生成AIからどのようにメリットを得ることを考えていますかと尋ねると、たいてい聞こえてくるのは、最も典型的な生成AIの例、つまりテキストとコード生成で、それだけです。そして、ええと、それは少し残念なことです。なぜなら生成AIにはそれ以上にずっと多くのことができるからです。私たちはすでに、使用可能なAI機能を何百種類も用意しており、それらは間違いなく非常に多くのさまざまなプロダクトに利益をもたらしますが、それにはインスピレーションと、そして、生成AI統合の経験が必要です。ええと、また、私たちのアプローチでは生成AIを一般化するのが難しいということも学びました。もちろん、基本的に何でも書き下せるコードライブラリではないので。
ええと、しかしそれは間違いなく実現可能であり、完全にその価値があります。そしてこれは、私たちが得ているフィードバックのおかげで学んだ最大の教訓の一つです。ええと、生成AI統合は現在、生成AI愛好家やデータサイエンスのグループ、そしてイノベーションチームに限られています。ですから、先ほど言ったように、機能統合者の大多数、開発者自身、そして現在存在する開発やデプロイの方法論の大部分を取り残しているようなものです。ええと、生成AIは多くの異なるケースで、まだ本番グレードにはなっていません。
ええと、つまりこれはfluについてです。ええと、私たちのロードマップについて2枚のスライドがあります。これを紹介できることをとても楽しみにしています。なぜなら、これは非常にまもなくリリースする予定で、すでにさまざまな企業、主にエンタープライズで使用されているからです。そこで私たちが取り組んでいる最初のことは、ええと、そして私はそれが最も難しいことだと思いますが、実際にはこの汎用化されたAI定義マークアップ言語を構築することです。つまりこれは実際には、3つの異なるステージ、3つの異なるパートで構成された言語です。最初のものは定義です。
そこで私たちは、推論とエージェントを1つのもの、1つのオブジェクトとして定義し、それをシンプルなYAMLファイルの中でAI機能と呼んでいます。そして次に設定があります。ほとんどの場合、開発者にはその設定を使って編集するだけでよいと考えています。そして次にオーケストレーション部分があります。これはCICDに非常に似ています。なぜなら、ロジックコーティングを通り、またプライバシーやセキュリティのプラグインなども通っていく、この情報の流れを定義するからです。私たちはこの全体を1つのthird GZファイルにパッケージ化し、それはAI marketplaceと呼ぶもの上で利用可能になります。ですので、ええと、そしてこれが、私たちのロードマップで紹介する2つ目のものです。
ええと、私たちはコミュニティ主導のマーケットプレイスを構築しており、このマーケットプレイスは実際に、AIのさまざまなユースケースを紹介するものです。そして、単にさまざまなプロダクトマネージャーにインスピレーションを与えるだけでなく、開発者が数分でAIを統合できるように支援するものでもあります。つまり、この特定のマーケットプレイスであなたが行う必要がある唯一のことは、たとえばテキストを音声に変換するような、自分のプロダクトで使いたいAI機能またはAI functionを見つけたら、deployをクリックするだけです。そうすれば数秒以内に、完全に動作する、本番グレード、エンタープライズグレードのAI機能が手に入り、それをあなたのプロダクトに統合でき、デバッグし、そしてカスタマイズすることなどができます。残っている唯一のことは、ここにあるように、私たちのseal lightを使って特定のAI機能をインストールすることです。ええと、これがfluです。ええと、QAの時間があると思います。私のプレゼンテーションを楽しんでいただけたなら幸いです。
ええと、ありがとうMax。素晴らしいです。ええと、質問がある場合は、下部のq and aボタンに入力してください。ええと、はい。では、質問1が見えます。現在どのAIモデルをサポートしていますか？ それで、ええと、先ほど述べたように、fluは非常にカスタマイズ性が高いです。ですので、実際には、私たちがマーケットプレイスでプラグインとして提供しているデフォルトのAIコネクターまたはモデルコネクターを使用できます。
ええと、これらのAIモデルは実際に、えー、現時点では、ええと、あー、entropicをサポートしており、open aiをサポートしており、ええと、O Lamaやその他多くのものをサポートしています。ええと、つまり実際には、現在の市場の大多数をカバーしているということですが、もし皆さんが、私たちが知らない非常に新しい最先端の、または異なるAPIスキーマのAIモデルをお持ちの場合、ええと、その場合は数分で独自のプラグインを簡単に書くことができ、そして、そして、そして独自のプラグインを書いたら、それを挿入してデバッグし、他の異なるAIモデルと同じようにAI機能を使うことができます。あー、これが答えです。はい、別の質問が見えます。はい、UbuntuでFlumeを実行できますか？ ですので、はい、もちろんFlumeはどこでも実行できます。
これはDockerコンテナで動作させるという考え方です。ええと、私たちがDockerコンテナを選んだ理由は、ええと、主に、企業が、ええと、自社の機密データを、ええと、外部のSaaS企業、特にスタートアップに、ええと、流出させることを望まないからです。そして私たちは、企業が自社内で完全な制御を必要としていると感じています。これがDockerコンテナを使っている理由です。ですので、OpenShiftのプライベート／パブリッククラウド上でも、開発者のPC上でも、どこでも実行できます。これも開発者から聞いていることです。
彼らは本当に、ええと、AIロジックを完全かつ身近に制御したいのです。ですので、これは彼ら自身のラップトップ上でも実行しているものです。ええと、別の質問が見えます。ええと、Armandoからですね、あー、エージェントとアシスタントをサポートしていますか？ ということで、エージェントは、うまくいけば、ええと、約2〜3週間でサポートする予定です。ええと、私たちがFlumeを構築していたときに得た、ええと、ある種の最大のアイデア、または概念の一つは、エージェントと直接推論APIの両方を、私たちがAI functionと呼ぶ1つのオブジェクトに抽出したことです。
なぜならエージェントは、あー、ご存じのとおり、AI専門家の観点から見ると推論とはまったく異なりますが、開発者の観点から見ると、それは基本的にはioだからです。つまり、非常に複雑な質問や実行するアクションを送るだけかもしれません。それは内部で、あー、エージェント自体の中で必要なことを何でも行い、その後この回答を返します。ですので、ええと、開発者の観点では、AI、あー、推論はAIエージェントと非常によく似ています。ですので、私たちは本当に、本当にすぐにエージェントをサポートする予定で、AMLファイル内でそれらを構築するのは、あー、とても簡単なので本当に楽しいものになるでしょう。
構築して理解するのが簡単なだけでなく、デバッグするのも本当に簡単です、ええと、そして、つまり、この、ええと、高品質なある種のグレードのAIへの接続性を持つことができます。ええと、ここに別の質問が見えます。ええと、Cとk向けのSDKはありますか？ FlumeをREST APIで使えますか。はい、Python向け、no Gs向け、あー、Java向け、ええと、rustとgo向けのC用SDKがあります、現時点で。ええと、私が忘れているものもあるかもしれませんが、それらは私たちのウェブサイトにあります。
ええと、そしてこれは中央集権型のソリューションなので、コードライブラリではなく、非常に簡単です、つまり、そのためのSDKを作成するのは簡単です。なぜなら、それは非常にシンプルな、ええと、HT DP REST APIに基づいているからです。ですので、SDKがない場合はREST APIを使うことができますが、ええと、つまり、SDKが必要なら私たちに依頼してください、おそらく数日で構築します。ええと、基本的にはそれが答えです。ええと、今のところすべての質問に回答しました。Maxに追加の質問はありますか？ もう数分待ちましょう。
はい、素晴らしいです。水を飲みます。では、では、では、はい、質問を待ちますが、でも、つまり、AIについて私が言いたいのは、私は今、ええと、約25年間コンピューターに関わっており、さまざまなフレームワークで開発してきましたし、そして、サイバー関連のことも、そして、多くの異なるアーキテクチャ、あー、超グローバル規模などにも携わってきました。つまり、AIに関しては、OpenAIがAIを発明したわけではありませんが、OpenAIはある種AIを世界に公開し、そのメッセージを伝え、そして、つまり、人々はすぐに、ここには何らかの方法で活用しなければならない爆発的なツールがあるのだと理解しました。ええと、そしてそれが、私たちがFlumeでやろうとしていることです。私たちは、この力を世の中のすべての開発者に与えなければならないと本当に信じています。
ええと、ええと、つまり、これが flu の背後にある考え方のようなものです。はい、それで、私は、ええと。はい、どうぞ。すみません。いえ、私は、私はただ言いたかったんです、なるほど、今のところ質問はもうないようですね。
ええと、そして私たちはまだ始めたばかりです。ええと、もし何かフィードバックや質問があれば、私たちのウェブサイトや GitHub リポジトリ、LinkedIn プロフィールなど、何でも訪れてください。ええと、とにかく、質問して、そして私たちのコミュニティに参加してください。これを作っていくのは、本当に楽しいプロセスだと思います。素晴らしいです。
ええと、Max、お時間をいただき本当にありがとうございます。そして、ええと、あなたが今後どんな素晴らしいものを作っていくのか楽しみにしています。Steffi、ええと、これを設定してくれて本当にありがとうございます。そして、皆さん、ええと、聞いてくださってありがとうございます。ええと、以上です。また後でお会いしましょう。
ありがとうございます。バイバイ。ありがとうございます。