為Claude智慧體構建更快、更便宜的PDF解析技能：LiteParse案例研究

在這篇部落格文章中，我們詳細記錄瞭如何透過評估、追蹤分析和迭代改進，將LiteParse文件解析技能最佳化為更便宜、更快且質量更高的助手。

設定

我們使用pdfQA-Benchmark ClimateFinanceBench資料集，下載了30份企業可持續發展/ESG報告PDF及其標註的問答對，然後透過Claude Agent SDK在15個（PDF，問題）對上執行Claude智慧體。每個執行產生結構化JSON答案和完整的JSONL互動追蹤。智慧體可訪問標準工具，並根據評估配置有條件地呼叫技能。

我們比較了多種配置：原始（raw）直接使用Claude內建讀取工具；liteparse初次包裝；liteparse-targeted更直接的變體；以及effective-liteparse——基於評估追蹤最佳化的版本。本文重點介紹最後一個版本的形成過程。

為何需要技能？

LiteParse可作為命令列工具或Rust、Python、JavaScript/TypeScript庫使用。由於文件解析本質上是I/O密集型的，需要直接訪問檔案，而MCP伺服器不支援檔案上傳，因此技能是最實用的整合模式。透過將使用說明打包成markdown檔案注入智慧體上下文，智慧體可將LiteParse CLI作為Claude內建PDF閱讀器的替代品。此外，CLI便於與grep、sed等Unix工具組合，實現過濾、搜尋和轉換。

發現反模式

前兩輪評估後，我們收集了延遲、輪次、成本等指標，並分析了JSONL追蹤，發現了一系列常見且昂貴的錯誤：

• 反覆解析同一PDF——最差情況下，一個文件被解析了9次。
• 對數字原生PDF啟用OCR，純粹浪費時間。
• 將高解析度頁面截圖讀入上下文，單個PNG消耗約14萬字元。
• 無限制的grep，一次性注入1.5萬–2.5萬字元。

最佳化：effective-liteparse技能

我們建立了effective-liteparse技能，將修復編碼為硬規則：解析一次並儲存到臨時檔案，然後搜尋該檔案；對數字原生PDF停用OCR（--no-ocr）；截圖僅作為最後手段，一頁，適度DPI；保持結果精簡。

此外，我們注意到智慧體經常使用grep、sed和Read進行多次緊密迭代以找到正確上下文。因此，我們擴充套件了技能，包含一個自包含的Python指令碼，用於併發讀取、分塊、索引並基於BM25進行檢索，並指示智慧體在模糊關鍵詞搜尋時使用此指令碼，預設對模式/子串搜尋使用詞法搜尋。

減少輪次

修復後，新問題浮現：effective-liteparse雖便宜但更慢，原因是輪次過多。最常用的工具是grep和sed，形成序列迴圈：grep→檢視→改進grep→sed讀取視窗→再次grep，每次呼叫都是完整API往返。我們之前的規則“先定位，再用sed讀取視窗”使每個查詢分裂成兩輪，“不進行散彈式搜尋”則促使模型進行許多細小的序列grep。

我們修改了指導原則，以減少往返：

• 在同一命令中獲取上下文——grep -n -i -C4 "term"一次返回匹配及其上下文，無需後續sed。
• 將獨立查詢批處理到一個命令中——帶標籤的for迴圈一次性探查多個事實。
• 硬搜尋預算——最多3次grep，之後回退到BM25排序器。

追蹤確認了新行為：批處理模式出現，平均輪次下降約15%（從13.1降至11.1）。

資料結果

我們使用LLM評判員（Gemini和GPT）評分，並分析效率指標。在15個問題的子集上：

質量（LLM評分，越高越好）：

| 指標 | 原始 | effective-liteparse | |------|------|--------------------| | 總體答案 | 46.47 | 56.67 | | 總體推理 | 58.47 | 65.90 | | Gemini答案 | 58.53 | 78.33 | | Gemini推理 | 71.33 | 86.00 | | GPT答案 | 34.40 | 35.00 | | GPT推理 | 45.60 | 45.80 |

效率（追蹤指標）：

| 指標 | 原始 | effective-liteparse | |------|------|--------------------| | 平均每個問題成本 | $0.751 | $0.474（-37%） | | p95成本 | $1.323 | $0.746 | | 平均輪次 | 8.47 | 11.08 | | 平均每輪時長 | 6.5秒 | 5.6秒（-14%） |

令牌使用：

| 指標（每次執行平均） | 原始 | effective-liteparse | |----------------------|------|--------------------| | 基礎輸入令牌 | 23 | 17 | | 快取寫入（5分鐘）令牌 | 86,666 | 29,623 | | 快取讀取令牌 | 214,924 | 354,330 | | 輸出令牌 | 2,433 | 3,546 | | 總輸入令牌 | 301,612 | 383,970 | | 成本 - 快取寫入（5分鐘） | $0.542 | $0.185 | | 成本 - 快取讀取 | $0.107 | $0.177 | | 成本 - 輸出 | $0.061 | $0.089 | | 平均成本（報告） | $0.751 | $0.452 |

LiteParse技能每個問題便宜37%，所有評判指標得分更高。雖然整個任務仍慢幾秒，但每輪時長更快，允許更多迭代。

關於令牌使用的說明

乍看之下，effective-liteparse變體處理了更多輸入令牌（約384k對約302k），但這是因為大部分是便宜的快取讀取（$0.50/百萬令牌），而昂貴的快取寫入（$6.25/百萬令牌）比基線低了約3倍（29.6k對86.7k）。原始方法每次讀取都會重新快取大型PDF影像頁面，而LiteParse本地解析並返回緊湊文本，因此快取寫入成本大幅下降。淨效果是成本降低約40%。

成本基於釋出的Claude Opus 4.7費率。報告成本是執行時的total_cost_usd；與逐類別彙總的小差距來自一個次要的Haiku呼叫。

經驗教訓

• 追蹤是真理。所有改進都來自閱讀智慧體實際行為。
• 技能指導有次生效應。“先定位再讀取”和“不散彈搜尋”聽起來合理，但增加了輪次。應最佳化總輪次而非每個命令的整潔性。
• 將框架與技能分離。最大的成本數字是框架人工產物，而非技能屬性。在歸因前仔細測量。
• 在這裡，更便宜和更好不是取捨。有紀律的本地解析在成本和答案質量上都優於原始PDF攝取。

完整基準測試可在 https://github.com/run-llama/benchmark-claude-pdfs 獲得和復現。