Picking the extraction LLM for knowledge-graph ingestion:breadth beats density, and Gemini 2.5 Flash wins on cost.

The extractor decides retrieval and cost, so measure it directly.

If you are standing up a knowledge-graph RAG system, the extraction LLM is the choice the benchmarks quietly make for you, and it is the one that moves your retrieval quality and your bill the most.

The companion memory substrate report answers the question "which graph substrate." This note answers the question that operationally dominates it for any system in this class: which LLM the substrate should use during ingestion. The choice is not interchangeable. It controls retrieval quality more than the substrate choice does, and it controls cost by an order of magnitude or more. Eleven candidates were evaluated against a fixed twenty-document subset and a twenty-four-cell smoke rubric. One model passed every cell, then was validated on a separate 482-document legal corpus before being recommended for production. The measurements are on LightRAG, the canonical open-source implementation of this class, but the findings are about the class.

The extraction LLM is the substrate.

Knowledge-graph RAG systems share one ingest shape. The published benchmarks for these systems hold the extractor constant, the architecture diagrams hide it inside the ingest box, and the ablation tables vary chunk size and retrieval mode but not the extractor. In production it is the variable that decides what your graph looks like. The class includes Microsoft GraphRAG, LightRAG, and the smaller ecosystem of similar pipelines on Neo4j vector-plus-graph storage. They differ in retrieval strategy, graph schema, and configuration surface; they share the same ingest pattern. For each chunk of source text, an LLM extracts entities, an LLM extracts relations among them, an LLM summarises an entity that appears across many chunks, and an LLM gleans a second pass to recover missed extractions. All four are LLM calls. The call dominates wall-clock time, dominates dollar cost, and produces every node and edge in the graph. The graph is what retrieval traverses, so the extractor's biases become permanent properties of the substrate until you re-ingest from scratch.

The published benchmarks rarely specify or vary the extractor. LightRAG's paper names gpt-4o-mini for some runs and reports retrieval scores; it does not study sensitivity to extractor choice. A reader who deploys with the upstream defaults gets gpt-4o-mini as the implicit extractor and inherits its limits without ever seeing the choice. That implicit-default-as-decision pattern is the failure mode this note makes explicit. Three properties of the extractor show up downstream.

• Entity count per document. Determines how much of the chunk text is reachable from any given query. More entities means more anchor points, means more chunks retrievable when a query lands on any of them.
• Schema fidelity. LightRAG expects pipe-delimited records. Models that violate the format have their output dropped by the parser. Schema noise looks like missing data in the graph but is actually rejected extraction.
• Description quality. When LightRAG summarises an entity that appears across many chunks, that summary becomes the canonical description stored in the graph. A weak summary degrades query-time matching even when the entity was extracted correctly.

None of this is what a chat-quality benchmark measures. The extractor's job is structured-text production under a tight schema with no narrative, so the best chat model on Arena leaderboards is not necessarily the best extractor.

The rubric is fixed before any model runs.

Stating the rubric a priori is what makes a benchmark reproducible; stating it post hoc reduces to a justification of whatever happened. Five things held constant across all eleven model rows: the corpus, the chunking, the embedder, the smoke rubric, and the reporting columns. The corpus is twenty documents pinned by explicit file list, not by directory glob, so the same files are ingested for every row; a benchmark that uses "the first twenty files alphabetically" silently drifts as new files land. Chunking uses LightRAG defaults, 1200 tokens per chunk with 100 token overlap, about four chunks per document. The embedder is a local 1024-dimensional model held constant so the variable under study is the extractor only.

The smoke rubric is six canary queries times four retrieval modes, naive, local, global, and hybrid, which equals twenty-four cells per model. Each cell is scored pass, marginal, or fail by the same evaluator against the documented expected references, and the cells and references were written before any model ran. Each row records entities per document, relations per document, the relation-to-entity ratio, the smoke score, and measured cost on the twenty-document subset, with cost taken at the provider's invoice level, not estimated. A separate 482-document legal corpus was used for production-class validation of the winning model.

Eleven rows, one clean winner.

The full table lives in the model-matrix artefact. The headline rows, sorted by smoke score, show one model with a strict 24/0/0 and a spread of density numbers that, read alone, would mislead. Note that gpt-4o-mini's density columns come from a 150-document full-corpus run rather than the pinned twenty-document subset, so its smoke score is comparable here while its entity and relation counts are not, and Llama 3.2 3B's ratio reflects only the relations that survived schema validation after the parser dropped most as malformed.

Three observations the table does not state outright. The two Gemini "newer is better" hypotheses, 3-flash-preview and 3.1-flash-lite-preview, both lost to 2.5 Flash; the 3.x line extracts more conservatively, produces sparser graphs, and loses smoke cells on the queries that need breadth. Newer is not better for this task. The relation-to-entity ratio is misleading on its own: Sonnet 4.6 has the highest ratio, 1.43, and still lost cells to Gemini Flash at 1.15, because a high ratio with a low absolute count is a dense little graph with poor coverage. And small open-source models do not fail gracefully: the 3B Llama row ran to completion while LightRAG's parser silently dropped most of its relation output, a failure invisible without explicit schema-violation counting.

Why the lower ratio wins on traversal.

The counter-intuitive finding sits in two columns of the matrix. Gemini 2.5 Flash produces a graph with two times the entities and 1.6 times the relations per document of Claude Sonnet 4.6, but its relation-to-entity ratio is lower, 1.15 against 1.43. On a chat benchmark you would expect the higher-ratio extractor to win on synthesis because each entity is more richly connected. On this benchmark the opposite happens: the model that produces more loosely connected nodes wins.

The mechanism is in the retrieval shape shared by every system in this class. A query is embedded and matched against entity nodes, the top-k entity neighbourhoods are traversed, and the chunks that originally produced those entities are fetched and returned. Whether the right chunk gets returned depends primarily on whether any entity in that chunk matches the query, not on how densely entities link to each other. Doubling the entity count roughly doubles the surface area the entity index covers, which roughly doubles the probability that a query lands on at least one entity from each chunk that should be returned. Relation density matters too, but only on the smaller class of queries that need multi-hop traversal across the graph; most production queries look like "what does this corpus say about X," and for those, breadth of the entity index dominates density of the relation index.

This generalises across knowledge-graph RAG systems with traversal-then-fetch retrieval: optimise the extractor for entity coverage first, and optimise for relation density only when the query distribution actually rewards it. It does not generalise to systems that score retrieval purely on relation paths, a smaller class than the literature implies, or to pure vector RAG without an entity index.

Normalised so you can project your own corpus.

The cost table covers the commercial rows measured on the twenty-document smoke corpus plus one local row that finished all twenty documents. Per-100-document figures are derived as documented in the cost-model artefact. This note does not name a total dollar figure because the absolute number depends on document length, chunking, gleaning aggressiveness, and the contract price with whatever gateway sits in front of the model. Each document on this corpus produced about four chunks of 1200 tokens, and LightRAG made about 2.5 LLM calls per chunk on average, with each call consuming roughly 8K input and producing roughly 2K output tokens. That comes to about 80K input plus 20K output tokens per document, or 8M input plus 2M output per 100 documents, before any gleaning overhead.

Two caveats live with the Sonnet row. The six-to-nine-times range is the list-price calculator; the measured invoice on the twenty-document smoke corpus ran roughly thirty to thirty-three times Gemini Flash because gleaning fired more aggressively and the model added explanatory text the calculator does not anticipate. Use the list ratio for contract pricing and the invoice ratio for projecting re-ingest cost at the wrong model's rate. The local row shows zero inference cost; the workstation, GPU, power, and wall-clock time it consumes are independent of model choice and not included.

The ranking conclusion is robust to multiplicative pricing factors below roughly ten times. Gemini 2.5 Flash is cheaper than Sonnet 4.6 on every published rate card surveyed here and is the only model in the matrix with a strict 24/0/0 smoke score. The cheapest model that hits 24/0/0 is the production answer, and nothing in the cost table flips that. An enterprise gateway discount changes the absolute numbers but rarely changes the ratios inside the cluster.

Hardware is the binding constraint, and reasoning mode is a tax.

The local-extractor question matters separately from cost, because some corpora cannot leave the operator's machine for sensitivity reasons. For those the question is not "is local cheaper," since cloud is so cheap on this workload that the cost argument barely survives, but "is local viable at all." Six local trials ran across two hardware tiers, a consumer-class GPU with 6 GB VRAM and a 32 GB Apple Silicon workstation. The 4B-class models in the 6 GB tier ran end-to-end; mid-size 14B-class models on the Apple Silicon tier ran with partial completion; 26B-class and above did not complete on either tier within the worker-timeout shape. None of the local rows cleared the smoke rubric against Gemini Flash. Qwen 3.5 4B no-think scored highest among the structurally usable local graphs at 8/4/12, and a Qwen 2.5 14B GGUF Q4 build on M1 Max was the best Apple Silicon completion at 5/4/15 on nineteen of twenty documents, not cross-comparable to the full-corpus rows. Neither approaches 24/0/0.

Default to Gemini 2.5 Flash, and re-run the rubric on your own corpus.

• Default extractor. Gemini 2.5 Flash via the provider gateway you already use. Re-validate the smoke rubric on a twenty-document subset of your own corpus before locking it in; the rubric file is small enough to keep in your repo.
• Reject the implicit gpt-4o-mini default. Several systems ship a small-tier model as the implicit extractor. It is three to five times cheaper at list price and loses cells you will care about; if you cannot upgrade it, at least make the choice explicit so future operators see it.
• Treat the relation-to-entity ratio as diagnostic, not a target. A ratio above ~1.4 with entity count below ~30 per document is a dense small graph that underperforms at scale; a ratio near 1.0 with entity count above ~60 is a wide sparse graph that traverses well.
• For local-only corpora driven by data residency. A 14B-class GGUF Q4 model on a 32 GB-or-larger Apple Silicon host, or a 4B no-think model on a consumer GPU, are the structurally viable options. Neither clears Gemini Flash; pair either with a separate query-time model for synthesis and accept the trade of retrieval breadth for residency.
• Where these numbers do not transfer. A corpus dominated by structured data, pure narrative, or specialist vocabularies may rank models differently; absolute breadth varies by roughly two times across corpora; changing chunk size, embedder, or contract pricing shifts magnitudes more than ratios. Each scope claim has a falsification condition in the invalidation artefact.

The takeaway for a delivery team is not the specific model; Gemini 2.5 Flash will be obsolete by the next reading. The thing to take is the discipline: when the substrate's published benchmarks hold a variable constant, that variable is usually the one that decides outcomes in production. Name it, run a smoke rubric on it before locking it in, and instrument the deployment so the documented decision survives day-to-day operations.