STEP 1741 — ransbench 交絡分離 + counter fix
STEP 1731 の 3 点フィードバック応答: (1) "greedy vs optimal" 表記統一 + bound 方向明記 · (2) 4-corpus 2x2 で文字集合 × 構造 交絡分離 · (3) claim-step.ts に auto-sync 内蔵
2026-09-04 · rei-aios-8a tab · worktree step1724-ransbench_arc
Executive summary
- Task 1: "optimal K=8" → "greedy K=8" に統一 + 96.6%/89.1% は下界 (greedy ≤ true opt) / D-FUMT₈ 87%/26% は上限値 と明記。
- Task 2 (v3 corrigendum で最終形): 4-corpus 2x2 + Gutenberg 追試 + within-corpus paired charset contrast で 3 段の深化: (v1) charset major (docstring only) → (v2) corpus 反転 (Melville で structure 勝) → (v3) pure charset は 4 種 contrast 中最小 (D8/gr 5.3 pts / ARI 0.134)、v1/v2 の "charset 25-38 pts" は実は charset + 書記体系 + 言語 + Japanese byte structure の合成量、20 pts 分が confound。順位主張は corpus × metric の 4 通り中 1 通りでしか成立しない。
- Task 3: scripts/claim-step.ts の cmdClaim に --sync-from-git internal 内蔵。実測 drift +9 auto-heal 動作確認 (counter 1732 → git_highest+1=1741 → advance)。
1. Task 1 — 表記統一 + bound 方向
STEP 1731 の全出力で「最適 K=8」「greedy optimal K=8」→「greedy K=8」「貪欲 K=8」に統一。
Bound の向き (正確な数学的表現)
greedy_I(K) ≤ true_optimum_I(K) ≤ full_256_I
greedy_I / full_256_I (96.6% Python / 89.1% Prose)
= LOWER bound on true_optimum_I / full_256_I
→ 真の最適の効率はこれ以上
D-FUMT₈_I / greedy_I (87% Python / 26% Prose)
= UPPER bound on D-FUMT₈_I / true_optimum_I
→ 真の相対達成率はこれ以下
正しい主張: 「D-FUMT₈ は Python で最適の 87% まで捕捉、Prose で 26% まで」= 上限値、真の効率はこれ以下。
2. Task 2 — 交絡の解消 (4 corpus 2x2)
STEP 1731 の Python (ASCII + code) vs Prose (UTF-8 + 自然言語) 比較は 2 変数を同時に動かしており、「非 ASCII 混じり自然言語」1 変数への特定不可。追加 2 corpus で 2x2 実験。
Corpus 構成
| corpus | size | non-ASCII % | 種別 | 建て方 |
|---|
| python_1mib | 1 MiB | 0.0% | 構造化 code | Python 3.13 stdlib .py concat |
| english_ascii_1mib (新) | 1 MiB | 0.0% | 自然言語 prose | stdlib docstring/comment 行 (ASCII 純, prose-heuristic filter) |
| json_utf8_1mib (新) | 1 MiB | 19.7% | 構造化 data | memory md metadata の JSON dump (JP 文字列 値) |
| prose_1mib | 1 MiB | 34.3% | 自然言語 prose | memory md concat (JP + EN 自然文) |
実測 2x2 (D-FUMT₈ lex_class / greedy K=8 = 相対達成率 UPPER bound)
D-FUMT₈ / greedy
structured
87%python_1mib · ARI 0.57
65%json_utf8_1mib · ARI 0.11
prose
80%english_ascii_1mib · ARI 0.55
26%prose_1mib · ARI 0.06
差分分解
| Effect | Fix | Vary | Δ (pts) |
|---|
| 文字集合 | structured | ASCII → UTF-8 | 87 → 65 = −22 |
| 文字集合 | prose | ASCII → UTF-8 | 80 → 26 = −54 |
| 構造 | ASCII | code → prose | 87 → 80 = −7 |
| 構造 | UTF-8 | data → prose | 65 → 26 = −39 |
周辺効果 (marginal): 文字集合 = 平均 −38 pts / 構造 = 平均 −23 pts。文字集合の効果が構造の約 1.65 倍。
交互作用 (interaction): additive model なら (Python 87% − 22 − 7) = 58% を予想。実測 Prose 26% は予想を −32 pts 下回る = UTF-8 と prose が同時にあると相乗的悪化。
5 corpus 実測 (Gutenberg 追試込み)
| corpus | kind | D-FUMT₈ I | greedy K=8 I | full 256 I | D8/greedy | ARI |
|---|
| python_1mib | ASCII code | 0.0348 | 0.0400 | 0.0414 | 87.0% | 0.571 |
| english_ascii_1mib | ASCII prose (docstring) | 0.0189 | 0.0235 | 0.0268 | 80.4% | 0.555 |
| gutenberg_moby_1mib (追試) | ASCII prose (Melville 純文学) | 0.0092 | 0.0166 | 0.0210 | 55.4% | 0.339 |
| json_utf8_1mib | UTF-8 data | 0.0204 | 0.0315 | 0.0338 | 64.8% | 0.111 |
| prose_1mib | UTF-8 prose (JP+EN) | 0.0049 | 0.0187 | 0.0210 | 26.2% | 0.056 |
Robustness (Gutenberg Moby Dick 追試) — decisive finding
docstring corpus は純自然英語 prose の robustness verify として不十分:
- english_ascii_1mib (Python stdlib docstring): D8/greedy = 80.4%, ARI 0.555
- gutenberg_moby_1mib (Melville 純文学): D8/greedy = 55.4%, ARI 0.339
- 差 = −25pts / ARI −0.22。docstring は「技術英語」で code に近い構造 (identifier repetition + short lines + fixed vocabulary) を持ち、純文学 (長文 + 複雑 punctuation + 語彙多様性) では D-FUMT₈ の粒度不足がより顕著。
v3 corrigendum — 揃った 2 軸周辺平均 (marginal mean)
v2 での structure 分解が ASCII 軸 conditional のみ (−31 / −7) だったため v1 の 2 軸周辺平均 (−38 / −23) と計算方法が不揃い。両者を同じ 2 軸平均で揃えると:
| anchor (D8/gr metric) | charset avg | structure avg | 優越 |
|---|
| docstring anchor | −38.2 | −22.6 | charset (1.7×) |
| Melville anchor | −25.7 | −35.1 | STRUCTURE (1.4×) |
Structure の Melville-anchor 値は −26〜−31 pts ではなく −35.1 pts (UTF-8 軸 −38.6 込み)。anchor で優越関係が反転 — v2 の「両者拮抗」は不正確、正しくは「anchor 反転」。
Metric dependence — ARI では反転しない
| anchor (ARI metric) | charset avg | structure avg | 優越 |
|---|
| docstring anchor | 0.480 | 0.036 | charset (13.5×) |
| Melville anchor | 0.371 | 0.144 | charset (2.6×) |
ARI では両 anchor で charset 優越。順位反転は D8/greedy 比の列にのみ現れる。json (D8/gr 65% / ARI 0.111) と Melville (D8/gr 55% / ARI 0.339) が % と ARI で 逆順 = 2 metric は互いに単調でない → Pattern J は "corpus 依存" だけでなく "corpus × metric 依存" に拡張。順位主張は 4 通り中 1 通り (Melville anchor × D8/gr) でしか成立しない。
③ Within-corpus paired charset contrast — 交絡 1 本潰し
クロス corpus の "charset" 軸は charset ⊗ 書記体系 ⊗ 言語 の 合成量 (JP は 3 バイト列 + 空白なし + 文字種数桁違い)。同一 gutenberg_moby の UTF-8 と ASCII-strip の paired contrast = charset だけを varying (1.74% non-ASCII の混入率のみ差)。
| corpus | non-ASCII | D-FUMT₈ I | greedy K=8 I | full 256 I | D8/greedy | ARI |
|---|
| moby_paired_utf8 | 1.74% | 0.0088 | 0.0176 | 0.0224 | 50.3% | 0.205 |
| moby_paired_ascii | 0.00% | 0.0092 | 0.0166 | 0.0210 | 55.6% | 0.339 |
| Δ (UTF-8 → ASCII) | −1.74pt | +0.0004 | −0.0010 | −0.0014 | +5.3 | +0.134 |
同一 1,036,451 chars of Moby Dick、encoding だけ変える (Gutenberg -0.txt UTF-8 で curly quote/em-dash 系 1.74% を含む/含まない)。「わずかな非 ASCII でも効く」の下限測定。
Paired-clean effect decomposition (v3 最終)
| effect | 説明 | D8/gr Δ | ARI Δ |
|---|
| pure charset | Moby Dick 同一 chars、UTF-8 vs ASCII (paired) | +5.3 | +0.134 |
| prose type (English 内) | docstring (技術) vs Melville (文学)、両 ASCII | +25.0 | +0.216 |
| code vs prose (ASCII 内) | Python vs Melville ASCII、両 ASCII 英語 | +31.6 | +0.232 |
| cross-corpus lang+script | Melville ASCII vs prose JP+EN | +29.2 | +0.283 |
Pure charset は 4 種 contrast 中最小 (D8/gr 5.3 pts / ARI 0.134)。v1/v2 で「charset」と呼んでいた 25-38 pts の大半は charset + 書記体系 + 言語 + Japanese-specific byte structure の合成量 = 25.7 - 5.3 = 20.4 pts が confound (writing system + language + Japanese byte-per-char 分布)。
v3 final finding — 順位主張は corpus × metric の 4 通り中 1 通りでしか成立せず:
- Pure charset effect は 4 種 contrast 中最小 (D8/gr 5.3 pts / ARI 0.134)。v1/v2 で「charset」と呼んでいた 25-38 pts の大半は charset + 書記体系 + 言語 + Japanese-specific byte structure の合成量だった。paired within-corpus で isolate すると 20 pts 分が confound と判明。
- Anchor 反転は D8/gr metric のみ: (a) docstring anchor で charset 勝、(b) Melville anchor で structure 勝、(c) 両 anchor × ARI で charset 勝。corpus × metric の 4 通りのうち 1 通りでしか「structure > charset」順位が成立せず。
- 安全に主張できる範囲: 「charset・structure・prose type・lang+script いずれの因子も実在するが、pure charset が最小 (~5 pts) で、prose-type-within-English (~25 pts) や code-vs-prose (~32 pts) の方が大きい」。「主因」の順位付けは corpus × metric に依存し robust でない。
- 元の「非 ASCII 混じり自然言語で失われる」は実は「Japanese 特有の byte distribution + prose type + language」で失われる、pure charset (UTF-8 化そのもの) は小効果。「わずかな非 ASCII でも 5 pts 効く」は下限測定として保持、ただし cross-corpus の 25-38 pts とは別 order of magnitude。
- この STEP は「主張を弱めた」記録ではなく「順位主張が corpus × metric の両方に依存することを定量的に示した」記録。前 STEP 1741 v1/v2 の「charset major」claim は出版すべきでない結論だった (指摘通り STEP 1741 で止めた判断は正しかった、v2 でも不十分)、v3 で pure charset isolate + metric dependence 発見で議論の土台が固まった。
3. Task 3 — counter auto-sync 内蔵
scripts/claim-step.ts の cmdClaim に computeGitHighestStep() を internal 呼出、drift 検出時 auto-heal + warning。実測動作:
$ npx tsx scripts/claim-step.ts --slug test_counter_fix_smoke
[claim-step] counter drift auto-healed: state.next=1732 < git_highest+1=1741 (drift=+9). Advancing before claim.
STEP 1741
Cost/benefit: 各 claim で git log --oneline --all = ~200-500ms overhead。対して STEP 1724→1731 renumber cleanup では 11 file × 27 参照の手動 rename が必要だった。頻繁な小コスト vs 稀な大コストで前者を選択。
Opt-out: 環境変数 CLAIM_STEP_NO_SYNC=1 で無効化 (test harness / minimal CI 用)。git log 失敗時は非致命的に fallback (counter 単独信頼)。
Peek も同 sync: --peek が drift を検出したら sync-safe next を表示 (state は書き換えない)。
4. 統合 conclusion (v3)
- STEP 1731 の観測「D-FUMT₈ は Prose で崩壊」の原因は「非 ASCII 混じり自然言語」ではあるが、pure charset (UTF-8 化そのもの) は最小効果 (~5 pts)。実際の主因は Japanese-specific byte structure + prose type + language の複合。
- D-FUMT₈ lex_class 8 クラスの内、class 6 (非 ASCII) 単純化の設計判断だけでは 5 pts しか説明せず、残り 20-30 pts は class 0-5 の粒度不足 (English literary prose では docstring の 5 倍程度 D-FUMT₈ の失敗率が高い、pure charset とは独立の効果)。
- 論文化する場合の安全な主張形式: 「D-FUMT₈ 8 分割は情報論的に (a) ASCII code で 87% 以下、(b) ASCII prose で 55-80% 以下 (prose type 依存, docstring:80 / Melville:55)、(c) UTF-8 では pure charset 効果 5 pts に加え、書記体系 + 言語の複合が追加影響。原因の相対 ranking は corpus × metric に依存し robust でない。paired within-corpus 実験のみが charset を isolate 可能」。
- D-FUMT₈ 改良の direction: 非 ASCII を 1 class にまとめる代わりに 8 分割で細分する場合、pure charset 5 pts のみ回復。より大きな gain (25-32 pts) が prose type / code-vs-prose separation にある = literary text 特有の byte distribution を意識した class 設計余地。
5. Honest scope
- v3 corrigendum で 3 段深化済 (2026-09-04): v1 charset major → v2 corpus 反転 (Melville) → v3 metric dependence + paired isolation で pure charset は 4 種 contrast 中最小 (5.3 pts) と判明。「主因」順位付けは corpus × metric に依存し robust でない、両因子とも実在 (paired charset 5 pts, prose type 25 pts, code-vs-prose 32 pts, cross lang+script 29 pts) までが安全な主張。
- paired within-corpus は charset 単独の isolation として cleanestだが、他因子 (prose type / code-vs-prose / lang+script) の paired isolation は未実施。例えば同一著者の英日 parallel translation で lang effect isolate、同一 English literary text の異写本で writing style isolate、等の paired 実験余地。
- json_utf8_1mib は memory md metadata の JSON dump で "構造化 data" のカテゴリだが、JSON 特有の構文 (キーの重複、括弧) が bench 数値を偏らせる可能性。より一般的な UTF-8 data (Redis dump 等) で追試余地。
- Moby Dick paired の non-ASCII 混入率 1.74% は「わずかな非 ASCII」域の測定。より高混入率 (5-15%) の英語 corpus (accented mixed) では charset effect が nonlinear に増える可能性、paired の scaling 実験余地。
- Greedy が真の最適に近い保証は Bernoulli scalar quantization ± contiguous 制約下のみ。byte 空間の一般組合せ最適 (Bell(256) 全列挙 10^400+) との差分は測定不能。
- 2 metric (D8/gr% と ARI) が単調でないことが判明したが、他の metric (I(state;bit) 絶対値, per-byte 情報量, encoder bpb 実測) での追試余地。それぞれ別の "順位" を示す可能性あり。
6. Artifacts
- experiments/ransbench/corpora/english_ascii_1mib.bin (Python docstring 抽出)
- experiments/ransbench/corpora/gutenberg_moby_1mib.bin (v2 追試: Melville Moby Dick + 非 ASCII strip)
- experiments/ransbench/corpora/json_utf8_1mib.bin
- experiments/ransbench/corpora/gutenberg_moby_paired_utf8.bin + gutenberg_moby_paired_ascii.bin (v3: 同一 1,036,451 chars of Moby Dick, encoding のみ差)
- experiments/ransbench/build_corpora_v2.py + fetch_gutenberg.py (Moby Dick reproducibility script)
- experiments/ransbench/optimal_partition.py (docstring 訂正 + bound 明記)
- scripts/claim-step.ts (computeGitHighestStep() + cmdClaim/cmdPeek 内蔵)
- STEP 1731 site page ↑ 更新 (bound 明記 + §4.5 交絡開示)