- Events
Milvus、Ollama、Llama Agentsを使ってローカルでAgentic RAGを構築する
トレーニング
Milvus、Ollama、Llama Agentsを使ってローカルでAgentic RAGを構築する
Join the Webinar
Loading...
セッションについて
最近リリースされたLlama Agentsにより、非同期ファーストで独自のサービスとして実行されるエージェントを構築できるようになりました。このウェビナーでは、StephenがLlama AgentsとMilvusを使用してAgentic RAG Systemを構築する方法を紹介します。
取り上げるトピック:
- エージェントが計画、メモリ、ツールを活用してさまざまなタスクを達成できるようにする方法。
- マルチエージェントフレームワークを使用し、カスタムのユーザー定義関数を呼び出せるようにすることで、RAGシステムを強化する方法。
- ハルシネーションなどの一般的な問題と、エージェントが自ら修正を試みられるようにフォールバックおよび自己修正メカニズムを追加する方法。
本日は、Mr. Ai BUおよびLAMAエージェントとの「マルチエージェントシステム」セッションと、ゲストスピーカーのStephan bpoをご紹介できることを嬉しく思います。StephanはZillowのデベロッパーアドボケイトで、以前はWaltで機械学習エンジニアとして働き、そこでMLプラットフォームを作成し、取り組んでいました。またそれ以前はB Bravoでデータサイエンティストを務めていました。Stefanはコンピューターサイエンスと人工知能を学びました。
彼はm LopsコミュニティBerlin Groupの創設メンバーで、そこでミートアップやハッカソンを企画しています。また、ボクシングとサーフィンも楽しんでいます。ようこそ、Stephan。どうもありがとうございます。ご紹介ありがとうございます。
本日はお越しいただきありがとうございます。ええ、はい。それでは、mic、ai、vis、LAMA agentを使ったマルチシステムについてお話しします。このプレゼンテーションの後半ではデモも行う予定で、実際にそれをどのように構築するかをお見せします。また、すべてが決定論的というわけではないこともご覧いただけるでしょう。ですので、気に入る回答が得られることもあれば、そうでないこともあります。
ですので、デモで正しい回答が出ることを願っています。ええ、見た目はいいのですが、私のことをご存じない方のために、まず自己紹介から始めます。はい、私はStefanで、zilliのデベロッパーアドボケイトです。そしてVisについて、もし何か質問があれば、気軽にメールを送ったり、LinkedInやTwitterでチャットしたりしてください。基本的にどこにでもいます。
ええと、visに関することでも、AI全般に関することでも、生成AIエージェントに関することでも、何でも聞いてください。通常、私が取り組んでいるのはそういったことです。そして続ける前に、Visについて少し紹介します。ご存じない方のために、私たちが誰で、何をしているのかを説明します。それから、デジタルな異なるエージェントについて話し始めます。visはLinux FoundationのAIand dataの一部です。そして私たちは、ええと、つまりZ sorry、visのキーコンテナです。
そして、私たちはLinux Foundationを卒業しています。GitHubには多くの異なる、多くのスターがあります。28,000以上あります。また、それを学んでいる人もたくさんいます。10,000社以上の企業が私たちを、おそらく本番環境で使っています。
しかしクールなのは、malwareでは簡単なセットアップから始められることです。つまりPIP in storeで開始し、ノートブック内で直接コーディングできます。しかしその後、非常に素早く、例えばcapabilities上にVISをデプロイしたり、クラウドでzillsを使ったりするところへ移行できます。また、さまざまなパートナーとの統合もあります。open ai、link Chain、LAMA Index、さまざまなもの、そしてFeature Richでもあります。
つまり、d embeddings、par embeddings filtering、re ranking、そして他にも多くのことをサポートしています。実際、本日は、エージェントを使ってmeta filteringを行う方法を見ていきます。そこでは、先ほど述べたように、エージェントが実際に自分たちでmetadata filteringを作成します。さまざまなAIツールキットとの統合があります。ですのでL Chain、LA Indexは最も有名な2つですが、D-S-P-Y-L use in ai、Voya ai、その他多くのパートナーとも連携しています。したがって、私たちのドキュメントで直接確認できます。vis ioで、さまざまなパートナーとの統合を確認できます。
まずRAGの概念を紹介します。全員がそれに詳しいかどうかわからないためです。その後、RAGの制限を簡単に見て、それからエージェントの部分により入っていきます。RAGはRetrieval, augment Generationのことで、基本的な考え方は、ULLMにあなたのデータを使って動作するよう強制することです。そしてそれをどう行うかというと、visのようなVector databaseに注入することで行います。基本的なアーキテクチャはこれです。
それでデータがあるとして、次にいくつかのコンテンツを抽出します。いわゆるチャンキングを行います。ええと、つまり、データの一部を取り出すようなことです。そしてすべてを埋め込みモデルに通し、それからすべてをVisに保存します。ユーザーからクエリが来たら、行うことは再び、それを埋め込みモデルに通すことです。前に使ったものと同じモデルです。そしてセマンティック検索と呼ばれるものを行います。つまり、クエリと意味的に類似したものを検索します。
するとMiddle Westが類似データを返します。すべてをLLMのコンテキストに戻し、そしてLLMが応答を生成し、その応答をユーザーに渡します。これが基本的な生のアーキテクチャです。ええと、これは基本的に5行のコードでできるものです。それが一例です。
もしあなたが、もしLAMA indexを使っているなら、ええと、データをロードして、それをVectorstoreに入れ、そしてクエリエンジンを構築し、それからクエリを実行できます。そして基本的にはそれだけです。うーん、だから、かなり良いものです。とても手早いものです。ええと、それで、調べたいドキュメントがある場合には、とても役に立つことがあります。ええと、しかし通常それだけでは十分ではありません。なぜならNA RAGは良いものですが、NA RAGは少し限定的だからです。つまり、異なる価値モードがあります。
そのうちの一つが要約です。つまり、RAGはセマンティック検索と密接に関連しているので、ドキュメントを要約するには、基本的にドキュメント全体を取得しなければなりません。そしてra、つまりRAGはそのために設計されていません。うーん、ですから通常、ドキュメントの要約には苦労することがあります。また、暗黙的なデータにも苦労することがあります。
つまり、もし質問をした場合、ええと、例えば、米国株で最もレビュー収益が高い会社は何ですか？のような質問です。すると、それはあなたのデータに対してセマンティック検索のようなことを行います。しかし、この情報がない場合、それについては分かりません。ですからまた、ドキュメントにそれが明示的に書かれている必要があります。つまり、そうでなければ、それがない場合には、見つけられない可能性が高いです。だからそれが、あなたが直面するかもしれない問題です。そういう場合には、ええと、別のツールを使う必要があります。
ええと、複数の質問にも苦労することがあります。つまり、複数の質問をすると、ラックシステムが一つを飛ばしてしまうか、適切に答えられないかもしれません。うーん、だからそれも、naive ragの失敗における苦労のようなものです。要するに、ええと、RAGはとても有用です。誤解しないでください。ええと、しかし基本的には必要ではあるが十分ではありません。なぜなら、うーん、多くのタスクはセマンティック検索に関連していますが、それ以外のタスクもあり、つまり、それ以上のものを必要とする場合があるからです。
そしてこれから、基本的なcrackの限界を超えるにはどうするのかを見ていきます。しかしまず、皆さんへのリマインダーです。ええと、私はML分野全体で何年も働いてきましたが、以前は「garbage in, garbage out」というものがありました。うーん、そして今ではそれはちょっとしたリマインダーで、つまり、良い料理は良い食材から生まれるということです。ですから、それでもデータ収集が良いものであることを確認しなければなりません。データクリーニングも良く、パースとチャンキングも良い必要があります。つまり、データ収集が良くなければ、ラックシステムがうまく機能することは期待できません。
ええと、そして、つまり、クリーニングが良くない場合も同じです。つまり、RLMは、RLMにとってノイズになる多くのものによって混乱することになります。そしてチャンキングも同じです。つまり、チャンキングが少し小さすぎる場合、ええと、または大きすぎる場合、RLMも混乱します。基本的に見方としては、もしあなた自身が、ええと、そのチャンクを理解できず、そしてコンテキストを本当に理解できないなら、LLMがそれを行うのは非常に難しくなる、ということです。
では、たとえばBDFsのように異なるドキュメントがある場合、lmsの容量を考えると、今では1 pa 1ページが、ええ、良いものになり得ます。ええ、ただその場合でも、段落ごとにchunkしたり、あるいはいくつかのsuper chunksを作って、さらに小さなchunksを作ったり、あるいはsummary chunkを持ち、さらに小さなchunkも持つ、ということもできるかもしれません。ええ、そういったものは、もしそれで苦労したくないなら、あなたのLLMにとって非常に役立ちます。ええ、私たちにはzills pipelineと呼ばれるものがあり、ええ、それはzills cloudで利用可能で、基本的に最先端のingestion pipelineを持っています。つまり、たとえば、ええと、良いchunkingがあるので、悪いchunkingを抱えて、そのために悪いrack systemを持つことで苦労する必要がありません。
ただ話を戻すと、na rag、これはNA rack pipelineで、それは良いものですが、とはいえ、これはsingle shotだけです。つまり、すべての質問がまったく新しいものになります。前の質問の記憶はありません。query understandingもplanningもありません。ええと、実際にはツールも使いません。またcorrectionもerror correctionsもなく、memoryもありません。
つまり、それがない小さなもののようなもので、本当に毎回クエリを投げるたびに、rack systemを再び通らなければならないということです。ええ、一方で、たとえばmemory内の何かを使うこともできます。ですから、それを改善したいときに覚えておくべきことの1つは、どのように改善したいのかを本当に測定したい、ということです。それは別の講演になります。ええ、でも、そうですね、覚えておいてください。もし本当に何かに取り組み、どうやってそれを証明するのかを測定したいなら、ええ、それを測定しなければなりません。
ええと、それはたとえば、golden data setsのようなものを用意することでも可能です。基本的には、自分自身が答えを知っていて、それから自分のrack systemが実際にその質問に適切に答えているかを確認する、というものです。ええと、そしてLMSを使ってLLMsを評価することもできます。それについてはinternet上に多くのdocumentationがあります。ええ、見てみるとよいでしょう。でも今はAgent Craigについて話しましょう。
これはクールで、クールで、クールで、基本的に今街で新しくクールなものです。ええ、そしてAgent Craigはmulti turnです。つまり、エージェントが質問を理解し、それから複数のステップで計画できます。これは非常に良いことです。ええ、また外部環境向けのtool interfaceもあります。
つまり、internetをbrowseする必要がある場合、ええ、そのエージェントは実際にこのtoolを使うことを決定し、それからinternetをbrosしてdataを取得し、そしてたとえばそれをLLMのcontextにintegrateできます。そうすれば答えを出せます。ええ、またreflectionもあり、ええ、そしてpersonalizationのためのmemoryもあります。ですから、今ではそれが、つまり、それは、はるかに良くなり得ることがわかります。ええ、そしてsingle shotsだけではありません。実際に、ほら、あなたのagentはtoolを使い、それがその後、ええと、ragをcallし、それからagentに戻り、そして実際に答えに満足するまでそれをloopできます。
ですから、さまざまな方法があります。ええ、1つ目はself reflectionです。つまり、queryがあり、それからdocumentsのchunksがあり、そして確認します。つまり、それらはtop K ribbon chunksを取得し、ええ、そして確認します。たとえば、okay、そのうちいくつかは正しいが、いくつかは曖昧だ、というように。ですから、曖昧なものについては、あなたのagentがinternetを検索して検証できます。そして、つまり、その後、internet上にあるdataと、database内にあるdataを比較できます。
そして、たとえば、okay、実際には、ほら、それはdatabaseにあるものと一致している、となります。5つの異なるwebsitesから5つの異なるresultsがあります。それらはだいたい同じことを言っています。ですから、それでかなり満足できます。それから答えをA LMに返し、そしてuserに答えを返すことができます。
それが1つ目です。それから、クエリルーティングと呼ばれるものもあります。つまり、クエリがあって、それをエージェントに通すと、エージェントが「ああ、これについてはデータベースを確認する必要があるのか、それとも直接どこか別の場所に行くのか？」という感じで判断します。つまり、例えばデータベースに、世界のさまざまな企業の財務状況についてのデータがあるとして、エージェントに、ええと、世界の動物園について何か質問した場合、データベースにはその情報がないと判断できます。なので、単に検索を行うのではなく、その部分を完全にスキップできます。そして、別のことを行うことができます。
つまり、インターネットにアクセスして、動物園について、ええと、さまざまな場所の情報を確認できます。これも可能な部分です。これがスクエアルーティングです。それから、サブクエリを伴うクエリルーティングがあります。ええと、これも非常に便利なものの1つです。
つまり、1つのクエリを持つのではなく、ええと、それを複数の別々のクエリに分割できて、それから、それぞれのクエリに対して検索を行います。例えば複数の質問がある場合、ええと、milli vis とは何か、zills とは何か、ええと、これらは2つの別々の質問のように扱えます。そうすると最初のものは、ええと、vis とは何か？になります。そして2つ目のクエリは、zills とは何か、になります。そして両方のクエリに対してベクトル検索を行います。ええと、そして両方の回答の top K を取得します。
それから、その2つを lm に組み合わせて渡し、それをユーザーに返します、すみません、回答として返します。つまり、これらは、より良い結果を得たり、複雑なクエリを調整したりするための、さまざまな方法です。それから会話メモリもあります。つまり、クエリがあって、RAG システムを通過し、それからすべてをメモリに保存します。基本的には履歴をコンテキストに戻して渡します。
そしてこれは、chat GPT でチャットがどのように機能するかの一例です。ここで注意しなければならない唯一のことは、実際には、ええと、履歴のコンテキストを多く入れるほど、コンテキストウィンドウのサイズを超えてしまう可能性もあるということです。なので賢く対応する必要があり、ええと、履歴を少し要約しなければならないかもしれません。そうすればまだ収まります。つまり、ただ追加して追加して追加していくことはできません。なぜなら、ある時点で、ええと、あなたのコンテキストウィンドウより大きくなってしまうからです。だから、それを常に覚えておく必要があります。
そして、ええと、react prompting と呼ばれるものがあります。これはアクションにつながる推論です。これは、ええと、基本的に LLM のさまざまな推論能力を統合するように設計されています。そして、アクションステップを取ることも可能です。クエリを行うと、後でデモ中にライブで見ますが、ええと、クエリを行うと、「はい、このクエリにはこのツールを使う必要があります」という感じになります。
そして実際に質問に答えていることを確認します。そして質問に答えているなら、結果を返します。そうすることで、情報を理解し処理し、ええと、状況を本当に評価することができます。そして適切なアクションを取ることもできます。また、いくつかの応答をあなたに伝えます。
そして状況を本当に追跡し続けます。本当に追跡していて、「ああ、なるほど、最初の質問は vis とは何か？だった。それを尋ねている。そして、インターネットをブラウズするような別のツールを使っている。それでも、自分がなぜそうしているのか、そして実際にユーザーに回答できたのかを確認するために追跡し続けている」という感じです。実際には、ええと、次のようになります。最初の思考を見ることができます。つまり、Apple remote についての質問です。ええと、そして最初の行動は実際に Apple remote を検索することだとわかります。
次に観察結果があります。ええと、それは検索の結果で、つまり上部のリモコンです。ええと、それから、まあ、二つ目の考えが浮かびます。なぜなら、もう一方の回答にあまり満足していないからです。それで、ええと、また本当に、つまり、別の検索をすることになり、それは front row に関するものです。たとえばここでは、front row が見つかりません。そこで、つまり、似たものを検索するわけです。
それで front row software を見つけます。これは似ていますし、それから、まあ、いろいろなものがあります。それで別の考えが浮かび、front row software を検索します。ええと、そして最後に最終的な考えとして、front row software は Apple remote またはキーボードのファンクションキーで制御される、ということになります。ええと、それからアクションとして完了します。ええと、そしてそれをユーザーに返すことができて、まあ、つまり実際には、ええと、結果はキーボードの、ええと、ファンクションキーです、という感じになります。はい、これが基本的に react prompting の仕組みです。
ええと、そしてまた、後で私のエージェントで使うものなので、実際に動いているところを見ることになります。それから何度も言いましたが、Agentry はツールを使えるようにしてくれます。ええと、たとえば、つまり、クエリがあって自動検索をしたいとします。そうするとクエリを持つことができ、LLM が実際に、ええと、このクエリを生成します。つまり、たとえばメタ metadata 用など、すべてに対してです。しかし、テキストから SQL を生成するようなものを持つこともできます。つまり、テキストであるクエリを NLM に通すと、ええと、実行できる sequel が返ってきて、つまり、それが答えを返してくれますが、別のツールも使えます。
カレンダーのようなものを通すこともできます。たとえば Google Calendar に接続すると、ええと、そうすると、よし、Han が明日空いているか確認する必要がある、というようにできます。ええと、すると Google Calendar 用の API も推論して、結果を返してくれます。ええと、その後、その答えをユーザーに返すことができます。基本的にそれが agent rag です。ええと、これから、実際にすべてをどう構築したかについて、もう少し深く入っていきます。
では、まずスタックについて話して、それから直接デモに入ります。今回、私はまず LAMA index を使っています。ええと、LAMA Index は LM アプリケーションを構築するためのフレームワークで、データの取得とさまざまな lms との統合に本当に重点を置いています。多くの AI ツールとの統合があり、本当に、本当にたくさんの AI ツールがあります。しかし最近、本当に LAMA agent と呼ばれるものがあります。
そして LAMA agent は LAMA index によって作られています。何かというと、オープンソースです。ええと、N LMS とマルチエージェントワークフローを使ってステートフルなアプリを構築できるようにしてくれます。cycle や branching もあります。human in the loop も可能です。永続化もできます。
たとえば、エージェントシステムを構築して、たとえばカスタマーサポートで働いているとします。その場合、実際に、つまり、顧客に新しいチケットか何かを発行する前に、人間にそれを検証してもらうよう求めることができ、つまり、よし、ここで止めて、このアクションが実際に起こるべきかどうかを人間に尋ねてください、というようにできます。そしてそれが起こる場合、人間が yes と言えば、アクションを続行できます。つまり、それができることの一つですが、マルチエージェントを実際に整理するのが本当に得意です。そして、右側にコンポーネントが見えると思います。そこを拡大します。
それで、コンポーネント部分についてですが、ユーザーがいて、それからコントロールプレーンもあります。これは、つまり、すべてのようなものを持っています。なのでこれ、コントロールプレーンは本当に LAMA 管理システムへの中央ゲートウェイのようなものです。つまり、現在のタスクだけでなく、システムに登録されているサービスも実際に追跡しています。そして、オーケストレーターを保持しているのもこれです。そしてオーケストレーターは本当に、つまり、受信タスクを処理し、さらにそれをどのサービスに送るかを決定するモジュールのようなものです。
つまり、サービスからの異なる結果をどう処理するかも同様です。そして、オーケストレーターはエージェントにすることができます。つまり、NLM が判断を下している場合もありますし、明示的にすることもできます。その場合はフローを定義でき、そして、つまり、非常に具体的なものをたどることができます。また、必要であれば両方を混ぜることもできます。それから、さまざまなサービスがあります。
ここで、さまざまなエージェントサービスを見ることができます。つまり、基本的に実際の作業が行われる場所です。つまり、サービスは受信タスクと、与えられたコンテキストを受け取り、それを処理して、すべてを結果として公開します。そして、ツールサービスは基本的に、エージェントツールの競争に取り組むために使われる特別なサービスのようなものです。なぜなら、それらも非常に重くなることがあるからです。つまり、それが LA my agent で、これを後で使います。
ええ、それがさまざまなコンポーネントです。そしてそうすることで、また、つまり本当に異なるエージェントを持つことで、すみません、個別のレベルで、それぞれ異なるエージェントサービスをスケールアップおよびスケールダウンすることもできます。なので、これは LLM にとって場合によっては非常に便利です。そして EM 埋め込みモデルについては、missile ai の LMS を使う予定です。私が知っている人向けに言うと、missile AI はフランス拠点の研究ラボです。そして彼らは最近、オープンソースモデルのようなものを公開しました。
彼らは本当に、私はオープンソースモデルに注力していると思います。実際、彼らはここ数週間で 2 つリリースしました。最初のものは mis で、128,000 のコンテキスト長を持つ 120 億モデルです。そしてこれは、そのサイズの割に関数呼び出しと検索に非常に強いです。また、例えば all AMA を使ってローカルで実行することもできます。
それが私が使うものです。そして、より複雑なタスクには、miss all large two を使う予定です。これは 1,230 億パラメータで、同じく 128,000 のコンタクト長を持っています。そしてこれも、実際に関数カーリングと検索スキルを使えるようにファインチューニングされています。なので、これらは brag と関数カーリングに本当に非常に優れています。そしてメインモデルについては、ral のものを使っているだけです。なぜなら、それも検索に注力されており、残念ながら rag には非常に有用だからです。
私が確認したときは英語のみでした。もし別の言語のものがある場合は、別の埋め込みモデルを使う必要があるかもしれません。また、VIS lights も使う予定です。Elvis からのすべては私の laptop で動きます。VIS Light の良いところは、vis によって PIP ツールを実行するだけで、基本的に vis lightweight のようなものが laptop 上にすべて揃うことです。
それから、ええと、VIS をクラウドで使いたい場合は、コードの URI を変更するだけです。つまり、ほら、見ていくと、私が呼び出しているのはローカルファイルなんですが、もし capabilities 上に何かを置くのであれば、クラスターの URI を入れる必要があり、cloud がある場合も同じなんです、わかりますよね？つまり基本的にはコードを1行だけ変更すればよくて、ええと、それ以外はすべてサポートされています。で、はい、これからデモの時間です。では実際に、ええと、私が見せたいものが動くか見てみましょう。というのも免責事項として、私のエージェントたちは、すべてが非決定的なので、通常は動くんですが、ときどき、ええと、本来やるべきことをやりたくないと決めてしまうことがあります。ええと、なので Agency General を使う上での大きな問題もそこにあって、はい、とても便利ではあります。ええと、なぜなら、ほら、自分で本当に判断させることができるからです。でも、ときどき気まぐれになることもあります。
では見てみましょう。今日は何があるか見てみましょう。ええと、でも、はい、始めましょう。こちらにこのデモがあって、これは VIS と ral を使った Lama agent を使用しています。つまり、vis については話しましたね。
こちらでは VIS Light を使っています。ええと、それから LAMA agent を使います。私のエージェントは私たちのマイクロサービスを実行していて、それから ral ai を使っています。ええと、さまざまなモデルです。はい、基本的には見ていきます。インターネットからデータを取得し、それを、ええと、vis に保存します。ええと、データクエリには Mistral と LAMA Index を使います。それから自動のデータ検索および読み取りエージェントを作成します。
それから、ユーザークエリに基づいて made filtering を作成するエージェントを用意します。そしてすべてが自動的に行われます。わかりますよね、なので見ていただけます。ええと、それから、はい、すべて動くはずです。デモのためだけに、依存関係はインストールしません。すでにインストールされているからです。ええと、でも、ほら、pre installed LAMAagent のようなものが見えますし、VIS も同様です。そしてそうすることで、vis slides をインストールするだけです。
それからここでは、LAMA Index との統合をインストールしています。ええと、また、ほら、ファイルを読み取れるようにするものです。ええと、それから Llamato を使って ral Namo を自分のラップトップ上でローカルに実行しています。なのでそれもインストールしています。ええと、それから、 um, RAL ai との統合です。埋め込みモデルについても同様です。
Um, これを実行します。ええと、これはエージェントに必要だからです。本当に、基本的に必要なんです。そうしないと、EEO in notebooks が満足しないと思います。なので、ええと、これは coding notebook 上で実行する場合にのみ必要だと言っておきます。API キーを、ええと、Israel からインポートします。もし持っていなければ、ええと、彼らのウェブサイトに行って追加できます。Um, でもこの方法では、ローカルにファイルを持っていて、それは end file で、そこから認証情報を読み取っているだけです。ええと、このデータがあります。ええと、これはお見せしますが、Uber と Lyft の財務データです。
ちょっとだけお見せします。ええと、見てわかるように、これは、ほら、米国の security exchange commission からのものです。ええと、これは Uber technology についてのもので、年次報告書です。わかりますよね。そしてもう1つ、Lyft のものがあり、同じようなものです。ほら、とても似た形式です。これは Lyft についてのものです。ええと、さまざまな、ほら、d のような、大量の文書があるのが見えます。そして238ページあります。もう一方は300ページあります。
なので、これらはかなり長い文書です。ええと、でもいずれにしても、すべて保存します。なので、ええと、すでにデータはダウンロードしてあるので、その必要はありませんが、ここからは埋め込みモデルを準備します。mis embed を使っています。ほら、先ほど言ったように、ええと、ral によって開発されていて、RAL モデルを使うつもりなので、私は、わかりました、たぶんこれらも使いましょう、という感じでした。なので、um, これから使うデフォルトの埋め込みモデルを定義しているだけです。ええと、すべての la my index 用です。
それでここで定義して、それから、はい、Miss Embeddingsをmiss embedモデルで使ってください、と言っているだけです。そして、私が使うデフォルトモデルも定義しています。すでに何度も言っていますが、ええと、私はalamaを使います。ええと、Ulamaを使うと、モデルを自分のノートPC上でローカルに実行できます。それもとても簡単にしてくれます。
ええと、それから、ええと、デフォルトでもまた、はい、ral nemoを使います、と言っています。Ral NEMOは120億パラメータの、ええと、モデルです。では、これからvisをインスタンス化して、いくつかデータを読み込みます。ええと、ここにあります。これらは前に示した2つのファイルです。そしてここでvisを作成しています。ええと、VIS Vector storeがあり、これはLAMA Indexとの直接統合です。
そしてここでURIが見えます。このURIは、ええと、ローカルファイルです。ここでURIをローカルファイルとして定義すると、VISはVIS lightを使うのだと認識します。もし、例えば、ities上の何かを使いたい場合は、URIを変更する必要があり、それは、よくわかりませんが、例えばcluster、ええと、gcp、do EU West oneのようになります。ええと、そうすると、はい、実際には別の場所に行く必要があるのだと認識します。そしてこれにはMilli slideを使いたいのですが、ここではこれに戻します。ええと、次元を1024にしています。ええと、それは埋め込みモデルの次元だからです。
Talによってoverride trueと言っています。ええと、私は危険に生きるのが好きなので、実際にはデータベース内にあるものをすべて上書きします。それから、ええと、コレクション名があります。ええと、それはComp Compan Company, companys Docs、すみません。つまり、コレクションの名前にすぎません。それからストレージコンテキストを作成します。ええと、VISをベクトルストアとして使います。ええと、それからデータを直接読み込みます。
ええと、つまり、データをメモリに読み込んで、それからインデックスを構築します。これで、インデックスを構築するとき、実際には、はい、メモリ内にあるドキュメントで、ええと、インデックスを構築してください、そして前に定義したストレージコンテキストを使ってください、と言っていることになります。そしてこれは、つまり、VISがインストールされていてすべてが揃っているものです。それからここでクエリエンジンを定義します。実行します。ええと、少し時間がかかりますが、それほど長くはならないはずです。そして、はい、ここがクエリエンジンです。
基本的に、上位3件だけ返してください、と言っています。ええと、例えば10件の結果などを返す必要はありません。なので今はインデックスを構築しています。時間の都合で先に進みますが、ここからが面白い部分の始まりです。ここでは、LLMがアクセスできるさまざまなツールを定義しています。
つまりこれは、例えば、特定のデータベースをブラウズするツールを持ちたい場合や、別のツールがGoogle Calendarに接続する場合に、それらをどう定義するか、ということです。それから、ええと、これは、ええと、クエリエンジンツールを定義していて、実際にはLyftについてだけのものです。つまりLyftドキュメントについてだけです。ええと、そして情報を提供します。つまり、説明を書かなければならず、そうすることでエージェントがどのツールをいつ使うべきかを理解します。これは、ええと、2021年のLyftの財務に関する情報を提供します。ええと、それから、ツールへの入力としてtype plan text questionを使用してください、と言っています。
また、データを解釈したり要約したりしようとしないでください、とも言っています。本当にそのまま欲しいだけです。ええと、そしてUberについても同じものがあります。ええと、Uberについては、つまり、Uber 10 Kで、それからここでは、2021年のUberの財務に関する情報を提供する、というようになります。ええと、そして他の質問は同じなので、それらを定義するだけにします。ええと、これでそれらは定義されました。ええと、しかし次に、エージェントに実際に何を、ええと、それらを使えることを伝える必要があります。
それで、ここでエージェントを設定しています。なので、私のLLMはまた同じで、つまり、ローカルで動かしているvisceral memoです。そしてエージェントは、ええと、react agentsになります。reactは、覚えていれば、前にお見せしたもので、つまり、LLMを使って実際に判断を行い、考え、クエリを分割して、実際に質問に答えていることを確認するものです。ええと、なのでそれを使います。それから、はい、ええと、利用可能なツールはこれです、と言っています。
query engine toolsは、上で定義したものです。つまり、ここにある2つのツールです。ええと、それからLLMを定義してください、そして variables を true にしています。単に、何が起きているかをよりよく見えるようにするためです。ええと、質問があります。それは、2021年のLyftとUberの総収益の比較を提供してもらえますか？というものです。ええと、それからレスポンスがあります。ここで確認できますが、ええと、これが私たちが与える入力です。
つまり、これは私が書いたものそのものです。それから、LLMの思考プロセスを見ることができます。ユーザーは、2021年のLyftとUberの総収益の比較について質問していて、この情報を見つけるためにツールを使う必要があります。すると、ああ、実際には、定義されている最初のツールを使う必要がある、となります。それはLyft 10 Kで、ええと、上で定義したもの、つまり、ええと、これです。
ええと、それから入力を与えています。ええと、2021年のLyftの総収益はいくらでしたか。2021年、すみません。これは私が自分で書いたものではありません。つまり、本当にLLMがその質問を2つの異なる質問に分割したのです。それで私たちのドキュメントを調べます。
観察結果はここにあります。つまり、2021年のLyftの総収益は36億でした。そして、はい、次に2021年のUberの総収益を調べる必要がある、となります。それで別のアクションにも進みます。それはUber 10 Kで、別のものです。
そして質問を、2021年のUberの総収益はいくらでしたか？に変えました。それから答えを見つけます。つまり、2021年のUberの総収益は170億でした。ええと、そして、はい、満足です、必要な情報はすべて集めました、ええと、ユーザーの言語は英語なので、2021年のLyftとUberの収益を比較できます、なぜなら両方を持っているからです。答えはここで見られます。2021年、Lyftの総収益は36億で、Uberは170億でした。これは、その年UberがLyftの4倍以上の収益を上げていたことを示しています。
そして、それが基本的にユーザーに返す答えです。なので、それが全体の、つまり、それが全体のverbal mode、すみません。ええと、でもそれがなければ、それは見えませんが、基本的には答えを得ることになります。いいですか？ええと、Lyftは36億で、Uberは170億でした。
これで、LLMが意味のある場合に質問を異なるクエリに分割できること、そして時には本当に考えることができることを見てきました。ええと、でも、はい、これは面白いです。ただ、想像してみてください。私は今、2つのドキュメントのために2つのツールを作る必要がありました。ここにあるのはそういうものです。つまり、これがあり、それから、でも、もし私が、分かりませんが、100社や1000社を持っていたらどうでしょう。私が金融アナリストだと想像してみてください。
ええと、すべての会社について別々のツールを作成しなければならないのは嫌です。欲しいのは1つのツールで、それは、つまり、私が持っているすべての会社に関するものですが、そのうえでいくつかのメタフィルタリングを作成できることです。つまり、たとえば会社名やドキュメント名でフィルタリングして、それからアクセスしたいデータだけを検索できるようにします。Uberを検索したいなら、Uberだけを検索するべきです。コレクション全体を検索する必要はありません。
それが、今やろうとしていることです。ええと、はい、基本的にはそれが私たちにあるもので、つまり、より高い精度、より効率的なものがあり、そしてさまざまなものをカスタマイズできます。ここでは、何をフィルタリングしたいかが分かっているときに、mainten filtering を使う方法の例をお見せしています。この例では、完全一致フィルターでフィルタリングします。つまり、fine name です。そして、Uber 21、Uber 2021 を指定したいです。
ですので、本当にこの1つだけでフィルタリングします。実は Lyft にしたいです。いや、Uber にしましょう。では Uber があり、これでフィルターが作成されました。そこで、再び agent を作成して、それからこれとやり取りしていきます。
これで、Uber の business business overview は何ですか？と尋ねます。そして、フィルタリングしている私の mates は Uberdocuments のみなので、何か見つかるはずです。見てみましょう。少し時間がかかります。ええと、もう1つの質問は同じですが、lift についてです。少し遅いので、両方実行します。
では、私の agent がデータを見つけるかどうか見てみましょう。私が持っている meta filtering のようなもので。つまり、見ることもできます。質問をすると、彼は「tool を使う必要がある」となります。そしてその tool は company docs を使っています。これは私が定義した新しい tool で、つまり、より広いものです。特定の会社について本当に具体的なものではありません。では、Uber についていくつかの observation が見えます。
ええと、はい、それから本当にそのまま続いていきます。これはかなり長くなることがあります。agent が回答に満足しているかどうかによりますし、agent が満足するかどうか分かりません。なぜなら、action についてループしているように見えるからです。ええと、agent を使うときに時々ある問題が少しこれで、つまり、彼らは時々回答に完全には満足せず、それでループして、何かを見つけようとして、本当に答えを見つけようとして、最大 iteration に達するまで続けます。ええと、今それをやっているように見えますし、これもデモ効果の一部だと思います。とはいえ、observation は実際には正しいことが分かります。
たとえば business overview を尋ねると、それは global technology platform で、さまざまなものをつなぐものです。ええと、でも、とりあえずこれはそのままにしておきます。もう少しで終わるはずなので。その一方で私がしたいのは、agent を使って metadata filtering を抽出することです。なぜなら、ここを見れば分かるように、上では、ここで手動で定義しています。つまり、filters を定義しているのですが、やはり、そんなことを全部に対してやりたくはありません。クエリを入力するだけにしたいのです。そして、そのクエリで、回答を直接得られるようにしたいのです。おそらくこれを確認します。
これはすぐ止めると思います。ええと、でもそれ以外はお見せしますし、もし終わっていなければ止めて、それからこれに戻れます。ここで、だから prompt があります。prompt template があり、これは LLM に「ねえ、何か具体的なものが与えられたら、いくつかの action ができる」と伝えるものです。この場合、LLM に質問を渡していて、本当に、次の質問が与えられたら、関連する metadata filters を抽出してください、という感じです。company names、years、そしてその他の関連する attributes を考慮してください。
つまり、LLM に、私が metadata filtering と見なすもの、そして重要だと見なすものを伝えるためだけのものです。でも同時に、「他のテキストは書かないでください」とも言っています。実際には metadata filter object だけが欲しいのです。そして、format する方法を説明しています。なぜなら、LLM は meta are filtering や、この object のことを特に知らないかもしれないからです。なので、「filters を作成して format してください。以下のように示します」という感じです。これがここにあるものです。
ええと、これは、ええと、上でも使っている例です。つまり、さまざまなフィルターを使ったフィルターのようなものです。そして、もし、ええと、私が言及した特定のフィルターがない場合は、red 91、ええと、それから質問を渡して、ええと、基本的にはそれを返します。なので、それが、ええと、私たちが持っているものです。ええと、それからまた Mr.
Nemo を使って、ええと、それから回答が得られます。そしてここで基本的に確認していて、回答を評価して、実際に Python でオブジェクトを構築し、ええと、それを使うようにしています。でもこれはまだ実行中だと思います。そうですね、これは残念ながらまだ実行中です。ええと、すぐに止めます。
なので、これもデモ効果の一部だと思います。すみません、ノートブックをすぐに再起動します。ええと、そうしないとちゃんと動かないので。ここはかなり素早く進めます。ええと、これらは私が定義しているツールのようなもので、また私のエージェント、ええと、そしてこれは、ええと、スキップします。ループしているように見えますし、残りが、ええと、10分しかないので、そんなに長く待ちたくありません。
ええと、でも考え方としては、その後、つまり、Lyft の答えは実際には見つけられません。Uber でフィルタリングしているからです。なので、これは後で実行します。そして実行されたら、ええと、質問できます。つまり、Uber の収益はいくらですか？というようなものです。ええと、そしてこれについては、まだ賢くありません。私のエージェントは、ええと、すべてを推論できるほどまだ賢くありません。ええと、なぜなら、私のメタデータキーのいくつかは、ええと、とても具体的だからです。つまり、実際には file name のようなもので、それからファイル名があります。
ええと、でもそれは基本的に、あなたが持っているメタデータフィルタリングに本当に依存します。なのでこれについては、私は、オーケー、これは fine name Uber 22 1 PDF の中にあるはずだ、ええと、そしてそれが得られたら、ええと、うまくいけば実際に、ええと、met is drink ができるはずです。でも今ちょっとデモ効果が出ているので、自分のエージェントのどこにいるのか確認しようとしています。オーケー、今またすべてを比較しています。なので、そしてこちらでも見えると思いますが、ええと、回答は実際には前にあったものとは違っています。
なので前は、つまり、もっと全体的なものでした。そしてこれは、たとえば 3. 7 billion のようなものです。そして今、output から来ているように見えますが、まだ動くか見てみましょう。はい、基本的にそれが冒頭で言っていたことです。こうしたエージェントは非常にうまく機能することがありますが、すべてが決定論的というわけではありません。
なので、それは本当に、つまり、エージェントと、それが取っているアクションに依存します。そしてこれは、はい、非常にすぐに答えを見つけられるはずです。それからライブデモに戻れます。すみません。やった。はい、できました。
オーケー、いいですね。そしてフォーマットも、以前のものとは違うことがわかります。ええと、でも今はライブデモに戻りましょう。もう終わっているはずなので。はい。ここで言っていたのはそういうことです。
MET フィルタリングを作成しました。そして実際に答えがこれであることがわかります。つまり答えは、キーが file name、値が Uber 21 PDF の metadata filter です。ええと、そしてそれはエージェント自身によって作成されました。なのでその後、同じ質問を、つまり、実行できます。ええと、そしてここに engine tool があり、ええと、そして私は、つまり、company docs filtering のように言います。それが名前です。でもここでは会社については何も書いていません。つまり、ただ「ねえ、お願いします、ええと、2021年のさまざまな企業の財務情報を提供しています」と言っているだけです。ええと、そしてそれがやっていることです。
そして今、すべてをもう一度私のエージェントに通して、答えを確認しています。ええと、ここでは本当に、つまり、ユーザーがUberの収益について質問していて、それは提供されたPDFで確認できるので、ええと、そのために会社ドキュメントのフィルタリングツールを使います。ええと、そしてまた質問をして、このドキュメント内でも答えを見つけています。そして今は実際にはUberのドキュメント内だけを検索していて、Lyftなどについては何もありませんでした。なので今、ええと、より大きな部分についてですが、基本的に、私はまだLAMA agentsを使っていなかったので、ここでLAMA agentが登場します。
つまりこれは、ほら、すべてをオーケストレーションできるものです。これまで小さめのタスクやさまざまな例をお見せしましたが、本当に動作するエージェントを持ちたい、そしてそれが本当に多くの異なることを行うようにしたい場合は、これが、それを定義する方法です。ここにLAMA agentがあり、ええと、ここには、ほら、エージェント付きのLAMA indexもあり、ええと、function calling workerとMR. aiがあります。以前のグラフを覚えていれば、メッセージキューもあり、それは、ほら、異なるエージェントとやり取りするために使われています。
次にコントロールプレーンがあります。ええと、これは実際には私がMISS for largeを使っている場所です。ええと、その理由は、コントロールプレーンが本当に、ほら、すべての頭脳だからです。なので、基本的に、より大きくて優れた機能を持つLRNがあると便利な場合があります。ええと、次にここでツールサービスを定義していて、ほら、さまざまなクエリエンジンツールがあります。
うーん、そしてはい、ここにはただ、ええと、さまざまなツールがあります。つまり、これらは基本的にメタツールです。ええと、そして最後にエージェントを定義し、ここでも再びme so largeを使います。なぜなら、エージェントや関数呼び出し、ええと、そして返却を扱ううえで非常に優れた能力を持つモデルが必要だからです。つまりそれが私たちのやることです。ええと、そして次に、ほら、説明を定義しているだけです。これで定義されました。ええと、すべてが見えるようにログレベルを変更しているだけです。
ええと、そして今、基本的にそれを起動します。エージェントサーバー、さまざまなツール、コントロールプレーン、そしてメッセージキューがあります。そして例えば、「Uberのリスク要因は何ですか？」と尋ねることができます。すると確認できます。まずエージェントサービスがあり、次に、ほら、さまざまなコントロールプレーンがあり、私たちはすべてをコントロールプレーンに公開しています。つまり、実際には新しいアクションを作成する必要があります。新しいタスクを作成する必要があります。そうすると、ほら、アクションに進み、ええと、エージェントを作成し、その後また公開し、ほら、それからさまざまなタスクを作成します。
すべてを説明するつもりはありませんが、ええと、それが仕組みです。そしてここが、つまり、あなたが「わかった、実際に答えを見つけたと思う」というような場所です。なので、コントロールプレーンに送り返しているように見えます。「よし、これは完了した」と。うーん、そしてその後、ほら、さまざまな他のアクションを行い、今は完了しているはずで、実際に出力できます。ああ、まだ完了していませんね、はい、これは完了しています。
つまりこのアクションは完了していて、その後、本当に、ほら、さまざまな、うーん、さまざまな呼び出しの間に進んでいき、まもなくこれは完了するはずです。ええと、もし実際にどこかの時点で動作していればですが。でもはい、基本的に起きていることは、それが、ほら、異なる、ええと、エージェントとやり取りし、異なるサービスとやり取りするということです。ええと、そしてうまくいけばどこかの時点で完了します。ただ、そうでなければ、ええと、残り10分なので結論に入ろうと思います。うーん、でもこれが基本的に、LAMA agentを使って、ええと、異なるエージェントを作成し、ええと、さらにvisualも使って、ほら、すべてをオーケストレーションする方法の考え方です。
えー、それから、すべてをvisandに保存します。はい、基本的に、もしこのチュートリアルが気に入っていただけたなら、少しデモ効果はありましたが、えー、それでも、そうですね、私たちのGitHubにスターを付けていただけます。えー、本当にありがたいです。えー、それは本当に、本当に私たちの助けになります。えー、それから、もし質問があれば、LinkedInで私を追加していただくこともできます。えー、喜んで質問にお答えします。えー、以上です。
ありがとうございます。はい、いいですね。ありがとう、Stefan。えー、チャットにいくつか質問がありますので、そのまま、えー、質問していきます。このragサービスをLAMAとmenstrual APIを使って実行するには、GPUベースのサーバーが必要ですか、それともCPUベースで十分ですか。
それから、このデモで使った共有サーバーvm、えー、CPUとizeを共有してください。はい、今はすべて壊れていますが、えー、これはCPUだけで使えます。えー、今のところすべて私のCPU上で動いています。えー、それから小さな、小さなラップトップでも、私がizeするモデルには問題なく動きます。はい、ありがとうございます。
それからvissのオンプレミスデプロイメントについて、vissに適した推奨の埋め込みモデルとl LMSは何ですか？えー、つまり、私たちはすべてをサポートしています。なので、それは実際にはユースケースにより依存します。埋め込みモデルは、たとえば言語によりますし、何をしているかにもよります。えー、どれだけのリソースを使いたいかにも依存します。えー、ただ、たとえばいくつかのモデルはドイツ語やフランス語で非常に優れています。
いくつかのモデルは英語のみで示されています。つまり、すべてを埋め込んだら、えー、そうですね、すべてをベクトルに保存できます。そうすれば良いです。はい、それからチャットにも、えー、Gen AIアプリ向けのAIモデルに関するリソースを共有しました。それから、データに適した埋め込みモデルの選び方に関するブログもあります。
なので、それは私たちのウェブサイトで確認できます。えー、そのリンクを共有しました。えー、それから別の質問として、エージェントのLLMを可能な限り決定論的にするためにtemperature equals zeroを設定し、それによってより決定論的な挙動を実現することはできますか？はい。えー、それは、えー、とても役に立つと思います。一般的に、えー、状況によりますが、つまり、はい、それはより、えー、決定論的にするのにとても役立ちます。たしか一度、temperatureを変更したことがあったと思います。
えー、あまり満足はしていませんでしたが、えー、またzeroで試してみます。はい、ありがとうございます。それから、誰かがこのノートブックを参加者に共有できますかと尋ねています。えー、これはMilus bootcampの私たちのbootcampに載る予定です。えー、Stefan、タイムフレームはありますか？たぶん次の日くらいですか？はい、週末までに。今はピアレビュー中なので、そういう理由です。
えー、はい、公開されたら、この、この全体の、えー、録画はYouTubeに投稿され、ノートブックはコメントに、つまり、説明欄に載りますので、えー、今週末に戻って確認していただけます、もし、もしそこに上がっていれば。えー、その点についてはお待ちいただきありがとうございます。えー、それから次の質問は、エージェントの例に何らかの中断ロジックを実装できますか、一定回数の試行後に諦めて回答を生成するようなものですか？はい。えー、たとえばmaxsituationsのようなパラメーターがあり、それをエージェントに設定できます。そうすると、そうですね、3回または4回の後に停止できます。
えー、またプロンプトによっては、エージェントに、もしある時点でわからなければ、そのまま停止して、そうですね、わからないと言う回答を出してください、と伝えることもできます。えー、通常はそういう仕組みです、デモ効果がある場合を除いて。えー、でも通常は、はい、そうです。はい、いいですね。他に質問がある方は、q and Aツールに残してください。
ええと、私の質問は、エージェントシステム内のさまざまなタスクに対して異なるLMSを選ぶ際の考慮事項は何ですか？というものです。それは本当に、LLMが何をしなければならないかによると思います。つまり、あまり高度な推論能力を必要としない小さなタスクであれば、小さなモデルが非常に有用かもしれませんし、十分かもしれません。ローカルで実行することもできます。でも、多くの推論能力が必要で、さまざまな関数に入り、異なるエージェントを呼び出すようなものが必要なら、より大きなモデルを検討するのがよいかもしれません。たとえば、Mistral Largeは1230億です。でも、LAMA 3.1の4000億のようなものも考えられます。
ええ、それらも非常に非常に役立つ可能性があります。ただ、より高価です。わかりました、ありがとうございます。では、特定のタスクを他のエージェントに委任しながら、高レベルの意思決定に大きなLLMを使う利点は何ですか？これは少し繰り返しになると思いますが、他のタスクに小さなLLMを使うと、時間とお金を節約できるということです。大きなLLMは処理が非常に遅いこともありますし、ええ、はるかに高価でもあります。
つまり、基本的には時間とお金です。わかりました。他に質問がある方はいらっしゃいますか？どうぞ、遠慮なく質問してください。もう1つ見えています。すでにminstrel AAMをローカルでホストしている場合、ノートブック内のMistral APIキーは何に使われるのですか？ええと、Mistral Largeに使われます。つまり、1230億モデルはローカルでは実行できません。
デモでは、ここにあるものです。残念ながらクラッシュしてしまいましたが、ここにあったものです。そうでなければ、本当にすべてを制御しています。つまり、ここにあるエージェントオーケストレーターを備えたコントロールプレーンでは、visual largeを使っていて、これは私のノートパソコンで実行するには大きすぎます。なので、それがAPIキーを持っている理由であり、埋め込みモデルのためでもあります。こちらはそこにしかないからです。ええ、デモの神様が必ずしも私たちに味方してくれるとは限りません。
ええ。そしてこの部分は一度もクラッシュしたことがなかったのに、よし行こう、という感じでした。もちろん、録画しているときに限ってこういうことが起こります。ええ。Stephan、本当にありがとうございました。少し早いですが、このウェビナーを終了します。ご参加いただいた皆さん、本当にありがとうございました。本日中にメールで録画とスライドをお送りします。ええと、そしてYouTubeの私たちのmiddle list bootcampで、このノートブックを探して、ぜひご自身で試してみてください。皆さんありがとうございました。そして本日ホストを務めてくださったStefan、ありがとうございました。
ありがとうございます。皆さん、さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Stephen Batifol
Developer Advocate
Stephen Batifol is a Developer Advocate at Zilliz. He previously worked as a Machine Learning Engineer at Wolt, where he was working on the ML Platform and as a Data Scientist at Brevo. Stephen studied Computer Science and Artificial Intelligence. He enjoys dancing and surfing.