GraphRAG without building the graph yourself

What conventional GraphRAG costs you

The pipeline is: ingest the corpus, run entity and relationship extraction with an LLM, resolve entities, build community summaries, load it into a graph store, and keep all of that current as documents change.

Extraction is the expensive part, and it is per-document, so cost scales with corpus size rather than with usage. Then you operate a graph database alongside your vector store, with the consistency questions that implies.

For a private corpus that investment is often justified. For the open web it is not remotely feasible.

The signals already exist

A search engine cannot build an index without computing structure. The link graph is needed for authority. Near-duplicate clustering is needed for deduplication. Entity and topic extraction is needed for classification. Embeddings are needed for semantic retrieval.

Every one of those is a graph edge, and almost every search engine throws them away and returns a ranked list. Publishing them instead is nearly free — the computation already happened.

The six operations, and what each replaces

related(id, hops) returns a bounded neighbourhood — follow the thread in one call rather than a search per hop.

corroborate(id) returns the story's independent-source view — verification without manual cross-searching.

authorities(topic) returns the passages a field treats as foundational — triage before reading.

dossier(entity) returns mentions, sources and co-mentioned entities — roughly ten searches and a merge, in one call.

path(a, b) returns the shortest edge chain between two passages — the investigative primitive, and the one that genuinely cannot be reconstructed from ranked lists.

assemble_context(q, budget) runs the whole retrieval loop server-side and returns a packed set with a reason per passage.

assemble_context: the loop as one call

Most RAG implementations contain the same sequence: retrieve, deduplicate, assess trust, rerank, truncate to budget. It is written once, rarely revisited, and it is where retrieval quality is actually decided.

Running it server-side lets the engine use signals your application does not have — corroboration counts across rejected duplicates, story clusters, graph centrality. And because every returned item carries the reason it was included, the selection is explainable rather than opaque.

curl -H "x-api-key: $UNLOB_API_KEY" \
  "https://api.unlob.com/assemble_context?q=who+funds+independent+web+indexes&budget=4000"

# Returns: story-collapsed, corroboration-ranked passages packed to
# 4,000 tokens, each with the reason it was included.

When you still want conventional GraphRAG

When the corpus is private. A coverage graph over the open web says nothing about your internal documentation, your support tickets or your contracts, and no amount of web retrieval substitutes for that.

When you need a schema you control. If your questions depend on domain-specific relationship types, extraction against your own ontology is the only way to get them.

The two compose well: a coverage graph for the world, a private graph for your own material.