音楽ストリーミングの DJ

背景

ある音楽ストリーミングアプリが、DJ 機能をベータとして追加します。 DJ は、ユーザーがこれまでに再生した曲と、アルゴリズムがユーザーの好みだと判断したものをもとに、キューを途切れさせずに回し続けます。 数曲おきに、次にかかる曲とその選曲理由について短くコメントします。 リスナーはマイクボタンを押して話しかけることで、DJ に方向性を指示することもできます。

AI エンジニアリングの構成をどう組むかは、2 つの特徴から決まります。

1. 出力が悪かったときのリスクが低い。 最悪でも曲がスキップされるか、DJ のコメントがぎこちない程度で、機能はベータと明示されています。
2. 新機能なので 出発点となる過去データがない。 チームはリスナーの実際の行動から学んでいく必要があります。

このため、できるだけ早く本番に出し、最初からライブのフィードバックをもとに反復する のが理にかなっています。

DJ のトレーシング

2 種類の トレース があり、これらが合わさって 1 つのセッションを構成 します。

視聴セッションと、2 種類のトレースを近くで見てみます。

ユーザーの行動を捕捉する

ユーザーから学ぶために、注目すべき行動 を該当するトレースに記録します。

原理的には、これだけあればチームはもう反復を始められます。 トレーシングと モニタリング だけで、それ自体が小さなループを形成するからです。 最初のうちは、DJ 機能をすばやく改善していくにはおそらくこれで十分です。

構成が成熟し、より体系的なテストを整えたくなったら、これらのシグナルの上にデータセットと実験を組み立てていけます。

体系的なテスト

ライブのシグナルだけの状態では、変更をテストするということはリリースしてスコアを見ることを意味します。 チームはさらに 2 つの意図的なテスト方法を追加できます。データセットに対する実験 と、実ユーザーに対する A/B テストです。

データセットに対する実験

このユースケースでは、エンドツーエンドをオフラインでテストするのは非常に困難です。 セッションが良かったかどうかは実際の視聴行動にしか現れず、好みはユーザーごとに違うため、全員に当てはまる期待出力が存在しないからです。 一方で select-tracks のような 単一のステップ はテストできます。期待値として、正確な曲目ではなくセットの方向性を記述します。

実ユーザーに対する A/B テスト

コメントのトーンのように、オフラインでは採点しにくい変更もあります。 リスクが低いので、チームは一部のリスナーに新バージョンを提供し、スキップ率や message_type の分布といったシグナルのスコアをグループ間で比較できます。 新バージョンのほうが良ければ、全体に展開します。

ここまでそろうと、ループ全体が回っている状態になります。

まとめ

これは、リスクが低く、学習に使える過去データもない機能の例です。 こうした場合に取れる最善の手は、できるだけ早くトレースを取り始め、それをモニタリングすることです。 データセット、実験、A/B テストといった残りは、その上に時間をかけて積み上げていけます。

他の例 や Academy も参照してみてください。