Entity Extraction mit LLMs – vom Dokument zum Knowledge Graph

Worum es geht

Ein Knowledge Graph ist nur so gut wie die Pipeline, die ihn füllt. Bis 2023 war Entity Extraction ein Spezialgebiet: spaCy, Stanford NER, Custom-Trainings, viele Edge Cases. Mit LLMs ist daraus ein gut beherrschbares Engineering-Problem geworden.

Dieser Artikel zeigt, wie eine moderne Pipeline aussieht, wo sie reibt, und welche Tools die Arbeit abnehmen.

Die vier Schritte einer Extraction-Pipeline

Dokumente
   ↓ Chunking              (Token-Limits, Kontextfenster)
Chunks
   ↓ Extraction (LLM)      (strukturierter Output)
Triplets (Subject, Relation, Object)
   ↓ Deduplizierung        (gleiche Entität, anderer Wortlaut)
   ↓ Resolution            (Anna B. = Anna Becker = anna@acme)
Knowledge Graph

Jeder Schritt hat seine eigenen Stolperfallen. Schauen wir sie der Reihe nach an.

Schritt 1: Chunking

Quelldokumente sind selten gut geschnitten. Verträge sind 80 Seiten, E-Mail-Threads sind 40 Nachrichten, PDFs haben Tabellen. Klassische Strategien:

• Naiv: feste Token-Größen (z.B. 1.000 Tokens, 200 Overlap) – funktioniert für Fließtext, zerstört Tabellen.
• Semantisch: an Absatz- oder Heading-Grenzen splitten – besser, aber langsamer.
• Strukturell: Markdown-Header, HTML-Sections, oder bei PDFs Layout-aware Parser wie Unstructured oder Docling.

Faustregel: Lieber etwas mehr Overlap und kleinere Chunks. Halluzinierte Beziehungen entstehen fast immer, wenn ein Chunk zwei Entitäten erwähnt, ohne deren Beziehung vollständig zu beschreiben.

Schritt 2: Extraction mit strukturierten Outputs

Hier hat sich in den letzten zwei Jahren am meisten geändert. Statt freier Prompts (mit Regex-Parsing) nutzen alle ernstzunehmenden Pipelines heute Structured Outputs – JSON Schema, das das Modell zwingt, korrekt geformte Daten zurückzugeben.

Minimales Beispiel mit Pydantic + Instructor:

from pydantic import BaseModel, Field
from typing import Literal
import instructor
from openai import OpenAI

class Entity(BaseModel):
    id: str = Field(description="kebab-case stable identifier")
    type: Literal["person", "company", "product", "contract", "ticket"]
    name: str
    attributes: dict[str, str] = {}

class Relation(BaseModel):
    source_id: str
    target_id: str
    label: str = Field(description="verb-phrase, lower case")
    confidence: float = Field(ge=0, le=1)

class ExtractionResult(BaseModel):
    entities: list[Entity]
    relations: list[Relation]

client = instructor.from_openai(OpenAI())

result = client.chat.completions.create(
    model="gpt-4.1",
    response_model=ExtractionResult,
    messages=[{
        "role": "system",
        "content": "Extrahiere Entitäten und Beziehungen aus dem Text. "
                   "Verwende stabile ids. Setze confidence ehrlich.",
    }, {
        "role": "user",
        "content": chunk_text,
    }],
)

Was hier wirklich wichtig ist:

1. confidence ist Pflicht. Modelle, die alles mit 1.0 markieren, sind kaputt – aber wenn ihr es nicht fordert, bekommt ihr keine.
2. Stabile ids. Sonst landen „Anna Becker", „A. Becker" und „Frau Becker" als drei Knoten im Graph.
3. Schema möglichst klein. Je mehr Felder ihr fordert, desto schlechter wird die Qualität. Lieber zwei Passes.

Schritt 3: Deduplizierung

Die Realität: Dasselbe Modell extrahiert aus zwei Chunks „Acme GmbH" und „Acme Group" – zwei Knoten, eine Firma. Drei pragmatische Strategien, in der Reihenfolge ihrer Kosten:

• Exact match: normalisiert auf lowercase, Whitespace strippen, Trade-Suffixe (gmbh, inc, ltd) entfernen. Holt 60–70 %.
• Embedding-basiert: Cosine Similarity über Entity-Embeddings + Threshold. Holt weitere 20–25 %.
• LLM-Reconciliation: Kandidatenpaare an ein LLM geben („gleiche Entität? ja/nein"). Holt den Rest, ist aber teuer.

Wir laufen die Pipeline meistens batchweise mit allen drei, in dieser Reihenfolge.

Schritt 4: Entity Resolution

Deduplizierung ist intra-Korpus. Resolution verknüpft mit der Realität: „Anna Becker" ist user_id=4471 im CRM, „Acme GmbH" hat customer_id=cust_8821.

Das geht selten automatisch. Bewährt hat sich:

• Ein Resolution-Layer mit klaren Schlüsseln (E-Mail-Domain → Firma, vollständiger Name + Firma → Person).
• Human-in-the-Loop für die ersten 5–10 % unsicherer Matches. Danach lernt die Heuristik mit.
• Fallback-Knoten für unaufgelöste Entitäten, statt sie wegzuwerfen – sie können später noch aufgelöst werden.

Tool-Vergleich

Tool	Stärke	Schwäche
LlamaIndex KG Index	End-to-End, Neo4j-Integration, schnell zum Prototyp	wenig Kontrolle über Schema
Instructor + OpenAI/Anthropic	volle Kontrolle, Pydantic-typsicher	Pipeline selbst bauen
LangChain GraphIndex	viel Glue, viele Integrationen	viel Abstraktion, hohe Lernkurve
Microsoft GraphRAG	Community Detection eingebaut, batch-orientiert	Python-only, opinionated
Unstructured + Custom Pipeline	bestes PDF/HTML-Parsing	Bauteile selbst zusammenstellen

Unser Default für Prototypen: LlamaIndex KG Index. Für Production: Instructor + eigene Pipeline + Neo4j.

Die häufigsten Fail-Modes

1. Halluzinierte Entitäten: Das Modell erfindet Personen oder Firmen, die im Chunk nicht stehen. → Strikte Prompts („nur, was wörtlich erwähnt wird"), confidence-Filter unter 0.7 verwerfen.
2. Zu viele Beziehungen pro Chunk: Das Modell will alles verbinden. → max_triplets_per_chunk setzen (10–15 ist gut).
3. Inkonsistente Relation-Labels: „arbeitet bei", „angestellt von", „Mitarbeiter:in von" → drei Kanten. → Vorab definierte Relation-Vokabulare oder LLM-basiertes Label-Mapping als Post-Processing.
4. Schema-Drift über Zeit: Neue Dokumenttypen → neue Felder. → Versionierte Schemata, regelmäßige Audits eines Sample.

Kosten-Realität

Für ein typisches Enterprise-Setup (10.000 Dokumente, ~5 Mio. Tokens):

• Extraction mit GPT-4.1 / Claude Sonnet 4.5: 80–200 USD einmalig
• Embedding-basierte Deduplizierung: 5–15 USD
• LLM-Reconciliation: 20–60 USD
• Inkrementelle Updates: ~1–3 USD pro 100 neuen Dokumenten

Das ist weniger als ein Tag Engineering. Der teure Teil ist das Aufsetzen der Pipeline und die Datenmodellierung — nicht die Tokens.

Fazit

Entity Extraction ist 2026 kein ML-Problem mehr, sondern ein Engineering-Problem. Die schwierige Arbeit liegt nicht im Prompt, sondern in den drei Schritten danach: Deduplizierung, Resolution, Schema-Disziplin.

Wer das einmal sauber gebaut hat, kann jeden neuen Dokumentenkorpus in Stunden statt Wochen graph-fähig machen. Das ist der Grund, warum Knowledge Graphs gerade wieder Mainstream werden.

---

Verwandte Artikel:

• Was ist ein Knowledge Graph? – das Konzept dahinter
• GraphRAG vs. Vector RAG – wofür der Graph dann genutzt wird
• Neo4j vs. Kuzu vs. Memgraph – wo der extrahierte Graph wohnt
• Knowledge Graph als Service – wenn ihr die Pipeline nicht selbst bauen wollt