Stop HTML-escaping scorer values in the ragas prompts

[Chen Yufeiyang (feiiiiii5)]

The ragas scorers HTML-escape the values they interpolate, so the judge reads a corrupted prompt:

fake.ragas.ContextEntityRecall({ text: 'Is 3 < 5 & 2 > 1? "q"' })
// reaches the model as: text: Is 3 &lt; 5 &amp; 2 &gt; 1? &quot;q&quot;

js/render-messages.ts renders values verbatim and pins that with a test — "should never HTML-escape values, regardless of mustache syntax" — but js/ragas.ts still calls mustache.render with the default escaper at all eight prompt sites. So the same value reaches the judge untouched through the LLMClassifier scorers (Factuality, ClosedQA, …) and entity-encoded through the ragas ones. For anything containing <, >, &, ", ' or / — scraped HTML, source code, maths — the prompt no longer matches the input, and a recorded trace no longer reproduces what was evaluated. Tag names read as literal text can also shift entity extraction.

The fix exports the escapeValue helper that already exists in render-messages.ts and passes it at the eight call sites, so both paths render the same way.

Test: pnpm run test --run js/ragas.test.ts -t "Ragas prompt rendering" fails on 9546b28 for the three scorers above and passes here (4 passed / 6 skipped); the new tests capture the outgoing user message and assert on it. Suite: 69 passed before, 73 after, with the same 8 pre-existing failures either way — all of them Missing credentials … set the OPENAI_API_KEY, which CI supplies from secrets. pnpm run build (tsup, CJS + ESM + DTS) passes, and pre-commit on the three changed files passes. There is no lint or typecheck script in this repo; npx tsc --noEmit reports one pre-existing error in js/render-messages.test.ts that this change does not touch.

Two things to push back on if you disagree:

• This makes JS differ from the Python implementation. py/autoevals/ragas.py renders with chevron, which HTML-escapes by default (verified on chevron 0.14.0, the pinned version), so today both languages escape and the bug is symmetric. The argument for changing JS is the repository's own test and the escape objects to stringified in autoevals #110 commit that fixed render-messages, not cross-language parity. If you would rather have parity, the alternative is to bypass chevron's escaping in Python ({{&text}} or an escape hook) — happy to do that as a follow-up.
• {{statements}} changes shape. It is a string[], so with the verbatim escaper it renders as JSON instead of comma-joined. That moves ragas towards Python (which renders the list directly), but it is a real prompt change at that one site; say the word and I will special-case it.

[Chen Yufeiyang (feiiiiii5)]

Hi @shaina-t @brodsky12 (or whoever picks this up) — four of my ragas/json fixes here have been open since 26 September with green CI, so this is one message rather than four pings.

• Stop HTML-escaping scorer values in the ragas prompts #227 — the ragas scorers HTML-escape the values they interpolate, so Is 3 < 5 & 2 > 1? reaches the judge as Is 3 < 5 & 2 > 1?. js/render-messages.ts renders verbatim and has a test saying it must never escape; js/ragas.ts still used the default escaper at all eight prompt sites. The fix reuses the escapeValue helper that already exists there.
• fix(ragas): resolve the judge model through the library default #226 — the judge model is resolved from the library default instead of being dropped, so ragas scoring runs even when the caller passed no model.
• fix(ragas): score 0 when Faithfulness gets no statements #225 — Faithfulness with no extracted statements scores 1 (a perfect verdict on no evidence) instead of 0.
• fix(json): do not treat booleans as numbers in JSONDiff #224 — JSONDiff treats booleans as numbers, so true vs 1 compares equal.

The question I would most like settled is on #227, because it is the one where a reviewer could reasonably disagree with me: I made the ragas path match render-messages.ts (no escaping at all, since the value is data, not markup), rather than escaping at the template boundary in ragas.ts and leaving the two paths different. If you would rather the escape live in one shared place instead of being removed, say so and I will do that — but then the should never HTML-escape values test in render-messages.test.ts has to change too, which is why I read it as the bug being the ragas side.