review19: (省略: 新サーバへの移行) / フェーズ1前処理を完全再構築 — 6.15Bトークン・125シャード / RTX 3060 で計画前倒しへ

作成日: 2026-09-05 対象: 新サーバ(Ryzen 3 4300U)移行後の初作業日。(省略: 移行作業とサーバ障害への対応)、フェーズ1 前処理の作り直し完了までの報告。

要旨: 本日でプロジェクトは故障前より良い状態に戻りました。

1. コーパス原本は無傷で生存(バックアップのコピーが sha256 完全一致)。内蔵ディスクにも二重化した

3. フェーズ1 の前処理を最初から最後まで再構築: スナップショット → トークナイザ(48k 採用)→ 全量トークン化 → 125 シャード・6.15B トークン。全段階で検証合格、8/13 の数値と完全一致
4. サイトを二言語化(/ と /ja/)し、モデル構成図・推論フロー図を両言語で埋め込み公開

6. 【要判断】時系列分割の val/test が 100% 日本語になる問題を発見(7 章)。学習開始前に分割の再設計が必要

4. サイト二言語化と構成図の公開

ご依頼の件、完了・公開済みです(コミット 42b120e → 名義変更後 edec793)。

• model_architecture_en.drawio / model_inference_en.drawio: 図のレイアウトはそのまま、ラベル計 49 箇所を英訳
• https://zxell.ai/(英語)に英語版の図 2 点、https://zxell.ai/ja/(日本語・新規)に日本語版の図 2 点を埋め込み
• 埋め込みは diagrams.net ビューア方式(図の XML はページ内蔵・ズーム/ライトボックス付き)。埋め込み XML が drawio 原本とバイト一致することを機械検証済み
• ヘッダに EN/日本語切替、hreflang タグ付き

6. フェーズ1 前処理の完全再構築 — 本日のメインディッシュ

review18 6 章の方針(「work/ 配下は流用せず、トークナイザから作り直し」)を完遂しました。 全段階で「書き込み後の読み直し検証」を実施し、故障機での 8/13 の数値と突き合わせています。

6-1. スナップショット再生成(parse_dump.py)— 45 分(旧機 2 時間 50 分)

統計の完全一致により「8/13 のパース処理は正しく、破損は書き込み後」という review16 の分析が裏付けられました。出力は内蔵ディスク。

6-2. サンプル抽出(extract_sample.py 改修)— 5 分

MySQL 喪失に伴いスナップショット読みに書き換え(抽出条件・整形・重複除去は旧版と同一。コミット 16b4406)。言語別の docs/chars は 8/13 の稼働 DB 版と 0.2% 以内で一致(差分は稼働 DB に 1.7 万件多かった分で説明がつく)。

6-3. トークナイザ学習・比較 — 48k/64k 各 90 秒(旧機の見込み数十分)

AVX2 の効果が予想以上でした。結果は 8/13 のレポートと chars/token が小数第 3 位まで完全一致:

採用判断も従来どおり 48k(64k は総トークンを 3% 減らすだけで、S モデルでは埋め込みが 33% 太る)。

6-4. 分割境界の再実測(boundaries.json)

旧 boundaries.json(8/13・work/ 産物)は使わず、スナップショット全走査で再計算:

• コーパスの pub_date 終端は 2024-02-12(不正日付 0・未来日付 0)。旧値 ref 2024-04-25 は故障ではなく実態でした(稼働 DB は dump より 1.7 万件分だけ未来まであった)
• 終盤の記事数は約 2,700 件/月(全期間平均 約 13 万件/月)。収集は 2024 年初頭に実質先細り
• 新境界: test = 2023-11-13 以降 / val = 2023-10-14 以降

6-5. 全量トークン化+シャード化(tokenize_full.py)— encode 70 分 + シャード 50 分

rows_scanned          7,969,236  (全行)
dup_links_skipped       420,934  (5.3% — phase0 実測の重複率と一致)
empty_skipped            41,641
異常・スナップショット損傷      0
出力: 125 シャード(train 123 / val 1 / test 1)・6.152B トークン
置き場所: サーバの配布ディレクトリ(各 50M トークン ≈100MB + sha256 付きメタ JSON)

• 総トークン 6.152B は 6-3 の推定 6.14B と 0.2% 差。3.1 節の作業仮説 6.5B もほぼ的中
• 言語構成(トークンベース): en 64.6% / de 21.7% / fr 10.0% / ja 3.7%
• シャード 1 個を独立に sha256 再計算し、メタデータと一致することを抜き打ち確認済み

これでフェーズ1 の前処理は完了です。学習可能なシャードがサーバの配布ディレクトリに揃いました。

7. 【重要・要判断】val/test が 100% 日本語になっています

シャードのメタデータ検証で発見しました。これは学習開始前に直すべき問題です。

val_000.bin : 1.15M トークン・2,667 記事 — 言語構成 {ja: 100%}
test_000.bin: 3.80M トークン・8,734 記事 — 言語構成 {ja: 100%}

原因は明快で、2023-10 以降まで収集が生きていたのは日本語フィードだけだったためです(en/de/fr のフィードはそれ以前に停止)。単一の時系列境界で切ると、末尾 4 か月 = ほぼ日本語だけが val/test に入ります。

このままでは「言語別パープレキシティ」「en/de/fr の要約評価」(成功基準 1.2)が val/test で測れません。対応案:

• A(推奨): 言語別の時系列境界。 各言語の「自分の時系列の末尾 3 か月 + 1 か月」を test/val にする。「新しい記事で評価する」という設計意図(roadmap 5 章)を言語ごとに保てる
• B: val/test のみ記事単位のランダム分割(時系列の意図は捨てる)
• C: 現状のまま(val/test は日本語専用と割り切り、en/de/fr は train 内ホールドアウトで別途評価)

A の実装は tokenize_full.py の境界判定を言語別辞書にするだけで、再実行は encode からやり直し(約 2 時間)です。ご判断ください(確認事項 1)。

8. クライアント体制の再評価(RTX 3060 の合流)

RTX 3060(12GB・Ubuntu Server・memtest 済み)+ GTX 1050(2GB)の 2 台体制が確定(1050 の 1 台は 3060 で置き換え)。roadmap 10 章に反映済みの要点:

• フェーズ 3 のゲート「VRAM 6GB+ の確保」は達成済み
• 分散実験は S スケールが主戦場(1050 の 2GB 制約)。速度比 ~15:1 の極端なヘテロ構成は、クライアントごとに局所ステップ数 H を変える DiLoCo の題材としてむしろ好都合

9. その他の本日の作業

• CLAUDE.md を現状に全面更新(4 テーブル構成・認証・リース・prep パイプライン。コミット f4d8202)
• roadmap.md に 10 章「2026-09-05 改訂」を追記
• push 済みコミット(名義変更後): edec793(サイト二言語化)/ 522a92d(依存更新)/ 16b4406(extract_sample スナップショット化)/ f4d8202(CLAUDE.md)

検証の限界を正直に: シャードの sha256 全数再検証はしていません(抜き打ち 1 個+書き込み時の自動検証のみ)。また新サーバは memtest 4 パス合格ですが、旧機の教訓に従い、学習開始後も定期的な checksum 照合を運用に組み込みます。

10. 確認事項

1. val/test の分割方針(7 章): A(言語別境界・推奨)/ B(ランダム)/ C(現状維持)のどれにしますか? A なら次回、境界の言語別再実測 → encode からの再実行(約 2 時間)を行います。

11. 次の作業予定

1. 確認事項 1 の回答を受けて val/test 分割を確定 → 必要なら再シャード化
2. S(30M)モデルの実装(モデル定義・学習ループ・チェックポイント形式)
3. RTX 3060 機のクライアント環境構築(PyTorch CUDA)→ シャード取得 → S ベースライン学習開始(フェーズ 1 の完了判定へ)
4. 評価ハーネス(言語別パープレキシティ・ROUGE 雛形)