- Events
Milvus、Ollama、LangGraphでローカルにAgentic RAGを構築する
トレーニング
Milvus、Ollama、LangGraphでローカルにAgentic RAGを構築する
Join the Webinar
Loading...
セッションについて
RAGシステムについては詳しく語られていますが、通常は基本にとどまります。この講演では、StephenがLangchainとMilvusを使用してAgentic RAG Systemを構築する方法を紹介します。
取り上げるトピック:
- エージェントに計画、メモリ、ツールを活用させ、さまざまなタスクを達成する方法。
- LLMにWeb検索を実行させ、カスタムのユーザー定義関数を呼び出せるようにする方法。
- ハルシネーションのような一般的な問題と、エージェントが自ら修正を試みられるようにするためのフォールバックおよび自己修正メカニズムの追加方法。
AgAgentic ragをVis AMAとL Graphでローカルに構築するセッションと、ゲストスピーカーである同僚のStefan Tupoをご紹介できることを嬉しく思います。StefanはZillowのdeveloper advocateです。以前はVolでmachine learning engineerとして勤務し、ML platformの作成と開発に携わっていました。また、その前はB Bravoでdata scientistとして働いていました。Stephanはcomputer scienceとartificial intelligenceを学びました。彼はML ops communityのBerlin Groupの創設メンバーで、meetupsやhackathonsを主催しています。
彼はボクシングとサーフィンを楽しんでいます。ようこそ、Stephan。ご紹介ありがとうございます。ご参加いただいた皆さん、ありがとうございます。ええ、今日はLAMA three graphを使ってローカルでagentを構築する方法についてお話しします。そして、えー、私はStefan Beforです。
本日のスピーカーです。えー、ziのdeveloper advocateだと申し上げましたが、この講演に関する質問があれば、LinkedIn、Twitter、またはemailで直接ご連絡いただけます。このクエリから私のLinkedInにアクセスできます。えー、それでは始めましょう。まずvisについてお話しします。えー、もしご存じなければ、VISはOpen、open Source vector databaseです。
実際にはLin explanationに属しています。えー、良い点は、私たちには、notebook上で直接PIP installできるVIS lightsから、billion plus vectorsのような規模へのスケーリングまで、すべてが揃っていることです。えー、またさまざまなpartnersと統合しており、spas、embeddings filtering、rear rankingなど、多くの異なる機能があります。えー、GitHubで直接確認してみてください。えー、starsも非常に助かります。
ええ、私たちはさまざまなAI toolkitsとも統合しています。例えばLang Chain、number、index haystack length use ai、voyage aiなどが考えられます。今日は特にLang ChainとLang Graphを使います。えー、それでは行きましょう。まず、RAGとは何かに詳しくない方のために、簡単に紹介します。
えー、その後、agent Ragとそれが何であるかについてもお話しし、それからさらに詳しく、デモに入ります、すみません。えー、実際にagentを自分たちで構築する様子をご覧いただけますし、質問があればチャットやQ&Aツールに自由に投稿してください。コードも後ほど共有されます。では、行きましょう、始めましょう。Ragはretrieval augmented generationを意味します。
基本的な考え方は、LMに自分のデータを使わせることです。つまり、データをVisのようなVector databaseに入れ、そのデータをLLMに渡します。質問をすると、えー、それによって自分のデータを使うことができます。基本的なraw architectureはこのようになります。まずデータ部分があります。
それからcontentを抽出し、chunkingと呼ぶ処理を行います。つまり、contentの一部を作成します。例えば、200文字ごとに抽出したものを、えー、データのchunkとして作成します。次にそれをembedding modelに通します。その後、それをvisに保存します。
そしてuserがいる場合、userはqueryを入力します。それも同じembedding modelに通し、えー、semantic searchと呼ぶものを実行します。つまり、意味的に類似したものを検索します。えー、そしてそれに類似したdataを返します。それをLLMのcontextに戻します。
LLMがresponseを返します。それが基本的なarchitectureです。これはうまく機能します。えー、いくつか制限はありますが、えー、かなりうまく機能します。自分のデータを使いたいだけの場合や、例えばlegal dataなどを使いたい場合、有名なfive line startersがあり、最初にデータを読み込むことになります。えー、それからembedしてindexします。
ええと、それからクエリを生成して、それからただ、ええと、クエリを実行します。それが、あの有名なやつです。ご存じの通り、それは、ただ、たった5行だけです。唯一の問題は、つまり、ご存じの通り、とてもシンプルだということです。Vector databaseに保存しているデータしか持っていません。
それでこの全体について、私が使う技術スタックは、ええと、Lang Chainを使います。なので、それに詳しくない人のために言うと、ええと、これはLLMアプリケーションを構築するためのフレームワークです。主にデータの取得と、それをLLMと統合することに焦点を当てていて、思いつくほとんどのAIツールとの統合もあります。それに加えて、実際にはLanguage Chainのland graphを使うつもりです。これはLLMを使ったステートフルなアプリを構築できるようにし、マルチエージェントのワークフローを構築することもできます。
また、サイクルや分岐も追加できます。ええと、human in the loopもあります。なので、たとえば、わかりませんが、カスタマーサポートで働いていて、エージェントが実際に、つまり、意思決定をする前に判断を行っている場合、人間に実際に尋ねることができます。たとえば、「ねえ、実際に、ええと、この顧客に返金してもいいですか？」という感じです。ええと、あるいは、そういったものを確認することもできます。基本的には常にチェックを入れることができます。
なので、これは非常に、非常に便利です。また永続化も追加できます。ご存じの通り、ragを使っているときは、通常は一方向に進むだけです。ええと、なので通常はメモリなどはありませんが、ええと、Lamb Graphを使うことで、ええと、それを追加できます。私はalamaも使っています。ええと、Alamaは本当にクールなツールで、基本的にLLMをどこでも実行できるようにしてくれます。
ええと、なので私は自分のノートPCで実行しています。それと一緒にLAMA threeも使うつもりです。ええと、billing models上で実行することもできるので、Lambsを実行するのがとても簡単になります。ええと、良い点としては、OpenAIの、ええと、APIと完全に互換性があることです。なので、Pythonを実行するとき、もし、ええと、Pythonを使うなら、それでalamaも実行できますし、実際にalamaを使うためにOpenAIをインポートする必要があります。
Vis lightを使うつもりです。ええと、前にも言ったように、Vis lightのようなものでは、ただ実行でき、ええと、一度ビルドすればどこにでもデプロイできます。なので、あとでUIを変更するだけで、Vis lightから始めた場合、Kubernetes上で動いているVUSに移行することもできますし、クラウド上のRissに移行することもできます。ええと、なのでコードをまったく変更する必要はありません。でも、ええ、前にも言いました。
ええと、Agent Ragについて話すつもりです。それは何でしょうか？まず、ご存じの通り、前に言ったように、シンプルなragがある場合、クエリがあり、それからエージェント、それからrag、そしてレスポンスを返すだけです。それで終わりです。ええと、Agentic Ragの良いところは、ええと、マルチターンにできることです。なので、たとえばragが正しい答えを出していない場合や、幻覚しているような場合、単に答えを返すのではなく、実際にもう一度チェックして、つまり、別の答えを生成できます。
ええと、なのでそれは、本当に役立つことがあります。また、クエリやタスク計画レイヤーを持つこともできます。ご存じの通り、非常に複雑なクエリがある場合、ええと、それを複数のクエリに分割できるかもしれません。なので、それも非常に便利なことがあります。また、エージェントやさまざまなツールでできるさまざまなことを計画することもできます。
ええと、また、さまざまなツールのためのインターフェースになることもできます。ええと、インターネットを閲覧するツールを持ちたいとしましょう。ええと、それもできます。Google calendarをチェックするツールを持つこともできます。それもできます。
ええと、それはリフレクションも追加します。つまり、あなたのエージェントが、ほら、確認するようにしているんです。ああ、実際に私は、私は何を言っているんだろう？それは正しいのかどうか？ええと、私は実際にユーザーの質問に答えているのか、ということ、そしてパーソナライゼーションのためのメモリもです。つまり、一方向に進むだけではなく、実際に、ほら、物事をメモリに保存して、ええと、それをLLMに戻すことができます。一般的な考え方としては、統計の例のように、すみません、ルーティングを行うことになります。これはadaptive ragと呼ばれるものです。
つまり、質問をさまざまな検索アプローチにルーティングすることになり、それは後で見ます。でも基本的には、私のエージェントが、ああ、データがそこにあるかどうかElvisで確認するのか？そしてデータがそこにない場合は、私のためにWeb検索を実行する、という判断をします。ええと、フォールバックもあります。つまりcorrective ragで、クエリに関連するdocがあればWebサイトにフォールバックします。そしてセルフ、自己修正もあります。つまりself ragです。
つまり、ハルシネーションのある回答や、質問に対応していない回答を修正しようとします。ええと、そして、ほら、質問に対応していなければ、別の回答を生成することになりますし、あるいは意図したものも処理するかもしれません。つまり、エージェンシーがそうした判断を自分で行うことになります。私はエージェントに何も言う必要はありません。ええと、プロンプトを少し行うことを除いて。なので、私のプロンプトは実際かなり長くなるのがわかると思います。
ええと、でもそれが、ほら、エージェントを持って、基本的にちょっとした魔法をさせるような方法です。そうですね、r in actionのようなものを見ていきます。ええと、そしてmilli lightsを使います、すみません。では、これから直接デモに入ります。ノートブックがありますので、皆さん見えているはずだと思います。
VIS lightsをインストールしています。つまり、pip、pip install by vis、ええと、それからさまざまな依存関係もすべてインストールしています。先ほど言ったように、すみません、先ほど言ったように、Link chainを使っています。ええと、それから、ほら、Link Chain、hum。そして、LLM向けのWeb検索であるものも使っています。これらは私たちが使えるものです。ええと、それで、ええと、私はただ、全部はインストールしません。そうしないと少し時間がかかるので。
ええと、はい、こんな感じです。基本的にMyra Ragがあって、LAMA threeを使っています。そしてVector databaseであるVisもあります。考え方としては、前に言ったように、ほら、ここにルーティングがあります。ほら、ユーザーからの質問があり、それから、ここにルーティングの部分があり、それが実際に私のindexに関連しているか、あるいは私のindexに関連していないかを確認します。関連していなければ、Web検索を行います。そして関連していれば、まずdocumentsを取得し、ええと、それからdocumentsを評価します。
つまり、ほら、documentsが関連しているかどうかを実際に確認しています。ええと、関連していれば、問題ないので回答を生成します。ええと、そして、ほら、次にハルシネーションをチェックし、ハルシネーションがあれば、別の回答を生成します。ええと、そしてeliminationがなければ、実際に質問に答えているかを確認します。つまり、質問に答えている場合、質問に答えていると思う場合は、その回答をNLMに返します。
そして答えていなければ、Web検索を行います。基本的に、何かがうまくいっていないとわかれば、常にWeb検索を行うことにフォールバックします。そうですね、基本的にリフレクションを追加しています。つまり自己修正です。plaingを追加します。つまり、これから、構築されるグラフがあり、それが本当に、ええと、さまざまなアクションを計画するのに役立つことがわかるでしょう。
えー、それから、そうですね、ツール使用も追加しています。つまり、controlflow 内に特定のノードをいくつか持たせるような感じで、たとえば web search などがあり、それから agent がそれらのツールを使います。なので、私はすでに model をダウンロード済みですが、alama でまだの場合は、その model を pull するだけで、えー、それから使えるようになります。なので、これから自分の files を import します。tab I を使うつもりで、table は open source ではなく、私の machine 上で動いていないからです。なので API key を使う必要があり、これから使う LLM を定義しています。
つまり LA three だけです。そしてここで、ここから link chain を使い始めます。なので internet も browse します。これから、えー、使う予定のさまざまな、うーん、articles をお見せします。まずこれが、えー、LLM powered agents についてのものです。見てみることができます。
読むわけではありませんが、つまり、彼は agents についてさまざまなことを説明しています。たとえば system overview です。つまり、前に言ったように、planning、memory、tool use、そしてそういったさまざまなものです。なので見てわかるように、これは agents についてのものだと覚えておいてください。もう1つあります。えー、prompt engineering についてのものです。つまり、同じようなもので、やはり LLM に関連していて、agents にも関連していて、えー、すべてに関係しています。
これらと、それから実は3つ目もあって、これは LLM に対する advers adversial attacks についてです、すみません。なので、これもやはり LLMs に関連しています。えー、なんとなくわかりますよね。なので、えー、URLs があり、それから、これらについて、えー、load して、それからすべての documents を取得し、それから split して chunks を作成します。うーん、この demo のためだけに、chunk size は 250 にします。
それについて絶対的なルールはありません。つまり、ああ、250 を使わなければならない、というわけではありません。ただ、この case ではかなりうまく機能するとわかっただけで、ほとんどは use case によります。えー、たとえば legal data を扱う場合は、より長い chunks にしたいかもしれません。えー、semantic chunking を使うこともできます。うーん、これは document の similarity に応じて chunks を作成します。えー、なので、それもできます。
それから、すべてを split して、えー、すべてを Vis に store します。ここで、私が持っている documents と新しい splits を使って、collection name を作成します。それが Rag bu で、えー、それから hugging face onbeddings、default のものを使います。えー、そして BU lights に store してください。すると file name を作成します。ではやってみましょう、実際に動くか確認しましょう。これはただの warning なので問題ありませんが、いま何をしているかというと、前にお見せした articles にアクセスして、それらを取得し、それから chunks を作成し、それからすべてを bu に挿入しています。
はい、なのでこれは動きました。よかったです。そして今から実際に agents と agents のさまざまな parts を作成します。これは retrieval grader です。先ほど言ったように Alama を使っています。えー、そしてここが、つまり、すべての prompts を書くところです。
なので、ここである意味、私たちが prompt engineer と呼ぶものになります。あなたは、user question に対する RETRIE documents の relevance を評価する grader です。そして基本的には、えー、それが user question に関連しているなら、relevant として grade し、そうでなければ filter out するように言っています。また、その document が relevant だったかどうかを示す yes または no の banner score も返してください。そうする理由は、現在の research で見られる限り、LLMs は、classification problem のようなものに関してはかなり得意だからです。
しかし、たとえば彼らに0から5で評価を付けるように頼むと、あまりうまくありません。なので基本的には、私はすべてをそのように分割するつもりです。すべては、NLMが返さなければならないバイナリスコアになります。ええと、それを自分のretrievalに使うつもりです。たとえば、自分がhallucinatingしているかどうかをチェックするためですね。はい、なので基本的にここではdocumentとuser questionを渡していて、ええと、ここに自分のchainがあります。
つまり、promptがあって、それからLLMがあって、そして私は、うーん、ただoutputをJasonとして返すようにしています。私のquestionは、単純なquestionで、ただagent memoryです。では実際に、この1つがrelevantだと思うか見てみましょう。これはvisに入って確認し、つまり、この1つがrelevantかどうかを見ることになります。そして私のquestionはagent memoryに関係しているので、得られるscoreはyesになります。先ほど見たように、articlesは実際にagentsとagent memoryに関係していました。
なので、それがyesと答えているのは理にかなっています。次にもう1つあって、これはただtextを生成するものです。これは、ええと、つまり、okay、answerが与えられたら、もし最初にanswerを知らなければ、知らないと言い、そうでなければ最大3文でtextを生成して、簡潔にしてください、というものです。これはただ、つまり、実際にたとえばGPTを持っているときに、textを生成してくれるものです。なのでここでやっているのはそういうことです。
基本的には、基本的には同じです。私のquestionはまだagent memoryに関係していて、ええと、contextとquestionを渡していて、ええと、実際に私たちが望むようなtextを生成しているか見てみましょう。少し、少し時間がかかりますが、それは問題ありません。そしてここで見ることができます。ええと、それからこのtextを生成します。
つまり、provided contextに基づいて、私はこう答えられます。agent memoryとは、agentsによって直接提供されるobservationとeventsのcollectionであり、ええと、などなど、などなど、という感じです。なので、それがやっていることです。これもまた、あなたが自分のrag agentsに与えるactionの1つです。これは次にhallucination graderです。
これは、つまり、私はまだalamaを使っていて、promptがあり、それはokay、あなたはanswerがgrounded inであるかどうかを評価するgraderです、と言っています。なので、もしgroundedであれば、binary scoreとしてyesを付けてください、ええと、そうでなければbinary scoreとしてnoを付けてください。ええと、それから、はい、また同じで、いつもそんな感じです。常にyesかnoを求めます。そして私が尋ねているのは同じquestionです。なので私はまだagent memoryについてquestionしています。
それで、answerによって確認するはずで、私にscoreを出してくれます。実際には、またscoreで、yesのようなものです。うーん、これはgroundedです。つまり、visの中に実際にagent memoryに関するものがあります。なのでこの件については満足です。そして、さきほども言ったように、answerのqualityが良いかどうかを確認するだけのチェックもしています。
なのでここでも同じです。questionを解決するのにanswerがusefulかどうかについて、binary score、つまりyesかnoを与えることになります。うーん、なので、それを渡しているわけです。うーん、そして私はまだ同じquestionを持っています。私のquestionはまだagent memoryに関係しています。
うーん、それで私たちは、okay、満足だ、つまり、実際にuserのquestionに対してusefulだ、となります。そしてここが、私のroutingをすべて持っている場所です。なのでこのroutingは、つまり、あなたが渡すものに応じて、基本的にagentsにどこへ行くかを指示するようなものです。私は、okay、あなたはuser questionをroutingするexpertとして始めます、としています。つまり、vector storeに行くか、web searchに行くかのどちらかです。そして、LLM agents、prompt engineering、different attacksに関係するquestionにはvector storeを使ってください、つまり、それ以外の場合はweb searchを使ってください、という感じです。ええと、なので、そういうふうに言います。please、それ以外の場合は、つまり、web searchを使ってください、そして実際にはchoiceを返すだけになります。
ええと、これは、質問に基づいて web search と言うか、vector store と言うかのどちらかです。そして、それから、data source というキーを持つ JSON を返すだけです。ええ、それだけです。なのでこれについては、質問が2つあります。ええ、ここに最初の質問があって、それは、Euro football はいつ開催されますか？というものです。そして2つ目があり、それは他にどのような種類の ancient memory かというもので、2つ目は Vector Store に行くことを期待していて、最初のものは web search になることを期待しています。
では、私のプロンプトが良かったかどうか見てみましょう。ええ、問題なさそうです。なので最初のもの、Euro football に関連するものについては、オーケー、これは web search だと言っています。そして2つ目については、agent memory に関連しているので、Vector store に行ってくださいと言っています。なのでここで、実際に web search を行うことになります。そこで私は、ええ、LLM 向けに特化した検索エンジンなので、かなり便利なものを使っています。ええ、そしてここから先は、これらのプロンプトをすべて定義します。プロンプトを定義するのは問題ありませんが、control flow はありません。
これを構築するには、フローとグラフが必要です。では進みましょう。ざっと見ていきます。ええ、すべての詳細には触れません。かなり長いので。ただここでは graph state を定義しています。これは、グラフの state を表しているだけです。つまり、question、LLM generation、web search を追加するかどうか、そして documents のリストがあります。それから reflection に必要なノードをすべて追加しています。つまり、re 関数を追加します。
これは vector store からすべてを取得します。ええ、それからすべてを print して、質問を invoke します。つまり実際に vector search を行うことができます、すみません。次にもう1つ、生成を行うものがあります。これは以前見たもので、取得した documents に基づいて rag を使って回答を生成します。これは本当に便利です。たとえばユーザーが質問していて、データはあるけれど、それをより良い回答の形にしたい場合です。基本的には、documents を grading する別の関数があります。
つまり、前に言ったように、documents が question に関連しているかどうかをチェックしています。これを確認しますが、これはかなり長いものです。ええ、ただ、さまざまな states をチェックします。question と documents を取得して、そして本当に grade します。オーケー、私たちは irrelevant なのか？ええ、それで問題ありません。document が関連していない場合は、それを print して、それから web search を行います。基本的にはそのように定義しています。ええ、つまり、LLM が実際に自分自身を grading していて、満足できなければ、web search を行うと定義して、それから続行します。ええ、それから web search 関数を定義します。
つまり、これもやはり、ユーザーの question に基づいています。ここにあります。ええ、web search tool があるので、それを、実際にはユーザーの question である query とともに invoke するだけです。すべてを return します。見栄えがよくなるように全部 join しています。ええ、そして web results を返します。そしてここが、conditional edge と呼ばれるものがある場所です。
これは、条件に基づいて、場合によっては graph から抜けられるというものです。これは question をルーティングしています。つまり、question を web search または rag のどちらかにルーティングしています。先ほど見たものです。つまり、data source が web search なら、web search を返して、それから search を実行します。あるいは agent がそれを行います。そして data source が vector store なら、vector store を返し、それから agent が invis 内のすべてを検索します。はい。
ここでも同様に、状態を定義します。つまり、エージェントが回答を生成するかどうかを判断するための状態です。したがって、回答を生成するか、あるいはWeb検索を追加します。そして、そうですね、その後、採点されたドキュメントを評価します。ええと、Web検索を行った場合は、つまり、関連性を確認しているだけで、その後、新しいクエリを再生成します。なぜなら、そうですね、Web検索を行っても、すべてのドキュメントが関連していないことがわかるからです。
そうですね、そうでなければ関連するドキュメントがあります。したがって、ここで回答を生成できます。そこで、つまり、生成がドキュメントに基づいていて、質問に答えているかどうかを判断します。そして、それは実際に、次のノードのための判断を返しています。つまり、「ああ、これで満足なのか、それとももう一度Web検索を行うのか？」あるいは「新しい回答を生成するのか？」ということです。だからこそ、こうしたものを定義するのです。
つまり基本的には、まず幻覚をチェックしています。ええと、生成がドキュメントに基づいているかをチェックし、その次に、ええと、実際に質問に答えているかをチェックします。そして、そうですね、その回答が有用だったか、あるいは有用でなかったかを確認します。そして、回答が根拠に基づいていない場合は、サポートされていないと言います。うーん、その上で、新しいWeb検索を行うこともできますし、別のリサーチを行うこともできます。
ええと、ここでは以前に定義したさまざまなノードをすべて追加するだけです。そうですね、Web検索ノード、retrieveノード、grade documents、そしてgenerateのものを追加します。では、すべて実行します。ええと、とても速いはずです。ええと、実行されたか確認しましょう、はい。
これで実行されたので、今度はグラフを定義します。つまりグラフが動いていて、これから構築します。基本的に、entryポイントとしてentryを設定し、質問をルーティングします。質問はWebサイトに行くか、あるいはvector storeに行きます。もし、わかりませんが、追加したい何か別のものがある場合は、もちろん、以前私がやったように関数を作成する必要があります。ただし、ここでは別のentryポイントも設定する必要があります。
もし、ええと、わかりませんが、bubがあって、さらに別のデータ用の別のデータベースがあるような場合は、そこでも確認できます。うーん、それから、はい、edgeを追加します。つまり、retrieveしたらドキュメントを採点するためのものです。ええと、それから採点して、その後、生成するかどうかを判断します。ええと、そしてWeb検索をするか、あるいはテキストを生成します。そしてここでは、つまり、生成を採点し、実際にそれに答えているかどうかを確認します。
そして、もしそうで、not supportedを返す場合は、次はgenerateになります。もしnot usefulだと思う場合は、Web検索を行います。そして何かusefulだと思う場合、そこで終了します。基本的にはそれがグラフの終わりです。うーん、そしてその時点で、ユーザーに回答を返すことになります。ではグラフを構築しましょう。今構築されました。ええと、これから実際にエージェントに質問を始めます。
つまり、ここでグラフをcompileしました。workflowをcompileするだけで、それで終わりです。そして質問をします。最初のものはまだ、私のagent memoriesに関連しています。質問は、「エージェントメモリの種類は何ですか？」です。では開始します。ええと、すると、どのタイプのagent memoryなのかがわかります。それが私のクエリです。
データソースはベクトルストアになります。そして、その質問を私たちのrackシステムにルーティングします。それからドキュメントを取得して、取得の部分は完了です。次に、ドキュメントが質問に関連しているかどうかをチェックします。つまり、ここではすべてのドキュメントを評価しているので、それらが良いかどうかを本当にチェックしています。それから評価します。では、すべてのドキュメントを評価したけれど、それで満足しているか？もしはいなら、答えを生成します。ここでは、どうやらLL airlineは満足したので、答えを生成することに決めて、それから生成を開始し、ハルシネーションをチェックします。
それから、判断としては、実際に生成結果は根拠づけられているので、その生成結果に満足している、という感じでした。そして、実際に質問に答えているかどうかもチェックします。そうすると、その生成結果は質問に対応しているようです。なので、ここで完了です。それだけです。えっと、そして今、実際にテキストを生成します。
そして、得られたテキストはこれです。つまり、提供されたコンテキストに基づくと、エージェントメモリには3つのタイプがあります。えっと、1つ目はretrieve modelで、次にreflection mechanismがあります。うーん、1つ抜けているようですが、それは問題ありません。それがLMSの動き方です。でもまあ、とにかく、エージェントメモリに関連する答えをそれなりに返してくれたことがわかります。
なので、ここでは満足しています。ベクトル検索を行い、すべてが動いています。グラフがどのように見えるかをお見せすると、最初にお見せしたものです。うーん、でもこんな感じです。開始があって、それからベクトルストアに行き、ドキュメントを取得し、ドキュメントを評価します。満足できなければ、Web検索をします。
満足していれば生成し、それが有用だと思えば停止します。そうでなければ、常にデフォルトでWeb検索に行くか、あるいはループすることもできます。再生成の部分でもループできます。つまり、それが実際に良いものだったかどうかを見るために、もう一度生成できます。それから、大きなカンファレンスが来週、えっと、実際にはヨーロッパで開催されます。なので、エージェントに、we are developers conferenceは次にヨーロッパでいつ開催される予定ですか？と尋ねることができます。するとここでは、LLMエージェントなどには関係していないことに気づきます。なので、ルーティングの部分では、ああ、実際にはここではWeb検索をしよう、となりました。
それで、その質問をWeb検索にルーティングしています。Web検索が終わり、いくつかのテキストを生成します。再びハルシネーションをチェックしています。えっと、答えが生成されているか、すみません、私たちのドキュメントに根拠づけられているか、実際に質問に答えているかをチェックしています。そして、どうやら質問に対応しているようなので、満足しています。すると答えを返します。We Developers conferenceは、次にヨーロッパで7月17日から7月19日まで、ドイツのベルリンで開催される予定です。
えっと、確認できますが、それは実際に正しいです。来週開催されます。なのでここでは満足しています。そしてそれは、エージェントがここでWeb検索をすることに決めたからです。つまり、MILにはそれに関連するものが何もなかった、というわけです。そして、もしvisにたくさんの異なるデータがあったとしても、うーん、それでもWeb検索を行うことができます。それから、私も、えっと、ドイツのベルリンに住んでいるので、訪れる人たちにとって、ベルリンで何ができるのか知りたいかもしれません。
なので、この質問をすることができます。そしてまた、Web検索を行い、それからテキストを生成します。ライブで見ることができます。今まさにテキストを生成しています。それから彼は再びハルシネーションをチェックしていて、基本的にエージェントがすべてをチェックしている様子がわかります。うーん、判断としては、根拠づけられている、ということでした。
では、質問に答えられているかを確認しています。ええと、どうやら、質問には答えられているようです。では、ええと、何ができるか見てみましょう。ええと、やることはたくさんあります。ええと、Bellin Wall Memorialand Documentation Centerを訪れることもできますし、Museum Islandsを探索することもできます。ええと、ショッピングストリートをチェックすることもできます。ええと、そして、もしもっとユニークなものを探しているなら、ええと、topography、towerを訪れることを検討してください。ええ、これは、とてもユニークです。
そう言えます。ええと、そして、そうですね、それ以外なら、Tear Gardenを散歩してみてもいいかもしれません。これは実際ベルリンにあるとても素敵な庭園です。なので、実際そう言えると思います。ええと、そして基本的には、こうして、さまざまなツール向けのエージェントを構築できます。私はWeb検索を使ったメールだけを示しましたが、もし別のツールがあるなら、それらをノードに追加して、異なる条件を設定するだけで、そうすればエージェントは、ええと、やりたいことをすべてできるようになります。
たとえば、Googleカレンダーを確認したり、そういったさまざまなことを確認したりすることもできます。ということで、私のデモなどはだいたい以上です。ええと、もし気に入っていただけたなら、ええと、GitHubでスターをお願いします。オープンソースコミュニティにとって本当に助けになります。それから、もし質問があれば、ええと、LinkedInで私を追加してください。どちらも、私は正しい場所へリダイレクトできるはずです。
ええと、どうもありがとうございました。チャットで多くの、ええと、アクティビティがあったのを見ましたので、いくつか質問があるかもしれません。では、これから質問を受け付けます。ありがとうございます。ええと、チャットに、なぜpipe関数を使わなかったのかという質問があります。何を選ばなかった、すみません？pipe関数です。
ああ、long chainのものですね。ええと、単にあまり好きではないからです。なんというか、個人的にあまり好きではないんです。なので、それが理由です。もしlong chainのものなら。ええと、もう一つあります。ええと、このユースケースにfunction callingは合いますか、それとも、より多くの引数が必要なAPIがツールである場合だけでしょうか？たとえば、freeform textを使うWeb検索に対して、内部APIの場合などです。いいえ、通常は、エージェントが、そのAPIの、ええと、パラメータを理解します。つまり、それが基本的に良いところです。
ええと、Google Calendarを呼び出す場合、それはAPI呼び出しで、そして、ええと、必要なさまざまなパラメータを推測してくれます。これはマルチエージェントシステムの例ですか？たとえば、各コンポーネントがエージェントなのでしょうか、それともグラフ全体がエージェントと見なされるのでしょうか？ええと、これはエージェントと見なされます。ええと、私が作っている別のデモがあって、ええと、それはマルチエージェントのようなものになる予定です。それらは同じ作業を同時に行うこともできます。すみません。
それは今後計画していることです。フォローアップ質問をグラフ内で行う場合、どのように機能しますか。たとえば、省かれた3つ目の種類のメモリについてフォローアップしたい場合は。ええと、できます、まあ、誰にフォローアップ質問をするのでしょうか？はい、では、ええと、省かれた3つ目の種類のメモリについてですね。そうすると、グラフ内で別のアクションを定義することになります。つまり、ええと、そこで止めることもできるかもしれません。ええと、フォローアップ質問をどのようにしたいかによります。それを自動にしたいのか、それとも、ええと、手動にしたいのかですね。つまり、「ああ、実際に自分でフォローアップ質問をしたい」となる場合です。ええと、そうでなければ、常に条件を追加できます。たとえば、もし分からず、ええと、すでにWeb検索をして、回答を生成しようとして、それでもまだ満足できない場合は、一旦止めて、ユーザーにフォローアップ質問を求める、というような条件です。
通常はそれが、どうやるか、私ならそうやる方法です。すみません。それから、すみません、今チャットを確認しようとしています。皆さん、Q&Aツールを使っていただけると、本当に質問を見逃さずに済むので助かります。ええと、はい。
ええと、OpenAI Assistant APIにどれくらい近いのか、OpenAIのシステムにどれくらい近いのか？ apr？ ええと、感じとしては、つまりOpenAIのシステム、DPRのほうがリソースは多いと思います。なので、ほら、オープンソースは良い場合があります。そうすれば人々が直接それを構築したり、私たちがどれくらい近いのか協力したりできます。私たちがどれくらい近いかという質問には、正直答えられません。これは、ほら、さまざまなオープンソースや言語モデルがあるのと同じだと思います。私たちはGPT-4 Oか何かにどれくらい近いのか、という話で、その場合はベンチマークがありますが、まあ、それ次第です。
マルチエージェントを構築するにはLangGraphを使うのが唯一の方法ですか、それとも他のアプローチや代替手段はありますか？いいえ、そのために利用できるツールはいろいろあります。ええと、LangGraphはその1つです。ええと、それから先週リリースされたLlama Agentsがあります。Crew AIもあります。ええと、これもオープンソースコミュニティではその用途でかなり、かなり知られています。ええと、クローズドソースのものもきっとあります。
ええと、私はそういうものはあまり使わない傾向があります。ええと、主にオープンソースで作業しているので、自分自身のものを持つこともできます。ほら、たとえば何らかの、ええと、つまりPythonですべてを書くこともできます。その場合はかなり手間がかかるかもしれませんが、でも、ほら、それもできることです。同じように、すみません、ええ、最後まで言うと、RAGを使うとき、基本的なRAGアプリケーションを構築するときと同じです。LlamaIndexやLangChain、あるいは別のツールを使うこともできます。自分でやることもできます。なので基本的にはここでも同じです。ええと、すべてをコントロールしたいなら、自分でやることもできます。では、エージェントをどう定義しますか？ Stephan？通常、エージェントとは、それ自体で行動を起こすものとして定義されるものです。
なので、そうですね、私はそう言います。つまり、ええ、答えが正しいかどうかをチェックするだけのようなものでも、ええと、通常それは私ならエージェントと呼ぶものです。あなたへの別の質問があります。RAGASのようなフレームワークは、回答、関連性、グラウンデッドネスのようなものをチェックします。ここでの違いは、ノードを使ったライブ評価だということですか？ええ、なので少し、RAGASは本当に、ええと、これは、はい、基本的にはそうです。
なので、質問を読んだところです。ええと、そうですね、基本的にライブでチェックしています。ええと、ここで私がしていることは基本的に、ほら、あなたがLLMと話していて、それが回答を返し、あなたはすでに答えを知っているのに、それが間違った答えを返してきて、「本当に？」と尋ねると、LLMが「ああ、実はあなたの言う通りです。ほら、私は、私は間違っていました」などと言う、あれと同等のことです。基本的にそれをやっています。
ええと、なので、違いはここではライブであるということです。これらのオープンソースLLMでPEFTはいつ使うべきですか？ええと、それはとても良い質問です。ええと、Hugging Faceのものだと仮定します。ええと、今のところ実際にはあまり見ていません。なので、何も言うつもりはありません。というか、わかりません。でっち上げるつもりはないので、調べてフォローアップする必要があります。回答を幻覚させたくないですよね。
その通りです。ええと、LangChainとLlamaIndexの使い分けはどのように区別しますか？これはユースケース固有ですか？ええと、そうですね、それは自分の好みにもよります。ほら、抽象化レベルや、統合の内容によって、LangChainやLlamaIndexを好む人もいるかもしれません。ええと、私の側では、ええと、当時は、ほら、LlamaIndexにはLlama Agentsがなかったので、LangChainが最初に、ほら、本格的にエージェントを持ち、ええと、それをより簡単にしたものでした。だから私がそれを選んだ理由でもあります。
ええと、でも通常はユースケース固有の場合もあります。そうであることもありますが、ほとんどは個人的な好みによります。素晴らしいです。すみません、今ちょっと質問ウィンドウを見失いました。大丈夫です。
ええと、なぜ幻覚にsameLLMを使うのか、あー、幻覚をチェックするため、だと思います。ええと、通常はただ、最初のチェックにすぎません。つまり、私は別に、専門家の混合とかではなく、ただ1つだけ、1つだけを使っています。なぜなら、それらは通常、自分たちが言ったことが正しかったかどうかをチェックできるからです。ただ、少し突っ込んでみると、ほら、以前に挙げた例は、ああ、本当にそうですか？と聞くと、皆さんの多くはSHA GPTが、ああ、いや、実はあなたの言う通りです。ええと、私は別のことをしていました、みたいになるのを見たことがあると思います。そうすると実際に正しい答えを出してくれたり、あるいは間違った答えを出したりして、それがとても面倒なんです。
でも、そうですね、それが問題です。ええと、今は専門家の混合もあります。つまり、エージェント用に異なるtelesを動かすようなことも可能です。とはいえ、それはユースケースにもよりますし、コストにもよります。ええと、例えば、より小さなLLMを使って、非常に具体的な何かをチェックすることができます。つまり、すべてをやろうとする大きなものを持つのではなく、タスク特化型に近いLLMSを持つようなものです。最近、多くの人々、特にクラウドプロバイダー、例えばAWSやGoogle Cloud、OpenAIのようなところが、
それらを使って、ええと、実際にかなり優れた全体システムを持つようにしています。つまり、AWSがqでそれをやっているのは知っています。彼らは主に専門家の混合のようなものを持っていて、特定のタスク向けにファインチューニングされた小さめのLLMSです。はい、場合によります。そして、エージェントを使うべき理由は何で、メリットやデメリットはありますか、あるいはそれについてどう考えますか？ええ、そうですね、クールなのは、つまり、私はそれをクールだと思っていて、それがまず1つ目のメリットです。つまり、エージェントが実際にインターネットをチェックしたり、カレンダーに何かを予約したりするのを見ることができます。そこがクールな部分です。
ええと、悪い部分は、そうですね、それが自分で物事を行うことです。だからもしかすると、明日のカレンダーに、びっしり予定が入っているようなサプライズがあるかもしれません。ええと、デメリットは、より高価になることです。ええと、当然、より多くのリソースを使います。なぜなら、それは考えなければならず、何かをbroしなければならないからです。だからそれは1つの点で、そして、でもそのプロセスは、そうですね、例えばVector databaseにデータがない場合、幻覚を起こしたり、関連性のない答えを出したりする代わりに、関連性のある答えを出すことができる、ということです。
だから、ユーザーもより満足するかもしれません。素晴らしいです。ええと、聴衆から最後に質問はありますか？なければ、今日のセッションを締めくくれます。最後の質問を待つ間、少しだけ時間を取ります。今日は皆さんにお時間をいただいたこと、そしてStefanの素晴らしいプレゼンテーションに感謝したいと思います。質問の最終受付です。どうやらすべて網羅したようです。
あ、来ました。ええと、どれくらい費用がかかるかについて、何か見解を示してもらえますか？場合によります。ええと、本番環境では。はい、それはモデルによりますし、何を使うかにもよりますし、非常に多くの要因があります。ええと、答えるのはほとんど不可能です。ええと、ただ言うなら、基本的なrackシステムだけを持つ場合、それはより高価になります。なぜなら、はるかに多くのアクションが発生するからです。つまり、ええと、はるかに多くのトークンを生成することになります。
なので、はい、私は、少なくとも2倍か3倍くらいです。ええと、でも、ユーザー数やその他すべての量によっては、それほど高価ではありません。通常、コストが問題なら、大きなものを持つのではなく、いくつかのアクションを行う小さめのRLMsを持つことを通常おすすめします。つまり、私は、つまり、私は自分のラップトップ上にLAMA threeしか持っていません。これは小さいものですが、ええと、でも、たぶん、1つのタスクだけを行うためにここにいるようなLLMSをいくつか持つ、ということです。ほら、彼らはここにいます。ええと、そうですね、彼らはここにいて、何だろう、あなたのカレンダー用にAPIsを呼び出すとか、そういうことをします。
ええと、低レイテンシの応答がより求められるようになっており、エージェント型RAGシステムにはかなり時間がかかることが多いですが、エージェント型システムに対してどのような最適化を提案しますか？私が最初に提案するのは、LLMに関係することではなく、ユーザー体験です。つまり、UIですね。ええと、ユーザーが理解できるようにしてください、ええと、待っている間に、つまり、何かが起きているのだと。ええ、それが1つ、ええ、私が普段提案していることです。ええ、それから、アクションを削減することもあります。ええと、たとえば、多くのデータをフィルタリングできる場合などです。
たとえば、ベクトル検索を行う場合、たぶん、メタデータでフィルタリングしてみるとか、スクロールする必要がないようなさまざまなものでフィルタリングしてみる、ということです。ええと、通常はそういったものが多いと思います。ええと、もう一度画面を共有しますが、ええと、通常私が提案するのはそういうことです。ええ、そして、ユーザーに何が起きているのかを必ず知らせるようにしてください。そうすれば、たとえ待つことになっても、なぜ待っているのかを理解できます。ええ。素晴らしい。
質問に関しては以上だと思います。ええと、はい、冒頭でもお話ししたように、ええと、私はベルリンでイベントを主催しています。10月にドイツ最大のハッカソンを開催する予定なので、ぜひLinkedInなどで私をフォローしてください。そうすれば、ええと、世界中から参加者を受け入れることがわかると思います。ですので、ベルリンにいなくても、ぜひお越しください。素晴らしい。
そのイベントを楽しみにしています。ええと、ありがとう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.