Introduction

You have a pile of unstructured documents and need to answer questions that span them — "who works with people who worked on project X", "which vendors are connected to this incident". No single document contains the answer. RAG retrieval won't chain the facts for you. You need a knowledge graph: entities as nodes, typed relations as edges, so that multi-hop reasoning becomes graph traversal.

Building one used to mean training a named-entity recognizer on your domain, training a relation classifier, writing entity-resolution heuristics, and maintaining all three as your data shifted. With Claude, each of those stages becomes a prompt.

What You'll Learn

By the end of this guide you will be able to:

• Use structured outputs to extract typed entities and subject–predicate–object triples from arbitrary text with no training data
• Apply Claude-driven entity resolution to collapse surface-form variants into canonical nodes, replacing brittle string-similarity heuristics
• Assemble and query an in-memory graph, and run multi-hop questions by serializing subgraphs back to Claude
• Measure extraction quality with precision/recall against a gold set and reason about the cost/quality tradeoff between Haiku and Sonnet

Everything runs in memory with no database. The techniques transfer directly to Neo4j, Neptune, or a Postgres adjacency table when you need to scale.

Prerequisites

• Python 3.11+
• Anthropic API key (get one here)
• Basic familiarity with graphs (nodes, edges, traversal)

Setup

We use two models. Haiku handles the high-volume, schema-constrained extraction work where speed and cost matter more than nuance. Sonnet handles entity resolution and summarization, where the model needs to weigh conflicting evidence across documents.

import anthropic
from pydantic import BaseModel, Field
from typing import List, Optional
haiku = anthropic.Anthropic().messages
sonnet = anthropic.Anthropic().messages  # use model="claude-sonnet-4-20250514"

Building a Corpus

We need a handful of documents that talk about overlapping entities, so that entity resolution has real work to do. The Apollo program is a good test bed: six short Wikipedia summaries that all mention NASA, the Moon, several astronauts, and a launch vehicle — but each article names them slightly differently.

import requests
def fetch_wikipedia_summary(title):
    url = f"https://en.wikipedia.org/api/rest_v1/page/summary/{title}"
    response = requests.get(url)
    response.raise_for_status()
    return response.json()["extract"]
documents = {
    "Apollo 11": fetch_wikipedia_summary("Apollo 11"),
    "Neil Armstrong": fetch_wikipedia_summary("Neil Armstrong"),
    "Buzz Aldrin": fetch_wikipedia_summary("Buzz Aldrin"),
    "Saturn V": fetch_wikipedia_summary("Saturn V"),
    "NASA": fetch_wikipedia_summary("NASA"),
    "Moon landing": fetch_wikipedia_summary("Moon landing")
}

For a production pipeline you would chunk full documents; the extraction logic is identical.

Entity and Relation Extraction

Classical NER tags spans of text with labels (PERSON, ORG, LOC). Classical relation extraction then classifies pairs of spans into relation types. Both traditionally require labeled training data per domain.

We collapse both stages into a single Claude call per document. The key is structured outputs: we define the output shape as a Pydantic model and pass it to client.messages.parse(). Claude's response is guaranteed to validate against that schema and comes back as a typed Python object — no regex parsing, no JSON decode errors, no defensive isinstance checks.

class Entity(BaseModel):
    name: str = Field(description="The canonical name of the entity")
    type: str = Field(description="Entity type: PERSON, ORGANIZATION, LOCATION, EVENT, VEHICLE, etc.")
    description: str = Field(description="One-line description providing disambiguation context")
class Relation(BaseModel):
    subject: str = Field(description="Name of the subject entity")
    predicate: str = Field(description="Relation type (e.g., 'commanded', 'launched', 'part_of')")
    object: str = Field(description="Name of the object entity")
class Extraction(BaseModel):
    entities: List[Entity]
    relations: List[Relation]
def extract_from_document(text, title):
    response = haiku.parse(
        model="claude-sonnet-4-20250514",
        max_tokens=4096,
        system="You are a knowledge graph extraction system. Extract all named entities and their relationships from the text.",
        messages=[{
            "role": "user",
            "content": f"Extract entities and relations from this document titled '{title}':\n\n{text}"
        }],
        response_model=Extraction
    )
    return response
Run extraction on all documents
all_extractions = {}
for title, text in documents.items():
    all_extractions[title] = extract_from_document(text, title)

Let's look at what was extracted. Notice how the same real-world entity appears under different surface forms across documents — this is the entity resolution problem we solve next.

Entity Resolution

The raw extraction gives us overlapping mentions: "NASA" and "National Aeronautics and Space Administration", "Neil Armstrong" and "Armstrong", possibly "the Moon" and "Moon". If we build a graph directly from this, we get a fractured mess where the same concept is split across disconnected nodes.

Traditional approaches use string similarity (edit distance, Jaccard on tokens) plus blocking rules. That works for typos but fails on "Edwin Aldrin" vs "Buzz Aldrin" — two names with zero character overlap that refer to the same person.

We instead ask Claude to cluster entities of each type, using the one-line descriptions from extraction as disambiguation context. The descriptions matter: "Armstrong — first person to walk on the Moon" and "Armstrong — jazz trumpeter" have the same name but should not merge.

from collections import defaultdict
def resolve_entities(extractions):
    # Group all entities by type
    by_type = defaultdict(list)
    for doc_extract in extractions.values():
        for entity in doc_extract.entities:
            by_type[entity.type].append(entity)
    
    alias_to_canonical = {}
    
    for entity_type, entities in by_type.items():
        # Build a prompt for Claude to cluster these entities
        entity_list = "\n".join([f"- {e.name}: {e.description}" for e in entities])
        
        response = sonnet.parse(
            model="claude-sonnet-4-20250514",
            max_tokens=4096,
            system="You are an entity resolution system. Group the following entities into clusters where each cluster represents the same real-world entity. Return a mapping from each alias to its canonical name.",
            messages=[{
                "role": "user",
                "content": f"Group these {entity_type} entities into clusters:\n\n{entity_list}"
            }],
            response_model=dict  # Returns alias -> canonical mapping
        )
        
        alias_to_canonical.update(response)
    
    return alias_to_canonical
alias_map = resolve_entities(all_extractions)

Two failure modes to watch for. First, any raw name Claude leaves out of every cluster silently disappears from the graph — a production resolver should fall back to a single-element cluster for unmatched names so nothing is lost. Second, the resolver can over-merge: a specific mission like "Gemini 12" may get folded into the broader "Project Gemini" because the descriptions overlap. The first loses nodes, the second loses precision. Both are worth spot-checking in the output below.

Assembling the Graph

With a clean alias map, we rewrite every relation endpoint to its canonical form and load the result into NetworkX. We use a MultiDiGraph because two entities can be connected by several distinct predicates ("launched from" and "operated by"), and direction matters ("Armstrong commanded Apollo 11" is not the same edge as "Apollo 11 commanded Armstrong").

Each node carries its type, the source document title, and the original surface form for traceability.

import networkx as nx
def build_graph(extractions, alias_map):
    G = nx.MultiDiGraph()
    
    for doc_title, extract in extractions.items():
        for entity in extract.entities:
            canonical = alias_map.get(entity.name, entity.name)
            G.add_node(canonical, type=entity.type, source=doc_title, original=entity.name)
        
        for relation in extract.relations:
            subj = alias_map.get(relation.subject, relation.subject)
            obj = alias_map.get(relation.object, relation.object)
            G.add_edge(subj, obj, predicate=relation.predicate, source=doc_title)
    
    return G
graph = build_graph(all_extractions, alias_map)
print(f"Graph has {graph.number_of_nodes()} nodes and {graph.number_of_edges()} edges")

Querying the Graph

Now we can answer multi-hop questions by traversing the graph. For complex questions, we serialize the relevant subgraph back to Claude for reasoning.

def query_graph(question, graph):
    # Serialize a relevant subgraph (e.g., 2-hop neighborhood of likely entities)
    # For simplicity, we serialize the whole graph here
    nodes_str = "\n".join([f"{n} ({data['type']})" for n, data in graph.nodes(data=True)])
    edges_str = "\n".join([f"{u} --[{data['predicate']}]--> {v}" for u, v, data in graph.edges(data=True)])
    
    graph_context = f"""Nodes:\n{nodes_str}\n\nEdges:\n{edges_str}"""
    
    response = sonnet.parse(
        model="claude-sonnet-4-20250514",
        max_tokens=2048,
        system="You are a knowledge graph query system. Answer questions based on the provided graph.",
        messages=[{
            "role": "user",
            "content": f"Given this knowledge graph:\n\n{graph_context}\n\nQuestion: {question}"
        }],
        response_model=str
    )
    return response
Example: multi-hop question
answer = query_graph("Which astronauts worked on Apollo 11 and what vehicles did they use?", graph)
print(answer)

Measuring Quality

To trust your pipeline, you need to measure precision and recall against a gold standard. Create a small annotated set of documents with known entities and relations, then compare your extraction output.

def evaluate_extraction(gold_entities, gold_relations, extracted):
    # Simple evaluation: exact match on entity names and relation triples
    extracted_entities = set((e.name, e.type) for e in extracted.entities)
    extracted_relations = set((r.subject, r.predicate, r.object) for r in extracted.relations)
    
    gold_entity_set = set(gold_entities)
    gold_relation_set = set(gold_relations)
    
    entity_precision = len(extracted_entities & gold_entity_set) / len(extracted_entities) if extracted_entities else 0
    entity_recall = len(extracted_entities & gold_entity_set) / len(gold_entity_set) if gold_entity_set else 0
    
    relation_precision = len(extracted_relations & gold_relation_set) / len(extracted_relations) if extracted_relations else 0
    relation_recall = len(extracted_relations & gold_relation_set) / len(gold_relation_set) if gold_relation_set else 0
    
    return {
        "entity_precision": entity_precision,
        "entity_recall": entity_recall,
        "relation_precision": relation_precision,
        "relation_recall": relation_recall
    }

Cost/Quality Tradeoffs

Haiku is faster and cheaper but may miss nuanced entities or relations. Sonnet costs more but delivers higher accuracy, especially for entity resolution where conflicting evidence must be weighed. A common pattern: use Haiku for bulk extraction, then use Sonnet for entity resolution and complex queries.

Key Takeaways

• No training data needed: Claude's structured outputs let you extract entities and relations with a single prompt, replacing traditional NER and relation classification pipelines.
• AI-powered entity resolution beats heuristics: Claude can resolve "Buzz Aldrin" vs "Edwin Aldrin" using semantic context, not just string similarity.
• Graph + LLM is powerful for multi-hop reasoning: Serialize your graph back to Claude for complex questions that span multiple documents.
• Always measure quality: Use a small gold standard to track precision and recall, and watch for over-merging or dropped entities.
• Choose your model wisely: Haiku for high-volume extraction, Sonnet for nuanced resolution and reasoning — the cost/quality tradeoff is real.