前回の記事では、ボートレースAIの検証を、過去データだけを使ったバックテストから、実際のレース時刻に合わせた本番運用へ進めることについて書きました。
今回は、その最初の本番事前判定がどのように行われたのかを紹介します。
今回の目的は、単に予想を当てることだけではありません。
レース結果が分かる前に予想を確定し、決められた時刻に記録し、後から書き換えられない状態で検証できるかを確認することが、最初の大きな目的でした。
今回確認したかったこと
過去のレースを使うバックテストでは、予想方法の比較や成績の集計を効率よく行えます。
しかし、すでに結果が分かっているデータを使うため、実際の運用とは条件が異なります。
本番では、次のような点も確認しなければなりません。
- 必要なデータを締切前に取得できるか
- 決めた時刻に予想を実行できるか
- 購入対象と見送りをルールどおり判定できるか
- 予想結果を正しく保存できるか
- レース結果を見た後に予想が変更されていないか
- 予想処理と結果の取得・評価処理を分離できるか
どれだけバックテストの成績がよくても、本番で予想の保存に失敗したり、締切後に判定されたりすれば、正しい検証にはなりません。
そこで今回は、予想精度の評価に入る前に、まず運用の仕組みそのものが正しく動くかを確認しました。
締切約12分前に予想を確定
今回の本番運用では、各レースの締切時刻に合わせて、約12分前に正式な事前判定を行いました。
展示情報などの直前データを反映しながらも、舟券を購入できる時間を残した状態で予想を確定するためです。
判定後は、AIが出した予想順位や購入判定を保存します。
その後、レース結果が確定しても、保存済みの予想内容は変更しません。
この仕組みによって、
結果を見た後で都合のよい予想に書き換えていない
ことを確認できるようにしています。
12レースすべてで事前判定が完了
今回の対象は12レースでした。
結果は次のとおりです。
- 対象レース：12レース
- 正式な事前判定：12件
- PURCHASE：6件
- SKIP：6件
- VALID：12件
- 未判定：0件
- 重複判定：0件
- 後付け判定：0件
- 判定結果の上書き：0件
12レースすべてで、締切前に正式な判定を保存できました。
また、すべての判定が検証対象として有効な状態で記録されています。
最初の本番運用としては、狙っていた処理の流れを、そのまま実行することができました。
PURCHASEとSKIPの意味
今回の運用では、すべてのレースを購入対象にはしていません。
事前に固定した条件を満たしたレースを「PURCHASE」、条件を満たさなかったレースを「SKIP」と判定しています。
今回の内訳は、PURCHASEが6件、SKIPが6件でした。
ただし、PURCHASEは「当たる可能性が高い」と保証するものではありません。
あくまで、
今回設定した検証条件を満たしたレース
という意味です。
実際にその条件が有効だったかどうかは、レース結果と払戻を集計し、一定期間の成績を確認しなければ判断できません。
SKIPになったレースについても、予想自体は保存します。
購入対象と見送りの両方を記録することで、条件によって成績にどのような違いが出るのかを後から比較できます。
VALIDは予想が有効に記録された状態
今回の12レースは、すべてVALIDとして保存されました。
VALIDは、予想が当たることを意味するものではありません。
主に、
- 締切前に判定された
- 必要なデータがそろっていた
- 正式な予想として保存された
- 後付けや重複ではない
- 検証対象として使用できる
といった条件を満たしている状態を表しています。
予想の的中・不的中を評価する前に、その予想が正しい手順で作られたものかを確認するための判定です。
今回、12件すべてがVALIDだったため、本番検証の対象として扱える予想記録を残すことができました。
予想処理と結果取得を分離
今回の運用では、予想を作成する処理と、レース結果を取得して成績を評価する処理を分けています。
事前判定の段階では、レース結果の取得や的中判定は行いません。
先に予想だけを確定して保存し、レース終了後に別の処理で結果を取得します。
この分離は、後付けを防ぐうえで重要です。
予想の作成と結果の評価を同じ流れで行うと、処理の順番やデータの扱いによっては、結果情報が予想側に混ざる可能性があります。
今回の本番事前判定では、結果取得や評価処理が混ざっていないことも確認できました。
本番事前判定そのものは成功
今回の結果を見ると、本番事前判定そのものは正常に完了したと考えています。
12レースすべてで、
- 締切前に正式判定
- PURCHASEまたはSKIPを記録
- VALIDとして保存
- 未判定なし
- 重複なし
- 後付けなし
- 上書きなし
- 結果取得との混在なし
という状態を作ることができました。
予想の的中結果とは別に、正しい条件でForward Testを行うための土台ができたことは、今回の大きな成果です。
運用面では改善点も見つかった
一方で、今回の運用がすべて完璧だったわけではありません。
予想処理そのものではなく、運用や監査の面で、次の改善点が見つかりました。
処理終了を示す明示的なログ
今回の処理では、各レースの判定結果は確認できました。
ただし、すべての処理が正常終了したことを一目で判断できる、明示的な終了ログが不足していました。
今後は、全対象レースの処理が終わった時点で、
- 処理開始時刻
- 処理終了時刻
- 対象レース数
- 正常処理件数
- エラー件数
- 最終終了ステータス
などをまとめて出力する仕組みを追加したいと考えています。
実行前バックアップ
今回の実行前には、専用のバックアップを作成していませんでした。
事前判定のデータは保存されており、今回の結果に問題はありませんでしたが、本番運用として考えると、実行前の状態を保存しておく方が安全です。
今後は、事前判定を開始する前に、
- データベース
- 予想設定
- 使用したスコア条件
- 判定対象一覧
などを保存し、万が一の際に実行前の状態と比較できるようにする予定です。
成功と的中は別に評価する
今回の本番運用では、事前判定の仕組みは正常に動きました。
しかし、仕組みが動いたことと、舟券が当たったことは別の話です。
PURCHASEとなった6レースが、実際にどのような結果になったのかは、レース結果を取得して集計しなければ分かりません。
今後の評価では、
- 購入件数
- 的中件数
- 投資額
- 払戻額
- 収支
- 回収率
- 連敗数
- ドローダウン
を確認します。
事前判定が成功しても、回収率が低ければ予想条件の改善が必要です。
反対に、短期間でよい成績が出ても、それだけで有効な戦略だと判断することはできません。
運用の正しさと予想成績を分けて、継続的に確認していきます。
次回は実際の結果を公開します
今回は、本番事前判定がどのような仕組みで動き、12レースの予想を締切前に固定できたかを紹介しました。
最初の本番運用として、予想を事前に記録し、後付けや上書きを防ぐ仕組みは正常に動きました。
その一方で、終了ログと実行前バックアップという改善点も見つかりました。
次回は、PURCHASEとなった6レースについて、
- 的中数
- 払戻
- 投資額
- 収支
- 回収率
を公開します。
当たった場合も、外れた場合も、そのまま記録して検証していきます。
コメント