文件模型

當「文件模組」（DocIQ）讀取一份文件時——履歷、發票、採購單——「文件模型」（document model）會告訴它該擷取什麼內容、填進哪一筆紀錄。取得文件模型有三種方式，而且有嚴格的先後順序。

採用組織的預設模型。 平台內建了一個龐大的模型庫，包括履歷、發票、採購單和到職清單。採用其中一個不需要任何成本，而且日後這個組織上的每個建置，看到的都會是同一組欄位。
只有在真的缺少某個欄位時，才擴充預設模型。 請洽你的 iMBrace 聯絡窗口。把欄位加進預設模型，會讓所有組織都看得到這個欄位，而不是為單一客戶另外複製一份模型。
只有在完全沒有預設模型可用時，才自行撰寫，而且要用平台自己的風格來寫，這樣日後如果平台推出預設模型，才能乾淨俐落地取代它。

不該做的事

把管理文件模型當成一個獨立、刻意的步驟，絕不是建置過程中的附帶結果。 在建置實際執行之外，另外新增或修改文件模型，這樣每個讀取同一種文件類型的建置，指向的都會是同一個模型。
不要把模型的選擇交給運氣。 只要一個步驟固定讀取同一種文件，就明確告訴它該用哪個模型，這樣每份文件都會落在你預期的那個數據表上。

在一項設計真正依賴它之前，先用你自己的幾份文件，逐一檢查以下每一點：

龐大的模型。 有幾十個欄位的模型，拆成幾次、各自聚焦的驗證會比較容易做。不論模型大小，都要拿每次的結果對照欄位清單，確認每個欄位都有被顧到。
巢狀的列。 發票上的品項、履歷中工作經歷裡的每一份工作：在你的測試集中，確認每一個子項目，都會落在與其父項目相連結的數據表上。
本質上是一張表格的文件——像是價目表、對帳單——其實是許多筆紀錄，而不是一筆。要把它當成一列一列來讀取。
看起來不像那個類型的文件。 在測試集裡放進一些不典型的例子——像是沒有職責說明區塊的職缺說明、缺少標準標題的表單——並確認代理人會把無法辨識的文件如實回報為「無法辨識」，而不是回報成功。
組織層級的設定。 「文件模組」的模型設定，是整個組織共用的。把你的建置測試時所用的設定，記錄在測試集旁邊，並在設定變動時重新跑一次整個測試集。
模型在哪裡執行。 哪個模型會讀取你的文件，是依安裝環境與組織分別設定的。如果個人資料必須留在自有機房內，請在第一份真實文件送進去之前，請負責維運該安裝環境的人確認：「文件模組」所用的每一個模型——不論是用於讀取還是搜尋——都是在該安裝環境內部執行的。

模型愈少，愈省成本、也愈準確。 分類時，會把每份文件拿去和組織裡的每一個模型比對，所以每一個沒在用的模型，都會增加成本，也多一個出錯的機會。只保留你真正會用到的模型；只要一個步驟固定讀取同一種文件，就把它指向那份文件的數據表，讓模型固定下來。
任何你會拿來分組或製圖的欄位，都給它一組封閉的詞彙表。 把允許的值列在該欄位的說明裡，這樣分組和製圖，用的就會是一組固定、已知的詞彙。
描述每一種文件類型時，同時說明它是什麼、也說明它不是什麼。 能點名出那些長得很像、但其實不是同一種類型的說明，才是真正能把它們區分開來的關鍵。