教師データ

DLManaka と Manaka は同じ教師コーパスを使います。manaka-teacher が圧縮済み教師シャードを書き、各学習器が読み込み時に自分の入力表現を作ります。DLManaka 専用の別コーパスはありません。

元データは qleap/Knowledge_distilled_dataset_by_NAGISA_V3 として公開されている NAGISA_V3 蒸留コーパスです。

構築手順

uv run --script tideborn/tools/fetch_teacher.py --shards 0 1 2 3
cargo build --release -p manaka-teacher -p tideborn-encode
./build/target/release/manaka-teacher data/deduped/*.parquet --strict \
  --out data/mteacher-deduped
uv run python -m tideborn.tools.check_shards data/mteacher-deduped --limit 50000

Python 側では tideborn-encode を読み込み、圧縮局面から DLManaka の入力プレーンをその場で作ります。

圧縮局面を共有する理由

両エンジン向けにコーパス全体を事前変換すると、合法手生成とエンコードを二重に行い、大きな成果物も 2 種類同期する必要があります。そこでシャードには圧縮局面と疎な教師信号だけを保存します。

DLManaka で測定した範囲では、読み込み時の展開コストは GPU の 1学習ステップより十分小さく、共有コーパスが GPU を待たせる原因にはなりませんでした。

コーパス整備

元データは対局単位でシャッフルし、その後に重複除去しています。

uv run --script tideborn/tools/shuffle_corpus.py --input data/raw --out data/shuffled
uv run --script tideborn/tools/dedup_corpus.py   --input data/shuffled --out data/deduped
uv run --script tideborn/tools/upload_corpus.py --input data/deduped --yes

重複除去後は 281,061,093 行。元の 300,045,733 行から 6.327% 減です。検証用の対局は学習側へ混入させません。

check_corpus.py は、対局ブロックが壊れていないことと、シャッフルが実際に対局をシャッフルしたことを確認します。

教師シャードの 1 行

フィールド	内容
packed	圧縮局面。どちらの最終入力テンソルでもない
label_hash	再生成した合法手順序の指紋値
prob_slots / probs	疎な教師方策
value_z	最終対局結果
value_q	教師探索のルート価値
aux_value	任意の補助教師信号。未設定なら NaN
ply / game_id	重み付け・分割用情報

記録サイズは約 43.8 B/行、281M 行で 12.3 GB です。

学習・検証分割

分割はランダムな行ではなく開始局面を基準にします。同じ序盤から 1 手だけ違う局面が、行 ID の都合で学習と検証に分かれることを防ぎます。

両学習器が同じ検証規則を使うため、元データ単位で検証集合を揃えられます。

整合性確認

1. manaka-teacher --strict が復元盤面上で候補手の合法性を確認する。
2. label_hash が各行の合法手順序を確認する。
3. check_shards.py が変換後の局面構造と疎な方策の不変条件を確認する。

エンコード定義は Rust 側を正本とします。DLManaka は crates/dl-manaka-core/src/encoding.rs を使い、Python 側に独立したプレーン・ラベル定義を持ちません。

自己対局と Parquet のバイト形式は 学習データ形式 を参照してください。