Querymind 技術架構解析：AI Agent 如何應用在商業分析流程

企業內部通常不缺資料，真正的問題是資料取得成本太高。客服想知道某個客戶最近的訂單狀態，業務想查某一區的成交率，主管想比較本月與上月的營收變化，這些答案大多已經在資料庫裡，但對非技術使用者來說，資料庫不是可以直接使用的工具。

Querymind 的設計方向，是把企業資料庫包裝成一個具備權限控管的 DB Agent。使用者不需要寫 SQL，而是用自然語言提出問題；系統會根據他的角色權限，判斷能查哪些資料、如何查詢、要用表格還是圖表呈現，並在需要時透過分析 Agent 產生進一步的商業洞察。

Querymind 想解決的企業資料痛點

在企業場景裡，資料問題很少只是「查不到」。更多時候是查詢流程過長、資料權限不清、報表無法覆蓋臨時問題，最後讓原本應該快速回答的營運問題變成一張開發需求單。

• 業務、客服、營運人員知道自己想問什麼，但不會 SQL，也不知道資料表在哪裡。
• BI 報表適合固定指標，但臨時追問常常需要工程師重新處理。
• 不同角色能看的資料不同，不能讓所有人直接碰完整資料庫。
• 查到數字之後，使用者仍然需要理解變化原因、異常訊號與下一步行動。
• 主管想要報表，但一線人員更需要即時查詢與可操作的回答。

因此 Querymind 不是單純的 Text-to-SQL 工具，而是一套把自然語言查詢、角色權限、資料語意、查詢驗證、圖表報表與 Insight 分析串起來的 Agent 系統。

傳統需求單開發報表 vs Querymind DB Agent

很多企業資料需求一開始並不是「產品功能」，而只是某個角色想確認一件事。例如客服想知道某類客訴最近是否增加，業務想比較不同區域的成交率，主管想看本月新客戶來源是否改變。這些問題如果用傳統方式處理，通常會變成一張需求單。

面向	傳統需求單 / 報表開發	Querymind DB Agent
問題提出方式	需求單、會議、口頭描述	自然語言提問
查詢邏輯	工程師寫 SQL 或 API	Agent 產生並驗證查詢
權限控管	分散在後端、BI、資料庫或人工流程	查詢前依 RBAC 限制資料表、欄位與資料列
介面需求	常需開發表單、篩選器、圖表	依問題動態產生表格、圖表與報表
適合場景	固定、高頻、正式流程	臨時查詢、探索分析、初步決策

這裡的重點不是說 DB Agent 取代所有報表開發。固定、高頻、需要正式審核的流程仍然適合做成標準介面；Querymind 更適合處理那些還在探索階段、每天都會變、但又確實影響決策的資料問題。

為什麼 DB Agent 不能只是 Text-to-SQL

Text-to-SQL 是 DB Agent 的重要能力，但不是完整答案。把一句自然語言轉成 SQL 只是中間步驟；真正困難的是企業場景裡的安全性、語意對應、查詢驗證與結果解讀。

• 權限先於查詢：Agent 不能先產生 SQL 再想權限，而是要先知道使用者能看哪些資料。
• 資料表不是商業語言：使用者說「成交率」時，系統要知道它對應到哪些欄位與計算邏輯。
• SQL 正確不代表商業正確：查詢可能語法正確，但聚合方式、時間區間或排除條件不符合問題本意。
• Insight 不能假裝成事實：資料庫查詢結果是事實，Agent 的分析是推論，兩者必須分層呈現。

Querymind 的整體技術架構

Querymind 可以理解為一個在企業資料庫前方的 Agent Orchestration Layer。它不只是把使用者問題丟給模型，而是先處理身份、權限、資料語意、查詢邏輯、結果呈現與 Insight 分析。

這樣的架構讓 Querymind 在回答問題前先理解「誰在問」、「他可以看什麼」、「這個問題需要哪些資料」、「應該用哪種形式輸出」。這也是 DB Agent 和一般聊天機器人最大的差別。

RBAC 權限設計：不同角色看到不同資料

企業導入 DB Agent 最容易被忽略的風險，是讓 AI 成為繞過權限的入口。Querymind 的查詢流程應該把 RBAC 放在查詢生成之前，先限制可見資料範圍，再讓 Query Agent 在可用範圍內產生查詢。

RBAC 不只是在 UI 上藏按鈕，而是要深入查詢流程：限制可用資料表、可見欄位、資料列範圍、時間區間，甚至限制可輸出的聚合結果。尤其在客服與業務場景裡，使用者需要快速取得資料，但不能因為方便查詢而暴露不該看的敏感資訊。

自然語言查詢流程：從問題到 SQL、圖表與報表

Querymind 處理一個問題時，不應該直接把原句丟給模型生成 SQL。比較穩定的方式，是把流程拆成多段可檢查任務。

User Question
  -> Authentication / RBAC
  -> Intent Detection
  -> Schema Mapping
  -> Query Planning
  -> SQL or API Query Generation
  -> Query Validation
  -> Database Execution
  -> Result Formatting
  -> Visualization / Report
  -> Insight Analysis

例如使用者問：「幫我看上個月北區新客戶成交率有沒有下降，順便列出可能原因。」這句話其實包含多個子任務：

• 判斷使用者要看的是趨勢比較，而不是單一查詢。
• 確認使用者是否能看北區客戶與成交資料。
• 把「新客戶」、「成交率」、「上個月」、「下降」對應到資料表與計算規則。
• 查出本月、上月或同期資料，產生比較結果。
• 選擇合適圖表，例如折線圖或區域比較長條圖。
• 讓 Insight Agent 分析是否有來源、渠道、業務負責人、產品類別等因素影響。

Agent 分工設計

Querymind 的 Agent 設計重點，不是把流程切得越細越好，而是把容易出錯、需要不同上下文的工作拆開。以下是一個可落地的分工方式。

Agent	負責任務	設計重點
Intent Agent	判斷使用者想查詢、比較、生成圖表、產出報表或取得 Insight。	避免把分析型問題誤判成單純查詢。
Permission Agent	根據 RBAC 限制資料表、欄位、資料列與輸出範圍。	權限要在查詢生成前完成。
Schema Agent	理解資料庫結構與商業語意的對應。	把「成交率」、「回購」、「客訴」轉成明確欄位與計算邏輯。
Query Agent	產生 SQL 或內部 API Query。	只在被允許的 schema 範圍內工作。
Query Validator	檢查查詢安全、聚合合理性與高風險操作。	阻擋越權、全表掃描、危險語句與錯誤聚合。
Visualization Agent	根據資料型態選擇圖表。	時間序列用折線圖，分類比較用長條圖，比例資料才用圓餅圖。
Insight Agent	分析異常、趨勢、分群差異與可能原因。	必須區分資料事實、推論與建議。
Report Agent	把結果組織成摘要、表格、圖表與決策建議。	讓輸出格式穩定，可被複製到週報或主管簡報。

從資料到 Insight：Querymind 如何做商業分析

企業使用者查資料時，通常不只想知道「是多少」，也想知道「為什麼」和「下一步怎麼做」。這就是 Insight Agent 的角色。

但 Insight 不能直接把模型推論包裝成資料庫事實。比較穩定的做法，是把輸出分成三層：

• 資料事實：來自資料庫查詢，例如「北區新客成交率從 18.4% 降到 14.9%」。
• 分析觀察：根據資料比較得到的現象，例如「下降主要集中在廣告來源客戶」。
• 行動建議：根據分析提出的下一步，例如「優先檢查北區廣告素材與客服跟進時間」。

這種分層能降低 AI 誤導風險。使用者可以先看到資料庫查出的事實，再理解 Agent 的分析推論，最後決定是否採納建議。

使用場景：客服、業務與主管怎麼用

Querymind 的價值，在於讓不同角色用自己熟悉的語言取得資料，而不是要求所有人學會資料庫結構。

客服場景

客服可以問：「這位客戶最近三筆訂單處理到哪裡？有沒有重複客訴？」系統根據客服角色，只開放客戶基本資料、訂單狀態與客服紀錄，不暴露成本、毛利或全公司營收。

業務場景

業務可以問：「我負責的客戶裡，最近 30 天有哪些高機率流失？」Querymind 可以查詢互動頻率、訂單下降、客服紀錄與合約狀態，回傳一份可跟進清單。

主管場景

主管可以問：「本月各區成交率和上月相比有什麼變化？請用圖表顯示並列出異常區域。」Querymind 會產生區域比較圖、摘要報告與可能原因。

技術挑戰與設計取捨

DB Agent 看起來像是讓 AI 更方便地查資料，但實作上最重要的是限制，而不是放大能力。

• Agent 數量不是越多越好：每多一個 Agent，都會增加延遲、成本與錯誤傳遞風險。
• 語意層需要長期維護：企業常用指標必須有明確定義，不能每次靠模型猜。
• 查詢驗證不能省略：尤其是跨表 join、聚合、時間區間和權限條件。
• 圖表要有規則：圖表不是裝飾，而是資料理解工具，選錯圖表會誤導判斷。
• Insight 要可追溯：每個結論最好能回到資料來源、查詢條件或比較基準。

我的看法是，企業 DB Agent 的產品化關鍵，不是讓 AI 回答所有問題，而是明確定義哪些問題可以自動回答、哪些問題需要補充條件、哪些問題必須拒答或轉人工確認。

結語：企業 DB Agent 的價值在於安全、可控與可解讀

Querymind 的價值不只是把自然語言轉成 SQL，而是把企業資料查詢與商業分析流程重新整理成一套可控系統。使用者用自然語言提出問題，系統依照 RBAC 限制資料範圍，再透過 Agent 分工完成查詢、圖表、報表與 Insight。

傳統報表開發仍然重要，尤其是固定、高頻、正式營運流程。但在大量臨時查詢、探索分析與初步決策場景中，DB Agent 可以大幅降低資料取得門檻，讓業務、客服、營運與主管更快從資料裡得到答案。

真正有價值的 AI Agent，不是把資料庫變成一個無限制的聊天入口，而是在安全、權限、語意與驗證都被設計好的前提下，讓企業內部的人更有效率地理解資料、產生報表，並把數字轉成可行的商業判斷。