> For the complete documentation index, see [llms.txt](https://docs.cherryai.com.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cherryai.com.cn/docs/jp/knowledge-base/cases.md).

# ナレッジベース活用事例

ナレッジベースの信頼性は、資料の量ではなく、境界が明確か、ソースを継続的に保守できるか、そして実際の課題で正しい証拠を安定して検索できるかで決まる。

{% hint style="info" %}
以下のパラメータは出発点にすぎない。まずは代表的な資料3～10件で、取り込み・検索・利用を通して動作確認し、その後で固定の質問セットに基づいて拡充する。
{% endhint %}

## まずは同じ方法で設計する

{% stepper %}
{% step %}

### 1. 最終タスクを明確に書く

ユーザーが下す判断や提出物を明確にする。たとえば、制度の確認、障害の切り分け、研究レポートの作成など。
{% endstep %}

{% step %}

### 2. 資料の境界を定める

利用時に一緒に検索すべき資料だけを同じナレッジベースに入れる。権限、ライフサイクル、製品型番、バージョンが異なる内容は優先して分ける。
{% endstep %}

{% step %}

### 3. ソースと更新方法を選ぶ

文書、ノート、目録、ウェブページを誰が保守するか、いつ差し替えるか、履歴版を残す必要があるかを明記する。
{% endstep %}

{% step %}

### 4. 検収用の質問を準備する

3～10個の実際の質問を用意し、正確な事実、条件ルール、口語的な聞き方、混同しやすいバージョンを網羅する。
{% endstep %}

{% step %}

### 5. 検索方式を調整する

まずはシンプルな設定を残す。BM25だけでは同義表現に対応しきれない場合に埋め込みを追加し、候補は正しいが順序が安定しない場合に再ランキングを追加する。
{% endstep %}

{% step %}

### 6. 対話またはAgentに接続する

1問1答なら通常の対話を使う。複数ステップの調査、比較、ファイル出力が必要な場合はAgentを連携する。公開前にソースを1件ずつ確認する。
{% endstep %}
{% endstepper %}

## ユーザー事例1：社員制度Q\&A

### 目的

社員が出張承認、宿泊基準、精算例外を確認でき、ソースを開いて原文を照合できるようにする。

### 資料の整理

* ナレッジベース：【社員出張規程】
* 項目：【出張承認フロー】
* 項目：【宿泊基準早見表】
* 項目：【出張に関するよくある質問】

<figure><img src="/files/33438f8060e398ac476e2ef4640044bcd0903fa7" alt="由多条制度资料组成并全部就绪的员工差旅制度知识库"><figcaption><p>規程条項とFAQは分けて保守し、どちらか一方を更新しても全資料を作り直す必要はない。</p></figcaption></figure>

### 推奨設定

| 項目      | 起点            | いつ調整するか                            |
| ------- | ------------- | ---------------------------------- |
| 検索      | まずBM25を使う     | 社員の質問の言い回しと規程の表現に差が大きい場合は埋め込みを追加する |
| 再ランキング  | ひとまず使用しない     | 正しい候補は出ているが順序が不安定なときに有効化する         |
| 資料バージョン | 現行版のみ保持する     | 履歴監査のために併存が必要な場合は、名称に年度を明記する       |
| 回答要件    | 結論、条件、ソースを分ける | 資料に記載がない場合は明確に示す                   |

### 検収問題

1. 出張時の宿泊費は最大いくらまで精算できますか？
2. 海外でのレンタカーは精算できますか？
3. 予想総費用が5000元を超える場合、誰が承認しますか？
4. 承認前にホテルを予約した場合、どう処理されますか？

### 対話プロンプト

> 「社員出張規程」のみを根拠に回答してください。まず結論を述べ、次に適用条件とソースを列挙してください。資料に記載がない場合は「規程に記載なし」と書き、常識で補完しないでください。

{% hint style="success" %}
検収合格の条件は、同一規程について原文の言い回しでも口語表現でもヒットし、回答内の金額・役割・条件が引用で直接裏付けられること。
{% endhint %}

## ユーザー事例2：製品アフターサポートアシスタント

### 目的

公式マニュアル、故障コード、審査済み事例を整理し、まずは安全で追跡可能な切り分け提案を出せるようにする。

### 資料の境界

| ナレッジベースまたは資料グループ | 内容             | 保守原則                |
| ---------------- | -------------- | ------------------- |
| 公式マニュアル          | 仕様、保証範囲、標準手順   | 型番と文書版を保持する         |
| 故障コード            | 1つの故障につき1セクション | 適用ファームウェアと機器型番を明記する |
| 審査済み事例           | 原因と解決策が確認済みの事例 | 未審査のチャット記録は直接取り込まない |

型番ごとのルール差が大きい場合は、型番別に独立したナレッジベースに分け、同じ故障コード同士が競合しないようにする。

### 検索とAgent設定

* PDFはまず目次、表、二段組本文を抜き出して確認する。
* 故障コードは正確な用語に依存するため、BM25を残す。
* 顧客の説明が口語的な場合は埋め込みモデルを追加する。
* アフターサポートAgentには公式マニュアルと審査済み事例を紐づけ、【ナレッジベース検索】のみ有効化する。

> 機器型番、故障コード、症状に基づいて3段階で切り分ける。各手順では、根拠が公式マニュアルか審査済み事例かを明記する。分解、通電、データ消去が関わる場合は、先にリスクを提示して確認を待つ。

### 検収基準

* 他の型番の手順を現在の型番に流用しない。
* 安全警告は操作手順の前に出す。
* 公式ルールと事例の提案は分ける。
* 資料で裏付けられない場合は人手に引き継ぎ、推測しない。

## ユーザー事例3：研究資料とレポート

### 目的

論文、インタビューノート、ウェブスナップショットから検証可能な証拠を抽出し、その後Agentにより出典付きの比較レポートを生成する。

### 資料の整理

* 研究課題ごとにナレッジベースを構築し、すべての論文を1つの巨大な庫に詰め込まない。
* ファイル名には著者、年、短いタイトルを含める。
* インタビューノートには、回答者の役割、日付、引用可否を明記する。
* ウェブ資料には取得日を記録する。ナレッジベースに保存されるのは取り込み時のスナップショットだからである。

<figure><img src="/files/89938946bde77a08fd907ff8c4b20ae279466e34" alt="从提出真实问题、检查召回、定位问题到只调整一项并重新索引复测的知识库质量闭环图"><figcaption><p>研究用ナレッジベースは、まず固定質問でソースの網羅性を確認し、その後Agentに跨文書の要約・統合を任せる。</p></figcaption></figure>

### Agentプロンプト

> 連携済みの研究ナレッジベースで「ユーザーが初回設定をやめた理由」の証拠を探してください。まずソースごとに元の見解と制約を列挙し、その後で共通点、相違点、検証待ちの仮説を整理してください。最終的にMarkdownレポートを生成し、推論を回答者の発言として書かないでください。

### 証拠から成果物へ

<figure><img src="/files/a9831b5e1ac059716bc332e5bdcfa05b3a5133e0" alt="资料来源经过知识库召回和 Agent 整理后形成文字文件或多语言图片的内容工作流图"><figcaption><p>まず証拠と制約を保持し、その後Agentにレポートとして整えさせる。完成物が逆に元のソースを覆い隠さないようにする。</p></figcaption></figure>

### 検収基準

* 共通認識は少なくとも2つの独立したソースで裏付けられる。
* 相違点はそれぞれの条件を残し、無理に統合しない。
* 引用、推論、提案は明確に区別する。
* ウェブスナップショットと論文版は追跡可能である。

## 設定ガイド：再利用可能な設計表

| 項目     | 回答すべき質問                              |
| ------ | ------------------------------------ |
| 目的     | ユーザーは最終的にどんな判断を下すか、またはどんな成果物を提出するのか？ |
| 境界     | どの資料を一緒に検索し、どの資料を分けるべきか？             |
| 出典     | ファイル、ノート、目録、ウェブページはどのように更新するか？       |
| 解析     | どの種類の文書でOCR、表、順序の問題が最も起こりやすいか？       |
| 検索     | BM25で十分か？ いつ埋め込みと再ランキングが必要か？         |
| 検収問題   | どの3～10個の質問が実際の利用を代表するか？              |
| 失敗時の処理 | 結果なし、版の競合、資料で裏付けられない場合はどうするか？        |
| 保守     | 誰が資料の差し替え、再インデックス化、バックアップを担当するか？     |

{% hint style="warning" %}
「たくさんの資料を取り込んだ」ことを完成基準にしない。資料が多いほど、重複版、権限の混在、ノイズの競合を明示的に管理する必要がある。
{% endhint %}

## よくある質問

<details>

<summary>規程、マニュアル、事例は同じナレッジベースに入れるべきか？</summary>

同じ質問で一緒に検索すべきか、権限と更新周期が一致しているかを確認する。差が大きい場合は分けた方がソース境界を管理しやすい。

</details>

<details>

<summary>事例庫にすべてのカスタマーチャットを直接取り込めますか？</summary>

推奨しない。まず原因、解決策、プライバシー内容を審査し、確認済みで再利用可能な事例だけを取り込む。

</details>

<details>

<summary>資料を拡充する前に何をする必要があるか？</summary>

固定の検収質問を1セット保持し、段階的に取り込んで再テストする。新規資料で結果が悪化したときに、どのバッチの内容が原因かを素早く特定できる。

</details>

## 続きを読む

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>知識ベース入門</strong></td><td>まず作成、取り込み、検索、利用を通す。</td><td><a href="/pages/9c817051b7c18956fa49b6caeec807ee7a1dec3b">/pages/9c817051b7c18956fa49b6caeec807ee7a1dec3b</a></td></tr><tr><td><strong>Agentと一緒に使う</strong></td><td>複数ステップの調査と資料権限を設定する。</td><td><a href="/pages/d3f1c70efc1da7234e403cca359ee86cb1751643">/pages/d3f1c70efc1da7234e403cca359ee86cb1751643</a></td></tr><tr><td><strong>よくある質問</strong></td><td>症状から、資料、検索、回答のどこに問題があるかを特定する。</td><td><a href="/pages/dc2f754740c26e611ee580046af16b3119732b27">/pages/dc2f754740c26e611ee580046af16b3119732b27</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.cherryai.com.cn/docs/jp/knowledge-base/cases.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.