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

| Step | Input | Action | Output | Verification | |------|-------|--------|--------|--------------| | 1 | Source profile (sourcetype + 5 knobs) | lib.score_approaches(profile) | [(approach, score), ...] sorted desc | weights * feature-scores, descending order | | 2 | Same | lib.recommend_approach(profile) | {recommended, ranked, rationale, source_type} | structured→structureddb; unstructured routes by dominant knob | | 3 | new_docs, total_docs, approach | lib.incremental_cost(...) | {docs_processed, docs_reprocessed, savings_vs_rebuild, ...} | iText2KG processes newdocs; rebuild processes totaldocs | | 4 | A named scenario | cli.py scenario growing-infra-telemetry | recommendation + incremental cost | recommends iText2KG and prints the re-processing saving |

Rationalizations

| Agent rationalization | Documented rebuttal | |------------------------|--------------------| | "LLMs extract from anything, just prompt one for every source." | For an already-structured source that discards deterministic precision and adds hallucination risk for zero benefit. The chapter integrates structured sources by materialization (APOC / CDC / virtual views), not by LLM triples. Match the extractor to the source. | | "Re-run the whole extraction on every corpus update; simpler." | incremental_cost shows the bill: re-processing 5000 documents to add 50 is 100x wasted work, and LLM extraction is neither free nor deterministic across runs. iText2KG extends the graph and disambiguates against the prior set — that is the entire point of the incremental approach. | | "iText2KG is incremental, so always pick it." | Incremental construction reasons within a section and disambiguates across sections; it does not gather every mention of an entity across a whole document the way RAKG does. When a relation depends on cross-document context, RAKG's retrieval-augmented grounding (higher relationship fidelity, hallucination filtering) is the right call. | | "Document-level RAKG has the best benchmark numbers, use it everywhere." | RAKG's 96%/88%/95% come with retrieval infrastructure and per-entity context gathering — heavier setup than a one-shot LLM pass, and pointless on a structured source or a corpus that never needs whole-document context. High benchmark numbers on one axis do not make it the default. | | "The source is a mix, so I can't decide." | Score the profile: a mixed source still handles unstructured text (weight 3), and the growth / document-context knobs route it exactly as an unstructured one would. Materialize the structured part, run the chosen LLM framework on the rest — record the split as a conscious decision. |

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
• incrementalcost: iText2KG processes only newdocs, a rebuild processes

total_docs, and savings equal total_docs - new_docs

• all four approaches scored, ordered descending; feature set is the 5 axes

1. Run the scenario. python cli.py scenario growing-infra-telemetry

recommends the incremental approach and prints the per-update saving.

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: AnthonyAlcaraz
• Source: AnthonyAlcaraz/agentic-graph-rag-skills
• License: MIT
• Homepage: https://www.oreilly.com/library/view/agentic-graphrag/9798341623163/

Install and usage instructions live in the source repository linked above.