> 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. ソースと更新方法を選ぶ

ドキュメント、メモ、ディレクトリ、Webページを誰が保守するのか、いつ差し替えるのか、履歴版を保持する必要があるかを明記します。
{% endstep %}

{% step %}

### 4. 受け入れ確認用の質問を準備する

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

{% step %}

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

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

{% step %}

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

1問1答なら通常の対話を使い、多段階の調査、比較、ファイル納品が必要なときはAgentをバインドします。公開前にソースを1件ずつ確認します。
{% endstep %}
{% endstepper %}

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

### 目的

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

### 資料の構成

* 知識ベース：【社員出張制度】
* 項目：【出張承認フロー】
* 項目：【宿泊基準クイックリファレンス】
* 項目：【出張FAQ】

<figure><img src="https://3776196818-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0Ut5BptC3t8CtSU1UWpM%2Fuploads%2FoYCk8ddQNgaZxNQ65As2%2Fclipboard.png?alt=media&amp;token=6a24e9c5-3456-492b-bf99-fc7cd426cf30" 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：研究資料とレポート

### 目的

論文、インタビュー記録、Webスナップショットから照合可能な証拠を抽出し、その後Agentがソース付きの比較レポートを生成します。

### 資料の構成

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

<figure><img src="https://3776196818-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0Ut5BptC3t8CtSU1UWpM%2Fuploads%2FmfHDAsphgab351BnEKkY%2Fclipboard.png?alt=media&amp;token=0fc8847f-23e0-4d93-8938-26e818df4b8f" alt="从提出真实问题、检查召回、定位问题到只调整一项并重新索引复测的知识库质量闭环图"><figcaption><p>研究ベースはまず固定の質問でソースの網羅性を検証し、その後にAgentへ渡して文書横断の要約を行わせる。</p></figcaption></figure>

### Agent用プロンプト

> バインド済みの研究知識ベースで「ユーザーが初回設定をやめた理由」の証拠を探します。まずソースごとに生の意見と制約を列挙し、その後で共通点、相違点、検証待ちの仮説を要約します。最終的にMarkdownレポートを生成してください。推論を回答者の原文として書いてはいけません。

### 証拠から成果物へ

<figure><img src="https://3776196818-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0Ut5BptC3t8CtSU1UWpM%2Fuploads%2FuAux5cNPlWeEphenKT5f%2Fclipboard.png?alt=media&amp;token=4875b86d-943e-4aea-85db-9085048edafe" alt="资料来源经过知识库召回和 Agent 整理后形成文字文件或多语言图片的内容工作流图"><figcaption><p>まず証拠と制約を残し、その後でAgentにレポートへ整理させる。完成品が元のソースを覆い隠さないようにする。</p></figcaption></figure>

### 受け入れ基準

* 少なくとも2つの独立したソースに支持されたものを共通認識とする。
* 相違点は各自の条件を残し、無理に統合しない。
* 引用、推論、提案を明確に区別する。
* Webスナップショットと論文バージョンは追跡可能である。

## 設定説明：再利用可能な設計表

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

{% hint style="warning" %}
「大量の資料を取り込んだ」ことを完了基準にしてはいけません。資料が増えるほど、重複版、権限の混在、ノイズの競合を明示的に管理する必要があります。
{% endhint %}

## よくある質問

<details>

<summary>規定、マニュアル、事例は同じ知識ベースに入れるべきですか？</summary>

同じ質問の中で一緒に検索すべきか、権限と更新周期が一致しているかで判断します。差が大きければ、ベースを分けたほうがソース境界を管理しやすくなります。

</details>

<details>

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

推奨しません。まず原因、解決策、個人情報を審査し、確認済みで再利用可能な事例だけを取り込みます。

</details>

<details>

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

固定の受け入れ確認質問セットを保持し、段階的に取り込んで再テストします。追加資料によって結果が劣化した場合、どのバッチの内容が原因かをすばやく特定できます。

</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="/docs/jp/knowledge-base/knowledge-base.md">ナレッジベース入門</a></td></tr><tr><td><strong>Agentと併用する</strong></td><td>多段階の調査と資料権限を設定する。</td><td><a href="/docs/jp/knowledge-base/agent.md">Agent と一緒に使う</a></td></tr><tr><td><strong>よくある質問</strong></td><td>症状から資料、検索、または回答の問題を特定する。</td><td><a href="/docs/jp/knowledge-base/troubleshooting.md">よくある質問</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.