The base created at registration installs an ontology no local model can hold

[Kmanley1]

The General base installs schema.org at registration (#325, f539e1a, in v0.1.0-rc5). That
pack projects to 915 entity types and 1,625 relation types, and extraction inlines the whole
vocabulary into the system prompt of every chunk. On a fresh install pointed at a local
OpenAI-compatible endpoint, every extraction call fails and the graph stays empty.

Measured

A 9 KB markdown file, 10 chunks, against LM Studio serving openai/gpt-oss-20b:

System prompt	483,102 chars ≈ 104,890 tokens
User message (the chunk)	~250 tokens — 0.24 % of the request
Per document (10 chunks)	~1,051,400 tokens
Document content	~2,304 tokens
Overhead	~456×

The upstream error is explicit:

400 {"error":{"code":400,"message":"request (105140 tokens) exceeds the available
context size (32768 tokens)","type":"exceed_context_size_error",
"n_prompt_tokens":105140,"n_ctx":32768}}

Dividing prompt by vocabulary gives a constant that makes this planable:
~190 chars ≈ 48 tokens per ontology term.

Loaded context	Ontology terms that fit
8,192	~155
32,768	~620
131,072	~2,481
schema.org = 2,540 terms	≈121k tokens — fits none of them

schema.org does not fit even at 131,072, which is gpt-oss-20b's maximum. Raising the context
cannot fix it. Loading the model at the full 131,072 was tried: it loads (7,794/8,188 MiB VRAM plus
RAM spill) and drives the GPU to 100 %, but a single chunk ran 671 s without completing before
being aborted. Ten chunks is upward of two hours for a 9 KB file, when it works at all.

Reproduce

1. Fresh docker compose --profile app up -d on 0.1.0-rc5.
2. Register (creates General with schema.org).
3. Administration → Models → any OpenAI-compatible local endpoint with a context ≤ 131,072.
   Test connection passes — it sends ~74 tokens.
4. Upload any document. Chunking and embedding succeed; every chunk fails extraction.

Two things that make this hard to diagnose

• Test connection passing is misleading. It exercises a trivial completion, so it certifies an
  endpoint that cannot run a single extraction.
• The error is swallowed. The upstream body above is precise, but it surfaces as
  LLM request failed (400 Bad Request): unknown error and the job log says only that 10 of 10
  chunks failed. Nothing names the ontology, the prompt, or the context. Diagnosing it required
  putting a logging proxy between the app and the endpoint. Forwarding the upstream error body
  would turn a multi-hour investigation into a one-line answer.

Why it went unnoticed

It is invisible against a hosted model with a large context window — there it is merely expensive,
and nothing reports the cost. It only fails against a small-context endpoint, i.e. the offline
deployment the README foregrounds ("It deploys offline… on hardware it controls"). #322 weighed
installing schema.org against asking at registration and reasonably chose the former; the
consequence for local endpoints does not appear to have been considered.

Related

• One model does every job in every base #470 — already argues extraction "wants something cheap and fast" and that some bases must
  "stay on a local endpoint". This is the arithmetic showing that combination is currently
  impossible, whatever model is chosen.
• The base created at registration installs no ontology pack #322 / The first base of a deployment starts with a vocabulary #325 — the change that introduced it.
• [UX] Add first-run onboarding for users without ontology expertise #313 — a new user lands in exactly this base.
• Installing several packs embeds the whole ontology once per pack #282 — ontology size already recognised as a cost at install-time embedding, but not in the
  per-chunk extraction prompt.

Possible directions

Not a request for any particular one:

1. Select a relevant ontology subset per chunk rather than sending all of it — the only option
   that scales with vocabulary rather than against it.
2. Default the registration base to a smaller pack. Gzipped: schema-org 207.0 KB, iof-core
   59.3 KB, w3c-org 24.2 KB, prov-o 16.9 KB, foaf 5.7 KB. schema.org is 3.5× the next largest.
3. Warn at KB creation and at model configuration when projected terms × 48 tokens exceeds the
   endpoint's context.
4. Forward the upstream error body instead of unknown error (worth doing regardless).

Not established here

Whether a smaller pack actually fixes it end to end — the arithmetic says a pack under ~155 terms
fits an 8k window, but that was not run. Only one model and one pack were tested.

[Kmanley1]

Ran the control. Same document, same machine, same model, same build — only the vocabulary differs.
A second base was created with ontology_packs: [] and the identical 9 KB file uploaded.

	General (schema.org, installed by #325)	second base (no pack)
Ontology terms	2,540	0
System prompt	483,102 chars	3,674 chars (132× smaller)
Extraction calls	10 × 400	10 × 200
Entities extracted	0	32 (13 facts)

So the ontology is the whole cause; nothing else needed to change.

Two things the control turned up that seem worth having:

1. The corpus did not grow its own ontology. #322 partly justified the empty-vocabulary base on
the grounds that "extraction still works — the ontology grows from the corpus (0003)". On this run
it grew by zero terms — the log says 够格的信号太少，跳过自动扩本体 ("too few qualifying
signals, skipping auto ontology extension"). On a small corpus the no-pack base stays empty, so the
entities come out untyped.

That makes both shipped configurations awkward for a first document: schema.org cannot run against a
local endpoint at all, and no-pack extracts without types. It reads as an argument for a small
default pack rather than either extreme — foaf and prov-o are 5.7 KB and 16.9 KB gzipped against
schema.org's 207 KB.

2. Prompt size and throughput are separate problems. With the tiny prompt the 400s disappear, but
per-chunk latency was 60–716 s, roughly 48 minutes for the one 9 KB file (20B MoE, 8 GB VRAM, rest
offloaded to RAM). Fixing the ontology fixes correctness, not speed — the two were wearing the same
error message. This is more evidence for #470's per-task model split, since extraction is the leg
that wants the cheap fast endpoint.

Happy to run other pack/model combinations if a specific comparison would help.

[WaylandYang]

Thanks for this. The measurement and especially the control run are exactly what was needed, and the conclusion is right: the pack is the whole cause. The mechanism underneath is a little different from "extraction inlines the whole vocabulary", and the difference decides the fix.

Since #85 (in rc5) extraction is not supposed to send the full vocabulary when it is this large. extraction.rs measures the rendered lists against ontology_prompt_budget (24,000 chars by default) and above that it retrieves a per-chunk slice, roughly 40 classes plus their ancestors, 30 relations and 30 attributes, using the chunk's own embedding against the ontology's vectors. schema.org is far above the budget, so your log should contain 本体超出提示词预算，改为按分块检索候选 right before the 105k-token request went out anyway. That request is the fallback: when retrieval returns no candidates, chunk_lists returns None and the caller uses the full list, on the reasoning that a big prompt is slow but no classes at all extracts nothing. Against a 32k window that reasoning is wrong, and it is what you hit.

Why retrieval returned nothing: the ontology's own vectors were never built. Registration installs schema.org and queues an embed_ontology job before there is an embedding model, because on a fresh install the model is configured afterwards. ontology_index::refresh returns 0 without a model, and nothing re-queues it when the model is configured later. Extraction does not call refresh before retrieving (type resolution and the suggestions route do). And because every chunk failed, the document is marked failed before resolve_types is queued, so the one automatic path that would have embedded the classes never runs. First document fails, nothing embeds the ontology, next document fails. On a hosted model the same fallback happens and merely costs money, which is why it went unnoticed; your paragraph on that is right.

You can confirm it from your side:

SELECT count(*) FILTER (WHERE embedding IS NOT NULL), count(*)
FROM entity_types WHERE kb_id = '<General kb id>';

I expect 0 of 915.

On the four directions:

1. Per-chunk subset: already the design; the work is making it actually run, and that is in A Chinese name does not stop the queue, and a stated figure is written down #523. Extraction now builds the ontology index before retrieving, as type resolution does, and saving an embedding model queues embed_ontology for every base, so the index is built while you are still choosing what to upload. One consequence worth knowing: the first extraction in a base waits in the queue for the ontology to embed, and 2,540 terms on a local embedding endpoint is a real wait. It is the right wait; a document extracted while the ontology was invisible is never re-extracted.
2. Smaller default pack: not on this evidence. The slice is sized so the pack's size does not reach the prompt. With retrieval working a chunk carries about 100 to 150 terms, 6 to 8k tokens by your constant, which fits 32k with room and does not reliably fit 8k. If 8k endpoints turn out to matter, the per-chunk constants are the knob, not the pack. Your control run's other finding, that a no-pack base extracts untyped, points the same way.
3. Warning at model configuration: the probe sends one sentence and certifies nothing about extraction; agreed it misleads. Worth its own issue, not the first thing to fix.
4. Forwarding the error body: yes, regardless. err_detail reads error.message and message; whatever LM Studio put in that 400 matched neither, and the fallback should be the raw body truncated rather than "unknown error". Not in A Chinese name does not stop the queue, and a stated figure is written down #523; separate item.

Once #523 is in a build, re-running the same file is the acceptance test, and your table is the before half of it.

[WaylandYang]

Closing: the failure this reports is fixed in #523, now on dev and in the next release candidate. Extraction builds the ontology's vectors before it retrieves, and saving an embedding model queues that build for every base, so the per-chunk slice is what a local endpoint receives.

What remains is tracked on its own: #526 (the wait moves from the worker into the queue), #527 (the upstream error body is forwarded instead of "unknown error"), #528 (the connection test says what it certifies).

When the next rc is out, the same 9 KB file against the same endpoint is the acceptance test; if it still fails, reopen this and it will be looked at first.