Dify / RAG精度
DifyでRAGの精度が出ないとき — Dify内でできること、Difyの外で解くこと
Difyで社内文書に答えるチャットを作った。デモは動いた。ところが現場が普段どおりの質問を投げ始めると、外れる——「Dify RAG 精度」で検索してこの記事にたどり着いた方は、たぶんこの状態だと思います。
最初に立場を言っておくと、私たちはRAGの構築と精度改善を仕事にしていますが、Difyから始めたことを間違いだとは思いません。ノーコードで文書を入れて試せる立ち上がりの速さは本物で、「まず動くものでニーズを確かめる」段階の道具として合理的です。問題はその先です。この記事では、精度が出ないときにDify内で調整できるツマミを先に出し切り、そのうえで「ここから先はDifyの外で解く領域だ」という線引きを、実装者の視点で書きます。設定項目の記述は、執筆時点（2026年8月）のDify公式ドキュメントに基づいています。
前提: 精度の壁は、Difyの欠陥ではない
まず押さえたいのは、いま突き当たっている壁がDify固有の問題ではないことです。Dify自身が、ナレッジ機能を大きく作り直したリリース（v1.9.0のKnowledge Pipeline）の告知で、ユーザーの痛点を「不正確なナレッジ検索、情報の欠落、最適でないチャンク結果」と率直に挙げています。つまりベンダー自身が認めるとおり、RAGの精度はツールを選んでも自動では出ない。データの切り方・検索の設計・測り方という、RAG共通の積み上げがそのまま要るのです。
だからこの記事は「Difyをやめて◯◯へ」という話ではありません。Difyの中でできることを全部やり、それでも残る部分だけを外に出す。順に見ていきます。
Dify内でできること — 精度のツマミは7つ
相談を受けていて感じるのは、Difyの精度調整のツマミが意外と使われていないことです。既定値のまま文書を放り込み、既定値のまま検索している。まず7つを一覧にします。
| ツマミ | 何を変えるか | 見る場所 |
|---|---|---|
| インデックス方式 | High Quality（ベクトル化）か Economical（キーワードのみ）か | ナレッジベース設定 |
| チャンク設定 | 区切り記号・最大チャンク長・オーバーラップ | チャンク設定（General） |
| 親子チャンク | 子チャンクで検索し、親チャンクで文脈を渡す | チャンク設定（Parent-child） |
| 検索方式 | ベクトル／全文／ハイブリッド＋セマンティックとキーワードの重み | 検索設定 |
| Top K・スコアしきい値 | 何件拾うか・どこで足切りするか | 検索設定 |
| リランキング | 拾った候補を質問への適合度で並べ直す | 検索設定（Rerankモデル） |
| メタデータフィルタ | 版・部署・日付などで検索対象を絞る | メタデータ＋検索ノード |
いくつか補足します。
インデックス方式は最初に確認してください。Economicalはチャンクあたり10個のキーワードで引く方式で、埋め込みのトークン費用がかからない代わりに、公式ドキュメント自身が検索精度は落ちると明記しています。しかも切り替えは一方向です。Economicalで作ってしまった場合はナレッジ設定画面からHigh Qualityへ上げられますが、High Qualityで作った後にEconomicalへ戻すことはできません。精度の相談をする以前に、ここがEconomicalのままというケースは実際にあります。
チャンク設定は、前処理がRAG精度の8割を決めるという話のDify版です。既定の区切りのまま切ると、見出しと本文が泣き別れたり、答えの半分だけが入った断片が生まれる。区切り記号を文書の構造（空行・見出し記法）に合わせるだけでも、渡る素材の質が変わります。親子チャンクは「検索は細かく・文脈は広く」を両立させる仕組みで、答えの前後が切れて回答が浅くなる症状に効きます。注意点として、親を文書全体にするFull Docモードは先頭10,000トークンで打ち切られ、親チャンクは作成後に編集できません。
検索方式は、固有名詞・型番・規程番号で外すならハイブリッド一択です。意味の近さで探すベクトル検索は、一字違いで別物になる語が苦手だからです（なぜそうなるかはハイブリッド検索の設計に書きました）。Difyはハイブリッド時にセマンティックとキーワードの重みを振れるので、社内語彙が強い文書ならキーワード寄りに倒して試す価値があります。Top K・しきい値は執筆時点の既定が3件・0.5で、しきい値を上げすぎて正解チャンクごと足切りしている例も、Top Kが小さすぎて根拠が揃わない例もあります。リランキングはRerankモデルを接続すると使えます。メタデータフィルタは、古い版や別部署の文書が混ざって誤答する症状への処方で、版・部署・日付をメタデータに持たせて検索時に絞り込めます。
あわせて、回答に出典を付けるCitation機能と、単発のクエリで検索結果を確かめるRetrieval Testingは常用してください。精度の議論は「どのチャンクが拾われたか」を見るところからしか始まりません。
症状から引く — どのツマミから触るか
| 症状 | まず触るツマミ |
|---|---|
| 社名・型番・規程番号で別の文書が返る | 検索方式をハイブリッドに＋キーワード側の重みを上げる |
| 答えの半分だけ・文脈が切れた浅い回答 | チャンク設定を文書構造に合わせる／親子チャンク |
| 古い版・関係ない部署の文書が混ざる | メタデータフィルタ（版・部署・日付） |
| 惜しいが答えていない文書が上位に並ぶ | リランキングを追加 |
| そもそも正解の文書が拾われていない | インデックス方式の確認・Top K/しきい値を緩める |
この表で直る範囲なら、Difyの中で完結します。実際、ここまでで体感が大きく変わるケースは珍しくありません。
ここまでやっても残る壁 — Difyの外で解く4つ
問題は、ツマミを全部触っても残る症状です。私たちの整理では、次の4つはDifyの機能の外にあります。
壁1: 精度を「測る」仕組みがない。 Difyには単発の検索テスト（Retrieval Testing）とログはありますが、評価セットを流して正答率を出す機構は、公式ドキュメントの機能一覧に存在しません。つまり「設定を変えたら良くなったのか」を、感覚ではなく数字で確かめる手段がDify内にない。ツマミが7つもあるのに物差しがないのは、実は一番苦しい制約です。私たちが商社の文書検索で正答率38.8%を93.6%まで運べたのは、業務シナリオの評価セットという物差しを先に作り、変更のたびに測ったからでした（評価セットの作り方）。Difyで運用する場合も、評価セットと採点スクリプトは外に持つことになります。
壁2: 文書構造に沿った分割は、Dify内で完結しない。 Difyのチャンカーは、区切り記号ベースのGeneral、親子、Q&Aの3種です。「条文単位で切り、条見出しを先頭に含め、短い条は束ねる」といった文書構造に沿った分割は、UI上の設定では作れません。ただしここには正式な逃げ道があります。DifyのAPIは分割済みのチャンクをそのまま投入する口（Chunks API）を持っており、外部で構造に沿って切ってから入れる構成が公式にサポートされています。前処理だけ外で書き、検索と画面はDifyに任せる——という分担が現実的です。
壁3: クエリ拡張・用語の正規化が、機能として無い。 通称・略称を正式名称に展開してから検索する、表記ゆれを辞書で吸収する、といった検索前の変換は、ナレッジベース設定にも検索ノードにも項目がありません。社内略語が強い文書群では、この不在が精度の頭を押さえます。ワークフローのLLMノードを検索の前段に置いて自作することはできますが、それは「Difyが機能として持っている」のとは別の話です。
壁4: 参照でつながった文書。 規程や契約のように「第◯条を準用する」で条文同士がつながる文書は、起点の条文だけ拾っても回答が不正確になります。参照関係を辿るGraph RAGに相当する機能は公式ドキュメントに記載がありませんが、これも公式の接続口があります。External Knowledge Base——自前のRAG検索をAPIでDifyに繋ぐ仕組み——を使えば、参照辿りを実装した検索を裏側に置き、DifyはUIと会話の層として使い続けられます。
線引きの結論 — 「脱却」ではなく、外に出す部分を選ぶ
まとめると、こうなります。
- Difyで粘る: 症状→ツマミの表で直る範囲。インデックス方式・チャンク・親子・ハイブリッド・しきい値・リランク・メタデータ。
- 外に持つ: 評価セットと採点（壁1）。これはDifyを使い続けるとしても最初に作る価値があります。
- 外で作って繋ぐ: 構造に沿った前処理（壁2・Chunks API）、参照辿りや独自検索（壁4・External Knowledge Base）。
「Difyからの脱却」という言い方をよく見かけますが、実装者としての実感はすこし違います。DifyはUI・権限・会話管理の層として優秀で、そこまで捨てる必要はない。効いていないのは検索と評価の層であり、そこだけ自前化する段階的な道が、公式のAPI設計としても用意されている。全部をDifyで粘るのでも、全部を作り直すのでもなく、どの層を外に出すかを選ぶ——それがこの記事でいちばん伝えたい線引きです。
よくある質問
DifyのRAG精度を上げる設定は、どこから触ればよいですか。
順番としては、①インデックス方式がHigh Qualityか確認、②検索方式をハイブリッドにして重みを調整、③チャンク設定・親子チャンクを文書に合わせる、④リランキングとメタデータフィルタ、です。ただし本文に書いたとおり、変更の効き目を測る物差し（評価用の質問リスト）を先に用意しないと、どの変更が効いたのか分からなくなります。小さくてよいので質問リストから始めることをすすめます。
Economicalモードで作ってしまいました。High Qualityに変えられますか。
変えられます。公式ドキュメントは、Economicalの性能が期待に届かない場合、ナレッジ設定画面からHigh Qualityへアップグレードできると明記しています。切り替えが効かないのは逆方向で、High Qualityで作ったナレッジベースをEconomicalへ戻すことはできません。
Difyだけで業務品質のRAGは作れますか。
対象文書が整っていて、症状→ツマミの範囲で精度が足りるなら作れます。一方で、「正しく答えているか」を数字で保証したい業務——規程・契約・技術文書——に入ると、評価を外に持つことは避けられず、文書構造に沿った前処理や参照辿りが要る場合はAPI連携の設計が入ります。そこからは、ノーコードの範囲を超えた通常のRAG構築の世界です（RAG構築の手順）。
Difyから自社構築へ移行するべきタイミングはいつですか。
「移行」を一括で考える必要はありません。評価セットで測りたくなったら評価だけ外に作る。分割を変えたくなったら前処理だけ外で書いてChunks APIで入れる。検索そのものを作り込みたくなったらExternal Knowledge Baseで繋ぐ。外に出した部分が増え、Difyに残っているのがUIだけになったときが、いわゆる「移行」を検討する自然なタイミングです。
Difyユーザーの精度点検リスト
- インデックス方式はHigh Qualityになっているか。
- チャンクの区切りは文書の構造（見出し・空行）に合っているか。答えの半分だけのチャンクが生まれていないか。
- 固有名詞で外すなら、ハイブリッド検索＋重み調整を試したか。
- Top K・スコアしきい値で、正解チャンクを足切りしていないか。
- 古い版・別部署の混入は、メタデータフィルタで塞いだか。
- 設定変更の効き目を測る質問リスト（評価セット）を持っているか。
- それでも残る症状は、壁1〜4（評価・構造分割・クエリ拡張・参照辿り）のどれかに当てはまらないか。
Difyの検索、外から見立てませんか
Difyで作ったRAGの「どの層で精度を落としているか」は、症状を聞けばかなり絞り込めます。いまの設定と、どの種類の質問で外れるのかを聞かせていただければ、ツマミで直る範囲か、外に出す段階かの当たりをお伝えします。発注前提ではない30分のオンライン相談です。RAG精度の全体像は症状から原因を引く診断ガイドに、精度改善が数字で動いた記録は商社の文書検索事例にあります。
参考文献
- Dify Docs: Configure the Chunk Settings — docs.dify.ai
- Dify Docs: Specify the Index Method and Retrieval Settings — docs.dify.ai
- Dify Docs: Knowledge Retrieval Node — docs.dify.ai
- Dify Docs: Metadata — docs.dify.ai
- Dify Docs: Connect External Knowledge Base — docs.dify.ai
- Dify v1.9.0 Release Notes (Knowledge Pipeline) — GitHub
この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。Difyの機能・既定値の記述は執筆時点（2026年8月）の公式ドキュメントおよび公式リリースノートの確認に基づきます。事例の数値はすべて公開済みの実案件既出値です。
Read next