contextgem vs receipt-ocr
Declarative LLM extraction from documents: describe Aspects and Concepts in plain language, get structured values back with paragraph- or sentence-level references and built-in justifications. — versus — Receipt-to-JSON in one pip install: CLI, Python API and FastAPI service that send a receipt image to any OpenAI-compatible model and return merchant, totals and line items, plus a Tesseract module.
Same idea — describe the fields, get structured values back. ContextGem is a general declarative extraction framework with paragraph-level references and justifications; receipt-ocr hardcodes one domain so there is nothing to design before it works.
| contextgem | receipt-ocr | |
|---|---|---|
| Stars | 2.0k | 636 |
| Forks | 184 | 79 |
| Language | Python | Python |
| License | Apache-2.0 | MIT |
| Last activity | 18 days ago | 28 days ago |
| Topics | ocr, data | ocr, data |
| Curated connections | 8 | 4 |
contextgem — the curator's take
Its thesis is explicitly anti-RAG: stop chunking and retrieving, put the whole document in a long context window and extract in place. You declare Aspects — the sections or themes worth pulling — and Concepts — the entities, booleans, numbers, ratings and JSON objects inside them — and the framework writes the prompts, builds the validation models, and returns every item with reference_paragraphs, reference_sentences and a justification. That provenance is the point: it makes contract and filing review defensible rather than merely plausible. Two limits it states about itself: no cross-document querying or corpus-wide retrieval, so reach for a real RAG framework there; and its detailed instruction style wants a model at gpt-4o-mini level or better, so 8B local models will struggle even though LiteLLM happily points it at Ollama.
receipt-ocr — the curator's take
Narrow on purpose, and that is the value — one schema, one document type, a working CLI, Docker service and FastAPI app on day one, and any OpenAI-compatible endpoint (OpenAI, Gemini, Groq) behind a single env var. Do not mistake it for a document-intelligence stack: no layout model, no bounding boxes, no batch pipeline, and accuracy is entirely whatever VLM you point it at. Good as a reference implementation or the expenses corner of a larger app; wrong choice for mixed document types or on-prem throughput.