🐡
Agentic RAGとは
概要
以下の記事のまとめ。
一般的なRAGの問題点をagentを使うことで解決している。
従来のRAGの問題点
問題点として以下があげられる。
1度のベクトルサーチを行いデータを取ってこれないと後続の処理が全て意味がなくなる。
情報のリソースがベクトルDBだけである。
Agentic RAG
Single-Agent RAG (Router)
- ベクトルサーチ
- web検索
- 計算機など
の様なtools持ったエージェントが最初にクエリを処理して必要な情報を取ってくる。
その結果をLLMに渡して回答を生成させる。
その際にagentは以下の様な思考のループを回すので、従来のragに比べて柔軟性がある。
必要なリソースが取れるまでループできる。
取りに行くtoolsをagentが判断してくれる。
Thought: Upon receiving the user query, the agent reasons about the next action to take
Action: the agent decides on an action and executes it (e.g., tool use)
Observation: the agent observes the feedback from the action
Multi-agent RAG Systems
最初のagentが必要な情報を取りに行くことは同じだが、toolsではなく専門のagentに対して問い合わせを行う。
それぞれのagentが自身のタスクに専念することで精度の向上が見込める。
（感想）
それぞれのagentの思考の連鎖はその場限りのものなので、コンテキストを無駄に使わないという利点がありそう。
プログラミングにおける関数のようになっているのでお互いの処理の中身は知らなくて良い。
Agentic RAGの実装
実装可能なフレームワーク
知らないフレームワークも結構あるので後日触ってみる。
また先日調べたllama-agentもまさにMulti-agent RAG Systems構成になっていた。
Agentic RAGの問題点
待ち時間がそれなりにかかる。
エージェントとして振る舞わせるllmにはかなりの賢さが必要になるので、場合によっては回答自体が返せなくなるケースもある。
その場合失敗モード（何らかの理由で失敗したことをユーザに通知）を実装する必要がある。
感想
RAGで一番気になっていた、やり直ししてくれないという部分が解消されているだけでも大分良さそうに見える。
Discussion