Difyで「自前の文書を根拠に答えさせたい」とき、中核になるのがナレッジベース（Knowledge）だ。
公式ドキュメントでは、ナレッジは Retrieval-Augmented Generation（RAG）により、LLMの事前学習データだけに頼らず、自分のデータを追加の根拠として使う仕組みとして説明されている。
この記事では、初心者向けに RAG の流れと、Dify で最初に決めるチャンク・索引・検索の選び方を整理する。
結論：まず押さえる3点
| 決めごと | 初心者の既定 | 後から変えやすいか |
|---|---|---|
| チャンクモード（General / Parent-child） | FAQ・用語集なら General。手順書・マニュアルなら Parent-child | 作成後は変更不可（区切り文字や最大長は後から調整可） |
| 索引方式（High Quality / Economical） | 精度を取るなら High Quality | High Quality → Economical への切替は不可。Economical から High Quality へのアップグレードは可能 |
| 検索方式（Vector / Full-Text / Hybrid） | 意味で当てたいなら Vector または Hybrid | High Quality なら設定で選べる |
| RAGの段階 | 何が起きるか | Difyでの対応箇所 |
|---|---|---|
| Retrieval（検索） | 質問に近いチャンクを取り出す | ナレッジの索引・検索設定、Retrieval Testing |
| Augmented（補強） | 取り出した文を質問と一緒にLLMへ渡す | アプリの Context / Knowledge Retrieval ノード |
| Generation（生成） | 文脈を踏まえて回答を作る | LLMノード／チャットボットの応答 |
迷ったら「FAQを数ファイル入れて、High Quality ＋ Hybrid（または Vector）で Retrieval Testing」から始めるとよい。
RAGとは何か（Dify公式の定義）
公式の Knowledge 概要では、RAG を次の3段階で説明している。
- Retrieval … ユーザーの質問に対し、取り込んだナレッジから最も関連する情報を取り出す
- Augmented … 取り出した情報を元の質問と組み合わせ、LLMへの補強コンテキストにする
- Generation … LLMがそのコンテキストを使って、より正確な回答を生成する
ポイントは「モデルを再学習する」のではなく、「質問のたびに関連文書を探して渡す」ことだ。
ナレッジベースは用途ごとに複数作れ、アプリへ選択的に紐づけられる。
ナレッジベースを作る最短手順
公式の「Create a Ready-to-Use Knowledge Base」は、次の4ステップだ。
- Knowledge → Create → Create a ready-to-use knowledge base で作成し、ローカルファイル／Notion／Webページを取り込む（空のナレッジも可）
- チャンク設定を決め、プレビューで分割結果を確認する
- 索引方式と検索設定を指定する
- データ処理の完了を待つ
取り込み後の索引化は非同期で進む。API上の状態遷移は waiting → parsing → cleaning → splitting → indexing → completed（または error）と説明されている。UIでも処理完了を待ってからアプリ連携に進む。
[文書アップロード]
↓
[前処理・クリーニング]
↓
[チャンク分割] ← ここが検索の粒度を決める
↓
[索引（Embedding等）]
↓
[アプリの Context に紐づけ]
↓
[質問 → 検索 → コンテキスト補強 → 回答]
チャンク：長文を「探せる単位」に割る
チャンクは、長い文書を検索しやすい小さな断片に分割したものだ。
公式のたとえどおり、一冊の本を章・段落に分けるイメージでよい。全文を毎回LLMに渡すのは遅く非効率なので、関連しそうな断片だけを渡す。
主なパラメータ:
| 項目 | 意味 |
|---|---|
| Delimiter（区切り文字） | どこで切るか（例: \n\n は段落、\n は行） |
| Maximum chunk length | 1チャンクの最大文字数。これを超えると強制分割 |
| Chunk overlap（General） | 隣接チャンクの重なり文字数。境界で文脈が切れにくくなる |
注意点:
- 区切り文字自体はチャンキング時に除去される。本文に自然に出てくる文字を区切りにしない
- チャンクモード（General / Parent-child）はナレッジ作成後に変更できない
- 区切り文字や最大長は後から調整できる
General と Parent-child
| 観点 | General | Parent-child |
|---|---|---|
| 構造 | 1階層。同じ設定のチャンク | 2階層。小さい child ＋ 大きい parent |
| 検索の動き | 一致したチャンクをそのまま返す | child でマッチし、返すのは parent（広い文脈） |
| 使える索引 | High Quality / Economical | High Quality のみ |
| 向きやすい用途 | FAQ、用語集など自己完結な短い単位 | 手順書・技術文書など、文脈が必要な文書 |
Parent-child の parent は Paragraph（区切りと最大長で複数親）か Full Doc（文書全体を1親）を選べる。
Full Doc では先頭約10,000トークンのみ処理され、それ以降は切り捨てられる。parent の編集もできず、直すなら再アップロードが必要、と公式にある。
初心者の目安:
- 1問1答に近い資料 → General
- 「この節の前後も読ませたい」文書 → Parent-child（Paragraph）
索引方式：High Quality と Economical
| 方式 | 仕組み | 検索オプション | 注意 |
|---|---|---|---|
| High Quality | Embedding でチャンクをベクトル化。意味の近さで探せる | Vector / Full-Text / Hybrid | 作成後に Economical へは戻せない |
| Economical | チャンクあたり最大10キーワード。トークン消費なしで精度は落ちやすい | 転置索引ベース | 期待に届かなければ High Quality へアップグレード可 |
High Quality では、ベクトルを多次元空間上の座標のように扱い、近い点ほど意味が近い、と公式が説明している。
画像も意味で取りたい場合は、Vision 対応のマルチモーダル Embedding を選ぶ。
検索設定：Vector / Full-Text / Hybrid
High Quality では、次の3つから選ぶ。
| 方式 | 何をするか | 向く場面 |
|---|---|---|
| Vector Search | 質問をベクトル化し、近いチャンクを取る | 言い回しが違う質問、多言語の意味合わせ |
| Full-Text Search | 文書中の語を索引し、語句を含む断片を返す | 固有名詞・型番など「Exactな語」が分かっているとき |
| Hybrid Search | 全文検索とベクトル検索を同時に行い、結果を再整理 | どちらも捨てたくないとき（実務の既定候補） |
Hybrid では、外部 Rerank モデルなしの Weight settings（意味 vs キーワードの比重）か、外部 Rerank モデルを選べる。
よく触るパラメータ:
| パラメータ | 既定（公式） | 意味 |
|---|---|---|
| TopK | 3 | 返すチャンク数の目安。大きいほど文脈は増えるがノイズも増えやすい |
| Score Threshold | 0.5 | これ未満の類似度は捨てる。上げるほど厳選される |
公式の注意として、一部の設定では TopK / Score が Rerank フェーズでのみ効く場合がある。意図どおり絞りたいときは、Rerank の要否と設定画面の説明をセットで確認する。
複数ナレッジをアプリに紐づける場合は、マルチパス検索で各ナレッジから候補を集め、Weight Score または Rerank で最終順位を付ける流れになる。
Embedding モデルがナレッジ間で不一致だと Weight Score が使えず、Rerank や設定の統一が必要になる、という公式 FAQ もある。
アプリへ紐づけて動かす
代表的な流れ（チャットアシスタントを例にした公式手順）:
- ナレッジを作成し文書を入れる
- Studio でアプリを作成する
- Context でナレッジを追加する（Chatflow/Workflow なら Knowledge Retrieval ノード）
- 必要なら Metadata Filtering で対象文書を絞る
- Retrieval Setting を確認する
- Citation and Attribution（引用・出典表示）を有効化すると根拠の可視化に役立つ
- Debug / Preview で質問を試し、問題なければ公開する
アプリ連携前に、ナレッジ画面の Retrieval Testing で「質問 → どのチャンクが返るか」を単体確認できる。
ここでの検索設定変更は一時的で、テストセッションにだけ効く。本番設定はナレッジ／アプリ側の正規設定で行う。
実装チェックリスト
- 用途ごとにナレッジを分けるか、1つにまとめるかを決める（混ぜすぎると検索ノイズが増えやすい）
- チャンクモードを決める前に、FAQかマニュアルかを判定する（後からモード変更不可）
- Preview でチャンクを見て、1チャンクに複数論点が混ざっていないか確認する
- 精度が必要なら High Quality を選び、Economical は検証用途かコスト制約時に限定する
- 言い換え質問と Exact 語質問の両方で Retrieval Testing する
- Hybrid なら Weight（意味/キーワード）か Rerank のどちらで順位付けするかを決める
- アプリの Context にナレッジを紐づけ、Citation and Attribution を有効化して出典を確認する
- TopK と Score Threshold を変え、回答の根拠が薄すぎ／多すぎないかを見る
失敗パターン
パターン1：文書を丸ごと1チャンクにして精度が出ない
→ 対策：General で段落区切り（\n\n）と最大長を見直し、Preview で「1チャンク＝1トピック」に近づける。文脈が必要なら Parent-child を検討する。
パターン2：Economical のまま意味検索を期待する
→ 対策：言い換えや多言語の意味合わせが必要なら High Quality に上げる。Economical はキーワード寄りの簡易索引と割り切る。
パターン3：アプリに繋いだまま原因切り分けができず迷走する
→ 対策：先に Retrieval Testing で「取れているか」を見る。取れていないならチャンク／索引／検索の問題。取れているのに回答が悪いならプロンプトや TopK／閾値の問題、と切り分ける。
パターン4：複数ナレッジ＋異なる Embedding で Weight Score が使えない
→ 対策：公式 FAQ どおり、Embedding を揃えるか Rerank モデルを使う。まずナレッジを1つに絞って挙動を固めるのも有効。
パターン5：Full Doc の Parent-child で長文が途中から消える
→ 対策：Full Doc は約10,000トークン制限がある。長い文書は Paragraph 親にするか、文書を分割して投入する。
まとめ
- Dify のナレッジは、RAG（検索→補強→生成）で自前データを根拠にする仕組み。
- 最初の分岐は チャンクモード と 索引方式。どちらも後からの自由度が低いので、FAQかマニュアルか・精度が要るかを先に決める。
- 運用の肝は Retrieval Testing。「取れない」と「取れるが回答が悪い」を分けてからパラメータを触る。
- アプリ側では Context 紐づけと Citation 表示までセットにすると、根拠付き回答の確認がしやすい。
次の一歩としては、短い FAQ（数問）を General ＋ High Quality で入れ、言い換え質問で Retrieval Testing → 同じナレッジをチャットアプリの Context に載せる、までを一度通すと理解が定着する。
参考リンク
- Knowledge（Dify Docs）
- Create a Ready-to-Use Knowledge Base
- Configure the Chunk Settings
- Specify the Index Method and Retrieval Settings
- Test Knowledge Retrieval
- Integrate Knowledge within Apps
- Dify公式ドキュメント
- Dify GitHubリポジトリ
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。