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.

Sparrow Standard Mode: Document Extraction with Ministral 14B

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.

Mistral OCR 4 + Sparrow: Document to JSON

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.

Building an AI Agent That Searches the Web and Makes Investment Decisions

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.

All steps orchestrated with Prefect.

🔗 GitHub: https://github.com/katanaml/sparrow
🌐 Live: https://sparrow.katanaml.io
📧 Enterprise inquiries: abaranovskis@redsamuraiconsulting.com