はじめに
「AIは本当に信頼できるの?」
「社内文書を効率的に検索・活用できないか?」
こんな課題を抱えている方に朗報です。
GitHub で爆発的な人気を集めている RAGFlow が、企業の文書管理に革新をもたらしています。
RAGFlow は、文書解析と LLM を組み合わせた次世代の QA システムです。
特筆すべきは、PDF やワード文書はもちろん、画像内のテキストまで正確に解析し、AIの回答に具体的な参照元を示せる点。
幻覚(ハルシネーション)を抑制し、信頼性の高い回答を実現します。
本記事では、RAGFlowの基本概念から実装方法、運用のベストプラクティス、AWS での本番環境構築まで、実務で即活用できる情報を徹底解説します。
AI による文書管理の革新を、ぜひ体感してください。
1. RAGFlow とは
RAGFlow は、RAG(Retrieval-Augmented Generation) を実現するために開発されたオープンソースエンジンです。
多様なファイル形式(Word、Excel、スライド、PDF、画像、スキャン文書、Web ページなど)を取り込み、Deepdoc でレイアウト解析・テキスト抽出しつつ、関連するテキストを大規模言語モデル(LLM)に入力して回答生成します。
回答時には必ず抽出元チャンクを参照し、ハルシネーションを抑制・回答の裏付けを提示できるため、実用性の高い QA システムを構築できます。
2. RAGFlow の内部構造とデータフロー
RAGFlow は主に以下のコンポーネントで構成されています:
-
Deepdoc
- OCR / レイアウト解析機能 を備えており、PDF の複数カラムや表、画像内文字まで解析してテキストを抽出。
- テンプレートベース、もしくは自動でチャンクを分割し、文書構造を大まかに把握できる。
-
ベクトル埋め込み
- 抽出したテキストを Embedding モデル により数値ベクトルに変換。
- デフォルトでは Elasticsearch に格納し、高速全文検索+ベクトル検索を行う(Infinity など他DBとの切り替えも可能)。
-
LLM ファクトリー
- OpenAI API や Azure OpenAI、あるいはローカル GPU 環境のモデル等、多様なモデルを切り替えて利用可能。
- 質問が来た際に、関連度の高い文書チャンクを LLM に渡し、回答を生成。
-
Front-end / REST API
- ブラウザからの文書アップロード、チャット UI、設定ファイル編集などの GUI を提供。
- Python SDK や HTTP API を通じて外部システムとも統合可能。
データフロー (Mermaid 図)
- Deepdoc が あらゆるファイル からテキストを抽出し、チャンクを生成
- Embedding モジュールでベクトル化し、Elasticsearch へ登録
- 質問に対して、検索+LLM へのプロンプト注入→最終回答を返す
3. ローカル環境への導入手順
(1) 前提環境
- ハードウェア: 4 コア CPU、16 GB メモリ以上を推奨
- Docker: バージョン 24 以上
- Docker Compose: v2.26.1 以上
-
Linux の場合:
sudo sysctl -w vm.max_map_count=262144
(Elasticsearch用)
(2) リポジトリのクローンと設定
git clone https://github.com/infiniflow/ragflow.git
cd ragflow
-
docker/.env
ファイルにてRAGFLOW_IMAGE
を指定。-
v0.16.0
やv0.16.0-slim
など。
-
- 埋め込みモデルを同梱しないスリム版はイメージが軽量だが、外部モデルや別途設定が必要になることもある。
(3) Docker Compose による起動
docker compose -f docker/docker-compose.yml up -d
-
サービス一覧
-
ragflow-server
: メイン API / Web UI -
elasticsearch
: テキストとベクトルの保存・検索 -
minio
: オブジェクトストレージ -
mysql
: メタデータ保存(ユーザー情報・設定など) -
redis
: キャッシュ
-
(4) ログを確認し、起動確認
docker logs -f ragflow-server
-
Running on http://127.0.0.1:9380
が表示されれば OK
(5) ブラウザでアクセス & 初期設定
-
http://localhost:9380
にアクセス -
デフォルトアカウント:初回起動時に読み込まれる
service_conf.yaml.template
内の設定 - LLM の API キーを設定:
- 例:
user_default_llm
にopenai
をセットし、OPENAI_API_KEY
を入力
- 例:
- Docker 上の Elasticsearch に大量のメモリを割り当てたい場合、
docker-compose.yml
の ES 関連設定を調整
(6) トラブルシューティング
-
Elasticsearch がメモリ不足で起動しない
-
vm.max_map_count
が設定されているか、Docker Desktop でメモリが足りているか確認
-
-
Web 画面にアクセスできない
- 使用中ポートが競合していないか(デフォルト 9380)
4. AWS ECS による本番環境への導入手順(詳細版)
ここでは、Fargate を用いた ECS を例に、RAGFlow を本番運用するまでの具体的な流れを解説します。
※インフラ構成はプロジェクト要件に合わせて柔軟に変更してください。
4.1 インフラ構成例
- ECS + Fargate: RAGFlow 本体(API、Deepdoc、フロントなど)をコンテナ化して実行
-
Amazon OpenSearch Service (もしくは Amazon Elasticsearch Service): ベクトル検索+全文検索用
- もちろん自前で Elasticsearch を立ち上げても OK
- Amazon RDS (MySQL/PostgreSQL): メタデータDB
- Amazon S3: 文書アップロード先、あるいは MinIO の代替
- Amazon Secrets Manager: APIキー、DB接続情報などの管理
4.2 ECS クラスターとサービス作成
- ECS コンソール にアクセスし、「クラスターを作成」 → 「ネットワーキングのみ(Fargate)」を選択
-
VPC / サブネット / セキュリティグループ を設定
- RAGFlow コンテナ → OpenSearch Service / RDS への通信が許可されるように設定
- サービス作成 時にタスク定義を紐づけ、任意のタスク数(1 など)を割り当て
4.3 タスク定義サンプル
Docker Compose と同等の設定を タスク定義 へ転記します。
例として、RAGFlowコンテナ 単体(Elasticsearch は外部リソース)のケースを想定します。
{
"containerDefinitions": [
{
"name": "ragflow",
"image": "infiniflow/ragflow:v0.16.0-slim",
"essential": true,
"entryPoint": ["/bin/bash"],
"command": ["-c", "/ragflow/docker/entrypoint.sh"],
"portMappings": [
{
"containerPort": 9380,
"protocol": "tcp"
}
],
"environment": [
// ここに必要な環境変数を記載
{
"name": "RAGFLOW_IMAGE",
"value": "v0.16.0-slim"
},
{
"name": "ES_HOST",
"value": "your-opensearch-service-endpoint"
},
{
"name": "MYSQL_HOST",
"value": "your-rds-endpoint"
},
// Secrets Manager の使用例は後述
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ragflow",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGate"],
"cpu": "1024",
"memory": "2048",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
"family": "ragflow-task"
}
-
ES_HOST
に OpenSearch のエンドポイントを指定 -
MYSQL_HOST
に RDS のホスト名を指定 - CPU / メモリサイズは必要に応じて調整
4.4 外部リソース連携
-
Amazon OpenSearch Service
- デフォルトの
service_conf.yaml
で Elasticsearch のエンドポイントを指定するときに、https://
の付与など要注意 - 認証が必要な場合は、IAM ロールを使用した署名付きリクエスト を検討
- デフォルトの
-
RDS (MySQL)
-
MYSQL_HOST
,MYSQL_USER
,MYSQL_PASSWORD
などを ECS タスク定義の環境変数または Secrets Manager で設定
-
-
S3 を利用する場合
- MinIO の代わりに S3 を使用するなら、
S3_BUCKET
やS3_ACCESS_KEY
,S3_SECRET_KEY
を設定。 - RAGFlow のオブジェクトストレージ連携オプションを参照し、MinIO モードを OFF、S3 モードに切り替え
- MinIO の代わりに S3 を使用するなら、
4.5 AWS Secrets Manager の活用例
ECS タスク定義 で以下のように指定し、Secrets Manager のキー MySecretKey
から値を注入:
"secrets": [
{
"name": "OPENAI_API_KEY",
"valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MySecretKey"
}
]
これで、外部に平文を置かずに LLM API キーを安全に渡せます。
4.6 運用時の注意点
-
ログ監視
-
awslogs
ドライバを使用して CloudWatch Logs に集約。重要なエラーをアラート連携すると良い
-
-
スケーリング
- 利用ユーザが増えた場合、タスク数を水平スケール(Fargate のスケーリング)
-
コスト管理
- OpenSearch のインスタンスタイプや RDS のスペックを運用状況に合わせて見直す
-
継続的アップデート
- 新しい RAGFlow バージョンが出たらタスク定義のイメージタグを更新してデプロイ
5. 活用シーンと具体的ユースケース
-
企業文書検索 / FAQ システム
- 分厚いマニュアルや社内規定、PDF 資料を一元管理し、自然言語で即座に回答
- Deepdoc が表や画像文字を解析 → ベクトル検索で該当部分抽出 → LLM でサマリ化&引用元表示
-
研究論文・特許調査
- PDF の段組みや図表も Deepdoc で解析
- 膨大な関連研究をベクトル検索し、要点を LLM で要約
- ハルシネーションを抑えつつ、根拠箇所を提示できる
-
カスタマーサポートシステム
- 自然言語で問い合わせ → RAGFlow が参照マニュアルや過去チケットを検索し回答
- LLM 単体よりも信頼性が高く、回答根拠を開示
-
大規模ドキュメントのエージェント活用
- RAGFlow の No-Code Workflow(エージェント)で QA + 外部 API コールを組み合わせ、複数ステップの自動化が可能
6. 高度な機能:Deepdoc, テンプレート分割, OCR, エージェントなど
-
Deepdoc
- OCR には複数エンジンを利用可能(Tesseract、PaddleOCR など)
- 行間や表の構造を認識し、Markdown や JSON 形式で抽出結果を格納
-
テンプレートベースのチャンク分割
- 文書のセクションや段落ルールを定義して分割する
- 例:法務文書は「第○条」「条文の解説」などに基づき分割し、LLM に最適な長さに調整
-
OCR
- 画像やスキャン PDF も解析可能
- 多言語対応のため、設定ファイルで言語モデルを指定
-
エージェント機能
- フロントの No-Code エディタ上で「文書検索 → 結果を GPT で要約 → さらに外部 API をコール → 最終回答」など複数ステップを設定
- DSL 形式で管理し、テスト/デバッグ実行が GUI で可能
7. 精度向上のためのポイント
-
文書品質と OCR クオリティ
- スキャン精度が低いと OCR が不正確になり、ベクトル検索の精度も下がる
- 事前に PDF の解像度確認、表や数式の場合はレイアウト整形 など
-
チャンクサイズの調整
- チャンクが大きすぎると無関係な内容が混在し、LLM が誤回答する可能性が増える
- 小さすぎると文脈が欠落する恐れがあるため、ドメインや文書種別に合わせて試行錯誤が必要
-
LLM パラメータチューニング
-
temperature
を下げると回答の安定性(確実性)が増し、上げると発想の自由度が高くなる -
top_k
やtop_p
、frequency_penalty
などもドメインに合わせて調整
-
-
ハルシネーション抑制
- 「必ず元文書の内容に基づいて回答する」ようにシステムプロンプトを設定
- LLM に対し「回答には常に参考箇所を提示する」など明示的な指示を与える
-
再ランキング
- 検索でヒットした文書チャンクを LLM による再ランキング でスコア付けすると、より正確な箇所を優先的に使える
まとめ
RAGFlow は、単なる文書検索システムを超えた、次世代の AI プラットフォームです。
その特長は以下の3点に集約されます:
- 高度な文書理解能力: Deepdoc による精密な文書解析で、複雑なレイアウトや画像内テキストも正確に把握
- 信頼性の高い回答: ベクトル検索と LLM の連携により、必ず根拠のある回答を提示
- 実用的な拡張性: ローカル環境での検証から AWS ECS による大規模運用まで柔軟に対応
特に、企業の文書管理、研究開発、カスタマーサポートなど、正確性と信頼性が求められる場面で真価を発揮します。
オープンソースならではの活発なコミュニティによる継続的な改善も見逃せません。
RAGFlow は、企業の知識管理を次のステージへと導く強力なツールです。
この記事を参考に、あなたの組織でも革新的な文書管理システムの構築を始めてみませんか?
参考文献
-
RAGFlow GitHub
https://github.com/infiniflow/ragflow -
公式ドキュメント(docs 配下)
https://github.com/infiniflow/ragflow/tree/main/docs