案例01｜從 1,000 份測試文件到 200 萬份真實檔案

一、案例定位

本案例依原書第 4 章 TechNova 文件處理情境重組。

用原書的 1,000 份測試文件與 200 萬份真實文件，理解 POC 成功後進入企業規模時，資料量、向量資料庫、API Rate Limit、安全與前處理瓶頸如何同時出現。

二、學習目標

計算測試集與真實檔案規模差距。
辨識規模化不只是增加伺服器。
理解 POC 元件在 Production 可能需要重新評估。

三、案例情境

TechNova 的文件處理 POC 在 1,000 份文件測試集上運作良好；法律部門實際檔案卻有 200 萬份，而且這只是最近 3 年，未來希望處理完整 20 年檔案。POC 使用 ChromaDB 作為向量儲存，但到了這個規模，團隊開始面對 Vector Database Scalability、API Rate Limits、Security Requirements 與 Data Preprocessing Bottlenecks。

四、開始資料

項目	原書數字／內容	意義
POC 測試文件	1,000 份	Demo 規模
法律部門實際檔案	2,000,000 份	Production 初始需求
實際檔案涵蓋期間	最近 3 年	尚非完整歷史
最終希望涵蓋	20 年	未提供 20 年總文件數
POC Vector Store	ChromaDB	POC 可用，不代表企業規模仍適合

五、Excel／AI 分析方法

Excel：=2000000/1000 計算初始實際規模相對 POC 的倍率。AI 可依已知瓶頸分類架構風險，但不得以 3 年線性外推 20 年總文件數，因原書未說明每年文件量相同。

六、計算結果

2,000,000 / 1,000 = 2,000。
也就是目前已知 Production 檔案量至少是 POC 測試集的 2,000 倍。
原書只說 200 萬份是最近 3 年，不能可靠推算 20 年總量。

七、結果分析與管理解讀

POC 的核心功能成功，不代表原架構可直接承受 2,000 倍資料量。真正的 Production Engineering 必須重新檢查向量儲存、API 配額、資料處理、安全、監控與成本。