LLM + KG integration.

Beyond naive RAG.

Standard RAG (Retrieval Augmented Generation) retrieves text chunks by vector similarity to the query and feeds them into an LLM context window. It works well for single-hop questions: "What is Itachi's canonical motivation?" fails on any question that requires traversing multiple relationships: "Which characters across all three arcs have a sensei lineage that connects to Naruto?" Vector similarity can find chunks mentioning Naruto, but cannot follow the senseiOf chain without structural guidance.

Microsoft's GraphRAG paper (Edge et al., 2024) formalizes this problem and introduces a solution: build a community graph over the text corpus (not just a semantic index), then use graph traversal to assemble context from related entities rather than from similar chunks. The curriculum's hybrid approach is more targeted: we have an explicit, hand-designed ontology (the Naruto ontology from Module 2) rather than a derived community graph, which means the traversal is more precise and the explanations are more interpretable.

Three GraphRAG patterns

• Entity-centric retrieval. Identify entities mentioned in the query, use graph traversal to find related entities, bias vector retrieval toward chunks mentioning those entities. This is the primary pattern in TwinKit Semantic v2.0.
• Community summarization. (Microsoft GraphRAG) Pre-compute summaries of entity clusters in the knowledge graph; retrieve the relevant cluster summary as context. Good for global questions; requires pre-computation.
• Subgraph extraction. For a given query entity, extract a k-hop subgraph as structured context alongside retrieved text chunks. Best for dense relational questions; expensive to compute at runtime for large graphs.

Five steps per query.

# The full hybrid retrieval pipeline in pseudocode

# Step 1: Extract entities from query
entities = llm_extract_entities(user_query)
# → ["Jiraiya", "naruto:NarutoUzumaki"]

# Step 2: SPARQL graph traversal
related = sparql_expand(entities, hops=2)
# → ["naruto:KakashiHatake", "naruto:SasukeUchiha", "naruto:Team7", ...]

# Step 3: ChromaDB retrieval biased toward expanded entities
chunks = chromadb.query(
    query_embeddings=embed(user_query),
    where={"entities": {"$in": related}},
    n_results=5
)

# Step 4: Compose context
context = sparql_results_as_text(related) + "\n\n" + format_chunks(chunks)
answer = llm_generate(user_query, context)

What changes from v1.0.

TwinKit v1.0: markdown ingestion → ChromaDB → LLM generation. TwinKit Semantic v2.0 adds the semantic layer as an optional module that activates when a domain ontology is available.

What the Naruto demo adds to the framework

The Naruto Knowledge Graph is the demo dataset that makes the framework tangible to non-practitioners. Instead of "a knowledge graph of your domain," it is a clickable, queryable graph of 87 characters, three arcs, and an ontology anyone who watched the show can verify. The Gradio or D3.js Explorer app (Exercise 4.3, step 5) is the front door — it is what people click on before reading the case study.

The two-birds strategy: TwinKit Semantic is the consulting artifact; the Naruto demo is the attention hook. They deploy together with one architecture.

The graph traversal queries in the hybrid pipeline.

PREFIX schema: <https://schema.org/>
PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

# Step 2 of the hybrid pipeline: given entity ?seed (Jiraiya),
# return all entities reachable via any naruto: property within 2 hops.
SELECT DISTINCT ?relatedEntity ?relatedName WHERE {
  # Seed entity lookup by name
  ?seed naruto:canonicalName ?seedName .
  FILTER (CONTAINS(LCASE(?seedName), "jiraiya"))

  # 1-2 hop expansion via any naruto: property (forward + inverse)
  {
    ?seed ?p1 ?hop1 .
    FILTER (STRSTARTS(STR(?p1),
           "https://sensemaking-ai.com/ns/naruto#"))
    OPTIONAL { ?hop1 ?p2 ?relatedEntity .
      FILTER (STRSTARTS(STR(?p2),
             "https://sensemaking-ai.com/ns/naruto#"))
    }
    BIND(COALESCE(?relatedEntity, ?hop1) AS ?relatedEntity)
  }
  OPTIONAL { ?relatedEntity naruto:canonicalName ?relatedName . }
}
ORDER BY ?relatedName

PREFIX schema: <https://schema.org/>
PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

# Find all characters who share a common sensei ancestor with Naruto.
# This requires 3+ hops: Naruto ← senseiOf ← Kakashi → senseiOf → Team7.
# Pure vector search cannot traverse senseiOf chains reliably.
SELECT DISTINCT ?co_studentName ?sharedSenseiName WHERE {
  # Naruto's sensei lineage (upward)
  ?sensei naruto:senseiOf naruto:NarutoUzumaki .

  # Other students of the same sensei
  ?sensei naruto:senseiOf ?co_student .
  FILTER (?co_student != naruto:NarutoUzumaki)

  ?sensei naruto:canonicalName ?sharedSenseiName .
  ?co_student naruto:canonicalName ?co_studentName .
}
ORDER BY ?sharedSenseiName ?co_studentName

# This is the query the Naruto KG Explorer generates when a user asks:
# "Who are Itachi's known masters?"
# The LLM generates SPARQL; Oxigraph executes it; the UI renders results.

# LLM system prompt excerpt (TwinKit Semantic v2.0):
# "You are a SPARQL query generator for the Naruto Knowledge Graph.
#  The ontology uses PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>.
#  Available properties: senseiOf, studentOf, rivalOf, memberOfTeam,
#  memberOfVillage, hasJutsu, hasRank, appearsInArc, familyOf.
#  Generate only valid SPARQL SELECT queries."

# LLM-generated query for "Who are Itachi's known masters?":

PREFIX schema: <https://schema.org/>
PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

SELECT ?masterName WHERE {
  {
    # Direct: someone who is senseiOf Itachi
    ?master naruto:senseiOf naruto:ItachiUchiha ;
            naruto:canonicalName ?masterName .
  }
  UNION
  {
    # Inverse: Itachi is studentOf someone
    naruto:ItachiUchiha naruto:studentOf ?master .
    ?master naruto:canonicalName ?masterName .
  }
}
ORDER BY ?masterName

Honesty is the differentiating artifact.

Exercise 4.3 step 7 specifies 20 multi-hop questions evaluated across three conditions. Here is the framework for structuring those results honestly.

The 20-question set design

• 5 single-hop factual questions (e.g., "What is Naruto's rank?") — vector retrieval should handle these well. Graph augmentation is not expected to help. A baseline win for vector-only.
• 10 multi-hop relational questions (e.g., "Who are the students of all Jonin-rank characters?") — graph traversal is necessary for precision. Hybrid should win here.
• 5 ambiguous or contested questions (e.g., "Who is Itachi's true master?" — answers depend on which source you trust) — neither approach handles uncertainty well. Document both failures honestly.

Where the curriculum lands.

The Module 4 README has the full nine-step capstone plan. The most important sequencing note: do the eval before writing the case study. The eval produces your findings; the case study communicates them. Writing the case study first produces marketing copy, not a technical contribution.

The publishable artifacts that come out of the capstone

• TwinKit v2.0 GitHub release — tagged, with a README that positions the semantic layer and links to the case study
• Naruto KG Explorer — live URL, publicly accessible
• Case study on barbhs.com: "Building a hybrid semantic + vector knowledge twin (with Naruto)"
• LinkedIn capstone announcement — with the eval results as the hook, not the architecture
• Conference abstract for 2027 (Connected Data World, SEMANTiCS, or a RAG-track AI conference)

After shipping: update the LinkedIn About section with the consulting positioning statement from the SYLLABUS closing note. The curriculum is complete. The artifacts are the receipts.

The final reading list.