資料中央廚房系統流程與資料表設計

搜尋規則

文章目錄 點擊收合

4) Usecase（用在那邊/用途場景）

5) Targetsystem（要送到哪個系統）

6) Systemlocation（系統指定位置）

7) Uploadfile（上傳檔主檔）

8) Filescan（掃毒/安檢結果）

9) Fileextract（內容抽取結果）

10) Filematch（內容與填寫資訊相符性檢核）

11) Aiconverter（AI 轉換器/處理器）

12) Aijob（AI處理任務）

13) Airesult（AI處理結果）

14) Emailout（Email寄送工作）

15) Systempush（送入後續系統工作）

16) Followtask（後續處理任務）

多對多 Junction Tables（只有這些用底線）

JT1) Uploadfile_Recipient（一個上傳要寄給多個收件人）

17) Recipient（收件人名冊，含外部人）

JT2) Filekind_Aiconverter（某種檔案性質可用哪些 AI 轉換器）

JT3) Usecase_Aiconverter（某種用途場景可用哪些 AI 轉換器）

JT4) Client_Aiconverter（特定客戶專用/特別規則的 AI）

JT5) Targetsystem_Filekind（某系統接受哪些檔案性質）

JT6) Targetsystem_Usecase（某系統服務哪些用途場景）

把（1）~（5）對回資料表

（1）上傳人填寫：客戶、檔案性質、用在哪邊、送給誰、送到哪個系統/位置

（2）掃毒 + 內容抽取 + 與填寫資訊一致性

（3）找到匹配的 AI 處理資料

（4）把處理結果用 Email 送出去

（5）把處理結果送到指定系統指定位置

(6) 我建議您一定要加的兩個「控風險」欄位（很關鍵）

如何加強資料中央廚房風險控管架構?

A. 把「匹配 AI 轉換器」做成可治理的規則引擎，不要寫死在程式

B. 加一層「Quarantine」概念：不是只有掃毒才隔離

C. 「結果送出」要可重送、可追溯、可證明

D. 不要把「抽取文本」全部塞資料庫：建議做索引化策略

E. 必須要有 Auditlog（不可竄改稽核軌跡）

怎麼定位這套系統?

這個架構最容易踩的坑?

這個架構最小可行落地（MVP）方案?

資料中央廚房系統流程

檔案上傳 >> AI Agent >> 操作處理 >> 處理結果>> 送出給系統>>後續處理
檔案上傳時要上傳人填寫：
（1）這是那家客戶要用到這個檔案？檔案是啥性質？是用在那邊？還有其他主要是用來找到可以對照的AI轉換器。同時要說明要去送給誰？可以用電郵送出去結果; 或者可以送到那個系统去使用？
（2）檔案上傳時先確認有沒有病毒？讀取附加檔案的內容,確認是否與上傳檔案之人所填寫內容相符？
（3）找到佩配的AI 處理資料
（4）把處理結果用電郵, 送岀去給上傳檔案之人所指定的人
（5）把處理結果, 送給上傳檔案之人所指定的後續系統所指定的位置, 讓該系統往下處理
檔案上傳人說明:
*檔案屬與哪家客戶+檔案性質+處理作業描述>>為了方便找到整理分類的 AI工具。
*AI處理後給誰？+ 給哪個IT指定地方？>> 為了把AI工具處理好的成果送給正確的人或地方。
我的需求如上, 請幫忙提出系統的個別資料表設計, 以及多對多的junction Tables 之設計
資料表設計原則,用上述（1）~（5）的流程，把「資料中央廚房」做成可落地的資料表設計，並把所有多對多 junction tables列出來（只有 junction table 用底線 _，其餘表名不使用底線）

核心資料表（不使用底線命名）

1) User（內部使用者/上傳者）

用途：誰上傳、誰觸發、誰後續處理
主要欄位

id (uuid, PK)
displayName (varchar)
email (varchar, unique)
userType (varchar) 例如 internal / external（若您未來要做外部入口可用）
status (varchar)
createdAt (timestamptz)

2) Client（客戶）

用途：上傳時要填「哪家客戶要用到這個檔案」
主要欄位

id (uuid, PK)
clientName (varchar)
taxIdOrRegNo (varchar, optional)
country (varchar)
status (varchar)
createdAt (timestamptz)

3) Filekind（檔案性質）

用途：上傳時要填「檔案是啥性質」；用來匹配 AI 轉換器
例：invoice、paymentRequest、vendorStatement、bankSlip、contract、payroll…
主要欄位

id (uuid, PK)
kindName (varchar)
description (text)
status (varchar)

4) Usecase（用在那邊/用途場景）

用途：上傳時要填「用在那邊」；同樣是匹配 AI 轉換器的重要條件
例：AP付款審核、查帳底稿、稅申報、HR 入離職…
主要欄位

id (uuid, PK)
usecaseName (varchar)
description (text)
status (varchar)

5) Targetsystem（要送到哪個系統）

用途：（1）（5）「送到那個系统去使用」「指定的位置」
例：Oracle、SAP、永輝 AIS、SharePoint、SFTP、Email only
主要欄位

id (uuid, PK)
systemName (varchar)
systemType (varchar) 例如 erp / dms / sftp / api
baseEndpoint (varchar)（API base / SFTP host / SharePoint site）
authProfileRef (varchar)（不存明碼，存 reference）
status (varchar)

6) Systemlocation（系統指定位置）

用途：（5）「指定的位置」：API 路徑、SFTP 路徑、資料夾ID、bucket/prefix…
主要欄位

id (uuid, PK)
systemId (uuid, FK → Targetsystem.id)
locationName (varchar) 例如 “Oracle_AP_InvoiceInterface”
locationType (varchar) 例如 apiPath / sftpPath / folderId / bucketPrefix
locationValue (text) 例如 /v1/ap/invoices 或 /inbox/ap/
dataFormat (varchar) 例如 json / xml / csv / zip
enabledFlag (boolean)
createdAt (timestamptz)

一個系統可有多個 location（1對多）

7) Uploadfile（上傳檔主檔）

用途：承接（1）上傳時填的所有欄位 + 指定要寄給誰 + 指定要送哪個系統
主要欄位

id (uuid, PK)
uploaderId (uuid, FK → User.id)
clientId (uuid, FK → Client.id)
filekindId (uuid, FK → Filekind.id)
usecaseId (uuid, FK → Usecase.id)
originalFilename (varchar)
mimeType (varchar)
fileSize (bigint)
storageUri (text)（S3/EFS/Blob/檔案伺服器路徑）
declaredDescription (text)（上傳者填的補充說明）
declaredMeta (jsonb)（上傳者填的結構化欄位：供應商、發票號、日期、金額…）
emailSendFlag (boolean)（是否要寄 Email）
targetSystemId (uuid, FK → Targetsystem.id, nullable)（可只寄信不送系統）
targetLocationId (uuid, FK → Systemlocation.id, nullable)
status (varchar) 例如 uploaded / quarantined / processing / done / failed
createdAt (timestamptz)

8) Filescan（掃毒/安檢結果）

用途：（2）先確認有沒有病毒
主要欄位

id (uuid, PK)
uploadfileId (uuid, FK → Uploadfile.id)
scannerVendor (varchar) 例如 clamav / trendmicro / crowdstrike
scanStatus (varchar) clean / infected / error
threatName (varchar, nullable)
scannedAt (timestamptz)
rawReport (text)

9) Fileextract（內容抽取結果）

用途：（2）讀取附加檔內容（OCR/解析/抽欄位）
主要欄位

id (uuid, PK)
uploadfileId (uuid, FK → Uploadfile.id)
extractMethod (varchar) 例如 ocr / pdfText / excelParse / emailParse
extractedText (text, nullable)（可存摘要或全文索引）
extractedData (jsonb)（抽出的欄位：供應商、金額、日期、invoiceNo…）
confidenceScore (numeric(5,2))
extractedAt (timestamptz)

10) Filematch（內容與填寫資訊相符性檢核）

用途：（2）「確認是否與上傳人填寫內容相符？」
主要欄位

id (uuid, PK)
uploadfileId (uuid, FK → Uploadfile.id)
ruleSet (varchar)（使用哪套比對規則）
matchScore (numeric(5,2))
matchStatus (varchar) pass / warn / fail
mismatchDetail (jsonb)（哪個欄位不一致、差異多少）
checkedAt (timestamptz)

11) Aiconverter（AI 轉換器/處理器）

用途：（3）找到匹配的 AI 處理資料（用 filekind + usecase + 其他條件）
主要欄位

id (uuid, PK)
converterName (varchar)
provider (varchar) 例如 googleDocumentAI / azure / aws / internalLLM
version (varchar)
inputSpec (jsonb)（需要哪些欄位/檔案類型）
outputSpec (jsonb)（輸出格式：json schema / csv schema）
enabledFlag (boolean)
createdAt (timestamptz)

12) Aijob（AI處理任務）

用途：把「某個 Uploadfile」交給「某個 Aiconverter」跑
主要欄位

id (uuid, PK)
uploadfileId (uuid, FK → Uploadfile.id)
aiconverterId (uuid, FK → Aiconverter.id)
jobStatus (varchar) queued / running / done / failed
startedAt (timestamptz)
finishedAt (timestamptz)
errorMessage (text, nullable)
runtimeLog (text, nullable)

13) Airesult（AI處理結果）

用途：（4）（5）輸出結果：寄信、送系統都用它
主要欄位

id (uuid, PK)
aijobId (uuid, FK → Aijob.id)
resultData (jsonb)（結構化結果）
resultFileUri (text, nullable)（若產出 CSV/PDF/ZIP）
summary (text, nullable)
confidenceScore (numeric(5,2))
createdAt (timestamptz)

14) Emailout（Email寄送工作）

用途：（4）把結果用 email 送出去（可多人、多次）
主要欄位

id (uuid, PK)
airesultId (uuid, FK → Airesult.id)
fromAddress (varchar)
subject (varchar)
bodyTemplate (text)
sendStatus (varchar) queued / sent / failed
sentAt (timestamptz, nullable)
providerMsgId (varchar, nullable)
errorMessage (text, nullable)

15) Systempush（送入後續系統工作）

用途：（5）送到指定系統 + 指定 location
主要欄位

id (uuid, PK)
airesultId (uuid, FK → Airesult.id)
systemId (uuid, FK → Targetsystem.id)
locationId (uuid, FK → Systemlocation.id)
payloadFormat (varchar) json/xml/csv
pushStatus (varchar) queued / pushed / failed
responseCode (varchar, nullable)
responseBody (text, nullable)
pushedAt (timestamptz, nullable)

16) Followtask（後續處理任務）

用途：送出後，系統/人員要往下處理（追蹤、簽核、補件…）
主要欄位

id (uuid, PK)
uploadfileId (uuid, FK → Uploadfile.id)
taskType (varchar) approve / review / fixMismatch / reupload
assignedTo (uuid, FK → User.id, nullable)
status (varchar) open / inProgress / done / closed
dueAt (timestamptz, nullable)
notes (text, nullable)
createdAt (timestamptz)

多對多 Junction Tables（只有這些用底線）

這些是您需求中「要能匹配 AI 轉換器」與「要寄給誰 / 送去哪裡」最常見會變成多對多的地方。

JT1) Uploadfile_Recipient（一個上傳要寄給多個收件人）

為什麼是多對多：一個 Uploadfile 可以指定多位收件人；同一個收件人也可能在很多 Uploadfile 出現
欄位

uploadfileId (FK → Uploadfile.id)
recipientId (FK → Recipient.id) ←（Recipient 表見下方）
recipientType (varchar) to/cc/bcc
createdAt (timestamptz)

👉 因此需要 Recipient（不含底線）：

17) Recipient（收件人名冊，含外部人）

id (uuid, PK)
displayName (varchar)
email (varchar)
orgName (varchar, nullable)
status (varchar)

JT2) Filekind_Aiconverter（某種檔案性質可用哪些 AI 轉換器）

用途：匹配（3）
欄位

filekindId (FK → Filekind.id)
aiconverterId (FK → Aiconverter.id)
priority (int)
enabledFlag (boolean)

JT3) Usecase_Aiconverter（某種用途場景可用哪些 AI 轉換器）

用途：匹配（3）
欄位

usecaseId (FK → Usecase.id)
aiconverterId (FK → Aiconverter.id)
priority (int)
enabledFlag (boolean)

JT4) Client_Aiconverter（特定客戶專用/特別規則的 AI）

用途：同一種 invoice，不同客戶格式可能不同（特別是 Oracle 附件/請款單格式）
欄位

clientId (FK → Client.id)
aiconverterId (FK → Aiconverter.id)
priority (int)
enabledFlag (boolean)

JT5) Targetsystem_Filekind（某系統接受哪些檔案性質）

用途：（5）避免送錯系統
欄位

systemId (FK → Targetsystem.id)
filekindId (FK → Filekind.id)
allowedFlag (boolean)

JT6) Targetsystem_Usecase（某系統服務哪些用途場景）

用途：（5）例如 Oracle AP 只吃 AP usecase 的資料
欄位

systemId (FK → Targetsystem.id)
usecaseId (FK → Usecase.id)
allowedFlag (boolean)

把（1）~（5）對回資料表

（1）上傳人填寫：客戶、檔案性質、用在哪邊、送給誰、送到哪個系統/位置

Uploadfile: uploaderId, clientId, filekindId, usecaseId, declaredMeta, emailSendFlag, targetSystemId, targetLocationId
Uploadfile_Recipient: 設定收件人（多個 to/cc）
Recipient: 收件人名冊
Targetsystem + Systemlocation: 系統與位置

（2）掃毒 + 內容抽取 + 與填寫資訊一致性

Filescan: 掃毒結果
Fileextract: 抽文字/抽欄位
Filematch: 與 declaredMeta 比對結果（pass/warn/fail + mismatchDetail）

（3）找到匹配的 AI 處理資料

匹配規則建議順序（我個人建議，實務最好用）：

Client_Aiconverter（客戶專用優先）
Usecase_Aiconverter（用途）
Filekind_Aiconverter（檔案性質）
再用 Filematch 的結果決定要不要進人工/補件

執行用：

Aijob：記錄選到哪個 converter
Aiconverter：轉換器定義

（4）把處理結果用 Email 送出去

Airesult：結果來源
Emailout：寄送記錄
Emailout 可對應多收件人：用 Emailoutrecipient（可選擇要不要做）
- 若您要「同一封 email 多人」又要追蹤每人狀態，可加一張 junction：Emailout_Recipient

（若您要我也可以補上 Emailout_Recipient 的設計）

（5）把處理結果送到指定系統指定位置

Systempush：送出工作 + response 記錄
Targetsystem / Systemlocation：目的地定義

(6) 我建議您一定要加的兩個「控風險」欄位（很關鍵）

Uploadfile.status 的狀態機（至少要有）

uploaded → scanned → extracted → matched → processing → done
任一步 fail 進 quarantined 或 needsReview

Filematch.matchStatus = warn/fail 時

自動建立 Followtask（taskType = fixMismatch / reupload / manualReview）

這能把「上傳者填錯」或「檔案內容與填寫不一致」的風險控住，避免錯送 Oracle、錯寄客戶。

如何加強資料中央廚房風險控管架構?

我會用「實務落地 + 風險控管」角度給您一些比較直白的建議（偏我的主觀判斷），讓這個資料中央廚房真的能跑起來、也能對客戶說得過去。
您的架構方向是對的：核心價值在「可控的自動化」
您現在的流程其實已經具備一個成熟平台的主幹：
上傳 → 安檢 → 抽取 → 比對 → 選轉換器 → 產出 → 通知/推送 → 後續追蹤
我認為這比很多公司一開始就衝「直接丟 LLM 問答」更正確，因為您先把「資料流」跟「責任鏈」建立起來了。
尤其（2）「掃毒 + 相符性比對」這兩個步驟，我個人覺得是這套系統能進企業端的關鍵。
我最建議您補強的 5 個點（按優先順序）

A. 把「匹配 AI 轉換器」做成可治理的規則引擎，不要寫死在程式

您已經有 filekind/usecase/client 的 junction tables，這很好。
下一步我建議：

增加一個 Matchpolicy（表名可叫 matchpolicy）
用來定義「在什麼條件下選哪個 converter」
讓規則可以被調整、版本化、可回溯

原因很現實：同一個客戶格式會改、不同國家文件版型也會改。如果規則寫死在程式，維護成本會爆。

（這是我主觀上最重要的一點。）

B. 加一層「Quarantine」概念：不是只有掃毒才隔離

您現在有 quarantined 狀態，我建議把「隔離」定義得更清楚：
隔離條件不只：infected
還應該包含：

抽取信心分數過低（confidence < 閾值）
比對 fail（例如金額差異超過 2%）
送系統 mapping 缺欄位
系統 push 回覆錯誤（例如 Oracle interface reject）

隔離後一定要：

自動開 followtask（manual review）
可在 UI 一眼看到「為什麼隔離」

這樣您對客戶/內控才能交代：不是 AI 亂送，是有控管閘門（gating）。

C. 「結果送出」要可重送、可追溯、可證明

我非常建議您把 emailout/systempush 當成「外部交付憑證」。
也就是：

每次送出都留存 request/response（至少摘要 + hash）
送出失敗可重送（idempotency key / retry count）
送出成功可追蹤（message id / interface id）

這會直接影響您日後能不能把它賣給大客戶：
大客戶最怕的不是失敗，是失敗了還找不到原因。

D. 不要把「抽取文本」全部塞資料庫：建議做索引化策略

fileextract.extractedtext 如果存全文，資料庫會膨脹很快。

我建議：

DB 只存：摘要、關鍵欄位、全文的 storageUri、hash
全文放 object storage（S3/EFS）
查詢靠全文索引（OpenSearch/Elastic）或向量索引（RAG）

DB 的責任是「交易與稽核」，不是當文件倉庫。

E. 必須要有 Auditlog（不可竄改稽核軌跡）

只要牽涉「付款附件、請款單、供應商資料、送 ERP」，我認為 Auditlog 是必備。

建議做：

auditevent（表名 1–2 字：例如 auditevent）
記錄：誰、何時、對哪個 uploadfile、做了什麼、結果如何、來源 IP、關聯 job id
最低限度要能回答：
- 這份檔案誰上傳？
- AI 用哪個版本處理？
- 何時寄給誰？
- 何時推到哪個系統位置？
- 中間有沒有被重送、修改？

這是您未來拿下「高內控客戶」的門票。