FastGPT を採用する前に読む: Flow ノードと RAG パイプラインの実際

FastGPT が埋めるのは「検索から回答までの配管」

LLM を使った社内 QA を作ろうとすると、モデル呼び出しそのものより前後に手間がかかる。文書を取り込み、チャンクに割り、ベクトル化し、質問時に近い断片を引き、必要なら並べ替え、プロンプトに詰めて返す。この配管をアプリごとに書き直すのが従来のやり方だった。FastGPT はこの区間を製品として用意し、その上に Flow という視覚的なワークフロー編集を載せている。README の説明では「開箱即用的数据处理、模型调用等能力」とあり、セットアップの少なさを売りにしている。対象は、RAG の精度改善を反復したいが、検索基盤そのものの実装は持ちたくない開発者や、非エンジニアにフローを触らせたいプロダクトチームだ。

Flow エディタと MCP が編成の中心にある

README のコア機能表では、アプリ編成の項目として「Agent Skill 编排」「对话工作流、插件工作流，包含基础的 RPA 节点」「用户交互」「双向 MCP」がチェック済みで、「辅助生成工作流」は未チェックのままだ。つまりワークフローの雛形を AI に下書きさせる機能は、この版では提供されていない。編成の単位は会話ワークフローとプラグインワークフローの 2 種類で、RPA ノードが基礎的な範囲で混ざる。双方向 MCP 対応は、外部の MCP サーバーをツールとして呼ぶ方向と、FastGPT 側を MCP から呼ばせる方向の両方を指すと読める。プラグイン側では「系统工具热更新」が済み、「RAG 模块热更新」「Agent-loop 热更新」「AI 实时生成插件」が未着手なので、検索モジュールやエージェントループの挙動を再起動なしで差し替える運用は想定されていない。

知識ベースは取り込み形式の広さで選ばれ、検索はハイブリッド前提

知識ベース機能の一覧は具体的だ。TXT、MD、HTML、PDF、Docx、PPTX、CSV、XLSX に対応し、URL 読み取りと CSV の一括インポートも入る。取り込み経路は手動入力、直接分段、QA 拆分导入の 3 つが示されている。検索側は「混合检索 & 重排」、つまりベクトル検索とキーワード系の検索を混ぜ、その後に並べ替えをかける構成だ。API 知識ベースという項目もあるので、外部の検索基盤を知識ベースとして差し込む使い方も想定されている。運用面では chunk 単位の記録修正と削除ができ、複数ナレッジベースの併用が可能とされている。ここで注意したいのは、混合検索の重みや再ランクのモデル選択がどの程度外部から調整できるかが README からは分からない点だ。検索品質を詰める作業の大半はこの調整に費やされるので、導入検討時に doc.fastgpt.io 側で確認する価値が最も高い領域になる。

導入は install.sh と docker compose の 2 ステップ

README が示す最短経路は明快だ。まず設定ファイルを取得する。

bash <(curl -fsSL https://doc.fastgpt.io/deploy/install.sh)

対話形式で入力を求められ、それが済んだら docker compose up -d で起動する。完全に立ち上がると http://localhost:3000 でアクセスでき、既定のアカウントは root、パスワードは 1234 と明記されている。この既定値はそのまま外部公開すると危険なので、公開前に必ず変更する。配布形態は 3 つに分かれる。クラウド版、Docker か Sealos Cloud で入れるコミュニティ自托管版、そして商業版だ。商業版は「更完整的功能，或深度的服务支持」を含むと説明され、導線は fastgpt.cn の問い合わせフォームになる。つまり README の時点で、機能の一部は商業版側に寄せられていることが示唆されている。どの機能がどの版に属するかは README には列挙されていないので、自托管版で足りるかは version 比較のページを見ないと判断できない。

未実装リストを読むと、デバッグ体験の穴が見える

README のチェックボックスは、このプロジェクトが何をまだ作っていないかを率直に晒している。応用デバッグの項目では「知识库单点搜索测试」「对话时反馈引用并可修改与删除」「完整调用链路日志」「应用评测」が済みで、「高级编排 DeBug 调试模式」と「应用节点日志」が未チェックだ。ノード単位のログが無いということは、分岐の多いフローで「どのノードが意図と違う入力を渡したか」を追う作業が、呼び出しチェーン全体のログから推測する作業になる。フローが十数ノードを超えてくると、この差は体感で効いてくる。同じくプラグイン側の「RAG 模块热更新」が未実装である点も、検索設定を変えるたびに再起動が要る可能性を示す。小規模な PoC では問題にならないが、毎日チャンク設計を変えながら精度を上げるフェーズでは反復速度に直結する。

自前で組むか、Dify や LangChain 系に寄せるか

同じ領域の選択肢として、Dify はノーコード寄りのアプリ構築とワークフローを前面に出し、モデル管理も統合する方向に進んでいる。FastGPT との違いは、知識ベースの取り込み形式とハイブリッド検索を製品の中心機能として並べている点、そして MCP を双方向で扱うと明記している点だ。逆に、検索ロジックを完全に自分で書きたいなら LangChain や LlamaIndex のようなライブラリで組む方が自由度は高い。FastGPT を選ぶ判断は「検索の実装を捨てて、その分フローと運用画面を得る」というトレードオフを受け入れられるかどうかに集約される。ランキング関数を差し替えたい、チャンク分割を独自アルゴリズムにしたい、といった要求が既に確定しているなら、このプラットフォームは土台ではなく障害物になる。

ライセンス表記は NOASSERTION のままで、そこが最大の未確認事項

リポジトリのライセンスは NOASSERTION と表示されており、これは GitHub が既知のライセンス条文として認識できなかったことを意味する。labring は他にも Sealos や fastgpt-plugin を出しているが、それらと同一条件かどうかはこの情報からは判断できない。自社製品に組み込む、あるいは顧客環境に納品する形で使うなら、リポジトリ直下の LICENSE ファイルの原文を読み、必要なら法務に回すべきだ。ここで法的な助言はできないが、少なくとも「OSS だから自由に使える」と仮定して進めるのは避けたい。もう一つのコスト要因はアップグレードだ。リリースは v4.16.0、v4.16.1、v4.16.2 と短期間で続いており、マイナー番号が細かく動く。Docker 配布なので追従自体は compose のイメージタグ更新で済むが、知識ベースのスキーマやフロー定義の形式が変わる場合は移行作業が発生する。変更点はリリースノートで確認するほかない。

編集部の結論

自前のナレッジベースを RAG で引かせたいが、検索ロジックをフルスクラッチで書く余力はないチームには候補になる。逆に、検索のランキング関数やチャンク分割を自前で制御したい場合、あるいは AGPL 系ライセンスを避けたい製品に組み込む場合は、先にライセンスと該当モジュールの実装を確認すべきだ。着手前に見るべきは、doc.fastgpt.io の self-host/deploy/docker の手順、リポジトリ直下の LICENSE ファイルの実際の条文、そして 4.16.x 系で未実装と明記されている項目が自分の要件に重なるかどうかの 3 点である。

公式情報源

1. Issues
2. labring/FastGPT on GitHub
3. Project website
4. README
5. Releases