Tiered entity extraction architecture

@@ -22,15 +22,15 @@ cites: []

---

The PointSav [[service-content|entity extraction pipeline]] runs three tiers in sequence on each document (Correction, 2026-08-02: this article's wikilink previously pointed at `service-extraction`, an unrelated single-pass CRM/email ingestion watcher with no GLiNER call, no tiers, and no DPO queue. The real implementing crate is `service-content` — its GLiNER→OLMo→GPU tiered pipeline matches every specific claim in this article almost line for line; corrected here). Tier 0 provides fast extractive detection on CPU. Tier A provides a generative fallback when Tier 0 is unavailable. Tier B provides a higher-capacity GPU enrichment pass and records improvements as training signal.
The PointSav [[service-content|entity extraction pipeline]] runs three tiers in sequence on each document. Tier 0 provides fast extractive detection on CPU. Tier A provides a generative fallback when Tier 0 is unavailable. Tier B provides a higher-capacity GPU enrichment pass and records improvements as training signal.

## Tier 0 — Extractive Detection (GLiNER)

Tier 0 routes document payloads to `service-gliner`, a GLiNER named entity recognition microservice running locally on the workspace VM (`urchade/gliner_medium-v2.1`). GLiNER is a **DeBERTa**-encoder model, not BERT — the real code's own comment notes DeBERTa specifically because it releases the Python GIL, a real performance property BERT does not share. It reads a text span and returns entity spans with classifications, and is purely extractive: it can only return spans that appear verbatim in the input text and cannot generate or infer names that are not present.

Typical latency on CPU is stated elsewhere in the codebase only qualitatively — a comment describes GLiNER as roughly "150x faster than OLMo" — no specific millisecond figure like the one previously cited here was found in source; treat the exact number as unsourced rather than repeat it as fact.
Typical latency on CPU is described only qualitatively — roughly "150x faster than OLMo" — with no specific millisecond figure published.

Documents are split into sentence-boundary chunks of at most 2,000 characters each before dispatch, with a 150-character overlap between consecutive chunks (not previously documented here). The DeBERTa encoder operates on a fixed context of 512 tokens; prose at the 2,000-character limit occupies approximately 480 tokens, leaving room for the label description strings without truncation. All chunks are dispatched in sequence; entity spans from all chunks are merged and deduplicated by (lower(entity_name), classification) key before the result is written to the graph store. Long articles and multi-page documents are therefore fully covered.
Documents are split into sentence-boundary chunks of at most 2,000 characters each before dispatch, with a 150-character overlap between consecutive chunks. The DeBERTa encoder operates on a fixed context of 512 tokens; prose at the 2,000-character limit occupies approximately 480 tokens, leaving room for the label description strings without truncation. All chunks are dispatched in sequence; entity spans from all chunks are merged and deduplicated by (lower(entity_name), classification) key before the result is written to the graph store. Long articles and multi-page documents are therefore fully covered.

Labels are expressed as plain-English descriptions rather than bare category names. The domain identifier in the document payload selects a label set:

@@ -50,7 +50,7 @@ Tier A routes document payloads to OLMo 7B running on the workspace VM's CPU via

Extraction uses a structured prompt that constrains the model to the same five entity classifications used by Tier 0. When grammar constraints are enabled, the model is forced to emit valid JSON conforming to the extraction schema, eliminating schema-violation rejections. The inference call uses `temperature: 0.0` to produce deterministic output and `cache_prompt: true` to allow KV-cache reuse across consecutive extraction calls on the same system prompt.

Tier A latency on CPU varies with document length and concurrent load; no specific range has a source citation, so none is asserted here. When the Doorman's [[apprenticeship-substrate|apprenticeship]] drain queue is active, Tier A slots may be occupied and interactive extraction calls will queue.
Tier A latency on CPU varies with document length and concurrent load and is not published as a specific range. When the Doorman's [[apprenticeship-substrate|apprenticeship]] drain queue is active, Tier A slots may be occupied and interactive extraction calls will queue.

## Tier B — GPU Enrichment

@@ -76,6 +76,6 @@ Documents for which Tier 0 returns a non-empty entity list always proceed to Tie

| Tier | Service | Method | Typical latency | Activates when |
|---|---|---|---|---|
| 0 | service-gliner (GLiNER, DeBERTa) | Extractive span detection | Not sourced — qualitatively "~150x faster than OLMo" per code comment | Default — first path |
| A | [[service-slm|service-slm]] (OLMo 7B CPU) | Generative completion | Not sourced in code | Extraction: Tier 0 unreachable; Training: every document (async) |
| B | service-slm (GPU node) | Generative enrichment | Not sourced in code | Circuit closed + node healthy |
| 0 | service-gliner (GLiNER, DeBERTa) | Extractive span detection | Not published — qualitatively "~150x faster than OLMo" | Default — first path |
| A | [[service-slm|service-slm]] (OLMo 7B CPU) | Generative completion | Not published | Extraction: Tier 0 unreachable; Training: every document (async) |
| B | service-slm (GPU node) | Generative enrichment | Not published | Circuit closed + node healthy |