#ビジネス2026.03.19

Dify ナレッジパイプラインとは？RAG精度と運用を左右する設計（失敗例つき）

RAGチャットボットの運用における設計の重要性を解説し、Difyのナレッジパイプラインの機能を紹介。データ取り込み工程の可視化、チャンク分割の推奨設計、メタデータの活用、検索精度向上のためのハイブリッド検索の選択肢を提示。よくある事故とその対策、評価指標、定期的な更新運用の必要性についても言及している。

はじめに

RAGチャットボットを本番稼働させて数週間後、「なぜか古い情報を答え続ける」「特定部署のドキュメントが別部署にも見えてしまった」――こうした事故は、設計段階の判断ミスが後から表面化したものです。

2025年9月にDifyが公開した「ナレッジパイプライン（Knowledge Pipeline）」は、こうした問題の根本原因であるデータ取り込み工程を可視化・制御しやすくする仕組みです。本記事では、パイプラインの構造から実務設計のポイント、よくある失敗パターンと評価指標まで、現場担当者が意思決定できる粒度で解説します。

💡 この記事はこんな方におすすめです

AI導入やDXをリードするAI推進担当者
セキュアなRAG運用設計が求められる情シス担当者
チャットボットの回答精度に課題を感じている業務部門の方

1. ナレッジパイプラインとは何か

Difyが2025年9月に公開した「ナレッジパイプライン」は、RAGにおけるデータ取り込み工程（ETL：Extract → Transform → Load）をワークフロー形式で設計・管理できる機能です。

従来、Difyのナレッジ機能ではファイルをアップロードすると自動でベクトル化される「ブラックボックス」的な処理でした。ナレッジパイプラインではこの処理をノード単位で分解・制御できるようになり、「なぜこのチャンクが拾われないのか」「どの段階で精度が落ちているのか」をトレースしやすくなりました。

一言で言えば： 「RAGのデータ準備工程をGUIで可視化・設計できる機能」

2. 従来のナレッジ機能との違い

比較軸	従来のナレッジ機能	ナレッジパイプライン
処理の可視性	ブラックボックス	ノードごとに確認・調整が可能
チャンク戦略	固定設定のみ	ノードで柔軟に変更可能
データソース	ファイルアップロード中心	プラグインやコネクタ経由で各種クラウド（Google Drive等）に接続可能
マルチモーダル	テキスト中心	プラグイン構成により画像・表・スキャン文書にも対応可能
デバッグ	困難	ノード単位でテスト実行や観測が可能

「以前は精度が上がらない理由がわからなかった」という声が多い背景には、この可視性の欠如があります。パイプラインはそこに直接答える設計変更です。

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） 構築したパイプラインに対し、テストクエリを投げてチャンクの抽出結果をプレビューし、調整を行います。

▼さらに詳しく知りたい方はこちら

※画像や表を含む複雑なドキュメントを知識化するアプローチについては、こちらの記事もご覧ください。

blog.elcamy.com

リンク先の情報を読み込み中...

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つの課題を同時に解決できる仕組みです。

推奨メタデータフィールド

document_type : faq / manual / regulation / contract
department    : sales / hr / legal / product
last_updated  : 2026-01-15
access_level  : public / internal / restricted

メタデータを活用した権限制御の設計

RAGシステムの「権限漏れ」事故は、多くの場合このアクセス制御が未設計であることが原因です。

設計方針：

ドキュメント登録時に access_level を必須フィールドとして設定
部署ごとにアプリを分け、参照できるナレッジを限定する
restricted（制限付き）文書は専用ナレッジベースに分離し、該当アプリからのみ参照可能にする

7. よくある3つの事故と原因・対策

事故1：古い情報を正しいものとして回答し続ける

症状： 規程改定や仕様変更後も、以前の情報を答えてしまう。

対策：

ドキュメントに version と last_updated メタデータを付与
コネクタ等の自動同期機能を利用するか、旧バージョンのチャンクは「上書き」ではなく「削除→再登録」のフローで管理

事故2：正しい情報があるのに回答できない（検索ミス）

症状： ナレッジに登録してある内容なのに「見つかりません」と回答される。

対策：

チャンクサイズをデータ種別ごとに見直す（セクション4参照）
検索方式を「ハイブリッド検索 + リランキング」に見直す
「検索プレビュー」機能でクエリに対してどのチャンクが取得されているかを確認

事故3：別部署のドキュメントが参照されてしまう（権限漏れ）

症状： 人事・経営情報が一般社員向けチャットボットの回答に含まれてしまう。 対策：

取り込み前に「公開レベル別の文書仕分け」を必ず実施
個人情報・機微情報（PII）は対象外とするか匿名化処理を挟む
ナレッジベースを公開レベルごとに分離し、アプリごとの参照権限を明示的に制限する

elcamy.com

リンク先の情報を読み込み中...

8. RAG品質を測る評価指標

実務上の目安 -

「精度が低い気がする」という感覚的な評価では改善できません。ElcamyがPoC（概念実証）や導入初期に目標値として設定することの多い、実務上の目安をご紹介します。

正答率（Accuracy）：目安 80%以上 代表的なクエリセットを用意し、期待回答と照合して正確に回答できた割合。
カバレッジ（Coverage）：目安 90%以上 「ナレッジに登録されているはずの情報」をクエリとして投げ、情報検索自体が成功した割合。
ハルシネーション率：目安 5%以下 回答にナレッジ外の情報（LLM独自の推測）が含まれた割合。システムプロンプトで「ナレッジにない情報は回答しない」と明示して抑制します。

(※より高度な評価を行う場合、RagasやDeepEvalなどの外部評価フレームワークを組み合わせて定量計測を行うアプローチも有効です)

▼さらに詳しく知りたい方はこちら

※より高度な評価を行う場合、外部評価フレームワークを組み合わせて定量計測を行うアプローチも有効です。具体的な評価指標の考え方やRagasの実装については、こちらの記事で詳しく解説しています。