RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

RAGFlow は infiniflow によるオープンソースの RAG（Retrieval-Augmented Generation）エンジンです。単なる「ドキュメントをアップロードして質問する」ための薄いナレッジベース外殻ではなく、ドキュメント解析、チャンク分割、検索、リランキング、引用の追跡、モデル設定、Agent 機能、API 統合までを一つのワークフローにまとめることを目指しています。

企業向けナレッジベース、ドキュメント Q&A、サポートアシスタント、社内情報検索、あるいは LLM により信頼できるコンテキスト層を持たせたい場合、RAGFlow は重点的に見る価値のあるオープンソース案の一つです。

01 RAGFlow は何を解決するのか

一般的な RAG システムがぶつかりやすい問題は主に三つあります。

ドキュメント解析の品質が安定しない。特に PDF、スキャン文書、表、画像、複雑なレイアウトで起きやすい。
チャンク分割戦略が見えにくく、検索ヒットはしていても実際の文脈が不完全になりやすい。
回答に信頼できる引用がなく、利用者が出典を確認しにくい。

RAGFlow はまさにこの部分に力を入れています。README では Deep document understanding、テンプレート化されたチャンク分割、チャンクの可視化、引用のグラウンディング、多経路検索とリランキングが強調されています。つまり、単にベクトルデータベースとチャット UI をつなぐのではなく、「高品質な入力が高品質な回答につながる」ことを重視しているということです。

02 主な機能

1. 高度なドキュメント理解

RAGFlow は複雑な非構造化データから知識を抽出できます。README に挙げられている形式には Word、PPT、Excel、TXT、画像、スキャン文書、構造化データ、Web ページなどがあります。

これは企業ナレッジベースにとって非常に重要です。現実の資料はきれいな Markdown ではなく、契約書、レポート、表、スキャン PDF、製品マニュアル、スクリーンショット、Web ページが混在していることが多いからです。解析品質が低いと、その後のベクトル検索も LLM の回答も弱くなります。

2. テンプレート化されたチャンク分割

RAGFlow はテンプレートベースの chunking を提供します。ここでの価値は、チャンク分割がブラックボックスではなく、文書タイプに応じてより適切な戦略を選べることです。

たとえば通常の記事、論文、表、Q&A 文書、画像説明、契約条項では、チャンクの粒度や境界の考え方が異なります。テンプレート化された分割により、「文が途中で切れる」「表の文脈が失われる」「見出しと本文が分かれてしまう」といった問題を減らせます。

3. 追跡可能な引用

RAGFlow は grounded citations を重視しています。つまり、回答がどのソース断片に基づくのかを追えるということです。さらにチャンクの可視化もあり、解析結果やチャンク分割結果を人が確認して調整しやすくなっています。

これは本番環境では特に重要です。企業内 Q&A は、ただ「それっぽい答え」を返せばよいわけではなく、検証可能である必要があります。ポリシー、コンプライアンス、財務、技術文書、サポート情報のような分野では、引用と追跡性はほぼ必須です。

4. 自動化された RAG ワークフロー

RAGFlow は RAG の一連の流れを、より完成度の高いワークフローとしてまとめています。

ナレッジベースの作成
データのアップロードまたは同期
ドキュメント解析
チャンクの確認と調整
LLM と embedding モデルの設定
多経路検索とリランキングの実行
チャットアシスタントの構築
API 経由で業務システムへ統合

このため、単なるライブラリというより RAG プラットフォームに近い存在です。チームにとっては UI と API の両方が有用で、非エンジニアはナレッジベースを保守しやすく、エンジニアは既存システムへ組み込みやすくなります。

5. Agent、MCP、ワークフロー拡張

最近の RAGFlow には Agentic workflow、MCP、Agent Memory、コード実行コンポーネントなども含まれています。これは、従来型のナレッジベース Q&A にとどまらず、Agent シナリオにも広がっていることを示しています。

典型的には、Agent が信頼できる企業知識レイヤーとして RAGFlow を使い、必要なときにナレッジベースから検索し、引用付きで回答を生成し、必要に応じてツール呼び出しやワークフローと組み合わせる、という形です。

03 基本的な利用フロー

公式のクイックスタートに沿うと、RAGFlow の一般的な使い方は次のようにまとめられます。

1. 実行環境を準備する

README にある基本要件は以下の通りです。

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

コード実行用のサンドボックスを使う場合は gVisor も必要です。また、公式 Docker イメージは主に x86 向けです。ARM64 を使う場合は、公式ドキュメントに従って自分でイメージをビルドする必要があります。

2. プロジェクトを取得する

1
2


git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. `vm.max_map_count` を確認する

RAGFlow のデプロイは Elasticsearch / OpenSearch のようなコンポーネントに依存するため、Linux では通常次を確認します。

1

sysctl vm.max_map_count

値が 262144 未満なら、一時的に次で設定できます。

1

sudo sysctl -w vm.max_map_count=262144

再起動後も維持したい場合は /etc/sysctl.conf に追加します。

4. Docker Compose で起動する

CPU モードはそのまま起動できます。

1

docker compose -f docker-compose.yml up -d

DeepDoc を GPU で高速化したい場合、README では .env に DEVICE=gpu を追加してから起動する方法が示されています。

1
2


sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

起動後はログを確認します。

1

docker logs -f docker-ragflow-cpu-1

サービスが立ち上がったら、ブラウザでサーバーのアドレスを開きます。デフォルト構成では通常次のようになります。

1

http://IP_OF_YOUR_MACHINE

5. モデル API Key を設定する

RAGFlow では LLM と embedding モデルの設定が必要です。README では service_conf.yaml.template 内でデフォルトの LLM factory を選び、対応する API_KEY を更新する流れが説明されています。

実際には、使うプロバイダーに合わせて次を設定します。

チャットモデル
embedding モデル
rerank モデル
PDF / DOCX 内の画像も理解したい場合はマルチモーダルモデル

6. ナレッジベースを作成して文書を取り込む

サービス起動後の典型的な流れは次の通りです。

Web UI にログインする。
dataset / knowledge base を作成する。
文書をアップロードするか、データソース同期を設定する。
解析完了を待つ。
チャンク結果を確認し、必要なら調整する。
チャットアシスタントを作成し、知識ベースを関連付ける。
回答品質と引用元を確認する。

業務システムに組み込みたい場合は、RAGFlow の API や SDK を使って、検索とチャット機能を自分のアプリに接続できます。

04 向いている場面

RAGFlow は次のような用途に向いています。

企業内ナレッジベース Q&A
製品マニュアル、技術文書、FAQ の検索
カスタマーサポートや営業支援アシスタント
契約書、レポート、規程文書に対する追跡可能な Q&A
複数形式の資料を一元的に扱いたい場合
UI による運用と API 統合の両方が必要なチーム
Agent のコンテキスト層として RAG を使いたいシステム

特に、文書形式が複雑で、引用が重要で、人が解析結果を確認・調整したい場合に向いています。

05 使うときの注意点

第一に、RAGFlow は軽量スクリプトではありません。ある程度のインフラ要件があります。公式の推奨は最低 4 コア CPU、16GB RAM、50GB ディスクです。少量の Markdown に対して Q&A をしたいだけなら、ここまで大きなプラットフォームは不要かもしれません。

第二に、文書品質は依然として重要です。RAGFlow は解析やチャンク分割を改善できますが、質の低い資料、古い資料、矛盾する資料を自動で信頼できるものに変えることはできません。本番導入前にはナレッジベースの運用設計が必要です。

第三に、モデル設定は結果に直結します。embedding、rerank、チャットモデル、マルチモーダルモデルの選択は、検索品質と回答品質の両方に影響します。RAGFlow はワークフローを提供しますが、最終的な品質はデータ、モデル、パラメータ調整の組み合わせで決まります。

第四に、本番環境では権限とデータセキュリティに注意が必要です。企業ナレッジベースには社内文書が含まれることが多いため、デプロイ方式、アクセス制御、ログ、API Key、モデル提供者側のデータポリシーまで事前に設計するべきです。

06 短い判断

RAGFlow の強みは、RAG で最も面倒な部分をプラットフォーム機能としてまとめていることです。複雑な文書解析、説明可能なチャンク分割、引用のグラウンディング、多経路検索、リランキング、モデル設定、Web UI、API、Agent 拡張までを一式で備えています。

検証可能で保守しやすく、業務システムにも接続できる企業ナレッジベースを作りたいなら、RAGFlow は「ベクトルデータベース + 簡単なチャット UI」より完成度の高い選択肢です。逆に、個人用途の小規模な Q&A や、扱うデータ形式が非常に単純な場合は、より軽量な RAG フレームワークのほうが扱いやすいかもしれません。