Vector RAG — fuzzy document search
Best for unstructured text: policies, manuals, articles, support history. Semantic recall over documents where there is no exact key to look up.
Knowledge graphs for LLMs
Knowledge graphs for LLMs: stop your AI guessing your domain
Hallucinated facts are why most product AI never earns user trust. Declare your domain once and the engine generates deterministic retrieval tools — no invented IDs, full recall on structured queries. Open-source, self-hosted, GitOps-native.
What is a knowledge graph for an LLM?
A knowledge graph is a typed model of your domain — your entities, their fields, and how they relate. Instead of trusting the model to recall or invent those facts, the agent queries the graph for the real record. The answer is grounded in your data, not the model’s imagination.
That is the difference between an AI that looks right in a demo and one you can put in front of a customer.
Knowledge graph vs RAG: when to use which
They solve different problems. Most production agents need both.
Knowledge graph — typed, exact lookups
Best for structured facts: IDs, statuses, prices, relationships. Deterministic retrieval where a wrong or invented value is unacceptable.
How knowledge-graph RAG (GraphRAG) grounds answers
Declare your domain once. The engine generates the retrieval tools. Your agent answers from real records.
You write
Entities as JSON Schema: categories, brands, attributes — with x-id-field, x-ref relationships, and x-index filters.
brewctl kg apply
The engine validates every reference and builds the graph atomically — all entities valid, or rollback.
Auto-generated tools
Each entity type produces list_X, get_X, and opt-in list_X_ids MCP tools, filterable by any indexed field.
Grounded agent
The agent resolves real records — cited, exact, with total counts so it never silently misses one.
Why it holds up in production
Declarative-first, not extracted by an LLM
- Zero extraction drift. Other platforms ask an LLM to extract entities from your docs. You declare them. JSON Schema in, typed MCP tools out.
- Full recall. Queries return total counts, so the agent never quietly drops an approved record.
- GitOps-native. Your domain lives in git: PR review, branching, atomic apply with rollback, Helm integration.
- Coexists with vector RAG and memory. Narrative search, structured retrieval, and cross-session memory on the same agent.
Updated in Knowledge Graphs 1.4: batch fetch (up to 500 records per call), summary projections, server-side sort, and range filters — by our measurements, cutting typical retrieval token cost by roughly 12×. Catalogs that outgrow one file split by directory.
my-bundle/brand.schema.jsonJSON Schema
{
"$id": "brand",
"type": "object",
"x-id-field": "brand_id",
"properties": {
"brand_id": { "type": "string" },
"name": { "type": "string", "x-index": true },
"country": { "type": "string", "x-index": true },
"parent_id": { "type": "string", "x-ref": "company" }
}
} Deploy the graphcopy and run
brewctl kg apply ./my-bundleA worked example
Knowledge graph example: from taxonomy to a grounded answer
One small catalog, end to end: what you declare, what the engine generates, and what your agent answers.
1 · Your taxonomyhuman-readable
category └─ footwear (Footwear) ├─ north-aurora tier: premium hiking boots ├─ stride-co tier: mid running shoes └─ budget-basics tier: budget casual sneakers
2 · Your declarationschema in, tools out
# schemas/brand.schema.json
x-id-field: code
properties:
code: { type: string }
category: { type: string, x-ref: category, x-index: true }
tier: { enum: [budget, mid, premium], x-index: true }
$ brewctl kg apply ./my-bundle
→ generated tools: list_brand(filters={category, tier}), get_brand(id) 3 · Your agent’s answergrounded, cited
User: "premium footwear brands?"
tool_call list_brand(filters={category:"footwear", tier:"premium"})
tool_result 1 record
Agent: "1 premium footwear brand: north-aurora.
Total returned: 1 — no missed records." In the platform
Knowledge graphs in SyntheticBrew (open-source)
Knowledge graphs are built into SyntheticBrew, the open-source, self-hosted AI agent runtime. Run it in one Docker command, connect any LLM, and ground your agents in your own data — on your own infrastructure.
Knowledge graphs for LLMs: common questions
What is a knowledge graph for an LLM?
A knowledge graph is a typed model of your domain — entities (products, customers, records), their fields, and how they relate. Instead of asking the LLM to remember or guess those facts, the agent queries the graph for the real record. That makes answers grounded and deterministic rather than invented.
Knowledge graph vs RAG — which should I use?
Use vector RAG for fuzzy search over unstructured documents (policies, articles, manuals). Use a knowledge graph for structured, typed lookups where exactness matters — IDs, statuses, relationships, prices. Most production agents need both, and SyntheticBrew runs them together.
What is GraphRAG?
GraphRAG is retrieval-augmented generation backed by a knowledge graph instead of (or alongside) a vector index. The agent traverses typed entities to answer multi-hop questions accurately, then can fall back to vector search for free-text context.
How do I build a knowledge graph for my AI agent?
In SyntheticBrew you declare your entities as JSON Schema, then run brewctl kg apply ./my-bundle. The engine validates references and generates the retrieval tools your agent uses automatically. The full walkthrough is in the Knowledge Graphs quickstart in the docs.
Ground your agents. Keep your data.
Start in Cloud, self-host the open-source engine, or have us model your domain and deliver the implementation.