Glossary

A single "thing" the graph knows about: a person, product, system, error code, organisation, or anything else your content discusses. The Graph Extraction Model finds entities in the text pieces (chunks) during upload. Each entity is stored as a graph node. It is also stored in the vector database, so a search can find it the same way it finds a chunk.

A directed connection between two entities. It is found in the same step as the entities. LOCAL search follows relationships outward from its starting entities.

The graph-theory names for entity and relationship. The UI and this documentation use them as alternative words.

A piece of a document’s text, stored for search, as in a RAG Topic. In a GraphRAG Topic a chunk has a second job. Entities and relationships remember which chunks they came from. This is called provenance. It makes it possible to delete a document without deleting entities that other documents still need.

The record of which documents an entity or relationship was found in. When you delete a document, only that document is removed from the record. An entity disappears only when no document is left that mentions it. So deleting a document often touches many entities but removes few.

A group of closely connected entities. The Topic finds communities by regularly grouping the whole graph. Every community with more than one entity gets a written summary, its community report. GLOBAL search answers from these reports, not from single chunks. See how a document becomes graph for when this runs.

How finely the graph is split into communities. Higher: more and smaller communities, with more detailed summaries but more model calls. Lower: fewer and larger communities. 1.0 is the standard value. The useful range is about 0.5 to 2.0. The grouping method (called Leiden) is not a choice. Every GraphRAG Topic uses it.

Rebuilding the communities and all community reports. It runs on the Refresh Cycle you set in step 3. You can also start it by hand on the Actions tab (see Configuration and functions). Until it has run, GLOBAL answers do not know about new or deleted documents. LOCAL answers do not depend on it.

The model that decides, for every chat message, how it is answered. It chooses between LOCAL, GLOBAL, HYBRID, PATH, DIRECT and ATTACHMENT. Users do not choose. See Retrieval strategies.

How sure the router must be before its choice between the searching modes is used. If it is less sure, the question goes to HYBRID. The standard value is 0.6.

The three main searching modes. LOCAL looks up specific things in the graph. GLOBAL answers overview questions from community reports. HYBRID combines both and may ask itself follow-up questions. See Retrieval strategies.

A variant of LOCAL for questions like "How is A related to B?". It looks for the chain of connections between two entities. Path Max Hops sets the longest chain it searches.

An answer written without any search. The router uses it for thanks, small talk and requests like "shorter" or "as a table" that only need the conversation so far. You can switch it off (then every message is searched). You can also set how sure the router must be (DIRECT Confidence Threshold, standard 0.9).

An answer written only from a file the user attached to the question, without searching the Topic. The router uses it when the attached file alone answers the question. It has no switch of its own.

The few entities a LOCAL search starts from. They are the ones that match the question best.

How LOCAL (and the LOCAL half of HYBRID) finds its starting entities. NODES starts from entity names. CHUNKS starts from text passages that match the question and uses the entities found in them. FUSED does both and is the standard. See Retrieval strategies.

The entities and relationships a LOCAL search collects, starting from the seeds and growing outward. It is limited by Hop Depth and Max Subgraph Nodes.

Text passages that have no entity in the graph, for example a table the extraction missed. LOCAL can add a few of them, so they can still answer a question.

Search by meaning. The question and the stored text are turned into numbers, and the closest ones win. It is the standard for LOCAL and GLOBAL.

An optional addition to dense search. It also looks for the exact words of the question. It helps with codes, IDs and names that search by meaning finds poorly. You switch it on separately for LOCAL and for GLOBAL in step 3. It is off by default. Its index lives in the Topic’s own storage, not in your vector database.

A GraphRAG Topic uses up to eight model roles: Language Model, Embedding Model, Graph Extraction, Deduplication, Community Report, Router, Follow-up and Image Describer. See Models and their roles.

A tick box next to each optional model role. Ticked: the role uses the Topic’s Language Model. A role needs either its own model or this tick. It cannot stay empty.

The external server that holds your entities and relationships. Neo4j, Memgraph, a generic Cypher-compatible server and CYROCK.DB are supported. Every GraphRAG Topic needs one. There is no built-in graph store. You register graph databases under Admin → Graph Databases.

Stores the vectors for chunks, entities and community reports. It is always an external server. Every GraphRAG Topic needs one. There is no built-in vector store. You register vector databases under Admin → Vector Databases.

One product that you can register twice: as a vector database and as a graph database. The connection settings are the same for both.

The name under which this Topic’s chunks, entities and reports are stored in the vector database. You type it yourself. It must be different for every GraphRAG Topic on the same database.

The one choice that says what the Topic does with pictures inside documents and with uploaded image files. Ignore skips them. Extract entities describes them and reads the description like normal text. Picture in the graph (standard) describes them and also keeps one entry per picture, which can show up in answers. Every mode except Ignore needs an Image Describer Model. See File types, Docling, and image handling.

The list of documents an answer used. It appears below the answer. The badge of an uploaded document is a download link that works for about 10 minutes. See Chat window.

Two kinds of source:

You can replace the wording of every prompt the Topic sends to a model, on the Prompts tab. The prompts are grouped by the model role that uses them. A prompt you do not touch keeps its built-in wording. If you save a text that is the same as the built-in one, the override is removed. See Configuration and functions.

Your Topic’s own instructions for the answer, such as tone and role. The Topic uses it only for the final answer of each question: the LOCAL or PATH answer, the last step of GLOBAL, the HYBRID final answer, or a DIRECT or ATTACHMENT answer. It shapes how the answer is written. It does not change what is searched. See Models and their roles.

A part of wizard steps 3 and 4 with a tick box in its title. Unticked, its fields are greyed out and the Topic uses working standard values. Tick it to change them. A section opens by itself when the Topic already holds values that differ from the standard, so you never miss a changed setting. See Creating a GraphRAG Topic.

Record-shaped files (JSON, XML, YAML, TOML, CSV, TSV). A GraphRAG Topic always flattens them into key and value text before splitting. There is no setting for this and no extra model call.