Simba：把評估指標寫進客服 RAG 流程的開源方案
OpenSource Production ready Customer service with built in Evals and monitoring
秒懂
- 它是什麼？
- Simba 是一套以 TypeScript 前端、FastAPI 後端與 Celery 佇列組成的客服助理，主打內建檢索與生成評估。它的價值在於可控與可量測，代價是你得自己扛下整條檢索鏈的維運。
- 適合誰用？
- 如果你已經有向量庫與 LLM 的維運經驗，而且需要把檢索準確率、忠實度、延遲這幾項指標做成可重複跑的流程，Simba 的評估優先設計值得花一個下午用 Docker 起一份來驗證。反過來說，若你只想貼一段 script 標籤就上線、沒有能力處理 Celery worker 與 Redis 的故障排查，這套自架架構會變成負擔，現成的託管客服服務更合適。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 90 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Simba 想解決的是「客服機器人無法量測」這件事
多數團隊導入客服 LLM 的流程是這樣：接上一個向量庫，塞進產品文件，上線，然後靠客訴來判斷好壞。問題在於這種回饋太慢，也太模糊。使用者說「答錯了」，你無法分辨是檢索沒撈到正確段落，還是撈到了但模型沒照著答。
Simba 的定位就是把這個灰色地帶切開。README 的對照表寫得很直白：一邊是「Can't measure AI quality」，另一邊是「Built-in evaluation framework with retrieval and generation metrics」。它把檢索指標（precision、recall、relevance）與生成指標（faithfulness、answer relevancy、latency）列為產品的一等公民，而不是事後補上的外掛。
目標使用者因此很明確：手上有一份會持續更新的知識庫、在意回答品質、而且有能力自己維運服務的工程團隊。文件也提到 conversation analytics 涵蓋 user satisfaction 與 resolution rates，但 README 沒有說明這兩項的資料從何而來，是使用者主動評分、還是模型自行推論，這點需要看原始碼才能確認。
從 npm 元件到 Celery worker 的實際資料流
README 的架構圖把整條鏈畫成五個角色。最左邊是嵌入網站的 npm 套件，請求打到 Simba API（FastAPI），API 再向向量庫查詢，向量庫選項包含 Qdrant 與 FAISS。API 同時呼叫 LLM，可以是 OpenAI，也可以是本地模型。
真正值得注意的是右下角那條線：文件匯入不是同步完成的，而是丟進 Celery，由 Redis 當作任務佇列。這代表上傳一份 PDF 之後，API 會立刻回應，但向量庫要等 worker 處理完才會有資料。對使用者而言，這是一個必須自己處理的狀態問題：如果前端在匯入後馬上發問，很可能檢索不到任何東西，而系統不會告訴你「還在排隊」。README 沒有描述匯入狀態的回報機制。
另一個細節是 DEVICE 環境變數。Docker 指令分成 DEVICE=cpu 與 DEVICE=cuda 兩條路徑，說明官方把本地 GPU 執行當成正式情境之一，而不是附帶功能。這與 LLM 欄位列出的 Local models 互相呼應。
安裝路徑有三條，選錯會多花時間
README 給了 Docker、pip 與 Claude Code 三種起步方式，適用的情境並不相同。
Docker 被標為 Recommended：先 git clone 專案，建立 .env 並填入 OPENAI_API_KEY，然後執行 DEVICE=cpu make build && make up（有 NVIDIA GPU 則換成 DEVICE=cuda）。完成後開 http://localhost:3000 進入 dashboard。這條路徑的好處是 Redis、向量庫等基礎服務一併被 compose 檔拉起，不必逐一套裝。
不想用 Docker 的話，安裝 simba-core 之後執行 simba server 與 simba front 兩個指令。要注意這裡的套件是 Python 發佈的，而專案主要語言標示為 TypeScript，兩者並不衝突：前端與 npm 元件是 TypeScript，後端服務走 Python 生態。
第三條是給 Claude Code 使用者的斜線指令，例如 /setup --all 會安裝 Python、前端與 npm 套件並啟動基礎服務，也可以只跑 /setup --backend、/setup --frontend 或 /setup --services。這條路徑對不熟悉 Claude Code 的人沒有意義，README 也沒有說明它與手動安裝的差異。
網站端整合則是一行 npm install simba-chat-widget，再從套件匯入 SimbaChat 元件，傳入 apiUrl 與 theme 兩個屬性。apiUrl 指向你自己的 Simba 實例，這也再次說明它是自架模型，不是託管服務。
可替換元件清單背後的整合成本
README 的 Customization Options 表列出五個可抽換的環節：向量庫（Qdrant、FAISS、Chroma）、嵌入模型（OpenAI、HuggingFace、Cohere）、LLM（OpenAI、Anthropic、Local models）、重排序器（Cohere、ColBERT、Cross-encoder）、解析器（Docling、Unstructured、PyMuPDF）。
這張表是 Simba 對抗黑箱方案的主要論據，但表格本身只列出名字，沒有說明切換方式是改設定檔、換環境變數，還是得改程式碼。README 從頭到尾沒有出現任何一個具體的 config key 名稱，除了 .env 裡的 OPENAI_API_KEY 與 DEVICE。也就是說，官方文件目前只承諾「可以換」，沒有交代「怎麼換」。
對評估工作來說，這個缺口會直接影響可行性。如果你想比較兩組嵌入模型的檢索表現，得先自己從原始碼找出注入點在哪。反過來說，如果元件真的都走介面注入，那麼同一份評估資料集就能重複跑在不同組合上，這正是 Simba 相對其他客服方案最實質的差異。這個判斷目前只能靠閱讀程式碼來驗證，不能只看 README。
非同步匯入與多租戶缺口是兩個現實邊界
第一個限制來自架構本身。Celery 加 Redis 的組合讓匯入具備吞吐能力，代價是多了一個會壞掉的環節。Redis 掛掉時，API 仍然會接受上傳請求，但任務不會被消化，使用者看到的是「文件上傳成功、問答查不到」。這種失敗模式不會在 HTTP 狀態碼上顯示出來，排查需要直接看 worker 日誌。
第二個限制寫在 Roadmap 裡。Multi-tenant support 是未勾選的項目，代表目前沒有官方的租戶隔離。如果你的情境是一家公司服務多個客戶品牌，共用一份知識庫會讓檢索結果互相污染，而 README 沒有提供任何 workaround，例如以 metadata filter 區分來源。這不是可以靠設定繞過的細節，它會影響你要不要選這個專案。
同樣未完成的是 webhook integrations 與 fine-tuning pipeline。前者意味著 Simba 目前不會主動把對話事件推給你的 CRM 或工單系統，你得自己輪詢。後者則說明它走的是 RAG 路線，不處理模型微調。
另外要提醒的是版本節奏。Release 列表顯示 v0.2.0、v0.3.0、v0.4.0 分別落在 2025 年 3 月 6 日、7 日與 11 日，三天內連發三個版本，而最後一次 push 是 2026 年 6 月 18 日。這代表 v0.4.0 之後仍有大量未發版的變動，README 描述的狀態可能已經落後於 main 分支。
跟直接串 LangChain 或現成客服 SaaS 差在哪
如果你只是想組一條 RAG 問答，LangChain 這類框架能給出更細的積木，但它不會附帶 dashboard、npm 聊天元件，也不會替你定義 retrieval precision 與 faithfulness 該怎麼算。Simba 把這些決策先做掉了：指標名稱固定、評估流程內建、前端元件現成。代價是彈性被壓縮，你得接受它的資料模型與任務佇列設計。
另一條路是託管客服 SaaS。那些服務幫你處理部署、擴容與多租戶，你不用碰 Redis，也不用管 worker 有沒有活著。差別在於你無法替換嵌入模型，也拿不到逐筆的檢索評分去做離線比較。Simba 的 README 把這點寫成 vendor lock-in 的對立面，這個說法在方向上成立，但自架的維運成本並沒有消失，只是從月費轉移到工時。
選擇的關鍵其實是：你需要的是「一組能重複驗證的檢索指標」，還是「一個明天就能上線的客服窗口」。前者選 Simba，後者選託管服務。兩者都想要的話，Simba 的 npm 元件至少讓前端整合這一段不必重寫。
授權與升級要留意的具體事項
專案採用 Apache-2.0，這個授權允許商業使用、修改與再散布，並包含專利授權條款。實際使用前仍應自行確認相依套件的授權是否相容，特別是嵌入模型與重排序器的選擇，因為 Cohere、OpenAI 這類商用 API 有自己的服務條款，與程式碼授權是兩件事。本文不構成法律意見。
升級成本方面，材料顯示的資訊有限。三個早期版本集中在同一週發佈，之後到 2026 年 6 月仍有推送，但沒有對應的 release 說明，因此無法從現有資料判斷 API 是否穩定、設定檔格式是否會變動。實務上，若你要追蹤 main 分支，得自己承擔未發版變更的風險；若只跟 release，則需要接受功能落後。
評估模組本身是另一個升級風險點。如果指標計算邏輯在版本之間改變，你先前累積的分數就無法直接比較。README 沒有提到指標版本或評估結果的儲存格式，這代表跨版本比較基準這件事，目前得由使用團隊自行設計。
編輯結論
如果你已經有向量庫與 LLM 的維運經驗，而且需要把檢索準確率、忠實度、延遲這幾項指標做成可重複跑的流程，Simba 的評估優先設計值得花一個下午用 Docker 起一份來驗證。反過來說，若你只想貼一段 script 標籤就上線、沒有能力處理 Celery worker 與 Redis 的故障排查，這套自架架構會變成負擔，現成的託管客服服務更合適。動手前先確認三件事：docker-compose 內實際會拉起哪些服務、評估指標具體由哪個模組產生、以及 v0.4.0 之後的提交是否已超出 README 描述的範圍。
社群筆記