RAGFlowを導入する価値があるかどうかは、文書が本当に「手強い」かどうかで決まります。InfiniFlowがGitHubでオープンソース化したRAGエンジンで、深い文書解析を売りにしています。スキャン版PDF、表やレイアウトのある文書、テキストと画像が混ざった資料も、まず構造化された断片に分解してインデックス化し、回答に引用を付けます。知識ベースが少量のきれいなプレーンテキストのウェブページだけなら、その解析能力は使われず、かける手間の意味はかなり小さくなります。
公式リポジトリの情報は本文に明記します。プラットフォームはGitHub、組織名はInfiniFlow、プロジェクト名はRAGFlow、ライセンスはApache 2.0です。システムは複数のコンテナで構成されます。RAGFlow本体が画面・API・タスク実行を担い、ElasticsearchまたはInfinityが文書エンジン、MySQLがメタデータ、Redisが解析タスクのキュー、オブジェクトストレージがアップロードファイルを扱います。モデルは自分で接続する必要があります。1.0のオープンソース版では、解析に使うDeepDocはCPU推論で動き、レイアウト分析、OCR、表認識を担当します。
デプロイコスト：推奨構成から始める
公式の推奨開始構成は、CPU 4コア、メモリ16GB、ディスク50GBで、Docker 24.0.0以上、Docker Compose v2.26.1以上です。デプロイは、リポジトリをクローンしてdockerディレクトリに入り、Docker Composeでビルド済みイメージを起動します。Elasticsearchを使う場合は、ホストのvm.max_map_countを262144以上に設定します。ビルド済みイメージは現在x86版のみで、ARM64のマシンは公式の注記を確認しましょう。実際のコストは文書量、解析タスク数、同時実行数で変わります。スキャン文書を大量に解析するときはCPUがボトルネックになるため、まず数十件の実際の文書で一通りのテストを行い、それから本番構成を決めましょう。
実際の落とし穴は4つあります。第一に、解析品質は文書自体に依存します。ぼやけたスキャン、ページをまたぐ表、特殊なレイアウトの資料はまず抜き取り検査をし、解析が間違っていれば後からチャンクを調整しても救えません。第二に、モデルは自分で設定します。チャットモデル、埋め込みモデル、リランキングモデルの選び方を間違えると、回答品質とコストが一緒に悪化するため、デプロイ前に3つのモデルの入手先と課金を決めましょう。第三に、複数コンテナのスタック運用は継続的なコストです。アップグレード、バックアップ、ディスク掃除には担当者が必要で、「一度入れたら放っておきたい」人は、数か月後に誰も面倒を見ていない古いバージョンに直面しがちです。第四に、回答に引用が付いていても、引用が必ず正しいわけではありません。契約やコンプライアンス資料が関わる場面では原文を抜き取り確認し、権限の分離も実際の組織構造に合わせて設定する必要があります。
向いているのは、大量のPDF、スキャン文書、表形式の文書を持ち、追跡可能な回答が必要で、Dockerスタックを自分で維持する意思のあるチームや個人開発者です。向いていないのは、文書が少なく書式もきれいで、すばやくQ&Aデモを作りたいだけの人で、より軽い方法やホスティングサービスのほうが速い場合と、運用の時間がなくそのまま使えるものを求める人で、解析能力が強くても運用の空白は埋められません。まず公式クラウドサービスで解析を試し、結果が良いことを確認してからセルフホストを決めましょう。
