Skip to main content
Field reference: knowledge_graph — every field, type, default, and tier for this page.
The Knowledge page is the control room for how your agent turns the files you upload into answers. It governs:
  • Knowledge-graph retrieval — how the knowledge_graph_query tool finds facts.
  • Extraction — whether (and how) a knowledge graph is built automatically from documents you upload on the Internal Data page.
  • Document profiling — the per-document summaries the agent uses to route a question to the right file.
  • Presentation — how retrieved facts are returned to the agent and cited in its replies.
  • Ranking signals — the gentle score adjustments (autocut, freshness, usage) applied when ranking retrieved passages.
  • Follow-up handling — rewriting terse follow-up questions into standalone searches.
  • GraphRAG summaries and entity resolution — thematic topic-cluster answers, and merging duplicate entities across documents.
It does not hold the files themselves — you upload knowledge-graph files and source documents on Internal Data. This page tunes what happens to them. (In the dashboard this page is labelled Retrieval.)
A knowledge graph is a set of facts written as triples: (subject) —[predicate]→ (object), e.g. (Acme Corp) —[acquired]→ (Bluebird Labs). Your agent walks these connections to answer questions that plain text search would miss — “who does Acme’s CFO report to?”, “what products use the Titan engine?”.

​
Retrieval strategy

This is the single most important setting. It decides how your agent searches the graph.

​
Depth and limit

  • Default graph depth (1–3) — how many hops the agent walks out from a matched entity. 1 = direct neighbours only; 3 = friends-of-friends-of-friends.
  • Max results per query (1–200) — the cap on facts returned to the agent per call.
The agent can override both per query, but these are the defaults it uses when it doesn’t.

​
Examples — picking a strategy

Hello world — a glossary bot. You upload a graph of (term) —[means]→ (definition) triples. Set strategy to Exact text match, depth 1. A user asks “what does idempotent mean?” — the agent finds the exact term and returns the definition. No embeddings, instant, free. Simple — a company directory. Triples like (Jane Doe) —[role]→ (CFO), (Jane Doe) —[reports_to]→ (CEO). Set strategy to Smart entity matching, depth 1. A user asks “who’s the finance chief?” — entity linking resolves “finance chief” → “CFO” → “Jane Doe” even though the user never typed her name. Medium — a product knowledge base. Triples connecting products, components, customers, and support cases. Set strategy to Deep traversal with PageRank, depth 2. A user asks “which customers are affected if the Titan engine has a bug?” — the agent walks Titan engine → products using it → customers running those products, and PageRank surfaces the most-connected (highest-impact) customers first instead of in arbitrary discovery order. Complex — an investigative research assistant. A dense graph of people, companies, transactions, and events. Set strategy to Hybrid, depth 3. A user asks “is there any connection between Acme’s new board member and the Bluebird acquisition?” — hybrid runs both entity-anchored BFS and PageRank, merges the results, and surfaces multi-hop paths a single strategy would rank too low to return. This is the most expensive mode; use it where a missed connection is costly. System-pushing — a “tell me about my whole knowledge base” concierge. You’ve uploaded tens of thousands of triples across many topics. Single-fact retrieval can’t answer “what are the major themes here and how do they relate?”. Build community summaries (below), then set strategy to GraphRAG global query. The agent receives a digest of the most query-relevant topic clusters — each with a title, a 2–3 sentence summary, and its top entities — and composes a thematic overview no triple-by-triple search could produce.

​
Entity linking

The Entity linking toggle controls embedding-based mention resolution. On (default), the agent resolves loose mentions to canonical entities. Off forces exact substring matching regardless of strategy — useful when your entity names are codes or IDs that should never be “smart-matched” to something similar.

​
Auto-extract knowledge graph from uploads

When enabled, every document you upload to Internal Data of a selected file type is parsed by an LLM, and a knowledge graph is generated from it automatically — you don’t have to build triples by hand.

​
Examples — auto-extraction

Hello world — one policy document. Turn extraction on, leave .txt/.md/.pdf selected. Upload your refund policy PDF on Internal Data. Within ~30 seconds a new graph appears named refund-policy.pdf (auto-KG) — triples like (refund) —[window]→ (30 days), (damaged item) —[eligible_for]→ (full refund). Your agent can now answer refund questions structurally, not just by keyword. Simple — a model line-up. Upload a product spec sheet. Extraction produces (Model X) —[battery]→ (40 kWh), (Model X) —[successor_of]→ (Model W). Now “which model replaced the W?” walks the successor_of edge. Medium — a knowledge base from a folder of docs. Upload 20 internal wiki pages. Each becomes its own auto-KG file. Cross-document entities (the same person, project, or product mentioned in several files) link up in the graph, so a question answered partly by doc A and partly by doc F resolves across both. Complex — a large handbook with a cost guard. You have a 200-page employee handbook but only want the first ~50 pages (policies) extracted, not the appendices. Set Skip files larger than to 50. The handbook uploads and is searchable via normal text retrieval, but auto-extraction skips it (logged with a reason), so you don’t pay to graph 150 pages of boilerplate. Split the policy section into its own file to extract just that. System-pushing — high-fidelity extraction on dense technical material. Your source documents are dense engineering specs where triple accuracy is critical. Point the Extraction model slot at a frontier model (configure a powerful slot on LLM Routing and name it here) instead of cheap_fast. Extraction costs more per document but produces far cleaner triples — worth it when a wrong relationship in the graph would mislead the agent.
Auto-extraction spends credits on every matching upload. If you upload many documents at once, watch your balance. Turn the master switch off to upload documents for plain text search without building graphs.

​
Document profiling

After each upload, a small LLM call writes a 2–3 sentence content summary plus topic keywords into the agent’s document catalog — so the agent knows what each document is about and routes a question to the right file, instead of seeing only “PDF, 12 pages”.
  • Profile new uploads — run profiling automatically after each ingestion.
  • Profile existing documents — Profile now back-fills profiles for already-uploaded documents that don’t have one yet.
Each profile is one cheap model call per document, billed to your balance. A document’s profile (and a manual Re-profile) is also available from its Knowledge stores panel on the Internal Data page.

​
Ontology alignment

Ontology alignment now lives on the Internal Data page, in the Ontologies card — right next to where you import ontologies and assign them per document. Import your RDF/OWL/Turtle/JSON-LD vocabulary there, turn on Align document graphs to an ontology, and extraction maps entities and relationships onto your schema so every graph is consistent and machine-readable. See Internal Data → Ontologies for the settings, strict mode, and a worked example.

​
Presentation

Controls how retrieved facts reach the agent and how it cites them.
  • Include source passages — when on, each triple is returned alongside the original document passage it was extracted from, so the agent can quote the source verbatim instead of paraphrasing. Requires auto-extracted graphs (manually-built triple files usually have no source text).
  • Citation style — footnote, inline, or none. How the agent attributes KG facts in its replies.
  • Source preview max chars — the maximum length of source-passage text returned per triple.

​
Examples — presentation

Simple — trustworthy support answers. Turn Include source passages on, citation style inline. When the agent answers “what’s the warranty period?”, it returns “24 months (per Warranty Policy §3: ‘All Titan-series products carry a 24-month limited warranty…’)” — quoting the source so the user can trust it. Complex — a compliance assistant that must cite chapter and verse. Source passages on, citation style footnote, preview chars raised to 600. Every factual claim the agent makes carries a footnote with a substantial excerpt of the originating document text, so a compliance reviewer can audit exactly where each answer came from.

​
Ranking signals

Small post-search score adjustments applied when ranking retrieved passages. They are deliberately gentle — they break near-ties, they never override a clearly better match. (Per-document priority is set on each file’s row on the data pages; High-priority documents are exempt from the freshness decay below.)
  • Autocut — cut the result list at the first sharp score drop-off instead of always returning a fixed number, so narrow questions don’t get padded with weak passages.
  • Freshness boost — prefer recently-added or recently-dated documents when passages score similarly. Documents the agent cites often, and files you mark high-priority, are exempt from the decay. Set the half-life (days) — a document that old ranks ~7% lower than a brand-new one on ties.
  • Usage boost — documents the agent actually cites in its answers gradually rank higher, so the knowledge base learns which sources answer real questions.

​
Examples — ranking signals

Simple — a tighter FAQ bot. Turn Autocut on. When a user asks a narrow question, the agent returns the one or two genuinely relevant passages instead of padding the list to a fixed count with loosely-related chunks — cleaner context, cleaner answers. Complex — a news-digest agent with a flagship source. Turn on Freshness boost (short half-life) so today’s items win ties over last month’s, and Usage boost so the sources that keep answering real questions drift upward over time. Then mark your flagship whitepaper High priority on its file row — it stays authoritative and is exempt from the recency decay, so it never sinks just because it is older.

​
Follow-up question handling

In a multi-turn chat, a terse follow-up like “what about 2024?” searches on those literal words and finds nothing. Rewrite follow-ups before searching fixes that:
  • Off — search the message exactly as typed.
  • Auto — detect short follow-ups and have a cheap model rewrite them into a standalone search query first. The message the agent answers is never changed; only the text used for retrieval is. Each rewrite is a small billed call.
The Retrieval Test is single-turn, so rewrites don’t apply there.

​
GraphRAG community summaries

For broad, thematic questions, the platform can pre-compute LLM-summarised topic clusters — groups of densely-connected entities — and answer from those summaries instead of individual facts. This powers the GraphRAG global query strategy.
  • Build now / Rebuild now — runs community detection over your graph, summarises each cluster with an LLM, and stores the result. Cost is billed. The card shows how many clusters exist and when they were last built.
  • Rebuild on KG upload — off by default (it’s expensive). Turn on if your knowledge base changes rarely and you want summaries always fresh.
  • Maximum communities — caps how many clusters get summarised. Higher = finer-grained themes, more LLM calls.
  • Query matching — how a global query is matched to clusters: Semantic (embed the question to find topically-relevant clusters — a tiny embedding fee per query, recommended) or Keyword (free word-overlap matching, the fallback when embeddings aren’t available).
  • Include cluster facts — return each matched cluster’s most-connected triples alongside its summary, so thematic answers carry concrete facts instead of only themes.

​
Examples — community summaries

Medium — a “what’s in here?” overview. You’ve uploaded a research corpus. Click Build now. After a minute the page shows “12 clusters, built just now”. Set strategy to GraphRAG global query. A user asks “give me an overview of what this knowledge base covers” — the agent returns a structured digest: “Three major themes: (1) Battery chemistry — centred on lithium-iron-phosphate cells…; (2) Supply chain — suppliers, lead times…; (3) Regulatory — certifications and standards…”. Complex — a living knowledge base. Your graph updates weekly as new documents arrive. Turn Rebuild on KG upload on and raise Maximum communities to 60 for fine-grained themes. Every new document both extends the graph (auto-extraction) and refreshes the topic summaries, so global-query answers always reflect the latest material — at the cost of a rebuild on each upload.

​
Knowledge-graph entity resolution

The same real-world entity often appears under different names across documents (“Acme Corp” vs “Acme Corporation”), splitting the graph so traversals miss connections. Entity resolution finds likely duplicates by embedding similarity, confirms them with a cheap model call, and merges them non-destructively — your uploaded graph files are never modified.
  • Resolve now — scan all knowledge graphs for duplicate entities and merge them; billed by the amount of text compared (typically a few credits for a mid-size graph).
  • Resolve automatically after extraction — run resolution whenever a new graph is extracted from an upload. Off by default, since each run is billed.

​
How it all fits together

A fully-loaded setup looks like this:
  1. Internal Data — you drop in PDFs and documents (and, optionally, an ontology).
  2. Knowledge → Auto-extract (on) — each document becomes a graph automatically.
  3. Internal Data → Ontologies (optional) — those graphs conform to your entity/relationship vocabulary.
  4. Knowledge → Retrieval strategy (auto or ppr) — the agent searches those graphs when answering.
  5. Knowledge → Presentation (source passages on) — answers come back cited to the source text.
  6. Knowledge → GraphRAG (built) — broad “overview” questions are answered from topic summaries.
Test the whole pipeline without spending a chat turn on the Retrieval Test page — it shows you exactly which facts your agent would retrieve for a given question, and what it costs. It has two modes: Test all methods runs every retriever side by side for near-free (just a couple of query embeddings, reranker skipped), so you can check “is anything finding this at all, and which retriever?”; Run full pipeline reproduces a real interaction’s retrieval — reranker included — and bills your account, so the figure reflects true production cost.