JDF
JSON document standard

# deterministic, offline — same doc → byte-identical chunks & stable hashes
$ jdf chunk report.jdf
  {"id":"p3e7","text":"…","path":["Report","Pricing"],"page":3,"types":["text","table"],"tokens":142,"hash":"ab12cd"}

# local embeddings; Ollama auto-starts via Docker if needed; skips unchanged chunks
$ jdf embed report.jdf --incremental   # → report.embeddings.json

Measured, not claimed — the benchmark

Twenty-four multi-page operations reports, authored as JDF and printed to PDF by a real browser, so both pipelines see identical content. 192 questions with known answers (120 table cells, 48 prose facts, 24 list items). The PDF side runs the usual Python parsers (PyMuPDF, pdfplumber, pypdf, poppler) and LangChain-style fixed chunking at two sizes; the JDF side runs jdf chunk. A third pipeline answers the question everyone with a PDF archive has: the same PDFs put through jdf convert (tables rebuilt as real table elements, headings detected) and then jdf chunk. Same local embedding models, same BM25, same hit rule for both. Every number below is regenerated by python rag_bench.py / python cost_bench.py and checked by --verify. Method and full tables →

BM25 — lexical, offline, deterministic

Embeddings — nomic-embed-text

Embeddings — BAAI/bge-small-en-v1.5

Embeddings — sentence-transformers/all-MiniLM-L6-v2

Embeddings — BAAI/bge-base-en-v1.5

R@1k tokens = the answer was inside the first 1,000 tokens of retrieved context (chunk-size neutral: a 2,000-character PDF chunk “hits” more often at top-1 simply because it is a quarter of the document, and then costs 3× the tokens). Hit = right document and the chunk contains both the answer and its row/subject key. 24 documents, 120 pages, 192 questions (120 table cells, 48 prose, 24 list). Embeddings run locally (nomic-embed-text via Ollama 0.32.6; BAAI/bge-small-en-v1.5 via sentence-transformers 6.0.1; sentence-transformers/all-MiniLM-L6-v2 via sentence-transformers 6.0.1; BAAI/bge-base-en-v1.5 via sentence-transformers 6.0.1). JDF chunk hashes verified; editing one paragraph re-embeds 1 of 192 chunks. Apple M5, 2026-09-13.

RAG cost — 1,000 PDF files vs 1,000 JDF files

Same pipeline, only the input format differs: chunks → embeddings → vector store → top-5 context → LLM. Tokens counted from the chunks each pipeline produces, dollars from published prices; the benchmark never calls a paid API.

1,000 files per format = the 24-document corpus cycled. Tokens are counted from the chunks each pipeline produces (ceil(chars/4), both sides); embedding time is measured throughput on Apple M5 (2026-09-13) applied to the totals. Prices from bench/prices.json (as of 2026-09-12); edit it for your provider — the benchmark never calls a paid API. The PDF column is the PDF pipeline that scored best in the accuracy run. Scaling: figures are measured at 1,000 documents and 1,000,000 queries; anything at other volumes (10,000 documents, 10M queries) is a linear estimate, not a measurement — index and re-index costs scale with documents, query cost scales with questions asked. Re-index: JDF re-embeds only chunks whose content hash changed (jdf embed --incremental); a PDF has no chunk identity, so an edit means re-chunking and re-embedding the whole document.

Synthetic corpus by design — a retrieval benchmark needs ground truth for every question, which public PDF corpora don't ship. The generator, every document, every question and every retrieved rank are in bench/. Run it on your own corpus and open an issue with the numbers.