Kg Extraction Approach Selector

KG Extraction Approach Selector

Overview

An agent's knowledge comes from heterogeneous sources — relational databases, documents, free text — and each source shape demands a different extraction strategy. The chapter's rule: the source and the reasoning need pick the approach, not the other way round. Forcing one extractor onto every source is the failure this skill exists to prevent.

Four approaches, each with a characteristic profile:

• Structured database integration: the source already has a schema, so materialize it into nodes and edges (batch, CDC stream, or virtual graph views). Deterministic and high-precision — no LLM variance to validate. Only applicable when the source is genuinely structured.
• LLM-based extraction: prompt an LLM for ontology-constrained subject-predicate-object triples from free text. Simplest to stand up and flexible across topics, but non-deterministic; validate against the ontology and route low-confidence extractions to human review.
• iText2KG (incremental): extract entities and relations section-by-section and disambiguate each against the prior set. A growing corpus is extended without re-processing what is already ingested, and no domain-specific schema is required.
• RAKG (document-level): gather every text segment where an entity appears plus related subgraphs before generating relations. Whole-document context and hallucination filtering push relationship fidelity high, at the cost of retrieval infrastructure.

The selector scores each approach across the five features weighted by the caller's source profile. A structured source is a categorical fact (you cannot LLM-extract triples from a relational table), so it hard-routes to materialization; everything else is decided by the weighted scores — an unstructured + growing corpus routes to iText2KG, unstructured + whole-document context routes to RAKG, and a one-shot unstructured pass routes to plain LLM extraction.

The incremental_cost helper makes the iText2KG advantage concrete. Adding 50 documents to a 5000-document corpus: iText2KG processes 50; a full-rebuild approach re-processes all 5000. The savings_vs_rebuild field is the re-extraction a batch pipeline pays on every update.

When to Use

• Choosing how to ingest a specific source into an agentic knowledge graph
• Justifying an incremental vs document-level vs one-shot extraction decision
• Estimating the re-processing cost of a growing corpus under each approach

Phrases: "how to extract this into the graph", "iText2KG vs RAKG", "incremental KG construction", "document-level extraction", "extract triples from documents", "structured database to graph".

When NOT to Use

• Choosing the graph model class. Property-graph vs RDF vs hypergraph is a different decision — use graph-model-selector. This picks the extractor.
• Vendor / product selection. This picks the approach class, not Neo4j-APOC-vs-a-specific-ETL-tool.
• Temporal / bitemporal modeling. Separating observation time from validity periods is the ATOM discussion in the same chapter, out of scope for this four-way selector.
• A mandated ingestion pipeline. If the extraction path is already fixed, adopt it; the scoring is moot.

Process

Rationalizations

Red Flags

• source_type=structured but the profile weights unstructured handling. A contradiction: a relational table is materialized, not LLM-extracted. Re-check the source classification before running the scorer.
• iText2KG chosen for a one-shot batch that never grows. Its incremental disambiguation machinery buys nothing if you extract once. Prefer plain LLM extraction and keep the setup cost low.
• RAKG chosen with no retrieval layer budgeted. Document-level grounding needs the mention-retrieval + subgraph-retrieval infrastructure; without it you are running plain LLM extraction with extra ceremony.
• All extraction routed through one approach across every source. The chapter is explicit that heterogeneous sources need heterogeneous strategies; a single-extractor pipeline is the anti-pattern.

Non-Negotiable Verification

1. Run the benchmark battery. python cli.py benchmark must report 10/10:
   • structured→structured_db, unstructured+incremental→iText2KG, unstructured+doc-context→RAKG, unstructured one-shot→llm_extraction
   • mixed+incremental still routes to iText2KG
   • incremental_cost: iText2KG processes only new_docs, a rebuild processes total_docs, and savings equal total_docs - new_docs
   • all four approaches scored, ordered descending; feature set is the 5 axes
2. Run the scenario. python cli.py scenario growing-infra-telemetry recommends the incremental approach and prints the per-update saving.
3. Verify CLI help. python cli.py --help exits 0 and prints this SKILL.md description (so any harness can discover the skill from --help).

Security Posture

• Prompt injection. The source profile is data-only knobs scored against fixed feature tables; adversarial values can at most skew the recommendation. The real injection surface is downstream: LLM/iText2KG/RAKG extraction runs prompts over untrusted documents, so the chosen pipeline - not this selector - must filter adversarial document content before extraction.
• Data exfiltration. No network calls, no file writes. Corpus statistics and source descriptions stay in-process; the report goes to stdout and the caller owns downstream piping.
• Privilege escalation. No shell invocation, no eval, no dynamic import. The recommendation is advisory - standing up the actual ingestion pipeline (DB credentials, retrieval infrastructure) happens elsewhere under the platform's own access controls.

Source Attribution

Distilled from Agentic GraphRAG (O'Reilly, by Anthony Alcaraz and Sam Julien) Ch3 — Building the Knowledge Graph, section "Extraction Approaches for Heterogeneous Sources": structured database integration (graph materialization / virtual views / hybrid), LLM-based extraction of ontology-constrained triples, and the two LLM construction frameworks the chapter names — iText2KG (incremental, topic-independent, schema-free with entity disambiguation) and RAKG (document-level retrieval-augmented construction; reported 96% accuracy, 88% entity coverage, 95% relationship fidelity). The temporal ATOM framework from the same section is deliberately out of scope for this four-way selector.