# 掃描書轉 EPUB 後，註腳為什麼會指錯？PDF Craft 的 JEV 複核方法

從讓 LLM 逐頁閱讀，到以 JEV 篩選可疑頁面：記錄 PDF Craft 檢查掃描書籍註腳關係的一次設計迭代。

![舊書頁的正文引用與頁底註腳以細線相連，旁邊是可重排的閱讀頁](https://pdfcraft.ai/zh-Hant/images/blog/jev-footnote-review.webp "概念插圖：轉換時要保留正文與註腳之間的閱讀關係。")

我開發 PDF Craft，是想把掃描書籍 PDF 變成真正方便閱讀、搜尋與整理的 Markdown 或 EPUB。但轉換不只是把圖片辨識成文字：正文裡的數字、圈號或星號，還得準確指向原書頁腳的那條註釋。否則文字雖然能重新排版，閱讀關係卻丟了。

整理舊書、學術資料或個人藏書時，這件事尤其重要。轉換結果應能在手機或閱讀器上舒適閱讀、搜尋與摘錄，也應讓讀者從正文標記找到完整的註釋。檢查輸出時，可以參考[掃描 PDF 轉 EPUB 指南](https://pdfcraft.ai/zh-Hant/blog/scanned-pdf-to-epub/)及[公式與註腳檢查清單](https://pdfcraft.ai/zh-Hant/blog/check-formulas-footnotes-after-ocr/)。

## OCR 辨識文字，不等於理解註腳

OCR 能找出頁面上的字，卻未必知道它們在書中扮演什麼角色。頁底的小字可能是註腳，也可能只是排到頁底的正文；右上角的圈號可能是引用標記，也可能是普通序號。一條註釋還可能被拆成兩塊，甚至跨到下一頁。

只要一處關係判斷錯了，EPUB 就可能出現標記沒有目標、兩條註腳黏在一起、頁碼混進句子，或上一頁末句接上下一頁欄頭的情況。註腳一直是 PDF Craft 裡最難處理的問題之一。

## 一年前：讓 LLM 讀過每一頁

最初的辦法很直接：既然傳統程式難以理解語意，就把整頁交給大型語言模型。它能看出頁底小字在解釋正文，理解星號、圈號、羅馬數字或漢字序號可能是引用標記，也能根據上下文判斷跨頁句子。

單頁結果很吸引人，整本書的代價卻很高。幾百頁代表幾百次呼叫、等待與可能的重試；跨頁判斷還要帶上相鄰內容，輸入越來越長。大多數頁面原本沒有問題，昂貴的模型常常讀完一頁，只確認不必修改。使用者也很難知道漫長的處理究竟是在前進，還是卡住了。

## 先讓傳統流程獨立完成整本書

後來的版本逐漸把主要工作交回 OCR 與確定性的規則：區分正文和註腳，合併自然段，拆出個別註釋，再把正文標記與註釋配對。這條流程快速、穩定、可重複，能處理多數頁面。

但書籍排版變化太多。註腳可能在頁底或欄間，標記可能是數字或符號，頁碼、欄頭與裝飾字元也可能混入文字。有些判斷終究需要理解句意。只靠規則會留下少數難題，讓 LLM 接管每一頁又太慢、太貴。

## 轉折：請 JEV 審查，而不是重做

已有的流程不需要推翻，它需要的是快速質檢：挑出值得懷疑的頁面，再請 LLM 仔細處理。我讓 JEV 只回答一個狹窄的問題：**這一頁的分析結果能否原樣通過？**它不重寫文字，也不逐條解釋註釋，只回傳用於篩選的機率。

審查以整頁為單位。如果演算法徹底漏掉一條註釋，逐條檢查已知註釋就無從發現；頁面層級的判斷仍可能察覺引用缺失、歸屬錯誤、跨頁異常或頁碼混入正文。我寧可多送幾頁給模型，也不願把錯誤直接放進 EPUB：誤報增加檢查成本，漏報影響閱讀結果。門檻仍須透過更多樣本校準。

```mermaid
flowchart TB
  accTitle: 從整頁審查到有約束的修復
  accDescr: OCR 與傳統演算法先處理頁面；JEV 判斷是否原樣通過。可疑頁交給 LLM 修復，再由程式檢查。通過後進入章節組裝，不通過則重試。
  A[OCR 與傳統演算法] --> B{JEV：頁面可信？}
  B -- 是 --> F[章節組裝與輸出]
  B -- 否 --> C[LLM 只修復目前頁]
  C --> D{程式完整性檢查}
  D -- 通過 --> F
  D -- 重試 --> C
```

## 讓 LLM 在嚴格邊界內修復

對可疑頁面，LLM 會看到前一頁、目前頁與下一頁的文字結構，但只能修改中間那頁。相鄰頁提供跨頁語境。這一步不送頁面圖片：OCR 已提供文字、位置及版面資訊，模型要做的是語意校正，而非再做一次 OCR。

模型可以重新標註正文、註腳和頁碼，修正段落連接與標記配對，卻不能自由改寫原文或變動頁面結構。程式會檢查註腳索引的順序、正文引用與註腳的對應、跨頁連接兩端的一致性，以及標記位置是否能在指定文字中明確找到。若檢查失敗，具體錯誤會退回模型，要求重新提交完整結果。不能為了減少重試而放鬆約束。

## 一份 26 頁樣本的提醒

在一次有大量註腳的 26 頁測試 PDF 中，JEV 選出 6 頁交給 LLM。六頁的首次提交都通過完整性檢查，原本正確的 22 組正文引用與註腳關係也全部保留。

真正修正的是幾個不顯眼、卻影響閱讀的問題：印刷頁碼被當成正文，一處頁碼錯誤地連起前後段落，還有一句引導讀者閱讀下文的話，被合併進後面的縮排引文。模型根據語意與縮排將它們分開。

這只是單次樣本觀察，不能推論所有書籍的準確率或成本。好的修復階段應尊重已經正確的部分，只改有證據支持的問題。

## 把昂貴的判斷用在必要之處

傳統演算法完成多數確定性的工作；JEV 快速篩選可疑頁面；LLM 處理少數需要語意理解的難題；程式約束守住最後的結構。修復頁面回到同一條流程，後續章節組裝以及 Markdown、EPUB 輸出不必另開一套系統。

這個方案還要在更多語言、版式與厚書上測試，特別是 JEV 的漏報率和送交 LLM 的門檻。至少方向已經明朗：不必讓 LLM 從第一頁讀到最後一頁，只為了找出藏在頁角的幾個錯誤。

如果你要處理自己的掃描書，可以先在 [PDF Craft 轉換頁面](https://pdfcraft.ai/zh-Hant/pdf-craft/)選一份有註腳的短樣本，核對正文標記、完整註釋與跨頁段落，再決定是否轉換整本書。