> 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.