Frontier AI and Agentic Internals

GraphRAG Internals: Structuring Neo4j Knowledge Graphs

Napísal Kinetikatech Operations Team · Aktualizované 2026-10-23

Vector search finds similar text. It does not answer questions that require connecting facts across documents. GraphRAG builds a knowledge graph from the corpus, detects communities, and summarizes them so a language model can reason over relationships instead of chunks. This guide structures a Neo4j graph for retrieval, from extraction to community summaries to query time.

Kľúčové body

Extract entities and relationships with a schema. Unconstrained extraction produces a noisy graph that retrieves worse than vectors.
Deduplicate aggressively. The same person or concept appears under many surface forms; merge them before community detection.
Detect communities with Leiden. Communities become the unit of summarization and the boundary for multi-hop questions.
Summarize each community. A short summary per community gives the model a high-level map before it drills into entities.
Store provenance. Every entity and edge must link back to source chunks so answers can be cited and audited.
Query with both paths. Combine graph traversal for relationship questions and vector search for topical questions.
Rebuild incrementally. Full rebuilds are expensive; track document versions and update only affected subgraphs.
Evaluate against a held-out question set. GraphRAG gains are easy to overstate; measure answer accuracy, not just retrieval recall.

Architecture

The pipeline has four stages. Extraction turns chunks into entities and edges. Deduplication merges surface forms. Community detection groups related entities. Summarization produces a navigable map. At query time, the system selects communities, expands to entities, and retrieves source chunks for the final answer.

Production configuration

Create entity and relationship schema cypher

CREATE CONSTRAINT entity_name IF NOT EXISTS FOR (e:Entity) REQUIRE e.name IS UNIQUE;
CREATE INDEX entity_type IF NOT EXISTS FOR (e:Entity) ON (e.type);

// Link an entity to its source chunk for provenance
MATCH (c:Chunk {id: $chunk_id})
MERGE (e:Entity {name: $name, type: $type})
MERGE (e)-[:MENTIONED_IN]->(c)

Community summary generation python

from graphdatascience import GraphDataScience
gds = GraphDataScience(driver)
G, _ = gds.graph.project('entities', 'Entity', 'RELATED_TO')
gds.leiden.write(G, writeProperty='community')

for cid in communities:
    members = fetch_entities(cid)
    summary = llm.summarize(members, max_tokens=200)
    db.run('MERGE (c:Community {id: $id}) SET c.summary = $s', id=cid, s=summary)

Hybrid query combining graph and vector python

def answer(question):
    communities = vector_search(question, index='community_summaries', k=3)
    entities = expand_communities(communities, depth=2)
    chunks = fetch_chunks(entities) + vector_search(question, index='chunks', k=5)
    chunks = dedupe(chunks)
    return llm.answer(question, context=chunks, communities=communities)

Edge cases from production

Extraction hallucinates relationships; validate edges against source text before writing them.
Community summaries go stale when the corpus changes; version them and rebuild on document updates.
Multi-hop questions exceed context limits; cap expansion depth and summarize intermediate nodes.
Entity resolution fails on abbreviations and acronyms; maintain an alias table seeded from the corpus.

Často kladené otázky

When is GraphRAG worth the cost?

When questions require connecting facts across documents, such as root cause analysis or policy comparison. For single-fact lookup, vector search is cheaper and sufficient.

How big should the graph be?

Start with a few thousand entities and measure retrieval quality before scaling; larger graphs need better deduplication and indexing.

Can I use an open source model for extraction?

Yes, smaller models work for extraction with a strict schema and validation; reserve frontier models for summarization and answering.

How do I keep the graph current?

Track document hashes and re-extract only changed documents, then recompute affected communities.

What is the main failure mode?

Noisy extraction produces a graph that retrieves worse than plain vectors; schema discipline and deduplication matter more than model size.

Ako Kinetikatech pomáha s frontier ai and agentic internals

To je to, čo robíme každý deň: Retrieval graphs, model serving, and agent control loops built for production, not demos. Naša služba Správa serverov a Údržba webových stránok pokrýva všetko od hodnotenia po implementáciu, monitoring 24/7 a núdzovú reakciu do 30 minút.

Pozrite sa s inžinierom