Difyで社内FAQを構築する — チャンク分割と検索精度の実務ガイド

社内FAQの自動化は、Difyで最初に取り組むのに適したワークフローです。 ただし現場では「モデルは合っているはずなのに回答がずれる」という声をよく聞きます。 原因の多くは、モデルの精度そのものではなく、その手前の「取り込み設計」にあります。

1. なぜ「取り込み」で結果が決まるのか

RAG (Retrieval-Augmented Generation) の回答精度は、大きく分けて次の3つのフェーズで決まります。

• Ingest: 文書のチャンク化・メタデータ付与
• Retrieve: 検索クエリの正規化・ベクトル検索・リランク
• Generate: 回答生成 (LLM側の制約と出典指示)

このうちDifyのUI上で最も"あとから修正が効きにくい"のがIngestです。 チャンク境界を後から変えると、埋め込み計算からやり直す必要があるため、 最初の設計判断が長く尾を引きます。

2. チャンク分割の実務判断

社内FAQ・規程を扱う場合、原則として「意味の切れ目」でチャンクを切ります。 機械的な文字数分割は、規程条文のような構造化文書では相性が悪いです。

推奨する分割単位

• 規程・マニュアル: 章・節単位
• FAQ集: 1問1答を1チャンク
• ハンドブック: 見出し (H2〜H3) 単位

# 例: マニュアルの分割ルール (擬似)
split_rules:
  - by: heading
    levels: [h2, h3]
  - max_tokens: 800
  - overlap: 80

3. メタデータをどう設計するか

チャンクにメタデータを付けておくと、後段の絞り込みが劇的に楽になります。 最低限、次の3つは付けておきたいところです。

• doc_type: 規程 / FAQ / マニュアル / 手順書
• updated_at: 改訂日 (古い規程を引かないためのフィルタ)
• access_scope: 全社 / 部署 / 経営層など

特に access_scope は、後から権限モデルを乗せる時に効いてきます。 「一度もフィルタしないRAG」は本番運用に耐えないため、最初から用意しておきます。

4. リランクは常に必要か

結論から言うと、FAQ用途では"入れておく方が事故が少ない"です。 ベクトル検索のトップ5〜10件を対象にリランクを噛ませることで、 「意味は近いが的外れ」なチャンクを弾けます。

リランクは万能ではありません。取り込み設計が破綻していると、 「悪いチャンクを丁寧に並べ替える」だけの結果になります。順序が大事です。

5. 出典表示は仕様として組み込む

社内利用では「その回答、どの文書から来た?」が問われます。 回答テンプレートに出典 (ドキュメント名 + 章タイトル) を必ず含める指示を入れ、 UIでも同時に表示するのが望ましいです。

まとめ

社内FAQの精度は、モデルよりも取り込み設計で決まります。 次のステップとして、実際にワークフローテンプレートを触ってみるのがおすすめです。