為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 獲得和復現。