contextgem vs PageIndex
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 — Vectorless, reasoning-based RAG — builds a hierarchical tree index from long documents so an LLM retrieves by relevance instead of similarity. No chunking, no embeddings, no vector DB.
Both reject chunk-and-embed for long documents, then diverge on what replaces it. PageIndex builds a hierarchical tree the model navigates to reach the right section; ContextGem skips retrieval entirely and sends the whole document into a long context window. Navigate versus extract in place.
| contextgem | PageIndex | |
|---|---|---|
| Stars | 2.0k | 35k |
| Forks | 183 | 3.1k |
| Language | Python | Python |
| License | Apache-2.0 | MIT |
| Last activity | 11 days ago | 2 days ago |
| Topics | ocr, data | rag |
| Curated connections | 7 | 6 |
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.
PageIndex — the curator's take
Reach for it on long, structured professional documents (contracts, filings, manuals) where similarity search returns 'similar but irrelevant' passages and you need reasoning over document structure. Tradeoff is per-query LLM reasoning cost/latency versus a cheap vector lookup, and you still need clean parsed text upstream. If your corpus is huge, homogeneous and similarity is good enough, a vector DB (chroma, supavec) is cheaper.