企業導入 AI，第一關不是模型，而是散落在 Excel 裡的資料

六項我們最在意的產品特色

1. Deterministic：理解一次，之後依核定規則處理

第一次遇到一張陌生表格時，AI 可以協助辨識可能的標題列、欄位名稱、日期格式、合計列與資料粒度。它不是直接把猜測當成正式真相，而是先提出一份可供檢查的定義。當使用者確認「每一列代表什麼」「哪一欄才是實際金額」「哪些列不該進分析」之後，系統就把這些判斷保存成正式規則。

下次同一種格式的檔案進來，資料管線依照已核定定義執行，不需要再次消耗模型資源去推測每個欄位的用途。這就是 deterministic 的核心：不把每次清理都當作新對話，而是讓已經通過業務確認的步驟成為可以重複執行的程序。

但 deterministic 並不等於永遠不會出錯。資料來源可能改版，供應商可能把欄位重新命名，甚至同一個系統不同部門匯出的檔案也可能格式不同。固定規則遇到不相容的變動時，正確的作法不是硬把錯誤資料塞進倉儲，而是偵測結構改變、暫停或隔離受影響資料，再請人確認。穩定性來自明確規則與變更管理，不是宣稱「AI 一次學會，以後什麼都不用管」。

2. Replayable：可以重跑，而且不會因為重送就把數字灌大

企業資料匯入幾乎一定會遇到重送。報表寄錯又補寄、同一個檔案上傳兩次、排程中斷後重新執行，或會計月底修正上個月的紀錄，都是日常情境。若系統只把每次收到的內容往資料表後面新增，重跑一次便可能讓營收、訂單數或庫存量憑空增加一倍。

因此，系統需要知道什麼條件能辨識同一筆業務資料。可能是訂單編號加商品明細編號，也可能需要結合門市代碼、交易日期和流水號。這個識別方式應由企業的業務定義決定，不能只以檔名或列號當作永久唯一鍵。當相同紀錄再次出現，系統要能依規則更新既有資料，或把它辨識為重複項目，而不是不加判斷地累加。

可重跑也讓修正有了正規流程。假設我們發現過去把日期讀成文字、折讓欄位漏減，或同一張訂單的商品列被錯誤加總，只要保留原始檔案、處理定義的版本與執行紀錄，就能先修正規則，再重新處理受影響的期間。這使資料結果可以追溯，也讓企業有機會回答「這個數字怎麼來的」「哪個版本的規則產生這份報表」。

要注意的是，重播資料並不是無限保存所有原始檔案的理由。原始資料是否含有個人資料、保留期限如何設定、誰有權重新執行、舊版本是否應刪除或遮罩，都必須納入企業既有的資料政策。重跑能力解決的是技術可恢復性，不會自動替公司完成資料保留與個資管理責任。

3. Reviewable：AI 怎麼理解資料，能讓人檢視和修正

很多資料整理經驗只存在資深同事腦袋裡。大家知道「報表上面那兩列不要」，知道某個欄位雖然寫「狀態」卻代表出貨狀態，也知道兩份清單要用哪組代碼才能對起來。短期看來，問那位同事是最快的辦法；長期看來，這些關鍵知識如果沒有被記錄，就會隨著工作交接、組織調整或人員離開而消失。

Reviewable 的意思，是把 AI 對資料的理解攤開來檢查：欄位如何命名、欄位型別是什麼、每一列代表訂單還是訂單品項、哪些欄位可以加總、哪些資料應該排除、不同來源如何連接。業務人員能補充領域知識，資料人員可以核對技術設定，管理者則能確認指標定義是否符合經營口徑。這不是為了增加簽核，而是要把原本只靠口耳相傳的資料規則，變成組織可以共同維護的資產。

可檢視也應該包含變更紀錄。當某個欄位定義從「銷售額」改成「已扣除退款的淨銷售額」，企業要能知道是誰在什麼時候調整了規則，受影響的儀表板有哪些，舊報表是否仍採用舊口徑。資料定義不是一次建好就永遠不變，它會跟著商業流程、產品型態和法規要求演進；可追蹤的版本管理，可以避免同一個名稱在不同部門各自代表不同數字。

4. Validatable：資料先通過檢查，再往分析和 AI 問答流動

自動化不應該只是讓錯誤跑得更快。資料欄位不存在、日期格式不符合預期、商品代碼找不到對應商品、訂單總額與明細加總差距太大，這些問題都應該在資料進入分析層之前被指出來。

我們把驗證想成一道品質閘門。基本檢查可以確認欄位是否存在、型別是否正確、必要欄位有沒有空值、主鍵是否重複。接著再加上業務規則，例如交易日期不能晚於匯入日期太多、折扣不能大於原始金額、已取消訂單不應列入有效營收，或每家門市每週都必須有資料。對財務或庫存資料而言，與原始 ERP 匯總數字做對帳也很重要，否則看起來格式正確的檔案，仍可能在某個轉換步驟中漏掉一整批資料。

驗證結果不必只有「通過」或「失敗」兩種。若錯誤涉及高風險欄位，例如交易金額或個人識別資訊，系統可以先隔離資料並請人確認；若只是非關鍵備註多了新格式，也可以先標記警示並繼續處理其他欄位。把警示等級與業務影響分開，才能避免不是完全停工，就是忽略所有異常的兩難。

人工智慧科技基金會在 2025 年台灣產業 AI 化調查中，透過專家訪談談到資料標準、資料品質與應用場景必須一起考量。資料不只是被保存下來就算治理完成，還要知道它是否能支援實際決策、是否有負責人、能不能在資料改變時被發現並修正。6

5. Evolvable：新來源進來，既有資料可以逐步長出新關聯

企業不需要等到所有部門都完成資料盤點，才開始第一個分析專案。一開始只有銷售明細，就先回答「最近哪些商品賣得最好」；後來加入庫存表，可以看到「哪些商品銷售增加，庫存卻逐漸不足」；再接上客戶或會員資料，才有機會理解「不同客群購買什麼商品、回購時間多久」。資料模型可以依照真實需求逐步擴張，而不是一開案就要求一次收齊整個企業所有來源。

然而，新增資料也不是把兩張表用看起來相似的文字欄位直接接在一起。商品名稱可能有縮寫、空格或新舊品名；不同系統的客戶編號也可能各自獨立。關聯建立時，要確認雙方的識別鍵是否穩定、資料是否一對多或多對多、歷史紀錄是否需要保留，以及未匹配的項目要如何處理。若把「台北門市」和「台北店」錯誤視為兩家店，或把兩家同名客戶合併，後續 AI 解讀再流暢也救不了資料模型的錯誤。

讓模型可演進的另一個好處，是企業可以把每次新增來源當成擴大資料價值的機會。過去只有月營收時，管理者只能看結果；加上促銷活動與庫存變化後，就能比較活動前後的庫存週轉和銷售差異；若再納入客服反映，還能追查熱賣品的退貨原因。資料之間的關聯逐步增加，舊資料也可能因新脈絡而回答更多問題。

6. Query-ready：清洗資料時，也把業務語意一併留下

清除空白、統一日期、修正錯字，只是資料整理的一部分。若資料進倉後還是不知道「商品」「訂單」「客戶」各指什麼，不知道哪個欄位是正式營收，也不清楚兩張表該如何連接，那麼 AI 問答每次仍得重新猜一次，甚至可能在看起來合理的答案裡犯下不容易察覺的錯誤。

因此，我們希望在資料清理階段，一起建立最基本的語意層（semantic layer）。語意層會把資料欄位轉換成企業真正使用的概念：一筆銷售的粒度是什麼、淨營收如何計算、退款應該如何扣除、產品分類採用哪個代碼、日期以交易日還是出貨日為準，以及不同資料集的關聯如何建立。這樣做的目的，是讓 BI 工具或 AI 查詢時有一套明確的業務語境，不用看到欄名後便自行推測。

同一個指標在不同情境下也可能有不同版本。財務部門可能以發票認列的營收為準，營運團隊可能以已出貨訂單觀察銷售，行銷部門則想看扣除取消訂單後的活動轉換。這些口徑不一定要強行統一成一個答案；更務實的作法，是把每個指標的名稱、計算方式、適用場景和負責人說清楚，並在使用者提問時讓系統知道該套用哪一種口徑。

當資料粒度、關聯和指標計算方式被明確描述，AI 的工作就不只是把中文問題翻譯成資料庫查詢。它也能根據語意層辨認問題中提到的是哪種銷售額、哪個期間、哪個商品維度，以及哪些資料不應被混加。當然，語意層仍需要業務負責人核定；它不是一個能從欄位名稱自動推導所有商業邏輯的魔法模組。