DeepBI 自架部署前的現實檢查：對話式 BI 的架構、安裝路徑與邊界
LLM based data scientist, AI native data application. AI-driven infinite thinking redefines BI.
秒懂
- 它是什麼？
- DeepBI 把 LLM 接進 BI 流程，讓使用者用對話產生查詢、圖表與儀表板。這篇文章拆解它的資料流、安裝方式（exe、Docker、Ubuntu 三條路），以及 README 沒有說清楚的地方。
- 適合誰用？
- 如果你需要的是讓不寫 SQL 的同事用自然語言問 MySQL 或 PostgreSQL 裡的資料，而且你能接受把資料庫連線交給一個自架服務，DeepBI 的 Docker 路徑值得在測試環境先跑一次。若你的資料必須留在內網且不接受外部模型呼叫，或你只需要固定報表而不需要對話式取數，這個專案不是合適的選擇。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 19 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是取數環節，不是報表排版
傳統 BI 工具把門檻放在建模與 SQL。分析師先寫查詢，再拉圖表，最後排進儀表板。DeepBI 想壓縮的是前半段：使用者用對話描述想看什麼，系統產生查詢與視覺化。README 的措辭是「Generates persistent queries and visualizations through dialogues」，關鍵字是 persistent，代表對話產出的不只是螢幕上的一次性結果，而是可以留下來、組進 dashboard 的查詢物件。
目標使用者因此不是資料工程師，而是有資料庫存取權、但不想每次找分析師排隊的營運或產品角色。支援的資料源涵蓋 MySQL、PostgreSQL、Doris、StarRocks、MongoDB，以及 CSV/Excel 匯入。這個清單偏向 OLTP 與 OLAP 的混合，Doris 與 StarRocks 的出現說明它預設面對有一定資料量的場景，不是只讀 Excel。
要注意 README 把「Automated data analysis reports」標為 to be developed。自動產出完整分析報告這件事還沒做完，你現在拿到的是對話取數與儀表板組裝，不是自動寫報告。
對話到查詢之間發生了什麼
從 README 能確認的架構元素有限，但幾個線索拼得出輪廓。技術棧包含 Python、Redis 與 PostgreSQL：PostgreSQL 負責持久化，Redis 出現在依賴清單裡，合理推測用於對話狀態或任務佇列的快取與排程。LLM 位於對話與資料庫之間，負責把自然語言轉成查詢語句。
這個資料流有一個必須說清楚的性質：自然語言轉 SQL 不是確定性轉換。同一個問題換個問法，可能產生不同的 JOIN 或聚合邏輯，而兩者都「看起來合理」。DeepBI 用 persistent query 的概念讓使用者把結果固定下來，等於承認了首次生成需要人工確認。這是正確的設計取向，但也意味著你不能把產出的查詢當成可信的資料定義，除非有人看過。
前端是獨立的 client 目錄（README 提到 client/app/assets/images 下的使用者手冊），服務預設開在 8338 與 8339 兩個埠，8338 是 Web 入口。兩個埠的分工在 README 沒有交代，部署時若要調整防火牆規則，得自己進去 docker-compose 檔案確認。
三條安裝路徑，成本差很多
最省事的是 Windows exe。從 releases 頁面下載 window_install_exe_EN.zip，解壓後雙擊執行，README 說目前測試支援 Win10 與 Win11。這條路徑適合單機試用，不適合當團隊服務。
Docker 是主要路徑，也是多數人該走的路。前置條件是機器上已有 docker 與 docker-compose，接著 git clone 專案、cd DeepBI、執行 ./Install.sh，預設埠 8338 與 8339，瀏覽器開 http://ip:8338。日常維運用 docker-compose start、stop、ps 三條指令。README 特別提醒，若出現 PermissionError 或 Permission denied，在指令前加 sudo。這個提醒本身透露安裝腳本會碰觸需要提權的檔案或 socket。
Ubuntu 直接安裝最麻煩。你需要先備好 redis、postgresql-16 與 python 3.8.17，Redis 要能用 127.0.0.1 無密碼命令列連上，Python 建議放進 pyenv 或 conda 之類的虛擬環境。安裝指令是 . ubuntu_install.sh，README 強調必須用點號而不是 sh，理由是腳本要靠 source 把 Python 虛擬環境帶進當前 shell。這個細節很容易被忽略，用 sh 執行會失敗在環境變數上。
資源方面，README 寫伺服器最低 1 核 2G，建議 2 核 4G。這是服務本身的門檻，不含 LLM 推論的開銷，因為推論通常走外部 API。
依賴 LLM 供應商是最大的架構賭注
DeepBI 的核心能力建立在大型語言模型上。README 沒有說明模型是本地部署還是呼叫外部 API，也沒有列出支援哪些供應商或需要哪些環境變數。這是評估時最需要向維護者確認的一點，因為它直接決定兩件事：資料會不會離開你的網路，以及每次提問的邊際成本由誰承擔。
若走外部 API，你等於把資料庫的 schema、欄位名稱，甚至部分查詢結果送到第三方。對金融、醫療或任何受監管行業，這通常需要先過一輪合規審查，而不是技術問題。若走本地模型，2 核 4G 的建議規格明顯不夠，你得另外準備 GPU 資源，那已經超出 README 描述的部署範圍。
這裡沒有中間選項可選。README 把 LLM 當成給定的前提，而不是可替換的元件，所以「先裝起來再說」的心態在這個專案上風險偏高。
什麼情況下它會讓你失望
第一種是資料庫不在支援清單內。清單是 MySQL、PostgreSQL、Doris、StarRocks、MongoDB 與 CSV/Excel。你如果用的是 SQL Server、Oracle 或 Snowflake，README 沒有給出任何擴充路徑或插件機制，只能自己讀原始碼改。
第二種是查詢複雜度。對話式生成對「上個月各通路的轉換率」這類描述清楚的問題表現最好；遇到需要多層子查詢、視窗函數或跨庫 JOIN 的需求，生成結果的正確率會下降，而錯誤往往不會拋出異常，只會給出一個語意上說得通但數字不對的答案。這比直接報錯更危險。
第三種是規模。README 對併發使用者數、查詢逾時、結果集大小上限都沒有說明。把一個對話式介面開放給幾十人同時使用，Redis 與 PostgreSQL 的壓力會怎麼變化，只能靠實測。
還有一點：README 的版本節奏可以觀察。最近的 release 是 v2.0.4，時間為 2024 年 10 月，而倉庫最後推送時間是 2026 年 8 月。兩者之間的落差代表這一年多可能有未發版的提交。這不是問題，但意味著如果你想用最新修正，可能得直接跟 main 分支而不是等 tag。
和 Metabase、Superset 的取數路徑差異
拿 Metabase 或 Apache Superset 對比最直接，因為它們同樣是自架、同樣接多種資料庫、同樣有儀表板。差別在取數的入口。Metabase 的問句產生器讓你用圖形介面點選欄位與篩選條件，邏輯是明確的；Superset 更偏向 SQL Lab 加上圖表配置，對會寫 SQL 的人效率很高。兩者的共同點是，最終執行的查詢由人明確決定。
DeepBI 把這個決定權部分交給模型。好處是門檻低，不會 SQL 的人也能問；代價是查詢的正確性需要驗證，而且驗證成本落在看得懂 SQL 的人身上。如果你的團隊裡沒有這種人，對話產出的圖表就沒有可靠的把關機制。
另一個實際差異是部署重量。Metabase 的 jar 或容器相對獨立，Superset 需要較多元件但路徑成熟。DeepBI 需要 Redis 與 PostgreSQL 一起跑，Ubuntu 直裝還綁定 Python 3.8.x 與 postgresql-16，版本約束比前兩者嚴格。
授權、維護與升級的實際成本
授權是 MIT，這是寬鬆授權，允許修改與商用，條款要求保留著作權聲明。需要注意的不是 DeepBI 本身，而是它呼叫的 LLM 服務：那部分有自己的商業條款與資料處理政策，與 MIT 無關。若你打算把 DeepBI 包進對外產品，這兩層授權要分開確認。以上不構成法律意見，正式用途請找法務。
維護成本主要來自三處。一是 Python 版本被鎖在 3.8.x，而 3.8 已進入生命週期尾聲，未來要升級得等上游調整。二是 postgresql-16 是明確要求，不能隨意降版。三是 LLM 供應商的 API 若變動，修補得等專案更新，而 release 節奏看起來不是每月一次。
升級前建議先讀 release notes 再動，並且在測試環境用同一份 docker-compose 跑一次。文件方面，README 指向 client/app/assets/images/en/user_manual_en.md 作為使用者手冊，這是目前最完整的操作說明來源，比 README 本身更能回答「這個按鈕做什麼」這類問題。
編輯結論
如果你需要的是讓不寫 SQL 的同事用自然語言問 MySQL 或 PostgreSQL 裡的資料，而且你能接受把資料庫連線交給一個自架服務，DeepBI 的 Docker 路徑值得在測試環境先跑一次。若你的資料必須留在內網且不接受外部模型呼叫，或你只需要固定報表而不需要對話式取數，這個專案不是合適的選擇。動手前先確認三件事：你打算接的資料庫是否在 README 列出的清單內、伺服器是否達到 2 核 4G、以及你要用哪一家 LLM 供應商與對應的 API 金鑰，因為這三項決定了安裝後能不能真的問出第一張圖。
社群筆記