Rag Scenarios And Solutions

Knowledge Graph Inconsistencies

Relationships between entities (users, teams, resources) stored inconsistently or incompletely, breaking multi-hop reasoning and access control logic.

TL;DR

Relationships between entities (users, teams, resources) stored inconsistently or incompletely, breaking multi-hop reasoning and access control logic.

Key Takeaways

  • The Problem
  • Deep Technical Analysis
  • How to Solve
  • Agent Instructions: Querying This Documentation

The Problem

Relationships between entities (users, teams, resources) stored inconsistently or incompletely, breaking multi-hop reasoning and access control logic.

Symptoms

  • ❌ "Alice is in Engineering" + "Bob is in Engineering" but no team entity
  • ❌ Relationships not bidirectional
  • ❌ Entity resolution errors (multiple IDs for same entity)
  • ❌ Broken transitive relationships
  • ❌ Cannot query "who can access X?"

Real-World Example

Knowledge base facts:
→ Doc A: "Alice works on Project Phoenix"
→ Doc B: "Project Phoenix uses Database Prod-DB"
→ Doc C: "Bob manages Database Prod-DB"

Query: "Who can access Prod-DB?"

Expected reasoning:
→ Alice → Project Phoenix → Prod-DB ✓
→ Bob → manages → Prod-DB ✓

AI response: "Bob manages Prod-DB"
→ Missed: Alice's indirect access via Project Phoenix
→ Relationships not explicitly modeled

Deep Technical Analysis

Implicit vs Explicit Relationships

Text-Based (Implicit):

Current approach:
→ Facts embedded in text
→ "Alice is member of Engineering team"
→ LLM must infer relationships

Problems:
→ Inference unreliable
→ Multi-hop reasoning fails
→ Cannot query graph structure

Graph-Based (Explicit):

Knowledge graph:
→ Nodes: Alice, Engineering, Project Phoenix
→ Edges: 
  - Alice -[memberOf]-> Engineering
  - Engineering -[worksOn]-> Project Phoenix
  - Project Phoenix -[uses]-> Prod-DB

Graph query:
→ MATCH (u:User)-[:memberOf]->(t:Team)-[:worksOn]->(p:Project)-[:uses]->(d:Database {name: "Prod-DB"})
→ RETURN u

Explicit traversal finds Alice

Entity Resolution

Multiple Representations:

Same person, different references:
→ "Alice Smith"
→ "Alice S."
→ "A. Smith"
→ "alice.smith@company.com"
→ User ID: 12345

Without resolution:
→ Treated as 5 different entities
→ Relationships fragmented

Canonical Entities:

Entity resolution:
→ Create canonical: entity_id: "user_12345"
→ Map all variants:
  - "Alice Smith" → user_12345
  - "alice.smith@company.com" → user_12345

All relationships link to canonical ID

Relationship Types

Access Control Graph:

Relationship types:
→ memberOf: User → Team
→ hasAccess: Team → Resource
→ manages: User → Resource
→ inheritsFrom: Role → Role

Query: "Can Alice access X?"
→ Traverse: Alice -[memberOf]-> Team -[hasAccess]-> X
→ Or: Alice -[manages]-> X
→ Multiple paths possible

Temporal Relationships:

Relationships change over time:
→ "Alice was in Engineering (2022-2023)"
→ "Alice now in Sales (2024-present)"

Graph needs temporal dimension:
{
  from: "user_12345",
  to: "team_engineering",
  relationship: "memberOf",
  valid_from: "2022-01-01",
  valid_until: "2023-12-31"
}

Current query uses current relationships only

Hybrid RAG + KG

Combined Approach:

1. Vector retrieval: Find relevant chunks
2. Entity extraction: Identify entities in chunks
3. Graph expansion: Query KG for related entities
4. Enriched context: Chunks + graph facts

Example:
Query: "What does Alice work on?"
→ Vector: Retrieves "Alice's bio"
→ KG: Finds Alice's team, projects, permissions
→ Combined: Complete picture

How to Solve

Build explicit knowledge graph for entities and relationships + implement entity resolution (canonical IDs) + use typed relationships (memberOf, hasAccess, manages) + store bidirectional edges + implement graph traversal for multi-hop queries + combine vector search with graph expansion + maintain temporal validity of relationships + test access control queries against graph. See Knowledge Graphs.


Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the ask query parameter:

GET /dev/rag-scenarios-and-solutions/data-quality/knowledge-graph.md?ask=<question>

The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.

Related Pages

Last updated January 26, 2026