正式文章・可供搜尋與引用

Methodology · 方法論

大型混雜檔案庫的 AI 分析法

從一座上萬筆、格式雜亂的舊檔案庫,到可閱讀的多面向分析與 Lesson Learn —— 含完整決策紀錄、每個分法的判斷準則與端到端流程圖(去識別化)。

目錄
  1. 五條核心原則
  2. 端到端流程圖
  3. 決策全紀錄(每一次問什麼、使用者答什麼、為何這樣問)
  4. 如何設計「範圍 / 輸出格式 / 目的」三問
  5. 三方案 A / B / C 如何評估
  6. 格式如何分四層(判斷樹+準則)
  7. 如何分群分領域、bundle 是什麼、為何要打包
  8. 各階段做法與當下的思考
  9. 踩過的坑與對策(Debug 紀錄)
  10. 覆蓋率分層思維 · 檢查清單 · 適用與限制
本文把分析「TW_FACTORY 30年資料」的整套方法抽象成可複用流程,並且把過程中每一次與使用者的決策對話、每個「分法」的判斷準則完整攤開——因為真正的方法論不在「LLM 做了什麼」,而在「LLM 在每個岔路口怎麼問、怎麼判、為什麼這樣切」。核心精神:先量測能力、再決定深度;先問清楚、再排方案給使用者 review;用便宜手段拿全貌,把昂貴注意力花在刀口。

一、五條核心原則

① 結構先於內容先把「有什麼、在哪、多大、什麼格式」100% 盤清,分類樹要從資料自己長出來,不要硬套人為框架。
② 先實測,再承諾不臆測工具行不行。用樣本實測抽取速度/成功率,才能給出誠實的覆蓋率與時間估算。
③ 排方案給使用者 review大任務不要悶頭做。把深度/時間/風險拆成幾個方案,讓使用者選了再動工。
④ 工具失敗就換路主流工具在受限環境崩潰時,退一步找更輕量、可控的替代(純 Python 直接解析格式)。
⑤ 分工平行深讀把不同領域切給多個 Agent 各自深讀,換取深度與廣度;主控者只負責備料與彙整。

二、端到端流程圖

P0 釐清 需求釐清 → 排方案 review 範圍 / 格式 / 目的 + 三方案 A/B/C P1 盤點 全檔盤點 → 真實分類樹 os.walk → inventory.csv(15,651) P2 實測 能力實測(樣本測速/成功率) libreoffice/xlrd/pdftotext/tesseract 工具可行? 速度/記憶體/品質 否 → 換工具/降範圍 是 ↓ P3 分層抽取 L1 xls/新格式 全抽 xlrd/openpyxl/pptx 快 · 5,941 檔 ★L2 舊doc/ppt 純Python olefile+UTF-16LE / atom 繞過LibreOffice · 5,080 L3 掃描PDF→OCR tesseract(需語言包) 延後 · 3,668 L4 .rar/圖檔 無工具/沙盒不支援 跳過 · 列盲區 P4 分群 分群打包成 6 個領域 bundle 關鍵字過濾 + 優先排序 + 容量上限 + 去空檔 P5 分析Agent A1 品質體系ISO/管審 A2 FMEA/8D不具合 A3 模切刀模高層主管彙整 A4 標準書配方 A5 設備維修 A6 投資設計CAD P6 彙整 彙整:HTML + Excel + 6 章 .md Pareto / 版本差異 / Lesson Learn / 索引 P6.5 內容產出Agent A7 SEO 文章對外發佈 A8 REEL短影音 A9 短片腳本 A10 專欄文章投稿 P7 檢核 自我檢核 數字一致/無壞值/無殘留格式/段落齊全 P8 交付 交付 + 對外發佈 去識別化內容上網站/社群 ↻ 實測失敗即回此重選工具/範圍

三、決策全紀錄

這是整個專案真正的骨架——LLM 在每個岔路口問了什麼、使用者怎麼回、LLM 為何這樣問、以及它如何改變後續。

第 1 輪範圍 / 格式 / 目的(複選)
Q1 分析範圍(可複選):①模切/刀模(高層主管彙整) ②品管部 ISO/標準書 ③設備/產線投資 ④既有 .md 彙總+全盤盤點 ⑤塑膠射出 ⑥橡膠壓模 ⑦CNC ⑧沖床 ⑨鋁擠型 ⑩彎折 ⑪整平 ⑫水電鍍
使用者選:涵蓋全部主題(不限於單一製程)
Q2 成果格式:①HTML 互動 ②Excel 多分頁 ③兩者都要
使用者選:兩者都要
Q3 目的(Lesson Learn 切入點):①知識傳承 ②品質防再發 ③投資決策 ④全面盤點
使用者選:以上皆是
為何這樣問:範圍選項不是憑空想的,而是 LLM 先快速掃過資料夾後浮現的真實主題叢集(再補上各製程:射出/壓模/CNC/沖床/鋁擠型/彎折/整平/水電鍍等);格式選項對應「瀏覽 vs 篩選」兩種使用情境;目的選項對應三種 Lesson-Learn 透鏡,決定分析時該抓什麼。
第 1.5 輪使用者的關鍵校正(最重要的轉折之一)
使用者說:「不要只分 4 大區塊,這是我工廠 30 年的資料,不要被限制」「精讀既有 .md 只是一小塊」「抽樣精讀可接受嗎?機率多少?」「檔名加『分析_』前綴、不覆蓋,OK」
這逼 LLM 做三件事:①放棄人為四分類,改讓分類樹從資料自己長出;②不能只靠既有摘要,要大規模抽取原始檔;③必須誠實量化覆蓋率。LLM 隨即回覆:結構/分類 100%、Office 內文抽取約 70%、人工深讀 5-10%,並點名最大盲區是掃描 PDF。
掃描 PDF 的補強路徑:掃描 PDF(圖面/報價/規格書)本身沒有文字層,純文字法抽不到內容,因此另以 OCR+語言包(中文 chi_tra/chi_sim、日文 jpn)另案分析——先用英文 OCR 抓得到數字/料號/日期,補上中日文語言包後即可完整辨識中日文掃描頁,再把結果回灌索引與分析。
第 2 輪使用者的重做指令
使用者說:「重作,沙盒記憶不夠就分 AGENT 下去做,這樣做太潦草了,深入去看,先估算時間,排方案給我先 REVIEW」
這句話定義了第二版的全部走向:①承認第一版太淺;②要用 Agent 分工;③先估時間、排方案、讓使用者 review 再動工。LLM 因此先做「能力實測」(測 OCR/libreoffice/xlrd 速度),才有底氣排方案。
第 3 輪三方案 + OCR + RAR
Q1 方案深度:A 精實深做 / B 標準全面 / C 全量窮盡
使用者選:「三個方案先評估給我」(要求更詳細的評估再決定)
Q2 掃描 PDF 中文會亂碼(無網路裝語言包),怎麼處理:①英文 OCR 先抽數值 ②使用者提供語言包 ③跳過 OCR
使用者選:使用者提供語言包
Q3 .rar 解不開怎麼辦:①使用者本機解壓後再讀 ②此次先跳過
使用者選:此次先跳過
為何這樣問:方案題把「深度 × 時間 × 風險」打包成可選項,避免 LLM 替使用者決定;OCR/RAR 是兩個已知盲區,必須讓使用者決定要補到什麼程度。
第 3.5 輪LLM 提交三方案詳細評估(見下節)+ OCR 語言包放置說明
使用者要「先評估」,所以 LLM 把 A/B/C 的覆蓋率、重要文件覆蓋、OCR 頁數、doc/ppt 轉檔量、處理時間、對話輪次消耗、風險、建議全列成表,並標明 LLM 的推薦(B 最平衡、A 最高 CP、C 僅數位典藏才需要)。
第 4 輪使用者的最終定案
使用者說:「跳過 OCR 語言包,先做 A,這禮拜我們再補這一塊」
定案=執行方案 A、OCR 延後。於是 LLM 才正式進入抽取與分析。注意:真正動工是在第 4 輪之後——前面數輪全在「對齊」,這正是不潦草的關鍵。

四、如何設計「範圍 / 輸出格式 / 目的」三問

這三問不是隨便列的,每一問都有設計邏輯:

範圍:選項來自「先掃一遍」的真實叢集

LLM 不會先問範圍,而是先 os.walk 快速看一遍頂層與次層資料夾的檔數分佈,等「真實的大塊」浮現(品管/設備/製程別…),再把這些叢集做成複選選項,並補上各製程(射出/壓模/CNC/沖床/鋁擠型/彎折/整平/水電鍍)。這樣選項才貼合使用者的資料,而不是 LLM 腦中的分類。允許複選,因為大資料庫的價值常跨多塊。

輸出格式:依「使用情境」對應

目的:用 Lesson-Learn 的三個透鏡

目的決定分析時抓什麼。三個透鏡各自會讓 Agent 在讀檔時聚焦不同訊號:

使用者選「以上皆是」,所以每個 Agent 的產出都被要求同時標記三類 Lesson-Learn 標籤,最後可跨域彙整成三切口總綱。

五、三方案 A / B / C 如何評估

方案不是「大中小」隨口分,而是用同一組量化維度把「深度 × 時間 × 風險」攤開,讓使用者能理性選。

維度A 精實深做B 標準全面C 全量窮盡
OCR 範圍~300 高價值 PDF~800 PDF全 3,668
doc/ppt 轉檔~1,000 高價值~2,500全 5,138
Agent 數6 域8 域10 域
內容覆蓋(檔數)~48%~61%~96%
重要文件覆蓋~85%~95%~99%
沙盒處理時間2–3 小時6–8 小時15–20+ 小時
對話輪次消耗很高(需多天)
風險高(工具不穩需大量重試)
適合⭐ CP 最高正式知識庫數位典藏才需要
評估方法本身的要點:①每個方案都建立在 P2 實測數字上(如 OCR 4.6 秒/頁、xls 0.8 分/全量),不是拍腦袋;②用「重要文件覆蓋」而非只看「檔數覆蓋」,因為價值不均勻;③把「對話輪次/時間成本」也算進去,誠實告訴使用者 C 案要跨多天。
實際結果:使用者選 A,並把 OCR 延到本週——這正是方案題的價值:用最小成本拿到高品質成果,盲區留待後補。

六、格式如何分四層(判斷樹+準則)

四層不是按副檔名硬分,而是按三個軸判斷:① 可抽性(需不需要重型工具/OCR)② 成本(每檔幾秒)③ 價值。判斷樹如下。

一個檔,怎麼歸層? 新格式或 .xls?xlsx/pptx/docx/xls 是 → 原生庫 L1 全抽xlrd/openpyxl/pptx 否 ↓ 舊二進位 doc/ppt?能用 olefile 解析? 是 → 純Python ★L2 全抽UTF-16LE / atom 解析 否 ↓ PDF 有文字層?pdftotext 測字數 否(掃描) L3 OCR成本高·按價值決定 有→直抽(L1) pdftotext 直抽少數文字型PDF L4 跳過:rar / 圖檔 / dwg / 3D無工具或沙盒不支援 → 列盲區、誠實標註
判斷準則工具本案結果
L1 全抽新格式或 xls,原生庫可直讀 → 最划算,無腦全做xlrd / openpyxl / python-pptx / python-docx5,941 檔,~3 分鐘
L2 全抽★舊二進位 doc/ppt,重型工具不穩 → 改純 Python 直接解析格式olefile 讀 WordDocument 流 UTF-16LE;ppt 遞迴解析 atom 0x0FA0/0x0FA85,080 檔,分批續跑
L3 延後PDF 無文字層(掃描)→ 需 OCR,成本高,按價值與資源決定tesseract(需中日文語言包)3,668 檔,本案延後
L4 跳過壓縮檔/圖檔/CAD/3D,無工具或環境不支援 → 列盲區rar 需 unrar;dwg/dxf/ai/stp 需專用軟體列入盲區清單
關鍵判斷:「能用輕量工具直接抽嗎?」是第一道閘。能(L1)就無腦全做;不能但能解析二進位(L2)就自己寫解析;要 OCR(L3)才按價值篩;連 OCR 都不適用(L4)就誠實跳過。把昂貴的 OCR 留到最後一層、且只對高價值檔做,是控制成本的核心。

七、如何分群分領域、bundle 是什麼、為何要打包

先講清楚:bundle(語料包)是什麼?
bundle 就是把同一個領域裡所有抽取出來的純文字,依規則挑選、截斷後合併成的「一個檔案」,當作餵給該領域 Agent 的單一輸入。一個領域一個 bundle。簡單比喻:原始資料夾像一座雜亂的大倉庫,bundle 就是 LLM 替每位專家(Agent)事先挑好、整理好、裝訂成冊的一本「該領域精選讀本」——專家不必自己進倉庫翻找,打開讀本就能專心分析。

7-1 領域怎麼切(6 域怎麼來的)

領域不是預設的,是 P1 分類樹的自然叢集再按三條規則收斂:

於是收斂成 6 域:①品質體系(ISO/管審/系統審核)②FMEA·8D·不具合 ③模切刀模 ④生產標準書與配方 ⑤設備資產 ⑥投資方案與設計CAD。方案 B/C 會把 ISO、圖檔/移管再拆出獨立域(8~10 域)——域數=深度旋鈕

內容產出 Agent(A7–A10,對外發佈用):分析完成後,再派四個內容 Agent 把去識別化結論轉成對外素材——A7 SEO 文章(搜尋導流長文)、A8 REEL(社群短影音腳本+分鏡)、A9 短片(YouTube/簡報式影片腳本)、A10 專欄文章(媒體投稿稿)。它們只吃去識別化內容、不碰營業秘密,是「分析 → 對外行銷」的橋樑,產出即可進入網站/社群部署流程。

7-2 bundle 怎麼設置(實際參數)

每個領域把屬於它的抽取文字,依下列規則打包成一個文字檔給 Agent:

  1. 歸域:用檔案相對路徑的關鍵字過濾。例如品質體系=路徑含 /ISO/ 或開頭是 管審/系統審核;模切=含 模切/膜切/刀模
  2. 去雜:跳過 <120 bytes 的近空檔、跳過抽取失敗標記 [EXTRACT-ERROR],提高訊噪比。
  3. 優先排序:大域加一個優先函數——檔名含高價值詞(作業指導書/程序/手冊/管制/対策/報告…)者排前面,其餘按檔案大小(內容多者優先)。
  4. 單檔截斷:每檔最多取 6000 字,避免單一巨檔吃光整包額度。
  5. 整包上限:每個 bundle 約 1.1 MB 封頂,確保 Agent 讀得完、不爆 context。
# bundle 設置的核心邏輯(簡化示意)
sel = [f for f in 全部抽取檔 if 關鍵字命中(f.path) and f.bytes > 120]
sel.sort(key=lambda f: (0 if 高價值詞(f.path) else 1, -f.bytes))  # 優先群在前,再按大小
out, total = [], 0
for f in sel:
    t = read(f)
    if t.startswith("[EXTRACT-ERROR]"): continue
    chunk = f"===== FILE: {f.path} =====\n" + t[:6000]   # 單檔截斷
    if total + len(chunk) > 1_100_000: break              # 整包上限
    out.append(chunk); total += len(chunk)
write(f"bundles/{域名}.txt", "".join(out))

每段都用 ===== FILE: 路徑 ===== 分隔,Agent 因此能在分析時引用真實檔名(六章報告裡的具體檔名與編號,就是這個設計帶來的)。

7-3 為何要先打包 bundle,而不是讓 Agent 自己翻?

理由說明
① 避免互搶資源6 個 Agent 共用同一個沙盒。若各自在上萬檔裡 grep/開檔,會互相拖慢甚至把記憶體吃爆。主控者先備料,Agent 只讀一個檔。
② 聚焦=更深Agent 不必花力氣「找檔」,全部注意力用在「讀懂與分析」,深度自然更高。
③ 控制 context 額度單檔截斷+整包上限,確保內容塞得進 Agent 的視窗、讀得完,不會中途斷掉。
④ 提高訊噪比預先濾掉空檔、錯誤檔、近重複檔,Agent 看到的都是有料的。
⑤ 可重現/可追溯bundle 是固定輸入,同樣的 bundle 餵同樣的 prompt,結果可重跑、可比對。
一句話:主控者的角色是「備料 + 編排 + 彙整」,Agent 的角色是「深讀 + 分析」。bundle 就是這條分工線的交接介面。

八、各階段做法與當下的思考

P1 全檔盤點 → 真實分類樹

os.walk 輸出 inventory.csv,用 Counter 按層級統計,讓分類樹從資料長出。

思考:第一版急著套四大區塊被打回。教訓:分類是「發現」不是「強加」。

P2 能力實測(決定一切的一步)

每種格式抽樣實測速度/成功率/抽到幾字。

思考:沒實測就估時間=騙人。實測立刻揭露 PDF 是掃描、xls 極快、LibreOffice 開機就吃時間——直接決定方案與覆蓋率。

P3 分層抽取(最關鍵轉折)

Pivot:LibreOffice 在沙盒會吃爆記憶體並殘留進程拖垮環境(連續 exit 137)。轉折=直接解析二進位:olefile 讀 .doc 的 WordDocument 流以 UTF-16LE 解碼、遞迴解析 .ppt 的 atom。
成效:抽取量 513 → 11,021 檔(~3% → ~70%),零記憶體風險、可續跑。
配套:單次指令 45 秒上限 → 抽取器寫成「38 秒上限+已完成跳過」可續跑;路徑太長就用 md5 雜湊檔名。

P5 六域 Agent 平行深讀

一次派 6 個 Agent,各讀自己 bundle,產出帶真實檔名/參數/RPN/根因的章節。

思考:Agent 的價值是分攤注意力(不是變出記憶體)——廣度 × 深度同步拉高,主控者保留結論不被細節淹沒。

P6–P8 彙整 → 檢核 → 交付

彙整成 HTML+Excel+md;自檢數字/壞值/格式/段落;交付時誠實標盲區與後續。

思考:可信度來自承認邊界,而非假裝全覆蓋。

九、踩過的坑與對策(Debug 紀錄)

現象根因對策
LibreOffice 連續 exit 137、bash 被殺沙盒記憶體不足+殘留進程;45 秒上限放棄 LibreOffice,改純 Python 解析二進位;殺乾淨殘留
全量抽取跑到一半逾時寫 6,000+ 小檔超過 45 秒抽取器改「38 秒上限+跳過已完成」可續跑
File name too long深層路徑攤平成檔名超過 255 bytes過長者改 md5 雜湊檔名,真實路徑寫進檔頭
PDF 抽到字只有 1-8 個檔案是掃描影像非文字 PDF判定盲區;OCR 走 tesseract(需語言包)
OCR 中文全亂碼沙盒無網路下載中日文語言包英文先抽數值;中日文待使用者提供語言包
第一版被嫌「太潦草」被重型工具卡住就退守抽樣換抽取法+分 Agent 深讀,覆蓋率與深度同補

十、覆蓋率分層 · 檢查清單 · 適用與限制

覆蓋率分層思維(按價值配置,而非齊頭)

可複用檢查清單

適用範圍與限制

適用:大量、格式雜亂、含舊二進位的內部資料庫盤點與知識萃取(知識交接、品質回顧、投資決策、稽核準備)。

限制:① 掃描影像/圖檔需 OCR 或專用軟體;② 純 Python 抽舊格式帶少量雜訊(適分析、不適精排版還原);③ 多 Agent 共用環境,重型作業仍需主控者集中;④ 詞頻統計反映「文件關注度」非絕對數值,須與實際 KPI 交叉驗證。