症狀：只按文件數量估算 WeKora 知識庫成本，上線後卻被模型呼叫、索引重建、工具執行和維運費用追上。
最快解法：把官方專案名為 WeKnora 的能力拆成資料處理、索引與儲存、問答模型、Agent 工具呼叫、沙箱執行、維運六類成本；小規模先本地或低並發驗證，增長後再按查詢量、並發及更新頻率擴容。
這篇適合三類讀者：企業知識庫負責人，需要為 RAG 與 Agent 建立可解釋的預算模型；產品工程師，要找出文件上傳、檢索、工具呼叫和自動 Wiki 的資源消耗；獨立開發者，想在上線前估算雲端工作區與長期運行開銷。
先把 WeKora 知識庫成本切成六個預算桶
官方說明中的 WeKnora 並不只是問答介面，功能邊界還包括 RAG、Agent、MCP、沙箱和自動 Wiki。你可以先參考官方中文專案說明核對能力範圍，再把預算分成以下六桶：
- 資料處理：檔案解析、文字清理、切分、嵌入，以及格式不完整或解析失敗後的重試。
- 索引與儲存：向量索引、關鍵字索引、原始文件、版本、備份和回滾保留。
- RAG 問答模型：查詢改寫、檢索、重排、上下文整理、答案生成，以及失敗後重新發問。
- Agent 與 MCP 工具呼叫：多步推理、外部搜尋、API 呼叫、工具回傳內容整理和權限檢查。
- 沙箱執行：程式碼執行所需的隔離環境、啟動等待、執行時間、輸出保存及清理。
- 維運：監控、日誌、告警、備份、升級、權限、網路流量與人工處理異常。
因此，預算模型應寫成：
總成本 = 資料處理 + 索引/儲存 + 問答模型 + Agent/MCP + 沙箱 + 維運
這不是報價公式，而是成本邊界。每一桶都要再以「使用量 × 單位資源消耗」計算；單位價格必須以當期供應商、部署平台或本站資料核實，不能把網路上的示例金額當成 WeKnora 的固定價格。
第一步：把文件匯入分成三種使用場景
首次匯入、增量同步和大批量重建，消耗方式並不相同。
首次匯入通常會連續觸發解析、切分、嵌入和索引建立。文件格式越多，越要檢查圖片、表格、掃描文字和附件是否走不同解析路徑。官方 DocReader 說明列出的環境變數，正好可用來核對解析服務、連線和執行設定，而不是只看 Web 介面是否能上傳。查看官方 DocReader 環境變數說明
增量同步則應記錄新增、修改和刪除的文件數，並確認系統是局部更新還是重新建立整個集合。若每次小幅修改都觸發整批嵌入，文件數不變，處理成本仍會上升。
大批量重建常見於切分規則、嵌入模型或重排策略變更。此時要預留並行索引、暫存空間、舊版本保留和回滾時間；不能只把新文件的數量放進預算。
建議你在匯入記錄中保留這些變數：
- 原始文件量與文件總容量；
- 每種格式的比例及解析失敗數；
- 切分後片段數；
- 每次嵌入與索引更新的批次量；
- 增量同步週期；
- 重建時是否保留舊索引。
注意：文件量只是輸入規模，不等於實際成本。相同數量的短文字文件和含大量表格、圖片的長文件，解析、儲存與模型上下文消耗可能完全不同。
第二步：用查詢路徑估算 RAG 問答
RAG 知識庫的單次問答，至少應拆成四個成本項：
- 檢索：向量搜尋、關鍵字搜尋，或兩者混合。
- 重排：對初步結果再次排序，增加額外計算或模型呼叫。
- 上下文組裝：把片段、來源、歷史對話和系統指令整理成模型輸入。
- 答案生成：計算輸入與輸出內容量，以及可能發生的改寫和重試。
混合檢索不是免費的「開關」；它可能同時維持不同索引路徑，再把結果合併。你可用官方混合搜尋文件確認向量與文字搜尋的處理邏輯，再決定要不要把兩種檢索都納入每次查詢的資源模型。若加入重排，也要把重排階段獨立記錄，官方的混合搜尋重排示例可作為流程核對依據。
可用以下符號建立查詢預算：
Q = 查詢次數 ×（檢索資源 + 重排資源 + 輸入上下文成本 + 輸出成本）+ 重試成本
其中「查詢次數」不應只看使用者按下送出鍵的次數。一次使用者問題可能被 Agent 改寫、分解成多個子查詢，或因沒有找到足夠內容而重新檢索。你至少要分開統計一般查詢、長上下文查詢和失敗重試。
第三步：為 Agent、MCP 和自動 Wiki 加上放大係數
Agent 部署的成本難以用文件量推算，因為它依照任務路徑消耗資源。一次簡單問答可能只做一次檢索；複雜任務則可能搜尋網頁、呼叫多個 MCP 工具、讀取回傳內容，再交給模型規劃下一步。
你可以按三類任務記錄：
- 一般任務：固定工具、單次檢索、沒有程式碼執行。
- 複雜任務：多輪推理、多個工具、較長回傳內容或多次檢索。
- 失敗任務：權限不足、工具逾時、格式錯誤或模型重試。
估算式可以寫成：
Agent 成本 = 任務次數 ×（推理輪次 + 工具呼叫次數 + 檢索次數 + 回傳內容處理）+ 失敗重試
自動 Wiki 也要按生成任務計算，而不是視為一次性功能。當來源文件更新時，Wiki 可能需要重新抽取、整理和生成；若你保留歷史版本，還要加入儲存和回滾成本。
沙箱則另行記錄啟動次數、等待時間、實際執行時間、輸出大小和逾時清理。官方沙箱文件可用來核對隔離能力和設定邊界：查看 WeKnora 沙箱說明。不要把沙箱當成普通 API 呼叫，因為它涉及隔離、權限、資源上限和執行後清理。
第四步：按資料邊界選本地、雲端或混合部署
本地部署適合資料不能離開內部環境、團隊要先驗證 RAG 流程，或查詢量尚未穩定的情況。優點是資料邊界較清楚、可控制網路出口；缺點是硬體、升級、備份、遠端存取和故障排查都由你負責。
雲端常駐適合多人同時使用、需要遠端協作，或產品已經有持續查詢和工具呼叫。優點是可按負載調整資源；缺點是長時間閒置仍可能產生工作區、儲存、流量和監控成本，資料傳輸路徑也要重新審核。
混合部署可把敏感原始文件留在受控環境，把部分推理、前端或非敏感索引放在雲端。它通常能平衡資料邊界與可用性，但連線、憑證、同步延遲和故障切換會增加維運項目。
判斷時可採用以下分支：
- 若資料不能離開內網，先選本地；若又需要外部協作，再評估混合架構。
- 若團隊仍在驗證切分、檢索和權限流程，選本地或低並發環境，避免先承擔常駐雲端開銷。
- 若查詢、Agent 任務和 Wiki 更新已成為日常服務，且高峰並發不穩定，選雲端或混合架構。
- 若需要長時間沙箱執行，先檢查隔離、逾時、日誌和清理能力；不符合條件就回退到受控本地執行。
- 若你無法每週取得文件量、查詢量、失敗率和資源使用記錄，就不要急著承諾固定月度預算。
部署前也應核對官方 Compose 與環境設定，避免自行假設服務依賴；官方 Docker Compose 設定可用作部署清單的對照來源。
第五步：設好預算護欄，再用每週資料修正
上線前先為每個入口設定上限：
- 每位使用者或每個工作區的查詢配額；
- 單次問答的最大上下文長度；
- Agent 可呼叫的工具數量與推理輪次；
- MCP 工具的逾時和錯誤重試次數；
- 沙箱的最長執行時間、輸出大小和並發數；
- 文件重建索引的觸發條件；
- 日誌、備份和舊版本的保留週期。
每週只要記錄四組數據，就能讓模型逐步接近實際：
- 新增、修改、刪除和重建的文件量；
- 一般 RAG 查詢、長上下文查詢和 Agent 任務量；
- 工具失敗、沙箱逾時、模型重試和人工介入次數；
- 索引、儲存、模型、工作區和網路資源的實際使用量。
生產環境檢查還應包括備份、權限、監控和故障恢復；可參考官方生產檢查清單逐項補齊。你可以把每週記錄放進Macstripe 幫助中心所管理的內部作業文件，讓產品、工程和財務使用同一套變數，而不是各自維護一份預算。
常見問題
WeKora（WeKnora）部署前，預算應該先計算哪些項目？
不要只按文件數量估算。你應先分開計算文件解析與嵌入、索引及儲存、RAG 問答模型、Agent 與 MCP 工具呼叫、沙箱執行，以及監控備份和故障處理等維運項目，再按首次匯入、日常增量和重建索引分別建立預算。
WeKnora 的 RAG 知識庫怎樣估算預算才不會失真？
先記錄每個查詢的檢索輪次、送入模型的上下文長度、重排是否啟用，以及高峰並發；再把查詢量乘以單次模型與檢索資源，另外加入文件更新和失敗重試的預留。這比用文件總數乘上一個固定單價更接近實際消耗。
企業知識庫的模型呼叫和向量儲存成本怎樣拆分？
模型呼叫通常跟輸入輸出內容量、推理輪次和重試次數相關；向量儲存則取決於切分後的片段數、嵌入維度、索引副本、備份與保留週期。兩者應分開記錄，因為查詢增加未必同步增加原始文件，而文件重建卻可能同時放大嵌入與索引負載。
WeKnora 適合本地部署，還是應該放到雲端？
本地部署適合資料邊界嚴格、需要先驗證流程且並發較低的團隊，但硬體維護和遠端存取要自行承擔。雲端常駐較適合多人協作、需要彈性擴容或持續提供服務的情況；若資料敏感度高而又需要外部存取，混合架構通常較容易平衡兩者。
