# LLM の出力を「実際に動かして」採点する eval ハーネスの作り方 安いモデルへ処理を落として良いかを判断するために、社内で LLM の成功率を測る eval を持つのは有効です。 ただし**採点が正規表現だと、正しい答えを落とし、間違った答えを通します**。 この指示書は、①生成コードを安全に実行して振る舞いで採点する仕組み、②課題自体が壊れている時の切り分け方、 ③実行を安全に閉じ込める方法（ここに実在する脱出経路があります）をまとめたものです。 対象: Node.js（v20+）。依存の追加は不要（`node:vm` / `node:test` のみ）。 --- ## 1. まず「課題が壊れている」のを検出する プロバイダを横断して同じ課題を解かせると、**参加者の半数以上が落とす課題**が出てきます。 これはモデルの優劣ではなく、**課題側の欠陥**であることがほとんどです。 そのまま順位付けに使うと「たまたま採点者の期待に合った1つ」を選ぶだけになります。 集計側にこの検出を入れてください。 ```js export function suspiciousTasks(rows) { const byId = new Map(); for (const r of rows) for (const task of r.tasks || []) { const x = byId.get(task.id) || { id: task.id, participants: 0, failed: 0 }; x.participants++; if (task.status === 'fail' || task.status === 'error') x.failed++; byId.set(task.id, x); } // 半数以上が落とした課題は、推薦の根拠から外す return [...byId.values()].filter((x) => x.failed * 2 >= x.participants); } ``` **重要**: 検出して除外しただけで放置しないこと。除外は応急処置で、課題は直さないと永久に測れないままです。 ## 2. 「設問の欠陥」か「採点基準の欠陥」かを切り分ける 除外された課題を直す時、**どちらを直すかは保存した実出力を読まないと決まりません**。 実行ログには必ず各回答の**本文**と**採点理由**を保存しておいてください（これが無いと切り分け不能です）。 見分け方は単純です。 | サイン | 原因 | 直し方 | |---|---|---| | 落ちた回答が**どれも同じ誤り方**をしている | **設問が二義的** | 設問を一意にする | | 落ちた回答が**互いに違う書き方**で、どれも動作としては正しい | **採点が実装スタイルを過剰指定** | 採点方式を変える | ### 設問の欠陥の実例 日本語の返信を書かせる課題で、prompt が 「打合せを**14時から15時へ**変更できますか」でした。 これは「14時→15時への変更」とも「14時〜15時の枠」とも読めます。 採点基準は前者を期待していたため、**後者に解釈した大多数が全滅**しました。 → `14時開始から15時開始へ` と一意化しただけで、**1/7 → 7/7 合格**。 多数派が同じ読みをしたなら、多数派が間違っているのではなく設問が二義的です。 ### 採点基準の欠陥の実例 「fn を最大3回、100ms・200ms の待機を挟んで再試行する `retry(fn)` を書け」という課題を、 複数の正規表現の AND で採点していました。そのうち1本が ``` (?:<\s*3|<=\s*3|attempt|retries|delays\.length) ``` ＝**「リトライ回数を数えるカウンタ変数があること」**を要求していました。 ところが `.catch()` を連鎖する実装は**動作が完全に正しいのに**カウンタを持ちません。 正しい答えが、書き方だけを理由に落ちていたわけです。 **ここで正規表現を緩めても直りません。** 別の任意な表層プロキシになるだけで、 「なぜその表層で判定してよいのか」を説明できない状態は変わりません。 → **測りたい性質（振る舞い）を直接測る**方式へ変えます。 ## 3. 生成コードを実行して振る舞いで採点する 課題の期待値に `exec_js` 型を追加します。チェック関数は **JSON ではなく実コードのファイルに書きます** （JSON 文字列に JS を埋めるとエスケープ事故が起きます）。 課題定義側: ```json {"id":"code-03","category":"code","prompt":"...","expect":{"type":"exec_js","check":"retry-3x-100-200"}} ``` チェック関数側（`eval-exec-checks.mjs`）: ```js import vm from 'node:vm'; export function extractCode(text) { const source = String(text ?? ''); const blocks = []; const fence = /```(?:javascript|js)?[ \t]*\r?\n([\s\S]*?)```/gi; for (const m of source.matchAll(fence)) blocks.push(m[1]); // 説明文とコードが混ざるので、最も長いフェンスを採用する return blocks.length ? blocks.reduce((a, b) => (b.length > a.length ? b : a)) : source; } ``` **採点は必ず2ケース以上**にしてください。1ケースだと「常に失敗する実装」や 「常に成功する実装」が通ってしまいます。 - 全失敗ケース: `fn` が**ちょうど3回**呼ばれ、待機が `[100, 200]`、最終的に **reject** する - 3回目成功ケース: `fn` が**ちょうど3回**呼ばれ、期待値で **resolve** する 各ケースは**別々のコンテキストでコードを評価し直す**こと（モジュールスコープに状態を持つ実装が 2回目で壊れるのを避けるため）。 ### 時間を実際に待たない `setTimeout` を偽物に差し替え、**待機ミリ秒を記録して即実行**します。これで数百 ms の待機が 0 になります。 ```js const recordedDelays = []; const handles = new Map(); let nextHandle = 1; const setTimeout = (callback, ms) => { recordedDelays.push(ms); const handle = nextHandle++; handles.set(handle, setImmediate(() => { if (!handles.has(handle)) return; handles.delete(handle); callback(); })); return handle; }; const clearTimeout = (handle) => { const immediate = handles.get(handle); if (immediate !== undefined) clearImmediate(immediate); handles.delete(handle); }; ``` ### `const retry = ...` を拾う `vm.runInContext` に渡したコードの `const` / `let` はグローバルに乗りません。 評価するコードの末尾に一行足して回収します（構文エラーの回答があるので try/catch で包む）。 ```js const exposed = `${code}\n;try{globalThis.retry=retry}catch(e){}`; vm.runInContext(exposed, ctx, { timeout: 2000 }); const fn = ctx.retry; // function 宣言でも const でもここに来る ``` --- ## 4. 【最重要】実行はサンドボックスから出られてはいけない 採点対象は**モデルが書いたコード**です。実行するなら閉じ込めが前提になります。 ここに**多くの実装が踏む実在の脱出経路**があります。 ```js // ❌ ダメ: これがあると脱出できる vm.createContext({ Promise, Object, Array, JSON, Math, Error, setTimeout, console }); ``` 渡した組み込みは**ホスト側のオブジェクト**なので、`X.constructor` がホストの `Function` になります。 ```js Promise.constructor('return process')().env.X = '1'; // ホストの process = fs / child_process に到達 ``` `Object` / `Array` / `Error` / `JSON` でも同じです。`require` や `process` を隠していても無意味です。 **「危険なものを渡さない」だけでは足りず、「渡した無害そうなものから危険なものへ辿れる」**のが本質です。 ```js // ✅ 正: 自作の偽 API だけ渡す。組み込みは vm 側の realm が自前で持っている const ctx = vm.createContext({ setTimeout, clearTimeout, console: { log() {}, error() {}, warn() {} } }); ``` `vm.createContext({})` は空に見えて**完全な realm**です（`Promise` も `Date` も `Map` も持っています）。 組み込みを渡すのは**そもそも不要**で、渡した瞬間に realm が混ざって穴になります。 ### 二重のタイムアウト `vm` の `timeout` は**同期実行しか止めません**。`while(true){}` は止まりますが、 pending のまま解決しない Promise は止まりません。外側にもう一段かけてください。 ```js export async function runCheck(name, text) { const check = CHECKS[name]; if (!check) return { pass: false, detail: `未知のcheck: ${name}` }; let timer; try { return await Promise.race([ check(extractCode(text)), new Promise((resolve) => { timer = globalThis.setTimeout(() => resolve({ pass: false, detail: '実行がタイムアウトした' }), 5000); }) ]); } catch (error) { return { pass: false, detail: `実行エラー: ${String(error?.message || error)}` }; } finally { if (timer !== undefined) globalThis.clearTimeout(timer); } } ``` **チェック関数は例外を投げないこと。** 構文エラーの回答は普通に来ます。 投げると採点が止まり、そのプロバイダの結果が丸ごと欠けます。 ### 脱出テストは「落ちること」を確かめてから採用する ```js test('サンドボックスからホストの process へ到達できない', async () => { delete process.env.__SANDBOX_ESCAPE; const attempts = ['Promise', 'Object', 'Array', 'Error', 'JSON'].map((name) => `try { ${name}.constructor('return process')().env.__SANDBOX_ESCAPE = '1'; } catch (e) {}`).join('\n'); await runCheck('retry-3x-100-200', `${attempts}\nfunction retry(fn) { return fn(); }`); assert.equal(process.env.__SANDBOX_ESCAPE, undefined, 'vm からホストの process に到達できた'); }); ``` **必ず、塞ぐ前のコードに対してこのテストを1回走らせて、落ちることを確認してください。** 落ちないテストはただの飾りです（実際にこの手順で、脱出が本物であることを確認できます）。 --- ## 5. 失敗理由は「真因」を指させる 採点が落ちた時の理由文字列は、**数字が正しくても真因を隠すこと**があります。 実例: 末尾に自走するデモコードが付いた回答（`retry` 自体は正しい）で、 そのデモの待機がこちらの計測に混ざり `待機が [100,100,200,200]（期待[100,200]）` と表示されました。 数字は事実ですが、**読んだ人は「実装のバグ」だと誤解します**。 → **自走そのものを検出**して報告するよう直します。 ```js const drain = () => new Promise((resolve) => setImmediate(() => setImmediate(resolve))); // 評価しただけで待機がスケジュールされたなら、自走するデモ/テストを含んでいる async function selfExecuting(evaluated) { await drain(); return evaluated.recordedDelays.length > 0; } ``` 設問が「コードだけ返してください」なら、自走コードはそれ自体が回答の不備なので不合格で妥当です。 **理由を正直にすること**が目的です。 ## 6. 判定は1回の計測でしない 同じ課題セットが同日2回の実行で 93.3% → 66.7% と振れた実測があります。 **モデルやルーティングを変える判断は、必ず2回以上の計測で行ってください。** また、成功率の分母は**「採点できた数」ではなく「試行数」**にします。 エラーで脱落した課題を分母から落とすと、**完走できないプロバイダほど高得点に見えます** （無料枠が切れて全件エラーのプロバイダが「成功率100%」で表の最上位に来る、という事故が実際に起きます）。 ```js const graded = pass + fail; return { n: rows.length, rate: graded ? pass / graded : null, // 採点成功率 attemptedRate: rows.length ? pass / rows.length : null, // 試行成功率（こちらを併記する） errors, truncated }; ``` エラー＋切断が1割を超えるプロバイダは、**点数に関わらず推薦候補から外す**のが安全です。 --- ## チェックリスト - [ ] 半数以上が落とす課題を検出する仕組みがある - [ ] 実行ログに各回答の**本文**と**採点理由**を保存している（無いと切り分け不能） - [ ] 落ちた回答の誤り方が揃っているか／バラバラかで、設問と採点基準を切り分けた - [ ] コードを採点する課題は、正規表現ではなく**実行して振る舞いで**判定している - [ ] 採点は**2ケース以上**（全失敗／途中成功）で、それぞれ別コンテキストで評価している - [ ] `vm.createContext` に**ホストの組み込みを渡していない** - [ ] 脱出テストがあり、**塞ぐ前のコードで落ちることを確認済み** - [ ] チェック関数は**例外を投げない**（構文エラーの回答は必ず来る） - [ ] 同期(vm timeout)と全体(Promise.race)の**二重タイムアウト**がある - [ ] 失敗理由が真因を指している（混入した数字をそのまま出していない） - [ ] 成功率を**試行数ベース**でも併記している - [ ] 判定は**2回以上の計測**で行っている ---