Graphify: 71.5x Token Compression by Honestly Labeling "What I Guessed" vs. "What I Read"

> Subject: Graphify-Labs/graphify > Fetched: 2026-10-20 | Stars that day: 906 > License: MIT | Language: Python

A Number That Raises a Question

71.5x.

That is Graphify's reported token compression ratio. A 2,000-line repository fed directly to an LLM costs roughly 50,000 tokens; after Graphify converts it into a knowledge graph, the LLM can understand the whole repository's structure with about 700 tokens.

The 71.5x ratio doesn't come from a better embedding model, a larger context window, or smarter chunking. It comes from an old-school approach: parse the code into a graph, then feed only the graph to the LLM.

But what makes the project genuinely interesting isn't the compression ratio — it's how honestly it labels "information certainty."

Three Confidence Levels: EXTRACTED / INFERRED / AMBIGUOUS

Most code-understanding tools output a binary answer: either "I understood this code" or "I didn't." Graphify tags every edge with one of three labels:

• EXTRACTED: Extracted directly from source. E.g., function A calls function B — read straight from the AST, no ambiguity.
• INFERRED: Deduced from code patterns. E.g., A calls B, B calls C, so Graphify infers A indirectly depends on C — an inference, not a direct read.
• AMBIGUOUS: Undeterminable. E.g., a dynamically dispatched call whose target is only known at runtime — Graphify marks it AMBIGUOUS rather than guessing.

This three-level labeling is Graphify's most important design decision. It tells the downstream LLM which information is fact, which is inference, and which is guesswork.

The problem with most RAG systems isn't "failed retrieval" — it's "retrieved, but without telling you whether it's true." Given a code snippet, an LLM doesn't know if it's complete or truncated, whether call relationships are real or inferred, whether variable types are certain or guessed. The result is hallucination — not because the LLM fabricates, but because it treats all input as fact.

Graphify's three-level labeling reduces hallucination at the source. Seeing EXTRACTED, the LLM knows it's fact; INFERRED, an inference; AMBIGUOUS, uncertainty. Uncertainty is explicitly propagated to downstream consumers.

AST Instead of a Vector Database

No embeddings, no vector store, no similarity search. Graphify uses ASTs (abstract syntax trees).

Workflow:

1. Parse: tree-sitter generates the AST. Supports Python, JavaScript, TypeScript, Go, Rust, Java, and 20+ languages total. 2. Extract: pull nodes (functions, classes, variables) and edges (calls, inheritance, imports, references) from the AST, each edge labeled EXTRACTED / INFERRED / AMBIGUOUS. 3. Serialize: serialize the graph into a compact text format for the LLM.

Why is this token-efficient? Because AST extraction captures structure, not text. A 100-line function may reduce to 3–5 lines of structural info: name, parameters, return type, calls. The other 95 lines are implementation detail, unnecessary for understanding "what this function does."

Vector databases aim to find "the most similar snippets," but "most similar" isn't "most necessary." A 50-line snippet may contain mostly irrelevant detail, while Graphify's 3-line structure may already answer the question.

Multimodal: Not Just Code

Graphify also parses:

• PDFs: text and figure structure
• Markdown: heading hierarchy and link relations
• Screenshots: UI components and interaction flows via VLM
• Architecture diagrams: Mermaid, PlantUML, draw.io

All inputs are unified into one graph structure. A repository's code, docs, diagrams, and UI screenshots merge into a single knowledge graph whose nodes and edges all carry EXTRACTED / INFERRED / AMBIGUOUS labels.

This addresses a real problem: repositories aren't understood through code alone. A function's name and calls live in code, its business meaning in the README, its UI behavior in screenshots, its deployment relations in architecture diagrams. Code-only analysis loses context.

SHA256 Cache: Incremental Updates

Graphify hashes each file with SHA256 and re-parses only changed files:

• First parse of a 2,000-line repo: ~30 seconds
• Re-parse after changing one file: ~2 seconds (only that file)
• The rest of the graph loads from cache

This makes Graphify a fit for continuous integration: after each commit, only an incremental graph update is needed, unlike most CI code-analysis steps that re-parse the whole repo regardless of whether one line or a thousand changed.

"Honesty" as a Design Principle

Graphify's philosophy in one sentence: be honest about how you know what you know.

Every edge declares its provenance — extracted from the AST, inferred, or undeterminable. That honesty lets consumers (LLMs or humans) judge better:

• EXTRACTED call relationships can be relied on
• INFERRED indirect dependencies need verification
• AMBIGUOUS dynamic dispatch needs runtime confirmation

Most code tools blur these together as "extracted from code" — but extraction and inference are different epistemic acts and shouldn't be conflated.

The distinction applies beyond code understanding. Any AI system handling uncertain information should label "how I know":

• Are knowledge-graph edges facts or inferences?
• Are retrieved documents originals or summaries?
• Is the model's answer evidence-based or parametric-memory-based?

Information provenance and certainty should travel with the information itself. That's Graphify's most important design lesson.

Fundamental Difference from RAG

Graphify isn't "better RAG" — it's a different route:

| Dimension | RAG | Graphify | |------|-----|----------| | Input | Text snippets | Structured graph | | Retrieval | Similarity | Graph traversal | | Certainty | Unlabeled | Three-level labels | | Token efficiency | Low (irrelevant text included) | High (structure only) | | Incremental updates | Hard (re-embedding) | Easy (SHA256 comparison) | | Multimodal | Unified embeddings needed | Unified graph structure |

RAG's strength is semantic matching — finding documents "saying similar things." Graphify's strength is structural precision — finding functions "with call relationships." They're complementary, not substitutes. Use Graphify for "what does this function do," RAG for "has anyone discussed this."

Use Cases

Best fits:

• Code review: understand a PR's blast radius, which functions are indirectly affected
• Architecture onboarding: new engineers grasp repo structure without reading everything
• Refactoring decisions: find all callers of a function, including indirect ones
• Security audits: trace data from input to output

Poor fits:

• "What's the concrete implementation?" — Graphify extracts structure, not implementation detail
• "Is there similar code?" — RAG territory
• "Why does this bug happen?" — needs runtime information

"Karpathy's /raw Folder"

The README cites an interesting reference: Andrej Karpathy maintains a /raw folder in the nanogpt repository holding raw, unprocessed code-understanding data — cited as one inspiration.

Karpathy's /raw is a gesture of transparency: no processing, no interpretation — raw data, look for yourself. Graphify inherits the stance but adds structure — not dumping raw code on you, but extracting its structure while telling you "this I extracted, this I inferred."

Transparency isn't "showing you the raw data" — it's "telling you what I did."

---

GitHub: https://github.com/Graphify-Labs/graphify License: MIT Docs: graphify-labs.github.io/graphify