検索を、エージェントが利用できるツールにする

第4章では、質問を受けたら検索し、その結果から回答する固定したRAGを説明しました。第5章では、モデルがツールを選ぶエージェントを学びました。この二つをつなぎ、検索をツールとして公開して、モデルが必要に応じて利用する構成がAgentic RAG（エージェンティックRAG）です。

たとえば、簡単な挨拶には検索せず、「交通費の規程を確認したい」という質問では規程検索を使う、といった判断をモデルへ任せられます。さらに、検索結果に不足があれば質問を言い換えて再検索したり、別の情報源も調べたりする構成が考えられます。

LangChainでは、Retrieverなどによる検索をツールとして表し、create_agentへ渡す部品の一つにできます。新しい検索原理に置き換わるのではなく、いつ何を検索するかという判断の場所が変わります。

固定したRAGと、何が変わるのか

固定したRAGでは、開発者が検索と生成の順序を決めます。質問ごとに同じ段階を通るため、処理の有無や費用を見積もりやすく、検索品質と生成品質を分けて調べやすい利点があります。必要な情報源が決まっている案内では、この単純さが役立ちます。

Agentic RAGでは、検索するか、どのツールを選ぶか、追加で調べるかを、途中の状態に応じて判断します。柔軟になる一方、必要なのに検索しない、同じ検索を繰り返す、適切でない情報源を選ぶ、といった失敗も増えます。検索を一回足しただけではなく、判断の品質も評価する必要が生じます。

比べる点固定したRAGAgentic RAG
いつ検索するか定めた手順の中で検索する。モデルが必要性を判断する場合がある。
追加の検索追加する条件や経路をあらかじめ決める。途中の結果を受けてモデルが要求できる。
確認する品質検索結果と、根拠に基づく回答。左の項目に加え、検索の要否・情報源・追加検索の判断。

追加検索が役立つ場合と、役立たない場合

「海外出張について、通常の規程と例外手続きを比較してほしい」という依頼では、複数の資料を順に調べることが有用な場合があります。一度の検索で両方そろわなくても、取得した資料から不足を判断し、別の検索へ進む構成を作れます。

一方、対象資料に該当する情報がそもそも無い場合、何度検索しても根拠は増えません。検索語の言い換えを延々と続けるより、不足を伝える方が適切です。また、利用者の勤務区分が不明なら、別の資料を増やす前に本人へ条件を尋ねる必要があるかもしれません。

このため、追加検索の判断には、何が不足しているのかという観点が必要です。単に候補が少ないから再検索するのではなく、回答に必要な条件や根拠を満たしているかを見ます。

固定した制御と、動的な判断を組み合わせる

実際の構成では、すべてを固定するか、すべてをエージェントへ任せるかの二択ではありません。たとえば、利用者の権限に応じた検索対象の制限は固定しておき、その範囲で検索語や利用する情報源を選ばせる方法があります。必ず社内資料を一度取得した後、不足時だけ追加検索を許可する構成も考えられます。

こうした組み合わせは、LangGraphで経路を明示したり、LangChainのmiddlewareで利用可能なツールや回数を制御したりして構成できます。必ず守る条件をアプリケーション側で保ち、判断が必要な部分へモデルを利用する考え方です。

たとえば「規程に関する質問では、許可された社内資料を必ず一度調べる」と決めた上で、「不足していれば追加検索を選べる」とする構成です。前半の必須の検索と、後半のモデルによる選択を分けると、どの柔軟性が必要なのかを具体的に説明できます。

判断が増えた分を、評価にも反映する

Agentic RAGでは、最終回答だけでなく、必要なときに検索したか、適切な情報源を使ったか、再検索が有益だったかも確認します。回答が正しくても、不要な検索を何度も行っていれば、時間や費用の面では改善の余地があります。逆に、検索回数が少なくても、根拠を見ずに回答したなら問題です。

基本のRAGがうまく動いていない原因を、エージェント化だけで解決できるとは限りません。資料の読み取りや検索対象の問題は、経路を柔軟にしても残ります。まず固定した構成のどこに限界があるかを把握し、必要な判断を追加すると、応用の意味が明確になります。次の節では、その比較を支えるトレースと評価を説明します。