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.
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."
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.
A look at Sparrow's Standard tier, powered by Ministral 3 14B via MLX-VLM.
In this video I run a document through Sparrow's UI (sparrow.katanaml.io/process) using the Standard model — Ministral 14B. It extracts structured line-item data into clean, valid JSON in about 22 seconds, no schema drift, no formatting issues.
Ministral 14B is the default model behind Sparrow's Standard tier — built for fast, everyday document extraction with strong accuracy, running fully local with no cloud dependencies.
Follow-up to the Mistral OCR + Sparrow integration video. Mistral released OCR 4 — the latest model with improved accuracy, native bounding box extraction, and structural block labels. One model string change in Sparrow to pick it up.
In this video, extracting a long financial statement table into structured JSON using Mistral OCR 4 + Mistral Small 4.
Sparrow is open source and local-first by design — documents never leave your infrastructure unless you choose the cloud backend.
In this video I build a local agentic AI pipeline that analyzes a bond portfolio and makes sell/hold decisions based on risk analysis and live web search data.
The agent runs four steps: load portfolio positions from JSON, classify each position as low/medium/high risk, search the web per position via Tavily API for historical performance and current outlook, then make a final sell/hold decision with reasoning — all powered by Gemma 4 31B running locally on Apple Silicon via mlx-vlm. No data leaves your machine.
Integrated Mistral OCR as a new cloud inference backend into Sparrow, an open-source document extraction platform. This gives Sparrow a full cloud option alongside its existing local backends (MLX, vLLM), so users without GPU infrastructure can still run enterprise-grade document extraction.
Pipeline: Mistral OCR converts the document to structured HTML, then Mistral Small extracts and transforms the data into JSON based on a defined schema with field-level hints.
In this video, extracting a bonds portfolio table with hint-driven rules:
Instrument name normalization (extracting issuer brand from full fund names)
European number formatting (period as thousands separator, comma as decimal)
Percentage formatting with sign preservation
Derived risk classification computed from profit/loss percentage
Same Sparrow API, same schema and hint format as local backends — just switch the backend flag to run on Mistral Cloud instead of MLX or vLLM.
Sparrow is open source and local-first by design — documents never leave your infrastructure unless you choose the cloud backend.
