Dify ナレッジパイプラインとは？RAG精度と運用を左右する設計（失敗例つき）
はじめに
RAGチャットボットを本番稼働させて数週間後、「なぜか古い情報を答え続ける」「特定部署のドキュメントが別部署にも見えてしまった」――こうした事故は、設計段階の判断ミスが後から表面化したものです。
2025年9月にDifyが公開した「ナレッジパイプライン（Knowledge Pipeline）」は、こうした問題の根本原因であるデータ取り込み工程を可視化・制御しやすくする仕組みです。本記事では、パイプラインの構造から実務設計のポイント、よくある失敗パターンと評価指標まで、現場担当者が意思決定できる粒度で解説します。
この記事はこんな方におすすめです
- AI導入やDXをリードするAI推進担当者
- セキュアなRAG運用設計が求められる情シス担当者
- チャットボットの回答精度に課題を感じている業務部門の方
目次
はじめに目次1. ナレッジパイプラインとは何か2. 従来のナレッジ機能との違い3. パイプラインを構成する主要な工程4. データ種類別：チャンク分割の推奨設計（チェックリスト）チャンク設計チェックリスト5. 埋め込みモデルとハイブリッド検索の選び方実務でよく候補に挙がる埋め込みモデル例ハイブリッド検索が有効なケース6. メタデータ設計で検索精度と権限管理を両立する推奨メタデータフィールドメタデータを活用した権限制御の設計7. よくある3つの事故と原因・対策事故1：古い情報を正しいものとして回答し続ける事故2：正しい情報があるのに回答できない（検索ミス）事故3：別部署のドキュメントが参照されてしまう（権限漏れ）8. RAG品質を測る評価指標
- 実務上の目安 -9. 更新運用の設計
- 陳腐化を防ぐ仕組み -棚卸しチェックリスト（四半期推奨）10. まとめ
- 設計フェーズで決まる8割 -Dify導入・ナレッジパイプライン設計のご支援サービス紹介サービスのお問い合わせ合わせて読みたい関連記事出典・免責事項
1. ナレッジパイプラインとは何か
Difyが2025年9月に公開した「ナレッジパイプライン」は、RAGにおけるデータ取り込み工程（ETL：Extract → Transform → Load）をワークフロー形式で設計・管理できる機能です。
従来、Difyのナレッジ機能ではファイルをアップロードすると自動でベクトル化される「ブラックボックス」的な処理でした。ナレッジパイプラインではこの処理をノード単位で分解・制御できるようになり、「なぜこのチャンクが拾われないのか」「どの段階で精度が落ちているのか」をトレースしやすくなりました。
一言で言えば： 「RAGのデータ準備工程をGUIで可視化・設計できる機能」
3. パイプラインを構成する主要な工程
Knowledge Pipelineは、一般に以下のような工程（ノード）で構成されます。実際のノード構成は、利用するテンプレートやプラグインによって柔軟に変化します。
- データソース（Data Source） ローカルファイルや、コネクタ経由でGoogle Drive・Notion・Confluenceなどの外部データソースに接続します。
- 抽出・整形（Data Processing / Extractor & Chunker）
- 抽出（Extractor）： PDFや画像からテキストや構造データを抽出します。画像やスキャン文書への対応も進んでいますが、実際の精度は利用するExtractorやOCRプラグイン（LlamaParse、Unstructured等）の構成に左右されます。
- チャンク化（Chunker）： 抽出したテキストを検索単位に分割します。分割方式・サイズ・オーバーラップを設定する、最も精度に影響する工程です。
- (※構成によっては、ここでLLMを用いてメタデータを付与・要約する処理（Enricher的な役割）を挟むことも可能です)
- ナレッジベース設定（Knowledge Base Node） 処理されたデータをベクトルDB等に格納します。Difyはバックエンド構成によって各種ベクトルDBや検索基盤を利用でき、自己ホスト環境では構成に応じてQdrant / Weaviate / Milvus / pgvectorなどを採用できます。
- 入力・テスト（User Input Field / Test & Publish） 構築したパイプラインに対し、テストクエリを投げてチャンクの抽出結果をプレビューし、調整を行います。
▼さらに詳しく知りたい方はこちら
※画像や表を含む複雑なドキュメントを知識化するアプローチについては、こちらの記事もご覧ください。
4. データ種類別：チャンク分割の推奨設計（チェックリスト）
「とりあえずデフォルト設定」が最も多い失敗の入り口です。データの性質ごとに分割戦略を変えることが、RAG精度の最大の改善ポイントになります。
チャンク設計チェックリスト
FAQ・Q&Aドキュメント
- 1チャンク = 1問1答に揃える
- チャンクサイズ：200〜400文字
- オーバーラップ：不要（問答間に意味的連続性がないため）
マニュアル・手順書
- 手順の「ステップ番号」でセクション区切りを設定
- チャンクサイズ：400〜600文字
- オーバーラップ：50〜100文字（手順の前後文脈を保持）
- メタデータに「版番号」「更新日」を付与する
規程・契約書・法務文書
- 条番号・項番号で分割（セクション単位）
- チャンクサイズ：600〜1000文字（条文の文脈を保持）
- オーバーラップ：100〜150文字
- 定義語・用語集を別チャンクとして独立登録
表・数値データ（Excel・CSV）
- テーブル1行 = 1チャンクとなるよう構造化
- チャンクサイズ：小さめ（200文字以下）
- カラム名をすべてのチャンクに含める（検索ヒット率向上）
- 数値範囲クエリはベクトル検索が苦手なため、メタデータフィルタリング併用
社内チャット・メール履歴
- 個人情報・PII（氏名、連絡先）を匿名化してから取り込む
- スレッド単位でチャンクを構成（バラバラにしない）
5. 埋め込みモデルとハイブリッド検索の選び方
実務でよく候補に挙がる埋め込みモデル例
以下は、Elcamyの実務経験に基づく埋め込みモデルの候補例です。最適解は、対象文書の言語・コスト制約・レイテンシ・自己ホスト要件などで変わります。
| 条件の目安 | 候補モデルの例 | 特徴 |
|---|---|---|
| クラウド利用・高精度 | text-embedding-3-large（OpenAI） | 多言語対応・安定した精度 |
| 日英混在・マルチ対応 | bge-m3（オープンソース） | 多言語対応、ローカルホスト可能 |
| 軽量・ローカル動作 | nomic-embed-text | 計算リソースを抑えられる |
| 検索精度の底上げ | bge-reranker-v2-m3 等（併用） | 初回検索後の再スコアリング |
ハイブリッド検索が有効なケース
Difyの検索方式（Retrieval Setting）は主に以下の3種類があります。
- ベクトル検索のみ： 意味的に近い内容を幅広く拾う。固有名詞・型番には弱い傾向。
- 全文検索のみ： キーワード完全一致。意味の揺れや類義語に弱い。
- ハイブリッド検索： 両方を組み合わせ、重み付けやリランキングモデルを用いてスコアリング。
製品名や型番、専門用語が混在する業務ドキュメントにおいては、ハイブリッド検索 + リランキングモデルの組み合わせが、多くの場合で有力な選択肢となります。
6. メタデータ設計で検索精度と権限管理を両立する
Dify v1.1.0以降、ナレッジにカスタムメタデータを付与してフィルタリング検索できる機能が強化されています。これは「精度改善」と「権限管理」の2つの課題を同時に解決できる仕組みです。
推奨メタデータフィールド
メタデータを活用した権限制御の設計
RAGシステムの「権限漏れ」事故は、多くの場合このアクセス制御が未設計であることが原因です。
設計方針：
- ドキュメント登録時に access_level を必須フィールドとして設定
- 部署ごとにアプリを分け、参照できるナレッジを限定する
- restricted（制限付き）文書は専用ナレッジベースに分離し、該当アプリからのみ参照可能にする
7. よくある3つの事故と原因・対策
事故1：古い情報を正しいものとして回答し続ける
症状： 規程改定や仕様変更後も、以前の情報を答えてしまう。
対策：
- ドキュメントに version と last_updated メタデータを付与
- コネクタ等の自動同期機能を利用するか、旧バージョンのチャンクは「上書き」ではなく「削除→再登録」のフローで管理
事故2：正しい情報があるのに回答できない（検索ミス）
症状： ナレッジに登録してある内容なのに「見つかりません」と回答される。
対策：
- チャンクサイズをデータ種別ごとに見直す（セクション4参照）
- 検索方式を「ハイブリッド検索 + リランキング」に見直す
- 「検索プレビュー」機能でクエリに対してどのチャンクが取得されているかを確認
事故3：別部署のドキュメントが参照されてしまう（権限漏れ）
症状： 人事・経営情報が一般社員向けチャットボットの回答に含まれてしまう。
対策：
- 取り込み前に「公開レベル別の文書仕分け」を必ず実施
- 個人情報・機微情報（PII）は対象外とするか匿名化処理を挟む
- ナレッジベースを公開レベルごとに分離し、アプリごとの参照権限を明示的に制限する
8. RAG品質を測る評価指標 - 実務上の目安 -
「精度が低い気がする」という感覚的な評価では改善できません。ElcamyがPoC（概念実証）や導入初期に目標値として設定することの多い、実務上の目安をご紹介します。
- 正答率（Accuracy）：目安 80%以上 代表的なクエリセットを用意し、期待回答と照合して正確に回答できた割合。
- カバレッジ（Coverage）：目安 90%以上 「ナレッジに登録されているはずの情報」をクエリとして投げ、情報検索自体が成功した割合。
- ハルシネーション率：目安 5%以下 回答にナレッジ外の情報（LLM独自の推測）が含まれた割合。システムプロンプトで「ナレッジにない情報は回答しない」と明示して抑制します。
(※より高度な評価を行う場合、RagasやDeepEvalなどの外部評価フレームワークを組み合わせて定量計測を行うアプローチも有効です)
▼さらに詳しく知りたい方はこちら
※より高度な評価を行う場合、外部評価フレームワークを組み合わせて定量計測を行うアプローチも有効です。具体的な評価指標の考え方やRagasの実装については、こちらの記事で詳しく解説しています。
Dify導入・ナレッジパイプライン設計のご支援
「社内文書をRAGで活用したいが、どのアーキテクチャが適切かわからない」「PoC後に精度が上がらず本番化できない」という状況であれば、ElcamyのDify導入支援サービスが力になれます。要件定義〜パイプライン設計〜品質評価まで一貫して支援しております。
出典・免責事項
本記事は、2026年3月時点で確認できる Dify 公式ドキュメント・公式ブログ公開情報をもとに整理しています。Knowledge Pipeline やメタデータ、マルチモーダル機能の仕様はアップデートにより変更される場合があります。導入前には以下の最新の公式情報をご確認ください。
- Dify 公式サイト: https://dify.ai/
- Dify 公式ドキュメント (Knowledge Base): https://docs.dify.ai/features/knowledge-base
- Dify 公式ブログ (リリース情報等): https://dify.ai/blog