Ragent を Java の Agentic RAG 基盤として読む: 7 モジュール構成と多路検索の実際
企业级 Agentic RAG 智能体 - 全链路覆盖文档解析、多路检索、意图识别、问题重写、会话记忆、MCP 工具调用与深度思考。面向真实业务场景，从 0 到 1 完整工程实现。
ひと目でわかる
- これは何？
- Ragent は Spring AI 2.0 系の上に組まれた Java の RAG / Agent プラットフォームで、文書取り込みから多路検索、MCP ツール呼び出しまでを 7 つの Maven モジュールに分けて実装している。学習教材としての性格が強く、その前提を理解して読むかどうかで評価が変わる。
- 誰に向いている？
- 導入を検討すべきなのは、Java で RAG を扱う際の実装パターンを手元で動かしながら把握したいチーム、および既存の Spring ベースの業務システムに検索拡張を組み込む際の構成案が欲しいチームである。逆に、すでに本番の RAG 基盤を持ち、特定ベンダーの SDK に依存しない抽象化を求めている場合、README が技術選定の理由として Spring AI 以外の採用を説明しているページを用意している点を踏まえても、まず自前の抽象化と突き合わせるべきである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Ragent が埋めようとしているのは Java 側の RAG 実装知識の空白
README は冒頭で「後端程序员转型 AI 工程师的第一站」と掲げ、対象読者を Java のバックエンド開発者に絞っている。問題設定は明確で、RAG の入門教材は Python に偏っており、Java 側では Spring AI や LangChain4j のバージョン差が大きく、低バージョンでは機能が足りず、高バージョンへの追従は書き直しに近い、という事情が背景として述べられている。Ragent はこの空白に対し、文書解析から多路検索、意図識別、問題書き換え、会話記憶、MCP ツール呼び出し、深い思考までを一続きの実装として提示する。想定読者は学習者と、社内システムに RAG を組み込もうとしている開発者の両方だが、README の訴求はどちらかといえば前者に寄っている。
7 つの Maven モジュールが分離しているもの
リポジトリは frontend と backend を分けたモジュラーモノリスで、backend は framework、infra-ai、system、rag、agent、bootstrap、mcp-server の 7 モジュールに分かれる。framework は統一レスポンスと例外、認証コンテキスト、冪等性、分散 ID、MQ アダプタ、Trace、SSE とノードをまたぐストリーミングのキャンセルを担当する。infra-ai は Chat、Embedding、Rerank、VLM の各モデルクライアント、モデル档位、ルーティング、初回パケットのプローブ、ヘルス状態とデグラデーションを担う。rag には問答、知識ベース、取り込み Pipeline、意図ツリー、検索、会話、管理端 API が入る。agent は v2 ReAct の実行骨格で、README によれば RAG のパイプラインをツールとして接続する段階にある。mcp-server は MCP Java SDK を使った独立のツールサービスで、天気、チケット、販売、Web 検索の例が同梱されている。この分割の意図は README に明記されており、モデル、ベクトルストア、オブジェクトストレージを差し替えても中核の問答フローを書き直さずに済ませることにある。
検索は 4 系統を並列に走らせ、後処理で 1 本にまとめる
検索チャネルはベクトル、Elasticsearch のキーワード、LightRAG の知識グラフ、You.com の Web 検索の 4 種類で、設定で有効化したものを並列実行する。各チャネルは専用スレッドプールで独立に動き、互いの失敗が他に波及しない。後処理は重複排除、重み付き RRF 融合、Rerank、メタデータ付与の順に流れ、README には召回予算、Rerank 候補プール、最小スコアといった調整項目の存在が示されている。ここで注意したいのは、この 4 系統すべてが既定で有効というわけではなく、設定で選択する設計だという点である。You.com は外部 API であり、LightRAG は別コンポーネントを要求する。オフライン環境では実質的にベクトルとキーワードの 2 系統運用になる。融合方式に RRF を選んでいるのは、異なるスコア尺度を持つチャネルを順位ベースで混ぜるための現実的な判断であり、重みをどう決めるかは結局のところ自前の評価データが要る領域である。
起動までの手順は README ではなく公式ドキュメント側にある
リポジトリの README は、ローカル構築の手順そのものではなく、公式ドキュメントの quick-start ページへのリンクを案内する構成になっている。したがって、README だけを読んで docker compose up の類のコマンドを得ることはできない。README から読み取れる起動に関わる情報は、backend が Maven のマルチモジュール構成であり、bootstrap が起動クラスと主設定のみを持つ装配層で、そこから各モジュールを組み立てるという点、そして mcp-server が独立して起動する別サービスだという点である。設定項目としては検索チャネルの有効化、モデル档位、ルーティング、初回パケットのプローブ、Redis を用いた公平キューイングと分散並行制御、会話記憶の直近 N ターンと永続化サマリの組み合わせが README に列挙されている。実際のキー名や値は公式ドキュメントの quick-start と設定リファレンスを参照する必要があり、この記事の材料からは確認できない。
学習用としては厚いが、汎用ライブラリとして見ると薄い
最も率直に言えば、Ragent はアプリケーションであり、ライブラリではない。7 モジュールは Maven のリアクタで一括ビルドされる前提で、framework や infra-ai を単体の artifact として外部プロジェクトに取り込む使い方は README に示されていない。モデルのルーティングやデグラデーション、初回パケットのプローブといった仕組みは infra-ai の中に閉じており、別のアプリケーションから再利用するには切り出す作業が要る。また README 自身が、agent モジュールについて v2 ReAct の骨格であり RAG パイプラインをツールとして接続する立場だと説明しており、Agent 側の完成度は RAG 側より一段低い。4 系統の検索を同時に維持する構成は、小規模な社内検索には明らかに過剰で、運用対象のコンポーネント数だけが増える。ナレッジが数百文書に収まる規模なら、この構成をそのまま持ち込む理由は薄い。
Spring AI をあえて使わないという選択
README は公式ドキュメント内に「为什么不用 Spring AI / LangChain4j」というページを用意しており、技術選定の理由を明示的に置いている。ここが Ragent の性格をよく表している。Spring AI や LangChain4j を使えば、モデル呼び出しやベクトルストア接続の部分は短く書ける。しかし Ragent が扱おうとしているのは、多路検索の融合順序、モデル档位とデグラデーション、Redis による公平キューイング、Trace と回答の溯源といった、フレームワークの QuickStart が触れない層である。抽象化レイヤに乗せると、この層の制御が効かなくなるか、逆にフレームワークの内部に踏み込む必要が出る。Ragent が自前の infra-ai を持つのはそのためだと読める。ただしこの判断は、フレームワーク側の更新を取り込むコストを自分で負うことを意味する。Spring AI のバージョンアップに追従する作業は Ragent 側の責任になる。
Apache-2.0 と、ドキュメントが本体であるという構造
ライセンスは Apache-2.0 で、特許条項と帰属表示の扱いが定められている。商用利用を妨げる条項は Apache-2.0 の範囲では見当たらないが、同梱アセットや依存関係のライセンスは別途確認が要る。ここで見落としやすいのは、Ragent の価値の相当部分がコードではなく nageoffer.com 上のドキュメントにあるという点である。README はドキュメント、オンライン体験、ローカル構築、履歴書への書き方、技術選定の理由という 5 つのリンクを冒頭付近に並べ、コードそのものより読み物としての入口を強調する。リポジトリを fork して自社向けに改変する場合、この説明資産は付いてこない。コードの保守コストは Apache-2.0 の範囲で自由に引き受けられるが、設計意図の再構築は自分でやることになる。
採用するなら何を先に確かめるか
最初に見るべきは framework と infra-ai の境界が、自社の認証基盤と監視基盤に対してどこまでそのまま使えるかである。framework は認証コンテキスト、Trace、SSE を抱えているため、ここを置き換えると rag モジュール側にも波及する。次に、rag が公開する管理端 API の範囲を確認する。README は管理端 API の存在を挙げるが、その粒度や権限モデルまでは示していない。多テナントで部門ごとに見える知識ベースを分ける要件があるなら、この部分が自前の追加実装になる可能性が高い。3 点目は取り込み Pipeline の再実行性である。大規模文書の増分更新を前提とするなら、Pipeline をオーケストレーション可能とした設計が実際にどこまで増分に対応するかを、コードを読んで確かめる必要がある。README の記述だけでは、全量再構築を避けられるかどうかまでは判断できない。
編集部の結論
導入を検討すべきなのは、Java で RAG を扱う際の実装パターンを手元で動かしながら把握したいチーム、および既存の Spring ベースの業務システムに検索拡張を組み込む際の構成案が欲しいチームである。逆に、すでに本番の RAG 基盤を持ち、特定ベンダーの SDK に依存しない抽象化を求めている場合、README が技術選定の理由として Spring AI 以外の採用を説明しているページを用意している点を踏まえても、まず自前の抽象化と突き合わせるべきである。最初に確認すべきは、framework と infra-ai の境界が自分の環境でどこまで効くか、そして rag モジュールが公開している管理端 API の範囲が自社の権限モデルに合うかである。学習用の題材と本番基盤は別物であり、Ragent はその境界を README 自身が明示している数少ない例だと言える。
コミュニティノート