Knowledge Graph — структурированное представление сущностей и явных отношений между ними. Вместо «эти два текста семантически похожи» граф умеет выражать: компания A ВЛАДЕЕТ объектом B, проект C РАСПОЛОЖЕН_В регионе D, документ E ОТНОСИТСЯ_К проекту C.
№66 Vector DB & Embeddings владеет similarity-based candidate retrieval; №67 — explicit entities/typed relations/traversal. №08 RAG владеет full retrieval-augmented answer pipeline; GraphRAG — один retrieval pattern внутри неё. №26 Multi-Hop Research владеет исследовательской стратегией, где следующий вопрос зависит от найденного evidence; graph traversal может быть одним из инструментов такого исследования. №17 Reasoning Search ищет по reasoning states/partial solutions; это не knowledge graph traversal. №61 Provenance хранит origin/derivation graph system objects; knowledge graph описывает domain entities/relations. №55–56 доставляют и парсят source data, из которой graph facts извлекаются.
Prerequisites: №08 RAG, №25 Evidence-First, №26 Multi-Hop Research, №27 Agentic RAG, №45 Verification, №46 Observability, №50 Contracts, №55 Ingestion, №56 Parsing, №61 Provenance, №66 Vector DB & Embeddings. Forward references: №76 Data Governance & Privacy, №77 Production AI Architecture.
REQUEST-TIME: entity resolution, graph lookup, neighborhood/path retrieval. CONTROL PLANE: ontology/schema, relation types, confidence thresholds, extraction policies, traversal limits. DATA PLANE: entities, edges, properties, aliases, evidence refs, temporal/access metadata. OFFLINE: graph extraction, entity linking, dedup, consistency checks, community summaries, rebuild and evals.
Success: graph query returns bounded authorized entities/relations with source-backed evidence and exact versions. Retryable: transient graph/index/network failure. Permanent: invalid schema relation, unresolved entity, forbidden traversal, missing graph generation. Idempotency: upsert by stable entity/edge identity + source fact version. Persist: entity IDs, aliases, relation type, source/evidence refs, confidence/status, temporal validity, access scope, graph generation. Security: path expansion cannot traverse through hidden nodes and leak their existence/relations.
№67 не владеет general RAG, vector similarity, reasoning-tree search, provenance graph, workflow dependencies or arbitrary database joins. Она владеет DOMAIN ENTITY/RELATION MODELING AND GRAPH-BASED KNOWLEDGE RETRIEVAL.
INVESTS_IN, LOCATED_IN, OWNS, PART_OF, DEPENDS_ON.Практичен для product/operational graph queries. Node/edge can carry arbitrary properties: dates, status, evidence, tenant, confidence.
Полезен при semantic-web/ontology/interoperability requirements. Can support formal vocabularies and reasoning layers.
{
"entity_ref": "entity://project/01J...",
"entity_type": "PROJECT",
"canonical_name": "...",
"aliases": [
"...",
"..."
],
"tenant_id": "tenant_A",
"status": "ACTIVE",
"properties": {
"region": "...",
"project_type": "..."
},
"source_refs": [
"source://..."
],
"valid_from": "...",
"valid_to": null,
"graph_generation": "g12"
}Stable entity_ref separates identity from labels.
{
"edge_id": "EDGE-...",
"subject_ref": "entity://company/A",
"predicate": "INVESTS_IN",
"object_ref": "entity://project/B",
"status": "VERIFIED",
"confidence": 0.98,
"evidence": [
{
"ref": "block://doc77/v4/page2/b9",
"source_ref": "source://official/..."
}
],
"valid_from": "2026-01-01",
"valid_to": null,
"extracted_by": {
"pipeline": "relation-extract-v3"
},
"tenant_id": "tenant_A"
}Для material domain facts полезны статусы:
LLM extraction may create CANDIDATE, not automatic truth.
Company, Person, Project, Location, Document, Product, Regulation...
OWNS, FUNDS, LOCATED_IN, PART_OF, WORKS_FOR, DEPENDS_ON.
COMPANY —OWNS→ PROJECT; PROJECT —LOCATED_IN→ LOCATION.
Add/rename/deprecate relation types with migration rules.
RELATED_TO is useless; too-detailed ontology becomes unmaintainable.Tax ID, registry ID, internal project ID, canonical external identifier.
Legal form, punctuation, transliteration, abbreviations.
Region, parent org, date, address, role, neighboring entities.
Embeddings/LLM can suggest same-entity candidates, but high-risk merges need deterministic evidence/review.
Text span «Омск-Фёдоровка», page 3, source v4, exact spelling and context.
Stable project entity with canonical name and aliases, linked to all mentions.
CEO role valid 2025–2027; concession status changed in 2026.
Fetched/extracted at a particular timestamp/source version.
Keep history instead of silently overwriting relation/property.
Relation references block/table/record that supports it.
Link points to exact source version/hash used during extraction.
Extractor/parser/model/config version captured via №61 lineage.
Known project/company/person identifier.
Alias index, exact name, rare identifier.
№66 can find seed entities/chunks from natural-language description.
Type=PROJECT + region=... + year=...
Ownership question follows OWNS/PART_OF, not every available relation.
Usually 1–3 hops, deeper only with explicit need/evals.
Limit neighbors from high-degree entities such as country/topic.
Max expanded nodes, paths and materialized evidence items.
Useful for beneficial ownership / organizational hierarchy.
Useful for impact analysis and architecture queries.
Useful for cross-document structured research.
PROJECT —LOCATED_IN→ REGION. The relation already exists in graph.
First source reveals operator name; next search queries external registry for operator ownership.
Resolve one company/project/person, expand immediate relations, collect source evidence, answer bounded question.
Use communities/clusters/aggregate summaries to answer «какие основные группы/темы/связи?» without traversing every raw edge at runtime.
Find likely entities/documents from natural-language query.
Follow explicit typed relations and filters from seeds.
Rank graph facts + source chunks and build answer context.
{
"seed_entities": [
"entity://project/B"
],
"allowed_relations": [
"INVESTS_IN",
"OWNS",
"LOCATED_IN"
],
"direction": "BOTH",
"max_hops": 2,
"max_nodes": 100,
"max_edges": 200,
"time": {
"as_of": "2026-08-31"
},
"filters": {
"tenant_id": "tenant_A"
},
"include_evidence_refs": true
}Вместо unrestricted query language model получает:
Advanced analysts/tools may use direct graph query language under separate permissions.
Company A —INVESTS_IN→ Project B [source: ...].
Load the exact source blocks behind material edges.
For long path, show sequence + relation semantics + citations, not raw graph dump.
Model chooses only from explicit entity/relation types.
Every extracted edge includes exact supporting text/table source.
Uncertain relation remains candidate and may require verification.
«Works with» must not become OWNS unless evidence explicitly supports ownership.
| Graph item | Status | Example |
|---|---|---|
| DIRECT FACT | Source explicitly states relation. | «Company A owns 60% of B» → A OWNS B. |
| NORMALIZED FACT | Deterministic normalization. | 60 percent → ownership_share=0.6. |
| DERIVED INFERENCE | Computed from several facts. | A controls C through B. |
| HYPOTHESIS | Possible relation needing confirmation. | Likely same project entity from ambiguous alias. |
Store separate edge/fact records with source/version/time rather than silently choosing latest.
Official source, newer valid time, trusted internal registry or human review may determine active fact.
Graph retrieval can return conflict metadata so answer does not present contested relation as certain.
Thousands of projects/companies linked to one country.
«Infrastructure» or «AI» nodes create noisy neighborhoods.
Sample/filter/rank neighbors before following them.
For ownership question, ignore broad TOPIC edges entirely.
Track node/path states during bounded traversal.
Traversal depth has explicit ceiling.
Deduplicate repeated fact chains before materialization.
Hidden project/customer name can leak even without source text.
«Company A works with confidential Client B» may itself be protected.
Traversal engine must apply tenant/ACL constraints at every expansion.
Source/evidence refs re-authorized before loading into context.
graph g11 ← ACTIVE graph g12 ← BUILDING g12 changes: ontology v4 entity resolver v7 relation extractor v5 new source snapshot dedupe rules v3 BUILD ↓ consistency checks ↓ entity/edge counts ↓ precision/recall evals ↓ ACL tests ↓ sample path verification ↓ PROMOTE g12 ROLLBACK: active_generation = g11
entities, edges, alias tables, recursive CTEs. Good for small/medium graphs, strong transactional integration and familiar operations.
Useful for very large/deep interactive traversals, graph-native analytics, path-heavy workloads or specialized graph algorithms.
kg_entities( entity_ref text primary key, entity_type text, canonical_name text, tenant_id text, status text, valid_from timestamptz, valid_to timestamptz, generation text, properties_json jsonb ) kg_aliases( alias text, entity_ref text, alias_type text, source_ref text ) kg_edges( edge_id uuid primary key, subject_ref text, predicate text, object_ref text, tenant_id text, status text, confidence numeric, valid_from timestamptz, valid_to timestamptz, generation text, metadata_json jsonb ) kg_edge_evidence( edge_id uuid, evidence_ref text, source_ref text, source_version text )
Recursive CTEs cover bounded 1–3 hop MVP traversal surprisingly well.
Q1:
"Какие проекты связаны с Company A?"
seed Company A
follow INVESTS_IN / OWNS
filter status=ACTIVE
return projects + evidence
Q2:
"В каких регионах находятся проекты,
в которые инвестирует Company A?"
Company A
--INVESTS_IN→ Project
--LOCATED_IN→ Region
Q3:
"Какие опубликованные отчёты зависят
от источника, который был отозван?"
NOTE:
this is primarily №61 provenance/lineage,
NOT domain Knowledge Graph.
Q4:
"Найди цепочку владения A → C"
A --OWNS/PART_OF→ ... --OWNS→ C
max_hops=4
verify every edge evidence
Correct canonical entity selected from mention/query.
Extracted relation is actually supported by evidence.
Important supported relations are present in graph.
Graph contains a valid relation path needed for target questions.
Returned nodes/edges are relevant to query intent.
Unauthorized node/edge exposure rate. Target 0.
Quality gain vs vector/lexical RAG baseline on relation-heavy tasks.
Traversal + materialization + generation overhead.
PERSON cannot LOCATED_IN a document if ontology forbids that relation shape.
Every active edge resolves to existing active entities.
Every VERIFIED edge has at least one accessible evidence ref.
valid_from ≤ valid_to; impossible overlapping states flagged.
High-similarity aliases/identifiers flagged for review.
Sudden degree explosion may indicate bad extraction/schema mapping.
Facts from superseded source versions handled correctly.
Edge/node access is not weaker than protected source evidence by accident.
Active entities by type/tenant/generation.
Verified/candidate/disputed edges by relation type.
Verified extraction precision on labeled samples.
Correct merge/link rate and false-merge rate.
Actual hops/nodes/edges expanded per query.
Entity resolve + traversal + materialization.
Unauthorized node/edge/path exposure. Target 0.
Quality gain vs simpler retrieval baseline on graph-suitable tasks.
knowledge_graph/ ├── schema.py ├── entities.py ├── aliases.py ├── resolver.py ├── relations.py ├── extraction.py ├── verification.py ├── traversal.py ├── materialize.py ├── reconcile.py └── tests/ MVP PIPELINE: source blocks ↓ mention extraction ↓ entity resolution ↓ relation candidates ↓ schema validation ↓ evidence check ↓ verified graph facts MVP RETRIEVAL: query ↓ resolve seed entity ↓ choose approved relation template ↓ max_hops <= 2 ↓ max_nodes <= 50 ↓ tenant/ACL/time filter ↓ load evidence ↓ answer + verify
No enterprise ontology, no graph DB cluster, no autonomous graph-building agent required.
| Signal | Potential upgrade |
|---|---|
| Large/deep path-heavy interactive queries | Dedicated graph database / graph-native query engine. |
| Huge corpus-wide structural questions | Community detection + hierarchical graph summaries. |
| Many ambiguous entities | Stronger entity-resolution pipeline, review queue, registry integration. |
| Ontology grows across domains | Schema registry, compatibility/versioning, domain ownership. |
| High extraction volume | Batch workers, confidence calibration, active-learning/eval pipelines. |
| Graph + vector both critical | Unified hybrid retrieval orchestration, not necessarily a single physical database. |
| Вопрос | Ответ |
|---|---|
| Стоит ли реализовывать? | Только если relation-aware use cases действительно важны. Для обычного document QA сначала RAG + vector/lexical retrieval. |
| Separate Component? | YES логически. Физически MVP может быть PostgreSQL tables + retrieval library. |
| Минимум 80% ценности? | Stable entities, typed relations, evidence-backed edges, entity resolution, temporal/access metadata, bounded traversal, graph retrieval evals. |
| Когда overkill? | Enterprise ontology, graph DB cluster, community hierarchy и autonomous extraction для маленького корпуса без graph-specific questions. |
| Trigger? | Questions repeatedly require ownership/dependencies/paths/entity aggregation or vector RAG misses relation structure. |
| Как измерить uplift? | GraphRAG answer quality vs vector-only baseline, entity resolution accuracy, edge precision/recall, path recall, retrieval latency, ACL violations. |
| Можно ли rule/tool/code вместо LLM-agent? | Да для storage/query/schema. LLM useful for extraction/entity linking/query interpretation, but verified graph truth must remain source-backed and constrained. |
Use vectors for similarity; graph for typed domain connections.
Names are aliases, not primary keys.
Source/version/provenance are part of graph fact contract.
Schema/evidence/verification decide what becomes trusted graph knowledge.
Relation allowlist, hop limit, degree cap and graph budget are mandatory.
Semantic seed → graph expansion → evidence materialization is a strong pattern.
Don't overwrite history when ownership/status changes.
Hidden nodes/edges cannot participate in unauthorized paths.
Upgrade storage only after path/query workload proves it necessary.
SOURCES
documents
tables
APIs
registries
↓
INGEST / PARSE
↓
MENTIONS
↓
ENTITY RESOLUTION
stable entity_ref
aliases
identifiers
context
↓
RELATION EXTRACTION
schema-constrained
evidence span required
↓
CANDIDATE FACTS
↓
VERIFY
type constraints
evidence support
temporal consistency
access scope
↓
KNOWLEDGE GRAPH
entities
typed relations
properties
valid time
status
evidence refs
↓
GRAPHRAG QUERY:
USER QUESTION
↓
RESOLVE INTENT / ENTITIES
↓
SEED RETRIEVAL
exact ID
lexical alias
vector search
metadata
↓
BOUNDED GRAPH EXPANSION
allowed relations
max hops
max nodes
degree cap
time filter
tenant / ACL
↓
PRUNE / RANK
↓
MATERIALIZE SOURCE EVIDENCE
↓
RAG CONTEXT
↓
GENERATE
↓
VERIFY CLAIMS
HYBRID:
VECTOR
finds semantically plausible entry points
GRAPH
follows explicit domain relations
PROVENANCE
explains where graph facts came from
VERIFICATION
checks whether evidence supports answer
BOUNDARIES:
№66 VECTOR SEARCH
"WHAT IS SEMANTICALLY SIMILAR?"
№67 KNOWLEDGE GRAPH
"WHAT IS EXPLICITLY RELATED, AND HOW?"
№17 REASONING SEARCH
"WHICH REASONING STATE SHOULD WE EXPLORE?"
№61 PROVENANCE
"WHERE DID THIS SYSTEM OBJECT / FACT COME FROM?"
№26 MULTI-HOP RESEARCH
"WHAT NEW EVIDENCE SHOULD WE FIND NEXT?"
CORE PRINCIPLE:
A KNOWLEDGE GRAPH
IS NOT A COLLECTION
OF LLM-GENERATED CONNECTIONS.
IT IS A VERSIONED,
SOURCE-BACKED MODEL
OF DOMAIN ENTITIES
AND TYPED RELATIONS.
GRAPHRAG IS USEFUL
WHEN THE QUESTION DEPENDS
ON THOSE RELATIONS.
IF THE QUESTION ONLY NEEDS
RELEVANT TEXT—
NORMAL RAG MAY BE
SIMPLER, CHEAPER
AND BETTER.
A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №67 Knowledge Graph & GraphRAG.
B–E. Existing boundary and placement. The existing conceptual boundary, class ADVANCED, default OFF and owner Knowledge / Research Engine remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.
F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.
I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.
K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.