缺乏公司情境的 AI 自動化只會產生通用的輸出。您的 recipe 可以撰寫出色的競爭分析——但它不知道您的產品名稱。它可以草擬事故回應——但它完全不了解您的作業手冊內容。它可以總結客戶回饋——但無法參考您內部的分類體系。
Knowledge base 解決了這個問題。上傳您的文件，JieGou 就會透過 Retrieval-Augmented Generation (RAG) 自動將相關內容注入每個 recipe 和 workflow 執行過程。
文件處理方式
上傳以下任何格式的檔案：PDF、DOCX、CSV、XLSX、TXT、Markdown、HTML。或直接從 URL 匯入。每次上傳的檔案大小上限為 10 MB，解析後的擷取內容上限為 1 MB。
上傳後，文件會經過多階段處理流程：
1. 分塊。 文件採用雙層策略進行分割。首先，系統會掃描 # 和 ## markdown 標題並在這些邊界處分割——這保留了結構良好文件的邏輯架構。對於沒有標題的非結構化文件，系統會退回到基於段落的分割方式。目標分塊大小約為 40,000 個字元（約 10K token），最小為 4,000 個字元，以避免缺乏有用情境的碎片。
2. 摘要生成。 每個分塊都會透過 Claude 取得一個 200-400 字的 LLM 生成摘要。這些摘要有兩個用途：當 embedding 搜尋沒有返回結果時提供備用情境，以及為檢索系統提供每個分塊內容的壓縮表示。
3. Embedding。 每個分塊使用 OpenAI text-embedding-3-small（1536 維度）進行 embedding。Embedding 與分塊內容和中繼資料一起儲存在 Firestore 中——無需外部向量資料庫。
執行時的檢索運作方式
當 recipe 或 workflow 步驟執行時，系統會從您的 knowledge base 建立情境視窗：
- 從使用者的提示或步驟的輸入生成查詢 embedding
- 對相關 knowledge base 中的所有分塊 embedding 執行 cosine 相似度搜尋
- 丟棄低於最小相似度閾值 0.3 的分塊
- Top-k 選擇在 token 預算內挑選最佳匹配——預設為 5 個分塊，最多 8,000 token
- 選定的分塊作為 XML
<reference_documents>區塊注入 LLM 提示中 - 如果沒有 embedding 符合閾值，系統會退回到基於摘要的情境
Embedding 儲存在 Firestore 中，cosine 相似度在應用程式程式碼中計算。沒有外部向量資料庫依賴。這是可行的，因為 token 預算限制了每次查詢的文件數量——您永遠不會搜尋數百萬個向量，只是搜尋您帳戶 knowledge base 中的文件。
三層情境解析
並非每次執行都需要相同的情境。JieGou 從三個來源解析 knowledge base 文件，並自動合併和去重：
| 層級 | 運作方式 | 使用時機 |
|---|---|---|
| 明確文件 ID | 執行時傳遞的特定文件 ID | 當您確切知道哪些文件相關時 |
| Recipe/workflow 附加 | 透過 recipe 或 workflow 上的 knowledgeBaseIds 欄位連結的 knowledge base | 當某些文件應該始終伴隨特定 recipe 時 |
| 自動情境 | 標記為 isAutoContext: true 的 knowledge base，按部門範圍限定 | 當文件應該對部門中的每次執行都可用時 |
自動情境是最強大的層級。將您的公司 wiki、產品文件或品牌指南標記為自動情境，該部門中的每個 recipe 都會在沒有任何手動設定的情況下獲得相關分塊。
回饋驅動的相關性
Knowledge base 會隨著時間變得更智慧。當使用者對執行品質給予按讚或按踩回饋時，系統會調整分塊的相關性分數，用於未來的檢索。
評分使用 Laplace 平滑：score = (ups + 1) / (ups + downs + 2)。這使每個分塊從中性的 0.5 開始，並根據證據進行調整，避免小樣本量產生極端分數。
產生的提升係數範圍從 0.5 倍到 1.5 倍，儲存在 Redis 中，TTL 為 7 天。持續出現在高品質執行中的分塊會被提升。出現在低品質執行中的分塊會被降級。隨著時間推移，最有用的內容會更頻繁地浮現，無需任何手動策展。
知識捕捉：從良好輸出中學習
這是 knowledge base 成為飛輪的地方。當 recipe 執行獲得正面回饋或在 JieGou 的 Quality Guard 中得分良好時，系統會自動從該輸出中捕捉結構化知識。
LLM 會提取：
- 標題——對捕捉的知識的描述性名稱
- 關鍵事實——重要的主張、決策或發現
- 實體——提到的人員、產品、公司和其他專有名詞
- 主題標籤——用於檢索匹配的類別
提取的知識儲存在專用的 「Auto-Captured Knowledge」 base 中，並設定 isAutoContext: true。同一部門的未來執行可以自動檢索此知識。
結果是：您的 AI 系統實際上從自己的良好輸出中學習。今天撰寫良好的競爭分析，會成為明天策略簡報的可檢索情境。
文件新鮮度
從 URL 來源的文件可以設定 refreshIntervalDays 以進行自動重新抓取。當系統重新抓取文件時，它會計算 SHA-256 內容 hash 並與儲存的 hash 進行比較。如果內容未更改，處理就會停止。
如果內容已更改，只會重新處理受影響的分塊——增量生成新的 embedding 和摘要，而不是重新處理整個文件。這使您的 knowledge base 保持最新，而不會在未更改的內容上浪費運算資源。
Write-to-KB workflow 步驟
Workflow 可以使用專用的 Write-to-KB 步驟類型直接將輸出寫入 knowledge base。這使 workflow 能夠隨著時間累積知識。
客戶支援分類 workflow 可能會解決工單，然後將解決方案摘要寫入 knowledge base。下次出現類似工單時，解決方案就可作為 RAG 情境使用。每週市場研究 workflow 可能會將其發現附加到競爭情報 knowledge base 中，該 base 會隨著每次執行而變得更豐富。
範圍和存取控制
Knowledge base 按帳戶範圍限定，並可選擇部門篩選。自動情境 knowledge base 尊重部門邊界——工程部門的內部文件不會洩漏到行銷部門的 recipe 執行中。
此範圍限定在檢索層強制執行。當三層情境解析執行時，自動情境 knowledge base 會在任何 embedding 搜尋發生之前，依執行使用者的部門進行篩選。
可用性
具有 RAG 的 knowledge base 適用於 Pro 方案及以上。自動捕捉的知識和 Write-to-KB workflow 步驟無需額外費用即可使用。了解更多所有功能 或 開始免費試用。