chunkr vs morphik-core
Document intelligence API in Rust: layout analysis, OCR with bounding boxes, and semantic chunking that turn PDFs, PPTs and Word docs into RAG-ready structured chunks. — versus — Multimodal retrieval engine for visually rich documents: ingestion, visual-first search over charts, tables and diagrams, knowledge graphs and cache-augmented generation — one engine, not a pipeline.
Two answers to visually rich documents: chunkr parses them into RAG-ready chunks for YOUR retrieval stack; Morphik owns retrieval end-to-end so the parse never leaves the engine.
| chunkr | morphik-core | |
|---|---|---|
| Stars | 4.1k | 3.7k |
| Forks | 269 | 322 |
| Language | Rust | Python |
| License | AGPL-3.0 | NOASSERTION |
| Last activity | 4 months ago | 17 days ago |
| Topics | ocr, rag | rag |
| Curated connections | 8 | 2 |
chunkr — the curator's take
The RAG-ingestion specialist: where OCR tools stop at text, Chunkr does layout analysis and SEMANTIC chunking — the chunks arrive respecting document structure, with bounding boxes for citation-grounding. Self-hosted via Docker Compose. Read the split carefully though: the AGPL open-source version runs community models while the paid cloud runs proprietary ones — the README says plainly the accuracy differs; benchmark the OSS tier on YOUR documents before committing. Also ~3 months quiet at review time, and AGPL matters if you embed.
morphik-core — the curator's take
Built on the observation that RAG dies on visual documents — charts become word soup — so retrieval is visual-first end to end, and the whole extract-embed-store-retrieve chain is one system instead of duct tape. When NOT: license is NOASSERTION, and the company has pivoted to nursing-home back-office AI with Core as the engine underneath — gauge maintenance commitment before betting your stack; for text-only corpora a plain vector store is simpler and cheaper.