VibeBI 如何 運作。

1 · 概覽

VibeBI 是地端企業分析平台，將原始倉儲轉化為受治理的自助 BI 服務。它建立在三個產品介面上，共用合約但職責分離：

• VibeBI Desktop — 進階使用者與管理介面：BI Agent（報表）、DG Agent（資料治理）、Explorer、Store，以及認證與存取畫面。
• VibeBI Web — 輕量、唯讀的消費端介面，用於發現並開啟受治理的報表分享連結。
• VibeBI Server — 無介面的地端控制平面：身分、存取控制、報表庫、排程、稽核、倉儲仲介與 LLM 閘道。

VibeBI 內建專屬 Agent 引擎。Agent 承擔大部分起草；人類資料管家與 IT 保管人經認證閘門核准並執行——他們從不是瓶頸。

2 · 架構

平台將 Agent 執行環境（在使用者筆電上）與控制平面（地端伺服器）分離。倉儲與 LLM 憑證從不到達終端使用者裝置。

flowchart LR
  subgraph client["User laptop"]
    DT["VibeBI Desktop"]
    SC["Agent sidecar :4580
VibeBI agent engine"]
    DT --> SC
  end
  subgraph server["On-prem server :8080"]
    AUTH["Auth / SSO"]
    BRK["Warehouse broker
read-only SQL"]
    GW["LLM gateway"]
    STORE["Report store
Postgres + object store"]
    ACL["Access control"]
  end
  CH[("Warehouse (EDW)
bronze · silver · gold")]
  WEB["VibeBI Web viewer"]
  SC --> AUTH
  SC --> BRK
  SC --> GW
  BRK --> CH
  DT --> STORE
  WEB --> AUTH
  WEB --> STORE
  STORE --> ACL
            

3 · The Alchemist（獎章架構）

VibeBI 的範圍 從銅層開始 — 於擷取之後。資料沿受治理的獎章架構提升：銅層 → 銀層 → 金層＋語義。唯一硬性規則： 金層絕不可直接由銅層建置；須先存在已認證的銀層檢視。

flowchart LR
  B["Bronze
source-shaped landing
source__entity"] --> S["Silver
silver_<domain>
conformed views"]
  S --> G["Gold
gold_<domain>
facts & dims"]
  G --> SEM["Semantics
entities · grain · tags"]
  SEM --> CR["Create / Web
published gold only"]
            

階段 1（銅層 → 銀層）涵蓋剖析、資料品質分析、一致化，以及資料域／機密分級提案。階段 2（銀層 → 金層）涵蓋實體解析、資訊清單與金層檢視起草、驗證與修復迴圈。實體資料庫名稱為部署設定，並非硬編碼於二進位檔。

4 · 語義層

語義層讓報表耐用。VibeBI 不把儀表板綁定實體資料表，而是對外提供 實體、粒度、對應、已認證指標與金層模型中繼資料 經由單一合約。

• 已認證指標 — 經資料管家核准的度量，含運算式、粒度與金層綁定。一個定義，處處重用。
• 業務詞彙表 — 公司／團隊／個人層級詞彙，含定義與別名，注入 Agent 工作階段。
• 欄位標籤 — 每個對外欄位皆帶有 ≥ 1 個資料域與機密分級。

因為報表讀取語義層，上游綱要變更由銀層→金層對應吸收——下游報表無需改寫即可繼續運作。

# Agent discovery contract
GetSemantics      # entities, tables, grains, mappings, certified metrics
QueryVibeBIGold  # read-only SQL against published gold for real answers

5 · 金層 BI 學習（自我成長迴圈）

金層不是一次性發布。VibeBI 會擷取 來自每個 BI Agent 回合的需求訊號 — 使用者問題、即時探測中的稀疏／空值指標、查詢錯誤、關聯缺口，以及助理無法回答的實體——並轉化為經資料管家審核的業務驅動因素、資訊清單與關聯改進。

flowchart LR
  BI["BI Agent turns
chat + gold/silver probes"] --> SIG["Learning signals
catalog backlog"]
  SIG --> PROC["Process backlog
drivers · joins · hints"]
  PROC --> STW["Steward review
Gold → BI Learning tab"]
  STW --> GOLD["Approve drivers
publish manifests · build gold"]
  GOLD --> SEM["Updated semantics
fewer gaps next turn"]
  SEM --> BI
            

資料管家保持掌控。 提案會建立 bi_learning 業務驅動因素於 提議 狀態，直至核准。針對稀疏指標的資訊清單重建會回到 草稿 直至重新發布。資料管家可逐步處理，或執行 完整管線 （處理 → 核准 → 發布 → 建置金層）於桌面完成。

BI Agent 收到精簡的 學習缺口 區段（稀疏度量、未涵蓋實體、待處理驅動因素），以便誠實作答，而非重複探測已知空值欄。DG Agent 在重新產生業務驅動因素時使用同一待辦。

6 · Agent 引擎

VibeBI 運行專為打造的內嵌 Agent 執行環境——不是通用聊天機器人。兩個 Agent 角色驅動產品：

7 · 治理模型

存取控制採用 兩個正交平面，由客戶定義，並在每個欄位、查詢、報表與分享上強制執行。

平面 A — 資料域（業務主題）

由業務擁有的主題領域（營收、供應鏈、人資薪酬），可選子域。每個資料域有一位 負責人 負責核准存取申請——業務課責方，而非技術上建表的人。

平面 B — 敏感度層級

角色（RACI）

• 資料域負責人 — 誰可存取某個資料域；核准存取申請；會簽敏感發布。
• 資料管家 — 資料的意義：定義、粒度、指標、資訊清單核准、DQ 認證，以及 金層 BI 學習 （處理對話訊號 → 核准驅動因素 → 發布金層）。
• 資料保管人（IT） — 管線如何執行：DDL 執行、效能、備份、緊急突破。

8 · 衍生報表存取

這是核心存取規則，且沒有繞過途徑：

報表層級授權（角色、分享連結）僅能 收窄 存取——絕不可超出底層資料權限。由多張銀層資料表構成的金層模型會繼承 聯集 的資料域標籤，因此所有被繼承資料域的負責人都成為核准者。

9 · 部署

100% 地端是我們的優勢 — VibeBI 完全在您的網路內運行，倉儲憑證與模型金鑰從不外流。試點為單機 VM 的 Docker Compose 安裝；正式環境可強化為高可用性叢集，無需重新設計產品。

地端是預設，而非唯一選項。同一架構可部署至 您選擇的雲端——公有、私有、混合或多雲 — 因此您可依資料駐留與營運策略，將控制平面與資料倉儲部署在所需位置。

伺服器刻意 精簡 — 輕量級二進位檔，可在一般硬體上流暢執行。所有代理運算——剖析、語義擷取、模型產生、報表起草——皆於 分散於每位使用者的桌面用戶端，而非伺服器。伺服器只負責治理、仲介與提供服務，即使使用者規模成長，伺服器端資源需求仍保持精簡。

對資料敏感的客戶，VibeBI 支援 完全氣隙隔離部署：100% 地端部署、零網際網路依賴，對接內部 LLM。資料、查詢與中繼資料皆不離開您的網路。整套系統——伺服器、桌面用戶端與 LLM——在防護邊界內以封閉迴路運作。

• 建立類 Agent 在使用者筆電上執行（約 100 位同時建立者）。
• Web 檢視器服務 PC 與行動裝置上的一般消費者（約 500 人同時）。
• 正式環境出貨 編譯產物 — 執行映像不含原始碼，正式環境不含 source map。
• 報表儲存為 .report.ts ＋產生的 HTML，經受 ACL 控管的 API 轉譯。

10 · 安全不變式

每次部署都守住五項不可妥協原則：

1. 倉儲憑證從不存放於用戶端裝置 — 所有金層／語義皆經由伺服器仲介層傳遞。
2. LLM 金鑰從不存放於用戶端裝置 — 僅限伺服器閘道或短期核發的權杖。
3. 分享連結為能力 URL — 不透明識別碼＋SSO／ACL＋短期轉譯權杖，而非靜態 HTML 路徑。
4. 報表存取由資料權限衍生 — 任何獨立的報表權限皆不得繞過資料域＋機密分級授權。
5. 正式環境部署編譯產物 — 無 src/ 於執行映像中。

11 · 技術堆疊