The README and document-extractor-spec.md both make an honest-but-unverified claim: fastdocparse's text-first pipeline (PyMuPDF + local OCR, no GPU) should be competitive with vision-LLM extraction tools like Sparrow on clean-to-moderate documents, while trading off accuracy on messy/handwritten/complex-table documents.
That claim has never been benchmarked. Per the spec ("Phase 6 — Benchmark, package, publish"): "This must be validated with real benchmarks before it's claimed publicly."
What this issue is asking for
A small, reproducible benchmark:
- A handful of representative documents across the stated sweet spot (clean invoices, forms) and the stated weak spot (handwritten forms, complex multi-column tables) — synthetic or from a public dataset with a permissive license, not anything sensitive/real.
- Run fastdocparse's extraction against each, using both a local Ollama model and a hosted model (to separate "model quality" from "pipeline design" as variables).
- If feasible, run the same documents through one open vision-LLM baseline for comparison (doesn't need to be Sparrow specifically — any reasonable vision-LLM extraction approach works as a comparison point).
- Report accuracy (field-level correctness) and, ideally, latency/cost, honestly — including where fastdocparse loses.
This is a bigger, more open-ended task than the other issues here — happy to discuss approach/scope in the comments before you start, and it's fine to submit partial results (e.g. just the clean-document benchmark) as a first PR.
Where results go
Update the "honest edge" section of document-extractor-spec.md and/or README.md with real numbers once available.
The README and document-extractor-spec.md both make an honest-but-unverified claim: fastdocparse's text-first pipeline (PyMuPDF + local OCR, no GPU) should be competitive with vision-LLM extraction tools like Sparrow on clean-to-moderate documents, while trading off accuracy on messy/handwritten/complex-table documents.
That claim has never been benchmarked. Per the spec ("Phase 6 — Benchmark, package, publish"): "This must be validated with real benchmarks before it's claimed publicly."
What this issue is asking for
A small, reproducible benchmark:
This is a bigger, more open-ended task than the other issues here — happy to discuss approach/scope in the comments before you start, and it's fine to submit partial results (e.g. just the clean-document benchmark) as a first PR.
Where results go
Update the "honest edge" section of
document-extractor-spec.mdand/orREADME.mdwith real numbers once available.