Skip to main content
Eric Kouassi

01/Retrieval · Knowledge Graphs · Agentsproduction

GraphRAG Platform

Humanloop, 2023 to 2025

A production retrieval platform whose index is a knowledge graph, so answers can follow relationships between entities across multiple reasoning steps.

Architecture diagram for GraphRAG Platform: sources feed a pipeline of Ingest, Extract, Graph, Retrieve, Synthesise, producing a grounded answer.

Problem

Vector similarity alone loses the structure connecting facts. Questions spanning several related entities return fragments that look relevant and reason badly, and no amount of reranking recovers a relationship the index never stored.

Result

Supported more than 1,000 active users, with multi-agent orchestration reducing manual analytical workload by roughly half.

Pipeline stages

  1. 01

    Ingest

    Documents are chunked and queued for extraction. Nothing is searchable until that pass has run over it, which is the bill the rest of the pipeline pays before it can do anything.

  2. 02

    Extract

    A model reads each chunk against a fixed set of entity and relation types. What does not fit the schema is rejected, because a graph that accepts anything cannot be queried.

  3. 03

    Graph

    Entities are merged into the graph, so a thing named in three documents becomes one node with three sources and the edges between them survive the chunk boundary.

  4. 04

    Retrieve

    Embedding search picks the entry nodes and the traversal expands from there. Similarity decides where to start; the graph decides what is connected to it.

  5. 05

    Synthesise

    The answer is generated over the retrieved subgraph and carries the path it walked, so a reader can check the reasoning against the entities it passed through.

Decisions

  • The index is a knowledge graph, not a vector store

    The alternative was to keep the vector index and work around it: bigger chunks, harder reranking, a second retrieval pass. All three spend compute trying to reconstruct structure that was discarded at index time, and none of them get it back reliably. Storing the relationships means retrieval follows them rather than infers them.

    Cost
    Ingestion is far slower and more expensive. Every document pays for entity extraction before it is queryable at all, which is a great deal more work than embedding it.

  • Extraction is a model constrained by a fixed schema

    Open-ended extraction produces a graph where the same relationship has been named four ways, which is unqueryable. A declared set of types means a chunk either fits or is rejected, and the schema is the thing that stays stable while the corpus grows.

  • Retrieval starts with embeddings and continues as traversal

    Translating a question straight into a graph query puts the whole retrieval on the model getting the query right. Seeding with embeddings keeps the entry point robust to how the question was phrased, and leaves the graph to do the part it is good at.

Stack

  • Python
  • FastAPI
  • Neo4j
  • LangChain
  • Vector databases
All systems