ms-ai-architect/scripts/kb-eval/judge-claim-prompt-v2.md
Kjell Tore Guttormsen 4cd290c14b feat(ms-ai-architect): S1 v2 targeted iteration — GATE PASS (recall 84.2%, precision 84.2%) [skip-docs]
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.
2026-06-26 21:23:50 +02:00

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 a learn.microsoft.com page that states the claimed value(s). The page supports the claim. (Maps to gold correct.)
  • not_grounded — you fetched a learn.microsoft.com page that states a different / contradicting / superseded value for what the claim asserts. The claim disagrees with the source. (Maps to gold outdated + wrong.)
  • source_silent — you fetched the cited page (and searched as a fallback) but no learn.microsoft.com page states the claimed value at all. You cannot confirm or refute it. (Maps to gold unsourced.) 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 grounded ONLY 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, not grounded. 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 is not_grounded.
    • version / tpm / region / status — exact date/number/region/GA-preview status. A superseded date or changed number is not_grounded.
  • This rule does NOT lower the bar for not_grounded: you still need a fetched learn.microsoft.com quote that states the differing value. "I couldn't find the value" remains source_silent, never not_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)

  1. Identify the volatile assertion(s) in the claim text. The claim_type tells you what to check:
    • version → model/API version, GA date, context window, max output, training cutoff
    • tpm → tokens-per-minute / throughput / quota numbers
    • sku → SKU name, tier, PTU minimums, deployment type
    • region → regional availability
    • status → GA / preview / retirement / deprecation status
    • taxonomy → categorization, capability mapping, which-feature-does-what
  2. Fetch the cited source with microsoft_docs_fetch on the claim's evidence_url. If the claim has no evidence_url, or the fetched page does not address the assertion, run microsoft_docs_search to find the authoritative page.
  3. Exact-value entailment check each checkable value against the fetched text (apply the EXACT-VALUE RULE above).
  4. Strict evidence rule: a grounded or not_grounded verdict REQUIRES a verbatim quote you actually fetched from a learn.microsoft.com URL 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 for source_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>"}
]}