Graph (GraphRAG)

CiteNexus can build an entity graph over your corpus and retrieve through it — but the graph is navigation over evidence, never a citation itself. Every graph hit resolves back down to a cited Evidence Unit before an answer is generated.

Enable it

Declare the graph signal. ingest() only marks the graph dirty — co-mention edges are corpus-wide, so a per-ingest full rebuild would not scale. The rebuild is lazy on the read path: the first graph retrieval after an ingest brings the index up to date before it loads, so ask() always sees a graph consistent with every committed ingest.

Python facade — Go and JavaScript have no equivalent

CiteNexus and the ingest / ask /evaluate / reconcile / delete verbs, plus the config layer they read, are the Python facade. The Go and JavaScript packages ship the deterministic core instead — the faithfulness gate, tokenizer, chunker, RRF and Result, at conformance parity — and enter through Ask / ask over an in-memory corpus (quickstart). The Python samples on this page have no port tab because there is nothing to put in it.

rag = CiteNexus("./citenexus-data", embedder=..., generator=...,
                signals=["embedding", "text", "graph"])
rag.ingest("annual-report.pdf")
response = rag.ask("How is the CFO connected to the audit committee?")

How the graph is built

• Co-mention (default, deterministic). Nodes and edges are derived from tokens that co-occur across Evidence Units — no model needed, fully reproducible.
• LLM-distilled (when injected). Provide a graph distiller (via from_config, config.graph_distill) and LLMGraphDistiller extracts grounded entities and typed relations, each carrying an eu_ref back to its source unit; it degrades to the co-mention graph if distillation fails.

GraphRetriever matches query tokens to node labels and returns the nodes’ underlying Evidence Units as candidates (retrieval signal graph), which then go through the same fusion → grounding path as every other retriever. Import the pieces from citenexus.graph (GraphStore, GraphRetriever, LLMGraphDistiller).

What's implemented — and what isn't yet

The grounded graph retrieval path works end-to-end. Two commonly-expected GraphRAG features are not implemented yet:

• Community detection (Leiden/Louvain). config.graph.community_algorithm exists but has no implementation; the community signal currently reuses the same graph retriever.
• Multi-hop traversal. Edges are built and stored but never walked by GraphRetriever — it matches query tokens against node.label, returns that node’s eu_refs, and never touches index.edges. Retrieval is a single node-label → Evidence-Unit lookup. config.graph.max_hops is not dead, but it does not govern this path: from_config reads it as the hop cap of the deep-ask agentic loop (strategy="deep").

Declare graph for grounded entity retrieval today; treat community summarization and hop-expansion as roadmap.