LiteParse 评测工具集实战基于 LLM-as-a-Judge 的 PDF 解析质量评估与基准测试【免费下载链接】liteparseA fast, helpful, and open-source document parser项目地址: https://gitcode.com/GitHub_Trending/li/liteparse本指南围绕仓库中的 dataset_eval_utils 评测工具集展开讲解如何为 PDF 解析任务生成结构化 QA 数据集ground truth、利用 LLM 裁判LLM-as-a-Judge跨解析器评估文本提取质量并对各解析器做延迟与性能基准测试。读完本文你将掌握lp-process、lp-evaluate、lp-benchmark三个 CLI 工具的完整用法、底层实现原理与评测结果解读方法可直接用于构建自己的文档解析评测流水线。工具集定位为什么需要专门的 PDF 解析评测框架PDF 解析的质量很难用单一的字符级指标如 Levenshtein 距离衡量文本顺序颠倒、表格结构丢失、多栏排版错位等问题都可能导致提取出来了但内容不可用。LiteParse 评测工具集liteparse-eval采用的思路是LLM-based QA evaluation先用 Claude 的视觉能力从文档页面生成问题-答案对作为 ground truth再让目标解析器提取文本、让 LLM 基于提取文本回答问题最后由独立的 LLM 裁判判断预测答案与标准答案是否语义等价从而把解析质量转化为可量化的通过率pass rate。该工具集在仓库中的位置为 dataset_eval_utils/ 核心实现分布在src/liteparse_eval/目录下通过 pyproject.toml 声明包信息并注册了三个 CLI 入口lp-process、lp-evaluate、lp-benchmark。环境准备与安装工具集要求Python 3.12。从dataset_eval_utils目录执行pip install -e .安装前建议先查看 pyproject.toml 中声明的依赖主要包括anthropic0.104.1LLM 问答与裁判能力liteparse2.0.0LiteParse 解析器本仓库主项目的 Python 封装pymupdf1.27.2、pymupdf4llm1.27.2、pypdf6.13.3、pdftotext3.0.0、markitdown[all]0.1.5、opendataloader-pdf2.4.1对比评测的解析器后端pillow12.2.0报告生成时的图像处理rapidfuzz3.14.5文本相似度辅助由于 LLM 评测与数据集生成都依赖 Anthropic 的 Claude还需要设置环境变量export ANTHROPIC_API_KEYsk-ant-...ANTHROPIC_API_KEY可以通过环境变量提供也可以用各命令的--api-key参数显式传入。所有依赖官方说明见 pyproject.toml三个 CLI 入口注册于 pyproject.toml。第一步用 lp-process 生成 Ground Truth 数据集lp-process利用 Claude 的视觉能力vision处理 PDF 和图片文件逐页生成结构化的 QA 数据作为后续评测的标准答案。基本用法lp-process /path/to/documents --output-dir ./ground_truth参数说明与 processing.py 中的 argparse 定义一致参数默认值说明input_dir位置参数—存放 PDF / 图片的输入目录--output-dir./output输出 JSON 文件的保存目录--modelclaude-sonnet-4-5-20250929用于分析的 Claude 模型--api-key无Anthropic API Key未提供时读取ANTHROPIC_API_KEY环境变量底层处理流水线从 processing.py 的process_file可以看到完整流程发现文档find_documents递归扫描输入目录支持.pdf、.jpg、.jpeg、.png、.gif、.webp六种格式并同时匹配小写与大写扩展名每批最多随机采样 50 个文档见 processing.py 与 L267PDF 转图片对 PDF 调用 LiteParse 的parser.screenshot(pdf_path, dpidpi)按页渲染默认 DPI 为 150processing.py若当前 LiteParse 版本未实现该能力会捕获NotImplementedError并跳过该文件图片编码将页面图片 base64 编码并根据扩展名推断媒体类型jpeg/png/gif/webpprocessing.pyClaude 结构化分析调用client.beta.messages.parse使用structured-outputs-2025-11-13beta 能力直接以 Pydantic 模型作为输出 schemaprocessing.py。Ground Truth 的数据结构每页输出一个 JSON 文件内容遵循PageAnnotationschemaprocessing.py{ has_text: true, document_type: academic_paper, layout_complexity: multi_column, qa_pairs: [ {question: 论文中提出的方法叫什么, answer: LiteParse}, {question: 实验在多少个数据集上验证, answer: 3 个} ] }字段含义has_text文档页是否包含可读文本document_type文档类型枚举值为academic_paper、form、invoice、newspaper、otherlayout_complexity版面复杂度枚举值为simple、multi_column、complexqa_pairs35 个问题-答案对。分析提示词要求生成有趣、多样、有时具有挑战性的问题因为这些数据将被用于文档解析基准LLM-as-a-judge 评判 QA 回答见 processing.py。输出文件命名规则多页 PDF 按页输出为{文件名}_page_{页码:03d}.json如report_page_001.json单张图片输出为{文件名}.jsonprocessing.py。该命名规则直接决定了后续lp-evaluate的匹配方式。官方预生成数据集README 提到一个已经用该框架生成并评测过的公开数据集可用 Hugging Face CLI 下载hf download run-llama/liteparse-eval-dataset --repo-type dataset --local-dir ./liteparse-eval-dataset下载后可直接配合lp-evaluate使用也可以作为参考示例理解 ground truth JSON 的组织方式。第二步用 lp-evaluate 运行 QA 评测lp-evaluate是评测的核心它让 LLM 基于解析器提取出的文本来回答 ground truth 中的问题再用独立的 LLM 裁判判断答案正确性最终汇总为通过率。基本用法lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider liteparse \ --output ./results/run1参数说明与 evaluation.py 一致参数默认值说明--data-dir必填存放源 PDF 文档的目录--ground-truth-dir必填存放 ground truth JSON 文件的目录--output无结果保存路径生成 JSON HTML 报告--parse-providerliteparse待评测解析器可选pymupdf、pypdf、markitdown、liteparse、pdftotext、pymupdf4llm-text、pymupdf4llm-md、opendataloader--llm-provideranthropic回答问题的 LLM当前仅支持anthropic文档与 Ground Truth 的匹配规则评测前程序会用ground_truth_dir.glob(*.json)找到所有 ground truth 文件然后在数据目录中查找同名不含扩展名的 PDF 源文件进行配对evaluation.py。因此使用lp-process生成数据后务必保持源文档与 ground truth 的文件名基准一致。找不到源文件的 ground truth 会被跳过并打印警告。双模型设计回答者与裁判分离从 evaluation.py 可以看到默认配置回答问题的 LLMclaude-sonnet-4-5-20250929与lp-process默认模型一致负责阅读提取文本并回答问题裁判 LLMclaude-haiku-4-5-20251001独立实例负责评判答案是否语义等价。把回答与裁判分离可以有效避免同一模型既当运动员又当裁判带来的偏差。AnthropicProvider初始化时设置了max_retries100、timeout10000的重试与超时策略anthropic.py在大批量评测时提升稳定性。三份输出文件运行后生成三个结果文件evaluation.pyoutput.json— 聚合结果总文档数、总问题数、整体 LLM 裁判通过率overall_llm_judge_pass_rate、逐文档通过率、解析延迟与 LLM 延迟的统计指标count、total、average、min、max、stddevoutput_detailed.json— 逐文档详细结果包含提取出的完整文本与每个 QA 对的 question/expected_answer/predicted_answer/llm_judge_pass方便排查失败原因evaluation.pyoutput_report.html— 交互式 HTML 报告基于 report.py 生成使用 PyMuPDF 渲染 PDF 页面预览逐文档展示 QA 明细与通过率适合分享给团队审阅。第三步用 lp-benchmark 做性能基准测试lp-benchmark与 QA 评测互补它只测量解析延迟与文本产出不涉及 LLM用于对比各解析器的速度。lp-benchmark ./documents --providers pymupdf liteparse --output ./bench.json以当前仓库源码为准实际参数为benchmark.py参数默认值说明input_dir位置参数—存放 PDF 的目录注意源码为目录而非单文件--providers全部本地解析器待评测解析器列表可选liteparse、pymupdf、pypdf、markitdown、pdftotext、pymupdf4llm-text、pymupdf4llm-md、opendataloader、pdf-inspector--warmup-runs5每个解析器计时前的预热轮数--output无JSON 结果保存路径需要说明README 中记录的示例lp-benchmark document.pdf --providers pymupdf liteparse --runs 20与当前源码存在差异——源码中位置参数是目录而非单文件且参数名为--warmup-runs无--runs预热默认值为 5。若你的安装版本命令行为与此不符请以lp-benchmark --help实际输出为准。评测流程与输出从 benchmark.py 的实现看流程为扫描目录下所有.pdf非递归用pypdf统计每份文档页数对每个解析器执行预热运行默认 5 轮规避冷启动与 JIT/加载开销对每份文档计时提取time.perf_counter记录耗时与提取字符数终端打印对齐表格包含每文档耗时、TOTAL 行、AVG/doc 行以及按页均摊的MS/PAGE行提取失败标记为ERROR聚合行带*提示输出 JSON 包含per_documentseconds、text_length、ms_per_page、total_seconds、avg_seconds、ms_per_page、num_success、num_error等字段。解析器 Providers 全览评测框架通过统一的ParserProvider抽象接口providers/parsers/base.py屏蔽差异每个解析器只需实现extract_text(file_path) - str。各实现位于 providers/parsers/Provider底层库实现要点liteparseLiteParse空间感知文本提取支持 OCR封装在 liteparse.py默认output_formatmarkdownpymupdfPyMuPDFfitz打开文档后逐页get_text()页间以空行连接pymupdf.pypypdfpypdf纯 Python 实现PdfReader逐页extract_text()pypdf.pymarkitdownMarkItDown微软文档转 Markdown 工具返回text_contentmarkitdown.pypdftotextpdftotextpoppler 命令行工具封装pymupdf4llm-text/pymupdf4llm-mdPyMuPDF4LLM分别输出纯文本与 Markdown 两种格式opendataloaderOpenDataLoader PDF数据加载生态的 PDF 提取其中liteparse作为默认提供者其封装类支持丰富的初始化参数liteparse.pyocr_enabled扫描件 OCR 开关、ocr_server_urlHTTP OCR 服务地址缺省回退 Tesseract、ocr_languageOCR 语言默认en、max_pages最大解析页数默认 1000、dpi渲染 DPI默认 150影响 OCR 质量、preserve_very_small_text是否保留极小字号文本。如需接入新解析器只需继承ParserProvider并实现extract_text默认的extract_text_batch提供顺序批处理实现支持原生批处理的提供者可覆写该方法base.py。裁判机制原理提示词与判定逻辑理解评测结果前需要了解两个关键提示词它们定义在 providers/llm/base.py回答提示词QA_PROMPT——要求 LLM 只依据document标签内文本回答问题简洁准确、尽量引用原文若文档不含答案必须回答not founddocument{ocr_text}/document Answer the following question about the document. Be as concise and accurate and possible, pulling from the exact text. If the document does not contain the answer, response with not found. Question: {question}裁判提示词JUDGE_PROMPT——判定两个答案是否语义等价明确给出四条标准措辞不同但语义相同算通过答案可依赖问题上下文预测答案说 not found 时仅在标准答案同样表示信息缺失时才通过。输出格式为pass简短理由/pass或fail简短理由/fail。裁判的通过判定逻辑在 anthropic.py将响应文本小写化后包含pass且不包含fail即判定通过若裁判调用异常或返回空内容则宽容地视为通过return True避免单次裁判故障拖垮整轮评测。端到端评测管线实操将三步串起来即构成完整的评测工作流# 1. 准备环境 export ANTHROPIC_API_KEYsk-ant-... pip install -e ./dataset_eval_utils # 2. 生成 ground truth每页一个 JSON lp-process ./documents --output-dir ./ground_truth # 3. 评测 liteparse 的提取质量 lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider liteparse \ --output ./results/liteparse # 4. 换 pymupdf 做对比 lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider pymupdf \ --output ./results/pymupdf # 5. 性能基准对比 lp-benchmark ./documents --providers pymupdf liteparse --output ./bench.json评测的四个阶段对应 evaluation.py 的run_qa_eval提取文本用所选 parser provider 从 PDF 提取文本同时记录解析耗时回答问题LLM 读取提取文本逐题回答 ground truth 中的问题逐题记录延迟裁判判定独立的 LLM 裁判判断预测答案与标准答案是否语义等价汇总按文档与整体计算通过率通过题数 / 总题数。运行lp-evaluate时终端会实时打印每份文档的通过率与平均 LLM 延迟例如QA: LLM judge pass: 82.5% [avg LLM: 3.21s]最后汇总整体通过率与总问题数evaluation.py。结果解读与报告使用聚合 JSONoutput.json中最关键的指标是overall_llm_judge_pass_rate——它衡量解析器提取出的文本能否支撑 LLM 正确回答问题的比例间接反映提取内容的语义完整性。详细 JSON 中的qa_evaluation.qa_pairs记录了每个问题的标准答案、预测答案与判定结果是定位解析缺陷的最佳入口预测答案与标准答案语义接近但被判 fail多为文本顺序错乱导致 LLM 引用出错或裁判判定过严可对照extracted_text字段核实大量问题回答 not found说明文本提取严重缺失如扫描件未开 OCR、表格内容丢失多栏版面通过率显著偏低可尝试切换为liteparse空间感知提取或开启 OCR。HTML 报告output_report.html由 report.py 生成内嵌 PDF 页面预览通过 PyMuPDF 渲染逐文档展示通过率与 QA 明细适合在评审会上直接打开讨论。常见问题与注意事项API Key 缺失所有 LLM 相关命令都需要ANTHROPIC_API_KEY未设置时会直接报错可改用--api-key传入ground truth 与源文档命名不一致lp-evaluate按同名 stem 匹配务必保持report.pdf↔report.json或report_page_001.json的命名约定扫描版 PDFlp-process依赖 LiteParse 的截图能力渲染页面若当前版本未实现会打印Skipping PDF (conversion not implemented)并跳过lp-evaluate侧如需处理扫描件请使用带 OCR 的解析器配置provider 依赖未安装每个解析器后端是独立依赖未安装对应库时lp-benchmark会在初始化阶段捕获异常并将该 provider 标记为ERROR不影响其他 provider 的评测README 与源码的命令差异lp-benchmark请以源码 argparse 定义的参数目录入参、--warmup-runs为准命令前可先执行lp-benchmark --help确认。总结LiteParse 评测工具集提供了一条从数据准备 → 质量评测 → 性能基准的完整评测闭环lp-process用 Claude 视觉能力生成带文档类型、版面复杂度标注的 QA ground truthlp-evaluate通过回答 独立裁判的双 LLM 机制把解析质量量化为通过率lp-benchmark补充延迟维度的对比数据。三者共享统一的ParserProvider抽象新增解析器只需实现一个extract_text方法即可纳入评测。这套框架既可用于 LiteParse 与其他解析器的横向对比也可作为团队内部文档解析回归测试的基础设施。【免费下载链接】liteparseA fast, helpful, and open-source document parser项目地址: https://gitcode.com/GitHub_Trending/li/liteparse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiteParse 评测工具集实战：基于 LLM-as-a-Judge 的 PDF 解析质量评估与基准测试
LiteParse 评测工具集实战基于 LLM-as-a-Judge 的 PDF 解析质量评估与基准测试【免费下载链接】liteparseA fast, helpful, and open-source document parser项目地址: https://gitcode.com/GitHub_Trending/li/liteparse本指南围绕仓库中的 dataset_eval_utils 评测工具集展开讲解如何为 PDF 解析任务生成结构化 QA 数据集ground truth、利用 LLM 裁判LLM-as-a-Judge跨解析器评估文本提取质量并对各解析器做延迟与性能基准测试。读完本文你将掌握lp-process、lp-evaluate、lp-benchmark三个 CLI 工具的完整用法、底层实现原理与评测结果解读方法可直接用于构建自己的文档解析评测流水线。工具集定位为什么需要专门的 PDF 解析评测框架PDF 解析的质量很难用单一的字符级指标如 Levenshtein 距离衡量文本顺序颠倒、表格结构丢失、多栏排版错位等问题都可能导致提取出来了但内容不可用。LiteParse 评测工具集liteparse-eval采用的思路是LLM-based QA evaluation先用 Claude 的视觉能力从文档页面生成问题-答案对作为 ground truth再让目标解析器提取文本、让 LLM 基于提取文本回答问题最后由独立的 LLM 裁判判断预测答案与标准答案是否语义等价从而把解析质量转化为可量化的通过率pass rate。该工具集在仓库中的位置为 dataset_eval_utils/ 核心实现分布在src/liteparse_eval/目录下通过 pyproject.toml 声明包信息并注册了三个 CLI 入口lp-process、lp-evaluate、lp-benchmark。环境准备与安装工具集要求Python 3.12。从dataset_eval_utils目录执行pip install -e .安装前建议先查看 pyproject.toml 中声明的依赖主要包括anthropic0.104.1LLM 问答与裁判能力liteparse2.0.0LiteParse 解析器本仓库主项目的 Python 封装pymupdf1.27.2、pymupdf4llm1.27.2、pypdf6.13.3、pdftotext3.0.0、markitdown[all]0.1.5、opendataloader-pdf2.4.1对比评测的解析器后端pillow12.2.0报告生成时的图像处理rapidfuzz3.14.5文本相似度辅助由于 LLM 评测与数据集生成都依赖 Anthropic 的 Claude还需要设置环境变量export ANTHROPIC_API_KEYsk-ant-...ANTHROPIC_API_KEY可以通过环境变量提供也可以用各命令的--api-key参数显式传入。所有依赖官方说明见 pyproject.toml三个 CLI 入口注册于 pyproject.toml。第一步用 lp-process 生成 Ground Truth 数据集lp-process利用 Claude 的视觉能力vision处理 PDF 和图片文件逐页生成结构化的 QA 数据作为后续评测的标准答案。基本用法lp-process /path/to/documents --output-dir ./ground_truth参数说明与 processing.py 中的 argparse 定义一致参数默认值说明input_dir位置参数—存放 PDF / 图片的输入目录--output-dir./output输出 JSON 文件的保存目录--modelclaude-sonnet-4-5-20250929用于分析的 Claude 模型--api-key无Anthropic API Key未提供时读取ANTHROPIC_API_KEY环境变量底层处理流水线从 processing.py 的process_file可以看到完整流程发现文档find_documents递归扫描输入目录支持.pdf、.jpg、.jpeg、.png、.gif、.webp六种格式并同时匹配小写与大写扩展名每批最多随机采样 50 个文档见 processing.py 与 L267PDF 转图片对 PDF 调用 LiteParse 的parser.screenshot(pdf_path, dpidpi)按页渲染默认 DPI 为 150processing.py若当前 LiteParse 版本未实现该能力会捕获NotImplementedError并跳过该文件图片编码将页面图片 base64 编码并根据扩展名推断媒体类型jpeg/png/gif/webpprocessing.pyClaude 结构化分析调用client.beta.messages.parse使用structured-outputs-2025-11-13beta 能力直接以 Pydantic 模型作为输出 schemaprocessing.py。Ground Truth 的数据结构每页输出一个 JSON 文件内容遵循PageAnnotationschemaprocessing.py{ has_text: true, document_type: academic_paper, layout_complexity: multi_column, qa_pairs: [ {question: 论文中提出的方法叫什么, answer: LiteParse}, {question: 实验在多少个数据集上验证, answer: 3 个} ] }字段含义has_text文档页是否包含可读文本document_type文档类型枚举值为academic_paper、form、invoice、newspaper、otherlayout_complexity版面复杂度枚举值为simple、multi_column、complexqa_pairs35 个问题-答案对。分析提示词要求生成有趣、多样、有时具有挑战性的问题因为这些数据将被用于文档解析基准LLM-as-a-judge 评判 QA 回答见 processing.py。输出文件命名规则多页 PDF 按页输出为{文件名}_page_{页码:03d}.json如report_page_001.json单张图片输出为{文件名}.jsonprocessing.py。该命名规则直接决定了后续lp-evaluate的匹配方式。官方预生成数据集README 提到一个已经用该框架生成并评测过的公开数据集可用 Hugging Face CLI 下载hf download run-llama/liteparse-eval-dataset --repo-type dataset --local-dir ./liteparse-eval-dataset下载后可直接配合lp-evaluate使用也可以作为参考示例理解 ground truth JSON 的组织方式。第二步用 lp-evaluate 运行 QA 评测lp-evaluate是评测的核心它让 LLM 基于解析器提取出的文本来回答 ground truth 中的问题再用独立的 LLM 裁判判断答案正确性最终汇总为通过率。基本用法lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider liteparse \ --output ./results/run1参数说明与 evaluation.py 一致参数默认值说明--data-dir必填存放源 PDF 文档的目录--ground-truth-dir必填存放 ground truth JSON 文件的目录--output无结果保存路径生成 JSON HTML 报告--parse-providerliteparse待评测解析器可选pymupdf、pypdf、markitdown、liteparse、pdftotext、pymupdf4llm-text、pymupdf4llm-md、opendataloader--llm-provideranthropic回答问题的 LLM当前仅支持anthropic文档与 Ground Truth 的匹配规则评测前程序会用ground_truth_dir.glob(*.json)找到所有 ground truth 文件然后在数据目录中查找同名不含扩展名的 PDF 源文件进行配对evaluation.py。因此使用lp-process生成数据后务必保持源文档与 ground truth 的文件名基准一致。找不到源文件的 ground truth 会被跳过并打印警告。双模型设计回答者与裁判分离从 evaluation.py 可以看到默认配置回答问题的 LLMclaude-sonnet-4-5-20250929与lp-process默认模型一致负责阅读提取文本并回答问题裁判 LLMclaude-haiku-4-5-20251001独立实例负责评判答案是否语义等价。把回答与裁判分离可以有效避免同一模型既当运动员又当裁判带来的偏差。AnthropicProvider初始化时设置了max_retries100、timeout10000的重试与超时策略anthropic.py在大批量评测时提升稳定性。三份输出文件运行后生成三个结果文件evaluation.pyoutput.json— 聚合结果总文档数、总问题数、整体 LLM 裁判通过率overall_llm_judge_pass_rate、逐文档通过率、解析延迟与 LLM 延迟的统计指标count、total、average、min、max、stddevoutput_detailed.json— 逐文档详细结果包含提取出的完整文本与每个 QA 对的 question/expected_answer/predicted_answer/llm_judge_pass方便排查失败原因evaluation.pyoutput_report.html— 交互式 HTML 报告基于 report.py 生成使用 PyMuPDF 渲染 PDF 页面预览逐文档展示 QA 明细与通过率适合分享给团队审阅。第三步用 lp-benchmark 做性能基准测试lp-benchmark与 QA 评测互补它只测量解析延迟与文本产出不涉及 LLM用于对比各解析器的速度。lp-benchmark ./documents --providers pymupdf liteparse --output ./bench.json以当前仓库源码为准实际参数为benchmark.py参数默认值说明input_dir位置参数—存放 PDF 的目录注意源码为目录而非单文件--providers全部本地解析器待评测解析器列表可选liteparse、pymupdf、pypdf、markitdown、pdftotext、pymupdf4llm-text、pymupdf4llm-md、opendataloader、pdf-inspector--warmup-runs5每个解析器计时前的预热轮数--output无JSON 结果保存路径需要说明README 中记录的示例lp-benchmark document.pdf --providers pymupdf liteparse --runs 20与当前源码存在差异——源码中位置参数是目录而非单文件且参数名为--warmup-runs无--runs预热默认值为 5。若你的安装版本命令行为与此不符请以lp-benchmark --help实际输出为准。评测流程与输出从 benchmark.py 的实现看流程为扫描目录下所有.pdf非递归用pypdf统计每份文档页数对每个解析器执行预热运行默认 5 轮规避冷启动与 JIT/加载开销对每份文档计时提取time.perf_counter记录耗时与提取字符数终端打印对齐表格包含每文档耗时、TOTAL 行、AVG/doc 行以及按页均摊的MS/PAGE行提取失败标记为ERROR聚合行带*提示输出 JSON 包含per_documentseconds、text_length、ms_per_page、total_seconds、avg_seconds、ms_per_page、num_success、num_error等字段。解析器 Providers 全览评测框架通过统一的ParserProvider抽象接口providers/parsers/base.py屏蔽差异每个解析器只需实现extract_text(file_path) - str。各实现位于 providers/parsers/Provider底层库实现要点liteparseLiteParse空间感知文本提取支持 OCR封装在 liteparse.py默认output_formatmarkdownpymupdfPyMuPDFfitz打开文档后逐页get_text()页间以空行连接pymupdf.pypypdfpypdf纯 Python 实现PdfReader逐页extract_text()pypdf.pymarkitdownMarkItDown微软文档转 Markdown 工具返回text_contentmarkitdown.pypdftotextpdftotextpoppler 命令行工具封装pymupdf4llm-text/pymupdf4llm-mdPyMuPDF4LLM分别输出纯文本与 Markdown 两种格式opendataloaderOpenDataLoader PDF数据加载生态的 PDF 提取其中liteparse作为默认提供者其封装类支持丰富的初始化参数liteparse.pyocr_enabled扫描件 OCR 开关、ocr_server_urlHTTP OCR 服务地址缺省回退 Tesseract、ocr_languageOCR 语言默认en、max_pages最大解析页数默认 1000、dpi渲染 DPI默认 150影响 OCR 质量、preserve_very_small_text是否保留极小字号文本。如需接入新解析器只需继承ParserProvider并实现extract_text默认的extract_text_batch提供顺序批处理实现支持原生批处理的提供者可覆写该方法base.py。裁判机制原理提示词与判定逻辑理解评测结果前需要了解两个关键提示词它们定义在 providers/llm/base.py回答提示词QA_PROMPT——要求 LLM 只依据document标签内文本回答问题简洁准确、尽量引用原文若文档不含答案必须回答not founddocument{ocr_text}/document Answer the following question about the document. Be as concise and accurate and possible, pulling from the exact text. If the document does not contain the answer, response with not found. Question: {question}裁判提示词JUDGE_PROMPT——判定两个答案是否语义等价明确给出四条标准措辞不同但语义相同算通过答案可依赖问题上下文预测答案说 not found 时仅在标准答案同样表示信息缺失时才通过。输出格式为pass简短理由/pass或fail简短理由/fail。裁判的通过判定逻辑在 anthropic.py将响应文本小写化后包含pass且不包含fail即判定通过若裁判调用异常或返回空内容则宽容地视为通过return True避免单次裁判故障拖垮整轮评测。端到端评测管线实操将三步串起来即构成完整的评测工作流# 1. 准备环境 export ANTHROPIC_API_KEYsk-ant-... pip install -e ./dataset_eval_utils # 2. 生成 ground truth每页一个 JSON lp-process ./documents --output-dir ./ground_truth # 3. 评测 liteparse 的提取质量 lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider liteparse \ --output ./results/liteparse # 4. 换 pymupdf 做对比 lp-evaluate \ --data-dir ./documents \ --ground-truth-dir ./ground_truth \ --parse-provider pymupdf \ --output ./results/pymupdf # 5. 性能基准对比 lp-benchmark ./documents --providers pymupdf liteparse --output ./bench.json评测的四个阶段对应 evaluation.py 的run_qa_eval提取文本用所选 parser provider 从 PDF 提取文本同时记录解析耗时回答问题LLM 读取提取文本逐题回答 ground truth 中的问题逐题记录延迟裁判判定独立的 LLM 裁判判断预测答案与标准答案是否语义等价汇总按文档与整体计算通过率通过题数 / 总题数。运行lp-evaluate时终端会实时打印每份文档的通过率与平均 LLM 延迟例如QA: LLM judge pass: 82.5% [avg LLM: 3.21s]最后汇总整体通过率与总问题数evaluation.py。结果解读与报告使用聚合 JSONoutput.json中最关键的指标是overall_llm_judge_pass_rate——它衡量解析器提取出的文本能否支撑 LLM 正确回答问题的比例间接反映提取内容的语义完整性。详细 JSON 中的qa_evaluation.qa_pairs记录了每个问题的标准答案、预测答案与判定结果是定位解析缺陷的最佳入口预测答案与标准答案语义接近但被判 fail多为文本顺序错乱导致 LLM 引用出错或裁判判定过严可对照extracted_text字段核实大量问题回答 not found说明文本提取严重缺失如扫描件未开 OCR、表格内容丢失多栏版面通过率显著偏低可尝试切换为liteparse空间感知提取或开启 OCR。HTML 报告output_report.html由 report.py 生成内嵌 PDF 页面预览通过 PyMuPDF 渲染逐文档展示通过率与 QA 明细适合在评审会上直接打开讨论。常见问题与注意事项API Key 缺失所有 LLM 相关命令都需要ANTHROPIC_API_KEY未设置时会直接报错可改用--api-key传入ground truth 与源文档命名不一致lp-evaluate按同名 stem 匹配务必保持report.pdf↔report.json或report_page_001.json的命名约定扫描版 PDFlp-process依赖 LiteParse 的截图能力渲染页面若当前版本未实现会打印Skipping PDF (conversion not implemented)并跳过lp-evaluate侧如需处理扫描件请使用带 OCR 的解析器配置provider 依赖未安装每个解析器后端是独立依赖未安装对应库时lp-benchmark会在初始化阶段捕获异常并将该 provider 标记为ERROR不影响其他 provider 的评测README 与源码的命令差异lp-benchmark请以源码 argparse 定义的参数目录入参、--warmup-runs为准命令前可先执行lp-benchmark --help确认。总结LiteParse 评测工具集提供了一条从数据准备 → 质量评测 → 性能基准的完整评测闭环lp-process用 Claude 视觉能力生成带文档类型、版面复杂度标注的 QA ground truthlp-evaluate通过回答 独立裁判的双 LLM 机制把解析质量量化为通过率lp-benchmark补充延迟维度的对比数据。三者共享统一的ParserProvider抽象新增解析器只需实现一个extract_text方法即可纳入评测。这套框架既可用于 LiteParse 与其他解析器的横向对比也可作为团队内部文档解析回归测试的基础设施。【免费下载链接】liteparseA fast, helpful, and open-source document parser项目地址: https://gitcode.com/GitHub_Trending/li/liteparse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考