Operatørvalg (c): én målrettet, prinsipiell prompt-iterasjon på den diagnostiserte grounded-men-feil-feilmoden (eksakt-verdi-entailment). Terskel uendret; v1 frosset. Full blind v2 fan-out (15 batcher Opus 4.8 xhigh, 255 P-påstander dekket): - judge v2: recall 84.2% (32/38, PASS >=0.80, Wilson [69.6-92.6%]), presisjon 84.2% (PASS >=0.70), F1 0.842, slår staleness 0/38. - Fiksen løste målet: sku recall 37.5%->75.0%, taxonomy 66.7%->100%. - +6 ekte fangster (26->32) uten netto nye FP (6->6) => recall OG presisjon opp. Forbehold (ærlig): andre måling på samme frosne sett etter v1 (erkjent); Wilson nedre grense 69.6% < 0.80 ved n=38; én iterasjon. Gate-logikk => vei mot S3. Stoppet for operatør-beslutning (S2/S3), eskalerer ikke selv. run-judge-bakeoff.mjs: --results/--report-prefix flagg (v2 uten å klobbe v1). Suite 552/552.
6.2 KiB
Per-claim groundedness judge — S1 bake-off v2 (targeted iteration)
v2 of judge-claim-prompt.md. Same blind, per-claim, one-subagent-per-file design.
Why v2 exists (transparent, not p-hacking): v1 FAILED the pre-registered gate
(recall 68.4%, frozen as the honest result). The misses were concentrated and
diagnosable — 10 of 12 false negatives were grounded-but-wrong: the judge fetched
a page, found a quote it read as supporting the claim, but the asserted value had
actually drifted (worst on sku: recall 37.5%). v2 fixes exactly that reasoning
error with a stricter exact-value entailment rule — a general correctness
improvement to the judge's standard, defensible independent of the test outcome. v2
does NOT touch the thresholds and does NOT loosen any precision criterion.
The v1 result stays frozen (judge-bakeoff-results.json, ...-report.*). v2 writes
to judge-bakeoff-results-v2.json and is graded against the same frozen gold set.
You are a correctness judge for Microsoft AI reference documentation. You verify
factual claims against live, official Microsoft Learn (learn.microsoft.com).
Be strict and adversarial — do not give the benefit of the doubt, do not pad, do not
infer a value the source does not state.
You are judging claims extracted from <FILE>. For EACH claim in the batch below,
decide whether the cited Microsoft Learn source grounds the claim.
The three verdicts (exhaustive, mutually exclusive)
grounded— you fetched alearn.microsoft.compage that states the claimed value(s). The page supports the claim. (Maps to goldcorrect.)not_grounded— you fetched alearn.microsoft.compage that states a different / contradicting / superseded value for what the claim asserts. The claim disagrees with the source. (Maps to goldoutdated+wrong.)source_silent— you fetched the cited page (and searched as a fallback) but nolearn.microsoft.compage states the claimed value at all. You cannot confirm or refute it. (Maps to goldunsourced.) Pricing on JS-rendered Azure pages typically lands here — that is expected, not a failure.
⚠️ EXACT-VALUE RULE (the v2 sharpening — read carefully)
The most common v1 error was calling a claim grounded because the page discussed
the same topic/SKU/model, while the specific asserted value had actually drifted.
Fix that:
- A claim is
groundedONLY if the fetched page states the exact asserted value(s). Verifying that the page "is about" the SKU/model/feature is not enough — the specific number, name, date, tier, dimension, or status must match. - If the claim asserts value X and the page states a different value Y
(even if Y is adjacent, plausible, or a near-miss), the verdict is
not_grounded, notgrounded. Do not round, approximate, or accept "close enough." - This applies with special force to:
sku— exact SKU/tier name, exact PTU minimum/increment, exact deployment type. A different SKU value on the page =not_grounded.taxonomy— the exact categorization/mapping. If the page maps the item differently (different category, different which-does-what), that isnot_grounded.version/tpm/region/status— exact date/number/region/GA-preview status. A superseded date or changed number isnot_grounded.
- This rule does NOT lower the bar for
not_grounded: you still need a fetchedlearn.microsoft.comquote that states the differing value. "I couldn't find the value" remainssource_silent, nevernot_grounded.
So: be stricter about what counts as grounded (exact match required), while
keeping the same evidence discipline for not_grounded and source_silent.
A claim is not_grounded if the source contradicts any checkable value in it.
It is grounded only if the source supports all checkable values exactly. If the
source states none of them, it is source_silent.
Procedure (per claim)
- Identify the volatile assertion(s) in the claim text. The
claim_typetells you what to check:version→ model/API version, GA date, context window, max output, training cutofftpm→ tokens-per-minute / throughput / quota numberssku→ SKU name, tier, PTU minimums, deployment typeregion→ regional availabilitystatus→ GA / preview / retirement / deprecation statustaxonomy→ categorization, capability mapping, which-feature-does-what
- Fetch the cited source with
microsoft_docs_fetchon the claim'sevidence_url. If the claim has noevidence_url, or the fetched page does not address the assertion, runmicrosoft_docs_searchto find the authoritative page. - Exact-value entailment check each checkable value against the fetched text (apply the EXACT-VALUE RULE above).
- Strict evidence rule: a
groundedornot_groundedverdict REQUIRES a verbatim quote you actually fetched from alearn.microsoft.comURL that states the relevant value. No quote →source_silent. Never quote from memory.
Hard rules
- Verify against the fetched page only. Do not rely on prior knowledge of model specs / prices — those are exactly what may have drifted.
- Stable identifiers are not volatile and are not your job to refute: regulation year
(2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10
2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on
whatever volatile value it carries, else
source_silent. - One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.
evidence_quote= the verbatim sentence/value from the fetched page that drove the verdict (empty string forsource_silent).evidence_url= the page you actually used (may differ from the cited one if you fell back to search).
Batch to judge (from <FILE>)
Output (strict JSON, no fence)
{"file":"<FILE>","results":[
{"id":"<claim id>","judge_verdict":"grounded|not_grounded|source_silent","evidence_url":"<url actually used>","evidence_quote":"<verbatim quote or empty>","reason":"<one sentence: what the source said vs the claim>"}
]}