知識庫設計指南
針對 Custom GPTs 與 Gemini Gems 的知識庫優化策略。 AI 閱讀文件的方式與人類不同，學會準備「AI 友善」的資料 (LLM Native Data)。
1核心觀念：對 AI 友善的資料
人類喜歡排版精美的 PDF（雙欄、頁首頁尾、圖片），但 AI 喜歡的是結構化、語意清晰、無雜訊的純文字。
通用黃金法則
Markdown > JSON/CSV > TXT > Word > PDF
| 排名 | 格式 | 為什麼排這裡 (AI 的視角) |
|---|---|---|
| 👑 1 | Markdown (.md) | 王者：結構與語意兼具。LLM 的訓練資料大量來自 GitHub 和技術文檔。它能透過 # 理解章節層級，透過 - 理解清單，語意保留最完整。 |
| 🥈 2 | JSON / CSV | 結構化資料密度最高。適合「數據」而非「文章」。對於 Code Interpreter 來說是滿分格式，但對於語意理解 (Semantic Search) 稍弱於 Markdown。 |
| 🥉 3 | TXT (.txt) | 純淨無雜訊，但也無結構。AI 讀起來很順，不會有亂碼。缺點是 AI 不知道哪裡是「標題」、哪裡是「內文」，長文件容易迷失重點。 |
| ⚠️ 4 | Word (.docx) | 普通：含有大量隱藏 XML 標籤。解析器在讀取時，偶爾會把排版資訊誤讀為內容。但比 PDF 好，因為文字流通常是連續的。 |
| ❌ 5 | PDF (.pdf) | 地獄：視覺格式，非數據格式。常見災難：雙欄排版導致文字順序錯亂、跨頁表格碎裂。PDF 是為了「列印」設計的，不是為了「數位讀取」。 |
2格式與檔案類型設計
規章、流程、手冊
最佳格式：Markdown (.md)
Markdown 的標題層級 (#, ##) 能完美對應 AI 的語意分塊。
- 清楚的 H1/H2 層級
- 移除頁碼與頁首雜訊
- 複雜表格轉為 CSV
產品清單、參數表
最佳格式：JSON / CSV
強制 Agent 進行精確查找，而非模糊搜尋。
- JSON：適合巢狀結構
- CSV：適合扁平大量數據
- 搭配 Code Interpreter 使用
程式碼庫、技術文件
最佳格式：合併 TXT / PY
不要上傳 100 個零散的小檔案。
- 合併為單一檔案
- 區塊前加上註解說明
- 保留原始縮排結構
3結構設計與管理
平台限制比較
| 特性 | Custom GPTs (OpenAI) | Gemini Gems (Google) |
|---|---|---|
| 檔案數量 | 20 個檔案 (UI 上傳上限) | 依賴 Google Drive，無硬性限制 |
| 單檔大小 | 512 MB / 2M Tokens | 支援極大 Context (1M/2M tokens) |
| 檢索機制 | RAG 檢索增強生成，只讀取相關片段 | Long Context 傾向將整份文件一次讀完 |
路由與索引法 (Router & Index)
當資料量大時，建立一個「導航地圖檔」 (Master_Index.md) 作為 Agent 的目錄。
# 知識庫索引
如果使用者問關於「請假流程」，請參閱 `HR_Policies.md`。
如果使用者問關於「報帳」，請參閱 `Finance_Guide.md`。
如果使用者要查詢「API 錯誤碼」，請參閱 `Error_Codes.json`。
檔案命名學 (Naming Convention)
AI 會讀取「檔名」來判斷這個檔案是否與使用者的問題相關。檔名就是第一道 Prompt。
未命名-1.pdf, 2024_final_v2.docx
Employee_Leave_Policy_2024.md
Product_Pricing_Q3.csv