Architecture

GraphRAG separates what it knows about tenants from what a tenant knows.

Two planes

Isolation is enforced twice: the application only ever addresses a tenant’s own database, and each tenant has its own database credentials so a scoping bug cannot cross the boundary at the storage layer either.

Ingestion pipeline

When you upload a document, a background worker runs it through:

1. Parse — the file is converted to text locally (no third-party upload). PDF, Office, HTML, Markdown and more are supported.
2. Chunk — the text is split into overlapping passages.
3. Embed — each chunk gets a vector embedding.
4. Extract — a language model reads each chunk and emits entities and relationships, constrained by the tenant’s ontology. Every relationship keeps the chunk that stated it, so graph facts remain citable.
5. Canonicalise & link — entities are de-duplicated and linked; MENTIONS edges connect chunks to entities and RELATES_TO edges connect entities to each other.

Ingestion is idempotent (re-uploading identical content does not duplicate it) and crash-recoverable (a job that fails part-way is retried or cleanly marked terminal).

Retrieval pipeline

A query flows through:

1. Hybrid retrieval — semantic vector search and keyword full-text search run in parallel and are fused (reciprocal-rank fusion).
2. Re-rank — a cross-encoder re-orders the candidates by relevance and trims to your k.
3. Graph expansion (optional, off by default) — from the entities in the retrieved chunks, the graph can recover related evidence and merge it back into the same budget.
4. Synthesis — the passages are handed to a language model, which answers with citations. Citations are validated against the passages actually supplied.

/v1/search returns the retrieved passages (and the subgraph); /v1/answer adds the synthesized, cited answer. See the Search & Answer reference.