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

一時期このアプリは、2つの異なる難易度の考え方から3つの異なる買い回り順を計算して、同じカートについて同じ人に全部見せていました。

カート画面はリスクのスカラーで並べる。ライブの見出しはその経路を並べ直す。計画画面は曲線の分位点で並べて、ライブ在庫を完全に無視する。その結果、「何時に家を出るか」が、その人が絶対に歩かない道順から導かれていました。

よくないです。

なぜ割れたのか

根本原因は、2つの難易度指標が別の問いに答えていることでした。

リスクのスカラーは一日単位の数値を返します。曲線は「いつ」についての分布です。どちらも他方から導けないので、消費側がそれぞれ都合のいい方を選び、そのままずれていきました。

症状は全部そこから出ています。

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

畳み込み

いまはすべてが1つの原始的な量、到着時刻に対する品ごとの生存関数を読みます。並び順も、確率も、時間もそこから来ます。

ここは向きが大事です。スカラーからは出発時刻を作れませんが、生存関数からはスカラーを作れます。だから関数が原始で、スカラーは派生です。逆ではありません。

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

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

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

記録の誠実な部分

計画文書には「何が間違っていたか」の表を残してあります。どの行も、誰かが戻してしまいうるバグの名前だからです。

そして、後続の変更が1つだけ意図的に数値を動かしたことも記録しています。クランプの不連続を直す修正で、単独でレビューし、単独で計測しました。改修に紛れ込ませて「全体として挙動を保った」と言うことはしませんでした。