Mirai Guide：すべての答えの背後に1本の生存曲線

かつてこのアプリは、2つの異なる難易度の考え方から3つの異なる買い回り順を計算し、同じカートについて同じ来場者に全部見せていました。カート画面はリスクのスカラーで並べ、ライブの見出しはその経路を並べ直し、計画画面は曲線の分位点で並べてライブ在庫を完全に無視していました。その結果、「何時に家を出るか」は、その人が決して歩かない道順から導かれていました。

なぜ割れたのか

根本原因は、2つの難易度指標が別の問いに答えていることでした。リスクのスカラーは一日単位の数値を返し、曲線は「いつ」についての分布です。どちらも他方から導けないので、消費側がそれぞれ都合のよい方を選び、ずれていきました。

症状はそこから出ています。同じカートなのにページ間で立ち寄り番号が食い違う。ライブの見出しが群衆考慮の並べ替えを固定で有効にしていたため、意図的に切った人にも適用される。完売した立ち寄り先が出発時刻モデルでは徒歩と待ち時間を消費し続け、行程を膨らませる。

畳み込み

いまはすべてが1つの原始的な量、すなわち到着時刻に対する品ごとの生存関数を読みます。並び順も、確率も、時間もそこから来ます。スカラーからは出発時刻を作れませんが、生存関数からはスカラーを作れます。だから関数が原始で、スカラーは派生です。逆ではありません。

要件は、違反した実装をレビュアーが却下できる形で書かれました。特に2つを繰り返す価値があります。

• 並び順のためにリスクのスカラーを直接呼ぶ消費側があってはなりません。 例外は1つだけ、隠さず記録されています。サーバー側のルートエンドポイントは曲線アーティファクトを読まずに動くため、等価な線形ランプを導きます。その公開順序はこの作業で変わっていません。
• 曲線がない場合の挙動は以前とビット単位で同一でなければなりません。 曲線の網羅率は部分的で、曲線なしの経路こそ通常の経路です。この改修でその数値を動かすことは許されませんでした。

結果として、カート、ライブ見出し、計画画面が同じカートを同じ順に並べ、出発の推奨は実際に歩く道順に対して計算され、群衆考慮のトグルはどこでも同じ意味になりました。

記録の誠実な部分

計画文書は「何が間違っていたか」の表を残しています。どの行も、誰かが再導入しうるバグの名前だからです。さらに、後続の変更が1つだけ意図的に数値を動かしたことも記録されています。クランプの不連続を直す修正で、改修に紛れ込ませて「全体として挙動を保った」と主張するのではなく、単独でレビューし単独で計測しました。