前言 #
這篇文章用於紀錄過去的做的專案，以免被我自己遺忘
摘要 #
本專案提出 L-chunk 系統，一個針對我國司法判決書之自適應結構分析與格式轉換工具。該系統採用三層混合檢測機制（嚴格規則、軟規則與 BERT 分類器），並透過自適應學習演算法自動推斷判決書之層級結構。實驗結果顯示，本系統在 1,102 筆台北地方法院刑事判決中達到 F1-score 0.9947 之檢測準確率，可有效處理不同法官之寫作風格差異，並將判決文本轉換為結構化 Markdown 格式，為後續法律科技應用奠定基礎。
一、專案背景與動機 #
1.1 專案背景 #
司法判決書作為法律體系之核心資料，蘊含豐富之法律資訊與邏輯結構，對法律科技發展具有關鍵性基礎作用。隨著數位化時代來臨，如何有效解析與利用大量判決文本，已成為法律科技領域之重要專案課題。然而，我國司法判決書存在編碼標準不一、結構標記缺失以及寫作風格不一等問題，使得自動化結構分析面臨諸多挑戰。
1.2 專案目的 #
本專案旨在建置一套具高度自適應性的判決結構分析系統，核心目標涵蓋多個層面。首先，針對判決書中長期存在的字元編碼問題，特別是 Private Use Area（PUA）字元所造成的資料不一致性，本專案將提出完整的識別與處理機制。其次，系統將具備自動檢測判決書層級結構的能力，使內容中的段落、子項與論述層級能被清楚辨識。此外，為因應不同法官在編號、標點與排版上的寫作差異，系統將採用可適應多樣風格的架構，以確保結構化標記的準確性。專案亦將實現判決書自動轉換為 Markdown 格式的功能，提升文本可讀性與後續加工效率。最終，透過提供乾淨、穩定且結構化的資料，本專案將為法律文本探勘與人工智慧應用奠定堅實基礎。
二、問題分析 #
2.1 判決書字元編碼問題 #
2.1.1 歷史脈絡 #
我國司法院自民國 86 年起採用大方廣資訊股份有限公司開發之「漢書」系統作為文書處理工具。根據文獻資料，截至民國 108 年，約有 1,600 萬筆判決書與 1,730 萬筆筆錄係由該系統製作完成[1]。然而，該系統在字元編碼支援上存在時代落差：儘管 Unicode 3.0 於 1999 年發布[3]，漢書系統遲至民國 108 年之漢書11始全面支援 Unicode 編碼，造成大量歷史文件採用 Big5 編碼。
2.1.2 編碼轉換挑戰 #
Big5 編碼在處理特殊字元時存在固有限制，首先是字元涵蓋範圍不足，對於罕見字、異體字或法院常用的特殊編號，Big5 字集中往往缺乏對應的編碼。為了補足這些缺漏，系統通常會採用「造字」機制，利用 Private Use Area（PUA）來映射特殊字元。然而，由於 PUA 字元缺乏統一的標準定義，會造成不同系統之間無法正確顯示或交換資料，形成跨系統相容性的問題。此外，造字編碼本身具有不連續與不一致的特性，進一步提高資料解析與維護的難度，並帶來資料完整性的風險。
2.1.3 對大型語言模型之影響 #
在資料驅動的人工智慧時代，字元編碼問題會直接影響模型的訓練與推論品質。由於 PUA 字元缺乏統一的語義定義，模型在建構詞嵌入（word embedding）時無法正確理解其含義，進而降低向量表示的品質。此外，不同系統之間的編碼不一致，使得資料預處理變得更加複雜，需要額外手段來比對、轉換或修正資料。更嚴重的是，模型可能將具有相同語義但採用不同編碼的字元視為完全不同的特徵，造成語料碎片化，降低模型的泛化能力並影響整體效能。
2.2 判決書結構化問題 #
2.2.1 排版格式限制 #
司法院判決查詢系統中的判決書以固定寬度的純文字方式排版，透過空白字元與換行字元來模擬視覺結構，而非使用 HTML 或 XML 等結構化標記語言。這種做法導致多項限制：首先，因缺乏響應式排版能力，頁面在縮放時無法適應不同的視窗大小，使用者體驗受限。其次，由於文稿內沒有明確的語義標記，系統無法直接識別標題、段落、列表等邏輯結構，使內容解析難度增加。再者，純文字格式欠缺結構化資訊，導致自動化處理與資訊擷取需要額外的推斷與轉換步驟，大幅提升技術複雜度。
2.3 法官寫作風格差異 #
在法律文書寫作中，「分點分項」原則旨在強化論述的清晰度與層次，但在實務上，不同法官對此原則的運用方式常有明顯差異。以編號方式為例，有些採用「一、二、三」等中文數字並搭配頓號，有些則偏好「1、2、3」的阿拉伯數字，亦有人使用「(一)(二)(三)」或「①②③」等符號，不同形式在後綴符號與視覺呈現上皆有所不同。除了編號方式本身，寫作風格的多樣性亦體現在層級符號的選擇、標點用法以及縮排習慣上，例如同一份判決可能同時混合多種編號格式，或不同法官對頓號、冒號、句號的使用皆有獨特偏好；縮排的空白字元數量與使用時機也會因人而異。這些差異造成自動化處理上的困難：以規則式方法需窮盡大量模式，正則表達式容易出現過度匹配或不足匹配，而固定模板更難以應對跨法官的風格變異，使得建立穩定可靠的文本解析系統更具挑戰性。
三、專案資料與範圍 #
3.1 資料來源 #
本專案採用司法院資料開放平台[4]提供之判決書資料集，具體選取標準如下：
- 時間範圍：2025 年 1 月
- 法院別：臺北地方法院
- 案件類型：刑事案件
- 篩選條件：使用
JFULL欄位前 15-20 字元進行模式比對，篩選出判決文件。
3.2 資料集 #
3.2.1 資料開放平台格式分析 #
本專案針對司法院資料開放平台提供之判決書，每筆判決皆 JSON 格式儲存[4]，包含以下欄位：
| 欄位名稱 | 說明 | 資料特性 |
|---|---|---|
| JID | 案件編號 | 結構化資料 |
| JYEAR | 年份 | 結構化資料 |
| JCASE | 字號 | 結構化資料 |
| JNO | 案號 | 結構化資料 |
| JDATE | 日期 | 結構化資料 |
| JTITLE | 案由 | 結構化資料 |
| JFULL | 全文 | 非結構化文本 |
| JPDF | PDF 連結 | 結構化資料 |
經過篩選後，本專案資料集包含 1,102 筆判決書，所有文件均具備完整之 JFULL 欄位內容。
3.2.2 分析標的 #
本專案主要針對 JFULL 欄位進行分析，該欄位包含判決書之完整文本，涵蓋：
- 案件標頭資訊（法院、案號、案由等）
- 主文
- 事實
- 理由
- 法官署名與日期
- 書記官署名與日期
- 附註事項（法條、附件、附表等）
此純文字格式為本專案欲處理之主要對象。
四、專案方法 #
本專案提出 L-chunk 系統，採用「先學習後應用」(learn-then-apply) 之自適應策略，將純文字判決書轉換為具結構化標記之格式。系統架構分為三大模組：文件結構分析、層級符號檢測與自適應規則學習。
4.1 系統架構概述 #
L-chunk 系統採用分層檢測的策略，結合規則式方法與深度學習模型，以逐步方式解析判決書的整體結構。流程首先從輸入的 JSON 格式判決書開始，經由文件結構分析模組（Judgment Splitter）辨識標頭、主文、事實、理由等主要區塊，並決定後續模型的最佳學習區間，如 S-D、R-D 或全文。接著，系統進入三層混合式層級檢測（Hybrid Level Symbol Detector），透過嚴格規則、軟規則與 BERT 分類器三種層級處理，從最具確定性的編號模式開始，再由較具彈性的規則補強，最後由深度學習模型處理模糊或非典型的情況。之後，自適應規則學習模組會依據既定的學習區間推斷層級邏輯，並將這些推論結果套用到整篇判決書，使解析結果能因應不同法官或文稿風格自動調整。最終，系統將輸出結構化的 Markdown 或 JSON 格式，使判決內容更易於呈現、儲存與後續分析。
輸入判決書 (JSON)
↓
[模組 1] 文件結構分析 (Judgment Splitter)
├─ 識別標頭、主文、事實、理由等區塊
└─ 確定學習區間 (S-D / R-D / 全文)
↓
[模組 2] 三層混合層級檢測 (Hybrid Level Symbol Detector)
├─ 層級 1: 嚴格規則 (Ultra-Strict Rules)
├─ 層級 2: 軟規則 (Soft Rules)
└─ 層級 3: BERT 分類器
↓
[模組 3] 自適應規則學習 (Adaptive Rule Learning)
├─ 從學習區間推斷層級邏輯
└─ 應用至全文
↓
輸出結構化 Markdown / JSON
4.2 模組一：文件結構分析 #
4.2.1 判決書結構模型 #
基於對大量判決書之觀察，本專案建立標準判決書結構模型，包含以下元素：
| 結構元素 | 代號 | 說明 | 出現頻率 |
|---|---|---|---|
| 標頭 | H | 法院、案號、案由等資訊 | 必要 |
| 主文 | M | 判決結論 | 必要 |
| 事實 | F | 案件事實陳述 | 常見 |
| 理由 | R | 判決理由論述 | 常見 |
| 事實及理由 | S | 事實與理由合併（簡易判決） | 常見 |
| 法官日期 | D1 | 法官署名與日期 | 必要 |
| 署名區 | SIG | 法官簽名區 | 必要 |
| 書記官日期 | D2 | 書記官署名與日期 | 必要 |
| 附註 | A | 法條、附件、附表等 | 選用 |
4.2.2 區塊切分演算法 #
系統採用正則表達式與關鍵字比對，依序識別各結構元素：
-
日期區塊識別：使用民國紀年格式正則表達式
pattern = r'中\s*華\s*民\s*國\s*(\d{1,3})\s*年' -
章節標題識別：比對「主文」、「事實」、「理由」等關鍵詞
4.2.3 學習區間確定策略 #
為適應不同判決書風格，系統採用以下優先順序選擇學習區間：
| 優先級 | 學習區間 | 範圍 | 選擇條件 |
|---|---|---|---|
| 1 | S-D | 事實及理由至文末 | 存在「事實及理由」章節 |
| 2 | R-D | 理由至文末 | 存在「理由」章節 |
| 3 | 全文 | 整份文件 | 無上述章節時之備案 |
選擇理由：事實與理由章節包含最豐富之層級結構，最適合作為規則學習樣本。
4.3 模組二：三層混合層級檢測 #
本系統採用「分層過濾」(layered filtering) 原則，透過三層檢測機制逐步提升精確度。
4.3.1 層級一：嚴格規則 (UltraStrictDetector) #
設計理念：針對最明確之層級符號，採用零容錯規則，主要針對篩選 PUA 字元與頓號組合。
檢測標準：
$$ \text{Strict Match} = \text{[換行符]} + \text{[單一符號]} + \text{[頓號]} $$具體而言，符合以下格式之行被視為層級符號：
- 前置條件：
\r\n(換行符) - 核心符號：單一字元（數字、中文數字或 PUA 字元）
- 後置條件：
、(頓號)
PUA 字元處理：
系統內建 PUA 符號字典，涵蓋司法院造字對應之 Unicode Private Use Area 字元（部分）：
| PUA 範圍 | 符號類型 |
|---|---|
| 0xF6BB-0xF6C4 | 半形阿拉伯數字帶括弧 |
| 0xF4FB-0xF4FF | 半形阿拉伯數字括弧 |
| 0xF4EA-0xF4EB | 半形阿拉伯數字括弧 |
檢測流程：
- 利用文件本身的結構，逐行掃描文本
- 檢查是否符合
\r\n + PUA 單字元 + 頓號格式 - 若符合，標記為層級符號
- 記錄符號類別與行號
優點：
- 零誤判率（針對符合條件之樣本）
- 處理速度快
- 可識別 PUA 字元
4.3.2 層級二：軟規則 (Soft Rules) #
適用場景：處理不完全符合嚴格規則之層級符號
只要句子開頭為常見層級符號模式，即視為潛在層級符號：
實作細節：
soft_rules = [
r'^\s*[一二三四五六七八九十]',
r'^\s*\d',
r'^\s*\([一二三四五六七八九十]\)',
r'^\s*[⑴⑵⑶⑷⑸⑹⑺⑻⑼⑽]'
]
4.3.3 層級三：BERT 分類器 #
在大規模處理判決書時，我們必須在運算速度與判斷準確度之間取得平衡。因此，本研究選擇以微調後的 BERT 模型作為最後一道防線，用以捕捉前兩層規則無法涵蓋的模糊或非典型層級符號。
在模型設計上，基礎模型採用 bert-base-chinese，並以二元分類任務判斷輸入行是否為層級符號。模型輸入為最大長度 128 tokens 的單行文本，輸出則為經 Sigmoid 轉換後的機率值，以估計該行屬於層級符號的可能性。為建立訓練資料，我們使用 Label Studio 進行人工標註，收集正樣本（層級符號行）與負樣本（非層級符號行）共 1,055 筆，並依 8:2 比例分割為訓練與驗證資料。
模型架構：
- 基礎模型：
bert-base-chinese - 任務類型：二元分類（層級符號 / 非層級符號）
- 輸入格式：單行文本
訓練資料：
透過 Label Studio 人工標註建立訓練集，包含：
- 正樣本：層級符號行
- 負樣本：非層級符號行
訓練集規模與分布：
- 標記樣本行數：1,055
- 正負樣本比例：371:684
- 訓練/驗證集分割：8:2
微調策略：
- 學習率：$2 \times 10^{-5}$ (預設)
- 批次大小：8
- 訓練輪數：3 epochs
- Warmup 步數：100 steps
- 權重衰減：0.01
- 評估策略：每個 epoch 結束後評估
- 儲存策略：保存最佳模型（基於驗證損失）
4.3.4 三層整合策略 #
系統將依「嚴格規則 → 軟規則 ＋ BERT」的順序進行判定；若某行符合嚴格規則便直接視為層級符號，若不符合則檢查是否符合軟規則，而對於無法由前兩層確定的情形，最後交由 BERT 模型進行判斷，使整體檢測流程更具彈性與可靠性。
4.4 模組三：自適應規則學習 #
4.4.1 學習目標 #
自適應規則學習模組的核心目標在於從學習區間內的層級符號中，自動推斷該判決書所採用的層級邏輯。具體而言，系統需完成三項任務：首先，進行符號類別識別，區分不同編號系統（例如中文數字、阿拉伯數字、括號中文數字、圓圈數字等）；其次，透過層級順序推斷建立符號之階層關係，判斷哪些符號為高層級、哪些為次層級；最後，將學習到的規則泛化，應用到全文以完成結構化標註。
4.4.2 符號類別分群 #
在符號類別分群方面，系統會將檢測到的符號依類型分類，例如 CHN_NUM 表示中文數字（如一、二、三）、ARA_NUM 為阿拉伯數字（1、2、3）、PAREN_CHN 為括號中文數字（(一)(二)(三)）、CIRCLE_NUM 為圓圈數字（①②③）等。
| 類別代碼 | 說明 | 範例 |
|---|---|---|
CHN_NUM |
中文數字 | 一、二、三 |
ARA_NUM |
阿拉伯數字 | 1、2、3 |
PAREN_CHN |
括號中文數字 | (一)(二)(三) |
PAREN_ARA |
括號阿拉伯數字 | (1)(2)(3) |
CIRCLE_NUM |
圓圈數字 | ①②③ |
4.4.3 層級順序推斷演算法 #
層級順序推斷的演算法主要透過三個步驟完成：首先分析符號的出現順序，假設先出現的符號類別層級較高；第二步進行數值序列分析，檢查同類別符號的遞增或遞減模式；最後根據上述分析結果分配層級，將符號類別對應至對應的階層。例如，若學習區間內檢測到序列「一、 ⑴ ⑵ 二、 ⑴」，則推斷 CHN_NUM 為 Level 0（最高層級），而 PUA_PAREN 為 Level 1（次層級）。
輸入：學習區間內之所有層級符號列表 輸出：層級映射 $\phi: \text{Category} \rightarrow \text{Level}$
演算法步驟：
-
出現順序分析
- 記錄每個符號類別首次出現之行號
- 假設：先出現之類別層級較高
-
數值序列分析
- 檢查同類別符號之數值序列
- 識別遞增模式（1→2→3）或遞減模式
-
層級分配
設 $C = {c_1, c_2, \ldots, c_k}$ 為檢測到之符號類別集合，依以下準則分配層級：
$$ \text{Level}(c_i) = \begin{cases} 0 & \text{if } c_i \text{ is top-level (first appearance)} \\ \text{Level}(c_j) + 1 & \text{if } c_i \text{ appears after } c_j \end{cases} $$
範例：
假設學習區間檢測到以下符號序列：
一、 (CHN_NUM, line 100)
⑴ (PUA_PAREN, line 105)
⑵ (PUA_PAREN, line 110)
二、 (CHN_NUM, line 120)
⑴ (PUA_PAREN, line 125)
推斷結果：
CHN_NUM→ Level 1 (最高層級)PUA_PAREN→ Level 2 (次層級)
4.4.4 規則應用至全文 #
學習完成後，系統將推斷之層級映射應用至全文檢測結果：
def apply_leveling_rules(detection_results, learned_mapping):
for result in detection_results:
if result.is_level_symbol:
category = classify_symbol_category(result.symbol)
result.assigned_level = learned_mapping.get(category, -1)
return detection_results
4.5 輸出格式轉換 #
4.5.1 行級分塊 (Line-Based Chunking) #
系統將檢測結果轉換為以行為單位之結構化區塊：
{
"line_number": 105,
"assigned_level": 1,
"symbol": "⑴",
"line_text": "⑴ 被告於案發時確實在場...",
"confidence": 1.0,
"method": "ultra_strict"
}
4.5.2 Markdown 轉換 #
基於層級資訊，系統將判決書轉換為 Markdown 格式：
- Level 0 →
#一級標題(header, M, F, R …) - Level 1 →
##二級標題 - Level 2 →
###三級標題 - Level -1 → 普通段落
範例輸出：
## 理 由
1. 甲、有罪部分
1. 壹、程序部分
1. 一、本判決所引被告以外之人於審判外所為之陳述，悉經當事人
於本院審理時明白表示同意作為證據（見本院易卷一第269 至272頁、第364頁、卷二第225至226頁、第341頁、第393頁 ），而該等證據之取得並無違法情形，且與本案之待證事實 ，具有關連性，核無證明力明顯過低之事由，本院審酌上開 證據作成時之情況，認為適當，依刑事訴訟法第159條之5第 1項所定傳聞例外之規定，認有證據能力。
2. 二、本判決資以認定被告犯罪事實之非供述證據，查無違反法定
程序取得之情形，依刑事訴訟法第158條之4規定反面解釋， 亦具證據能力。
2. 貳、實體部分
1. 一、認定事實所憑之證據及理由
4.6 評估指標 #
系統效能評估採用以下指標：
-
精確率 (Precision)：
$$P = \frac{TP}{TP + FP}$$ -
召回率 (Recall)：
$$R = \frac{TP}{TP + FN}$$ -
F1-score：
$$F1 = 2 \cdot \frac{P \cdot R}{P + R}$$
其中：
- $TP$：正確識別之層級符號數
- $FP$：誤判為層級符號之數量
- $FN$：漏檢之層級符號數
五、實驗結果與分析 #
5.1 模型效能比較 #
本專案比較 BERT 分類器與傳統機器學習方法在層級符號檢測任務上之效能。實驗採用相同之訓練與測試集進行公平比較。
5.1.1 整體效能指標 #
| 模型 | 準確率 | 精確率 | 召回率 | F1分數 |
|---|---|---|---|---|
| BERT | 0.9905 | 0.9895 | 1.0000 | 0.9947 |
| Random Forest | 0.9052 | 0.9043 | 1.0000 | 0.9497 |
| Logistic Regression | 0.9005 | 0.9038 | 0.9947 | 0.9471 |
| SVM | 0.4550 | 1.0000 | 0.3915 | 0.5627 |
關鍵發現：
- BERT 在精確率與 F1-Score 上均顯著優於傳統方法
- F1-Score 相較最佳傳統方法提升約 4.3 個百分點（0.9947 vs 0.9497）
- 傳統方法在精確率上達到 100%，但召回率較低，存在較多漏檢
5.2 自適應學習效能 #
5.2.1 學習區間分布 #
對 1,102 筆判決書之分析顯示，學習區間分布如下：
| 學習區間類型 | 文件數量 | 比例 | 平均學習行數 |
|---|---|---|---|
| S-D (事實及理由-文末) | 685 | 62.2% | 248 行 |
| R-D (理由-文末) | 347 | 31.5% | 186 行 |
| 全文 | 70 | 6.3% | 312 行 |
分析：
- 多數判決書（93.7%）具備明確之「事實及理由」或「理由」章節
- S-D 區間最常見，符合簡易判決之常見格式
- 全文學習僅用於結構不明確之特殊案例
參考文獻 #
[1] 大方廣資訊股份有限公司. 《漢書系統簡介》. Retrieved from https://dc.stone.com.tw/archives/1706
[2] 大方廣資訊股份有限公司. 《公司沿革》. Retrieved from https://www.stone.com.tw/stone/web/about/about.jsp?cp_no=CP1465268835330
[3] Unicode Consortium. (1999). Unicode Standard Version 3.0. Retrieved from https://www.unicode.org/history/publicationdates.html
[4] 司法院. 《判決書系統使用說明》. Retrieved from https://judgment.judicial.gov.tw/readme.aspx
[5] Devlin, J., Chang, M. W., Lee, K., & Toutanova, K. (2018). BERT: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805.
