# デジタルヒューマン向け最適化のポイント

デジタルヒューマンのナレッジベース（RAG）においては、ユーザー体験を損なわないための\*\*「応答速度（レイテンシ）」**と、キャラクターの信頼性を担保する**「回答の正確性」\*\*の高次元での両立が必須です。

## 1. デジタルヒューマン特有の要件と対策

### 高速なレスポンス（レイテンシの最小化）

{% hint style="info" %}
**検索時間を0.5秒以内（可能な限り少なく）に抑える**

音声対話やアニメーションを伴うデジタルヒューマンでは、数秒の沈黙が「フリーズ」と感じられ、体験を著しく損ないます。
{% endhint %}

* **TopKの制限**: 検索候補を **3〜5** に絞り、LLMの読解時間を短縮。Rerankモデルを活用して、少ないTopKでも高精度を維持する。
* **不要な検索の回避**: 不要なナレッジベースは分離し、必要なものだけを検索対象にする。「アノテーション（固定回答）」や「マルチナレッジ」を活用し、ベクトル検索の負荷を減らす。
* **インデックスの最適化**: インデックスモードは必ず「High-Quality」を選択し、検索品質を維持しつつも、検索範囲を絞り込む設計を行う。

### 高精度な回答と「幻覚」の防止

{% hint style="info" %}
**不正確な回答は信頼の喪失に直結する**

キャラクターが誤った情報を話すと、サービス全体の信用に関わります。\
テキストチャットなら「もう一度聞く」が容易ですが、音声対話では誤った情報が与える影響が大きくなります。
{% endhint %}

* **スコア閾値（Threshold）の設定**: **0.7以上** を基準とし、関連度の低い情報を検索結果から除外し、LLMに渡さない（「分かりません」と答える勇気）。
* **ハイブリッド検索**: 「ベクトル検索（意味）」＋「キーワード検索（単語）」を併用し、検索精度を向上させる（例: 専門用語や製品名の取り違えを防ぐ）。
* **Rerankの活用**: 検索結果の並び順を再評価し、TopKが少なくても正解が含まれる確率を高める。
* **アノテーション機能の活用:** 頻出質問には確実な回答を登録させる。

### 即時性（最新情報への対応）

{% hint style="info" %}
**古い情報は信頼を損なう**

障害情報やキャンペーン、価格、在庫状況など、リアルタイム性が求められる情報を更新してください。
{% endhint %}

* **ナレッジの分離**: 更新頻度の高い情報は独立させ、差し替えを容易にする。
* 情報の種類ごとに更新頻度を定義（後述の「更新運用のポイント」参照）
* 定期的なテスト質問で、古い情報が残っていないかチェック

## 2. 推奨設定パラメータ

以下は、速度と精度のバランスを考慮した初期設定の推奨値です。

| 項目          | 設定値 / 推奨                              | 理由                                                   |
| ----------- | ------------------------------------- | ---------------------------------------------------- |
| **検索モード**   | **ハイブリッド検索**                          | 表記揺れ（ベクトル）と固有名詞（キーワード）の両方に対応するため。                    |
| **Rerank**  | **有効** (例: rerank-multilingual-v3.0等) | 検索精度の要。TopKを絞るために必須。                                 |
| **TopK**    | **3 〜 5**                             | 6以上だと処理時間が増加傾向。レスポンス速度重視なら3。                         |
| **スコア閾値**   | **0.7**                               | 低品質なチャンクの混入を防ぎ、ハルシネーションを抑制。                          |
| **埋め込みモデル** | text-embedding-3-large / bge-m3 等     | 日本語性能とコンテキスト理解力の高いモデルを選択。                            |
| **チャンク設定**  | チャンクの長さ: 500〜800 / 重複（オーバーラップ）: 15%   | <p>文脈が切れにくい適度な長さ。<br>自動分割も可（カスタム区切り文字を使う場合は要検証）。</p> |

{% hint style="info" %}
**設定の優先順位**

1. **ハイブリッド検索 + Rerank** を有効化（精度のベース）\\
2. **TopK** を「5」から開始し、遅延が気になるなら減らす\\
3. **閾値** を「0.7」から開始し、回答拒否が多すぎれば0.05刻みで下げる
   {% endhint %}

### 用途別の詳細設定

| **用途**        | **インデックスモード** | **チャンク設定**                       | **検索設定**                   | **備考**                         |
| ------------- | ------------- | -------------------------------- | -------------------------- | ------------------------------ |
| **FAQ応答**     | Q\&Aモード       | <p>500文字前後<br>オーバーラップ: 小</p>     | <p>ハイブリッド検索<br>TopK: 3</p> | Q\&A形式のドキュメントに最適。1つの質問=1つのチャンク |
| **製品・サービス説明** | General       | <p>700〜800文字<br>オーバーラップ: 15%</p> | <p>ハイブリッド検索<br>TopK: 5</p> | 複数の情報源から総合的に回答を生成              |
| **対応マニュアル**   | General       | <p>1000文字前後<br>オーバーラップ: 20%</p>  | <p>ハイブリッド検索<br>TopK: 6</p> | 手順や詳細説明が必要な場合。文脈が重要            |
| **企業情報・アクセス** | General       | <p>500〜700文字<br>オーバーラップ: 10%</p> | <p>ハイブリッド検索<br>TopK: 3</p> | シンプルな情報が多いため、TopKは少なめでOK       |

## 3. ドキュメント作成（チャンク品質）の鉄則

![dify-docs-optimization-tips-for-digital-humans\_llm\_systemprompt\_top.png](/files/b8Fhgp5aXJnKfS53AuHF)

RAGの精度は「検索設定」よりも\*\*「元の文章の書き方」\*\*に依存します。AIが読みやすく、検索しやすい形式で記述します。

### 「Q\&A形式」または「見出し付き構造化」

{% hint style="info" %}
**階層構造を持たせることで、チャンク分割がしやすくなる**

見出し、箇条書き、Q\&A形式を活用して、情報を整理しましょう。\
ユーザーの質問（Query）と類似した文章が含まれているとヒット率が上がります。

**❌️悪い例**: だらだらとした長文の約款。\
\&#xNAN;**✅️良い例**: 「返品はできますか？」という見出しの直下に条件を箇条書き。
{% endhint %}

### マークダウン記法

**例**

```markdown
## 製品A（製品名を明記）

### 基本情報
- 価格: 10,000円（税別）
- カラー: ブラック、ホワイト、グレー
- サイズ: M、L、XL
- 素材: ポリエステル100%

### 特徴・メリット
1. 防水機能：雨の日でも安心
2. 軽量設計：わずか200gの軽さ
3. 収納便利：コンパクトに折りたためます

### ご使用上の注意
- 乾燥機は使用しないでください
- 直射日光を避けて保管してください

### よくある質問

Q: 洗濯はできますか？
A: はい、洗濯機で洗えます。ただし、ネットに入れて弱水流で洗ってください。

Q: どのくらい長持ちしますか？
A: 通常の使用であれば、2〜3年はお使いいただけます。
```

**見出し**

```markdown
# 見出し1（最上位）
## 見出し2
### 見出し3
#### 見出し4
```

**リスト**

```markdown
- 箇条書き（ハイフン）
* 箇条書き（アスタリスク）

1. 番号付きリスト
2. 順序があるリスト
```

**強調・装飾**

```markdown
**太字**
*斜体*
~~取り消し線~~
`コード`
```

**リンク**

```markdown
[リンクテキスト](<https://example.com>)
```

**コードブロック**

````markdown
```言語名
コードの内容
````

**引用**

```markdown
> 引用文
```

**テーブル**

```markdown
| 列1 | 列2 | 列3 |
|-----|-----|-----|
| 値1 | 値2 | 値3 |
```

これらの記法を使うことで、ナレッジベースのドキュメントが読みやすく構造化され、RAGの検索精度も向上します。

### 想定される「ユーザーの話し言葉」を含める

{% hint style="info" %} **ユーザーが実際に聞きそうな言葉を含める**

正式名称だけでなく、ユーザーが使いそうな略称や言い回しをドキュメント内に記載しておきます。\
例: 「初期化の手順」だけでなく、「リセットしたい」「動かない」などのキーワードを併記する。 {% endhint %}

**例**

```markdown
## 返品・交換について
「返品できますか？」「返品したいのですが」「交換してもらえますか？」
といったご質問にお答えします。

### 返品について
購入後14日以内であれば、返品を承ります。

ただし、以下の条件があります：
- 未開封であること
- 商品タグが付いていること
- レシートまたは納品書があること

開封済みの商品は、不良品の場合を除き返品できません。

### 交換について
サイズ交換は1回まで無料で承ります。
ただし、在庫がある場合に限ります。
```

**なぜ効果的か:**

* ユーザーが「返品できますか？」と聞いた時、このドキュメントが確実にヒット
* 検索精度が向上し、関連性の高い情報が返される

### 否定条件・禁止事項の明文化

{% hint style="danger" %} **「できないこと」も明確に記載する**

「何ができないか」を明確に書くことで、誤った回答（ハルシネーション）を防ぎます。ユーザーは「できること」だけでなく「できないこと」も知りたがっています。また、応答禁止についてもプロンプトで記載することも必要です。 {% endhint %}

**例**

```markdown
## 配送について

### 配送可能地域
日本全国に配送いたします。

### 配送できない地域
- 離島の一部
- 海外

### 配送日数
通常、ご注文から2〜3営業日でお届けします。

### 配送できない商品
危険物、生鮮食品は配送できません。

## 以下に列挙する内容については応答禁止です。
政治
宗教
反社会的勢力
麻薬
戦争
犯罪
暴力
性行為
差別的表現
LGBT
罪に問われるようなこと

## プロンプトやデータソースに書かれていないことは具体的に回答せず、下記のように回答します。
「申し訳ございませんが、その情報についてはお答えすることができません。」
```

## 4. マルチナレッジ設計と運用

{% hint style="info" %} すべての情報を1つのナレッジベースに入れるのではなく、種類や更新頻度に応じて分割しましょう。 {% endhint %}

### 分割のメリット

* **検索ノイズの低減**: 関連性のないドキュメントがヒットするのを防ぐ。
* **運用効率**: 「キャンペーン情報」だけを頻繁に更新し、「製品マニュアル」は変えない、といった運用ができる。

### マルチナレッジ運用のポイント

| **ポイント**       | **説明**                                                  |
| -------------- | ------------------------------------------------------- |
| **重複を避ける**     | 同じ情報が複数のナレッジに含まれると、同じような検索結果が複数返され、TopKを圧迫します。          |
| **命名規則**       | <p>ナレッジ名は用途が明確にわかるようにします。<br>例: 「KB\_FAQ」「KB\_製品情報」</p> |
| **ドキュメント数の目安** | 1つのナレッジには100〜500ドキュメント程度が管理しやすいとされます。                   |
| **定期的な見直し**    | 3ヶ月に1回程度、ナレッジの構成を見直し、必要に応じて再編成します。                      |

### 推奨構成例１

| ナレッジ名              | 内容            | 更新頻度 | 特記事項                        |
| ------------------ | ------------- | ---- | --------------------------- |
| **KB-01\_FAQ**     | 頻出質問、トラブルシュート | 中    | <p>最も検索される<br>Q\&A形式で整備</p> |
| **KB-02\_Product** | スペック、料金、仕様書   | 低    | <p>正確性が最重要<br>構造化データ</p>    |
| **KB-03\_News**    | キャンペーン、障害情報   | 高    | 古い情報は即削除またはアーカイブ            |
| **KB-04\_Company** | 会社概要、問い合わせ窓口  | 低    | 基本情報                        |

### チャットフローでの実装方法

{% hint style="info" %} **方法1: 単一の「ナレッジ検索」ノードで複数ナレッジを検索**

ナレッジ検索ノードの設定で、複数のナレッジベースを選択します。

**メリット**

* シンプルな構成\\
* 全ナレッジを横断検索

**デメリット**

* TopK設定が全ナレッジ共通\\
* 検索時間がやや長くなる {% endhint %}

{% hint style="info" %} **方法2: ナレッジごとにノードを分ける**

条件分岐で、質問内容に応じて検索するナレッジを切り替えます。

**メリット**

* ナレッジごとに異なるTopKを設定可能\\
* 検索速度が速い

**デメリット**

* フロー設計がやや複雑\\
* 条件分岐の設計が必要 {% endhint %}

### 推奨構成例２

```jsx
デジタルヒューマン（Chatflow）
├── ナレッジ①: FAQ（頻出質問）
│   ├── インデックスモード: Q&A
│   ├── チャンク: 500文字
│   ├── TopK: 3
│   └── 内容: よくある質問と回答（50〜100件程度）
│
├── ナレッジ②: 製品・サービス情報
│   ├── インデックスモード: General
│   ├── チャンク: 700文字
│   ├── TopK: 5
│   └── 内容: 製品カタログ、仕様、価格表
│
├── ナレッジ③: 会社情報
│   ├── インデックスモード: General
│   ├── チャンク: 500文字
│   ├── TopK: 3
│   └── 内容: 会社概要、アクセス、営業時間、沿革
│
├── ナレッジ④: キャンペーン・お知らせ（頻繁に更新）
│   ├── インデックスモード: General
│   ├── チャンク: 500文字
│   ├── TopK: 3
│   └── 内容: 期間限定情報、最新ニュース
│
└── ナレッジ⑤: 対応マニュアル（内部向け・オプション）
    ├── インデックスモード: General
    ├── チャンク: 1000文字
    ├── TopK: 6
    └── 内容: 問い合わせ対応手順、エスカレーション基準
```

## 5. 更新・品質管理フロー

{% hint style="info" %} **古い情報は信頼を失う最大の原因である**

「作って終わり」ではなく、ログに基づいた継続的なチューニングが必要です。キャンペーン終了後も古い情報が残っていたり、価格が変わっているのにドキュメントが更新されていないと、ユーザーの信頼を大きく損ないます。 {% endhint %}

1. **変更の反映**
   * ドキュメント修正後、必ず\*\*「再同期（Re-index）」\*\*を実施する。
   * 古い情報（終了したキャンペーン等）は削除する。
2. **実機テスト**
   * 同期後、主要な質問（5〜10件）をテストし、回答内容と\*\*出典（引用チャンク）\*\*が正しいか確認する。
3. **ログモニタリング（週次）**
   * 「回答できなかった質問」や「ユーザーからの低評価」を確認。
   * 不足している情報はナレッジに追加（またはアノテーション登録）する。
4. **アノテーション（固定回答）の活用**
   * 毎回RAG検索させる必要のないあいさつや、絶対に間違えてはいけない回答は、RAGの前段で固定回答として設定し、レスポンス速度を向上させる。

### 更新頻度の目安

| **情報種別**     | **更新頻度**                 | **優先度** | **備考**           |
| ------------ | ------------------------ | ------- | ---------------- |
| **キャンペーン情報** | 開始/終了時に即時                | 🔴 最優先  | 終了したキャンペーンは即座に削除 |
| **価格情報**     | 変更時に即時                   | 🔴 最優先  | 誤った価格案内はクレームに直結  |
| **在庫状況**     | <p>リアルタイム連携<br>または日次</p> | 🔴 最優先  | 可能であればAPI連携で自動更新 |
| **製品情報**     | <p>新製品発売時<br>仕様変更時</p>   | 🟡 高    | 発売前に準備、発売日に公開    |
| **FAQ**      | 月1回見直し                   | 🟡 高    | 問い合わせログから新規質問を追加 |
| **会社情報**     | 変更時                      | 🟢 中    | 営業時間、所在地、代表者など   |
| **季節情報**     | 季節の変わり目                  | 🟢 中    | 夏季/冬季の営業時間など     |

### 運用フロー例

```jsx
【ステップ1】変更内容の確認と計画
  ├─ 何を変更するか明確化
  ├─ 影響範囲の特定（どのドキュメントに影響するか）
  └─ 更新スケジュールの決定
     ↓
【ステップ2】ドキュメントの更新
  ├─ 該当ドキュメントを修正
  ├─ 関連ドキュメントも確認（矛盾がないか）
  └─ 不要になった情報は削除（古いキャンペーン情報など）
     ↓
【ステップ3】テスト実施
  ├─ 想定質問でテスト（5〜10パターン）
  ├─ 回答内容の確認
  ├─ レスポンス速度の確認
  └─ 検索ログで実際の検索結果を確認
     ↓
【ステップ4】本番反映
  ├─ ナレッジベースの更新（ファイル差し替えまたは再同期）
  └─ 本番環境でも簡単な動作確認
     ↓
【ステップ5】事後確認（1週間後）
  ├─ ユーザーフィードバックの確認
  ├─ ログから検索状況を確認
  └─ 必要に応じて微調整
```

## トラブルシューティング

実際の運用で遭遇しやすい問題と解決策をまとめました。

### よくある問題と解決策

| **問題**                       | **原因**                                                | **解決策**                                                            |
| ---------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------ |
| 検索結果が返らない、または「見つかりませんでした」と返す | <p>・スコア閾値が高すぎる<br>・ドキュメントに関連情報がない<br>・表現が不一致である</p>   | <p>・スコア閾値を0.5〜0.6に下げる<br>・想定質問をドキュメントに含める<br>・同義語・言い換えを追加する</p>    |
| 回答が遅い（3秒以上かかる）               | <p>・TopKが大きすぎる<br>・ナレッジが多すぎる<br>・Rerankが有効化されていない</p> | <p>・TopKを3〜5に下げる<br>・不要なナレッジを検索対象から外す<br>・Rerankモデルを有効化する</p>      |
| 間違った情報を返す                    | <p>・古い情報が残っている<br>・複数の矛盾する情報がある<br>・検索精度が低い</p>       | <p>・ドキュメントを更新し同期する<br>・矛盾する情報を削除する<br>・ハイブリッド検索 + Rerankを有効化する</p> |
| 同じような検索結果を複数返す               | <p>・重複したドキュメントがある<br>・チャンクのオーバーラップが大きすぎる</p>          | <p>・重複のドキュメントを削除する<br>・オーバーラップを10〜15%に下げる</p>                      |
| 検索結果に無関係な情報を含む               | <p>・スコア閾値が低すぎる<br>・TopKが大きすぎる</p>                     | <p>・スコア閾値を0.7以上にあげる<br>・TopKを3〜5に下げる</p>                           |

## よくある質問（FAQ）

### Q: インデックスモードは「Economy」でも大丈夫ですか？

**A:** \*\*デジタルヒューマン用途では推奨しません。\*\*Economyモードは検索精度が低下するため、不正確な回答が増えます。**必ず「High-Quality」を使用してください。**

### Q: TopKはいくつが最適ですか？

**A:** **基本は5、速度重視なら3、精度重視なら6**がおすすめです。TopKを大きくすると検索時間が増え、デジタルヒューマンの会話テンポが悪くなります。

### Q: Rerankモデルは必ず使うべきですか？

**A:** 精度を上げたい場合は**推奨します**。Rerankモデルを使うことで、TopKを少なくしても高い精度を維持できます。特に日本語の場合、rerank-multilingual-v3.0が効果的です。ただし、Rerank処理が入ることで処理に時間がかかる場合がありますので、Rerank処理の有無を試して速度や精度を比較してください。

### Q: ドキュメントを更新したのに検索結果が変わりません。

**A:** Difyでは\*\*「チャンク」タブで同期処理を実行する必要があります\*\*。ドキュメントを更新しただけでは検索結果に反映されません。

### Q: 複数のナレッジベースを使うべきですか？

**A:** **推奨します**。情報の種類や更新頻度に応じて分割すると、検索精度と管理効率が向上します。最低でも「FAQ」と「その他」の2つに分けることをおすすめします。

### Q: アノテーション機能とは何ですか？

**A:** **頻出質問に対して固定回答を設定できる機能**です。RAG検索をスキップして即座に回答が返るため、速度・精度・コストすべてが改善します。FAQの上位10件程度をアノテーション登録するのがおすすめです。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.digitalhumans.jp/dify-guide/knowledge-base/dify-docs-optimization-tips-for-digital-humans.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.