> For the complete documentation index, see [llms.txt](https://docs.maiagent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.maiagent.ai/build/knowledge-base/tags-and-metadata.md).
# 文件管理：標籤及元資料
知識庫文件管理：用標籤分類文件與 FAQ、用元資料控制檢索範圍與參考資料權限，以及與標籤過濾、查詢元資料的關係。
由於知識庫中可能有大量的文件或 FAQ 需要管理，MaiAgent 提供標籤管理、元資料管理功能，讓您能夠分類、整理大量的文件及 FAQ。
## 標籤管理 確定 」
加入後的標籤就會出現在 FAQ 欄位中
非會員 」及「教學 」標籤的文件讓 Agent 使用。
如圖：篩選後 Agent 僅能使用初級露營的文件，避免透露不相關的訊息給非會員對話使用。
包含所有標籤（AND） 」或「包含任一標籤（OR） 」即可切換這一組的判斷方式（下圖為舊版 AND／OR 按鈕，位置相同）；建構器底部會用一句話描述目前的條件，可用來確認設定是否正確。
{% endhint %}
元資料管理 建立 `next_review` 這類日期欄位，並為文件填值（新上傳的文件可用預設值自動帶入）。
2. 複查時用 [批量管理元資料](/build/knowledge-base/km.md#batch-manage-labels-metadata) 下載整個知識庫的元資料 Excel，依該欄位排序或篩選，找出已到期的文件。
3. 對到期的文件更新內容或刪除，再把新的檢核日期填回去上傳。
另一個做法是把「版本狀態」做成標籤（例如 `已審核`、`待複查`），並用 [知識庫標籤過濾](/build/agent/label-filter.md) 讓 Agent 只參考已審核的文件；複查中的文件改掛 `待複查` 標籤，就不會被檢索到。
### 元資料管理頁：欄位、預設值與檢索時使用 元資料管理 」 定義，之後才能在各文件與 FAQ 填值。頁面上方的說明寫明用途：「元資料欄位可以為文件提供額外的結構化資訊，幫助更好地組織和檢索內容。設定全域預設值後，新上傳的文件將自動套用這些預設。」清單欄位：
| 欄位 | 說明 |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 欄位名稱 | 元資料的 key，例如 `url`、`version` |
| 類型 | 預設 ＝系統內建欄位；自定 ＝您用 「新增自定欄位 」 建立的欄位 |
| 欄位描述 | 給管理者看的用途說明 |
| 預設值 | 新上傳的文件自動套用的值；未設定顯示「(無)」 |
| 檢索設定 | 打勾代表已開啟 「檢索時使用 」 |
| 操作 | 編輯 、刪除 （需有知識庫編輯／刪除權限） |
按 「新增自定欄位 」 或 「編輯 」 時要填：
* **欄位名稱**：只能以字母開頭，包含字母、數字和底線，不超過 50 個字元。
* **欄位描述**：選填，不超過 200 個字元，例如「引用文件跳轉連結」。
* **預設值**：選填。畫面提示「設定全域預設值，新上傳的文件將自動套用此預設」；已上傳的文件不會回填，要補值請用[批量管理元資料](/build/knowledge-base/km.md#batch-manage-labels-metadata)。
* **檢索時使用**：開啟後，畫面說明是「檢索時將此資訊送給 LLM 作為回答判斷及參考」——也就是檢索到某個片段時，會把這份文件的這個元資料值一併交給 Agent。適合「文件版本」「適用地區」「生效日期」這類會影響答案的資訊；只用來做[自訂連結映射](#custom-url-mapping)的 `url` 這類欄位不必開，可以省 token。
{% hint style="warning" %}
編輯欄位會影響所有已使用此欄位的文件；刪除欄位後，所有文件中此欄位的資料都會被移除，無法復原。
{% endhint %}
### 為文件新增元資料 新增元資料 」鍵，加入剛剛輸入的鍵值對應關係(可以一次加入多個元資料)。
查看引用節點
查看原始檔案位置
&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
%20(1).png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
.png?alt=media)
