llm_aided_ocr：用 LLM 修補 Tesseract 的錯字，但你要先想清楚成本

它解決什麼問題，誰會需要它

掃描 PDF 經過 Tesseract 之後，輸出的文字常常夾雜錯字、斷行錯亂、頁首頁尾重複。人工修正既慢又無聊。llm_aided_ocr 把這道工序交給大型語言模型，讓模型根據上下文推測正確的字詞，同時把純文字轉成結構化的 Markdown。專案提供的範例是一封 Warren Buffett 與 Katharine Graham 的歷史信件，從原始 PDF 到 LLM 校正後的 Markdown，可以看出它鎖定的對象是歷史文件、書籍掃描、舊報紙這類需要保留可讀性的文本。需要的人包括數位人文研究者、文件數位化團隊，以及任何想把老 PDF 變成乾淨文字檔的工程師。但不是所有 OCR 問題都適合用 LLM 解，後面會談到界線。

管線拆解：從 PDF 到 Markdown 的四個步驟

專案的流程很清楚，README 把每個環節都列了函式名稱。首先是 convert_pdf_to_images()，用 pdf2image 把 PDF 每頁轉成影像，支援 max_pages 與 skip_first_n_pages 參數，代表可以只處理部分頁面。接著 ocr_image() 呼叫 pytesseract，但之前會先經過 preprocess_image()，把影像轉灰階、用 Otsu 方法做二值化、再膨脹來強化文字。這是傳統 OCR 的前處理，對抗低解析度掃描。第三步是核心：process_document() 把整份 OCR 文字按句子邊界切成 chunk，chunk 之間有重疊以保留上下文。每個 chunk 送進 process_chunk()，先做 OCR 錯誤修正，再選擇性做 Markdown 格式化。最後一步是重複內容移除與頁首頁尾抑制，這兩個功能都放在 Markdown 格式化階段。整個流程的順序有意義：先校正再格式化，避免模型在格式轉換時把錯字一起保留。

LLM 整合的兩種路徑與非同步設計

這專案支援兩種 LLM 來源：本機與 API。本機端用 llama_cpp 載入 GGUF 模型，並支援自訂 grammar 來限制輸出結構。API 端支援 OpenAI 與 Anthropic，分別有 generate_completion_from_claude() 和 generate_completion_from_openai() 兩個函式。README 特別提到 API 端有錯誤重試邏輯，並會動態調整請求大小以符合 token 限制。非同步處理是 API 模式的亮點，用 asyncio 同時處理多個 chunk，但仍維持順序，確保最後輸出連貫。這對長文件很重要，因為逐 chunk 同步處理會慢得無法忍受。本機模式沒有提到非同步，這是一個明顯的落差，若你打算用本機模型處理大量文件，速度可能成為瓶頸。

Token 管理：看似貼心，實際上是必要之惡

LLM 校正的品質取決於能塞進多少上下文，但 API 有 token 上限，費用也隨 token 數增加。專案提供 estimate_tokens()，優先使用模型專屬 tokenizer，否則退回 approximate_tokens() 做粗略估算。同時有 TOKEN_BUFFER 與 TOKEN_CUSHION 兩個常數，用來確保請求不會超過模型上限。這聽起來很周全，但代表一個現實：你無法把整份文件一次丟給模型，必須切 chunk。切 chunk 本身就有資訊遺失風險，即使有重疊也無法完全避免跨 chunk 的上下文斷裂。例如某個專有名詞第一次出現在前一個 chunk 結尾，模型在下一個 chunk 校正時就少了依據。這是所有 LLM 輔助 OCR 方案的共同限制，但這個專案用重疊來緩解，效果如何取決於 chunk 大小設定，README 沒有給出建議值。

品質評估與輸出檔案：有把關，但依賴 LLM 自己

專案內建 assess_output_quality()，會比較原始 OCR 文字與處理後的輸出，並請 LLM 給出品質分數與解釋。這個設計有創意，但也有根本問題：讓同一個 LLM 評估自己的校正結果，等於請考生改自己的考卷。模型可能對自己的錯誤視而不見，尤其是當錯誤是模型自己引入的（例如過度改寫）。輸出檔案的命名規則很清楚：原始 OCR 存成 {base_name}__raw_ocr_output.txt，校正後存成 {base_name}_llm_corrected.md 或 .txt。保留原始輸出是正確的做法，至少讓使用者能比對。但 README 沒有提到任何 diff 工具或視覺化比較，你得自己寫程式去比對兩個檔案。

安裝與設定：Python 3.12 是硬性要求

安裝流程不算簡單。README 建議用 pyenv 安裝 Python 3.12，然後建立虛擬環境，接著 pip install -r requirements.txt。系統還需要 Tesseract OCR 引擎，Ubuntu 用 apt-get、macOS 用 brew、Windows 要另外下載安裝檔。設定檔是 .env，關鍵變數有 USE_LOCAL_LLM、API_PROVIDER、OPENAI_API_KEY、ANTHROPIC_API_KEY。若 USE_LOCAL_LLM=False，就必須設定 API_PROVIDER 為 OPENAI 或 ANTHROPIC，並提供對應金鑰。若設為 True，則需要本機 GGUF 模型，但 README 沒有列出具體的模型名稱或下載位置。這對新使用者是障礙，你得自己找相容的模型。另外，README 提到支援 GPU 加速本機推理，但沒有給出任何 CUDA 或 llama_cpp 的安裝細節，實際部署時可能要翻原始碼。

授權不明與維護狀態：採用前要停一下

這個專案的授權標示是 NOASSERTION，代表 GitHub 無法判定授權條款，這對商業使用是紅旗。你必須聯絡作者或檢查 repository 內是否有 LICENSE 檔案，否則不能隨意整合進產品。最後一次 push 是 2026 年 8 月，以現在的時間點來看算是近期有活動，但沒有 release 標籤，表示沒有穩定的版本號。對依賴外部專案的團隊來說，沒有 release 意味著 API 可能隨時變動。README 要求 Python 3.12，這本身也限制了部署環境，若你的基礎設施還在 Python 3.10，就得先升級。整體而言，這是一個功能完整但尚未產品化的工具，適合願意讀原始碼的工程師，不適合只想裝了就跑的使用者。

替代方案：不是只有 LLM 一條路

如果你不想承擔 LLM 的 API 成本或不確定校正品質，可以考慮傳統 OCR 後處理工具，例如 OCRFeeder 或 Tesseract 自身的 --psm 參數調整。但那些方法不會理解語意，只能靠字典或規則修正。另一個方向是使用專門的 OCR 引擎如 OCRmyPDF，它加入 PDF 的文字層，但不做語意校正。真正的替代方案是直接採用雲端 OCR 服務，例如 Google Cloud Vision 或 Azure Form Recognizer，它們內建了機器學習模型，輸出品質通常比 Tesseract 好，且不需要自己接 LLM。差別在於：llm_aided_ocr 讓你自己選擇 LLM，可以完全本機處理以保護隱私，但雲端服務是一體化方案，設定少但隱私與成本控制較弱。若你的文件包含敏感資料，本機 LLM 路徑有吸引力，但你需要準備夠強的 GPU。

編輯結論

若你手上有一批掃描 PDF，且現有 Tesseract 輸出錯誤太多、人工修正成本高，這個專案值得一試。它特別適合需要 Markdown 格式輸出、且能接受 API 費用的團隊。但若你的文件量極大、對成本敏感，或需要即時處理單頁文件，這套流程可能過重。使用前應先確認：你的 PDF 是否為印刷體、是否包含大量表格或特殊排版（這類內容 LLM 校正容易出錯），以及你能否承擔每份文件的 API token 消耗。另外，專案依賴 Python 3.12 與 Tesseract，部署環境需先備妥。最後，LLM 校正會改寫文字，若文件需法律或學術上的逐字正確性，請務必保留原始 OCR 輸出以供比對。

官方來源

1. Dicklesworthstone/llm_aided_ocr on GitHub
2. Issues
3. README