Skip to content

feat(evals): score suggest_edge_types, and answer #508 with the numbers - #512

Merged
jasonssdev merged 1 commit into
mainfrom
feat/508-edge-typing-eval
Aug 9, 2026
Merged

feat(evals): score suggest_edge_types, and answer #508 with the numbers#512
jasonssdev merged 1 commit into
mainfrom
feat/508-edge-typing-eval

Conversation

@jasonssdev

Copy link
Copy Markdown
Owner

Closes #508. src/ is untouchedevals/ and CHANGELOG.md only.

#508 asked for confidence-threshold auto-acceptance and named a cap-harness A/B as the gate on any prompt change. That gate did not exist: evals/ scored extraction, and nothing scored this suggester at all.

evals/edge_typing/ is that gate. Type accuracy against labelled pairs whose answers _RELATION_RUBRIC decides on its own, plus stability (modal share across runs — no labels needed), type distribution, and calibration when an arm asks for a confidence.

Finding 1 — the suggester fails its own rubric, confidently

Measured on qwen3:8b, 15 labelled pairs, 5 runs:

metric baseline
type accuracy vs label 0.35
mean stability 0.99
related_to share 0.65

It answers related_to where a document says "it happened because the payment gateway migration removed a header", and part_of where one says "one of the scheduled maintenance jobs… each registered the same way" — cases the prompt's own tie-break chain says resolve to caused_by and member_of.

Stability of 0.99 means it is not guessing. It is confidently and reproducibly wrong, which is a much larger problem than the automation ergonomics #508 set out to improve. Filed separately.

The fixture reproduces the field distribution independently: related_to lands at 0.65–0.67 here against a measured 67% on a real bundle (edge_typing.py:146).

Finding 2 — this is why no threshold ships

Same fixture, both arms:

metric baseline confidence arm
accuracy 0.35 0.37
stability 0.99 0.96
latency 19.6s 23.2s

Asking for a confidence is quality-neutral at ~18% more latency, and the signal is real but insufficient:

threshold admitted precision
none 100% 0.37
>=0.6 27% 0.65
>=0.9 15% 0.73

0.73 means roughly one auto-applied relation type in four is wrong by the rubric. #385's concern was that bulk acceptance "would rapidly apply a lot of low-value material"; writing wrong types unattended at that rate is not an improvement on asking a human.

So no threshold gate ships, and the confidence field was reverted rather than left in production with no consumer. The harness stays — it is what makes the next attempt measurable instead of hopeful.

A methodology error I made and corrected

The first baseline/treatment pair spanned a fixture that grew from 7 to 15 edges mid-investigation, which made the comparison worthless — the same trap extraction_cap already records from the other direction, where comparing fixtures at different adjudication depths under-reported Spanish recall by half. Both arms were re-run on the final fixture and the README states the rule.

Labels are constructed, not adjudicated, and the README says so plainly: read accuracy as rubric-consistency, not field accuracy.

Disclosure: no review receipt

Same lens defect as PRs #503, #506, #507, #509, #510 and #511.

Closes #508.

#508 asked for confidence-threshold auto-acceptance and named a
cap-harness A/B as the gate on any prompt change here. That gate did not
exist: `evals/` scored EXTRACTION and nothing scored this suggester, so a
change would have been adopted on intuition -- which this project has
already paid for once.

`evals/edge_typing/` is that gate. It scores type accuracy against
labelled concept pairs whose answers `_RELATION_RUBRIC` decides on its
own, plus stability (modal share across runs, no labels needed), type
distribution, and calibration when an arm's prompt asks for a
confidence.

Two findings, measured on `qwen3:8b` over 15 pairs, 5 runs per arm, the
SAME fixture in both arms.

The suggester answers roughly two thirds of decidable pairs against its
own rubric, at a stability of 0.99: `related_to` where a document says
"it happened because", `part_of` where one says "one of the ... each
registered the same way". It is not guessing. It is confidently and
reproducibly wrong, which is a larger problem than the automation
ergonomics #508 set out to improve. Filed separately.

Asking for a confidence is quality-neutral -- accuracy 0.35 -> 0.37,
stability 0.99 -> 0.96, ~18% more latency -- and the signal is real but
insufficient. Thresholding lifts precision from 0.37 to 0.65 at >=0.6
(27% of emissions admitted) and 0.73 at >=0.9 (15% admitted). At 0.73,
roughly one auto-applied relation type in four is wrong by the rubric.
#385's concern was that bulk acceptance would rapidly apply low-value
material; writing wrong types unattended at that rate is not an
improvement on asking.

So no threshold gate ships, and the confidence field is reverted rather
than left in production with no consumer. `src/` is untouched by this
commit.

The first baseline/treatment pair spanned a fixture that grew from 7 to
15 edges mid-investigation, which made it worthless; both arms were
re-run on the final fixture and the README states the rule.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

curate: confidence-threshold auto-acceptance needs the suggesters to expose confidence first

1 participant