> 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/zhong-wen-fan-ti/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

一次問答用普通對話；需要多步研究、比較同文件交付時綁定 Agent。上線前逐條核對來源。
{% endstep %}
{% endstepper %}

## 用戶案例一：員工制度問答

### 目標

讓員工查詢差旅審批、住宿標準同報銷例外，並且可以打開來源核對原文。

### 資料組織

* 知識庫：【員工差旅制度】
* 條目：【出差審批流程】
* 條目：【住宿標準速查】
* 條目：【差旅常見問題】

<figure><img src="/files/605329854681bd110f8a7a74d7e588d92af4cf74" alt="由多条制度资料组成并全部就绪的员工差旅制度知识库"><figcaption><p>制度條款同 FAQ 分開維護，更新其中一份時唔使重做全部資料。</p></figcaption></figure>

### 推薦配置

| 項目   | 起點         | 幾時調整               |
| ---- | ---------- | ------------------ |
| 檢索   | 先用 BM25    | 員工問法同制度措辭差異大時增加嵌入  |
| 重排   | 先唔使用       | 正確候選已經出現但順序唔穩定時啟用  |
| 資料版本 | 只保留當前版     | 歷史審計需要並存時喺名稱入面寫明年份 |
| 回答要求 | 結論、條件、來源分開 | 資料未說明時明確標記         |

### 驗收問題

1. 出差住店最高可以報幾多？
2. 海外租車可唔可以報銷？
3. 預計總費用超過 5000 元時由邊個審批？
4. 未經批准先訂酒店會點樣處理？

### 對話提示詞

> 只根據「員工差旅制度」回答。先給結論，再列適用條件同來源；資料冇說明時寫「制度未說明」，唔好用常識補全。

{% hint style="success" %}
驗收通過時，同一條制度用原文問法同口語問法都可以命中，回答入面嘅金額、角色同條件可以由引用直接支持。
{% endhint %}

## 用戶案例二：產品售後助手

### 目標

將官方手冊、故障碼同已審核案例組織埋一齊，等客服先可以俾出安全、可追溯嘅排查建議。

### 資料邊界

| 知識庫或資料組 | 內容            | 維護原則           |
| ------- | ------------- | -------------- |
| 官方手冊    | 規格、保養邊界、標準步驟  | 保留型號同文檔版本      |
| 故障碼     | 一條故障一個小節      | 標註適用韌體同設備型號    |
| 審核案例    | 已確認原因同解決方案嘅案例 | 未審核聊天記錄唔可以直接匯入 |

唔同型號規則差異明顯時，按型號拆成獨立知識庫，避免相同故障碼互相競爭。

### 檢索同 Agent 配置

* PDF 先抽查目錄、表格同雙欄內文。
* 故障碼依賴精確術語，保留 BM25。
* 客戶描述較口語化時增加嵌入模型。
* 畀售後 Agent 綁定官方手冊同審核案例，只啟用【知識庫搜索】。

> 根據設備型號、故障碼同現象分三步排查。每一步標明依據來自官方手冊定係審核案例。涉及拆機、用電或者數據清除時，先提示風險並等待確認。

### 驗收標準

* 唔好將其他型號嘅步驟用喺而家呢個型號。
* 安全警告出現在操作步驟之前。
* 官方規則同案例建議分開。
* 無資料支持時轉人工，唔好估。

## 用戶案例三：研究資料與報告

### 目標

從論文、訪談筆記同網頁快照入面抽取可核對證據，再由 Agent 生成帶來源嘅比較報告。

### 資料組織

* 按研究問題建庫，唔好將所有論文塞入一個大庫。
* 檔名包含作者、年份同短標題。
* 訪談筆記標明受訪者角色、日期同係咪可引用。
* 網頁資料記錄擷取日期，因為知識庫保存嘅係匯入快照。

<figure><img src="/files/9d0be85164e1eb156f3b81e5f34c3a0a52ff0cf5" alt="从提出真实问题、检查召回、定位问题到只调整一项并重新索引复测的知识库质量闭环图"><figcaption><p>研究庫先用固定問題驗證來源覆蓋，再交畀 Agent 做跨文檔歸納。</p></figcaption></figure>

### Agent 提示詞

> 喺已綁定研究知識庫入面搵「用戶點解放棄首次配置」嘅證據。先按來源列出原始觀點同限制，再歸納共識、分歧同待驗證假設。最終生成 Markdown 報告；唔可以將推斷寫成受訪者原話。

### 從證據到交付物

<figure><img src="/files/5c4d83ac5f80d2a79e4a5a73e75262fa5ec45c82" alt="资料来源经过知识库召回和 Agent 整理后形成文字文件或多语言图片的内容工作流图"><figcaption><p>先保留證據同限制，再畀 Agent 整理成報告；唔好畀成品反過來掩蓋原始來源。</p></figcaption></figure>

### 驗收標準

* 共識由至少兩個獨立來源支持。
* 分歧保留各自條件，唔好硬合併。
* 引用、推斷同建議有明確標識。
* 網頁快照同論文版本可追溯。

## 配置說明：可重用設計表

| 項目   | 要回答嘅問題                  |
| ---- | ----------------------- |
| 目標   | 用戶最終要做出乜嘢判斷或者交付乜嘢結果？    |
| 邊界   | 邊啲資料應該一齊檢索，邊啲一定要分開？     |
| 來源   | 文件、筆記、目錄同網頁點樣更新？        |
| 解析   | 邊類文檔最容易出現 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="/pages/c4ff2dccd8d41a479c48fa660dff084b09b128c0">/pages/c4ff2dccd8d41a479c48fa660dff084b09b128c0</a></td></tr><tr><td><strong>同 Agent 一齊使用</strong></td><td>配置多步研究同資料權限。</td><td><a href="/pages/8f1bf24557618a64833de8c8bb2d72f034b39940">/pages/8f1bf24557618a64833de8c8bb2d72f034b39940</a></td></tr><tr><td><strong>常見問題</strong></td><td>從症狀定位資料、召回或者回答問題。</td><td><a href="/pages/63b1e545034e96e6aba4adcc4b63d4be0c910334">/pages/63b1e545034e96e6aba4adcc4b63d4be0c910334</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/zhong-wen-fan-ti/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.