Extract data from MRI reports privately with Sparrow

Many organizations won't send medical reports to a public cloud API, yet the results still get retyped by hand. In this video, Sparrow turns an MRI lumbar spine report into structured data: disc levels with grades, measurements as numbers, and the full impression.

Sparrow is open source and runs on infrastructure you control, on your own machines or a private cloud GPU, so patient data stays inside your environment. This video uses the online version with a synthetic report

Extract data from drilling reports locally with Sparrow

Drilling reports arrive as PDFs and get retyped by hand.

In this demo, Sparrow turns a daily drilling report into structured data: header fields, casing, directional survey, and the full time log. Sparrow is open source and runs on your own hardware, so your documents never leave your network. This demo uses the online version.

 

Sparrow OCR Table Query with Field Filtering

Sparrow now supports field filtering in table mode: instead of extracting every column, you query only the fields you need and Sparrow maps and type-coerces just those from the OCR'd table. In this video I run it on a financial table, using dots.ocr for table detection and a schema that pulls only instrument name, quantity, and valuation out of an eight-column table.

 

Testing Qwen3.8-27B on a Hard Pivot Table (No Column-Shift Errors)

Testing Qwen3.8-27B on a hard document extraction case: an insurance pivot table with row/column headers and aggregated values instead of a flat list. Same table from two prior tests, same generic "*" query, no schema. Result: no column-shift errors, every value landed in its correct column.

 

Table Only Extraction Mode on Large Financial Statement

In this video I test Sparrow table only extraction mode on a large financial statement table. I use a 6 month property management sample data, with 51 rows and 7 columns, including section headers, blank spacer rows and multiple levels of subtotals.

Table only mode uses dots.ocr for table structure detection, combined with Sparrow custom processing logic on top, to produce a JSON array, with column headers mapped as keys. Section headers like INCOME and OPERATING EXPENSES are extracted too, with empty values, this way row order and table structure stay intact.

I go through the extraction result and compare it against the source table.

Bigger Isn't Always Better: Gemma 31B vs Ministral 14B on a Pivot Table

More parameters doesn't automatically mean better extraction. 

Same insurance pivot table as the last video, same generic "*" query, no schema, but this time run through Sparrow's Advanced mode, backed by Gemma 4 31B Dense, instead of Standard mode Ministral 14B.

Result: Gemma 4 31B, despite being over twice the size, was less accurate on this pivot table than Ministral 14B was. It hallucinated on column values — assigning null to cells that had real values, then shifting the actual value into the next column instead. A column-alignment failure Ministral 14B didn't have.

The takeaway: model size isn't a proxy for fit. Structured extraction on dense tabular layouts seems to favor whatever model was better tuned for structure-following, not the model with more parameters. Worth testing both tiers against your actual documents before assuming "Advanced" means "more accurate."

Can an LLM Read a Pivot Table? Sparrow + Ministral 14B

Pivot tables are a genuinely hard case for LLM-based extraction — row/column headers, merged cells, and aggregated values instead of a flat list. In this video I test whether Ministral 14B, running in Sparrow's Standard tier, can handle one.

The document: an insurance pivot table. The query: a generic "*", no predefined schema. Sparrow's UI (sparrow.katanaml.io/process) sends it to Ministral 14B running locally via MLX-VLM, which has to infer the structure itself and return clean, structured JSON.

No schema tuning, no hints file — just upload and extract.

Built with Sparrow — open-source document intelligence platform.